可以将文章内容翻译成中文,广告屏蔽插件可能会导致该功能失效(如失效，请关闭广告屏蔽插件后再试):

问题:

I know there are already a few questions on SO about the oracle padding exploit but none of them explain how it downloads the web.config. I run a couple of ASP .NET apps which I have already tested using Microsoft recommended mitigation factors but i'm still scared that people will be able to get the web.config.

Can someone please explain how they do this or even provide a link to a tool that I can use to test my site with. I find that the official explanation of this part of the attack is really lacking.

The attack that was shown in the public relies on a feature in ASP.NET that allows files (typically javascript and css) to be downloaded, and which is secured with a key that is sent as part of the request. Unfortunately if you are able to forge a key you can use this feature to download the web.config file of an application (but not files outside of the application).

回答1:

Guys - the answer is that once they have obtained the machineKey, they can use that key to fetch the files using another feature in ASP.NET

"In ASP.NET 3.5 Service Pack 1 and ASP.NET 4.0 there is a feature that is used to serve files from the application. This feature is normally protected by the machine key. However, if the machine key is compromised then this feature is compromised. This goes directly to ASP.NET and not IIS so IIS's security settings do not apply. Once this feature is compromised then the attacker can download files from your application - including web.config file, which often contains passwords.

Versions of ASP.NET prior to ASP.NET 3.5 SP1 do not have this feature, but are still vulnerable to the main machine key attack."

(see the post at the bottom of here: http://forums.asp.net/t/1603799.aspx from the asp.net team)

回答2:

Scott Guthrie has a post which explains it to some extent.

回答3:

This blogpost is pretty interesting: http://www.gdssecurity.com/l/b/

also read this: How serious is this new ASP.NET security vulnerability and how can I workaround it?

回答4:

afaik it goes like this:

these are hit: webresource.axd and scriptresource.axd, both use an encrypted/signed value that asp.net tries to check if its valid
because of differences in the response when the files are or not valid, they can make the padding attack.
once the attack is successful they can generate a request for a resources as if it were originally emitted from asp.net

Now, as far as I knew, both of those are supposed to serve embedded resources, but I guess that's not the case (Scott Gu did mention in his post's comments those are the ones being used in the attack showed).