lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <b7a807650711211342p4d599659r6a387b8e200e7be7@mail.gmail.com>
Date: Wed, 21 Nov 2007 21:42:59 +0000
From: "Adrian P" <unknown.pentester@...il.com>
To: steven@...urityzone.org
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: Wordpress Cookie Authentication Vulnerability

comment inline ;)

On Nov 20, 2007 8: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.

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" <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/
>



-- 
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ