Get Help:Ask a Question in our Forums|Report a Bug|More Help Resources
Last post Sep 22, 2010 03:43 AM by i8beef
Sep 21, 2010 04:24 PM|LINK
So with this attack, does the attacker actually get the MachineKey, and thus could later download my web.config and decrypt it, or does this just allow them to forge cookie / view state without knowing what the machine key is? Just curious if web.config
encryption is circumvented by this as well...
/ Michael /
Sep 21, 2010 05:09 PM|LINK
THey can get the machine key in certain scenerios.
Sep 21, 2010 05:38 PM|LINK
So an encrypted web.config can be decrypted if it was encrypted using the standard machineKey?
So if I use a separate RSA key for encrypting the web.config, am I still safe if they happen to get the web.config file?
Sep 21, 2010 10:46 PM|LINK
The attack allows decryption of cipher text and the encryption of plain text with the same key that is used by the oracle, but does not appear to allow key recovery.
I strongly suspect that in the demo video the way they accomplished key recovery was by pulling it from the web.config.
link to the paper:
Sep 21, 2010 11:50 PM|LINK
Ok, so now I'm confused... I read through the paper (Thanks for the link...). I'm concerned about this part specifically:
A final note is people often use one global crypto key and a fixed IV to encrypt everything, so if attackers found a Padding Oracle, then they can use it to decrypt all data encrypted under that key and IV.
This sounds to me like once the attack has succeeded, anything encrypted with the MachineKey is fair game. So if I were to encrypt the connectionStrings for instance, and someone used WebResource.axd to download the web.config, they should be able to conceivably
just use that web.config encrypted value as the cypher text and unencrypt it just like any other message...
Sep 22, 2010 02:56 AM|LINK
Assuming that the same key and IV are used i don't see why that wouldn't work. A quick way to check this would be to feed an encrypted connection string into the "d" parameter of a request to WebResource.axd.
If you get anything other than a crypto exception it would most likely work (key and IV are the same).
Sep 22, 2010 03:43 AM|LINK
Well, since I believe the default encryption method for web.config files uses the machine key...
There is a method to encrypt with a separate RSA key, but I'm under the impression that the standard a lot of people use is the machine key method...
So I guess that web.configs encrypted with the machine key are vulnerable to decoding in a coordinated attack with this exploit. Good to know. Guess I feel better about completely disabling WebResource and ScriptResource for my MVC apps.