Jump to content

XSS/Code Injection Issues


Recommended Posts

I am running the latest version of Revive Adserver and am experiencing what I believe to be XSS code injection issues. I believe there could be a vulnerability/exploit out there. I've been running PHPAdsNew/OpenX/Revive for over 10 years and haven't had this happen before.

I've checked for extra admin accounts and there are none, I changed my passwords, etc., but basically any ads I display cause a malware pop-up that you can't close followed by virus warnings. Also, I found files that were likely injected into my images folder...the contents were php but coded so they could not be read:

  • ef245a0187359c78f346589bb7628562.php
  • 45a0187359c78f346589bb7628562.php

Any ideas out there on how to deal with it? I could use some help! Thank you!

Link to comment
Share on other sites

If you haven't already, move the current revive webroot somewhere else for later review.

Do a clean install of revive. Move only your image files to new install and copy your config over after manually reviewing it.

Review the append and prepend fields in _banners and _zones tables. Look especially for <script> and <iframe> tags that should not be there.

This may help you find the file that was compromised.

grep -rIP '(eval|exec|system|passthru)\(' /path/to/revive-install | grep -P '\$_(REQ|GET|POS)'

Reset passwords and review rest of server. Through the files you found other areas may be infected.

Link to comment
Share on other sites

Thank you for this! I will report what I find here. So that grep command did not work because the files I found are somehow encrypted. For example, here is a small part of it: 

<?php $ijdskjfk["&@#13^3^4^%&3$*136223%(&3&%3%14**2&@$#&*6^#^^$&1(_22%!^=@%^+#@^&##@3##333#2$^3-3&$$3(323^^2&3)15&&5$57*)%)^53%&2#226&^%%%1##4^-^=4&43&^@#4=^%-3*3"]="\x32@\x25%\x25@\x5e%\x35^\x5e5\x32)\x25+\x3f5\x325\x34*\x31*\x5e1\x32&$


Link to comment
Share on other sites

So I disinfected my site...these two files, according to Comodo, were back door scripts. Both were in my site's /www/images directory, so everyone may want to check their installation as well. The most disturbing thing is that one had the same date/time stamp on it as the Revive Adserver files 5/24/18 @ 3:49 AM. Is it possible that hackers somehow added this file to Revive's installation zip file before I downloaded it? I am just speculating here, but I am not sure how else that file could have the same date/time stamp as my other files.

Link to comment
Share on other sites

One of the Ad Networks that I used to serve ads from is called District M. Through them, unfortunately, I was also serving ads that contained horrible pop up malware...the type of ad pop up that you can't close or use the back button on--Usually claiming that you won a prize or that your device is infected and you simply need to download their "fix" to resolve it. I am wondering if it is possible that this type of malware could have also been the source of the 2 backdoor files? Could this malware also have utilized a Revive Adserver exploit to get the two files onto my site? 

I am surprised that more Revive folks have not responded here, as I do believe that there should be more concern about whatever exploit is being used to infect Revive installations. I've been using this software for over 10 years since it was called PHPAdsNew, and have never had such issues before.

Link to comment
Share on other sites

 This Topic is very important!

It seems to me that I protected my server by disable writing to the images directory.

I have a php script that injected into the images directory, like as ef245a0187359c78f346589bb7628562.php

I was unable to create a report on hackerone.com

Please take action!


Edited by Oleg Rumjancev
add link to the exploit script
Link to comment
Share on other sites


Unfortunately, we had the same issue with our ad server today.
Digging through log files I found some activities related with ef245a0187359c78f346589bb7628562.php and 45a0187359c78f346589bb7628562.php.

Please check: http://ads.kajgana.com/access-log.html

Link to comment
Share on other sites

Hi @scott001, @Oleg Rumjancev, @Dejan & other interested parties!

Thank you very much for your posts above. Obviously, we want Revive Adserver to be as secure as it possibly can be, and reports from the community help us to do this. 

Firstly, it's very pleasing to hear from @scott001 that this is the first issue in over 10 years of use - I hope that helps to go to show that compromising Revive Adserver is not easy an easy thing to do!

In terms of @scott001's post about the two back-door scripts having the same date/time as the rest of the release file, I would like to remind all users to always ensure they get Revive Adserver from the official website links, and to check the MD5 hashes of the files that we publish before using them. We have seen reports in the past where we suspect (but have not been able to prove) that users downloaded Revive Adserver from a non-official source, and that their systems were compromised in this way. (I am not saying that @scott001 definitely did this - I just wanted to reminder everyone to use the official source.)

Having said that - we have double checked our releases, and they have not been compromised - so, the files @scott001 was seeing may have come from elsewhere. (It is possible to alter the creation date/time of files, so it's not a guarantee of when they were created.)


In terms of the Revive Adserver team responding to posts such as these - unfortunately your post came during what (for all of us) was a bit of an end of year break. We, unfortunately, are not a large, well funded team, able to provide 24/7 support - this is a community forum (rather than a paid for support system), after all. (If you'd like to help us out, so that we can grow, and possibly move towards more core-team support, please see our Patreon page!).

If, in future, anyone has concrete evidence of system compromise - with specific details that will help us figure out the cause - then please, do by all means raise a HackerOne issue. We are more likely to see and respond to comprehensive, detailed reports of issues there. (But please note we will not allow HackerOne issues that attempt to simply get personal support from the core team.)

I do note that @Oleg Rumjancev has reported an inability to log a report in HackerOne, but as far as I can see, the system is working fine - it may be worth attempting this again, if you have specific information that could help us trace a vulnerability, please.


I hope that all of this helps clarify what you can expect from the core team, and the best way to deal with and report security issues!



Link to comment
Share on other sites

  • 2 months later...

So the only further info I have is that it is possible that a 3rd party network that I was serving ads from served malware that somehow allowed them to inject those files. The strange thing was that they were indeed dated to the exact time and date as the rest of the installation files. I do always upgrade from Revive, and follow the link in admin to the upgrade file download.

One think I wanted to point out, which could be a vulnerability, and I've pointed this out before, there are copies of the php config files in /var/cache which contain the password data. If you try to protect these files by chmoding them 644 you will get warning that your permissions are set incorrectly, and your ad stats may not be properly counted. The only way to stop the error, and the recommended permissions when running an installation where those directories are set to higher permissions, is to chmod them to 666. I am not sure this is secure enough.

In any case, I did track the malware ads as coming from the 3rd party network, but I also discovered some injected hidden link to an Italian shopping site that was put into all pages of my site. Once I removed the two files mentioned that I found in the images directory the hidden links in my site ended.

So I suspect that the malware ads that were served were somehow able to pull in the 2 files to the image directory. There needs to be an .htaccess file in that directory that stops php files from executing.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...