Wordpress <= 2.3.1 Cookie Authentication Vulnerability
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
wordpress (Ubuntu) |
Confirmed
|
Undecided
|
Emanuele Gentili |
Bug Description
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.
Description
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 | 4cee2c84f6de6d8
...
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:
wordpressuser
wordpresspass
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
wordpressuserp
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:
wordpress
wordpress
4) You have admin access to the blog
Impact
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.
Changed in wordpress: | |
assignee: | nobody → emgent |
status: | New → Confirmed |
Changed in wordpress: | |
status: | Confirmed → Fix Released |
Changed in wordpress: | |
status: | Fix Released → Confirmed |
.Solution
No vendor patch is available.
No timeline for a vendor patch has been announced.
Workarounds:
- Protect the Wordpress database, and do not allow backups to be
released.
- Keep your Wordpress installation up to date. This should reduce the
risk that your database will be compromised.
- Do not share passwords across different sites.
- If you suspect a database to be compromised, change all passwords
to different ones. It is not adequate to change the passwords to
the same ones, since Wordpress does not "salt" [1] the password
database.
- Remove write permissions on the Wordpress files for the system
account that the webserver runs as. This will disable the theme
editor, but make it more difficult to escalate Wordpress
administrator access into the capability to execute arbitrary code
- Configure the webserver to not execute files in any directory
writable by the webserver system account (e.g. the upload
directory).
Potential fixes:
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:
- Passwords are unsalted [2], leaving them open to brute force, rainbow
table and other attacks [3].
- It is impossible to revoke a cookie without changing the user's
password.
- Cookies do not contain an expiry time, so are always valid (until
the user's password changes)
- There ought to be an option to limit cookies to a particular
IP address or range.
References:
[1] http:// en.wikipedia. org/wiki/ Salt_(cryptogra phy) trac.wordpress. org/ticket/ 2394 www.lightblueto uchpaper. org/2007/ 11/16/google- as-a-password- cracker/
[2] http://
[3] http://