Update on ASP.NET Vulnerability

Earlier this week I posted about an ASP.NET Vulnerability, and followed this up with another blog post that covers some Frequently Asked Questions about it.

We are actively working on releasing a security update that fix the issues, and our teams have been working around the clock to develop and test a fix that is ready for broad distribution across all Windows platforms via Windows Update.  I’ll post details about this once it is available.

Important Update: You can now download the official security patch update here.  Please install it ASAP on your servers – it is the only way to protect against the vulnerability.

Revised Workaround and Additional URLScan Step

In my first blog post I covered a workaround you can apply immediately on your sites and applications to prevent attackers from exploiting it.  Today, we are revising it to include an additional defensive measure.

This additional step can be done at a server-wide level, and should take less than 5 minutes to implement.  Importantly, this step does not replace the other steps in the original workaround, rather it should be done in addition to the steps already in it.  Below are instructions on how to enable it.

Install and Enable IIS URLScan with a Custom Rule

If you do not already have the IIS URLScan module installed on your IIS web server, please download and install it:

It takes less than a minute to install on your server. 

Add an Addition URL Scan Rule

Once URLScan is installed, please open and modify the UrlScan.ini file in this location:

  • %windir%\system32\inetsrv\urlscan\UrlScan.ini

Near the bottom of the UrlScan.ini file you’ll find a [DenyQueryStringSequences] section.  Add an additional “aspxerrorpath=” entry immediately below it and then save the file:

[DenyQueryStringSequences]
aspxerrorpath=

The above entry disallows URLs that have an “aspxerrorpath=” querystring attribute from making their way to ASP.NET applications, and will instead cause the web-server to return an HTTP error.  Adding this rule prevents attackers from distinguishing between the different types of errors occurring on a server – which helps block attacks using this vulnerability.

After saving this change, run “iisreset” from a command prompt (elevated as admin) for the above changes to take effect.  To verify the change has been made, try accessing a URL on your site/application that has a querystring with an aspxerrorpath and verify that an HTTP error is sent back from IIS.

Summary

If you’ve already implemented the workaround we’ve previously published, please add the above step to help block attackers from exploiting the vulnerability.

Our team is working around the clock to release an update via Windows Update that fixes the underlying product vulnerability.  Until that update is available, you can use the above workaround to help prevent attackers from using the vulnerability against your applications. 

Important Update: You can now download the official security patch update here.  Please install it ASAP on your servers – it is the only way to protect against the vulnerability.

Once we release the security update, you will no longer need to implement any workaround steps.  You can learn more about this vulnerability and the workaround from:

Please post specific questions about the vulnerability in this forum on the www.asp.net web-site.

Thanks,

Scott

Published Friday, September 24, 2010 4:13 PM by ScottGu

Comments

# re: Update on ASP.NET Vulnerability

Friday, September 24, 2010 7:24 PM by Mbanavige

Thank you very very much Scott for your tireless efforts in helping to keep the community informed on this topic.

# re: Update on ASP.NET Vulnerability

Friday, September 24, 2010 7:39 PM by Nico Lubbers

I am sure you are working long days (and nights) to fix this issue. Is there also a possible rule in Microsofts ISA firewall that can be used?

Nico

# re: Update on ASP.NET Vulnerability

Friday, September 24, 2010 7:42 PM by Fuady

Thanks a lot, Scott.

Still waiting for the patch..

Go ASP.NET team!

# re: Update on ASP.NET Vulnerability

Friday, September 24, 2010 7:49 PM by Adam

Hi Scott

How well does url scan play with SharePoint?  Are there any issues that may be encountered by installing it on a server without testing it with any custom applications first?

Is there a list of what url scan checks for out of the box so we can try to figure out in advance if there may be issues with our custom apps?

Thanks

# re: Update on ASP.NET Vulnerability

Friday, September 24, 2010 7:50 PM by Brandon Zeider

Thanks Scott, great to see support like this!

# re: Update on ASP.NET Vulnerability

Friday, September 24, 2010 8:07 PM by Peter Kellner

Thanks for the update on this

# re: Update on ASP.NET Vulnerability

Friday, September 24, 2010 8:30 PM by sukumarraju

I 'm confident that very soon windows update will get rid of this vulnerability, proving .NET hassle free, robust and secure frame work as ever.

Thanks for your update Scott.

# re: Update on ASP.NET Vulnerability

Friday, September 24, 2010 8:33 PM by Steve

Scott, can we use Request Filtering feature in Server 2008 R2 IIS 7.5 instead of URL Scan? The result of denying the query string with that is an IIS 404 error unless that is redirected.

# re: Update on ASP.NET Vulnerability

Friday, September 24, 2010 8:56 PM by androidyou

Hi Scott,

in terms of the contribution to the vulnerability.

removal of the sub-error status and block of aspxerrorpath=. are they kinda 50/50 important. or just 90/10

# re: Update on ASP.NET Vulnerability

Friday, September 24, 2010 9:00 PM by Michael Collins

Is this fix being applied to the Windows Azure environments, or do we need to configure anything for our compute instances?

# re: Update on ASP.NET Vulnerability

Friday, September 24, 2010 9:21 PM by rovastar

@steve, yes you can use the request filtering in iis7. See the security advisory for details on this. @scottgu i am not convinced this addition step is enough still. I'll drop guys an email later additional steps for url scan if what i suspect is true. @everyone, you really need to install this workround as well even if you have all 200 http custom error pages as you can in certain formed url's avoid these custom error routines.

# re: Update on ASP.NET Vulnerability

Friday, September 24, 2010 11:14 PM by Vijay Pandurangan

Hi Scott,

Is the POET, targets webresource.axd alone or even other resources? Especially I want to know whether, in ASP.NET MVC, the removal of the handler for webresource.axd help to prevent this POET attack or not.

# re: Update on ASP.NET Vulnerability

Friday, September 24, 2010 11:20 PM by Rovastar

@carl, it means a query string in a url like www.mysite.com/mypage.aspx?aspxerrorpath= look in the urlscan logs as well for confirmation.

# re: Update on ASP.NET Vulnerability

Saturday, September 25, 2010 12:59 AM by Carl

@Rovastar sorry, I forgot to include the full link. Let met resay it:

"To verify the change has been made, try accessing a URL on your site/application that has a querystring with an aspxerrorpath and verify that an HTTP error is sent back from IIS."

Does it mean to try something random like this?

www.mydomain.com/default.aspx?aspxerrorpath

If so, this generate a "404 - File or directory not found." under IIS7.5 with your instructions.

I do see the block in urlscan, but it still go to 404. If I understand, the 404 is OK because it comes from IIS, not from ASP.NET.

"and will instead cause the web-server to return an HTTP error"

Carl

# re: Update on ASP.NET Vulnerability

Saturday, September 25, 2010 1:33 AM by ScottGu

@Adam,

>>>>>> How well does url scan play with SharePoint?  Are there any issues that may be encountered by installing it on a server without testing it with any custom applications first?

I believe you can safely install URLScan on a machine with SharePoint.  

Hope this helps,

Scott

# re: Update on ASP.NET Vulnerability

Saturday, September 25, 2010 1:34 AM by ScottGu

@Steve,

>>>>>>> Scott, can we use Request Filtering feature in Server 2008 R2 IIS 7.5 instead of URL Scan? The result of denying the query string with that is an IIS 404 error unless that is redirected.

Yes - the Request Filtering feature built-in R2 can also be used.  Click the "Workaround" section in this advisory to see the exact steps on how to enable this: www.microsoft.com/.../2416728.mspx

Hope this helps,

Scott

# re: Update on ASP.NET Vulnerability

Saturday, September 25, 2010 1:34 AM by ScottGu

@androidyou,

>>>>>>> removal of the sub-error status and block of aspxerrorpath=. are they kinda 50/50 important. or just 90/10

I'd highly recommend both steps.  They are important to block the exploit.

Thanks,

Scott

# re: Update on ASP.NET Vulnerability

Saturday, September 25, 2010 1:35 AM by ScottGu

@Michael,

>>>>>>>> Is this fix being applied to the Windows Azure environments, or do we need to configure anything for our compute instances?

The fix will ultimately be rolled out on Azure - although I don't have an exact ETA yet.  We are making sure they are kept in the loop.

Thanks,

Scott

# re: Update on ASP.NET Vulnerability

Saturday, September 25, 2010 1:35 AM by ScottGu

@zhengchun,

>>>>>>>>> i have installed it on my computer,but i found it conflict with IIRF(Ionic ISAPI Rewriting Filter),it will affect iirf not work.

If you can send me email (scottgu@microsoft.com) we can help.

Thanks,

Scott

# re: Update on ASP.NET Vulnerability

Saturday, September 25, 2010 1:37 AM by ScottGu

@Carl,

>>>>>>> Does it mean to try something random like this? www.mydomain.com/default.aspx?aspxerrorpath

Yes - something like that or:

    www.mydomain.com/default.aspx?aspxerrorpath=foo.aspx

If that returns a 404 error from IIS then the URLScan step is working.

Hope this helps,

Scott

# re: Update on ASP.NET Vulnerability

Saturday, September 25, 2010 5:24 AM by Adrian

I have found that using UrlScan on IIS 6 can interfere with HTTP modules which work directly with the HTTP request, e.g. (used for large file uploads in ASP.Net) because it tops out at 30MB of request length, so it's worth properly testing your application if you're going to put URLScan in.

# re: Update on ASP.NET Vulnerability

Saturday, September 25, 2010 6:18 AM by Adnan

Thank you very much Scott.

this article very important for me.

Thanks. :D

# re: Update on ASP.NET Vulnerability

Saturday, September 25, 2010 6:39 AM by Nik

On two different Win2k8 64 bit machines, I've tried to install Urlscan 64 bit.

In both instances, it installs the dll, but there's no .ini file for some reason.

So I tried to use Request Filtering, as it's got IIS 7.

In the one case, the Request Filtering icon in inetmgr will not show up,even though the role feature is definitely installed.  I've rebooted etc.

Any help??

# re: Update on ASP.NET Vulnerability

Saturday, September 25, 2010 7:33 AM by Michal Altair Valasek

But this would work only in case when CustomErrors are enabled with ResposeRedirect, am I right?

# re: Update on ASP.NET Vulnerability

Saturday, September 25, 2010 7:52 AM by Michal

Scott can you explain why we need this? Why serving the same file for all exception does not help?

# re: Update on ASP.NET Vulnerability

Saturday, September 25, 2010 8:05 AM by kad1r, asp.net

Thanks for update and post. I have a question. After install this update do we have to make custom errors mode is on or not? I mean after this update can I make custom errors off?

# re: Update on ASP.NET Vulnerability

Saturday, September 25, 2010 12:59 PM by Michael

But when we followed your recomendation and added redirectMode="ResponseRewrite" to our customErrors section then there is no request with aspxerrorpath in the querystring. The server rewrites the error page in the same request. So how should UrlScan help here?

(I still have the problem with ResponseRewrite that the server does not call AquireRequestState and thus the Session is not available on my error page, but that's a different story)

# re: Update on ASP.NET Vulnerability

Saturday, September 25, 2010 1:20 PM by Rovastar

@michal, because a certain malformed/crafted url could access other pages in certain conditions. I have tried several sites but i don't host .net 3.5.1 or 4.0 so i haven't tested that workaround. I imagine it can be broken by this though due to the nature of the attack. I'll happily explain more once the patch is available.

# re: Update on ASP.NET Vulnerability

Saturday, September 25, 2010 1:23 PM by Rovastar

yes you will need both, turn custom errors on and this urlscan fix to be protected.

# re: Update on ASP.NET Vulnerability

Saturday, September 25, 2010 5:47 PM by Matthew Hintzen

Scott, actually your blog entry about IIS URL Scan only take a few moments to install is only true if you have already installed the IIS 6 Metabase compatibility component on your Windows Server 2008 machine.  Might want to include steps for adding that part in if necessary.

# re: Update on ASP.NET Vulnerability

Saturday, September 25, 2010 10:16 PM by steve schofield

For sites that use urlwrite 2.0 extensively, what about using an outbound URL Rewrite rule be considered a workaround?

# re: Update on ASP.NET Vulnerability

Saturday, September 25, 2010 11:34 PM by Rachel

I tried to install the urlscan32_x64 and I got a message stating that IIS metabase is required. I cannot seem to find a download for IIS metabase. Is there actually a download that exists for IIS metabase? If so where can I find the download for it?

# re: Update on ASP.NET Vulnerability

Sunday, September 26, 2010 6:07 PM by CaptainQuery

Follow my URL for a fix+source for ASP.NET 4.0 using a custom crypto provider which signs the hashes. This will make the oracle padding attack very hard.

www.spoelstra-kolen.nl/.../index.html

My guess is that MS will provide a similar solution for asp.net versions lower than 4.0.

# re: Update on ASP.NET Vulnerability

Sunday, September 26, 2010 6:32 PM by Xiao Han

Hi Scott,

I am just making sure I understand your post right.

1.Install the msi file to the machine

2.Edit the UrlScan.ini file

3.Under [DenyQueryStringSequences]section, add entry "aspxerrorpath="

4.Save the file.

I am wondering for step 3, do I need to specify any page or path on that machine, such as "aspxerrorpath=C:\Web\Application\errorpage.aspx"? Or I just leave it empty like "aspxerrorpath="?

Thank you.

# re: Update on ASP.NET Vulnerability

Sunday, September 26, 2010 10:13 PM by Matt Youngblut

Since 1.1 is no longer on mainstream support, does that mean that this patch will do nothing to resolve the issue in 1.1?  If so, is this the kiss-of-death for 1.1?

(If so, can't the IE6 team do something similar to scare people off of it?)

# re: Update on ASP.NET Vulnerability

Monday, September 27, 2010 6:04 AM by DCH

AllowDotInPath=1               ; If 1, allow dots that are not file

For people whose URL contains folder which contains dot, the URL scan module's default rule which dis-allow dot in folder. Which has cause us huge problem, if you have same problem, please change to above...

# re: Update on ASP.NET Vulnerability

Monday, September 27, 2010 6:38 AM by Eugenio

Hello,

If a reverse-proxy block a url containing "aspxerrorpath", Is it enough ?

Thanks in advance

Eugenio

# re: Update on ASP.NET Vulnerability

Monday, September 27, 2010 7:51 AM by Paul

We've found that the default URLScan.ini file blocks all Classic ASP requests, so if you need to server these files you'll have to edit the ini file first. We've also found that the pages are now significantly slower to be served from the web server now. In fact they are so slow that we are probably going to backout URLScan.

# re: Update on ASP.NET Vulnerability

Monday, September 27, 2010 10:01 AM by anime

Microsoft has released a patch that is intended to help protect against a reported vulnerability in ASP.NET. It is recommended that users install ASP.NET or patch or implement the previously published solution to prevent unauthorized Web site visitors to view protected content.

# re: Update on ASP.NET Vulnerability

Monday, September 27, 2010 10:06 AM by Guy

Thank you very much for sdharing this scott, your blog rocks as always!!

Very much appreciated buddy!

# re: Update on ASP.NET Vulnerability

Monday, September 27, 2010 10:09 AM by Mike H

One issue I came across with running this setup, is that it filters out by default anything with a . in the path.

After running it, my themes didn't load because the theme names have . in them, as well as the microsoft ajax, because the folder names have a . in them.  The log showed that the GET request was denied because of the .

#Fields: Date Time c-ip s-siteid cs-method cs-uri x-action x-reason x-context cs-data x-control

2010-09-27 13:11:52 10.1.3.99 6 GET /App_Themes/betastore.mysite.com/StyleSheet.css Rejected URL+contains+dot+in+path URL - -

2010-09-27 13:11:52 10.1.3.99 6 GET /Scripts/System.Web.Extensions/1.0.61025.0/MicrosoftAjax.js Rejected URL+contains+dot+in+path URL - -

In any case, to get around this, I had to flip the flag for allow . in the path.  

# re: Update on ASP.NET Vulnerability

Monday, September 27, 2010 11:14 AM by frobnitzz

I've got another comment running on the other blog post... but this one is specifically about blocking requests with "aspxerrorpath="!

Am I ok to use ISA to do this instead?

Adding a signiture in the HTTP policy for a publishing rule blocking "aspxerrorpath=" certainly works if you construct a URL client/request side, but is it enough (so can I skip the URLScan steps with this in place)?

I'd rather configure this on X number of publishing rules than lots and lots of web servers :)

Thanks in advance!

# re: Update on ASP.NET Vulnerability

Monday, September 27, 2010 1:03 PM by Pete

On hosts where we can't access the web server at this level (including Azure) we're using IIS Rewrite.  Any reason not to?

# re: Update on ASP.NET Vulnerability

Monday, September 27, 2010 1:05 PM by Jim Kennelly

Will the autoupdate patch sequenece include a patch for visual studio 2010 so new projects web.config are setup properly just incase the deployement is to an unpatched server?

# re: Update on ASP.NET Vulnerability

Monday, September 27, 2010 1:08 PM by Jasmin Gagnon

Hi

Just to let you know, I had to change the AllowVerbs section in urlscan.ini to make my WCF Data Services works again after intalling UrlScan.

[AllowVerbs]

GET

HEAD

POST

DELETE

PUT

MERGE

Enjoy!

# re: Update on ASP.NET Vulnerability

Monday, September 27, 2010 2:03 PM by Kevin Stevens

When we tried this on a test environment, we found our sites caught in a redirect loop. The error page redirect contains the "aspxerrorpath=" itself, which UrlScan blocks.

Where did we go wrong.

# re: Update on ASP.NET Vulnerability

Monday, September 27, 2010 6:06 PM by Patty

Scott,

I followed your instructions and modified my web.config file and the new custom error file comes up for any error - EXCEPT for when I enter a url with "?aspxerrorpath=blah" on the end...then I get just a straight 404 error (not my custom page).  Is this how this is supposed to work?  Isn't the custom error page supposed to show for ANY error?

Thanks,

Patty

# re: Update on ASP.NET Vulnerability

Tuesday, September 28, 2010 4:18 AM by frobnitzz

@Baillard

tyvm for the link :)

# re: Update on ASP.NET Vulnerability

Tuesday, September 28, 2010 9:41 AM by Judy Vedder

Thank you Scott for the information and keeping us updated.  We really appreciate all of the work!

Judy

# re: Update on ASP.NET Vulnerability

Tuesday, September 28, 2010 3:43 PM by pitz

If you're still using the workaround (instead of downloading and testing the released patch), note the importance of adding URLScan into the workaround, because the customErrors section by itself is not enough to prevent the padding oracle exploit.  forums.asp.net/.../1607422.aspx

# re: Update on ASP.NET Vulnerability

Wednesday, September 29, 2010 12:17 AM by amsharepoint

When we applied the workaround in our SharePoint Environment, users were no longer able to check out documents to their local SharePoint drafts folder. Any ideas on why? Any workarounds for this workaround?

# re: Update on ASP.NET Vulnerability

Wednesday, September 29, 2010 12:55 PM by Ron Egolf

Scott, I applied your workaround to my IIS servers and seem to have broken more than i fixed.  Legitimate files are getting blocked. Any ideas?  

# re: Update on ASP.NET Vulnerability

Thursday, September 30, 2010 3:29 PM by regolf

I applied your patch(s) to a hosted server running .PHP apps (Moodle, Joomla, WordPress) for about 20 hosted clients.  The phone is ringing .,... it seems extensions. .img, .pdf, .docx, .doc, .rtf are all getting 404 errors.  I have tried to retrace my steps to remove the patches, but am missing something.  any suggestions???

# re: Update on ASP.NET Vulnerability

Thursday, September 30, 2010 3:43 PM by regolf

I removed web.config file I had created and placed in my microsoft.net\framwork\v1.1.4322\CONFIG folder... My extensions not opening issue resolved itself immediately after IISRESET.  

What did i neglect to do?  

# re: Update on ASP.NET Vulnerability

Monday, October 4, 2010 12:52 PM by J.

Hi,

I did ask a question on how to rebuild the machine key if a potential hack was present. I want to do this out of precaution. Now it seems this comment is not logged here or removed. I find that very weird.

Could you please help me with this? In particular now it turns out that the DNN site has been potentially compromised:  This site is offline for routine maintenance; we apologize for any inconvenience.  

DotNetNuke.com Maintenance Report – 10/4/2010

On Friday October 1, while performing a routine review of our server logs we discovered evidence that would lead us to believe that a user may have exploited the Oracle Padding vulnerability on DotNetNuke.com to elevate permissions on their account and gain host access.  Having identified the intrusion we took immediate steps to take the site offline for the weekend so we could further harden our infrastructure as well as assess the full extent of the intrusion and make the needed changes to get the site back up and operating.

Since the Oracle Padding vulnerability allows a user to compromise the Machinekey for the website, which is used as part of encrypting user’s passwords, we knew that we would need to change the MachineKey value.  While this sounds simple, it actually turned out to be a much larger task than initially anticipated.  Over the weekend, DotNetNuke engineers worked to develop a tool to extract all of the existing users passwords and re-encrypt them using the new machine key and password salt.  Unfortunately due to the number of user accounts on DotNetNuke.com, this process was not able to finish running by the end of the weekend.

Based on the current processing speed and the remaining accounts to be processed we anticipate being back online later today.

# re: Update on ASP.NET Vulnerability

Monday, October 4, 2010 12:56 PM by Jelle Ossewaarde

Hi,

I asked advice on how to change the Machine key if a potential hack is suspected. Since Friday it seems the famous DNN website it out of service. Seems they have been compromised. We want to change our machine key also. How can be encrypt the salted data again? Please advice.

J.

# re: Update on ASP.NET Vulnerability

Tuesday, October 5, 2010 11:56 AM by kakalin

Great post, I had already blocked many of my visits but didn’t realize how many features that had! Thanks.

# re: Update on ASP.NET Vulnerability

Friday, October 8, 2010 11:36 AM by Lloyd McFarlin

For the most part, UrlScan breaks SharePoint with it's default configuration.  You should enable the verb "OPTIONS" and header "Translate" after installing UrlScan.  Otherwise, SharePoint will lose it's ability to allow users to edit library documents in Office.

# re: Update on ASP.NET Vulnerability

Monday, October 11, 2010 11:17 AM by Ameen

We installed the below patches in our production environment,

KB2416451 – Microsoft .NET Framework 1.1 Service Pack 1

KB2418241 - Microsoft .NET Framework 2.0 Service Pack 2 and Microsoft .NET Framework 3.5 Service Pack 1

KB2416473 - Microsoft .NET Framework 3.5 Service Pack 1

After installing we found one of our application broke, so we want to uninstall these patches and include the workaroud provided.

However we have a WCF services in our web server, do we need to have CustomErrors tag for the WCF services as well?

Can anybody answer?

# re: Update on ASP.NET Vulnerability

Monday, October 11, 2010 1:59 PM by ScottGu

@Ammen,

Can you send me email (scottgu@microsoft.com) with details of the issue?  I can then loop you in with someone who can help.

Thanks,

Scott

# re: Update on ASP.NET Vulnerability

Tuesday, October 12, 2010 9:48 AM by Mehrdad

Is it nessesary to install URLScan on a developing server too? These are the server that publish their contents on the production?