views:

674

answers:

6

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

A: 

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

gautema
"An oracle in the context of cryptography is a system which provides hints as you ask it questions." Has nothing to do with Oracle (the software maker). Oracle PR cannot be too happy about the nomenclature here...
Thilo
This post does not help with the details about web.config which is what the asker wants to know
cottsak
+3  A: 

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)

James Crowley
This 'feature' appears to be provided by the WebResource.axd and/or ScriptResource.axd files. I haven't seen confirmation that disabling/removing these will fix the web.config file disclosure issue, but it seems likely. It looks like the attack may be able to retrieve the machine key, which is the pre-requisite to attacking these files.
I've tried using the WebResource.axd approach with the `ClientScript` methods and from what i can tell, not only do the files you wish to serve this way need to be built as Embedded Resources but you need to add declaration in the AssembilyInfo too. If im not doing any of this, how does this exploit work? And how does it get something so critical as the web.config?
cottsak
A: 

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

eglasius
A: 

The following post may be interesting for this thread:

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

Augustine
A: 

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

Josh Yeager