New Attack Against ASP.NET

It’s serious:

The problem lies in the way that ASP.NET, Microsoft’s popular Web framework, implements the AES encryption algorithm to protect the integrity of the cookies these applications generate to store information during user sessions. A common mistake is to assume that encryption protects the cookies from tampering so that if any data in the cookie is modified, the cookie will not decrypt correctly. However, there are a lot of ways to make mistakes in crypto implementations, and when crypto breaks, it usually breaks badly.

“We knew ASP.NET was vulnerable to our attack several months ago, but we didn’t know how serious it is until a couple of weeks ago. It turns out that the vulnerability in ASP.NET is the most critical amongst other frameworks. In short, it totally destroys ASP.NET security,” said Thai Duong, who along with Juliano Rizzo, developed the attack against ASP.NET.

Here’s a demo of the attack, and the Microsoft Security Advisory. More articles. The theory behind this attack is here.

EDITED TO ADD (9/27): Three blog posts from Scott Guthrie.

EDITED TO ADD (9/28): There’s a patch.

EDITED TO ADD (10/13): Two more articles.

Tags: , , , , , , ,

Posted on September 27, 2010 at 6:51 AM • 37 Comments

Comments

Somebody • September 27, 2010 8:16 AM

Fortunately its not particularly stealthy and will generate a lot of error messages (only useful if you’re looking at them of course).

Some IDS vendors have signatures detecting this already but no patch from MS yet.

I’ve read conflicting reports on how this was disclosed but it seems the researchers went public without giving MS a decent opportunity to patch.

rob • September 27, 2010 8:30 AM

Some blogs show that the error messages are not so obvious. And the worst: the padding error message is very common it happens when the keys are changed and old links are still alive. So the amount of errors doesn’t really matter. And in the video they get SYSTEM access!! ….

HJohn • September 27, 2010 8:32 AM

@: “there are a lot of ways to make mistakes in crypto implementations, and when crypto breaks, it usually breaks badly.”

Complexity sometimes introduces fragility.

James • September 27, 2010 8:59 AM

Re disclosure: Rizzo and Duong haven’t shown enough in their demo for anyone to figure out the exact method of their attack; they’ve not yet released the POET tool. They’re waiting for MS to issue a patch.

Of course, there’s a lot of clues in what they DID show so it’s possible that others could work out the details before the patch appears…

Somebody • September 27, 2010 9:13 AM

@James: They’ve released the tool at netifera linked above (I was playing with it on Friday). With a tool and a demo video, the majority of people out there won’t bother to “work out the details”.

James • September 27, 2010 9:17 AM

I -believe- that that version of the POET tool is the same one they’ve had available for some time, and doesn’t include the ASP.NET exploit.

Yau • September 27, 2010 10:09 AM

For background, these attacks are practical realisations of Vaudenay’s Padding Oracle attacks (no relation to the database corporation) as given in Bruce’s post. Essentially these attacks rely on susceptibility to bit-flipping in CBC mode encryption, especially when the ciphertext is not integrity protected. Three conclusions are:
1. Encryption without integrity can lead to loss of confidentiality.
2. It’s better to encrypt-then-MAC than to MAC-then-encrypt in this context.
3. Developers should be aware of leakage of plaintext information, via error messages or otherwise.

There are two related further padding oracle attacks on ISO standards as cited by Rizzo and Duong (disclaimer: I’m one of the below authors):

K.G. Paterson and A. Yau, Padding Oracle Attacks on the ISO CBC Mode Encryption Standard. in T. Okamoto (ed.), Proc. CT-RSA04, Lecture Notes in Computer Science Vol. 2964, pp. 305-323, Springer, 2004.

http://www.isg.rhul.ac.uk/%7Ekp/padding.pdf

A.K.L. Yau, K.G. Paterson and C.J. Mitchell, Padding oracle attacks on CBC-mode encryption with random and secret IVs. In H. Gilbert and H. Handschuh (eds.), FSE 2005, Lecture Notes in Computer Science Vol. 3557, pp. 299-319, Springer, 2005.

http://www.isg.rhul.ac.uk/%7Ekp/secretIV.pdf

An bit-flipping attack on IPsec using ICMP error messages as a side channel:

K.G. Paterson and A.K.L. Yau, Cryptography in theory and practice: The case of encryption in IPsec. In S. Vaudenay (ed.), Eurocrypt 2006, Lecture Notes in Computer Science Vol. 4004, pp. 12-29, Springer, 2006.

http://eprint.iacr.org/2005/416.pdf

Dave • September 27, 2010 10:10 AM

Is it standard practice- passing sensitive information back to browser encrypted and then trusting that information sent back to you is valid?

I honestly never do this. I don’t like including sensitive information in round trips, encrypted or not. And especially not user/login information. It just felt dirty.

I suppose storing this info in a cookie would be efficient, not having to look that info up all the time and avoiding having to use some sort of session on the server, but it just seemed bad- why give a potential hacker an ‘impenetrable’ box that contains the keys to your vault?

I always used the bare minimum information in all web apps: sessionID. If I ever included user specific information in a cookie, it was never important, usually only harmless user preferences.

I suppose if sessionID is crackable via this attack as well, then you still have a problem, but then you still need to hijack or guess an existing sessionid to proceed.

Nicko • September 27, 2010 11:28 AM

@Dave: The service is not trusting the information sent back to it; the integrity of the data is checked after being decrypted. The problem is that different error messages are being sent depending if the information does not decrypt correctly or if the information decrypts correctly but is then found to be invalid. This single bit of information is sufficient to allow an encrypted message to be cracked open.

Kees • September 27, 2010 11:53 AM

ASP.NET 4.0 can be fixed now as it allows custom algorithms in the machineKey.

A working fix for asp.net 4.0 which adds a sha256 hash to the data being encrypted:
http://www.spoelstra-kolen.nl/captainquery/index.html

We already have seen this attack in the wild (selective targets). The problem is that it is fairly easy to implement.

I must say that MS is doing the best they can with advising possible work arounds. I hope they can release a fix tomorrow (patch tuesday)

HJohn • September 27, 2010 2:13 PM

@Rob: Sometimes? You can remove that qualifier.

Perhaps, but I have seen some pretty complex systems that aren’t fragile.

Joe • September 27, 2010 4:19 PM

@Nicko,

Since the server’s response time may vary with the type of error, and that response time can be tracked, simply returning the same error page could still be a security flaw. (It would take a lot more trials.)

In addition to displaying the same error message a random delay could be added to reduce the observable relationship between the the error and response time.

Rob • September 27, 2010 4:22 PM

@Joe:

The botulinum toxin that it would take to print the period in the end of a sentence is enough to kill 30 people. You were saying?

Gambler • September 27, 2010 6:01 PM

@Nicko:

If the service does not blindly trust the encrypted values, then how does this attack allow attackers to download web.config and do other nasty things described in the articles?

Here is what the last comment to the last article says:

“They are not “recovering” the machine key. They use the ciphertext from the WebResource request, and are able to bruteforce encrypt their own string “R|~/web.config”, once this is encrypted it is passed to ScriptResource.axd. This will then spit out, in plain text, the web.config file, enabling them to view the machine and validation key.”

If this is true (and it sounds plausible), then it’s not just an issue of cryptography, but also an issue of really bad system design.

Papa Smurf • September 27, 2010 10:23 PM

My take away:
The Computing Community was told how to in 2002.
OC exploited it after M/S sold source code to Russia.
but refused to allow US courts to see it, AND
M/S did not ever fix it.
Years later the losses led to lack of liquid substance,
from the public’s banks’ accounts,
covered on the books by R.E. ‘profits”,
from credit default swap bets,
which collapsed,
exposing the underlying weakness.
Was any [One] at M/S complicit?
Do you think [anyone] might be [curious]?

kme • September 28, 2010 1:52 AM

Joe: Adding random delays does not prevent timing attacks. Random delays are just noise, and noise is filterable.

Kees • September 28, 2010 2:45 AM

@kme
Filtering the noise needs more requests, making the hack harder.
It is possible to give the request a constant run time, with a random delay added to the constant. Our work around had this implemented.

@papa smurf
there was also an attack on a java framework earlier this year.
http://www.gdssecurity.com/l/b/2010/09/14/automated-padding-oracle-attacks-with-padbuster/
Universities and companies can have access to the windows source code (under strict limitations).
The code that was exploited is available from Microsoft. If not it can be inspected via reflector.
For the hack you do not need the code, you only need to look at the the encrypted data and the documentation at the MSDN site.

Stephane • September 28, 2010 3:09 AM

Wouldn’t security in depth involve NOT saving any sensitive information in the web.config file anyway ? I mean, the only real secret that you need to save somewhere on the machine is the DB access credentials and these can usually be stored an another, more secure, fashion (integrated authentication, anyone ?)

Stephane • September 28, 2010 3:12 AM

@joe Living organism went through tens of thousand (sometimes hundred or millions) of years of pretty harsh testing and there is a continuous QA check done on every individual instance of each one of them. That’s hardly the condition encountered with human-created artifact where mass-production of identical item is the norm.

Anon • September 28, 2010 5:20 AM

@James: The details of the attack method were published at Eurocrypt in 2002 by Serge Vaudenay. The only missing bit with regard to the attack on ASP.NET is finding out what the two messages for the two types of error are. Google “Security Flaws Induced by CBC Padding Serge Vaudenay” or look at http://www.springerlink.com/content/…

@Nicko: Did you read their USENIX paper? It’s not just “finding out what the two messages for two types of error are”.

HJohn • September 28, 2010 12:29 PM

@Joe: Off topic but, Living organisms are complex and pretty robust.

Actually, I think that’s an on topic, clever analogy. Living organisms are no doubt complex and robust. However, that doesn’t mean a minor event can’t destroy them.

HJohn • September 28, 2010 12:34 PM

@HJohn at September 28, 2010 12:29 PM

I should have added…

Living organisms can, at times, be surprisingly resilient against massive events. Some people have survived falls of tens of thousands of feet when parachutes don’t open, have been burned severely and lived, survived horrific accidents, etc. Some people, on the other hand, have been killed by seeminlgy trivial events that wouldn’t even make most flinch.

Complex and durable, while surprisingly fragile at times.

Volker • September 28, 2010 1:56 PM

Hi!
Could someone please explainm the mechanism for a layman?
I got as far as to understand that when you can fake y_i-1 you can change bits in x_i.
But, say, given a 128 bit cipher and, for instance 100 bits of padding, what’s the point of it? Wouldn’t I need 2^100 tries alone until the “wrong padding” message disappears? And then, how can I make any statements about the remaining 28 bits?

Patrik • September 29, 2010 7:11 AM

Slightly off topic: why would anyone use a padding scheme that can be so easily guessed? Virtually all standardized methods use some form of easy to guess values.

Adding a random padding with a 4-bit length field is my preferred method.

Yau • September 29, 2010 7:19 AM

@Patrik
Yes there are padding methods that are “oracle resistant” in the sense that there are no invalid paddings. But in general it’s a much better strategy to protect the integrity of the ciphertext to prevent padding oracle and other forms of ciphertext manipulation attacks.

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.