Security Research & Defense

Information from Microsoft about vulnerabilities, mitigations and workarounds, active attacks, security research, tools and guidance

December, 2011

  • ASP.NET security update is live!

    Today we released MS11-100, addressing a newly disclosed denial-of-service vulnerability affecting several vendors’ Web application platforms, including Microsoft’s ASP.NET. Yesterday, we posted an SRD blog describing the vulnerability and the detection and workaround opportunities. With this blog post, we’d like to update you on the following topics:

    • Why is this bulletin rated “Critical” for a Denial-of-Service vulnerability?
    • Signature progress from protection partners
    • Updated snort rules
    • Thanks to the ASP.NET team for holiday heroics

    Why is this bulletin rated “Critical” for a Denial-of-Service vulnerability?

    Yesterday evening, we published an Advanced Notification alerting customers to a new out-of-band security update planned to be released today. The notification listed the update as addressing a Critical Elevation-of-Privilege vulnerability, leading to several questions from customers who expected the bulletin addressing a Denial-of-Service vulnerability to be rated Important.

    Before hearing about this vulnerability, we had planned to release a .NET security update addressing three vulnerabilities, one of which was a Critical elevation-of-privilege vulnerability. When this vulnerability notification arrived a few weeks ago, the ASP.NET team included the fix into the update already being developed and tested. So the bulletin today addresses four vulnerabilities, one of which is the ASP.NET Denial-of-Service vulnerability presented yesterday. You can read more about the other vulnerabilities in the Security Bulletin and we also invite you to join us for a webcast at 1:00 p.m. PST today (Dec 29) where we will describe the vulnerabilities and answer your questions live “on the air.” You can sign up for the webcast here.

    Signature progress from protection partners

    We have been working with our MAPP partners, answering questions and providing additional guidance. We are seeing early progress toward signatures, one of which being our own MMPC team having released a signature for the Forefront Threat Management gateway (TMG). The MMPC signature page is at http://www.microsoft.com/security/portal/Threat/Encyclopedia/NIS.aspx?threat=Vulnerability-Win-ASPNET-POST-DoS-CVE-2011-3414. We have also heard from partners about the progress they are making and are looking forwarding to seeing additional signatures this week. It’s exciting to see this information sharing mechanism working!

    As we mentioned earlier, Web application servers from several vendors are affected by this same vulnerability. The “nice” thing about these kind of industry-wide issues is that our detection logic sent out to the MAPP partners results in protection for not just the Microsoft issue but for attacks targeting any affected platform.

    Updated Snort rules

    Sourcefire, while developing their IDS/IPS signature, has been kind enough to share their Snort rule with us and has given us permission both to use it in protecting Microsoft’s properties and also to share with customers. While the Snort rules we provided in the blog yesterday were effective in detecting the issue, Sourcefire's rules are more efficient. The first signature from yesterday would operate very rapidly, but the second – which had no static content match – would enter on every single TCP packet passing through the IDS. While it would exit rapidly in most cases due to the flowbit, the overhead from that would stack up and if the PCRE runs into a form post that sends 20+ parameters, the PCRE would start crunching away on the CPU quite rapidly. Thanks, Sourcefire team, for your help!

    To that extent, here are two updated Snort rules:

    alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (msg:"DOS generic web server hashing collision attack"; flow:established,to_server; content:"Content-Type|3A| application|2F|x-www-form-urlencoded"; nocase; http_header; pcre:"/([^=]+=[^&]*&){500}/OP"; reference:cve,2011-3414; reference:url,events.ccc.de/congress/2011/Fahrplan/events/4680.en.html; reference:url,technet.microsoft.com/en-us/security/advisory/2659883; classtype:attempted-dos; sid:20823; rev:1;)

    alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (msg:"DOS generic web server hashing collision attack"; flow:established,to_server; content:"Content-Type|3A| multipart/form-data"; nocase; http_header; pcre:"/(\r\nContent-Disposition\x3a\s+form-data\x3b[^\r\n]+\r\n\r\n.+?){500}/OPsmi"; reference:cve,2011-3414; reference:url,events.ccc.de/congress/2011/Fahrplan/events/4680.en.html; reference:url,technet.microsoft.com/en-us/security/advisory/2659883; classtype:attempted-dos; sid:20824; rev:1;)

    This first rule covers the x-www-form-urlencoded use case in a single rule, instead of using flowbits, because the stream reassembler and http_inspect will put the entire request together, and allows you to view it as a single logical packet. That eliminates the concern about a rule without a content match, and means that it should be reasonably fast. Also, this changes the number of parameters necessary to trigger an alert down to 500, because a) that should have virtually no false positives in the wild anyway, and b) the fewer parameters the PCRE needs to count out, the faster the rule will be. The second rule covers the multipart/form-data use case.

    Additional acknowledgement

    The ASP.NET team has worked straight through the past several weeks to make this short turnaround release possible – building, packaging, and testing this security update in order to release packages in such a short time so we could protect customers as quickly as possible.

    Yesterday’s SRD blog mentioned a few of the team members but missed several others. With apologies to the team members who didn’t get mentioned and at the risk of forgetting others, here are the key ASP.NET engineers who made this compressed schedule possible: Anand Paranjape, Pranav Rastogi, Jim Wang, Clay Compton, Matt Fei, Hong Li, Carl Dacosta, Amit Apple, Drago Draganov, Konst Khurin, Levi Broderick, Miguel Lacouture-Amaya, Jason Pang, Jim Carley, Jon Cole, Mike Harder, Zhenlan Wang, Dmitry Robsman, Jeffrey Cooperstein, Nazim Lala, Qing Ye, Reid Borsuk, Jamshed Damkewala, Christy Henriksson, Jose Reyes, William Mitchell, Darla Hershberger, Sophy Wang, and Ashutosh Kumar. Thanks, all of you and others behind the scenes for your work to get this package out in such a short time!

    Dec 29 update:  Updated Snort rule with more efficient pcre from Sourcefire team.  Previously "/([\w\x25]+=[\w\x25]*&){500}/OPsmi".  Now "/([^=]+=[^&]*&){500}/OP".  Should be ~10x faster.  Thanks Caleb Jaren from the Microsoft Network Security Analysis & Monitoring team for testing it.

    - Jonathan Ness, MSRC Engineering

  • More information about the December 2011 ASP.Net vulnerability

    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:

    <configuration>
    <system.web>
    <httpRuntime maxRequestLength="200"/>
    </system.web>
    </configuration>

    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:

    <configuration>
    <system.web>
    <httpRuntime maxRequestLength="20"/>
    </system.web>
    </configuration>

    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

  • Assessing the risk of the December 2011 security updates

    Today we released thirteen security bulletins. Three have a maximum severity rating of Critical with the other ten having a maximum severity rating of Important. We hope that the table below helps you prioritize the deployment of the updates appropriately for your environment.

    Bulletin Most likely attack vector Max Bulletin Severity Max Exploit-Ability Index Likely first 30 days impact Platform mitigations and key notes
    MS11-087

    (TTF Font parsing)
    Victim opens a malicious Office document or browses to a malicious website. Critical 1 Attacks seen in the wild have exploited this vulnerability to install Duqu malware.

    Browser-based attack vector more difficult to both trigger and exploit than the Office document attack vector. Successful exploitation results in code running as SYSTEM.

    See this SRD blog post for more information about attack vectors and workarounds.

    MS11-092

    (Windows Media)
    Victim browses to a malicious website that offers malformed DVR-MS media file. Critical 1 Victim browses to a malicious website that offers malformed DVR-MS media file.  
    MS11-090

    (Killbits)
    Victim browses with IE6 to a malicious website. Critical 1

    (IE6 only)
    Likely to see exploit code developed for IE6 in next 30 days.

    IE7 and later have disabled this particular binary behavior already. 

    See this SRD blog post for more information about this binary behavior and why we are disabling it via a killbit security update.

    MS11-089

    (Office)
    Victim opens a malicious DOCX file. Important 1 Likely to see exploit code developed in next 30 days. Affects new Open XML-based file format. Therefore FileBlock and MOICE are not valid workarounds.
    MS11-096

    (Excel)
    Victim opens a malicious XLS file. Important 1 Likely to see exploit code developed in next 30 days.  
    MS11-094

    (PowerPoint)
    Victim opens a malicious PPT file. Important 1 Likely to see exploit code developed for CVE-2011-3396, a DLL preloading issue.  
    MS11-099

    (Internet Explorer)
    None of the issues addressed in this update could result in remote code execution.

    The most likely-to-be-attacked issue could facilitate an XSS attack: victim would browse to a malicious website which may have access to information that the victim would automatically send to a different domain.
    Important 1 Likely to see exploit code developed for CVE-2011-2019, a DLL preloading issue.  
    MS11-095

    (Active Directory)
    Attacker able to authenticate to domain controller sends valid LDAP request. The DC generating the response could potentially allow malicious code to run in the context of LSASS (SYSTEM). Important 1 Likely to see exploit code developed in next 30 days. Not all domain controllers are vulnerable. Attacker can only trigger vulnerability on a DC’s that return a certain sequence of content to an LDAP query.
    MS11-091

    (Publisher)
    Victim opens a malicious PUB file. Important 1 Likely to see exploit code developed in next 30 days for older versions of Publisher. Publisher 2010 not affected.
    MS11-098

    (Kernel)
    Attacker logged-in to a machine locally exploits vulnerability to elevate to a higher privilege level. Important 1 Likely to see exploit code developed in next 30 days.  
    MS11-097

    (CSRSS)
    Attacker logged-in to a machine locally exploits vulnerability to elevate to a higher privilege level. Important 1 Likely to see exploit code developed in next 30 days.  
    MS11-088

    (Office IME)
    Attacker logged-in interactively to a machine exploits vulnerability to elevate to a higher privilege level. Important 1 Likely to see exploit code developed in next 30 days. Only affects systems where Microsoft Pinyin Chinese IME is installed.
    MS11-093

    (OLE32)
    Victim right-clicks on a malicious Office document and chooses to display its Properties. Important 1 Likely to see exploit code developed in next 30 days.  

    Thanks to the entire MSRC Engineering team for the hard work on these cases!!

    - Jonathan Ness, MSRC Engineering

  • More information on the December 2011 ActiveX Kill Bits bulletin (MS11-090)

    This month we released MS11-090 to address a vulnerability in the Microsoft Time component (CVE-2011-3397), which features the deprecated time behavior that is still supported in IE6. We would like to provide further information about this issue and help explain why a “binary behavior kill bit” is the appropriate course of action.

    Which products are affected?

    The vulnerable component was removed from IE7 and later browsers. IE6 is the only supported browser that is affected.

    What is, or was, the time behavior?

    The time behavior is a feature of HTML+TIME 1.0, which was released in IE5. It provides an active timeline for enabling animated content.

    Why is CVE-2011-3397 included in the ActiveX Kill Bits bulletin (MS11-090) instead of in the cumulative IE bulletin (MS11-099)?

    The most appropriate remedy for this issue is to issue a kill bit to disable the deprecated binary behavior.

    What is the binary behavior kill bit?

    Usually, the kill bits we issue are targeted toward disabling specific ActiveX Objects. For example, the following registry key sets a kill bit for an ActiveX object on x86-based systems:

    Windows Registry Editor Version 5.00
    
    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}]
    "Compatibility Flags"=dword:00000400
    

    The binary behavior kill bit is very similar. To set a kill bit for a particular binary behavior, you can use:

    Windows Registry Editor Version 5.00
    
    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}]
    "Compatibility Flags"=dword:04000400
    

    The highlighted bit notifies IE to never load binary behaviors from the specific CLSID. The registry key for x64-based systems is:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\CLSID of the ActiveX control 

    x86 IE:

    HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Internet Explorer\ActiveX Compatibility\CLSID of the ActiveX control

    For more information about the kill bit, please refer to David Ross’s excellent Kill-Bit FAQ Series. It will be updated shortly to discuss the binary behavior kill bit.

    Special thanks to Kwan-Leung Chan and Eric Lawrence on the IE team.

    - Chengyun Chu, MSRC Engineering

  • More information on MS11-087

    Today, we released MS11-087 addressing an issue in the font parsing subsystem of win32k.sys, CVE-2011-3402. The bulletin received a Critical rating due to a potential browser-based attack vector. We have not seen the browser-based attack vector exploited in the wild. The bulletin includes a workaround to disable this remote code execution attack surface. You might consider applying the workaround even after applying security update MS11-087, simply to reduce your attack surface. This blog explains how in more detail.

    Issue Summary

    This vulnerability has been used to drop the Duqu malware. An insufficient bounds check within the font parsing subsystem of win32k.sys could potentially allow a malformed font to corrupt ring0 memory. In the case of the Duqu dropper, a malformed font embedded inside an Office Word document triggered this memory corruption vulnerability to jump to attacker shellcode.

    To be clear, Duqu did not exploit the browser-based attack vector. As far as we know, this vulnerability has only been exploited via a custom font embedded within an Office document. However, attackers could potentially construct a malicious font in such a way that it could be embedded in a webpage. There is an easy workaround to block that particular attack surface.

    Protecting your environment

    The best option for protecting against this particular vulnerability is to apply the MS11-087 security update. It will comprehensively address this issue.

    If you are unable to apply the update right away and/or are concerned primarily about the browser-based attack surface, you might consider simply disabling IE’s ability to download custom fonts entirely. The side effect of this approach is potential display and layout glitches on web pages that leverage custom fonts to display text in interesting new ways. However, the vast majority of web sites use fonts included with Windows or use text layout tricks that do not require this particular custom font technology. Opening a web page that embeds a custom font after you have applied the workaround will cause Internet Explorer to display the text using a built-in font. Below, you can see the user experience of browsing to a webpage that leverages a custom font:

    Figure 1: Webpage using custom, downloaded font

    Figure 2: Same webpage displayed after workaround is applied

    Workaround Steps

    You can disable custom font download in Internet Explorer either interactively (using the GUI) or via Group Policy or a Management Deployment Script across multiple machines.

    - Interactive deployment

    • Launch Internet Explorer
    • On the ‘Tools’ Menu select ‘Internet Options’.
    • Click the ‘Security’ Tab.
    • To change the setting for the ‘Internet’ zone select ‘Internet’ and press the ‘Custom Level’ button.
    • Scroll down to the ‘Downloads’ section and select ‘Prompt’ or ‘Disable’ for the ‘Font Download’ security setting.
    • Press OK to close the ‘Security Settings’ dialog box.
    • Press OK to close the ‘Internet Options’ dialog box.

    - Group Policy deployment

    NOTE: The Group Policy MMC snap-in can be used to set policy for a machine, for an organizational unit or an entire domain. It is assumed that the reader will know how to deploy the steps below for their particular environment.

    • · Open the group policy management and configure it to work with the appropriate group policy object (i.e. local machine, OU or domain GPO).
    • · Navigate to the following node:
      • o User Configuration -> Windows Settings -> Internet Explorer Maintenance -> Security.
    • · Double click ‘Security Zones and Content Rating’.
    • · On the ‘Security Zones and Content Rating’ dialog box select ‘Import the current security zones and privacy settings’ and then click the ‘Modify settings’ button.
    • · NOTE: This will create a group policy for Internet Explorer based on the settings of the currently logged in user.
    • · On the ‘Internet Properties’ dialog box ensure the ‘Internet’ zone is selected and then press ‘custom level’.
    • · Scroll down to ‘Downloads’ and set ‘Font Download’ to ‘Prompt’ or ‘Disable’.
    • · Press OK to return to the ‘Internet Properties’ dialog box.
    • · On the “Internet Properties’ dialog box select the ‘Local Intranet’ zone and then press ‘custom level’.
    • · Scroll down to ‘Downloads’ and set ‘Font Download’ to ‘Prompt’ or ‘Disable’.
    • · Press OK to return to the ‘Internet Properties’ dialog box.
    • · Press OK to return to the ‘Security Zones and Content Ratings’ dialog box.
    • · Press OK to return to the group policy management console.
    • · Refresh the group policy on all machines or wait for the next scheduled group policy refresh interval for the settings to take effect.

    - Managed Deployment Script deployment

    This security setting can be manually entered into the registry by creating a registry script and importing it either by double clicking it or running regedit.exe as part of a logon or machine startup script. For managed deployments Regedit.exe can be used to import a registry script silently with the ‘-s’ switch. For more information on regedit command line switches refer to: http://support.microsoft.com/kb/q82821/

    To set this setting to ‘Prompt’ for the Internet and Local Intranet Zones paste the following text into a .REG file and then import the .REG file on managed machines as part of your organizations managed deployment process:

    Windows Registry Editor Version 5.00
    
    ; Zone 1 is the local intranet zone
    ; 1604 is the Font download policy
    ; dword:00000001 sets the policy to prompt
    [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\1]
    "1604"=dword:00000001
    ; Zone 3 is the internet zone
    [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\3]
    "1604"=dword:00000001
    

    To set this setting to ‘Disable’ for the Internet and Local Intranet Zones paste the following text into a .REG file and then import the .REG file on managed machines as part of your organizations managed deployment process:

    Windows Registry Editor Version 5.00
    
    ; Zone 1 is the local intranet zone
    ; 1604 is the Font download policy
    ; dword:00000003 sets the policy to disable
    [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\1]
    "1604"=dword:00000003
    ; Zone 3 is the internet zone
    [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\3]
    "1604"=dword:00000003
    

    Bottom Line

    We encourage you to first apply the security update to address this particular vulnerability. However, you might consider also blocking the browser-based font attack surface from within Internet Explorer as a good ‘attack surface reduction’ step. The tiny minority of web pages that embed custom fonts may display differently but you will be protected from any potential browser-based attack vectors leveraging custom fonts within Internet Explorer.

    - Chengyun Chu and Jonathan Ness, MSRC Engineering