About the Padding Oracle Attack
You may have read about the Padding Oracle Attack, risking exposure of sensitive information in millions of ASP.NET sites.
This site is not one of the them in any real sense, and never was.
The ASP.NET Padding Oracle Attack exploits a vulnerability published as early as 2002 by Serge Vaudenay in a paper entitled "Security Flaws Induced by CBC Padding Applications to SSL, IPSEC, WTLS...". As usual it's amazing how long time it takes for these things to come to the attention of the large vendors, such as Microsoft.
This attack is in no way specific to ASP.NET - just about every major web platform is likely to be potentially vulnerable. For the technical details, please read the paper by Vaudenay as well as more recent paper entitled "Practical Padding Oracle Attacks" by Juliano Rizzo and Thai Duong. Here I'll just try to explain the factors that cause the vulnerability, and what the consequences may be as well as to describe why this site never was vulnerable in any real sense.
Padding is used in a block cipher to make clear text about to be encrypted an even multiple of the block length. In other words, if the encryption algorithm is designed such that it encrypts 16 bytes at a time, and your clear text is not a multiple of 16 bytes long, we need to add a few dummy bytes at the end to make it an even multple of 16 in this example. These 'dummy bytes' are called padding.
Most encryption schemes use padding that follows a pattern so that the decryption logic can recognize and remove them. Since such a padding scheme is self-verifying, the decryption program can determine if the padding is correct or not - and also give a specific error if the padding is wrong.
An attack requires access to an application that uses a block encryption cipher and actually knows the decryption key, and which an attacker can 'ask' if a given encrypted text contains a padding error or not.
The idea is to send in encrypted text to the application, and then determine if it specifically has a padding error after decryption or not. Obviously, if an attacker sends in bad encrypted text, an error is likely to occurr, but the attack requires that an attacker can distinguish the very specific error 'padding error' from other errors reported.
What's a Padding Oracle?
There are basically two ways an attacker can determine if a padding error has occurred as the result of the the manipulated encrypted text: The easy way is if the application actually says exactly this. With ASP.NET you can for example get the quite clear message "CryptographicException: Padding is invalid and cannot be removed". It does not get any clearer. The harder way is if the application shows different timing characteristics between reporting this error and other possible errors. This is a much harder attack, and much more likely to take significantly longer time since the timing is determined by many other factors as well that are likely to be unknown and uncontrollable by the attacker.
The way to defend against the attack is then to A) ensure that no specific message or error code is returned when a padding error occurs, and B) ensure that timing cannot be used by an attacker as an indirect distinguisher.
A Padding Oracle is something we can ask a question about a given encrypted text, and receive an answer stating either 'Yes, the padding is correct' or 'No, the padding is incorrect'. The trick is to ensure our application is not a Padding Oracle!
The consequences of an attack and why it's so serious for ASP.NET
What's the worst that can happen? Well, anything that is protected by the encryption key used to encrypt the data that the attacker is potentially vulnerable to both inspection and undetected modification.
In the case of ASP.NET, this usually means that the 'machine key' is vulnerable. This is the ASP.NET machine key used to encrypted ViewState and cookies etc, it's not the Windows machine key. In the case of this site, we generate a new key every time the site is started, so even a successful attack has very short time of validity.
Gaining access to the ASP.NET machine key typically means being able to impersonate a logged on user, and possibly gain access to files and other information available to that logged on user. In the case of ASP.NET 3.5 SP 1 and later, it means being able to access all files accessible to the web application via a virtual path. In actual practice, the attack is practical with only a few thousand tries on a typical web site.
The problem with ASP.NET is that a security researcher found a pretty much universal 'Padding Oracle' that is almost entirely independent of the application in question. It uses the 'WebResource.axd' handler as an attack vector. This handler seems to have the bad taste to respond 404 Not Found when the coded resource has correct padding, but is wrong - and 500 Server Error when the coded resource has incorrect padding. There's your padding oracle.
This is pretty bad, so we certainly should take this seriously.
The status for www.axantum.com
The Xecrets on-line password storage has never been vulnerable to this attack for the simple reason that we don't know the encryption key users use, so there's no possibility that our application can be used as a padding oracle for the purpose of breaching the Xecrets password encryption.
However, the Xecrets site as such does use ASP.NET and can theoretically be used as a padding oracle in the sense that it if it should fall to such an attack it would be possible to act as an administrator of the application (not the system). This will still not enable anyone to access stored Xecrets, because the system does not know the encryption key for those files. There is no sensitive information available that is protected by the ASP.NET machine key. It could in theory enable someone to get free access to the Xecrets service though!
Also, becase we create a new machine key every time we restart or recycle the application, even a successful attack would only be valid for a rather short time. Then again, there are rumours that a followup to the attack could lead to code injection.
The Xecrets site uses custom handling of both server errors and not found errors, but it's still probable that it was vulnerable to the WebResource.axd attack. The Xecrets site has from start employed a number of strategies to give aways as little information as possible and reasonable in the face of errors, and has thus always conformed to the first criteria to avoid vulnerability - it returns the same message and page regardless of what kind of error manipulated encrypted text sent to the site causes.
The problem here is that Microsoft has once again failed to follow that maxim, and also failed to follow general good cryptology practices and confused encryption with authentication. Encrypted data should always be verified for authenticity before use, for examle by employing a Message Authentication Code, or a digital signature. All encryption from Axantum uses the well-known 'Encrypt-then-HMAC' or other mechanisms to ensure the authenticity of encrypted data. If ASP.NET had done the same, this would never have happened.
Once again it is shown that following established security and encryption practices will mitigate the situation even in the face of future attacks, impossible to know at the original time of construction. It is also shown that even today, it will take up to 8 years(!) for billion dollar companies to react to a published threat affecting some of the worlds most widely deployed platforms.
As of today, the Xecrets site is also updated to avoid even the ASP.NET Padding Oracle attack via WebResource.axd - or any other similar vector for that matter.
