Today we released seven security bulletins. One has a maximum severity rating of Critical with the other six 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.

- Jonathan Ness, MSRC Engineering

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

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

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.

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

- Jonathan Ness, MSRC Engineering

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

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

This month we released MS11-083 to address an externally found reference counter issue in TCP/IP stack. Here we would like to give further information about the exploitability of this vulnerability.
 
Vulnerability
The vulnerability presents itself in the specific scenario where an attacker can send a large number of specially crafted UDP packets to a random port that does not have a service listening. While processing these network packets it is observed that some used structures are referenced but not dereferenced properly. This unbalanced reference counting could eventually lead to an integer overflow of the reference counter.
  
Effects of reference count wrap around
With the above described vulnerability, when the system is deluged with network packets, the reference counter in the structure will keep incrementing and eventually wrap around.

If a dereference happens just after the counter has wrapped to zero, the structure will be freed. Depending on the timing conditions, four scenarios are possible:
• The memory is still mapped and contains the old data. No crash results and the system works as normal.
• The memory is unmapped and the system crashes when it is referenced. This results in a system denial-of-service.
• The memory is re-allocated for the same structure. No crash results and the system works as normal.
• The memory is re-allocated for a different structure. This could result in a system crash, or if attacker-controlled data is present, could lead to memory corruption or remote code execution.
 
Exploitability 
While the last scenario can theoretically lead to RCE, we believe it is difficult to achieve RCE using this vulnerability considering that the type of network packets required are normally filtered at the perimeter and the small timing window between the release and next access of the structure, and a large number of packets are required to pull off the attack. As a result, we assign an Exploitability Index of "2" for this vulnerability.

Ali Rahbar, Mark Wodrich from MSRC Engineering, Gangadhara Swamy from IDC.

Special thanks to Jeremy Tinder from MSRC.

Today we released eight security bulletins. Two have a maximum severity rating of Critical with the other six 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.

- Jonathan Ness, MSRC Engineering

On January 10^th, Microsoft released MS12-006 in response to a new vulnerability discovered in September in SSL 3.0 and TLS 1.0. Here we would like to give further information about the technique used to exploit this vulnerability and workaround options Microsoft has released if you discover a compatibility issue after installing the update.

Is SSL broken?

Yes and no. Yes means that under certain circumstances, the attacker can decrypt the encrypted SSL traffic. No means that there are significant mitigating factors that would make the attacks difficult or impossible. By default, SSL 3.0 and TLS 1.0 are enabled on Windows operating systems.

What does the update do?

The update modifies the way that the Windows Secure Channel (SChannel) component sends and receives encrypted network packets. This addresses the vulnerability affecting WinHTTP and provides the possibility to enable the protection system-wide. However, in order to be protected from the web-based attack vector through Internet Explorer for this vulnerability, customers must install both MS12-006, and the Cumulative Security Update for Internet Explorer (2618444), MS11-099.

Attack vector

In the advisory, it is mentioned that the vulnerability could allow the attacker to decrypt the SSL 3.0/TLS 1.0 encrypted traffic. While the affected component is a Windows component, the primary vector is to attack the browser’s use of the HTTPS protocol to intercept sensitive information, such as the session cookie of the HTTPS session.

Mitigation

Based on our current investigation, the following are mitigating factors that would make any potential attack via currently known exploit vectors difficult or impossible:

• The HTTPS session must be actively attacked by a man-in-the-middle; simply observing the encrypted traffic is not sufficient.
• The malicious code the attacker uses to decrypt the HTTPS traffic must be injected and run within the user’s browser session.
• The attacker’s malicious code needs to be treated as from the same origin as the HTTPS server in order to it to be allowed to piggyback on an existing HTTPS connection. Most likely it requires the attacker to exploit another vulnerability to bypass the browser’s same origin policy.

Therefore, if the user closes all existing HTTP tabs and untrusted HTTPS tabs, then browses to the trusted HTTPS site, such as the log-in page of hotmail.com in a new browser session, and logs out of that HTTPS session before browsing any other HTTP sites or untrusted HTTPS sites, the user will NOT be at risk for this attack.

Workaround

One workaround we would encourage the web server administrators to do is to give a higher priority for the RC4 Cipher Suite than CBC since the attack only affects cipher suites that use CBC. By giving a higher priority for RC4 on the server, RC4 instead of CBC will be used in the security communication since all of windows clients support RC4, unless put in FIPS compliant configuration. Please refer to this MSDN article to learn how to perform this operation via group policy. It is an effective option for web server administrators using Windows Vista or Windows Server 2008 and later platforms.  We recommend putting TLS_RSA_WITH_RC4_128_SHA as the top of the priority list, as indicated in the following image:

We would also encourage users and web administrators to enable the newer security protocols, such as TLS 1.1, on both the client side and the server side. By default, these are disabled (more below). If the browser and web server both enable TLS 1.1, the HTTPS traffic uses TLS 1.1 protocol instead of SSL 3.0/TLS 1.0, and thus won’t be affected by such attacks. TLS 1.1 protocol is supported in Windows 7 and Windows 2008 R2.

Automated FixIt Options:

Microsoft has released several FixIts to help automate enabling TLS 1.1 and a workaround FixIt to disable the functionality of the update if you find a compatibility issue that you need immediate ability to rollback without uninstalling.

To ENABLE TLS 1.1 for Internet Explorer and other WinINET-based applications running on Windows 7 and Windows Server 2008 R2, please click here: 

To ENABLE TLS 1.1 for server-side components running on Windows 7 and Windows Server 2008 R2, click here: 

If you would like to revert the changes made by these FixIt's, you can find a corresponding DISABLE Fixit for both the client side and server-side changes at http://support.microsoft.com/kb/2588513.

To temporarily DISABLE the security update to confirm a compatibility issue without having to uninstall it, click here: 

To re-enable the security update, click here: 

Why TLS 1.1 is not enabled by default?

The main reason to not enable TLS 1.1 by default is due to compatibility problems. We need more servers to implement HTTPS protocols correctly so we can enable TLS 1.1 by default in the client in the future versions of IE. We will work hard to drive adoption of TLS 1.1 or TLS 1.2 as an industry-wide effort.

Special thanks to Nasko Oskov and Eric Lawrence.

Update Sep 27 - Mitigating factors list applies to all currently known attack vectors.  Thanks for the suggestion to clarify, Juliano.

Update Mar 14, 2012– Renaming to reflect release of MS12-006 and adding links for additional FixIt items. Special thanks to Kevin Ledman. 

- Chengyun Chu, Jonathan Ness and Mark Wodrich from MSRC Engineering

Last week, we released Security Advisory 2607712, notifying customers that fraudulent digital certificates had been issued by certificate authority DigiNotar. We’d like to follow up on that notification in this blog post by explaining more about the potential risks and actions you can take to protect yourself from any potential attacks that would leverage those fraudulent certificates.

• Scope of the risk
• Vulnerable configurations
• What Microsoft is doing to protect you
• What you can do to protect yourself
• Additional protections built-in to Windows Update

Scope of the risk

Digital certificates issued by a trusted Certificate Authority (CA) establish the identity of a computer. Protocols that assure your privacy, such as SSL (HTTPS) and TLS, leverage a server’s digital certificate to ensure that no third party can eavesdrop on or tamper with conversations between a client and the server. Clients and servers establish their identity via a digital certificate. Clients make a decision to trust the identity of the server because they trust that a CA verifies the legitimacy of the person or company requesting the certificate. If a trusted CA were to be compromised or tricked into issuing fraudulent certificates, a malicious attacker could potentially request and be granted a digital certificate that would allow the attacker to participate in HTTPS conversations, snooping on or tampering with the contents.

For an attack to be successful, an attacker must have been issued a digital certificate for the server or domain to which the client is initiating a connection. Also, the attacker must be able to tamper with the conversation in progress. Practically speaking, this tampering can happen in one of three ways:

• The attacker is on your local network (open wireless network, for example);
• The attacker owns or operates the network infrastructure between the victim client and the listening server; or
• The attacker controls the DNS server used by your ISP, or can influence your choice of DNS server via DHCP responses if a client gets DNS settings via DHCP.

Without this type of “man-in-the-middle” access, an attacker would be unlikely to be successful in carrying out an attack.

In this particular case, we were originally aware of fraudulent certificates issued by DigiNotar for *.google.com and have since become aware of fraudulent certificates issued for *.microsoft.com, *.windowsupdate.com, www.update.microsoft.com, and a number of other domains for which conversation privacy is extremely important. Windows Update is a special case addressed later in the blog; however, suffice it to say that if the attacker had one of those certificates and had man-in-the-middle access to your network traffic, they could potentially snoop on (or change the contents of) conversations between you and any of those domains.

Vulnerable configurations

All versions of Windows are affected by this attack. However, when a user initiates an HTTPS SSL connection via Internet Explorer on Windows Vista, Windows 7, or Windows Server 2008 and encounters a new root certificate, the Windows certificate chain verification software checks a list of valid root certificates, which is hosted on Windows Update. As of August 29th, this Certificate Trust List (CTL) on Windows Update has been revised to remove DigiNotar from the list of trusted Certificate Authorities so that any certificates issued by DigiNotar are no longer trusted for HTTPS conversations.

Windows XP and Windows Server 2003 do not have the same Windows Update check mechanism. Instead, these versions of Windows rely on a static list of trusted root certificate authorities. This list is updated through the non-security update “Update for Root Certificates (KB 931125)”. DigiNotar was not initially included as a trusted root certificate in Windows XP, so if you have never installed this update, you are not vulnerable to any certificates issued by them.

However, any Windows XP or Windows Server 2003 system that installed this update as of November 2008 or later would have DigiNotar added as a trusted root certificate. Administrators of these systems can follow the steps in the “What you can do to protect yourself” section below to take proactive actions to remove DigiNotar as a trusted root Certificate Authority until Microsoft releases an update that fully addresses this problem.

Windows Phone devices are unaffected. No Windows Mobile devices have a DigiNotar certificate in the Trusted Root Certificate Store.

What Microsoft is doing to protect you on Windows Vista and later platforms

Microsoft has updated the Certificate Trust List (CTL) hosted on Windows Update to remove DigiNotar as a trusted root Certificate Authority. Attacks targeting Internet Explorer users on Windows Vista and later platforms any time after August 29th will likely fail. However, we should note that systems having previously encountered DigiNotar certificates may have cached DigiNotar as a trusted root Certificate Authority. This cached list is updated client-side every seven days. Therefore, the last date on which any attack targeting Internet Explorer users on Windows Vista and later platforms might possibly be successful is September 5th.

What Microsoft is doing to protect you on Windows XP and Windows Server 2003

We are currently preparing an update for Windows XP and Windows Server 2003 platforms which will add DigiNotar to our Untrusted Certificate Store. This update will be available soon.

What you can do to protect yourself

First, as indicated in the security advisory, we recommend keeping Microsoft software updated. If you’re able to do so, opt into Automatic Updates to automatically get the Windows XP and Windows Server 2003 updates when they become available.

Second, you can choose to delete the DigiNotar root from the root store manually. You might consider doing this if you believe the risk to your network or system is urgent and you would like to take action before the Windows XP and Windows Server 2003 update becomes available. After doing this, you’ll also need to clear the local cache. The steps for both removing the DigiNotar root from the trusted root CA store and clearing the cache are listed below.

Step 1: Remove the DigiNotar Root from the trusted root CA store

• Click Start, click Start Search, type mmc, and then press ENTER.
• On the File menu, click Add/Remove Snap-in
• Under Available snap-ins, click Certificates, and then click Add
• Under This snap-in will always manage certificates for, click Computer account, and then click Next
• Click Local computer, and click Finish
• If you have no more snap-ins to add to the console, click OK
• In the console tree, double-click Certificates
• Double-click the Trusted Root Certification Authorities store and click on Certificates to view all certificates in the store
• Select the two DigiNotar Root CA certificates. You can confirm the right certificates by checking their thumbprints which should be “c0 60 ed 44 cb d8 81 bd 0e f8 6c 0b a2 87 dd cf 81 67 47 8c” and “43 d9 bc b5 68 e0 39 d0 73 a7 4a 71 d8 51 1f 74 76 08 9c c3”
• Right-click the certificates and select Delete

To perform the above steps from the command-line, you can use the certutil.exe tools as follows:

• certutil -delstore authroot “c0 60 ed 44 cb d8 81 bd 0e f8 6c 0b a2 87 dd cf 81 67 47 8c”
• certutil -delstore authroot “43 d9 bc b5 68 e0 39 d0 73 a7 4a 71 d8 51 1f 74 76 08 9c c3”

If you distribute roots in your enterprise using group policy, follow the instructions to remove a root across an enterprise network via group policy - http://technet.microsoft.com/en-us/library/cc786148(WS.10).aspx. In step 3 of those group policy instructions, choose the root CA in question here - DigiNotar Root CAs with thumbprints "c0 60 ed 44 cb d8 81 bd 0e f8 6c 0b a2 87 dd cf 81 67 47 8c" and "43 d9 bc b5 68 e0 39 d0 73 a7 4a 71 d8 51 1f 74 76 08 9c c3".

Step 2: Clear the cache to remove any older cached CTL

The simplest way to do so is to use “certutil –urlcache * delete”. This will clean up the cache for the current user. You can find further documentation on this step, including a Microsoft Fix It package to clean up the cache, at http://support.microsoft.com/kb/2328240

--

As indicated above, most customers on Windows Vista and later platforms are already protected due to the updated Certificate Trust List on Windows Update, which is checked when Windows encounters a new root Certificate Authority. To ensure that DigiNotar has not been cached locally as a trusted root CA, you can clear the local cached CTL as explained above. A fresh CTL will automatically be downloaded the next time Windows encounters a new root CA.

There is one final edge case to consider that will not be automatically protected:

• If you are an enterprise customer having Windows Vista and later workstations; and
• If you have disabled the auto root update mechanism via the group policy option; and
• If you have manually added DigiNotar as a trusted root authority –

  Then you likely will want to add the DigiNotar roots to the Untrusted Certificate Store via group policy.

Additional protections built-in to Windows Update

Attackers are not able to leverage a fraudulent Windows Update certificate to install malware via the Windows Update servers. The Windows Update client will only install binary payloads signed by the actual Microsoft root CA certificate, which is issued and secured by Microsoft. Also, Windows Update itself is not at risk, even to an attacker with a fraudulent certificate.

Thanks to Yogesh Mehta, Shain Wray, Charles Anthe, and Mark Wodrich for the help with this blog post.

Updated Sept 5:  Added certutil.exe command line example.  Thanks Uwe Wizovsky for the tip.

- Jonathan Ness, MSRC Engineering