Saturday, September 18, 2010

Asp.Net Cryptographic Oracle Padding (COP) Vulnerability

On September 17, 2010, Microsoft issued an important bulletin regarding a major vulnerability that exists in Asp.Net that can allow a hacker to decrypt and encrypt data used by the Asp.Net application (data such as what is typically stored in the ViewState).

First off, watch this video of an attack run against a DotNetNuke Asp.Net web-site and see the level to which an attacker can gain access to the site: (super user, ability to upload modules and files, ability to run commands and ability to download files once the attack was successful and the cryptographic keys were extracted).

More information:

MS bulletin: Microsoft Security Advisory (2416728)

  • Called the "Cryptographic Oracle Padding"  (COP) or sometimes just the “Padding Oracle” vulnerability. (I like COP better!)
  • Exists in many web-platforms (, ruby on rails, etc). It looks like it exploits the fact that some web-platforms return different error messages depending on the type of errors in the encrypted text. By modifying the encrypted information and sending it repeatedly to the server the hacker can get enough information to be able to begin decrypting and encrypting data.
  • Some other systems that are vulnerable:
    JSF implementations such as: Apache MyFaces and SUN Mojarra.
    Ruby on Rails
    OWASP ESAPI for Java (up to version 2.0 RC2)
    Video of an attack on a website hosted using Apache (created by Netifera):
  • Most developers follow the best practice of never storing sensitive information in the view-state, but sometimes people end up using the view-state to store sensitive information, because they think it is secure as it is encrypted. In this case, sensitive information may get compromised.
  • Best practice: never pass sensitive information to a client if the client has no use for it - which normally makes the ViewState ineligible for storing secure data. Also, never store security related information in the ViewState (eg: user access level, etc.)
  • Microsoft has provided a basic vb script that allows you to quickly determine which web-sites might be vulnerable.
  • Shutting down the vulnerability is as simple as making sure the server does not provide error specific information and uses a single error page for all errors. (In addition, the single error page can use a random delay to make it even harder to exploit cryptographic vulnerabilities – there is an old one where one could use the time taken to respond to a request to slowly glean more information into the cryptographic keys). (Enable custom errors and use a single error page for all errors)

As the paper by concludes by paraphrasing Nate Lawson, so do I, as the thoughts are important:

If you find yourself needing to implement crypto, it’s likely you
can avoid it by thinking about the situation differently. For example, many web developers get seduced into designing their own crypto as a way to push state to the client instead of managing it on the server. This opens up a much wider attack surface on the server application since now every part of that blob needs to be considered malicious. As the saying goes, "... now you have two problems."

The reason all this is so hard is that crypto is fundamentally unsafe. People hear that crypto is strong and confuse that with safe. Crypto can indeed be very strong but is extremely unsafe.

More technical info and background on the vulnerability is available from Microsoft at this blog-post:

Information about the exploit can be found at the Netifera (I believe they are the guys who found the vulnerability):

Also, while at NetiFera read their paper: Practical Padding Oracle Attacks.


More videos of attacks against the COP vulnerability:

A paper describing the attack in more detail:
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.

No comments: