W3 Total Cache and WP Super Cache Vulnerability Being Targeted in the Wild

As if on queue, almost 7 days since we released the post about the latest W3TC and WP Super Cache remote command execution vulnerability, we have started to see attacks spring up across our network.

In our post you might remember this:

<!–mfunc echo PHP_VERSION; –><!–/mfunc–>

In this example we explained how it was a very simple approach to displaying the version of PHP on your server. There were a lot of questions following that saying, well what’s so harmful in that. Etc… With little help from us the attackers go on to show us what they can do.

Taking a Look at the Attacks

In this section I’ll show you three of the various attacks we’re seeing. In each you can see how they abuse the mfunc vulnerability, one in a more traditional approach of injecting a backdoor and other in a more creative way that allows them to abuse HTTP headers. In either case they all seem to be getting passed via comments, and we give an example of that below. This is obviously for educational purposes only.

Example One – Targeting HTTP Headers

So in this example we see them abusing the mfunc vulnerability to pass shell commands via the HTTP headers in the place of the URL itself.

Screen Shot 2013-05-03 at 8.56.49 PM

In this instance they are attacking your site while leaving very little trace, for instance they can do things like:

HTTP_CMD: Base64 encode of the backdoor/code they want to run

And it works with GET. Here is a better explanation if you’re not following:

A normal header would look something like this:

Connected to site.com (IP) port 80 (#0)
GET / HTTP/1.1
User-Agent: curl/7.24.0 (x86_64-apple-darwin12.0) libcurl/7.24.0 OpenSSL/0.9.8r zlib/1.2.5
Host: blog.sucuri.net
Accept: */*

With this attack it’d look something like this:

Connected to site.com (IP) port 80 (#0)
GET / HTTP/1.1
User-Agent: curl/7.24.0 (x86_64-apple-darwin12.0) libcurl/7.24.0 OpenSSL/0.9.8r zlib/1.2.5
Host: blog.sucuri.net
HTTP_CMD: Base64 encode of the backdoor/code they want to run
Accept: */*

Most folks would never even log that, so forensically speaking it’d be hard to know they were attacking this way.

Example Two – Passing a Backdoor

So in this example they misuse the mfunc and use it to pass a backdoor into your server. Not nice at all.

Screen Shot 2013-05-03 at 7.54.05 PM

In this case it looks a bit worse, but when you decode it, it’s a lot easier to understand, her it is decoded:

Screen Shot 2013-05-03 at 7.56.09 PM

Do you see what they’re doing? How they’re passing basic PHP commands to your server? Look here:


They’re using basic PHP functions against you. They use the fopen to open a new file called maeksv.php. They then inject the payload into that file using puts, they encode it, and proceed to close the file. If you look at the payload that was dropped into that file you find something like this:

Screen Shot 2013-05-03 at 7.58.36 PM

Don’t worry, a little fine tuning and you see it’s real intention here:

Screen Shot 2013-05-03 at 8.03.32 PM

Using this the attacker can now do something like this:

Example Three – Embedded with Comments

We know that these are occurring via comments but it’s always fun to see the things they say, like this for instance:

Screen Shot 2013-05-03 at 8.31.42 PM

Or even this:

Screen Shot 2013-05-03 at 8.33.57 PM

So in these scenarios they are leaving you what appear to be legitimate, yet silly, comments. If you’re none the wiser that’s all you’d see, approve and be on your way.

Where are they Coming From

Well, here are some of the IPs we’re picking up via our network:

Some quick look ups show us IPs coming from all over – Netherlands, Brazil, China, Russia, Singapore..

What To Do?

The most obvious thing is to update immediately, both authors have made changes to their core to address these issues. That in it of itself will help you. Other options include the following:

  • Leveraging a Web Application Firewall (WAF)
  • Adding Captcha’s to comments to deter spam bots
  • Ensure all comments are going through some kind of moderation
  • Don’t land the comments on your server, leverage 3rd party plugins – e.g., Disqus

In the guidane above do realize that the captcha won’t necessarily protect you if you accept it, but it should slow bot attacks.

About Tony Perez

Tony works at Sucuri. His passion lies in educating and bringing awareness about online threats to business owners. He spends his time giving presentations and writing content that everyday website owners can appreciate. His passions revolve around understanding the psychology of bad actors, the impacts and havoc hacks have on website owners, and thinking through the evolution of attacks. You can find his personal thoughts on security at Tony on Security and you can follow him on Twitter at @perezbox.

  • babel

    why dont write a crawler that fixes the issue on all affected open accessible websites!

  • http://twitter.com/wmwebdes Keith Davis

    Hi guys

    Just picking up on something you said towards the end…

    “Don’t land the comments on your server, leverage 3rd party plugins – e.g., Disqus”

    Does that mean that using Disqus or Livefyre is another way of hardening your site?

  • http://seanja.info/ Sean Sandy

    Surely Akismet would catch a comment that is just a base64 encoded string

  • Adam D

    Hrm. Great post but WAFs are almost totally redundant unless the hackers are complete idiots and ALL are very easy to bypass. I’d not have that at the top of list of security measures.

  • Robert Maroon

    HI Tony,

    Maybe I am late for the party, still I would like to ask a question.

    You suggest to land comments on somebody else’s server, by using a service like Disqus, but… wasn’t it a source of a DDOS just a couple of weeks ago?


    (Apart from the fact that pingbacks should be disabled by default.)

  • http://www.friv3.co/ friv 3

    This goal can be achieved if not, I will wait for its results.

  • PPlank

    “As if on queue” – what you really meant to say was “As if on cue” 😉

Share This