F5 Friday: Mitigating the ‘Padding Oracle’ Exploit for ASP.NET

“When crypto breaks, it usually breaks badly.” – Dennis Fisher, ThreatPost

One of the most frustrating occurrences in information security is to discover that the security systems and technology being leveraged to protect applications and data is flawed: that it, itself, is vulnerable to attack and exploitation. This is particularly true in the cryptography realm, because as Dennis Fisher pointed out, when “crypto breaks, it usually breaks badly.”

The “padding oracle” exploit is not, as the name implies, an attack on Oracle products. It is unfortunate for Oracle (as it has been for Zeus Technologies and the increasingly news attracting Zeus Trojan) that this attack appears to be eponymously named. The recently proven exploit is actually targeted at ASP.NET and the “oracle” nomenclature refers to components of its cryptographic systems that are exploited in this attack.

WHAT IT IS

The attack actually exploits two things: the way in which ASP.NET handles errors when encrypted data in a cookie has been modified (tampered with) and the practice of allowing unfiltered error messages to be sent back to the client. The former is specific to ASP.NET, the latter is a larger problem with all web application deployments, despite the ease with which such information-rich data can be intercepted and subsequently blocked from being seen by clients – legitimate or not.

ThreatPost has a more detailed explanation of the exploit, but in general what happens is that if the ciphertext has been changed, the vulnerable application generates an error. This error gives an attacker information about the decryption process and carries more information and data that can give a miscreant the means by which they can infer the number of bytes necessary to find the key used to encrypt the data and ultimately decrypt it. This gives them access to what might be sensitive data such as bank balances or social security numbers exchanged as cookies by financial applications. According to researchers, the attack is 100 percent reliable.

Rizzo and Duong said that the attack is reliable 100 percent of the time on ASP.NET applications, although the time to success can vary widely. The real limiting resources in this attack are the speed of the server and the bandwidth available.

'Padding Oracle' Crypto Attack Affects Millions of ASP.NET Apps

Experts are saying this has impact on millions of ASP applications.

Microsoft responded quickly to this exploit and released a workaround that blocks the errors messages from being sent to the client, but the researchers say it is not enough.

However, Juliano Rizzo and Thai Duong, the researchers who developed the attack against ASP.NET, have said that their technique doesn't require the error messages, they simply make the attack easier. Of course, easy is always better than hard, but the researchers say that customers will not be fully protected until Microsoft releases a patch for the flaw.

HOW YOU CAN MITIGATE with F5 SOLUTIONS

First and foremost, of course, would be to block error pages. This alone, according to researchers, is not enough to stop the exploit but it will slow down attackers and, if you’re honest about it, it’s just an information security “best practice” to disallow data leaks whenever possible. If you aren’t preventing data leaks by intercepting and stopping error messages from being sent to the client then you need to do so anyway. Not just to assist in preventing this attack, but many other attacks.

Stack traces and application errors are data leaks, make no mistake about that.

Using BIG-IP ASM (Application Security Manager) or iRules and BIG-IP LTM (Local Traffic Manager) provide a centralized, simple method of blocking error pages. Not just those carrying an HTTP error code, but those that may be contained within pages and returned with an HTTP 200 OK status. Block errors, they don’t mean anything to end-users and they carry valuable information to miscreants. This should be SOP within your organization regardless of the solutions you use to deliver applications. There are plethora of options available that enable this – including some native to web and application server platforms – so there’s really no excuse for not blocking errors.

The second half of the solution is to not allow tampered data to reach the vulnerable application server. Every request should be inspected and, if it has been tampered with, rejected. To that end, BIG-IP ASM can detect tampering of data, including cookies. ASM enables this by signing domain cookies from the application on the response and subsequently blocking any request in which that data has been manipulated. This is also an information security best practice, particularly when tampering with data stored in cookies might adversely affect not just the security of the data but the transaction itself. If pricing information for products in “shopping carts” is stored in cookies, and that data is altered before being submitted, some systems will treat it as authoritative, which allows miscreants to potentially purchase expensive items for pennies. It’s happened, which is why signing of requests and inspection of cookies has become standard practice. The same techniques can detect and prevent tampered cryptographic data from being leveraged to exploit this ASP.NET vulnerability.

Combining the two techniques will prevent exploitation, primarily due to shielding the application from ever seeing a request in which data has been altered. BIG-IP ASM, as is the case with all full-proxy based architectural solutions, virtualizes the application and mediates for it with the client. The client sees ASM as the “endpoint”, as the “server”, and it is the ASM then that becomes the target of the attack. Because ASM is not vulnerable to this exploit and has additional protections – such as the ability to detect tampering with encrypted/signed data – it can prevent requests that might exploit this vulnerability from being processed by the ASP.NET server.

Additionally, ASM (and other BIG-IP solutions) can take advantage of stronger cryptography through longer key lengths. The success of the “padding oracle” attack depends in part on the size of the cryptographic secret. Using stronger, i.e. longer, keys can help stop – or make exceedingly expensive and difficult – the process of breaking the cryptography and subsequently decrypting the data (which is ultimately the point of this attack).

IS YOUR INFORMATION STRATEGY COMPLETE?

It is anticipated that Microsoft will release a patch for this vulnerability in the Oct 12th timeframe. That’s less than two-weeks away, and it’s possible Microsoft will release that patch earlier than anticipated. In the mean time, you may be vulnerable and a “patch is on the way” is not enough to protect applications in the interim – especially given that the patch will almost certainly need to be tested and certified before being deployed. This may be the opportune time to re-evaluate portions of your information security strategy and put into place a mitigating intermediary like BIG-IP ASM. Not only will it give you the chance to mitigate this particular attack right now, but it puts into place another strategic point of control at which you will be able to mitigate future attacks on-demand.

Regardless of how you address this vulnerability, you need to address it – and sooner rather than later. A 100 percent reliable attack is not something you want to play around with.