Summary:
- These vulnerabilities affect: All versions of Microsoft’s .NET Framework
- How an attacker exploits it: Multiple ways, including sending specially crafted web requests or enticing users to click maliciously crafted links
- Impact: Various. In the worst case, an attacker can log in to your web application as another user, without having that user’s password
- What to do: Install the proper .NET Framework update immediately, or let Windows Update do it for you.
Exposure:
Last week — following the holiday weekend — Microsoft released a blog post and Security Advisory about a new, publicly disclosed ASP.NET Denial of Service (DoS) vulnerability.
A few days later, they released an out-of-cycle Security Bulletin fixing that .NET Framework vulnerability, and three others. Whether you manage a public web server with ASP.NET applications, or host such .NET applications internally, we highly recommend you download, test, and deploy the appropriate .NET Framework updates as soon as possible.
Microsoft’s out-of-cycle .NET Framework security bulletin describes four vulnerabilities, including the publicly disclosed DoS vulnerability mentioned above. The vulnerabilities have different scopes and impacts. I detail two of the more relevant issues below, in order of severity:
- ASP.NET Forms Authentication Bypass Flaw – ASP.NET doesn’t properly authenticate specially crafted usernames. If an attacker has (or can create) an account on your ASP.NET application, and knows the username of a victim, the attacker can send a specially crafted authentication request that gives him access to the victim’s account without needing a valid password. However, your ASP.NET web site or application is only vulnerable to this when you’ve enabled “Forms Authentication.”
- ASP.NET HashTable Collision DoS Vulnerability – Without going into great technical detail, ASP.NET suffers from a flaw involving the way it hashes specially crafted requests. In short, by sending specially crafted ASP.NET requests to you web application, an attacker can fill ASP.NET’s hash table with colliding hashes, which can greatly degrade the performance of your ASP.NET application or web site. If you are technically inclined, and would like more details, we recommend reading n.run’s advisory concerning this flaw.
Solution Path:
Microsoft has released .NET Framework updates to fix these vulnerabilitie. If you have web servers or clients that use the .NET Framework, you should download, test and deploy the corresponding updates immediately.
Due to the exhaustive and varied nature of .NET Framework installations (1.1, 2.0, 3.5.x, and 4.0 running on many Windows platforms), we will not include links to all the updates here. We recommend you visit the “Affected and Non-Affected Software” section of Microsoft’s bulletin for those details.
If possible, we also recommend you use Windows Update to automatically download and install the appropriate .NET Framework on client computers. That said, you may still want to keep production servers on a manual update process, to avoid upgrade-related problems that could affect business-critical machines.
For All Users:
This attack typically leverages normal looking HTTP requests, which you must allow for users to reach your web application. Therefore, Microsoft’s patches are your primary recourse.
Status:
Microsoft has released updates to correct this vulnerability.
References:
- Microsoft Security Bulletin MS11-100
- Microsoft Security Advisory
- Microsoft Security Blog Post
- Technical Write-up on ASP.NET Hash Table DoS Flaw
This alert was researched and written by Corey Nachreiner, CISSP.
If we have IPS enabled, are we protected?
Jake,
That is a great and very valid question.
We outsource our IPS signatures to a best-in-class IPS vendor. The pros to doing this are that we get rapid, high-quality signatures that have great catch rates in our tests (we use some industry-standard IPS testing equipment to validate all our signatures). The con is… since we don’t manage the signature library, I’m limited in the tools I have locally to search signatures. We have our security portal:
(http://www.watchguard.com/SecurityPortal/ThreatDB.aspx)
However, its search is based on rule ID and name, it doesn’t search the other signature fields. Thus, a search for MS11-xxx, won’t have hits, even though we have many signatures for many MS bulletins last year.
So at this point, I am unsure if we have a MS11-100 signature yet. We have already opened a ticket with our partner though for this signature. If we don’t already have one, they well create one very quickly (their turn around was been very quick for our requests). Anecdotally, I can tell you when I’ve pointed out other zero day Microsoft exploits in the past (which had exploit code), our partner had created signatures for them almost immediately, and had tested the signatures and added them to our database within days.