LWN: Comments on "Wordpress Cookie Authentication Vulnerability"

Wordpress Cookie Authentication Vulnerability

judas_iscariote — Wed, 21 Nov 2007 21:21:54 +0000

not only the authentication system design is horrible...wordpress is a great example of a cool
blog user interface but an horrible, messy, insecure code.

Wordpress Cookie Authentication Vulnerability

jengelh — Tue, 20 Nov 2007 19:12:40 +0000

The main purpose of rainbow tables is to combat unsalted web apps ;-)

Wordpress Cookie Authentication Vulnerability

Los__D — Tue, 20 Nov 2007 18:21:30 +0000

The main purpose of salts is to combat things like rainbow tables.

Wordpress Cookie Authentication Vulnerability

Max.Hyre — Tue, 20 Nov 2007 18:03:37 +0000

Wouldn't that be safer if every user must define config['salt'] in their config file?

No. Anything the user adds to the authentication process weakens it: witness passwords. If you want to use salt, generate it yourself; otherwise you'd get config['mh'] all over the place. (Where ``mh'' is the user's initials.)

Wordpress Cookie Authentication Vulnerability

zlynx — Tue, 20 Nov 2007 16:28:34 +0000

What they need to do is either use SSL client certificates, which would be a great idea since
they do exactly what is desired: authenticate the client, or:

Use Javascript.  Have the server provide a random value, then in Javascript MD5 or otherwise
hash the password or password MD5 + random value and return the result to the server.

In either case, the secret is never sent over the network.

Wordpress Cookie Authentication Vulnerability

drag — Tue, 20 Nov 2007 16:10:05 +0000

Ya..

Google around for 'Rainbow tables'. There are ones you can download for free and ones you can
pay for. 

Just going out to pirate bay and doing a quick search I found downloads for MD5, SHA1, and NT
Lan manager tables.

Wordpress Cookie Authentication Vulnerability

Los__D — Tue, 20 Nov 2007 14:49:50 +0000

This was in response to making the salt a configured value.

Of course, when nobody really needs to care about testing the sums, they could have stored the
passwords bit flipped, and have Wordpress no more unsafe than it is now...

Wordpress Cookie Authentication Vulnerability

drag — Tue, 20 Nov 2007 13:40:42 +0000

Because anybody can use the md5sum of the md5sum of the password to gain access to any account
there isn't any point to cracking the password. Effectively Wordpress found a way to defete
the whole point of using hashes to secure passwords. They could of used all the salt in the
world and it wouldn't of mattered.

Maybe using 'md5sum[ salt + md5sum[ password ]]' to make the token would of made a difference.
But then it would matter exactly how the cookie-based auth token is generated. For instance if
the salt was stored in the same database as the password hashes it wouldn't do much good.. if
the salt was time based it wouldn't do much good. 


This sort of thing is a very difficult problem and is why most of the time it's better to use
some method that has been developed by security researchers and has been audited by third
parties rather then try to make up your own auth systems.

Wordpress Cookie Authentication Vulnerability

Los__D — Tue, 20 Nov 2007 11:41:58 +0000

Ehm, that would be the password hash

Wordpress Cookie Authentication Vulnerability

Los__D — Tue, 20 Nov 2007 11:41:34 +0000

AFAIK, normally you generate a random salt, and store that salt with the password.

Salts are only there to avoid dictionary attacks.

Wordpress Cookie Authentication Vulnerability

Velmont — Tue, 20 Nov 2007 09:45:56 +0000

Hmm. In my own CMS (before I went over to use WordPress), I salted the extra md5 in the cookie, like this:

cookie_pass = md5( md5(password) + config['salt'] + userid )

Wouldn't that be safer if every user must define config['salt'] in their config file?

Wordpress Cookie Authentication Vulnerability

Ross — Tue, 20 Nov 2007 09:15:55 +0000

It's true that any encrypted password can be attacked offline if you have the hash, but if the
passwords were properly salted, it would be much more expensive to crack them because an
attacker couldn't build a pre-encrypted dictionary.

Wordpress Cookie Authentication Vulnerability

lutchann — Tue, 20 Nov 2007 06:41:31 +0000

That's true of pretty much any authentication system, except those based on asymmetric
cryptography.  Wordpress is far from unusual in storing password equivalents on disk.  So
unless Wordpress somehow encouraged making the user table accessible to attackers, I still
don't see why this is a big deal.

Wordpress Cookie Authentication Vulnerability

Ross — Tue, 20 Nov 2007 06:09:26 +0000

For one thing, this type of problem would allow access to continue long after the broken code
is fixed, without the user knowing about it.  Also, because of the way the password is stored,
it would easy allow offline cracking of passwords, and users tend to reuse the same password
on different sites.

Wordpress Cookie Authentication Vulnerability

drag — Tue, 20 Nov 2007 03:53:18 +0000

I donno. Good point.

I just figured being able to display a table requires less rights then being able to modify it
and since it's needed by the authentication stuff then it would be accessable to parts of the
website accessable by anonymous people.

Wordpress Cookie Authentication Vulnerability

lutchann — Tue, 20 Nov 2007 03:39:37 +0000

And by "new user" I mean "new administrator".  In other words, how does having administrator
access to the web site give you more power than the SQL injection vulnerability itself?

Wordpress Cookie Authentication Vulnerability

lutchann — Tue, 20 Nov 2007 03:37:29 +0000

I'm not very familiar with SQL/PHP security issues, but if you discovered an SQL injection
vulnerability in Wordpress, couldn't you just use it to add a new user to the authentication
table?

Apache security

ccyoung — Tue, 20 Nov 2007 03:08:06 +0000

if you do not trust app security, then apache security is a savior.

nonetheless apache security is not cheap, requiring extra transmission bytes, extra
processing, and (frequently many) extra db reads per page access.

Wordpress Cookie Authentication Vulnerability

drag — Tue, 20 Nov 2007 00:25:12 +0000

Well if you use a code injection vunerability you can display tables and such without actually
having login access to the database. Finding a input feild (say URL or text input box) without
correct input validation can provide this level of access.

Since Wordpress then, effectively thru cookies, uses MD5 hashes of passwords as passwords then
it's stupid simple to gain access to any account. 


To look at it this way...

A similar example would be on old Unix boxes without shadow passwords. Say you get access to a
FTP accound all you have to do is then download the /etc/passwd file. This is very easy to do
since everything uses that file for doing such mundane things as mapping a username to uid.
Any network service, any user program, any user account can allow access to /etc/passwd. You
don't need to be root to do that.

It appears to me that password table in the sql database is pretty much equivelent to
/etc/passwd.

Well in those old Unix/Linux systems the passwords would be encrypted in some manner. The
attacker would then have to run a brute force program to find passwords that match the hashes.

However.. Wordpress is so badly designed that the attacker does not have to even do that. Once
they obtain the hash of the password they can actually use the hash _as_the_password_. It's
very bad.

So this vunerability is a combination of a attacker finding bad input validation and badly
designed Single-Sign-On authentication systems based on browser cookies.

Wordpress Cookie Authentication Vulnerability

lutchann — Tue, 20 Nov 2007 00:10:30 +0000

I don't get it.  If an attacker already has access to your SQL database, what more does it get
them to have administrator permissions in the web interface?

Wordpress Cookie Authentication Vulnerability

tobor — Mon, 19 Nov 2007 23:03:14 +0000

Don't blame the language for this worse-than-failure design decision.

Wordpress Cookie Authentication Vulnerability

jwb — Mon, 19 Nov 2007 21:29:54 +0000

Oh boy!  As a system administrator there's nothing I like better than yet another mediocre PHP
hack with its own half-baked authentication and authorization system.  I have a version of
wordpress kicking around here somewhere but a few months back I ripped out the auth/authz code
and made it respect the authenticated user coming from Apache, which is IMHO the only sane way
to do things.