Date: Wed, 21 Nov 2007 07:51:30 +0800
From: "Eduardo Tongson" <propolice@...il.com>
To: full-disclosure@...ts.grok.org.uk
Subject: Re: 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 <nytrokiss@...il.com> wrote:
> Wordpress never knew how to deal with cookies!
>
>
> On Nov 20, 2007 9:23 PM, Steven Adair <steven@...urityzone.org> 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"
> <fulldisc+Steven.Murdoch@...cam.ac.uk> 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/
>

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists