Is Padding Oracle Attack possible with always 200 OK response

I currently perform penetration testing of ASP.NET application and trying to exploit Padding Oracle Attack. This AFAIK is based on response code analysis, but both ScriptResource and WebResource axds of the system under 开发者_如何学Pythontest always respond with 200 OK, even if cipher has been invalid. In this case, however, the content of the response is an empty string.

Is it possible to use any of the axd as the oracle in this case? Maybe basing on response content difference.

The Padding Oracle Attack works by being able to distinguish between two cases:

• The server failed to decrypt the data because, upon decryption, it did not found a properly formatted padding.
• The server found a correct padding, but the decrypted data turned out to be random junk.

There may be several ways for an attacker to get such a distinction. A specific error code from the server is just the easiest to exploit; but any detectable difference is enough. The attack was first published in 2002 (yes, it took 8 years for people to notice that it could be applied to ASP !) and it has been demonstrated on a SSL connection with only a timing difference: the server was decrypting the data, and then was verifying the MAC only if the decryption went fine; the extra 2ms taken by the MAC computation were enough for the attacker to know whether the padding was valid, allowing for direct application of the Padding Oracle Attack.

To answer your original question, the content length can be used. Padbuster notes the status code but I think it detects entirely off the response length.

To answer your reply to Troy, a long ciphertext length does not indicate they are vulnerable. Typically a short ciphertext length does indicate they are vulnerable, but you need to dot net url decode the value then see if modulus 8=0 to see if it's vulnerable. In other words, the length will be a multiple of 8. Usually i'll see one block of ciphertext (16 bytes) end up about 25 bytes once it's dot net url encoded. The fix includes a HMAC (I think), which extends the length and should make one block cipertexts impossible. I can't say this with certainty, as I'm not sure how long the HMAC is and if it works after padding or not.

It sounds to me like the padding oracle patch may have been installed and as a result you're not getting the error codes you were expecting. Have a look at Do you trust your hosting provider and have they really installed the padding oracle patch and see if you can establish this.