‘Padding Oracle’ Crypto Attack Affects Millions of ASP.NET Apps

A pair of security researchers have implemented an attack that exploits the way that ASP.NET Web applications handle encrypted session cookies, a weakness that could enable an attacker to hijack users’ online banking sessions and cause other severe problems in vulnerable applications. Experts say that the bug, which will be discussed in detail at the Ekoparty conference in Argentina this week, affects millions of Web applications.

A pair of security researchers have implemented an attack that exploits the way that ASP.NET Web applications handle encrypted session cookies, a weakness that could enable an attacker to hijack users’ online banking sessions and cause other severe problems in vulnerable applications. Experts say that the bug, which will be discussed in detail at the Ekoparty conference in Argentina this week, affects millions of Web applications.

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.

The pair have developed a tool specifically for use in this attack, called the Padding Oracle Exploit Tool. Their attack is an application of a technique that’s been known since at least 2002, when Serge Vaudenay presented a paper on the topic at Eurocrypt.

In this case, ASP.NET’s implementation of AES has a bug in the way that it deals with errors when the encrypted data in a cookie has been modified. If the ciphertext has been changed, the vulnerable application will generate an error, which will give an attacker some information about the way that the application’s decryption process works. More errors means more data. And looking at enough of those errors can give the attacker enough data to make the number of bytes that he needs to guess to find the encryption key small enough that it’s actually possible.

The attack allows someone to decrypt sniffed cookies, which could contain valuable data such as bank balances, Social Security numbers or crypto keys. The attacker may also be able to create authentication tickets for a vulnerable Web app and abuse other processes that use the application’s crypto API.

Rizzo and Duong did similar work earlier this year on JavaServer Faces and other Web frameworks that was presented at Black Hat Europe. They continued their research and found that ASP.NET was vulnerable to the same kind of attack. The type of attack is known as a padding oracle attack and it relies on the Web application using cipher-block chaining mode for its encryption, which many apps do.

Block ciphers need the messages they decrypt to be broken up into blocks that are some multiple of the specified block size, eight bytes for example. As messages don’t always fit into neat eight-byte sizes, they often require padding to reach the specified size. The attack that Rizzo and Duong have implemented against ASP.NET apps requires that the crypto implementation on the Web site have an oracle that, when sent ciphertext, will not only decrypt the text but give the sender a message about whether the padding in the ciphertext is valid.

If the padding is invalid, the error message that the sender gets will give him some information about the way that the site’s decryption process works. 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.

In addition, an attacker could execute this technique without waiting for the error messages by using information gained through side-channel leakages.

“It’s worth noting that the attack is 100% reliable, i.e. one can be sure that once they run the attack, they can exploit the target. It’s just a matter of time. If the attacker is lucky, then he can own any ASP.NET website in seconds. The average time for the attack to complete is 30 minutes. The longest time it ever takes is less than 50 minutes,” Duong said.

ASP.NET is a hugely popular Web framework, and Rizzo and Duong estimated that 25 percent of the applications online are built using ASP.NET. However, that number is far higher in the corporate and financial services worlds, and apps such as online banking and e-commerce would obviously be prime targets for this attack.

Although crypto attacks can be quite complex, Rizzo said that this technique can be carried out by a moderately skilled attacker.

“The first stage of the attack takes a few thousand requests, but once it succeeds and the attacker gets the secret keys, it’s totally stealthy.The cryptographic knowledge required is very basic,” Rizzo said.

Suggested articles


  • Anonymous on

    What precisely will this do other than reveal the length of the key, modulo whatever the block size is? You'd need to brute force search within the designated key size range in order to find the key, and you'd still then need to do it within the lifetime of a persons session.

    I'm not sure what exactly they've achieved here?

  • Anonymous on

    Explain "side-channel leakages"?

  • Anonymous on

    The POET tool doesn't appear to understand cookies, so how would it be able to attack forms auth?

  • Anonymous on

    I'm glad that POET doesn't understand cookies! Hope it is not easy to implement.

  • asmx86 on

    Totally useless. If you can sniff in realtime then you can already hijack their session which means accessing the site with user's credential.

    So, what they discovered is that you can crack the content of this and see whats in it - which means the application itself must SAVE in these cookies important data, maybe stupid programmers do that - the way to do it is just using the session id and save data server side.

    Besides all this, all banks in the world use SSL - try to break that...

    Anyway, good research but too much smoke if you know what I mean.

  • Dave on

    The title of the article seems very misleading, and a bit sensationalized.

    If this attack relies on error messages being returned to the client, then it hardly affects millions of ASP.NET apps.  All applications when deployed should have verbose error turned off... this is standard deployment practices.  If someone forgets to do this and the app is returning error details to clients, they have a big problem regardless.

  • Anonymous on

    First off, this only works if the developer is dumb enough to stuff crap in cookies.  Generally, you should only use cookies for the session state, if that.  Everything in the session state should be stored in a database (or other persistent media) on the server side.  Didn't we have this discussion regarding viewstate some years back?  Same thing...  Store it on the server side.  At best, they can retrieve your viewstate or session state ID which is pretty much invalidated on the next page request.  Also, make you sure bind those session/viewstate decoding calls to at least the subnet to make sure you don't get some hacker out there hijack a session.  I know, even thats not perfect but it's better than nothing at all.


  • Anonymous on

    This seems more plausible on an Intranet application where the company thinks "inside = secure" and does not use HTTPS for the entire transaction internally. Maybe HTTPS is just used for logging in. There are a lot of those applications.

  • Anonymous on

    Yes I could see where this would be an issue.. That is of course if you ignore the fact that if you can view a cookie of an active session, decrypting the contents is pretty meaningless.

    An infinite downvote for the lack of a real security threat.  This article should be title 'Things you should probably already know about transfer protocols' or 'The internet; a big scary place!!11!1!'

  • Anonymous on

    The biggest application would be getting round the CAPTCHA protected sign up forms as these are vulnerable to this attack as they will decrypt any ERC thrown at them and the p0 (target text in this case) is designed to be human readable.




  • Anonymous on

    (First commenter, returning again)

    Glad to see everyone else is sharing in the conclusion - no security threat of note, unless an application is putting sensitive information in a cookie and trusting it blindly. I've not stumbled onto an application that sets 'IsAdmin=true' in a cookie for some time.

    Gotta admit, the sensationalist bullshit had me going for a minute, but I'll be ignoring this site going forward. Infinite downvote for editorial quality.

  • Anonymous on

    clearly this author has some personal motive against .net (possibly a php/java/etc freelancer hoping to use this to convert some prospective clients from their existing .net sites via fear mongering of the laymens?) to have written such a biased article.

    serious downvote x 1000

  • Delphi on

    Apparently, none of the commenters yet understand what an oracle does. Further, I would not depend upon any particular site following _your_ security guidelines for cookies.
  • Anonymous on

    I think before you judge, you should wait until the research is presented at Ekoparty and ignore all the speculation until then. It's the present ignorant speculation that increases the value of the research. The foundation of message integrity and authentication presently resides in cryptography, hence their statement when it breaks, it breaks badly.

  • Jack Waldron on

    Clearly the majority of posters saying this is a useless article haven't bothered to RTFWP. Which celarly states that the attack can break WEP WTLS, SSH, SSH2, IPSEC, etc encryption to get at the data. It also states that at least some of these protocols can be configured in such a way as to defeat the attck. But that configuration is not necessarily the default or common one. So, this is a real threat. Whether any online banks are vulnerable remains to be seen. I would not be surprised to see small local banks susceptible.

  • Anonymous on

    The FormsAuthenticationToken is serialized and stored in the forms auth cookie.  So if you are able to manipulate that cookie you could change the forms auth token name in the cookie to "admin" and become the admin.

  • Nico on

    @asmx86: All banks in the world do NOT use SSL (TLS) for all HTTP requests.  They typically use it only to protect the login page (and often only the POST to it!).  As for what applications put in the cookie's cleartext: the only thing that helps is to have large, unpredictable session IDs as the cookie cleartext, because predictable cookie cleartext allows the attacker to re-create valid cookies with ease.

    The problem is not doing integrity protection correctly.  "Crypto is hard" -- I want a Barbie doll that says that.

  • Corneliu on

    Nico, if there is a bank that does not use HTTPS for all the logged in part I'd be very scared to be a customer of that bank. I doubt there is a single bank that does not use HTTPS for everything.

    If the login only is HTTPS and the rest is HTTP you can very quickly sniff the session, steal the cookies and start transacting on that user's behalf in less than 1 minute. And that has nothing to do with cookie encryption or ASP.Net. Any site not using HTTPS is vulnerable for cooking stealing. You don't even have to decrypt it, you can just use it in 99% of the scenario.

    Show me one single bank without HTTPS and I'll be rich, sun-bathing happily in Fiji within 24h. 


  • Anonymous on

    Nico, most of the banks are using SSL for the whole online banking application. Please point out one bank in which doesn't use SSL for their whole online banking site. This article is a misleading one. What they could do is just to be able to decrypt/modify the cookies which are protected by .NET framework. If stupid enough .NET developers store critical/sensitive information in their applications then it would be a problem, otherwise, it's almost useless. 

    "own any ASP.NET website in seconds" statement is an over-hype and lame statement. 



  • dr on

    Everyone who waves this one off is not really getting it. ;-P

    And isn't paying enough attention to the way typical ASP sites store state, authentication, credentials and other important material.

    But I'm sure you'll figure it out once your, or an important site to you gets popped because of it.

    The article also should mention that the mitigation for this "not quite so lame" vulnerability is enabling HMAC view states.



    P.S. This is the kind of crypto procedural bug that will have "ripple" in other implementation and places that use the MachineKey code. Waiting for the re-runs in syndication. ;-P ;-)

  • witej on

    Why they do not used HMAC for signing encrypted cookie first, to know that they are decrypting valid something?

  • Senki Alfonz on

    The article fails to mention Microsoft Corp.'s statement/opinion about the issue, and such one-sided presentation is a serious breach of basic jornalism ethics. Shame on Dennis Fisher!

  • Kevin Wall on

    Regarding the question about POET not being able to understand cookies, so how
    would it be able to attack forms auth...

    Based on what I've read here and elsewhere, I suspect that the encrypted ASP.NET __VIEWSTATE is also likely to be susceptible to a padding oracle attack. (However, that's just speculation on my point at the moment.) But the __VIEWSTATEis often passed as a "hidden" form parameter and I've frequently seen it used to support authentication and/or authorization in which case POET could likely address that without any changes.  Besides, I doubt that it would take that much work to get POET so that it could operate on cookies anyway.

  • LaughingAtPaintByNumbersBrigade on

    "First off, this only works if the developer is dumb enough to stuff crap in cookies."

    If you look back that the 'information exposure' or cross site scripting scandals of banking sites over the last few years, ASP.Net is in the mix. ASP does seem to have more than its fair share of developers, who know little about security, relying on frameworks and 'generation tools' from Redmond.

  • Anonymous on

    True.  I've been a .Net developer for a long time (and you're quoting my response).  My background included many years in the financial sector where security trumped everything else.  I guess that gives me a little more experience in writing secure applications than the average person who picked up the "crash your IIS app in 24 hours" book.

    I think that's also one of the things that employers simply don't understand anymore.  any moron can code .Net/Java/PHP/Python, but you really need to find and keep those that have the experience to not shoot the company in the foot when it comes to lack of things like security.

  • John William on

    Kevin, the ASP.NET Viewstate field isn't encrypted by default, it's Base64 encoded. Just google for "viewstate online decoder". So there is nothing to crack :) And by the way: passwords aren't stored in the Viewstate field.
  • Anonymous on

    Can the author of this article reespond to some of these comments please

  • Anonymous on

    Really? No one thinks that being able to forge ASP.NET authentication tickets is a big deal?
  • Anonymous on

    Another implementation of the same technique, following on from the POET tool - http://www.gdssecurity.com/l/b/2010/09/14/automated-padding-oracle-attacks-with-padbuster/

  • Anonymous on

    Have you seen this? http://www.youtube.com/watch?v=yghiC_U2RaM

    You may also take a look at the whitepaper before posting silling comments!

  • Anonymous on

    O gosh, did anybody notice the video is NOT about COOKIES but about encryption used by ASP.NET ? Decrypting a cookie is just an example to show breaking the encryption.
  • AqD on

    What does the crack have to do with owning a website? It's nothing important at all.

    Cookie is supposed to be unsafe and web programmers should know about that. Anyone who would store sensitive information such as social security numbers in cookie is definitely a moron, and a moron cannot be make secure web sites no matter what.

  • Keith on

    According to Microsoft's security warning, this exploit could be used to read files from the application's web folder, as well as the viewstate.  If the program is poorly written this could give the attacker access to credentials needed to access the database (if credentials are hard coded or stored in clear text in the web.config and assuming integrated security isn't used), and it would definitely provide enough information to a skilled hacker to try other vectors of attack.  Access to the application's files content would provide a hacker with the database schema (or at least as much of it that is accessed in code) as well as direct access to the security code portion of the application.

    This attack would have to be combined with other more difficult attacks to succeed in 'owning a server'.  The article also mentions that this attack was originally discussed with Java, so it is hardly an ASP.NET limited error.

  • Anonymous on

    I believe this attack works on anything that .net uses the oracle for.  For example if you login to website a and are given a cookie, hidden form field, querystring value, etc that includes a user identifier encrypted using the oracle, all you need to do is change that value to another user to be them.  Normally noone would be able to do that because the values are encrypted.  This vulnerability makes it so you can get the private key, and re-encrypt values to stuff in those fields.  And lets please stop saying ssl/tls fixes this.. it doesnt..  SSL/TLS is a transport protocol and has nothing to do with anything at the application layer.  If I login to a credit union X through SSL as an authorized user, using my own account, I will likely get some sort of identifier that allows me to move from page to page without the server loosing track of me between clicks.  All I need to do is modify that identifier so that I look like another user and all of a sudden I am them.  Of course you would hope that banks have all kinds of mechanisms and mitigating controls in place to prevent or detect that... and.. many of them do.  Many do not.

  • vivzizi on

    Well apparently Microsoft thought the problem severe enough to issue an emergency patch to .net today

    09 29 2010




  • Anonymous on

    Poor article. Title lead me to believe that it involved Oracle database vulnerability. Kaspersky is simply creating fear to sell it's products. These so called researchers obviously have a anti-MS bais.

  • antihacker101 on

    i hope you get  this, nots sure if the mem pointer will make this message screw up.

    by now, authoritys know that this worm originally circled around me while fighting directly the hacker involved which is high in office.   each of ya still sees attacks as single exploits.   this hacker took the best features of most hacks and made ONE art.  the rest are decoys(mostly psycholgically).     one example you may realize is the adobe popup that you couldnt block. 

    you couldnt block cause the main intent was the hidden backdoor by people we trust.

    the incoming was the 2nd connection.  the main connection is still higher than boot and may consist of bios drivers rewritten so it even cuts out a dos cd for low level formating.

    the error repeated DAV  DAV   DAV   DAV   DAV   DAV (more to it). 

    at the same time, i used process viewer to see the hacker was connecting axel.dav with a database to get in.  

    since feb 2009, i still get over 2000 if not 4000 ips per hour 24/7

    here is a list.  HELP, im sending the worm(inderectly) and also phone systems involved.

    here is a paste if it works.  i just cleared, and less than 2 seconds, i got  this

    Sat Jan 31 11:43:04 2004Blocked incoming TCP connection request from to
    [INFO]Sat Jan 31 11:43:04 2004Blocked incoming TCP connection request from to



    the first ever repeating when this started  was apnic aka asia tele com web site.

    the next linked to dns joint forces and comcast/rr/and all the others with someones new security team.

    what worrys me is the Tapi mutex, mutant, soap, xml, cookies and subject lines and smtp.

    im hoping that  the kinect was not the main intent .

    another possibility was  that call from a number that didnt exist where the other person talking sounded like a recording from another country.      that would match the tapi situation and the aloha or satalite situation linked with dunn.        hi there mr PARKS

Subscribe to our newsletter, Threatpost Today!

Get the latest breaking news delivered daily to your inbox.