Wordpress Cookie Authentication Vulnerability
Original release date: 2007-11-19 Last revised: 2007-11-19 Latest version: http://www.cl.cam.ac.uk/users/sjm217/advisories/wordpress-cookie-auth.txt CVE ID: <pending> Source: Steven J. Murdoch <http://www.cl.cam.ac.uk/users/sjm217/>
Wordpress 1.5 -- 2.3.1 (including current version, as of 2007-11-19)
With read-only access to the Wordpress database, it is possible to generate a valid login cookie for any account, without resorting to a brute force attack. This allows a limited SQL injection vulnerability to be escalated into administrator access.
This vulnerability is known to be actively exploited, hence the expedited public release.
For authentication, the Wordpress user database stores the MD5 hash of login passwords. A client is permitted access if they can present a password whose hash matches the stored one.
$ mysql -u wordpress -p wordpress Enter password: **
mysql> SELECT ID, user_login, user_pass FROM wp_users; +----+-------------+----------------------------------+ | ID | user_login | user_pass | +----+-------------+----------------------------------+ | 1 | admin | 4cee2c84f6de6d89a4db4f2894d14e38 | ...
Of course, entering your password after each action that requires authorization would be exceptionally tedious. So, after logging in, Wordpress presents the client with two cookies:
The cookie names contains the MD5 hash (6092...1a5f) of the blog URL. The value of wordpressuser_... is the login name, and the value of wordpresspass is the double-MD5 hash of the user password.
Wordpress will permit access to a given user account if the wordpressuserpass_... cookie matches the hash of the specified user's wp_users.user_pass database entry.
In other words, the database contains MD5(password) and the cookie contains MD5(MD5(password)). It is thus trivial to convert a database entry into an authentication cookie.
At this point the vulnerability should be clear. If an attacker can gain read access to the wp_user table, for example due to a publicly visible backup or SQL injection vulnerability, a valid cookie can be generated for any account.
This applies even if the user's password is sufficiently complex to resist brute force and rainbow table attacks. While it should be computationally infeasible to go backwards from MD5(password) to password, the attacker needs only to go forwards.
The exploitation steps are therefore: 1) Find the hash of the blog URL: Either just look at the URL, or create an account to get a user cookie 2) Read the user_pass entry from wp_users table: Look for backups, perform SQL injection, etc... 3) Set the following cookies: wordpressuser_<MD5(url)>=admin wordpresspass_<MD5(url)>=MD5(user_pass) 4) You have admin access to the blog
A remote attacker, with read access to the password database can gain administrator rights. This may be used in conjunction with an SQL injection attack, or after locating a database backup.
An attacker who has alternatively compromised the database of one Wordpress blog can also gain access to any other whose users have the same password on both.
No vendor patch is available. No timeline for a vendor patch has been announced.
The problem occurs because it is easy to go from the password hash in the database to a cookie (i.e the application of MD5 is the wrong way around). The simplest fix is to store MD5(MD5(password)) in the database, and make the cookie MD5(password). This still makes it infeasible to retrieve the password from a cookie, but means that it is also infeasible to generate a valid cookie from the database entry.
However, there are other vulnerabilities in the Wordpress cookie and password handling, which should be resolved too:
 http://en.wikipedia.org/wiki/Salt_(cryptography)  http://trac.wordpress.org/ticket/2394  http://www.lightbluetouchpaper.org/2007/11/16/google-as-a-password-cracker/
2007-10-29: firstname.lastname@example.org notified; no response 2007-11-02: email@example.com notified; Confirmation of active exploitation requested by Wordpress 2007-11-02: Confirmation sent; no response 2007-11-19: Advisory released to full-disclosure and BugTraq
-- w: http://www.cl.cam.ac.uk/users/sjm217/