[Full-disclosure] Wordpress 2.5 Cookie Integrity Protection Vulnerability
Wordpress 2.5 Cookie Integrity Protection Vulnerability Original release date: 2008-04-25 Last revised: 2008-04-25 Latest version: http://www.cl.cam.ac.uk/users/sjm217/advisories/wordpress-cookie-integrity.txt CVE ID: CVE-2008-1930 Source: Steven J. Murdoch <http://www.cl.cam.ac.uk/users/sjm217/> Systems Affected: Wordpress 2.5 Overview: An attacker, who is able to register a specially crafted username on a Wordpress 2.5 installation, is able to generate authentication cookies for other chosen accounts. This vulnerability exists because it is possible to modify authentication cookies without invalidating the cryptographic integrity protection. If a Wordpress blog is configured to freely permit account creation, a remote attacker can gain Wordpress-administrator access and then elevate this to arbitrary code execution as the web server user. The vulnerability is fixed in Wordpress 2.5.1 I. Description Since version 2.5, Wordpress authenticates logged-in users through a cryptographically protected cookie, based on papers by Fu et al [1] and Liu et al [2]. This measure was introduced partly in response to vulnerability CVE-2007-6013 [3,4]. The new cookies are of the form: "wordpress_".COOKIEHASH = USERNAME . "|" . EXPIRY_TIME . "|" . MAC Where: COOKIEHASH: MD5 hash of the site URL (to maintain cookie uniqueness) USERNAME:The username for the authenticated user EXPIRY_TIME: When cookie should expire, in seconds since start of epoch MAC: HMAC-MD5(USERNAME . EXPIRY_TIME) under a key derived from a secret and USERNAME . EXPIRY_TIME. The flaw in this scheme is that USERNAME and EXPIRY_TIME are not delimited in the MAC calculation. Hence the cookie may be modified, without altering MAC, provided that the concatenation of USERNAME and EXPIRY_TIME remains unchanged. This class of vulnerability, the cryptographic splicing attack, was commented on by Fu et al [1], but Wordpress does not employ their recommended defence. An attacker wishing to exploit this vulnerability would therefore create an unprivileged account with its username starting with "admin". The cookie returned on logging into this account can then be manipulated so as to be valid for the administrator account. II. Impact A remote attacker, who can create an account with specially crafted username, is able to gain administrator level access to the Wordpress installation. Through standard techniques, this can be escalated to arbitrary PHP code execution as the web server system user. III. Solution Upgrade to Wordpress 2.5.1 Workarounds: - De-select "Anyone can register" in the Membership section of General Settings to disable account creation. References: [1] Dos and Don'ts of Client Authentication on the Web, Kevin Fu, Emil Sit, Kendra Smith, Nick Feamster http://pdos.csail.mit.edu/papers/webauth:tr.pdf [2] A Secure Cookie Protocol, Alex X. Liu, Jason M. Kovacs, Chin-Tser Huang, Mohamed G. Gouda http://www.cse.msu.edu/~alexliu/publications/Cookie/cookie.pdf [3] Wordpress Cookie Authentication Vulnerability: CVE-2007-6013 Steven J. Murdoch, http://www.cl.cam.ac.uk/users/sjm217/advisories/wordpress-cookie-auth.txt [4] http://trac.wordpress.org/ticket/5367 Timeline: 2008-04-22: [EMAIL PROTECTED] notified Confirmation of receipt received 2008-04-25: Wordpress 2.5.1 released incorporating patch Vulnerability notice published -- w: http://www.cl.cam.ac.uk/users/sjm217/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Wordpress Cookie Authentication Vulnerability
On Tue, Nov 20, 2007 at 07:08:36PM +0100, Stefan Esser wrote: > Could you elaborate why you consider this news? Most public SQL > injection exploits for Wordpress use this cookie trick. I couldn't find it on the Wordpress bug tracker and when I mentioned it to the Wordpress security address, they did not mention having heard of it before. I also couldn't find a detailed explanation of the problem online, nor in the usual vulnerability databases. Blog administrators, like me, therefore risk sites being compromised because they didn't realize the problem. It seemed intuitive to me that restoring the database to a known good state would be adequate to recover from a Wordpress compromise (excluding guessable passwords). This is the case with the UNIX password database and any similarly implemented system. Because of the vulnerability I mentioned, this is not the case for Wordpress. So I also thought it important to describe the workarounds, and fixes. If these were obvious, Wordpress would have already applied them. Some commenters did not think that the current password scheme needs to be, or can be improved, despite techniques to do so being industry standard for decades. Clearly this misconception needs to be corrected. I did mention that this was being exploited, so obviously some people already know about the problem, but not the right ones. Before I sent the disclosure, there was no effort being put into fixing the problem. Now there is. Hopefully blog administrators will also apply the work-arounds in the meantime. Steven. -- w: http://www.cl.cam.ac.uk/users/sjm217/ pgplepDMUt5nV.pgp Description: PGP signature ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Wordpress Cookie Authentication Vulnerability
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: Source: Steven J. Murdoch <http://www.cl.cam.ac.uk/users/sjm217/> Systems Affected: Wordpress 1.5 -- 2.3.1 (including current version, as of 2007-11-19) Overview: 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. I. 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 | 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_=admin wordpresspass_=MD5(user_pass) 4) You have admin access to the blog II. 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. III. 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
