How to find a backdoor in a hacked WordPress

Over here, Jorge Escobar is writing about how he got hacked with the latest version of WordPress. After some minor back and forth on FriendFeed, I got him to do a search which found a malicious backdoor he might not otherwise have found.

In so doing, it occurred to me that most people don’t keep up with the world of WordPress in the way I do, and so have not seen nearly as many hack attempts. So I figured I’d post my little contribution, and show people how to find hidden backdoors when cleaning up their hacked sites.

Non-technical users can safely ignore this post.

What’s a backdoor? Well, when somebody gets into your site, the very first thing that happens is that a backdoor is uploaded and installed. These are designed to allow the hacker to regain access after you find and remove him. Done craftily, these backdoors will often survive an upgrade as well, meaning that you stay vulnerable forever, until you find and clean the site up.

However, let’s be clear here: After you get hacked, the ONLY way to be 100% secure is to restore the entire site to a period before you were hacked, and then upgrade and/or patch whatever hole the hacker used to gain entry. Manual cleanup of a site is risky, because you might miss something. It’s also time-consuming. But, if you don’t have regular backups, you may have no real choice.

First, the obvious stuff:

A backdoor is code that has been added to your site.

It will most likely be code not in the normal WordPress files. It could be in the theme, it could be in a plugin, it could be in the uploads directory.

It will be disguised to seem innocuous, or at least non threatening.

It will most likely involve additions to the database.

Let’s go over these individual points one at a time.

Added code

While it’s true that simple “backdoors” often take the form of hidden admin users, generally complex backdoor code is simpler than that. It simply gives the attacker the means to any PHP code they like, usually through the use of the eval command.

A simple example would be this:

eval($_POST['attacker_key']);

This, very simply, executes any PHP code sent to it from a browser.

Of course, they wouldn’t put this code just anywhere… It has to not be that easy to find, and it has to survive a normal WordPress upgrade.

How to hide code

First, we have to consider where we can put our malicious code. A WordPress upgrade deletes a lot of directories. There’s three obvious places:

1. Themes. Good plan, themes survive core updates. However, people tend to edit their themes a lot. Also theme names change around a fair amount, so doing this automatically is difficult.

2. Plugins. Plugins are a good place to hide code. People don’t generally look at them in detail, and many plugins have vulnerabilities of their own that might be exploitable. Some of them even keep some of their directories writable, meaning we can directly upload our backdoor code to there easily, after we gain access.

3. Uploads. Perfect. It’s explicitly designed to be writable. People don’t generally see what’s in the folders, since they’re just looking at the normal interface in WordPress. This is where something like 80% of backdoor codes get put.

The art of disguise

This one is easy.

Step 1: Pick a name that looks harmless.

wp-cache.old. email.bak. wp-content.old.tmp. Something you won’t think of. Remember, it doesn’t have to end with PHP just because it’s got PHP code in it.

Step 2: Hide the code itself.

Except in special circumstances, legitimate code will not use “eval”. But, it happens often enough to be generally considered not harmful in and of itself. So looking for “eval” is not a good way to find malicious code.

However, attackers need to disguise their attacks over the wire as well, to prevent hosts from blocking them. The easy and cheap way to do this is base64 encoding.

Base 64 encoding lets them disguise their commands to their hidden “eval” command to be just a random looking string of letters and numbers. This is usually enough to get by any server filtering. However, this does mean that their code will have one tale-tell thing in it: base64_decode.

Base64_decode (and the similar uudecode) are the main way to find malicious code used today. There’s almost never a good reason to use them. Note the “almost” there, many plugins (notably the venerable Google Sitemap Generator) use base64_decode in legitimate ways. So it’s not exactly a smoking gun, but it is highly questionable for some randomly named file lying around to have that inside it.

Smarter authors realize this, and so have taken steps to hide even that sign…

Database obfuscation

Here’s a bit of code I’ve seen around recently. This code does something really clever. Note that it was heavily obfuscated by including hundreds of line of randomness, hidden in /* PHP comments */. This is why having a text editor with code and syntax coloring can be very handy.

Note, this code was in a file named wp-cache.old in the wp-content/uploads directory. It was included at the end of the wp-config.php (also a file that usually does not get overwritten in an upgrade).

The function named strrev is used. strrev reverses a string. So the code that it’s pulling out is reversed! So much for looking for “base64_decode”.

The actual value in the database looked like this:

...a bunch of junk here...J3byJXZ"(edoced_46esab(lave

Reverse that. What do you have? Why, it’s our old friends eval and base64_decode. Clever. Searching the files for these two warning signs would have uncovered nothing at all. Searching the database for same would have also shown nothing.

The key it used, BTW (rss_f541b3abd05e7962fcab37737f40fad8) is also designed to be nonthreatening. WordPress itself creates several similar looking keys as part of its RSS feed caching mechanism.

So, break down how this code works.

The hacked wp-config.php code causes an include of a nondescript file, called wp-cache.old.

That code, which does not use any trigger words, loads a nondescript value from the options table.

It performs some string operations on that code, then executes it.

The code in question was the rest of the hack, and did many different things, such as inserting spam links, etc.

Summary

This is the sort of thing you’re up against. If your site got hacked, then there exists a backdoor on your site. Guaranteed. I’ve never seen a hacked WordPress installation that was missing it. Sometimes there’s more than one. You have to check every file, look through every plugin, examine even the database data itself. Hackers will go to extreme lengths to hide their code from you.

And one more thing… before claiming that your WordPress got hacked even despite having the latest code, make sure that it wasn’t actually hacked already, before you put the latest code on there. If you don’t fully clean up after a hack, then you *stay* hacked. It’s not a new hack, it’s the same one.

The latest WordPress (as of this writing) has no known security holes. Claiming that it does when you don’t know that for sure is really not all that helpful. You’re placing the blame in the wrong place. The WordPress team makes the code secure as is possible, and is very fast on patching the security holes that are found, when they’re found. But they can’t patch code that made it onto your site from some other method, can they? Just something to keep in mind.

Before switching to 2.8.4, our site was compromised. The @*%$! spammers deployed two files to our system /wp-admin/fotter.php and /wp-admin/inclode.php (note the purposeful misspellings). These were encrypted files that were web-based backdoors. These were causing our theme footer to be overwritten nightly.

great post, let me wonder about potential ways to avoid – at least – some hack attemps. first one: deny via htaccess any GET querystring with, let’s say, base64 or 46esab (actually, who need them?). second one: a little plugin that looks around for the same things in POST queries.

It’s still early days, but I’ve written a script to help seek out old versions of WordPress and even help with some of the clean-up. Introducing WordPress Butler!. It will be most useful for web hosting companies or individuals who manage multiple WordPress blogs on the same server.

We’ve been hacked. I found a file hidden in an upload folder, called 257409.php. No reason for a php file to be buried in one of those folders. It contained 203KB of random characters. It took me a bit to find the hidden eval and base64_decode within (it being on the first line helped, though).<?php $wvUJRFQ='###e####va#####l########(#ba##s##############e###########6###4############_##d##################e#c#########o####d#e##(

We are going to go to a brand new theme (ours is very old) and upgrading to the latest version of WordPress – and will follow the instructions in the article How To Completely Clean Your Hacked WordPress Installation. Should we be looking for more backdoors or other malicious code if we do this?

P.S. I’ve found several other files that have been altered, including wp-manager.php, wp-blog-header.php… I can’t even begin to figure out what to do with the wp-manager file, since I don’t have the original. On to re-doing the site. Quite insidious, this invasion!

Thanks, Otto. I’m kinda compulsive, so I had to comb through the site to find whatever I could. There were, as you say, more backdoors, and I don’t trust that I caught all of them. I also deleted multiple users from the database, and did lose the extra (hidden) admin person. I can see that they easily could have gained access through our plugin folder. I’m learning a lot more about this than I ever planned to learn. I guess it’s good. I appreciate your sharing this information.

Does anyone know if people who installed WP into a randomly named sub-directory under the DocumentRoot were less likely to get hacked? It probably doesn’t matter too much, but if any of the backdoors assumed where files were located with respect to the docroot — then installing WP in a subdirectory would be another security measure. Not that injected code couldn’t smarten up and add logic to compensate. I’m just curious. Also, did it affect WPMU installations the same way?

one of my sites got hacked, I had it restored to a Jan 6th version…(I am adding the lost info and will do a backup). I did have the latest version of wordpress but like you said, the hack could have already been installed.

I had it restored to a previous date but…

HOW do I prevent this from happening again on this site, as well as, on my other sites which haven’t been hacked –in other words, how do I find the backdoor and close it?