Re: [Full-disclosure] Wordpress Cookie Authentication Vulnerability
This issue is SA27714 (severity 1/5) http://secunia.com/advisories/27714/ and FrSIRT/ADV-2007-3941 (severity 1/4) http://www.frsirt.com/english/advisories/2007/3941 too. Secunia advisory lists these workarounds: Grant only trusted users read access to the users table. Restrict access to the wp-admin directory (e.g. with .htaccess). - Juha-Matti Right this problem has existed for a long time, but it's not the end of the world for someone to point it out again I suppose. I think it's obvious that there's another main issue here and that's the way WordPress handles its cookies in general. They are not temporary sessions that expire or are only valid upon successful authentication. The cookies work for ever.. or at least until the password changes. If someone uses an XSS attack to obtain the cookies or sniffs them (most blogs are just HTTP) they can essentially permanently authenticate. The same result occurs with being able to read the database. Furthermore, one could in theory conduct a bruteforce attack against the WordPress password by just making normal requests to the blog but changing the cookies that does the double MD5 of the password. You could in theory emulate normal continued browsing of the website while sending MD5(MD5(password)) over and over with each request via the cookie. Other than perhaps a large increase in browsing of the blog, this could possibly go unnoticed as an attack -- as it would not be logged anywhere (in most instances) that the cookies were being presented. Once authenticated into WordPress, the normal blog pages look different, so it would not require an attacker to access the Admin area to verify. Anyway, good to see the CVE is already there. Maybe better session management will find its way into WordPress. Steven http://www.securityzone.org (..runs on WordPress.. oh noes!) This is CVE-2007-6013 since 19th Nov including WordPress ticket #5367: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6013 - Juha-Matti --clip-- ___ 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
comment inline ;) On Nov 20, 2007 8:23 PM, Steven Adair [EMAIL PROTECTED] wrote: Right this problem has existed for a long time, but it's not the end of the world for someone to point it out again I suppose. I think it's obvious that there's another main issue here and that's the way WordPress handles its cookies in general. They are not temporary sessions that expire or are only valid upon successful authentication. The cookies work for ever.. or at least until the password changes. If someone uses an XSS attack to obtain the cookies or sniffs them (most blogs are just HTTP) they can essentially permanently authenticate. The same result occurs with being able to read the database. Furthermore, one could in theory conduct a bruteforce attack against the WordPress password by just making normal requests to the blog but changing the cookies that does the double MD5 of the password. You could in theory emulate normal continued browsing of the website while sending MD5(MD5(password)) over and over with each request via the cookie. Other than perhaps a large increase in browsing of the blog, this could possibly go unnoticed as an attack -- as it would not be logged anywhere (in most instances) that the cookies were being presented. Once authenticated into WordPress, the normal blog pages look different, so it would not require an attacker to access the Admin area to verify. That's actually an interesting way to BF the passwords. Much more stealth than doing it via the login page. I like it! Anyway, good to see the CVE is already there. Maybe better session management will find its way into WordPress. Steven http://www.securityzone.org (..runs on WordPress.. oh noes!) This is CVE-2007-6013 since 19th Nov including WordPress ticket #5367: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6013 - Juha-Matti Steven J. Murdoch [EMAIL PROTECTED] kirjoitti: 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/ ___ 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 - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ -- pagvac gnucitizen.org, ikwt.com ___ 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
A remote attacker, with read access to the password database can gain administrator rights. This also applies to many other blog software and also every system with a password database. -- Francesco Vaj [CISSP - GIAC] Senior Content Manipulation Consultant mailto:[EMAIL PROTECTED] aim: XSS Cross Site XSS Worm: Cross Site Scripting Attacks Wordpress Blog Password Hash Replay Information Portal (tm) 2007 http://www.XSSworm.com/ -- Vaj, bella vaj. ___ 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 Wed, Nov 21, 2007 at 03:48:06AM +1100, XSS Worm XSS Security Information Portal wrote: This also applies to many other blog software In which case they are not storing their passwords properly. What makes the Wordpress scheme vulnerable is that you can attack it *without* brute forcing the password. Also, because there is no salt, brute forcing is much easier than it need be. and also every system with a password database. No, it does not apply to systems which use one way hashing correctly, for example the UNIX password database. This technique has been known for around 30 years. The reasoning and history behind these schemes can be found in a paper by Morris and Thompson, published in 1978: http://cm.bell-labs.com/cm/cs/who/dmr/passwd.ps Steven. -- w: http://www.cl.cam.ac.uk/users/sjm217/ pgpNyuAobMH2y.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/
Re: [Full-disclosure] Wordpress Cookie Authentication Vulnerability
Steven J. Murdoch schrieb: Wordpress Cookie Authentication Vulnerability Original release date: 2007-11-19 ... Source: Steven J. Murdoch http://www.cl.cam.ac.uk/users/sjm217/ Could you elaborate why you consider this news? Most public SQL injection exploits for Wordpress use this cookie trick. A simple search on milw0rm will reveal that even a Gulftech Wordpress SQL injection exploits from 2005 uses this method to login as admin once it has discovered the hash. Yours, Stefan Esser ___ 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/
Re: [Full-disclosure] Wordpress Cookie Authentication Vulnerability
This is CVE-2007-6013 since 19th Nov including WordPress ticket #5367: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6013 - Juha-Matti Steven J. Murdoch [EMAIL PROTECTED] kirjoitti: 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/ ___ 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
Right this problem has existed for a long time, but it's not the end of the world for someone to point it out again I suppose. I think it's obvious that there's another main issue here and that's the way WordPress handles its cookies in general. They are not temporary sessions that expire or are only valid upon successful authentication. The cookies work for ever.. or at least until the password changes. If someone uses an XSS attack to obtain the cookies or sniffs them (most blogs are just HTTP) they can essentially permanently authenticate. The same result occurs with being able to read the database. Furthermore, one could in theory conduct a bruteforce attack against the WordPress password by just making normal requests to the blog but changing the cookies that does the double MD5 of the password. You could in theory emulate normal continued browsing of the website while sending MD5(MD5(password)) over and over with each request via the cookie. Other than perhaps a large increase in browsing of the blog, this could possibly go unnoticed as an attack -- as it would not be logged anywhere (in most instances) that the cookies were being presented. Once authenticated into WordPress, the normal blog pages look different, so it would not require an attacker to access the Admin area to verify. Anyway, good to see the CVE is already there. Maybe better session management will find its way into WordPress. Steven http://www.securityzone.org (..runs on WordPress.. oh noes!) This is CVE-2007-6013 since 19th Nov including WordPress ticket #5367: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6013 - Juha-Matti Steven J. Murdoch [EMAIL PROTECTED] kirjoitti: 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/ ___ 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 - 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
Wordpress never knew how to deal with cookies! On Nov 20, 2007 9:23 PM, Steven Adair [EMAIL PROTECTED] wrote: Right this problem has existed for a long time, but it's not the end of the world for someone to point it out again I suppose. I think it's obvious that there's another main issue here and that's the way WordPress handles its cookies in general. They are not temporary sessions that expire or are only valid upon successful authentication. The cookies work for ever.. or at least until the password changes. If someone uses an XSS attack to obtain the cookies or sniffs them (most blogs are just HTTP) they can essentially permanently authenticate. The same result occurs with being able to read the database. Furthermore, one could in theory conduct a bruteforce attack against the WordPress password by just making normal requests to the blog but changing the cookies that does the double MD5 of the password. You could in theory emulate normal continued browsing of the website while sending MD5(MD5(password)) over and over with each request via the cookie. Other than perhaps a large increase in browsing of the blog, this could possibly go unnoticed as an attack -- as it would not be logged anywhere (in most instances) that the cookies were being presented. Once authenticated into WordPress, the normal blog pages look different, so it would not require an attacker to access the Admin area to verify. Anyway, good to see the CVE is already there. Maybe better session management will find its way into WordPress. Steven http://www.securityzone.org (..runs on WordPress.. oh noes!) This is CVE-2007-6013 since 19th Nov including WordPress ticket #5367: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6013 - Juha-Matti Steven J. Murdoch [EMAIL PROTECTED] kirjoitti: 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/ ___ 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 - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ -- http://search.goldwatches.com/ http://www.jewelerslounge.com ___ 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
Hello folks, I wonder why we don't see web applications use secure cookie recipes like [1] and [2]. There are also existing secure password hashing frameworks such as Solar's [3]. Are developers just unaware of these secure schemes?. Amusingly a proprietary web application I audited used static tokens. Even if you change your password cookies are still valid. Even passwords are stored as raw MD5 hashes on the database. I think programmers should be taught secure practices from the start. [1] http://cookies.lcs.mit.edu/pubs/webauth:tr.pdf [2] http://www.cse.msu.edu/~alexliu/publications/Cookie/cookie.pdf [3] http://www.openwall.com/phpass/ Eduardo Tongson NCCS On 11/21/07, James Matthews [EMAIL PROTECTED] wrote: Wordpress never knew how to deal with cookies! On Nov 20, 2007 9:23 PM, Steven Adair [EMAIL PROTECTED] wrote: Right this problem has existed for a long time, but it's not the end of the world for someone to point it out again I suppose. I think it's obvious that there's another main issue here and that's the way WordPress handles its cookies in general. They are not temporary sessions that expire or are only valid upon successful authentication. The cookies work for ever.. or at least until the password changes. If someone uses an XSS attack to obtain the cookies or sniffs them (most blogs are just HTTP) they can essentially permanently authenticate. The same result occurs with being able to read the database. Furthermore, one could in theory conduct a bruteforce attack against the WordPress password by just making normal requests to the blog but changing the cookies that does the double MD5 of the password. You could in theory emulate normal continued browsing of the website while sending MD5(MD5(password)) over and over with each request via the cookie. Other than perhaps a large increase in browsing of the blog, this could possibly go unnoticed as an attack -- as it would not be logged anywhere (in most instances) that the cookies were being presented. Once authenticated into WordPress, the normal blog pages look different, so it would not require an attacker to access the Admin area to verify. Anyway, good to see the CVE is already there. Maybe better session management will find its way into WordPress. Steven http://www.securityzone.org (..runs on WordPress.. oh noes!) This is CVE-2007-6013 since 19th Nov including WordPress ticket #5367: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6013 - Juha-Matti Steven J. Murdoch [EMAIL PROTECTED] kirjoitti: 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/ ___ 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 - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ -- http://search.goldwatches.com/ http://www.jewelerslounge.com ___ 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 Wed, 21 Nov 2007 07:51:30 +0800, Eduardo Tongson said: I wonder why we don't see web applications use secure cookie recipes like [1] and [2]. There are also existing secure password hashing frameworks such as Solar's [3]. Are developers just unaware of these secure schemes?. Browse the worsethanfailure.com website for a while, and you'll convince yourself that the average developer thinks that booleans are trinary-state. ;) pgpuHeG4aHsug.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/
Re: [Full-disclosure] Wordpress Cookie Authentication Vulnerability
--On November 20, 2007 7:21:29 PM -0500 [EMAIL PROTECTED] wrote: On Wed, 21 Nov 2007 07:51:30 +0800, Eduardo Tongson said: I wonder why we don't see web applications use secure cookie recipes like [1] and [2]. There are also existing secure password hashing frameworks such as Solar's [3]. Are developers just unaware of these secure schemes?. Browse the worsethanfailure.com website for a while, and you'll convince yourself that the average developer thinks that booleans are trinary-state. ;) They're not???)(*)(*@)(*(*#)(*$ :-D Paul Schmehl ([EMAIL PROTECTED]) Senior Information Security Analyst The University of Texas at Dallas http://www.utdallas.edu/ir/security/ ___ 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: pending 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_MD5(url)=admin wordpresspass_MD5(url)=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: -
