Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security FullDisclosure
[Top] [All Lists]

Re: [Full-disclosure] Wordpress Cookie Authentication Vulnerability

Subject: Re: [Full-disclosure] Wordpress Cookie Authentication Vulnerability
Date: Wed, 21 Nov 2007 21:42:59 +0000
comment inline ;)

On Nov 20, 2007 8:23 PM, Steven Adair <steven@securityzone.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@cl.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/

<Prev in Thread] Current Thread [Next in Thread>