Smokey's Security Weblog

veritas odium parit

[UPDATED] Microsoft IIS 0-Day Vulnerability in Parsing Files Reported

TheRegister | 25th December 2009

A researcher has identified a vulnerability in the most recent version of Microsoft’s Internet Information Services that allows attackers to execute malicious code on machines running the popular webserver.

The bug stems from the way IIS parses file names with colons or semicolons in them, according to researcher Soroush Dalili. Many web applications are configured to reject uploads that contain executable files, such as active server pages, which often carry the extension “.asp.” By appending “;.jpg” or other benign file extensions to a malicious file, attackers can bypass such filters and potentially trick a server into running the malware.

There appears to be some disagreement over the severity of the bug, which Dalili said affects all versions of IIS. While he rated it “highly critical,” vulnerability tracker Secunia classified it as “less critical,” which is only the second notch on its five-tier severity rating scale.

“Impact of this vulnerability is absolutely high as an attacker can bypass file extension protections by using a semicolon after an executable extension such as ‘.asp,’ ‘.cer,’ ‘.asa’ and so on,” Dalili wrote. “Many web applications are vulnerable against file uploading attacks because of this weakness of IIS.”

Opinion Sans | 25th December 2009

After reading up on related posts and IIS issues, the nature of the vulnerability is such that it’s going to be widely exploited soon, quite successfully, and not only by the usual suspects, but more effectively by the specialized groups of attackers that are after unrestricted access to your protected network, and, of course, the other groups after more mundane items like bank accounts.

Update 2009-12-28: Microsoft response

MSRC TEAM | Sunday, December 27

On Dec. 23 we were made aware of a new claim of a vulnerability in Internet Information Services (IIS). We are still investigating this issue and are not aware of any active attacks but wanted to let customers know that our initial assessment shows that the IIS web server must be in a non-default, unsafe configuration in order to be vulnerable. An attacker would have to be authenticated and have write access to a directory on the web server with execute permissions which does not align with best practices or guidance Microsoft provides for secure server configuration. Customers using out of the box configurations and who follow security best practices are at reduced risk of being impacted by issues like this.

Once we’re done investigating, we will take appropriate action to help protect customers. This may include providing a security update through the monthly release process, an out-of-cycle update or additional guidance to help customers protect themselves.

This vulnerability was not responsibly disclosed to Microsoft and may put customers at risk. We continue to encourage responsible disclosure of vulnerabilities as we believe reporting vulnerabilities directly to a vendor serves everyone’s best interests. This practice helps to ensure that customers receive comprehensive, high-quality updates for security vulnerabilities without exposure to malicious attackers while the update is being developed.

I want to close by providing some resources and best practices for securely configuring IIS servers:

IIS 6.0 Security Best Practices
http://technet.microsoft.com/en-us/library/cc782762(WS.10).aspx

Securing Sites with Web Site Permissions
http://technet.microsoft.com/en-us/library/cc756133(WS.10).aspx

IIS 6.0 Operations Guide
http://technet.microsoft.com/en-us/library/cc785089(WS.10).aspx

Improving Web Application Security: Threats and Countermeasures
http://msdn.microsoft.com/en-us/library/ms994921.aspx

*This posting is provided “AS IS” with no warranties, and confers no rights*

Update 2009-12-29: Microsoft denial

MSRC TEAM | Tuesday, December 29

We’ve completed our investigation into the claims that came up over the holiday of a possible vulnerability in IIS and found that there is no vulnerability in IIS.

What we have seen is that there is an inconsistency in IIS 6 only in how it handles semicolons in URLs. It’s this inconsistency that the claims have focused on, saying this enables an attacker to bypass content filtering software to upload and execute code on an IIS server.

The key in this is the last point: for the scenario to work, the IIS server must already be configured to allow both “write” and “execute” privileges on the same directory. This is not the default configuration for IIS and is contrary to all of our published best practices. Quite simply, an IIS server configured in this manner is inherently vulnerable to attack.

However, customers who are using IIS 6.0 in the default configuration or following our recommended best practices don’t need to worry about this issue. If, however, you are running IIS in a configuration that allows both “write” and “execute” privileges on the same directory like this scenario requires, you should review our best practices and make changes to better secure your system from the threats that configuration can enable.

The IIS folks are evaluating a change to bring the behavior of IIS 6.0 in line with the other versions. In the meantime, they’ve put more information up about this on their weblog.

*This posting is provided “AS IS” with no warranties, and confers no rights*

Take care and remain alert!

Advertisements

December 27, 2009 - Posted by | Advisories, Alerts, Recommended External Security Related Links, Vulnerabilities | , , , , , , , , , , , , , ,

No comments yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: