

'Padding Oracle' Crypto Attack Affects Millions of ASP.NET Apps - Uncle_Sam
http://threatpost.com/en_us/blogs/new-crypto-attack-affects-millions-aspnet-apps-091310

======
tptacek
_I wrote a comment about this a year and a half ago, and I'm just go to re-
paste it verbatim here:_

You want sick? Here's sick.

An AES block is 16 bytes long. You want to encrypt the lyrics to "Yellow
Submarine". You can't just repeat AES for each 16 byte block, because then you
can tell where the words "yellow submarine" --- 1 AES block --- occur: they'll
encrypt to the same block. So you use CBC mode, XOR'ing each plaintext block
to the previous ciphertext block, creating a unique ciphertext every time you
encrypt those lyrics. But "Yellow Submarine" is 902 characters long; the last
block is 6 bytes short. So you pad the message which a count of the pad
characters --- 06h 06h 06h 06h 06h 06h.

With me so far?

Decrypt the message. Check the padding: it should repeat as many times as the
value of the last byte. If not, you decrypted badly. Send an error to that
effect.

Hey guess what! I can decrypt parts of your message!

If I stick a random AES block in your message, it will scramble the padded
block. Every once in awhile, that scrambled message will end in 01h. 01h is
valid padding. The message will be gibberish, but you at least won't tell me
it had bad padding.

You wouldn't tell me if you decrypted to bad padding if I generated 02h 02h
either. But that's much less likely than 01h.

Now I know that your plaintext XOR my random block produces a last byte of
01h. Solve.

Now my point: this is actually way old news --- back to Bleichenbacher and
Vaudenay and probably before that (I'm not the resident expert) --- but
attacks like this have broken peer-reviewed versions of TLS, the most peer-
reviewed crypto protocol ever designed.

Don't build crypto.

 _Some quick back-story_

Vaudenay described this attack almost 10 years ago, in this paper:

[http://lasecwww.epfl.ch/php_code/publications/search.php?ref...](http://lasecwww.epfl.ch/php_code/publications/search.php?ref=Vau02a)

It's very readable for a crypto paper.

We blogged about padding oracles in our AES post 2 years ago.

Then Thai Duong and Juliano Rizzo independently re-discovered them and went on
a tear looking for software vulnerable to the flaw. Just a few months ago,
they busted up Java Server Faces with the exact same vulnerability.

The nature of the attack is this: in almost all modern web frameworks, session
storage can be stored "clientside" in fat cookies. These cookies are encrypted
so that users can't modify their contents. Because of this vulnerability,
attackers can take legitimate fat cookies, decrypt them, and (often) modify
their contents. Those attackers can then (say) issue fraudulent payments,
change their user ID, alter their account balance, or inject SQL or Javascript
into code that never expected to be exposed to attack because it was guarded
with AES.

This vulnerability is also a galactic pain in the ass to address:

* It exploits the common-case error handling behavior of most web stacks (generate exception, do something that visibly indicates to the user that an exception was generated)

* It's not enough just to stifle the errors; you have to make observable behavior in the bad-padding case identical to the good-padding case.

* If you're MAC'ing packets as well as encrypting them, you also have to make sure the timing is the same in the bad-padding and good-padding case, which means you have to "pretend" to MAC the bad-padding packets, which is extremely counterintuitive (you have to catch an exception then pass "something" to a MAC verification routine).

 _Some food for thought_

It's 2010, vulnerability research is no longer a cottage industry (it's
hundreds of millions annually), and we're _just now hearing_ about exploits of
one of the simplest crypto flaws there is (there is almost no math to this
one).

Software security people simply don't read crypto papers.

Crypto researchers, at least until recently, don't break software.

God only knows how much other scary stuff is buried in those papers waiting
for an enterprising bug hunter to try them out.

~~~
icey
What are potential solutions to this? Keep a KV store of ids and checksums of
every cookie sent and verify them when requesting the data back from the
client?

~~~
judofyr
I believe the real solution to this problem is to not encrypt the cookies at
all, but rather just use HMAC to make sure no-one can tamper with them.

If you need to put sensitive data in cookies, _you're doing it wrong!_

~~~
tptacek
The train has already left the station on encrypted fat cookies. It's not
productive to argue that the problem is fundamental to the design; it isn't.
This is the textbook definition of an implementation fault.

Note that (a) lots of people have screwed up HMAC recently and (b) HMAC isn't
a solution to the padding oracle problem unless you take pains to make sure it
isn't.

~~~
judofyr
Regardless of the issue mentioned in this article, it could be argued that
encrypting cookies, which basically means that you're storing data on a user's
computer which the user is not allowed to even _look_ at, is a flawed idea. If
the user should not be able to look at it, why store it at the user's computer
in the first place? And why must the app hide the data for the user?

(Unless I'm mistaken and there's other advantages for choosing encryption over
MAC?)

Interesting, how could you exploit padding oracle when you're using HMAC?

~~~
tptacek
You need to do both: encrypt to provide confidentiality, MAC to provide
integrity.

In sign-then-decrypt designs --- which, from what I've seen, is what most
designs are --- you can still exploit a padding oracle when the app catches
padding errors and skips the (pointless) MAC verification for a packet it
plans to discard anyways.

------
redstripe
This looks pretty bad. The standard way to authenticate in an asp.net app,
FormsAuthentication.RedirectFromLoginPage(), basically encrypts a username and
saves it to a cookie.

Any subsequent requests to a site will trust that cookie as long as it
decrypts properly.

~~~
brl
Yes, exactly. Among other things, this attack allows you to forge
authentication cookies on _any_ ASP.NET application with a 100% success rate.

------
tedunangst
Or you could use SSL and not give a shit.

The bug isn't being able to decrypt cookies, it's thinking that encrypted
cookies are useful.

~~~
tptacek
SSL has absolutely nothing to do with this vulnerability. The encryption being
discussed here protects the application from its own users.

~~~
tedunangst
From the article: "The attack allows someone to decrypt sniffed cookies, which
could contain valuable data such as bank balances, Social Security numbers or
crypto keys."

I'm pretty sure I already know my bank balance, so hiding it from me seems
pretty pointless. And like I said, protecting an app from its users by
encrypting cookies is a stupid idea from the start.

~~~
tptacek
I thought "the crypto is protecting the app from its users" was pretty clear,
but apparently it wasn't. Let me try it again: "the crypto that Juliano and
Thai broke is protecting your bank from _you_ ". Is that more helpful? The
attack doesn't involve sniffing.

Can I ask, what's the psychology of knee-jerk "this vulnerability doesn't
matter" comments? You clearly don't know what the flaw is, and that's fine,
but I'm really curious: why do you _want_ it to be pointless? Isn't the world
a more interesting place when ASP.NET can blow up spectacularly because of a
2-line programming error?

~~~
tedunangst
OK, fine, the crypto is protecting the bank from me. It's still stupid. Don't
send users secrets with the implicit promise that they won't tamper with it.

It's a lot better for my bank to not send me anything to tamper with. Then it
doesn't matter if the crypto works or not, because there's nothing I can
tamper with.

Why is it pointless to point out that there's a better way to build apps that
avoids the entire flaw?

~~~
tptacek
What's your point? That you don't like the way ASP.NET, J2EE/JSF, Rails, and
Django work? You started out saying "just use SSL and you don't have this
problem". You were wrong. Then you said "but all I can see is stuff I already
know". You were wrong there too. Now you've backpedaled all the way to first
principles. Sure, now you're not wrong; indeed, if everyone just redesigns
their applications not to use AES at all, they _will in fact be safer_.

~~~
tedunangst
OK, the jab about SSL was misguided. On my first read of the article, I
thought it was about protecting cookies from eavesdroppers. I didn't consider
people attacking the app because I thought it was kind of silly that you'd
leave yourself open to that. Oh well, turns out I'm wrong and the world is
crazy.

------
bdfh42
I suspect that there are precious few ASP.NET applications where this is any
sort of a risk (millions? - rubbish) and any developer that lets his or her
server side code send anything other than a generic error message back to the
client in 2010 would be an idiot.

"Nothing to see here" as they say.

~~~
tptacek
The generic error is all they need. Next time, don't write "nothing to see
here" when all you did was skim a news story.

~~~
storm
To be fair, the "millions" does seem quite hyperbolic, at least insofar as it
assumes every ASP.NET app will be in grave and imminent danger. Plenty of
ASP.NET devs don't use cookies at all beyond the default behavior, which is to
track session id. Modifying that wont be terribly useful without another known
session to hijack, I'd think.

~~~
tptacek
Bruce Leidl ('brl) works with Juliano, and just commented that this is a
100%-effective attack against _any_ ASP.NET application's authentication.

It's OK to be skeptical about things (god knows I am), but it's important to
be clear about where your actual knowledge ends. I think one thing that's
confusing people is that the talk hasn't actually been presented yet.

~~~
storm
Between your comments, brl's, and the JSF paper, its clear enough how this
works now. Thanks.

I still suspect this is being overhyped. Being able to forge the auth cookie
100% of the time doesn't change the fact that you need a server-recognized
value to actually forge.

This seems like it could indeed badly damage apps that stash important things
in client state expecting it to be secure, but a lot of bog standard asp.net
apps will be unscathed, unless I'm missing some killer detail. We'll see.

Edit: If the contents of a forms authentication cookie are not session-bound
and assume that crypto == safe, that could certainly make things interesting.
No idea though.

Edit2: Increasingly convinced that this could enable devastating attacks on
forms auth (a large proportion of asp.net apps to be sure) - the content of a
forms auth ticket appears to be trivially constructed.

