Broadband Tech > Security > Security > [MS DENIAL] Microsoft IIS 0-Day Vulnerability Parsing Files

Results of Investigation into Holiday IIS Claim
Posted Tuesday, December 29, 2009 11:42 AM by MSRC TEAM

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. Once again, here’s a list of best practices resources:

· IIS 6.0 Security Best Practices

· Securing Sites with Web Site Permissions

· IIS 6.0 Operations Guide

· Improving Web Application Security: Threats and Countermeasures

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.

I hope this helps answer any questions.

Christopher

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

said by Microsoft :

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.