Weekly Edition
Return to the Security page
| |||||||||||||
Cryptographic splicing makes for a Wordpress vulnerabilityAuthentication bypass vulnerabilities are particularly painful because they allow an attacker to access and potentially modify things that should be off-limits. It is important to ensure that when fixing that kind of bug, one does not introduce a different, but equally potent, hole. A recent Wordpress vulnerability clearly demonstrates the care that needs to be taken. The problem started in November 2007, when Steven Murdoch reported a problem with Wordpress authentication cookies. Essentially, the cookie that Wordpress used was an MD5 hash calculated using a value stored in the database's user table. Any attacker that could get read access to the database, via a SQL injection or looking inside a database backup for example, could generate a cookie value that would allow them access as that user. The password itself was not stored in the database as plaintext, but the value used in the cookie was just a simple MD5 of the stored value. So, the value stored was MD5(password) and the cookie value was MD5(MD5(password)). Murdoch released his advisory in advance of a fix, because the vulnerability was being actively exploited. It was entered as bug #5367 into the Wordpress bug tracking system and a long conversation about how to properly fix it ensued. As part of that discussion, Murdoch suggested that a paper entitled "Dos and Don'ts of Client Authentication on the Web" [PDF] be consulted. The paper covers various issues regarding cookies and the kinds of attacks that can be made against them. Some, but not all, of its recommendations were followed. The new cookie scheme was released at the end of March as part of the Wordpress 2.5 release. Authentication cookie values were now calculated using the following (with the '.' operator representing concatenation):
USERNAME . "|" . EXPIRATION . "|" . MD5(USERNAME . EXPIRATION . secret)
This took into account the hazards of a straightforward hash of a stored
value and added an expiration to the cookie, but it failed to protect
against a cryptographic splicing attack.
When calculating the hash of the concatenation of the username and expiration (along with a secret known by the server), no delimiter was used between the two. This means that the hash for username "foobar" with expiration "20080507" is the same as the hash for username "foo" with expiration "bar20080507". This allows anyone with a username that begins the same as another username, to generate a legitimate cookie for that other user. Using the example above, user "foobar" could create valid cookies for a user "foo" (or any other prefix substring). Many Wordpress weblogs allow new users to create an account with any name they choose, so long as it is not already taken. By choosing one that starts with the administrator's username, an attacker can generate a cookie for themselves, modify it slightly, and have a valid cookie to access the administrator account. No password cracking is required, nor is any access to the database needed. Wordpress 2.5.1 has been released to address this problem. Earlier versions could disable the registration feature and delete or suspend any user accounts with suspicious usernames as a workaround. Though if those suspicious accounts exist, it would not be surprising to find that the real administrator no longer knows the proper password for that account. The paper that Murdoch referenced clearly indicated the danger from cryptographic splicing, but the Wordpress implementers must have missed it. Cookie authentication schemes are a necessary evil for web applications—it would be nearly unusable to have to authenticate on each page—but they are difficult to get right. A careful reading of the paper will help, as will using already vetted libraries or frameworks. It is one of those things that is hard to get right and extremely important to do so. (Log in to post comments)
Cryptographic splicing makes for a Wordpress vulnerability Posted May 8, 2008 7:53 UTC (Thu) by ekj (guest, #1524) [Link] You don't have to authenthicate on every page without cookies. HTTP:Basic authenthication is implemented in such a way in browsers that they ask only once for username and password for a site, aslong as subsequent pages use the same Authenthication-realm, the same username and password is authomatically reused. Yes, technically this means your BROWSER authenthicates every request, but you the USER don't see this and aren't inconvenienced by it. You do need to reauthenthicate if you close and reopen your browser though, cookies can prevent that, if desired.
Cryptographic splicing makes for a Wordpress vulnerability Posted May 8, 2008 11:02 UTC (Thu) by epa (subscriber, #39769) [Link] One of the biggest favours the Firefox developers could do for the web would be to make basic http authentication more pretty and user-friendly, perhaps allowing a username/password widget to be embedded in a web page and styled with CSS, so that web site authors would use it instead of developing their own cookie-based monstrosities.
Cryptographic splicing makes for a Wordpress vulnerability Posted May 8, 2008 15:53 UTC (Thu) by felixfix (subscriber, #242) [Link] How would that help? Wouldn't it only work for browsers that implement that particular extension to HTML/CSS?
Cryptographic splicing makes for a Wordpress vulnerability Posted May 8, 2008 16:04 UTC (Thu) by TRS-80 (subscriber, #1804) [Link] REST based authentication is a in-depth study on how to make HTTP authentication more friendly, in part by using AJAX to log in via a normal HTML form and various apache config tricks. But really W3C should fix HTTP authentication so there's no need to use these sorts of egregious hacks - for example, you have to implement challenge-response yourself in JavaScript and phishing becomes a problem.
Cryptographic splicing makes for a Wordpress vulnerability Posted May 8, 2008 16:23 UTC (Thu) by bronson (subscriber, #4806) [Link] And add the ability to log out! What did the HTTP devs think, that nobody ever wanted to share a computer?
Cryptographic splicing makes for a Wordpress vulnerability Posted May 8, 2008 18:52 UTC (Thu) by martinfick (subscriber, #4455) [Link] That would probably be a browser implementation issue wouldn't it? File a bug against your browser if it does not allow this.
Cryptographic splicing makes for a Wordpress vulnerability Posted May 8, 2008 19:36 UTC (Thu) by bronson (subscriber, #4806) [Link] Can you name a browser implementation that does work? Many bugs have been filed, and there's endless discussion only a google search away, but there's been zero forward progress. Opened 2004: https://bugzilla.mozilla.org/show_bug.cgi?id=260186 Opened 2001: https://bugzilla.mozilla.org/show_bug.cgi?id=68409 Since it's broken, nobody uses it, and nobody's interested in fixing it, I suppose HTTP Auth should just be deprecated. Cookie-based auth is awful, but it does work and people do use it.
Cryptographic splicing makes for a Wordpress vulnerability Posted May 8, 2008 21:18 UTC (Thu) by martinfick (subscriber, #4455) [Link] Can you name a browser implementation that does work? Yes, konqueror. It stores this info in the kde wallet system, the wallet system will allow you to remove entries from it.
Cryptographic splicing makes for a Wordpress vulnerability Posted May 9, 2008 3:01 UTC (Fri) by bronson (subscriber, #4806) [Link] That just forgets your password, right? It doesn't actually allow you to log out.
Cryptographic splicing makes for a Wordpress vulnerability Posted May 9, 2008 4:19 UTC (Fri) by evanp (subscriber, #50543) [Link] Subsequent HTTP requests cause your browser to prompt you to login, so yes, you are indeed "logged out" in that sense. The server isn't notified, though, which might be what you were asking about.
Cryptographic splicing makes for a Wordpress vulnerability Posted May 8, 2008 21:35 UTC (Thu) by martinfick (subscriber, #4455) [Link] Also, with mozilla you can simply insert a new username@ after the ":" of your protocol like this "http://bogus@site.com" and it will then proceed to prompt you for a username & password. Now you can enter your original username and a bogus password which it will now remember. Yes, this is a hack, but it will do what you want. There may be a better method, but that is what I came up with quickly. I was surprised that it was not stored under the password tab in the options menus.
Cryptographic splicing makes for a Wordpress vulnerability Posted May 15, 2008 11:13 UTC (Thu) by endecotp (guest, #36428) [Link] > Can you name a browser implementation that does work? I believe that the old "Mozilla Suite" added an HTTP Auth logout button just-too-late for it to end up in firefox.
Cryptographic splicing makes for a Wordpress vulnerability Posted May 8, 2008 8:56 UTC (Thu) by eru (subscriber, #2753) [Link] 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.
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 (guest, #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
Cryptographic splicing makes for a Wordpress vulnerability Posted May 8, 2008 10:57 UTC (Thu) by ewan (subscriber, #5533) [Link] IMHO the best way of authenticating to a website is to use SSL with a client certificate; it's nicely secure and you never get asked for a password by a website, only by your own browser, and (usually) only after a restart. Clearly, it's not universally available, but where it is it's a very slick solution.
Cryptographic splicing makes for a Wordpress vulnerability Posted May 9, 2008 8:19 UTC (Fri) by jschrod (subscriber, #1646) [Link] It's a hassle if you have several identities against different web applications, i.e., multiple certificates. Automatic certificate selection doesn't work then, as no realm concept as in baseauth exists. You can read about a bunch of problems at http://wiki.mozilla.org/PSM:CertPrompt There is also the `logout' problem, just as in base auth; i.e., if you want to use different SSL certs against the same web app. This is especially neeeded during development, to simulate different users with differen roles. Currently, one needs several browser instances with different profiles for that (each of them eating up 100s of MBs.) In addition, manual cert selection is a drag, if you have a Web server that authenticates only part of its Web site. When you first access some other part of the Web server, the SSL connection is established. When you then link to the protected area, the SSL connection must be renogetiated, and that doesn't properly work in many older browsers. Oh yes, and moving a whole site to https might not be advisable either, for performance reasons. I don't even want to start about the problems to set up a revocation process properly. After all, you want to be able to re-issue a cert to a client when it got stolen or so. Since you will have the same X.509 fields, more or less, revocation lists is the only way to go. Have a lot of fun with them. IMNSHO, client certs are also not a good solution to the client authentication problem. Been there, done that, lots of problems. :-)
Cryptographic splicing makes for a Wordpress vulnerability Posted May 16, 2008 12:30 UTC (Fri) by robbe (guest, #16131) [Link] > Automatic certificate selection doesn't work then, as no realm concept as in baseauth exists. That's not true. If a server requests a client certificate, it has to send a list of "acceptable" CAs. The client is supposed to use a cert that is signed by one of those. If you plan your environment carefully automatic selection can work (except for IE which apparently is too dumb to heed the acceptable CA list and always shows all certificates to to the user). I agree with most of your other points. Setting up proper authentification via client certificates is a complicated mess.
This is a solved problem Posted May 8, 2008 13:00 UTC (Thu) by dskoll (subscriber, #1630) [Link] I don't understand why this has to be so complex. If you want to use cookies for authentication, you generate a strong random value and use it as the key into a session cache. The session cache can either be in the database or on some other storage mechanism if you're worried about SQL injection attacks.
This is a solved problem Posted May 8, 2008 22:15 UTC (Thu) by pdewacht (subscriber, #47633) [Link] The benefit of this method is that you don't need to keep any server-side state for sessions: all needed information can be kept in the cookie, and the hash ensures the information can't be forges.
Secruit should depend on the impact Posted May 9, 2008 2:54 UTC (Fri) by dps (subscriber, #5725) [Link] What the Murdoch paper fails to say is that what security you need depends on the impact of breaking the scheme. If someone steals a LWN cookie or WSJ cookie the marginal cost of shipping the bits to them too is presumably minimal. If you are thinking of online banking, stock trading or another system where the impact can be large then you probably want something stronger than what is proposed. It is easy to ensure that cookies only work once if you have a database table that maps cookie values to user names. Some banks think that things like SecurID's tokens are worth the money. FYI you can throw money at the SSL performance problem. An outfit called nCipher sells gigabit ethernet adapters with both TCP and SSL done on the hardware. Disclaimer: nCipher will be employing me in the near future :-)
Secruit should depend on the impact Posted May 10, 2008 15:42 UTC (Sat) by dvdeug (subscriber, #10998) [Link] It seems like foolish economy to not worry about doing things right when the cost of doing things right is cheap. As for LWN, that's assuming that none of the administrator groups have magic powers, and it's also assuming that the cost of letting people masquerade as other people is minimal, which it arguably isn't.
|
|||||||||||||