locked
Is MachineKey compromised or does this just allow forgeries? RRS feed

  • Question

  • User1459398585 posted

    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 /

    Tuesday, September 21, 2010 12:24 PM

Answers

  • User1640174264 posted

    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).

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Tuesday, September 21, 2010 10:56 PM

All replies

  • User-234406897 posted

    THey can get the machine key in certain scenerios.

    Tuesday, September 21, 2010 1:09 PM
  • User1459398585 posted

    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?

    Tuesday, September 21, 2010 1:38 PM
  • User1640174264 posted

    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

    Tuesday, September 21, 2010 6:46 PM
  • User1459398585 posted

    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.

    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...

    Tuesday, September 21, 2010 7:50 PM
  • User1640174264 posted

    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).

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Tuesday, September 21, 2010 10:56 PM
  • User1459398585 posted

    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.

    Tuesday, September 21, 2010 11:43 PM