Exchange Server and the Oracle Padding Attack

Computer security is a terribly complicated field. There's a great imbalance between attack and defense: Defenders have to block every attack, but attackers have to get lucky only once to be able to compromise a system. As our networks and systems have become more complex, new avenues of attack and defense open up. However, the more insidious threat comes from security flaws that lie undiscovered for some length of time. Numerous cases exist where criminal organizations have paid for information about previously undisclosed flaws, and it's certainly reasonable to assume that national-level intelligence and espionage agencies keep private stables of vulnerabilities that they can use to attack an opponent.

The recent disclosure of a flaw in Microsoft's ASP.NET framework leading to oracle padding attacks is a classic case of a buried flaw that suddenly surfaces, leaving behind questions about who knew about the flaw and how they might have exploited it without notice. Sadly, those are exactly the kinds of questions for which we're unlikely to see public answers. Companies that have been attacked are loath to admit it, and the criminals or agencies doing the attacking aren't likely to speak out either. Instead of worrying about unanswerable questions, let's dive into the details of the attack and assess its potential impact on Microsoft Exchange Server.

First, we have to deal with the concept of padding. Modern encryption algorithms process data in equal-sized chunks called blocks. The block size can vary from algorithm to algorithm, but it's common to see 8 bytes as a block size. Suppose you want to encrypt 114 bytes of data. That number isn't evenly divisible by 8, so you'd really be asking the cryptographic algorithm to encrypt 14 full blocks plus two leftover bytes. The solution is to tack on another six bytes of padding to make the total data size 120 bytes, or 15 blocks. The most common padding scheme is known as PKCS#5; it calls for padding a set of N bytes with value N. In our example, we'd add 6 bytes to the last block, and each of those bytes would contain the value 0x06. If your data doesn't need any padding, PKCS#5 calls for tacking on 8 bytes of value 0x08.

Now, what about the "oracle" part of the attack? As much as I like to mock Oracle the company for its poor security track record, the company actually has nothing to do with this attack. In order to determine if the ciphertext is properly formed, the receiving end needs to know what's padding and what's not. A so-called padding oracle is just a piece of code that checks the padding and returns a value indicating whether it's valid padding or not. This process helps detect messages that get corrupted in transit or that are missing their padding for some reason.

Most application servers—including ASP.NET—return a specific error message if the padding is invalid. By tampering with the contents of an encrypted block and sending it to the server, you can see what kind of error message is returned and use that information to deduce the intermediate value produced during encryption—and from that information, you can work backward to decrypt encrypted information sent by the server to the client.

The padding oracle attack, then, depends on spamming a server with a number of encrypted requests with invalid padding, then analyzing the returned error messages. There's a detailed explanation of the attack's mechanics available in the article "Automated Padding Oracle Attacks with PadBuster" if you're into that sort of thing. The nature of the attack suggests that the key workaround is to force all server-side errors to produce the same error message instead of customized ones, and in fact that's exactly what Microsoft's existing workaround suggests you do.

The real question is which ASP.NET-based applications are vulnerable to this attack. The answer is that it depends on the individual app’s design. For example, SharePoint is vulnerable because it makes heavy use of encrypted data in the ASP.NET ViewState object. The server sends encrypted information to the client, which caches and returns it. If attackers can steal this data, they might be able to get passwords or database connection strings.

At press time, I haven’t seen any definitive answers about Exchange. There’s one report from an ASP.Net forum that claims Exchange 2007 is vulnerable. Exchange 2010 returns the same result as Exchange 2007 using the test provided in that post. However, it’s not clear that Exchange passes or stores any valuable information in a way that could be compromised by this attack.

Unfortunately, absence of evidence isn't evidence of absence. It's probably wise to keep an eye on the IIS logs of your Exchange Client Access servers or front-end servers to check for unusually high numbers of error messages. Hopefully, Microsoft will both soon clarify the affected server applications and release a robust patch, but in the meantime you should be on the lookout for warning signs.

Udpate: Microsoft Pushes Out Patch for ASP.NET Flaw