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...
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.
Ok, so now I'm confused... I read through the paper (Thanks for the link...). I'm concerned about this part specifically:
<div style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;" id="_mcePaste">A final note is people often use one global crypto key and a fixed IV to encrypt</div> <div style="position: absolute;
left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;" id="_mcePaste">everything, so if attackers found a Padding Oracle, then they can use it to</div> <div style="position: absolute; left: -10000px; top: 0px; width: 1px;
height: 1px; overflow-x: hidden; overflow-y: hidden;" id="_mcePaste">decrypt all data encrypted under that key and IV.</div>
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...
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).
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.
i8beef
Member
69 Points
45 Posts
Is MachineKey compromised or does this just allow forgeries?
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 /
Rovastar
Member
182 Points
59 Posts
Re: Is MachineKey compromised or does this just allow forgeries?
Sep 21, 2010 05:09 PM|LINK
THey can get the machine key in certain scenerios.
i8beef
Member
69 Points
45 Posts
Re: Is MachineKey compromised or does this just allow forgeries?
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?
Yaur
Member
43 Points
9 Posts
Re: Is MachineKey compromised or does this just allow forgeries?
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:
https://media.blackhat.com/bh-eu-10/whitepapers/Duong_Rizzo/BlackHat-EU-2010-Duong-Rizzo-Padding-Oracle-wp.pdf
i8beef
Member
69 Points
45 Posts
Re: Is MachineKey compromised or does this just allow forgeries?
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:
<div style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;" id="_mcePaste">A final note is people often use one global crypto key and a fixed IV to encrypt</div> <div style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;" id="_mcePaste">everything, so if attackers found a Padding Oracle, then they can use it to</div> <div style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;" id="_mcePaste">decrypt all data encrypted under that key and IV.</div>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...
Yaur
Member
43 Points
9 Posts
Re: Is MachineKey compromised or does this just allow forgeries?
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).
i8beef
Member
69 Points
45 Posts
Re: Is MachineKey compromised or does this just allow forgeries?
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.