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
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
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
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.
to post comments)