User: Password:
|
|
Subscribe / Log in / New account

Cryptographic splicing makes for a Wordpress vulnerability

Cryptographic splicing makes for a Wordpress vulnerability

Posted May 8, 2008 8:56 UTC (Thu) by eru (subscriber, #2753)
Parent article: Cryptographic splicing makes for a Wordpress vulnerability

This means that the hash for username "foobar" with expiration "20080507" is the same as the hash for username "foo" with expiration "bar20080507".

Doesn't the "secret" that was concatenated at the end affect anything here? I suspect the explanation of the vulnerability misses some detail.


(Log in to post comments)

Presumably secret is constant per-server

Posted May 8, 2008 9:39 UTC (Thu) by tialaramex (subscriber, #21167) [Link]

The secret is presumably constant, per server. So you need to get the server to work out a
hash for you, with the same content as the one it would issue to a real administrator.
Fortunately their idiotic design† makes exactly this possible.

† I'd love to be charitable, but the thing about cryptography is that you can't be trusted to
DIY. If you're not using a system designed by someone who knew what they were doing and then
reviewed by others with an interest in revealing any defects, then you might as well go back
to storing plaintext passwords or using the honour system. Really.

Cryptographic splicing makes for a Wordpress vulnerability

Posted May 9, 2008 16:47 UTC (Fri) by giraffedata (subscriber, #1954) [Link]

The explanation misses a lot of details.

I'm wondering how the hacker makes the expiration string "bar20080507". Does the client choose the expiration string? That seems like something the server would do.

Also, the article doesn't really explain what an authentication cookie is, but I presume it's something the server sends to a client that has provided a valid password so that knowing that cookie in the future can stand for knowing the password. And for some reason that's better than just having the password as a cookie.

Cryptographic splicing makes for a Wordpress vulnerability

Posted May 16, 2008 12:15 UTC (Fri) by robbe (subscriber, #16131) [Link]

> The explanation misses a lot of details.

Here's my understanding (only from the article, YMMV):

0. Assume that there is an "admin" account with special power, and that 
the attacker has created an "admin99" account.
1. The attacker successfully logs in via a form, and the server sends her 
the cookie "admin99|20080601|DEADBEEF". (Assume that md5
("admin9920080601secret") == "DEADBEEF".)
2. On subsequent requests the attacker presents the above cookie. The 
server notices that the cookie is valid (because md5
("admin9920080601secret") == "DEADBEEF"), that this is user "admin99", 
and that the session has not yet expired (it's still May 2008). Fine!
3. But now the attacker sends the following doctored cookie: "admin|
9920080601|DEADBEEF". This still checks out as valid because md5
("admin9920080601secret") == "DEADBEEF"), the session is for some 
reason[1] still not considered expired, so the attacker now has the 
identity of user "admin".

[1] IMO not validating the expiration date format is one of the main 
errors here. Or does WP strive to be Y10K compliant??

Cryptographic splicing makes for a Wordpress vulnerability

Posted May 16, 2008 13:37 UTC (Fri) by jake (editor, #205) [Link]

> IMO not validating the expiration date format is one of the main 
> errors here. Or does WP strive to be Y10K compliant??

In the article, I was trying to steer clear of providing complete, exploitable details while
still giving more details than the advisory.  I believe the expiration is actually the number
of seconds since the epoch, which may be easier to exploit and still validate as a reasonable
expiration.

jake


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds