Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Exploits-HackingTools
[Top] [All Lists]

[UNIX] Wordpress Cookie Authentication Vulnerability

Subject: [UNIX] Wordpress Cookie Authentication Vulnerability
Date: 26 Nov 2007 13:21:07 +0200
The following security advisory is sent to the securiteam mailing list, and can 
be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion

The SecuriTeam alerts list - Free, Accurate, Independent.

Get your security news from a reliable source.
http://www.securiteam.com/mailinglist.html 

- - - - - - - - -



  Wordpress Cookie Authentication Vulnerability
------------------------------------------------------------------------


SUMMARY

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.

DETAILS

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:
  wordpressuser_6092254072ca971c70b3ff302411aa5f=admin
  
wordpresspass_6092254072ca971c70b3ff302411aa5f=813cadd8658c4776afbe5de8f304a684

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

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.

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_(cryptography)> 
http://en.wikipedia.org/wiki/Salt_(cryptography)
[2]  <http://trac.wordpress.org/ticket/2394> 
http://trac.wordpress.org/ticket/2394
[3]  
<http://www.lightbluetouchpaper.org/2007/11/16/google-as-a-password-cracker/> 
http://www.lightbluetouchpaper.org/2007/11/16/google-as-a-password-cracker/

Timeline:
2007-10-29: security@wordpress.org notified; no response
2007-11-02: security@wordpress.org 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


ADDITIONAL INFORMATION

The information has been provided by  
<mailto:bugtraq+Steven.Murdoch@cl.cam.ac.uk> Steven J. Murdoch.
The original article can be found at:  
<http://www.cl.cam.ac.uk/users/sjm217/advisories/wordpress-cookie-auth.txt> 
http://www.cl.cam.ac.uk/users/sjm217/advisories/wordpress-cookie-auth.txt



======================================== 


This bulletin is sent to members of the SecuriTeam mailing list. 
To unsubscribe from the list, send mail with an empty subject line and body to: 
list-unsubscribe@securiteam.com 
In order to subscribe to the mailing list, simply forward this email to: 
list-subscribe@securiteam.com 


==================== 
==================== 

DISCLAIMER: 
The information in this bulletin is provided "AS IS" without warranty of any 
kind. 
In no event shall we be liable for any damages whatsoever including direct, 
indirect, incidental, consequential, loss of business profits or special 
damages. 




<Prev in Thread] Current Thread [Next in Thread>
  • [UNIX] Wordpress Cookie Authentication Vulnerability, SecuriTeam <=