According to what I am reading, this can only be exploited if best practice recommendations are not observed.
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
Securing Sites with Web Site Permissions
IIS 6.0 Operations Guide
Improving Web Application Security: Threats and Countermeasures
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.
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.
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.
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
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.