
Demo of ASP.NET Padding Oracle Attack - ronnier
http://threatpost.com/en_us/blogs/demo-aspnet-padding-oracle-attack-091710?utm_source=Threatpost&utm_medium=Tabs&utm_campaign=Todays+Most+Popular
======
patio11
One comment on that page and already I want to cry: no, custom error pages do
nothing to prevent this attack. Textually identical responses can be
distinguished by side channel attacks, such as via timing. If you have
distinct code paths depending on what kind of error you are throwing, you take
different amounts of time to get through them, and even if that difference is
tens of microseconds the magic of high school stats will let any computer
capable of counting figure out which errors are the ones it is interested in.

~~~
Groxx
I've been seeing that kind of comment _everywhere_ this attack pops up. Or
people claiming this is because ASP.NET's AES implementation has a bug in it.
Or damn near _anything_ but what's _actually_ going on in any kind of padding
oracle attack.

~~~
alecco
Comments from uninformed fanboys are to be expected. What's appalling is MS's
VP in charge of ASP.NET spreading misinformation and down-playing the
vulnerability.

[http://weblogs.asp.net/scottgu/archive/2010/09/18/important-...](http://weblogs.asp.net/scottgu/archive/2010/09/18/important-
asp-net-security-vulnerability.aspx) <http://forums.asp.net/1233.aspx>

~~~
Groxx
Wow, yeah, that's pretty bad. I wonder if it's deliberate, or if they simply
don't understand the attack...

The funny thing about all this is that the fix is relatively easy: encrypt-
then-sign, and validate-then-decrypt. From what I gather, ASP.NET doesn't sign
their data (or they decrypt (and fail early) and then validate). Implementing
this may or may not break some internal code due to more data, however, so who
knows when they'll push a fix.

Though, please, correct me if I'm missing something. IANA crypto expert by any
means, but this attack seems conceptually simple enough that most anyone
_should_ be able to understand the causes of it if they get away from all the
misinformation around it.

edit: clarification: on the validate-then-decrypt, you _should_ be almost
entirely safe, as it's bounded by the security of your signature. To make it
safer yet, return the same error on a padding failure _after_ validation as on
a validation failure, and _always_ do _all_ steps to guard against timing
attacks. Otherwise, if they get lucky enough to make a valid data block that
passes your signature, they can still see / time padding errors. But that
should be astronomically rare, unless you're using MD5.

~~~
euroclydon
You make a good point. I wonder if the time frame between writing the
encrypted data, and reading it back has anything to do with it. Because if it
were possible for the time frame to be long, then the application would be
required to persist the signature for a while.

~~~
Groxx
You lost me a bit there... writing and reading it back, and persisting the
signature?

To try to cover the base I think I see: ASP.NET uses a single encryption key
for all sessions, until you change the values in the web.config file (which I
think requires a reboot).

~~~
euroclydon
I was thinking that the signature needed to be kept on the server, away from
the attacker, because they could simply re-sign the message, but now I realize
that checking the signature first would prevent the routine from ever getting
to the decrypt algorithm, and thus no information would be leaked, so the
attack would fail.

------
SriniK
Site seems to be down. Here are the googlecache links. Looks like half ass
implementation without signing cookies.

<http://bit.ly/aT8R3D> \- Demo of ASP.NET Padding Oracle Attack

<http://bit.ly/b3FdoI> \- 'Padding Oracle' Crypto Attack Affects Millions of
ASP.NET Apps - text version

------
ronnier
Here's a direct link to the video:
<http://www.youtube.com/watch?v=yghiC_U2RaM>

