This attack has been around a while, but an IP range in Belarus with a user-agent of Mozilla/4.0 appears to be trying it again. WordPress servers should be prepared for the old SQL attack.

Here are just two of the many attempt types:

?cat=999+UNION+SELECT+null,CONCAT(666,CHAR(58),user_pass,CHAR(58),666,CHAR(58)),null,null,null+FROM+wp_users+where+id=1/*

?cat=%2527+UNION+SELECT+CONCAT(666,CHAR(58),user_pass,CHAR(58),666,CHAR(58))+FROM+wp_users+where+id=1/*

This attack tries to expose the blog software’s admin (id=1) password. I guess 666 is a delimiter for someone — if successful the attack looks like it will generate a page with the admin password hash positioned between a pair of 666 and colons (CHAR58) like this:

666:PasswordHash:666

To check and see if you have been breached use a shell account and login to mysql:

mysql -pPassword -u Username Databasename

Then look for id=1

select * from wp_users where id=1;

This should show you the admin account information including the hashed password.

One form of prevention against these lame scripted attacks is to setup a WordPress blog with the wp_users column named something else, such as dudes or even just users. The problem with this is keeping WordPress and its plugins aware of a new column name. Defaults have the obvious risk but WordPress does not even allow the admin account name to be changed without directly editing the database.

Another way to reduce the effectiveness of scripted attacks is to use an application-level firewall like SEO Egghead’s plugin or PHPIDS.