Oracle padding exploit - how does it download the web.config?

Question

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

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

Answer 2

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

Answer 3

FYI, a patch for this bug has been released on Windows Update.

http://weblogs.asp.net/scottgu/archive/2010/09/30/asp-net-security-fix-now-on-windows-update.aspx

Answer 4

The following post may be interesting for this thread:

http://blog.mindedsecurity.com/2010/10/breaking-net-encryption-with-or-without.html

Answer 5

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?

Answer 6

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