Wordpress Exploit

I recently upgraded to WordPress 2.5 – and in the process of doing so, I noticed something funky with my older 2.3.3 installs claiming to be 2.5 already. I thought it was odd – but didn’t immediately come across anyone having reported strangeness here and so I just ignored it.

Now that 2.5.1 is out, I thought I’d go upgrade again. Well, after the upgrade I was still having the dashboard tell me that I needed to upgrade. Odd. This time a web search did uncover information that was relevant.

Details on the wp-info.txt exploit are interesting. It seems to me that several problems are being lumped into the one discussion, but I found some helpful advice to help clean things up from the links provided there.

Symptoms:

Presence of wp-info.txt
Displayed version changed without upgrading.
Database modifications
New files ending in _new, _old, .pngg, .jpgg, .giff appearing inside writable directory

What is odd – is that the problem was pretty widespread on my system, based on the number of files that I had to remove / modify this feels very much like a ‘worm’ type attack that continues to re-insert itself. I certainly found files that had been multiply modified. (Memo to self – dig deeper when we see backups of strange files that shouldn’t change).

My first step was to punt the bogus files.

find . -name *_old* -exec rm '{}' \;
find . -name *_new.php* -exec rm '{}' \;
find . -name *.giff -exec rm '{}' \;
find . -name *.jpgg -exec rm '{}' \;
find . -name *.pngg -exec rm '{}' \;
find . -name wp-info.txt -exec rm '{}' \;

find . -name *_old* -exec rm '{}' \;

find . -name *_new.php* -exec rm '{}' \;

find . -name *.giff -exec rm '{}' \;

find . -name *.jpgg -exec rm '{}' \;

find . -name *.pngg -exec rm '{}' \;

find . -name wp-info.txt -exec rm '{}' \;

There will also be some ‘magic goo’ inserted into of many of your .php files. You should be able to locate them by doing the following at the root of my web structure:

grep -ri _wp_debugger *

1 2	grep -ri _wp_debugger *

I simply edited out the offending lines manually.

It also seems that any file that matches

grep -ri qwerty *

1 2	grep -ri qwerty *

is bogus as well, and needs to be removed.
Then it was time to dig into the databases. Lucky me, all of my wordpress installs had been hit by this so that meant walking more than one database.

The first thing to check is the active plugins. It seems that part of the exploit installs a hidden plugin that you need to edit the database to see and remove. The normal wordpress plugin view will not show you.

SELECT * FROM wp_options WHERE option_name = 'active_plugins';

1 2	SELECT * FROM wp_options WHERE option_name = 'active_plugins';

If you do have an entry that is clearly not one of the plugins you intend to have running, you need to clear things out. Mine looked something like “../../wp-content/uploads/2007/05/colour_temp_3_old.jpg”. Which sort of explains what is going on with all those bogus files we removed before.

The following SQL will disable all plugins

UPDATE wp_options SET optionvalue="" where option_name="active_plugins";

1 2	UPDATE wp_options SET optionvalue="" where option_name="active_plugins";

Once you do this – go back and re-enable any plugins you do want running.

Another issue is the inclusion of a phantom user “WordPress”. Again this requires database spelunking as the normal wordpress UI will not show you this malformed user. Use the following SQL to look at the user table.

SELECT * FROM wp_users;

1 2	SELECT * FROM wp_users;

In my case – the user id attached to the bogus user was 8. So was able to delete the row using:

DELETE from wp_users WHERE id=8;

1 2	DELETE from wp_users WHERE id=8;

At this point, my 2.5.1 upgrade stopped telling me that I needed to upgrade to 2.5.1 – so I may still have some problems lurking, but I think I’ve cleared out the bulk of the problem. What a mess.

Leave a Reply