WordPress 2.5.1 came out recently. It includes a critical security fix for a cookie integrity bug that would allow an attacker to impersonate other users, including WordPress admins, by manipulating the contents of an HTTP cookie. Whenever I read about a vulnerability predicated on the user identity being embedded into a client-side token (as opposed to a pseudorandom session identifier), I like to dig a little deeper to see what’s going on.

How does the authentication mechanism work?

The advisory describes the structure of the WordPress authentication cookie as follows:

The new cookies are of the form:

"wordpress_".COOKIEHASH = USERNAME . "|" . EXPIRY_TIME . "|" . MAC 

Where:

COOKIEHASH:  MD5 hash of the site URL (to maintain cookie uniqueness)
USERNAME:    The username for the authenticated user
EXPIRY_TIME: When cookie should expire, in seconds since start of epoch
MAC:         HMAC-MD5(USERNAME . EXPIRY_TIME) under a key derived
             from a secret and USERNAME . EXPIRY_TIME.

So you login to WordPress with your username and password, and then the login page issues you a cookie such as the one below:

Set-Cookie: wordpress_52440d615a927011d57374216b3ff789=
  admin%7C1209329209%7C7d5e9e67d8f74a2b657b2e63437a1241; path=/blog/

As expected, the cookie contains the username, expiration in epoch time, and an MD5 hash (the %7C’s are the URL-encoded form of the ‘|’ character). The wp_generate_auth_cookie() function generates the cookie as follows:

$key = wp_hash($user->user_login . $expiration);
$hash = hash_hmac('md5', $user->user_login . $expiration, $key);
$cookie = $user->user_login . '|' . $expiration . '|' . $hash;

Each subsequent request that your browser makes to WordPress contains the authentication cookie, which the software then verifies to make sure you are who you say you are. This occurs in the wp_validate_auth_cookie() function:

list($username, $expiration, $hmac) = explode('|', $cookie);
.
.
$key = wp_hash($username . $expiration);
$hash = hash_hmac('md5', $username . $expiration, $key);

if ( $hmac != $hash )
  return false;
$user = get_userdatabylogin($username);
.
.

As you can see, the function parses out the username, expiration, and HMAC from the cookie. It then generates the expected hash value, based on the concatenation of username and expiration, and compares it to the HMAC in the cookie. If the values match, it fetches the user object corresponding to the username in the cookie, and you’re authenticated.

So how can this be attacked?

The authentication mechanism assumes that an attacker cannot calculate the HMAC. However, this assumption is broken because the two inputs used to calculate the HMAC (username and expiration) are not clearly delineated. To illustrate, let’s say I register a new user account and for the username, I select admin0. Now I login to the application and I get back my authentication cookie, which would look something like:

admin0|1209331305|HMAC_FUNCTION("admin01209331305")

Do you see where we are going with this? Now that we know the expected value of HMAC_FUNCTION for the string “admin01209331305″, we can re-use it to our advantage. We simply remove the 0 from the end of the username and prepend it to the expiration time, keeping the HMAC value the same:

admin|01209331305|HMAC_FUNCTION("admin01209331305")

The HMAC calculation checks out, and as far as WordPress is concerned, you’ve just authenticated as the admin user.

How was it fixed, and does it matter to me?

The fix was straightforward: use a delimiter to ensure there is no ambiguity between the username and the expiration when calculating the HMAC. Now when I login as the admin0 user, my cookie looks like this:

admin0|1209331305|HMAC_FUNCTION("admin0|1209331305")

You can’t re-use the calculated HMAC_FUNCTION for “admin0|1209331305″ in any useful way, because there’s no longer ambiguity between the username and expiration values.

As stated in the original advisory, you should upgrade ASAP if your WordPress instance is configured to permit account creation.

Apparently the security blunder of the weekend goes to the Barack Obama campaign for having XSS vulnerabilities throughout their website. There’s no need for me to rehash the story, you can read other articles that describe what happened. My thoughts on the matter are as follows:

• I wish the media wouldn’t refer to this as “hacking Obama’s website” because it’s not quite accurate; XSS attacks end users, not the web site itself. Clearly one makes a better headline than the other.
• Can people (that’s you, security bloggers) stop saying things like “they should have been filtering inputs?” The most effective way to protect against XSS is HTML entity encoding, NOT input validation. Input validation is great and all — and please continue to use it in general — but you’re going to miss something.
• Why is anybody surprised about this? Did anybody really think that the Obama (or Clinton, or McCain) campaigns would be spending money on web security testing? I guess they might be from now on…

All quite amusing nonetheless.

One of my favorite pieces of swag from RSA was this “Not a CISSP” button that was pinned onto me by none other than Sinan Eren as I was chatting with Justine Aitel at the Immunity booth. Actually, there should have been a prize awarded just for finding the Immunity booth — they were subletting another vendor’s space for a few hours at a time, so one minute they’d be there and the next they were gone.

I digress. What inevitably happened once I started walking around with this button proudly displayed was that I would get one of two reactions. The first group — mostly current and former co-workers and acquaintances — understood the humor and got a good chuckle out of it. The second group would ponder for a bit and then ask, with some confusion, why I’d intentionally point out the fact that I’m not a CISSP. I’d give a brief answer and get back to talking about Veracode (we booth babes have responsibilities, you know).

So, why indeed? The long answer is that like many security certifications, it’s an ineffective measure of a security professional’s practical abilities. Employers and customers often assume the guy with the five magic letters on his resume is technically superior to the guy without. In my experience, it’s exactly the opposite, particularly in situations where you have to sit down at a keyboard and actually DO something as opposed to talking about it. Certainly, I’ve encountered some very notable exceptions to this observation, but we’re playing by the 80/20 rule here.

There’s a good reason for this. The trend in information security is toward specialization. Security has become such a broad umbrella of varying disciplines that it’s quite difficult to be a generalist. A security career is a balance between breadth and depth, and these days, the skilled pen tester, reverse engineer, or vulnerability researcher is more marketable than the guy who knows a little bit about dozens of different disciplines but can’t apply that knowledge in a practical situation. The CISSP subject matter illustrates this perfectly — you have cryptographic algorithms, site location principles, network security, and civil law on the same exam. I won’t even get into the complaints I’ve heard about the poorly-worded, overly simplistic exam questions or the ones that simply test one’s ability to memorize obscure facts.

I’m not claiming that there’s no value to holding the CISSP certification. It can’t hurt to have some exposure to business continuity planning, for example. The problem, as I stated in the beginning, is that the CISSP title is often interpreted as an indicator of practical abilities rather than a book-level understanding of security basics. These misaligned expectations can ultimately lead to bad hiring or staffing decisions.

Career advice, take it or leave it: If an employer or prospective employer demands that you get your CISSP in order to be hired or to progress in your career, run fast in the opposite direction and find a place where you will be valued for your cumulative experience rather than a piece of paper. Learn by doing, don’t “learn the test,” so to speak.

And that, in a nutshell, is why I love my “Not a CISSP” button.

By the way, here was my other favorite from RSA, thanks to WhiteHat. This one and “Samy is my hero” were the best out of a pretty clever selection… even though they forgot the semicolon after the single quote. <grin>

I was just reading an article discussing the timeframe for upcoming revisions to the PCI-DSS. Nothing quite so exciting as reading about a compliance roadmap, right? This article reminded us about PCI Section 6.6 becoming mandatory in June 2008, with additional guidance and clarification coming in May (hey, a whole month to prepare!). As a refresher, 6.6 says that web applications must be reviewed by a third party for security vulnerabilities, or a web application firewall (WAF) must be installed. Anyway, in this article, PCI-DSS General Manager Bob Russo makes the following statement:

“Personally, I’d love to see everyone go through on OWASP-based source-code review, but certainly, that’s not going to happen,” Russo said, referring to the expensive and time-consuming process of manual code reviews. “So the application firewall is probably the best thing to do, but there needs to be some clarification around what it needs to do. That clarification is coming; that’s been the biggest question.”

Really? The WAF is the “best thing to do?” Maybe he meant to say “cheapest” or “quickest,” but how is a WAF better than fixing the root cause of vulnerabilities? I don’t deny that a WAF can be valuable to a layered security approach. For example, if I need to quickly plug a hole in my web app, I can configure the WAF to block it, thereby buying time for the development team to fix the problem. Instead of having to fix the bug immediately, it can be rolled into the next release cycle, with the WAF protecting the site in the interim.

Sure, the WAF can protect against some known attacks, and if you set it up the right way, it can attempt to detect and block other, unknown attacks — that is, if it’s configured aggressively enough. Except very few companies will actually do that. Nobody wants to risk the WAF confusing a legitimate request with an attempted attack and subsequently blocking user traffic.

This is why I argued, a while back, that a WAF really should be considered a compensating control since it is more of a band-aid than a best practice solution. That would give the requirement a lot more credibility rather than giving enterprises an easy way out.

Recently making the rounds is this hack against the Facebook Moods application, currently installed by over 84,000 users. By manipulating the fb_sig_user parameter, it’s possible to alter the mood of any user who has the application enabled.

Though this is just another manifestation of an authorization bypass issue, the security community should coin a new buzzword to describe these types of vulnerabilities when they are specific to social networking applications. Given the increasing prevalence of social networking sites and extensible APIs, it seems the logical thing to do. One need only think back to Cross Build Injection (XBI) and Cross-Site Printing (XSP) to realize the importance of a shiny new acronym to raise the visibility of such a critical risk. I propose that, going forward, security practitioners should refer to these vulnerabilities as Cross Social Networking Application Direct Object Reference (XSNADOR). That’s pronounced eks-SNEY-dohr, in case you were wondering.

XSNADOR attacks are very common, they have simply lacked a catchy label for the media to latch on to. Look at all of these Facebook application hacks published last summer. These bugs would have had much greater visibility as XSNADOR attacks — maybe even enough visibility for the author to continue posting. The blogosphere and the twittersphere would have been abuzz, raising the level of awareness everywhere.

If you have a security blog, feel free to take part in a little Cross-Publicity Injection (XPI) and discuss this newly-discovered application security risk with your readership. Help spread the word about XSNADOR! Bonus points for every acronym you reference in your post.

Happy April 1st everyone!