Today, we released Security Advisory 2659883 alerting customers to a newly disclosed denial-of-service vulnerability affecting several vendors’ web application platforms, including Microsoft’s ASP.NET. This blog post will cover the following:
- Impact of the vulnerability
- How to know if your configuration is vulnerable to denial-of-service
- How to detect the vulnerability being exploited at network layer
- How to detect the vulnerability being exploited on the server
- Background on the workaround to protect your website
Impact of the vulnerability
This vulnerability could allow an anonymous attacker to efficiently consume all CPU resources on a web server, or even on a cluster of web servers. For ASP.NET in particular, a single specially crafted ~100kb HTTP request can consume 100% of one CPU core for between 90 – 110 seconds. An attacker could potentially repeatedly issue such requests, causing performance to degrade significantly enough to cause a denial of service condition for even multi-core servers or clusters of servers.
We anticipate the imminent public release of exploit code. Therefore, we encourage ASP.NET website owners to review the Security Advisory 2659883 and this blog post to evaluate the denial-of-service risk to your web property and to implement the workaround and/or attack detection mechanisms until a security update is available to comprehensively address the issue.
Vulnerable configurations
The root cause of the vulnerability is a computationally expensive hash table insertion mechanism triggered by an HTTP request containing thousands and thousands of form values. Therefore, any ASP.NET website that accepts requests having HTTP content types application/x-www-form-urlencoded or multipart/form-data are likely to be vulnerable. This includes the default configuration of IIS when ASP.NET is enabled and also the majority of real-world ASP.NET websites.
Detecting attacks at the network layer
Microsoft has released detailed detection guidance and code to test signatures to all 80 of our MAPP partners. We expect that the network-based IDS and IPS vendors in the program will build robust detection and protection signatures for this issue. Microsoft’s own Forefront Threat Management Gateway (TMG) will receive an update containing a signature for this issue today. (Vulnerability:Win/ASPNET.POST.DoS!NIS-2011-0001)
Microsoft’s internal network security analysis & monitoring team has developed a snort signature to detect attacks on the wire. They are currently testing it and plan to put it into production to protect Microsoft’s own network. There are two rules:
alert tcp any any -> any $HTTP_PORTS (msg:“Microsoft 2659883 URL Encoded Content flowbit”; flow:established,to_server; content:" application|2F|x|2D|www|2D|form|2D|urlencoded";nocase;http_header;flowbits:set,urlEncodedContentType;flowbits:noalert;classtype:misc-activity; sid:1000019; rev:1;)
alert tcp any any -> any $HTTP_PORTS (msg:“Confirmed Microsoft 2659883 payload”;flow:established,to_server;flowbits:isset,urlEncodedContentType;pcre:"/(\w*(&|=)){1000,}/smi";flowbits:unset,urlEncodedContentType; sid:1000020;rev:1;)
The first rule will check for the content type “application/x-www-form-urlencoded”. If it is present, the rule will set the flowbit “urlEncodedType”. If the urlEncodedType flowbit is set, the second rule will check for 1000 or more form values being sent in the HTTP request. As Microsoft, the other affected vendors, and protection partners continue to investigate this issue, we will likely discover more efficient ways to detect exploits in the wild. Please contact us at switech –at- microsoft dot com with ideas for more efficient detection than the above.
Detecting attacks at the server level
Successful attacks will exhaust server CPU resources. Therefore, you can detect attacks by something as simple as Task Manager on the web server. The screenshot below shows the result of one malicious request against a 4 core machine. Notice that one entire core is dedicated to processing this one request (~25% CPU usage).
More information about the workaround to protect your web properties
The security advisory lists workaround steps to limit the maximum HTTP request size that ASP.NET will accept from clients. Attackers would need to send (relatively) large HTTP requests to exploit the vulnerability. So if your website does not normally need to accept large requests from legitimate users, you can configure ASP.NET to reject all requests larger than a certain size. Note that if your website does need to accept user uploads, this workaround is likely to block legitimate requests. In that case, you should not use this workaround and instead wait for the comprehensive security update.
If your application uses ViewState, we recommend limiting HTTP request size to 200kb. To do so, add the following to your ASP.NET configuration file:
<span style="font-family: 'courier new', courier;"><configuration></span><br><span style="font-family: 'courier new', courier;"> <system.web></span><br><span style="font-family: 'courier new', courier;"> <httpRuntime maxRequestLength="200"/></span><br><span style="font-family: 'courier new', courier;"> </system.web></span><br><span style="font-family: 'courier new', courier;"></configuration></span>
If your application does not use ASP.NET ViewState, we recommend limiting HTTP request size to 20kb. To do so, add the following to your ASP.NET configuration file:
<span style="font-family: 'courier new', courier;"><configuration></span><br><span style="font-family: 'courier new', courier;"> <system.web></span><br><span style="font-family: 'courier new', courier;"> <httpRuntime maxRequestLength="20"/></span><br><span style="font-family: 'courier new', courier;"> </system.web></span><br><span style="font-family: 'courier new', courier;"></configuration></span>
Note that any requests larger than the maxRequestLength will result in a ConfigurationErrorsException thrown server-side and an HTTP error status returned to the client. Therefore, we want to stress that this workaround option will disrupt both legitimate and attack HTTP requests that exceed the request length. Therefore, please thoroughly test this workaround in your environment, focusing on any scenarios that involve uploading files or making large data submissions to the web service.
Non-workaround – URLScan
Microsoft’s URLScan tool often helps mitigate vulnerabilities involving malicious HTTP requests. However, it is not applicable in this particular case because the malicious form values in a successful attack are most likely to be in the body of the HTTP request, not in the URL itself. URLScan does not inspect the request body. Attacks are unlikely to be successful using only the URL (even factoring in cookies, headers, server variables, etc) due to a default 16KB limit for the combined request size excluding the request body. The request body is the only unbounded payload.
Conclusion
Our ASP.NET team is hard at work testing a security update for broad deployment. If you are concerned about the risk of your ASP.NET site being targeted by attackers, please consider implementing the detection and workaround guidance described in this blog post.
Thanks to the ASP.NET team for the hours and hours of work spent over the holiday on this issue - Dmitry Robsman, Jeffrey Cooperstein, Zhenlan Wang, Matt Fei, Nazim Lala, Jamshed Damkewala, Hong Li, Reid Borsuk and others! Thanks Mike Harder for your work investigating different workaround options. Thanks Dave Midturi, David Seidman, Andrew Gross, and Maarten van Horenbeeck for your help in coordination. Thanks Chengyun Chu and Ali Pezeshk for your technical investigation. And finally thanks Caleb Jaren and Abhijeet Hatekar for the snort signature help!
- Suha Can and Jonathan Ness, MSRC Engineering