暗行御史

And if you query the URL, you simply get the web.config code. This is how the attacker is able to get your sensitive data which doesn't have to be only the machineKey, but can be also your connection string to database or anything else for that matter.

As you surely guessed right, the "d" parameter contains the locator of the resource, somehow encrypted. So far, it seems fine until somebody is able to guess or encode the resource identificator. Once he can get the correct one or the encryption key, he can access anything and simply generate those keys.

This solution of theirs basically has only single point of breach which is the encrypted resource key itself. If there would be additional precaution, like allowing only certain types of files to be retrieved, the security issue wouldn't be that bad for everyone, but it unfortunately is.

How the attacker gets the key?

Although breaking the cipher via brute force may seem hard enough, there are ways how to get there quite easily, if the solution isn't robust enough to eliminate just every possibility.

What is typically used to break the ciphers is something called Side channel. Side channel is an information of any type that can leak out from the process and tell the attacker how his particular attack proceeded. Side channel can be really anything and it isn't anyhow based only on software implementation, it can be also part of the hardware. For example, if you try to hack the ATM with electronic device connected to your laptop simulating the credit card, even the time in which the particular request is processed (e.g. longer if succeeds, shorter in case of error, or specific number of cycles executed) can tell the attacker how successful he was until he breaks the cipher going the right way. The creators of sich devices fight against this by incorporating random waits or ensuring that any operation takes same amount of time using delayers. These side channel clues serve the attacker as some sort of oracle to reduce the number of options. Same thing with the software implementations. Any information that can leak out from any security process significantly reduces the number of options. If you want to know more about side channels, try to start here:

http://en.wikipedia.org/wiki/Side_channel_attack

In this particular case of ASP.NET vulnerability, the Side channel clearly is the difference between "Page not found" and "Cryptographic exception". You can get the first one if you link to the non-existing file, and the second one if you attempt to change the URL to the resource.

Very bad thing about AES algorithm that is used by these resources is that it already has known side channels specific to padding of the encrypted data so it is not that hard to break it as you can see here:

http://www.youtube.com/watch?v=yghiC_U2RaM&hd=1

This is exactly what an attacker can do.

One other issue of this is that the length of the encrypted resource key is depending on the length of the data value which means the attacker can use much shorter data to attack and further reduce the number of options. That is another side channel in this particular case.

So what the attacker does is he attempts to partial-guess (using the oracle) the machine key used for encryption of particular key, either one that he chooses or some default one (WebForms link script WebForms.js which has known format of decrypted data and is used on almost any web site implemented through ASP.NET). He basically requests the files until he gets 404 which means the cryptography part has succeded. Once he gets the machine key, he can generate any resource key he wishes. Specifically with the web.config, the decrypted key looks like:

Q|~/web.config|#|298f20c0

Not exactly sure what is the second part (timestamp or hash maybe) but clearly the first part locates the resource. So the attacker generates the URL using this resource locator, and requests the resource. Now he gets the web.config file with all the sensitive information or any other file your web site can access the same way.

How to prevent that?

Now you know how it works on the attacker side which is important so you can understand why the recommended solutions are the way they are. What we need to do is basically to close the side channel which in this case is the error reporting. That is why the official recommendation is to basically provide single error for any case. They suggest following settings: