WordPress vulnerability at identityblog

Sun's Rohan Pinto has spent a fair amount of time this week using a recipe that has been discussed in the Blogosphere recently to hack into my blog, which runs WordPress 2.0.1, and then apologizing for it (I appreciate that, Rohan).

He was able to use a vulnerability in WordPress to employ his “subscriber” account (which normally only grants comment rights) in order to import a fake post onto my site (I've since removed it but it is shown at the right).

The exploit used was described about three weeks ago (July 27th, 2006) when Dr. Dave published his “Critical Announcement affecting ALL WordPress Users.”  All in all, it was a fairly stern warning.  I would have upgraded to a newer version of WordPress but couldn't because I was travelling:

If you are running WordPress as your blogging platform and if you have been trusting enough to leave User registration enabled for guests, DISABLE IT IMMEDIATELY (in wp-admin >> options: make sure “Anyone can register” is not checked).

Additionally, delete or disable ANY guest account already created by people you are not sure about.

Leaving it open and letting people sign-up for guest accounts on your WordPress blog could lead to incredibly nasty stuff happening if anybody so desired. And trust me I am not exaggerating this. So don’t wait a second to disable this option and please relay the message. WordPress dev team has been notified a while back and I dare hope they will soon start acting on it, if only by relaying a similar announcement through the official channel (as well as, of course, releasing a proper patch).

Sorry for the shrill hysterical tone, but this is a big deal. However, disable that one option and you are fine, no need to panic further

[cheers go to Geoff Eby for discovering and bringing this insane security exploit to my attention]

Initially Rohan entitled the post that described the exploit, “Is Cardspace Secure Enough?”.  That bothered me, since the exploit had nothing to do with InfoCard or Cardspace or my PHP demo code.  Rohan was good enough to later make that perfectly clear:

Pursuant to my prior post. Please do take note of this. I would like to make it crystal clear to everybody that me logging into Kim’s blog and publishing as “him” was NOT a infocard exploit, but rather a “wordpress” exploit…

Please, please, please do note, that this IS NOT a infocard hack.

Conor Cahill read about the exploit and commented: 

Access Control is always going to be a responsibility of the entity managing the resource (in this case, Kim's blog is managed by a wordpress installation that he setup on his server, so his server must manage the access control).

The selection of the tool to manage the rescource will be based upon the reliability of the manager and the value of the resource.

I'm sure Kim wouldn't have put his bank account up on wordpress without a lot more testing and perhaps requiring someone else to stand behind it should there be such a problem…

All of this is true, of course, with the exception that my blog usually has more in it than my bank account.  Further, in the case of WordPress, it is the application that manages the security, not the underlying operating system or environment (in this case a LAMP stack) or hardware.

Of course, I didn't choose WordPress because it was the most secure solution in the world;  I chose it because it was an interesting blogging tool, with a lot of cool features, and would help me learn about the issues confronting people on non-Microsoft platforms so I could have a more inclusive view of identity problems.  And it has been great for those purposes.

You might think I would be abandoning WordPress.  But I won't.  I like it and want to continue to explore what it is like to work with it, and help make it better.  To me the real lesson in all of this is that the approach to remote operations used in WordPress – and almost all web-based applications – is just not adequate.  The more you know about all the exploits that are possible in the http world, the more you want to run headlong into the world of Web Services, where each transaction has its own security environment, in the sense that the security environment travels with each message and operation.  In the same way, SOA moves the control of authorization from the application to the operation definition process, so creative application authors like those who built wordpress, don't have to take sole responsibility for all the subtle security problems that will inevitably arise as we move further into the virtual world.

I take it for granted that given all my pontification about identity and security my site will be used in creative ways.  So I have no ill feeling toward Rohan.  The important thing is the conversation and the learning that come out of this.

So to rephrase Conor, in this case, the selection of the tool to manage the rescource will be based upon an analysis of the risks and benefits of using an emerging technology to reach others working on the issues.