WordPress cookie authentication vulnerability

In my previous post, I discussed how I analyzed the recent attack on Light Blue Touchpaper. What I did not disclose was how the attacker gained access in the first place. It turned out to incorporate a zero-day exploit, which is why I haven’t mentioned it until now.

As a first step, the attacker exploited an SQL injection vulnerability. When I noticed the intrusion, I upgraded WordPress then restored the database and files from off-server backups. WordPress 2.3.1 was released less than a day before my upgrade, and was supposed to fix this vulnerability, so I presumed I would be safe.

I was therefore surprised when the attacker broke in again, the following day (and created himself an administrator account). After further investigation, I discovered that he had logged into the “admin” account — nobody knows the password for this because I set it to a long random string. Neither me nor other administrators ever used that account, so it couldn’t have been XSS or another cookie stealing attack. How was this possible?

From examining the WordPress authentication code I discovered that the password hashing was backwards! While the attacker couldn’t have obtained the password from the hash stored in the database, by simply hashing the entry a second time, he generated a valid admin cookie. On Monday I posted a vulnerability disclosure (assigned CVE-2007-6013) to the BugTraq and Full-Disclosure mailing lists, describing the problem in more detail.

It is disappointing to see that people are still getting this type of thing wrong. In their 1978 summary, Morris and Thompson describe the importance of one way hashing and password salting (neither of which WordPress does properly). The issue is currently being discussed on LWN.net and the wp-hackers mailing list. Hopefully some progress will be made at getting it right this time around.

5 thoughts on “WordPress cookie authentication vulnerability

  1. Someone should write up a proper description of how to do this kind of website password security in one place. How to store a password. How to generate an authentication cookie when someone logs in. Whether to stretch passwords. How to use an email address to handle the situation where a user forgets their password (so many sites get this wrong in so many ways). And so on.

    Bad practice in this area is I’m sure far more common than good. Many web applications still email you your password as soon as you set it!

  2. In the past, the attitude of the core WordPress developers towards security has always left something to be desired — attempts to proactively improve security, including the authentication system, have been shouted down for various reasons (performance, compatibility with ancient versions of PHP, etc.). Last I saw they were still ignoring suggestions to start using parameterized SQL.

    Vulnerabilities with exploits in the wild usually get fixed fairly quickly, at least, especially highly public ones. So there’s hope for this one… 🙂

  3. Oh, my. Before reading your posts, I had never looked at WordPress’ source code, and I’m still shocked how such a popular software has an amazingly bad code quality. Definitely, I’m not ever using it for anything.

  4. @Abel Cheung

    Yes, I’ve been following along on the mailing list. I’m not a member and other list members have already made the points I would have, so I haven’t felt the need to post. For example, I liked your comment on how to look at the vulnerability.

    I’ve been contributing to a thread on the bug tracker. Hopefully the discussion will remain on how to best fix the problem, rather than debating over whether to call it a vulnerability or “unwanted behavior”.

Leave a Reply

Your email address will not be published. Required fields are marked *