This attack seems to be taking advantage of the security vulnerability that necessitated WordPress 2.6.3, whereby if an attacker could get control of an RSS feed that you publish on your blog (for example using the RSS widget), he might be able to execute any commands.

Hackers are taking advantage of the open-source nature of the software to analyze the source code and test it for potential vulnerabilities. It is then left up to developers and users to detect, track down, and then close off the vulnerabilities in the code that attackers are using. The pattern seems to be that when a new hole is found, it is broadly exploited, then developers rush out a patch and a new release.

Agreeing with many of his overall points, such as the necessity of making frequent backups and keeping up-to-date, I thought it was interesting to note that the specific sites he mentions do not seem to support the premise that they fell even while diligently being updated.

By checking the source of these sites as cached by various search engines, you can see what version of WordPress they were using recently. The first one Cubrilovic mentions was “hacked” back in January, when it “was running the most recent version of WordPress available at the time.” Apparently that attack didn’t inspire its maintainer to keep up with updates, as a cached page shows that as recently as the end of May it was using a version of WordPress, 2.3.3, that was seven weeks outdated.

Cubrilovic also links to another compromised site, whose owner admits that he had “been running an ancient version of WordPress and had meant to upgrade, but it never seemed urgent.” At another he points out, the owner says “I was already at the latest, 2.5.1, and still got hit.” However, a cache search shows that as of June 1 the site was still using version 2.5, five weeks after the 2.5.1 security release, suggesting that the attack came prior to the upgrade. TechCrunch itself as of three days ago ran a version of WordPress over 10 weeks old.

Cubrilovic makes it sound like a WordPress user has to follow every bit of news about WordPress to stay safe: “For users of WordPress, backups are essential, as are frequent updates, monitoring your blog usage and tracking the official WordPress blog and other blogs for news of any new security holes.” That’s not bad advice, but keep in mind that since WordPress 2.3 there has been a prominent, automatic reminder to upgrade whenever a new release comes out. In each of the examples, the users had to ignore week after week this message at the top of their admin screens:

According to Donncha O Caoimh of Automattic, this exploit took advantage of a vulnerability that has been fixed in the latest stable version of WordPress, 2.5.1. As he points out, although 2.5.1 sites have succumbed to the attack, the evidence so far is that they were compromised prior to being upgraded. O Caoimh has a thorough description of how to identify this hack, how to avoid hacks in general, and what to do to recover from a hack in general. If you manage a WordPress blog, you should read his post.

This topic has appeared in the WordPress bug tracker, on the WordPress.org support site, and a number of people have blogged about it.

I am curious about his antipathy towards version 2.5, something he promises to blog about later. My guess is that it has to do with the design of the administrative back-end. That just confirms my opinion that the WordPress admin should be template-able. After all, no one ever decided not to upgrade WordPress because they didn’t like Kubrick.

Veaux does link to some of these sites in his post, so don’t follow those links unless you really know what you’re doing.

The scenario is like this: you go to leave a comment on someone’s site, and surreptitiously that (evil) site tricks you into changing your WordPress admin password and emailing it to the evil site owner by clicking what appears to be a comment submission button.

WordPress guards against CSRF attacks in general by confirming actions that don’t seem quite right (i.e. when the nonces don’t check out), but this attack hides all of the confirmation message except the approval button, which appears to be part of the evil site’s comment form.

It’s very easy to imagine how this could be targeted at a user’s blog by using the URL the user enters in an evil site’s comment form. I’ve submitted a suggested solution as a WordPress Trac ticket.

How can you avoid this attack for now? Don’t stay logged in to your WordPress blog when not necessary, and change the default username (or blog under another username with just “author” permissions, and keep “admin” just for occasional site maintenance).

UPDATE: My patch has been committed to both development WordPress and the 2.3 branch, so this issue should be taken care of in the next security release.

Actually, the development version of WordPress has been implementing a new “prepare” method of the WordPress DB class. The “prepare” method uses vsprintf to makes sure sure, for example, that integers are truly integers, which should accomplish the same thing as Kierznowski’s proposed escape_int and escape_str methods.

And WordPress once actually did use mysql_real_escape_string(), over two and a half years ago. The problem is that WordPress’s minimum requirements specify only that one use PHP version 4.2 or newer. However, mysql_real_escape_string() was not introduced until PHP version 4.3.0, so WordPress had to rely on an alternate way of escaping queries, one that apparently has caused some trouble, so the whole thing was bypassed. However, PHP 4.3.0 functions have crept into development WordPress already, so it’s likely by the time of the next release (version 2.5) in the spring, that the minimum version will have increased and WordPress will be free to use mysql_real_escape_string.