Security Research & Defense

Announcing the release of the Enhanced Mitigation Evaluation Toolkit

swiblog — Tue, 27 Oct 2009 16:21:00 GMT

Even as you read this, people around the world are hunting for vulnerabilities in software applications. Odds are some of them will be successful. Depending on their motives and what they find, your software and systems may be put at risk. So how do you protect your software from unknown vulnerabilities that may or may not exist? One option is to use security mitigations.

Microsoft offers a number of different mitigation technologies that are designed to make it more difficult for an attacker to exploit vulnerabilities in a given piece of software. Take a look at Michael Howard’s article “Protecting Your Code with Visual C++ Defenses” (http://msdn.microsoft.com/en-us/magazine/cc337897.aspx) for a brief overview of some of these technologies.

To help on this front, we are announcing the initial release of a new utility called the Enhanced Mitigation Evaluation Toolkit (EMET). Version 1.0.2 is now available, free of charge at the Microsoft Download Center (http://go.microsoft.com/fwlink/?LinkID=162309). This utility builds on our current offerings in several key ways:

1. Until now, many of the available mitigations have required for an application to be manually opted in and recompiled. EMET changes this by allowing a user to opt in applications via a simple command-line utility without recompilation. This is especially handy for deploying mitigations on software that was written before the mitigations were available and when source code is not available.

2. EMET provides a higher degree of granularity by allowing mitigations to be applied on a per process basis. There is no need to enable an entire product or suite of applications. This is helpful in situations where a process is not compatible with a particular mitigation technology. When that happens, a user can simply turn EMET off for that process.

3. Mitigations that have previously been limited to up-level versions of Microsoft Windows now ship with EMET and are available down-level. Users can benefit from these mitigations without the need to upgrade their systems.

4. EMET is a living tool designed to be updated as new mitigation technologies become available. This provides a chance for users to try out and benefit from mitigations before they are included in the next versions of our products. It also gives users the opportunity to provide feedback and help guide the future of mitigation technologies in Microsoft products.

Supported Mitigations

This initial release of EMET is primarily focused on providing an extensible framework that will have future mitigations added to it. A total of four mitigations are also being included with this release and are listed below. We will provide announcements as future mitigations are added. If you have ideas about mitigations you’d like to see (whether they already exist or not) feel free to contact us.

SEHOP

This mitigation performs Structured Exception Handling (SEH) chain validation and breaks SEH overwrite exploitation techniques. Take a look at the following SRD blog post for more information: http://blogs.technet.com/srd/archive/2009/02/02/preventing-the-exploitation-of-seh-overwrites-with-sehop.aspx. With this protection in place, the msvidctl exploit we already blogged about (http://blogs.technet.com/srd/archive/2009/07/28/msvidctl-ms09-032-and-the-atl-vulnerability.aspx) would have failed.

Dynamic DEP

Data Execution Prevention (DEP) is a memory protection mitigation that marks portions of a process’ memory non-executable. This makes it more difficult to an attacker to exploit memory corruption vulnerabilities. For more information on what DEP is and how it works, take a look at the two part SRD blog available at http://blogs.technet.com/srd/archive/2009/06/12/understanding-dep-as-a-mitigation-technology-part-1.aspx and http://blogs.technet.com/srd/archive/2009/06/12/understanding-dep-as-a-mitigation-technology-part-2.aspx.

NULL page allocation

This blocks attackers from being able to take advantage of NULL dereferences in user mode. It functions by allocating the first page of memory before the program starts. Right now the exploitation techniques for these types of vulnerabilities are only theoretical. However, this mitigation will protect you even if that changes. Please note this protection does not impact kernel mode NULL dereferences as the current version of EMET only supports user mode mitigations.

Heap spray allocation

Heap spraying is an attack technique that involves filling a process’ heap with specially crafted content (typically including shellcode) to aid in exploitation. Right now, many attackers rely on their content being placed at a common set of memory addresses.

This mitigation is designed to pre-allocate those memory addresses and thus block these common attacks. Please note that it only aims to break current exploit that take advantage of these common addresses. It is not a general mitigation for the larger heap spraying attack. That said, if attackers do change the addresses they use, EMET users can change the addresses

A Note about Application Compatibility

Security mitigations carry an application compatibility risk with them. Some applications rely on precisely the behavior that the mitigations block. For this reason mitigations are typically turned off by default and require opt-in from a developer before they are enabled. While EMET allows users to override this, it is important to be aware of the risk. EMET is intended for tech savvy users such as IT professionals and security researchers who can troubleshoot issues that these mitigations may introduce. We also recommend testing your applications and use scenarios with these mitigations prior to deploying them on any production systems.

Feedback

We encourage you to download and try out the tool. If you have any feedback on your experiences with the tool, you can reach us at switech@microsoft.com .

Special thanks to Matt Miller for his assistance with EMET.

- Fermin J. Serna and Andrew Roths, MSRC Engineering

Assessing the risk of the October security bulletins

swiblog — Mon, 12 Oct 2009 17:05:00 GMT

This morning we released 13 security bulletins, our largest release of 2009. Altogether, these bulletins address 34 separate CVEs. We’d like to use this blog post to help you prioritize your deployment of the updates.

Prioritization Criteria

We’ve provided a prioritized list of bulletins in the table below. The prioritization is based on the following criteria:

1. The bulletins are grouped and sorted according to severity and the exploitability.

2. Within each group we prioritize the bulletins with publicly available exploit code ahead of the others.

3. After that we list bulletins where technical details of the vulnerability have been widely discussed, even if no exploit is publicly available.

4. Finally, we take into account platform mitigations that impact the reliability of exploits.

Prioritization Table

Bulletin	Most Likely Attack Vector	Bulletin Severity	Max Exploit-ability Index	Likely first 30 days Impact	Platform mitigations
MS09-051 (Speech codec)	Browsing to a malicious website or ASF (WMA, WMV) attached to email.	Critical	1	We have reports from partners of limited attacks in-the-wild.
MS09-050 (SMBv2)	Attacker initiates a network connection to a vulnerable workstation or server. This would most likely be an attacker on the local subnet as SMB is typically blocked by edge firewalls.	Critical	1	We are aware of reliable working exploit code distributed to limited number of customers. We are also aware of unreliable exploit code available publicly. We have not, however, heard of customers being exploited by this vulnerability. We expect working reliable exploit code to be made public within the next 30 days.	Windows Vista not affected in ‘Public’ network profile
MS09-054 (IE)	Browse to a malicious website.	Critical	1	One of the vulnerabilities addressed was presented publicly at BlackHat. We are not aware of any active exploits for these issues at time of release; however, we expect reliable exploit code to be made public within the next 30 days.	Windows Server 2003, 2008 and 2008 R2 at reduced risk due to Enhanced Security Configuration.
MS09-061 (.NET)	Browse to a website hosting a malicious .NET application that runs in the browser.	Critical	1	One of the vulnerabilities was posted on a public forum. However, we are not aware of any working exploits for the issue or customers who have been impacted. We expect reliable exploit code to be made public within the next 30 days.	Windows Server 2003, 2008 and 2008 R2 at reduced risk due to Enhanced Security Configuration.
MS09-062 (GDI+)	Browse to a malicious website or click on an image attached to an email	Critical	1	All vulnerabilities addressed have been responsibly disclosed. We expect reliable exploit code to be made public within the next 30 days.	Windows Server 2003 and 2008 at reduced risk due to Enhanced Security Configuration.
MS09-052 (WMP)	Browsing to a malicious website or ASF (WMA, WMV) attached to email.	Critical	1	This vulnerability was responsibly disclosed. We expect attackers could develop a reliable exploit; however, only systems with Windows Media Player 6.4 are vulnerable. Therefore, the likelihood of attackers choosing to write exploits for this vulnerability is lower.
MS09-055, MS09-060 (ActiveX, Office ATL)	Browsing to a malicious website that instantiates an ActiveX control in a malicious manner.	Critical	1	So far, the only ATL-related vulnerability that has been exploited in the real world is msvidctl.dll, addressed by MS09-032. No other ATL vulnerabilities have been exploited. We expect the IE defense-in-depth mitigation combined with the difficulty building custom ATL streams to make these vulnerabilities less likely to be exploited.
MS09-057 (query.dll)	Browsing to a website that scripts an ActiveX control in a malicious manner.	Important	2	This vulnerability was responsibly disclosed. This one is less likely to see a working reliable exploit made publicly available due to the nature of the vulnerability.
MS09-053 (IIS)	An FTP server would need to grant untrusted users access to log into and create a specially-crafted directory. If an attacker were able to successfully exploit this vulnerability, they could execute code in the context of LocalSystem, the service under which the FTP service runs. IIS5 & IIS6 are impacted.	Important	1	Public exploits are available for this issue.	Internet Information Services 6.0 on Windows Server 2003 is at reduced risk because it was compiled using the /GS compiler option.
MS09-059 (LSASS)	Attacker initiates a network connection to a vulnerable workstation or server. LSASS crashes and forces the machine to reboot.	Important	3	This issue was responsibly disclosed. The impact of this vulnerability is denial-of-service only.
MS09-058 (Kernel)	An unprivileged user with logon rights and ability to run arbitrary executables can compromise a system locally.	Important	2	We rarely see exploits developed for local elevation of privilege vulnerabilities within the first 30 days after release.
MS09-056 (x.509)	Spoofing threat	Important	3	Attack details are public but code execution is not possible. We have seen limited exploitation of the spoofing threat.

It is important to factor in your organization’s potential attack surface when deciding in which order to apply the updates. For example, if you grant FTP access to untrusted users, MS09-053 might be the most critical security update for you despite its “Important” rating. If your organization does not have Windows Vista or Windows Server 2008 systems, MS09-050 is less relevant for you because SMBv2 is not supported on earlier systems.

SRD Blog Posts This Month

In addition to this we’ve written several blog entries to help you understand the vulnerabilities more deeply and help you make a more informed risk analysis as you prepare to deploy these updates. Here are the topics covered:

MS09-051: Chen describes how you can know whether a system is vulnerable to this Windows Media Player issue, how the codec download behavior works, and what you can do to protect vulnerable systems. [link]

MS09-050: Mark walks through the history of the exploit landscape for the publicly disclosed SMB remote code execution vulnerability to help you understand the risk to your environment. [link]

MS09-054: Chen explains why there is a FireFox attack vector for this Internet Explorer bulletin, and how you can disable this attack surface if you choose to do so. [link]

MS09-061: Kevin lists the attack vectors for this .NET security bulletin and the various workaround options available. He also explains why we recommend disabling partially-trusted .Net applications and not fully-trusted .NET applications. [link]

MS09-062: Kevin discusses the “kill switches” for GDI+ image format parsers. He shows how you can permanently disable the parsing of, say, TIFF files as a defense-in-depth measure or in response to an unpatched vulnerability. [link]

MS09-056: Maarten outlines the impact of the X.509 / ASN.1 vulnerabilities and highlights some mitigating factors that make them less severe than you might think. [link]

We hope that helps you understand this month’s large security bulletin release. Please email us with any questions.

- Jonathan Ness and Andrew Roths, MSRC Engineering

Special thanks to the entire MSRC Engineering staff for their work on this month’s security bulletins and blogs.

MS09-056: Addressing the X.509 CryptoAPI ASN.1 security vulnerabilities

swiblog — Mon, 12 Oct 2009 17:00:00 GMT

MS09-056 addresses two vulnerabilities that affect how the Windows CryptoAPI parses X.509 digital certificates. Applications on the Windows platform as well as Windows components such as the WinHTTP API can call into the CryptoAPI which provides cryptographic services to validate digital certificates. Internet Explorer, for instance, uses the CryptoAPI to parse and validate the certificate of remote web servers while browsing.

Digital certificates can prove that one peer in an SSL connection is who he claims to be. They are signed by a trusted, independent third party known as a Certificate Authority. Most often used to protect communications to web sites, they are also in common use to protect e-mail communications or B2B connections. The X.509 standard describes what information can go into a certificate and uses ASN.1 (Abstract Syntax Notation 1) to describe the format of the data. Object Identifier or OID is the ASN.1 type used to identify specific elements of the certificate such as an algorithm or attribute type. For example “2.5.4.3” is the OID that identifies the “Common Name” or “CN” string field in a certificate.

Addressed in this security update are a null truncation vulnerability and an integer overflow condition in ASN.1 parsing. Both of these vulnerabilities were discovered and presented by Dan Kaminsky at the BlackHat security conference in Vegas at the end of July of this year.

· CVE-2009-2510: Fields in the certificate’s subject name (such as the ‘Common Name’ or ‘CN’ field) which contains a NULL character in the string will cause the CryptoAPI to parse only the portion of the string prior to the NULL character. However, the certificate may have been issued to the organization / domain that comes after NULL character in the string.

· CVE-2009-2511: In a certificate, each Object Identifier (OID) is stored as a sequence of integers but is converted to a string by CryptoAPI when parsing a certificate. . The ASN.1 standard does not specify a maximum value for integers, but CryptoAPI assumes integer components of an OID can be safely parsed into a 32 bit integer in memory. A specially crafted OID number may result in an integer overflow condition that could cause it to be parsed in a way that allows the OID number’s data to replace the data for the previously encountered OID. This can cause the Certificate Authority and Windows to parse the certificate differently. This vulnerability can be exploited in those cases where the Certificate Authority ignores the specially crafted OID and agrees to sign the certificate, whereas the Windows CryptoAPI does parse the crafted OID.

Both of these vulnerabilities have an impact of spoofing, which means that an attacker could use them to fraudulently spoof the identity of another legitimate server on the internet.

This sounds quite serious and it is. However, it is important to take into account that the effort required in setting up such an attack is extensive. In order to exploit this issue in a web browsing scenario an attacker must successfully complete the following steps:

1. Convince a certificate authority to sign a rogue certificate. This would need to be a Certificate Authority that is present in the Root Certificate store of the Windows machine;

2. Execute a successful man-in-the-middle attack that hijacks the connection from a vulnerable client to a server and present the certificate to the client, e.g. via a DNS spoofing attack or via ARP cache poisoning on a local subnet.

Leveraging an attack which abuses these flaws is not trivial but cannot be excluded. We do believe that the threat of these attacks is significantly mitigated by these requirements posed on the attacker. However, the TLS Handshake Protocol (RFC 2246) makes two security promises that are violated by these vulnerabilities:

· The peer's identity can be authenticated;

· That no attacker can modify the communication without being detected by the parties to the communication.

As this vulnerability shows the potential of breaking this security promise, we consider it important to address these issues and are releasing this security update. We recommend that customers install them at their earliest convenience.

Updates to the CryptoAPI affect a vast number of applications that run on the Windows platform and these require very thorough and stringent testing prior to release. For this specific update our engineers looked specifically for applications that may have been affected by the unique changes made to this API and performed very detailed and specific interoperability testing. Quality of security updates is paramount to Microsoft which for the CryptoAPI often results in a fairly long test cycle.

During the development of these security updates Microsoft has continued to evaluate the threat environment to assess the risk these vulnerabilities posed to our customers. Certificate authorities that are included in the Root Certificate store on Windows are all required to meet the requirements of the Microsoft Root Certificate Program. A list of the third-party certification authorities (CAs) that are trusted by Microsoft and whose root certificates are distributed via the Root Certificate Program can be found in KB article 931125. During the development of these updates the MSRC has worked with certificate authorities to ensure that their systems were also hardened to help prevent signing certificates that may have attempted to exploit these vulnerabilities.

Thanks to Gavin Thomas and Robert Hensing from the MSRC Engineering team and Kelvin Yiu from Windows Crypto for their technical investigation into these two issues.

-Maarten Van Horenbeeck, MSRC Program Manager

MS09-051: A note on the affected platforms

swiblog — Mon, 12 Oct 2009 16:24:00 GMT

MS09-051 addresses a vulnerability (CVE-2009-0555) in the speech codec of Microsoft Window Media Component.

Users of Windows XP/Windows Vista/Windows Server 2003/Windows Server 2008* are affected by this vulnerability. However, for Win2k users, the story is more complex and we would like to go into more detail in this blog.

*Windows Server 2008 Core installation is not affected.

Are Win2K users affected?

Only in certain circumstances.

By default the vulnerable codec WMSPDMOD.dll is NOT shipped in-box on Win2k. The speech codec is not included in Windows Media Player (WMP) 6.4, which ships with Windows 2000. The optional WMP 7.1 download also does not include it. WMP 9 on the other hand does contain the speech codec. If you’ve installed WMP 9 on your Win2k machine you are affected and we recommend you install this update.

However even if a user only has WMP version 6.4 (default on win2k) or version 7.1, there is a possibility they are also vulnerable. This is due to the automated codec download feature of WMP. The first time a user plays a file requiring a codec that is not present on the system, the player will attempt to download and install it from the Microsoft codec server.

Here is an example. Using WMP 7.1 to play a WMA file that uses Speech codec, you will see the following codec download dialogue in WMP. If you have ever chosen to install the CAB you will have the speech codec WMSPDMOD.dll installed on your machine.

For WMP 6.4 users the player installs a different CAB from the Microsoft’s codec server. The speech codec it provides, WMAVDS32.ax, is affected by this vulnerability too.

How can I protect myself if I am a WMP 6.4/7.1 user on Win2k?

One option is to upgrade your WMP from 6.4/7.1 to WMP 9 and then apply the MS09-051 update.

Another option is to unregister and delete the old vulnerable speech codec if it has already been installed. To do that, follow these steps:

1) Check if WMAVDS32.ax or WMSPDMOD.dll existed in the window’s system32 directory. If files existed, the vulnerable codec has already been installed due to the codec download feature

2) Unregister the old codec

a. For 6.4 users, do regsvr32 /u wmavds32.ax

b. For 7.1 users, do regsvr32 /u wmspdmod.dll

3) Delete these codec files

The side effect of the above steps is that it leaves users unable to play files that use the speech codec.

What if I still need to play these files?

The Microsoft codec server has been updated with the fixed codec. For WMP 6.4/71 users, new versions of the codec will be downloaded and installed if the old codec was not present or was unregistered and deleted and a media file requiring that codec was opened.

Big Thanks to Gavin Thomas and Robert Hensing from MSRC Engineering Team, and Rob Van Schooneveld from WIN GRP SE team.

-Chengyun Chu, MSRC Engineering

MS09-050: Exploit timeline for the SMB2 RCE vulnerability

swiblog — Mon, 12 Oct 2009 14:58:00 GMT

This month we are releasing update MS09-050 to address the SMBv2 RCE vulnerability (CVE-2009-3103). Due to the fact that public exploit code exists for this vulnerability, we felt it would be good to summarize the exploit landscape at the time of release, so customers can use this information to prioritize the deployment of the update.

Initial disclosure

The initial public disclosure of this vulnerability on Sept. 7, 2009 included proof-of-concept code which would lead to a denial of service (DoS) due to the targeted system rebooting. Microsoft immediately began working to understand the vulnerability and produce a high-quality update. From an early stage we realized this vulnerability posed a Remote Code Execution (RCE) threat, and we released a security advisory to notify customers of the risk and suggested a work-around (disabling SMB2) which would protect systems from attack until the official update was ready.

Exploit timeline

One week later on Sept. 14, a security company released proof-of-concept code for a local exploit. On Sept. 17, the same company released proof-of-concept code for a remote exploit. The security company provided the local and remote exploit only to a subset of their customers who subscribe to an “early update” package. I will refer to this exploit as the “commercial exploit”.

Microsoft analyzed the commercial exploit code to determine the risk to customers and gauge how likely it would be for other security researchers to achieve a working exploit. Based on this analysis, we determined that the exploit provided was reliable, and that there was low risk of active exploitation (due to the limited release of the exploit). We continued to test the update and work towards releasing it as soon as it reached an acceptable quality level, barring changes in the exploit landscape.

At this time we were also aware that other researchers in the security community were working towards a remote exploit, and that they were planning to include it in freely-available tools. On Sept. 28, the first public exploit code was released. Again, we analyzed the exploit to determine the risk to our customers. We determined that the exploit was not reliable on all systems and would only work on a limited number of configurations reliably.

On Oct. 4, a blog post outlined changes to the public exploit code that would improve its reliability, but did not detail the exact code changes required. The post provided enough technical detail that we knew it would not take long for the public exploit to be updated, and a few days later we saw updated public exploit code posted online. At about the same time, the commercial exploit was also released to the security company’s wider set of customers.

Microsoft analyzed the newest public exploit code and determined that it was not yet reliable. (In fact it seemed to be totally unreliable in our testing.) We expected the gap between the commercial exploit and the public exploit to quickly close as more people gained access to the commercial exploit, and more people worked with the public exploit.

Current situation

There is currently no functioning RCE exploit for 64-bit systems running 64-bit Windows. The current commercial and public exploit tools only work against 32-bit Windows systems, and developing a reliable exploit for 64-bit Windows should be very difficult. However, 64-bit SMB servers are still at risk of DoS attacks using this vulnerability.

A reliable remote exploit is not widely available for 32-bit systems, and the risk of widespread attacks against systems is currently low. However, that could change at any moment. We recommend people deploy this update to their 32-bit SMB servers rapidly, as we anticipate a reliable exploit will be released within the first 30 days after this update is released. (More realistically the exploit will be released in the first week). Updating 64-bit SMB servers can be prioritized primarily based on the risk of DoS attacks.

Credit

I would like to thank the Windows SMB and Windows Serviceability teams for their hard work on this update, Jonathan Ness and Bruce Dang for the SMBv2 workaround and "Fix-It" automation, and Brian Cavenah and Ken Johnson for technical advice and help analyzing the exploits.

- Mark Wodrich

MS09-054: Extra info on the attack surface for the IE security bulletin

swiblog — Mon, 12 Oct 2009 14:36:00 GMT

MS09-054 addresses an IE vulnerability (CVE-2009-2529), which was discovered and presented by Mark Dowd, Ryan Smith, and David Dewey at the BlackHat conference in July.

First we’d like to make it clear that any customers that have applied the update associated with MS09-054 are protected, regardless of the attack vector. And most customers need not take any action as they’ll receive this update automatically through Automatic Updates.

For those customers that are evaluating whether or not to deploy this update, and want more information on how to protect themselves until they do, we’ve provided more details in this blog post to help understand this vulnerability.

What’s the attack vector?

A browse-and-get-owned attack vector exists. All that is needed is for a user to be lured to a malicious website. Triggering this vulnerability involves the use of a malicious XBAP (XAML Browser Application). Please not that while this attack vector matches one of the attack vectors for MS09-061, the underlying vulnerability is different. Here, the affected process is the Windows Presentation Foundation (WPF) hosting process, PresentationHost.exe.

While the vulnerability is in an IE component, there is an attack vector for Firefox users as well. The reason is that .NET Framework 3.5 SP1 installs a “Windows Presentation Foundation” plug-in in Firefox, as shown below.

Via this plug-in it is possible to launch XBAP, and reach this vulnerability, from within Firefox.

How can I protect myself?

Customers should apply MS09-054 as this addresses the underlying vulnerability for all users, both IE and Firefox. While you’re evaluating and testing your deployment of MS09-054, you may want to consider the following workarounds.

For IE users, our recommended workaround is to disable XBAP in the Internet zone. By default, IE8 on Win2k8 and Win2k3 already has XBAP disabled in the internet zone. For others, you can disable XBAP via the following security setting in IE.

For Firefox users with .NET Framework 3.5 installed, you may use “Tools”-> “Add-ons” -> “Plugins”, select “Windows Presentation Foundation”, and click “Disable”.

Big thanks to David Ross, Fermin J. Serna, and Andrew Roths from the MSRC Engineering Team, Eric Lawrence and Jeremy Reed from IE team, and Jennifer Lee from WPF team.

Updated October 16, 2009 - updated blog post to clarify that Firefox users are protected from CVE-2009-2529 if they install the MS09-054 update.

MS09-061: More information about the .NET security bulletin

swiblog — Mon, 12 Oct 2009 14:30:00 GMT

MS09-061 fixes vulnerabilities in the .NET Framework which could allow malicious .NET applications execute arbitrary native code, resulting in remote code execution. This post is intended to help clarify the attack vectors for these vulnerabilities, and to cover recommended workarounds.

Important note:
These vulnerabilities in the .NET framework do not affect applications built on the .NET framework – you do not need to recompile any of your applications after installing this update. These vulnerabilities lie only in the .NET framework and make it possible for malicious .NET applications to escape restrictions placed on them.

The attack vectors:
So how could these vulnerabilities be exploited? In short, they make it possible for malicious .NET applications to break out of the Code Access Security (CAS) sandbox. There are 3 common scenarios where an attacker could take advantage of this to achieve remote code execution:

· Malicious web page

o A malicious web page could host a malicious XAML Brower Application (XBAP), Silverlight application, or managed plug-in (off by default in IE8).

o Please note that Silverlight 3 is not affected by this bulletin. Users who have upgraded to Silverlight 3 are not vulnerable to attacks from malicious Silverlight applications.

o Note that Internet Explorer is not the only browser impacted as other browsers also support XBAPs.

o If successful, a malicious application could use one of these vulnerabilities to execute arbitrary code on the client in the context of the current logged in user.

· Malicious ASP.NET applications

o Servers which allow untrusted ASP.NET applications to be uploaded and run are vulnerable and should prioritize installing this update.

o Malicious ASP.NET applications could use one of these vulnerabilities to execute arbitrary code on the server in the context of user account of the application pool they are assigned to.

· Malicious .NET applications on network shares

o By default prior to .NET 3.5 SP1, .NET applications on network shares run in the CAS sandbox (they are considered partially trusted).

§ If .NET 3.5 SP1 is installed, then .NET applications on network shares run in full trust by default.

o A malicious .NET application that has been run from a network share could use one of these vulnerabilities to escape the CAS sandbox and execute arbitrary code on the client in the context of the current logged in user.

How to protect computers without the security update:
First of all, we recommend installing this update as soon as possible. However, if it is not possible to install the update on all of your computers immediately, there are a couple of workarounds which, when applied together, can help protect your computers in the interim.

1. Disable partially trusted .NET applications

a. Detailed steps are available in the security bulletin: http://www.microsoft.com/technet/security/Bulletin/MS06-061.mspx.

b. This workaround will not affect fully trusted .NET applications, such as .NET applications (EXEs) located on your local hard drive.

c. However, partially trusted applications, such as XBAP, managed plug-ins, ASP.NET applications, and .NET applications on network shares (if you are using a .NET Framework version older than 3.5 SP1), will not be allowed to run.

d. This workaround does not protect against malicious Silverlight applications.

e. Note that this workaround will disable all ASP.NET applications.

2. Temporarily disable Silverlight

a. This workaround is not applicable for Silverlight 3 users as Silverlight 3 is not vulnerable.

b. If you can upgrade to Silverlight 3, we recommend you do that instead of using this workaround.

c. Detailed steps are available in the security bulletin: http://www.microsoft.com/technet/security/Bulletin/MS06-061.mspx.

d. This workaround prevents Silverlight from loading, preventing malicious websites from exploiting this vulnerability, but also preventing non-malicious Silverlight applications from loading.

Why not disable fully trusted .NET applications?
There is no need to disable fully trusted .NET applications because they can already do anything in the context of the user account they run in, so arbitrary code execution within that same user account context would not gain an attacker anything.

However, partially trusted .NET applications are restricted by the .NET framework’s CAS feature, and are prevented from performing dangerous actions even if the user account they are running as is allowed to. These partially trusted applications would have something to gain by exploiting one of these vulnerabilities, as they could then perform sensitive actions. Essentially they could elevate from untrusted to trusted applications.

Wrap up
I hope you have found this information helpful in understanding the impact of these vulnerabilities, and in how to best protect your computers.

-Kevin Brown, MSRC Engineering

Special thanks to Eugene Bobukh of the MSEC PM team.

Updates October 17, 2009 - updated blog post to clarify that Silverlight 3 is not affected by this bulletin.

New attack surface reduction feature in GDI+

swiblog — Mon, 12 Oct 2009 14:27:00 GMT

MS09-062 fixes several vulnerabilities in GDI+ related to image parsing. It also includes a feature which allows administrators to disable parsing for each of the different image formats. This feature was publicly released early this year in an optional GDI+ update available on the Microsoft Download Center, but is now being release as part of this bulletin.

After installing this update, you can selectively turn off each of the image parsers in GDI+. This can be helpful in reducing the attack surface of your computer. For example, if you have no need to display TIFF files on a computer, you can disable just the TIFF parsing in GDI+, reducing your attack surface and susceptibility to any future vulnerabilities in the GDI+ TIFF parsing code.

Below is a table of the parsers in GDI+ that can be disabled, and the registry keys used to disable them:

Format	Registry Key
BMP	HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Gdiplus\DisableBMPCodec (DWORD) == 1
GIF	HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Gdiplus\DisableGIFCodec (DWORD) == 1
PNG	HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Gdiplus\DisablePNGCodec (DWORD) == 1
ICO	HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Gdiplus\DisableICOCodec (DWORD) == 1
TIFF	HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Gdiplus\DisableTIFFCodec (DWORD) == 1
JPEG	HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Gdiplus\DisableJPEGCodec (DWORD) == 1
WMF/EMF*	HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\GRE_Initialize\DisableMetaFiles (DWORD) == 1

* The disable switch for WMF and EMF was present before this update (included for completeness)

When one of these disable switches is activated, any attempts to parse a file of that particular format will return an error, just like the parser would normally return an error if the image file was corrupted.

Some applications might assume that parsing will always succeed, particularly when parsing images installed as part of the application. These applications may not gracefully recover when GDI+ returns the error. For this reason, if you want to use this feature to reduce your attack surface, we recommend first disabling the parsers you don’t plan to use, and then testing the applications you use frequently to make sure they are not adversely affected.

Also note that this feature reduces your attack surface by disabling the GDI+ parser for a particular image format, not all parsers for that image format on your computer. Some applications, including Microsoft applications, do not use GDI+ for image parsing. Those other parsers would not be disabled by these registry keys.

We hope you find this feature, and this post, helpful!

-Kevin Brown, MSRC Engineering

Special thanks to Christopher Leung and Ryan Becker from the Windows Sustained Engineering team.

Update on the SMB vulnerability situation

swiblog — Fri, 18 Sep 2009 20:00:00 GMT

We’d like to give everyone an update on the situation surrounding the new Microsoft Server Message Block Version 2 (SMBv2) vulnerability affecting Windows Vista and Windows Server 2008.

Easy way to disable SMBv2
First exploit for code execution released to small number of companies
Mitigations that help prevent attacks
Status of fixes

Easy way to disable SMBv2

Until the security update is released, the best way to protect systems from this vulnerability is to disable support for version 2 of the SMB protocol. The security advisory was updated yesterday with a link to the Microsoft Fix It package that disables SMBv2 and then stops and starts the Server service. (This initial Fix It might prompt you to also restart the Browser service.) You can also click here:

Click Here To Disable SMBv2

To revert the workaround, and re-enable SMBv2, you can click here:

Click Here To Re-Enable SMBv2

Disabling SMBv2 may slow down SMB connections between Windows Vista and Windows Server 2008 machines.

First exploit for code execution released to small number of companies

We are not aware of any in-the-wild exploits or any real-world attacks.

However, we are aware of exploit code developed by Immunity Inc. and released to customers who subscribe to the CANVAS Early Updates program. We have analyzed the code ourselves and can confirm that it works reliably against 32-bit Windows Vista and Windows Server 2008 systems. The exploit gains complete control of the targeted system and can be launched by an unauthenticated user.

The exploit can be detected by intrusion detection systems (IDS) and firewalls that have signatures for the vulnerability being targeted (CVE-2009-3103).

This exploit code from Immunity is only available to a small group of companies and organizations who will use it to determine the risk to their own networks and systems, or those of their customers. (We are aware that other groups are actively working on exploit code which is likely to be made public when it is completed).

Mitigations that help prevent attacks

There are a number of mitigating factors that could aid in preventing attacks such as:

Enterprise customers can disable SMBv2 using a simple registry script or the Fix It described above. Disabling SMBv2 prevents the vulnerable code from being reached.
Consumers (not part of an enterprise network) are protected by the on-by-default firewall included in Windows Vista:
- The on-by-default Windows firewall protects vulnerable systems
- The on-by-default Windows firewall allows packets through only if a user explicitly shares a folder or printer.
- When a Windows Vista user chooses the ‘Public’ firewall setting, the firewall will block packets even if a folder or printer has been shared.

Status of fixes

Even with the above mitigations, we’re not slowing down our investigation, and are working on an update that can be delivered for all customers. The product team has built packages and are hard-at-work testing now to ensure quality. It takes more testing than you might think to release a quality update. For this update, the product team has so far already completed over 10,000 separate test cases in their regression testing. They are now in stress testing, 3rd-party application testing, and fuzzing. We'd sure like to complete all that testing before the update needs to be released. We are keeping a close eye on the changing landscape and balancing this against the remaining test actions to determine the best ship schedule to bring a quality update to customers.

- Mark Wodrich and Jonathan Ness, MSRC Engineering

*Posting is provided "AS IS" with no warranties, and confers no rights.*

OffVis updated, Office file format training video created

swiblog — Mon, 14 Sep 2009 20:00:00 GMT

In July, we released a beta Office file format viewer application called OffVis as a downloadable tool. We are pleased today to announce an updated version of OffVis and a 30 minute training video to help you understand the legacy Office binary file format.

OffVis 1.1

The community response to the release of the OffVis tool on July 31st has been great. Thank you for the feedback! We are releasing this new version 1.1 of OffVis in response to that feedback. This release introduces several requested new features and fixes bugs. Here are the highlights:

Now requires only .Net Framework 2.0 (1.0 Beta required 3.5, preventing some people from using it)
Addressed OLESS loading logic bugs that was leading to false negatives (detection logic misses)
Added the detection logic for several more Word and PowerPoint CVE’s, detecting files sent in by customers.
Added a “Reallocate” feature (under Tools menu) that makes some corrupted files parse-able
Clarified some error message text
Prevented OffVis from appearing in a saved location off-screen
Cleared highlighting after the parser changes
Removed limit on number of parsing notes displayed

Here is the new list of detected CVE’s:

CVE	Product	Bulletin
CVE-2006-0009	PowerPoint	MS06-012 (March 2006)
CVE-2006-0022	PowerPoint	MS06-028 (June 2006)
CVE-2006-2492	Word	MS06-027 (June 2006)
CVE-2006-3434	PowerPoint	MS06-062 (October 2006)
CVE-2006-3590	PowerPoint	MS06-048 (August 2006)
CVE-2006-4534	Word	MS06-060 (October 2006)
CVE-2006-4694	PowerPoint	MS06-058 (October 2006)
CVE-2006-5994	Word	MS07-014 (February 2007)
CVE-2006-6456	Word	MS07-014 (February 2007)
CVE-2007-0515	Word	MS07-014 (February 2007)
CVE-2007-0671	Excel	MS07-015 (February 2007)
CVE-2007-0870	Word	MS07-024 (May 2007)
CVE-2008-0081	Excel	MS08-014 (March 2008)
CVE-2008-4841	Word	MS09-010 (April 2009)
CVE-2009-0238	Excel	MS09-009 (April 2009)
CVE-2009-0556	PowerPoint	MS09-017 (May 2009)

Please email us any undetected malicious samples that exploit vulnerabilities for code execution. We will evaluate whether we can add detection that can help everyone detect malicious files.

You can learn more about OffVis from our original blog post about the tool or an article written by Russ McRee in the ISSA journal. You can download the tool at http://go.microsoft.com/fwlink/?LinkId=158791

Office legacy binary file format training video

Bruce Dang and Nick Finco from the MSRC Engineering team put together a 30 minute training that describes the legacy binary Office file format and describes how to parse it. Our Bluehat team agreed to record it and host it on the Bluehat technet site. You can view the video at http://research.microsoft.com/en-us/UM/redmond/events/BH09/lecture.htm. In less than thirty minutes, they provide in-depth technical guidance, including full-screen demos. This video is geared toward security analysts, virus researchers, IDS signature authors, and security professionals.

Direct video link: http://research.microsoft.com/en-us/UM/redmond/events/BH09/lecture.htm

Summary

Thanks to the many people who made this possible. Kevin Brown and Dan Beenfeldt for the development of OffVis. Robert Hensing and Bruce Dang for tireless hours testing the tool and building and refining detection logic. The MSRC Engineering team for technical investigations leading to these detections. Bruce and Nick Finco for recording the video. Damian Hasse and Matt Thomlinson for the support to release this tool. Celene Temkin and the Bluehat team for the logistical magic to make the video happen. Thanks everybody!

- Jonathan Ness, MSRC Engineering

*Posting is provided "AS IS" with no warranties, and confers no rights.*

AutoPlay Windows 7 behavior backported

swiblog — Sat, 12 Sep 2009 04:27:34 GMT

Back in April we talked about the Windows 7 improvements in AutoPlay that disables certain functionality which has been abused by malware (like Conficker). We also mentioned that these changes will be backported to down level platforms. On August 25^th this functionality was made available for Windows XP, Windows Server 2003, Windows Vista and Windows Server 2008, please visit the following KB article for more information and how to download the updates http://support.microsoft.com/kb/971029

Thanks to Dave Midturi (from MSRC) and Ugo Enyioha (from Windows Sustained Engineering team) for helping on this work.

Thanks,

Damian Hasse – MSRC Engineering

*Postings are provided "AS IS" with no warranties, and confers no rights.*

Assessing the risk of the September Critical security bulletins

swiblog — Tue, 08 Sep 2009 19:57:00 GMT

This morning we released five security bulletins, all of them having a bulletin maximum severity rating of Critical and two having a bulletin maximum exploitability index rating of "1" (Consistent exploit code likely). We wanted to just say a few words about each bulletin to help you prioritize your deployment this month.

The following table presents a high-level view of the severity of each of the five Critical bulletins and the platforms at reduced risk:

Bulletin	Primary Attack Vector	Max Exploit-ability Index	Likely first 30 days Impact	Platform mitigations
MS09-047	IE browsing to malicious website, ASF or MP3 files attached to email.	1	Exploit developed for code execution in context of logged-in user.	IE8 running on XP SP3 or Vista SP1 at reduced risk due to DEP. Windows Server 2003 and 2008 at reduced risk due to Enhanced Security Configuration. The hardened heap improvements in Vista and Windows Server 2008 makes exploitation harder.
MS09-045	IE browsing to malicious website.	1	Exploit developed for code execution in context of logged-in user.	IE8 running on XP SP3 or Vista SP1 at reduced risk due to DEP. Windows Server 2003 and 2008 at reduced risk due to Enhanced Security Configuration.
MS09-048	Attacker sending stream of malicious TCP/IP packets	2	Exploit developed causing a machine resource exhaustion denial-of-service.	Windows Vista not affected in ‘Public’ network profile
MS09-049	Attacker sends malformed wireless frames to nearby workstation.	2	Exploit developed causing wlansvc service to crash.	Windows Server 2008 at reduced risk due to Enhanced Security Configuration. The hardened heap improvements in Vista and Windows Server 2008 makes exploitation harder.
MS09-046	IE browsing to malicious website.	2	Exploit developed causing IE to crash.	IE8 running on XP SP3 at reduced risk due to DEP. Windows Server 2003 at reduced risk due to Enhanced Security Configuration.

Information about MS09-045 and MS09-046

MS09-045 and MS09-046 are both “driveby-style” vulnerabilities. The attack vector is most likely malicious websites hosting specially-crafted javascript (MS09-045) or malicious use of the DHTML ActiveX control (MS09-046) to infect browsing users. Vulnerabilities that confuse the script engine can be tough to reverse-engineer from the update so it may take a while for attackers to discover and weaponize. We still might see a reliable exploit within 30 days, hence the “1” rating for MS09-045. The MS09-046 repro is more straight-forward and is likely to be discovered but it will be more difficult to produce a reliable exploit for code execution.

Information about MS09-047

The attack vector for both CVE’s addressed by MS09-047 is most likely again a malicious website but these vulnerabilities could also be exploited via media files attached to email. When a victim double-clicks the attachment and clicks “Open” on the dialog box, the media file could hit the vulnerable code. Both these vulnerabilities were responsibly-disclosed with no attacks known in the wild. However, both are fairly straightforward so it probably won’t take the community long to figure them out. We would not be surprised to see an exploit for one or both of these CVE’s within the first month of release.

Information about MS09-048

Next up is MS09-048 addressing vulnerabilities in the TCP/IP stack implementation. To hit the vulnerable code, an attacker must flood a victim with specially-crafted TCP/IP packets inducing one of two denial-of-service outcomes:

System runs out of non-paged pool memory (CVE-2008-4609 and CVE-2009-1926)
System incorrectly handles the hash value of a connection, crashing in kernel-mode code leading to a reboot / blue-screen-of-death (CVE-2009-1925)

CVE-2009-1925 is rated Critical because the attacker is forcing the system to call into a random kernel address. However, based on our research, the attacker does not have sufficient control of the address to reliably achieve code execution. You can read all about it in Mark Wodrich’s blog post here. The exploitability rating of this issue is “2.”

CVE-2008-4609 is the most likely issue from MS09-048 to be further researched as it was a coordinated release between multiple companies having the same vulnerability. Cisco is planning a 10am advisory release this morning as well. Check http://www.cisco.com/en/US/products/products_security_advisories_listing.html#advisory for more information from them.

Information about MS09-049

MS09-049 addresses an issue with the way Windows Vista handles Wireless networking requests. An attacker able to send malformed wireless frames can cause the Windows Vista user-mode service (wlansvc) to crash. This will be tricky to exploit due to Windows Vista’s hardened heap manager. Attacks will most likely crash the service, disrupting the ability to browse for (or automatically connect to) new networks. If already associated to a network, the machine will remain connected. Attacks will not cause the machine to reboot. The community will likely discover the vulnerability; however the Windows Vista heap mitigations will make it difficult to reliably exploit.

Thanks Mark Wodrich for your analysis of the TCP/IP and Wireless issues that went into this blog post. Big thanks also to the reviewers who re-shaped this post making it much better than my original: Damian Hasse, Andrew Roths, Greg Wroblewski, Robert Hensing, and Gavin Thomas from the MSRC Engineering team; Mike Reavey from MSRC Operations.

- Jonathan Ness, MSRC Engineering

*Posting is provided "AS IS" with no warranties, and confers no rights.*

MS09-048: TCP/IP vulnerabilities

swiblog — Tue, 08 Sep 2009 19:55:00 GMT

This month we released MS09-048 which addresses three vulnerabilities in the Windows TCP/IP stack. One of the vulnerabilities, CVE-2009-1925, is rated Critical due to the risk of Remote Code Execution (RCE). The other two vulnerabilities are Denial of Service (DoS) issues (due to memory exhaustion) without the risk of RCE.

The Exploit Index rating for CVE-2009-1925 is 2 (Medium), and this blog post is intended to provide more information on the exploitability of this issue, and the reasons why the risk of RCE is lower than the Critical rating may imply. We also provide information on the new memory exhaustion protections that were implemented to address the DoS vulnerabilities.

Why is the severity “Critical” in the bulletin?

The TCP/IP stack is a part of the Windows kernel, and handles low-level networking protocols such as IP, TCP and UDP. The vulnerability tracked by CVE-2009-1925 allows an attacker to cause the TCP/IP stack, under certain conditions, to execute code at an invalid address. This can be done by a remote, anonymous attacker. Since executing at an invalid address is something that could be leveraged by an attacker to gain RCE, we rated the bulletin using this “worst case” impact, hence the Critical severity in the security bulletin.

Why is the Exploitability Index rating Medium?

The Exploitability Index is intended to provide guidance to help prioritize patch deployment. The Exploitability Index rating is based on the probability that a reliable code-execution exploit will be created within 30 days of the bulletin release [1]. For various reasons, we do not anticipate a reliable code-execution exploit will be produced for this vulnerability. Specifically:

The vulnerability is due to TCP/IP incorrectly using a field that contains a hash value for the TCP connection, and treating the hash value as a function pointer.
The hash value is computed using the Toeplitz Hash (described in detail here). This hash algorithm takes a random key as input. The key is not known to the attacker and not under the attacker’s control, which means the resulting hash value is not under the attacker’s control.
This effectively means the address which will be invoked as a function pointer is a random value that cannot be predicted by the attacker.
An attacker may be able to “spray” kernel memory with their malicious payload, and this would increase the chance that a random address would be within data they control. This would still be unreliable.

Due to the above, except in staged scenarios where the attacker knows details about the random key used by the target computer, RCE exploits will not be reliable. As a result we assigned a Medium rating in the Exploitability Index.

Will Denial of Service (DoS) attacks be reliable?

Attackers will be able to trigger this vulnerability to cause a system crash (bugcheck) when the invalid address is executed – this would a system-level Denial of Service (DoS). Systems that are exposed to untrusted users should be patched to protect against DoS attacks. It is also possible to mitigate against the attacks by using network firewalls that block the attack.

New protections against memory exhaustion attacks

With this security update, we are introducing new protections in the TCP/IP stack to prevent memory exhaustion attacks. The new protections are enabled by default on Windows Server 2003 and 2008, but not on Windows Vista. The protections will activate when the system is under severe memory pressure (when the system runs very low on nonpaged kernel memory). At this point, TCP connections will be dropped at random, helping to keep the system operational. This feature can be controlled using netsh and the registry as outlined in KB 974288.

Servers that are under heavy load during normal operating conditions may experience severe memory pressure that would trigger the new protections. To prevent the new protections from activating and dropping connections, the administrator can follow the instruction in KB 974288 to disable the protections or exclude specific TCP ports.

To protect systems where the new protection feature cannot be used, a NAT or reverse proxy could shield the system. For example, to protect Windows 2000 systems, a device that is not vulnerable to the DoS attacks could proxy incoming connections.

References

1. Microsoft Exploitability Index, http://technet.microsoft.com/en-us/security/cc998259.aspx

Updated September 11, 2009: Notes added about KB 974288 to answer customer questions.

- Mark Wodrich, MSRC Engineering

Posting is provided "AS IS" with no warranties, and confers no rights.

SQL Server information disclosure non-vulnerability

swiblog — Thu, 03 Sep 2009 02:31:00 GMT

We’ve gotten some questions about a reported issue with SQL Server exposing plaintext user passwords. We investigated the issue and found that attackers would need administrative control of a SQL Server to extract passwords from it. We checked with the security researchers who reported the issue and they confirmed that this is an information disclosure issue requiring the attacker to first have administrative control of the installation. Therefore, we do not consider this a bulletin class vulnerability. As we have mentioned in previous blog entries, it is impossible to defend against a malicious administrator. In the end, you’ve simply got to trust your legitimate administrators and keep attackers from gaining administrative access (see Immutable Law of Security #6).

SQL Server 2008 installations actually have reduced exposure to this specific issue as the SQL team has removed specific commands that enable SQL administrators to dump memory from within SQL. And neither SQL Server 2005 nor SQL Server 2008 have SQL authentication enabled by default. (If you use the default Windows Authentication Mode instead of SQL authentication, SQL Server does not receive or store your Windows credentials.) However, any compromised system into which you enter credentials is at risk from a malicious administrator. There are a few other ways for a malicious administrator to gain user credentials. It’s really very difficult to defend a program running on a system where an attacker has full administrative control.

Thanks Ben Richeson from the MSRC Ops team and Al Comeau from the SQL team for help with this one.

- Jonathan Ness, MSRC Engineering

*Posting is provided "AS IS" with no warranties, and confers no rights.*

New vulnerability in IIS5 and IIS6

swiblog — Wed, 02 Sep 2009 03:59:00 GMT

This afternoon, the MSRC posted a security advisory describing a newly-disclosed vulnerability in the IIS FTP service that could potentially grant remote code execution to untrusted users. You can find the advisory here.

Vulnerability summary

The vulnerability is a stack overflow in the FTP service when listing a long, specially-crafted directory name. To be vulnerable, an FTP server would need to grant untrusted users access to log into and create that long, specially-drafted directory. If an attacker were able to successfully exploit this vulnerability, they could execute code in the context of LocalSystem, the service under which the FTP service runs.

Configurations at risk

The vulnerable code is in IIS 5.0 (Windows 2000), IIS 5.1 (Windows XP) and IIS 6.0 (Windows Server 2003). IIS 7.0 (Windows Vista, Windows Server 2008) is not vulnerable. IIS 6 is at reduced risk because it was built with /GS which help protect the service from exploits by deliberately terminating itself when the overflow is detected before attacker’s code runs. We have not seen exploit code for this vulnerability that is able to bypass the /GS protection.

Also, remember that only servers that allow untrusted users to log on and create arbitrary directories are vulnerable.

Protecting your servers

The advisory lists several options to protect your servers from this vulnerability until a fully-tested security update is available. The end result of the workarounds is to prevent untrusted users from having write access to the FTP service. The options presented in the advisory include:

Turn off the FTP service if you do not need it
Prevent creation of new directories using NTFS ACLs
Prevent anonymous users from writing via IIS settings

The IIS Manager setting to prevent Write access can be found on the following dialog in IIS 5.

The IIS team's best practices FTP guidance can be found at http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/7b4bdad5-9a0a-4bf6-8b00-41084b783e20.mspx?mfr=true

Detecting attacks

We expect several of our MAPP partners with network-based detection and protection to be able to identify and potentially prevent attacks. For example, you can find snort rules available already at http://www.snort.org/vrt/docs/ruleset_changelogs/changes-2009-09-01.html.

You can also detect attacks yourself by examining logfiles. The exploit issues several commands followed by very long strings. The FTP service, by default, logs commands issued. For example, here is a sample log entry from pointing the proof-of-concept code at an internal server:

#Software: Microsoft Internet Information Services 5.0
#Version: 1.0
#Date: 1111-01-01 22:45:13
#Fields: time c-ip cs-method cs-uri-stem sc-status 
22:45:13 169.254.117.152 [1]USER anonymous 331
22:45:13 169.254.117.152 [1]PASS password 230
22:45:13 169.254.117.152 [1]MKD JUNK@ÿàC~ñú~ñú~ñú~ñú~ñú~ñú~ñú~ñú~ñú~ñú~ñú~ñú~ñú~ñú~ñú~ñú~ñú~ñú~ñú~ñú~ñú~ñú~ñú~ñú~ñú~ñú~ñú~ñú~ñú~ñú~ñú~ñú~ñú~ñú~ñúEEEE›±ôw~ñúHHHHIIII~ñúJKKKécþÿÿNNNN 257

You can find these log files, by default, in c:\winnt\system32\logfiles\MSFTPSVC1. If you currently store logfiles on the same machine as the vulnerable service, you may want to reconfigure the service to store them elsewhere to prevent an attacker from cleaning up the logfiles.

We’d like to thanks Wade Hilmo and Nazim Lala from the IIS team for providing information for this blog post. Brian Cavenah from the MSRC Engineering team also was very helpful in this investigation. Thanks guys!

- Bruce Dang and Jonathan Ness, MSRC Engineering team

*Posting is provided "AS IS" with no warranties, and confers no rights.*