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/
