A few words about the RISKS of WordPress 1.2, 1.5, 2.0 or anything less than 2.0.4

A Real World Attack

If you want a quote to put in an article just say “Anybody with a basic webserver account, can strip a WordPress 1.x website of its posts and comments, without you doing a thing wrong, and you won’t even be able to find out who did it.”.

If you haven’t updated, I can understand why you find this hard to believe. After all, nothing has happened yet has it? I was a more than a little surprised at the vulnerabilities myself, but this method posted in multiple places on the web for months now.

When Michael wrote:

I have a hard time accepting that this could be done WITHOUT A TRACE, not even in the Apache logfiles! […] So either you are telling me that someone can hack into WP and then instruct WP somehow to delete files (an even so his hacking in would be logged) or – and this is even harder to believe – an attacker would manage to break out of the virtual server, gain root access, and manage to clean up the logfiles manually.

I responded with some details of the attack. I’ll remind you that a simple 35 second upgrade makes your site invulnerable to this attack. I said to Michael:

There’s a third option that you have not listed. That the attacker does not actually perform attack. He gets you to do it without realizing [you’ve done so]. The attacker simply leaves a trigger on your site. From then on, it is just a matter of time till you activate it. Activation can be [be triggered by something as simple as] a logged in user, with admin powers, visiting the site.

The technique I mailed to Security@wordpress involved creating an image that worked as a normal image until a WordPress admin viewed it. At that point, it activated its payload, which could be one of many different actions, taking advantage of weaknesses in WordPress 2.0.2 and earlier. The working example I sent to Matt and Ryan involved deleting a post and then [also deleting] the comment containing attack.

Regarding the Apache log, notice that I said “there wouldn’t be any *traceable* evidence in your Apache logs”. There would be evidence, but it would show that a user left a comment [and how coud you pick out a comment by an attacker vs one by a spammer, especially when the damage isn’t done until hours or days later.] It would be one series of entries in your apache log, as the attacker uses an anonymous web browser site to leave a comment on your blog.

That comment could contain many one pixel white images that when viewed by a WordPress administrator would, each, delete a single post. The very first image would be the command to delete the comment [containing the attack].

That’s about as much detail as I can give you without giving you actual working code.

Pretty neat, huh? Have you ever made a post and then not logged out? If so, the next time you go to your WordPress 1.5.2 site to review the comment a user left, you might delete a few hundred posts. Wouldn’t that be a nice surprise for the next morning? How recent are your database backups anyway?

Most members of the WordPress Hackers (hackers as in code writing not attacking) mailing list have seen “Proof of Concept” working examples of each of the attacks I listed on the first page of this article. They have also been published at security sites. The blogs of people who have discovered them often post working examples. I’ve verified that each of those attacks did work on a specific version of WordPress.

What we need to do is convince the people running 1.x or 2.0.0 that if they don’t do something soon, their sites will be taken over or wiped out.