Cryptographic splicing makes for a Wordpress vulnerability

Authentication 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.

Index entries for this article
Security	Vulnerabilities/Cryptographic splicing
Security	Web application flaws

---

to post comments

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.

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.

How would that help?  Wouldn't it only work for browsers that implement that particular
extension to HTML/CSS?

And add the ability to log out!  What did the HTTP devs think, that nobody ever wanted to
share a computer?

That would probably be a browser implementation issue wouldn't it?  File a bug against your
browser if it does not allow this.

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.

That just forgets your password, right?  It doesn't actually allow you to log out.

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.

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.

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

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.

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

> 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

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.

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. :-)

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

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.

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 :-)

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.