Is it true that the WebResource.axd can potentially return any file in the application?

There is a lot of discussion about todays fix for ASP.NET to prevent an attack that can be开发者_如何学Python used to get the encryption keys from an application. In one discussion I read that it could also be used to make the WebResource.axd handler return any file in the application by forging the request parameters to point to a known file location (where /web.config would be the most obvious choice).

Is that true?

---

no, but ScriptResource.axd does, blogged about it here: http://eglasius.blogspot.com/2010/09/aspnet-padding-oracle-how-it-relates-to.html. I recommend reading it, since there was plenty of info out there that didn't get into what and when its exposed / or was inaccurate. I also added extra info in the comments:

Using reflector, its right there at: ScriptResourceHandler.ProcessRequestInternal.

Notice how it receives a VirtualFileReader. The decrypted d parameter begins with either q or r.

Values are taken from the parameter separated by |, and there must be a multiple of 2 number of values. It process them in pairs, where the first seems to be the assembly.

It goes through that code path when you don't specify an assembly. The second value in the pair has a comma separated list.

I stopped at the code, but a request from an assembly is probably like: qsomeAssembly|resource while a request for a file q|somefile

Right before the ms patch was published, one of the researches answered me a question over twitter that confirms they only got the encryption keys by gaining access to those in the web.config.

They cracked part of the encryption/decryption before doing so, but that didn't allow them to break past anything that was signed until getting the keys in web.config (by default in there in DotNetNuke).

Extra confirmation of it on the linked blog post in this answer: how-was-the-oracle-padding-attack-on-asp-net-fixed. Patch limits the ScriptResourceHandler to only serve js / can be turned off if needed. Additionally note that this wasn't there previous to .net 3.5 SP1, which is yet another confirmation as the patch info published by ms explicitly mentions that the file exposure only occurred since that version and above.