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

[Tom Ritter]

When their talk first started getting hyped on twitter last Thursday,
the focus was on ASP.Net's viewstate [1,2] rather than the cookie
aspect. (Viewstate is a base64 blob of data in a hidden form field
about the current state of controls on the page.) I wonder if
threatpost focused on cookies because it's more accessible to
non-webforms programmers.  On Friday, a tweet mentioning using HMAC on
the viewstate was a valid mitigation [3].  This made sense to me
because...

<speculation>
If Viewstates are protected with a simple hash by default, you could
append data and still generate a valid hash (because of many hash
functions' design flaw that created the need for HMAC itself [4]).

So you run the padding oracle attack described (which I won't explain
for fear of explaining it wrong) but you can append encrypted blocks
and generate valid hashes of your appended data.

Using HMAC on the viewstate instead of a vanilla hash function
prevents targeting the viewstate because you can no longer append
blocks and generate new hash.
</speculation>

What's weird is I find confusing literature about what *is* the
default for protecting the viewstate.  In this article[5] it says that
in .Net 1.1 viewstates are HMAC-ed to prevent tampering...
	----
	validationKey - This specifies the key that the HMAC algorithm uses
to make ViewState tamper proof.
	----

But this article [6] implies only SHA1 uses an HMAC and MD5 does not,
in .Net 2.0.  (.Net 2 also added encrypted viewstate which is another
story)
	----
	SHA1 - SHA1 is used to tamper proof ViewState and, if configured, the
forms authentication ticket. When SHA1 is selected for the validation
attribute, the algorithm used is HMACSHA1.
	MD5 - MD5 is used to tamper proof ViewState and, if configured, the
forms authentication ticket.
	----

And in this article[7], maybe the most recent, which talks about .Net
4.0 it gets even more confusing, adding specific HMAC options:

	----
	If your application is built on the .NET Framework 3.5 or earlier,
you can choose SHA1 (the default value), AES, MD5 or 3DES as the MAC
algorithm. If you're running .NET Framework 4, you can also choose
MACs from the SHA-2 family: HMACSHA256, HMACSHA384 or HMACSHA512.

	After you choose a MAC algorithm, you'll also need to manually
specify the validation key. Remember to use cryptographically strong
random numbers: if necessary, you can refer to the key generation code
specified earlier. You should use at least 128-byte validation keys
for either HMACSHA384 or HMACSHA512, and at least 64-byte keys for any
other algorithm.
	----

I'm thoroughly confused about what the default is in each version, and
how each option actually behaves.  Based on some of the documentation
and how I understand POET (their tool for the padding oracle attack)
working, I think there may be a disconnect between the writers, and
the security team.  I tried hard to get my company to send one of our
(non-security) Argentinean devs I'm friends with to ekoparty to take
notes and fill me in, but to no avail.  I hope after the presentation
blogs and this list fill with details about it.

Unrelated, at one point a phrase was written and echoed precipitously:
SHA1 is preferable because it produces a larger hash
http://www.google.com/search?q=%22larger+hash+than+MD5%22+%22and+is+therefore+considered+more+secure%22&filter=0

Anyway, Colin Percival and Thomas Ptacek got in a discussion[x] about
Encrypt-then-MAC, reproduced here because following twitter
discussions is a pain:

  Ptacek: CBC + HMAC decrypt+validate is an infamously tricky piece of
code to get right. I've never seen a generalist's implementation that
did.
  Percival: This is why (a) you should encrypt-then-MAC, not vice
versa, and (b) not use CBC mode.
  Ptacek: What does encrypt-then-MAC have to do with it? That's the
pattern that creates the timing variant of the attack.
  Percival: With encrypt-then-MAC, fake messages are discarded without
having their CBC padding inspected.
  Ptacek: Sorry, I misread. But then: you trust SHA256 as a first-line
defense more than AES?
  Percival: Do I trust HMAC-SHA256 more than AES? Hell yes.

Colin's right of course, if the HMAC option is used, then it should
throw out the attempts POET makes without indicating the padding is
good or bad... It's just that darned documentation that's confusing
me!

-tom


[1] http://twitter.com/dragosr/status/24070283257
[2] http://twitter.com/tqbf/status/24032786374
[3] http://twitter.com/dragosr/status/24073818333
[4] http://en.wikipedia.org/wiki/HMAC#Design_principles
[5] http://channel9.msdn.com/wiki/wiki/HowToConfigureTheMachineKeyInASPNET2/
[6] http://msdn.microsoft.com/en-us/library/ff649308.aspx
[7] http://msdn.microsoft.com/en-us/magazine/ff797918.aspx
[x] http://twitter.com/tqbf/status/24033073128
http://twitter.com/cperciva/status/24036001435
http://twitter.com/tqbf/status/24036476121
http://twitter.com/cperciva/status/24038505268
http://twitter.com/tqbf/status/24038614141
http://twitter.com/cperciva/status/24039346001

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com