Security Advisory 971492 provides official guidance about the new IIS authentication bypass vulnerability. We’d like to go into more detail in this blog to help you understand:
- Am I at risk? If so, what could happen?
- How can I protect myself?
Which IIS configurations are at risk?
Only a specific IIS configuration is at risk from this vulnerability. First, we will list configurations that are not at risk, so some of you reading can quickly stop worrying about your web servers:
- An IIS server not running WebDAV is safe.
The Windows Server 2003 IIS (version 6) shipped with WebDAV disabled by default. - An IIS server not using IIS permissions to restrict content to authenticated users is safe.
- An IIS server that does not grant filesystem access to the IUSR_[MachineName] account is safe.
- An IIS server that hosts web applications using only forms-based authentication is probably safe.
If your web server meets all of the following criteria, you will want to read on:
- IF an IIS 5, 5.1, or 6.0 webserver is running with WebDAV enabled;
- AND the IIS server is using IIS permissions to restrict a subfolder of content to authenticated users;
- AND file system access is granted for the restricted content to the IUSR_[MachineName] account;
- AND a parent folder of the private subfolder allows anonymous access;
THEN an anonymous remote user may be able to leverage this vulnerability to access files that normally would only be served to authenticated webserver users.
This vulnerability is primarily an information disclosure threat.
Does the information disclosure vulnerability completely bypass the authentication mechanism?
Not exactly. The malformed URL causes the IIS access check to incorrectly be made using the IIS metabase access key from a parent directory instead.
A malicious HTTP request sent to a vulnerable IIS server ends up being evaluated by both the web server and the WebDAV extension. When the WebDAV extension attempts to normalize the URL, it modifies the URL in such a way that the access check is made using the permissions from the parent directory but IIS serves the file in the sub-directory. Therefore, the most likely attack would be a malicious anonymous user requesting contents of a webserver subdirectory that uses IIS permission restricting access to only authenticated users. The root of the webserver would typically grant read access to the anonymous user account so this vulnerability would allow the protected subdirectories to be accessed using the permissions of the webserver root (allowing anonymous access).
Why do you say “primarily an information disclosure threat”? What else could happen?
We are still investigating different attack ideas possible using this vulnerability but the original report claimed files could be uploaded and modified. However, what we have found is that the IIS installer applies an NTFS access control entry to explicitly deny write access to the anonymous account (IUSR_[MachineName]) in wwwroot and subdirectories that inherit wwwroot’s ACL. So in the default case, this vulnerability will not allow a malicious attacker to upload or modify webpages.
Mitigations and Workarounds
At the top of this blog post, we listed the IIS configurations safe from this vulnerability. Each item could be turned into a workaround or mitigation.
Workarounds
Workaround #1: Turn off WebDAV
Turning off WebDAV might be a good option if you are not using it or can live without out until we have a security update available. You can find instructions at http://support.microsoft.com/kb/241520.
Workaround #2: Change filesystem ACL’s to deny access to IUSR_[MachineName]
Remember that there are two levels of permissions for files served by IIS. First, the user must be granted access by the NTFS file system and only then are the permissions in the IIS metabase checked. If you deny access to the webserver anonymous account (IUSR_[MachineName]), the access check bypassed by this vulnerability will not be reached. You can find instructions for hardening file system permissions on a webserver at http://support.microsoft.com/kb/271071.
Workaround #3: Use URLScan to block malicious requests.
URLScan helps protect affected systems from attempts to exploit this vulnerability. You can find instructions for deployment URLScan at http://technet.microsoft.com/en-us/security/cc242650.aspx.
Mitigations
Mitigation #1: WebDAV is disabled by default on IIS 6 (shipped with Windows Server 2003).
Mitigation #2: If a web server does not use IIS permissions to restrict access to content, this vulnerability is not relevant.
Mitigation #3: If a website uses forms-based authentication, this vulnerability is likely not relevant.
This access check bypass vulnerability is most likely to be hit for websites implementing basic, digest, or integrated authentication. Most Internet-based websites use forms-based authentication (username / password form typed into the server-side webpage). A forms authentication schema implemented as an ISAPI filter on PREPROC_HEADERS would not be susceptible to this vulnerability. However, a forms authentication scheme implemented in an ISAPI extension would be susceptible because WebDAV would still get the request.
Mitigation #4: IIS installer denies write access by default to the anonymous account (preventing webpages from being uploaded or modified using this vulnerability).
Thanks to Wade Hilmo and Nazim Lala of the IIS team for help investigating this issue.
If you have any questions, please send them in to secure@microsoft.com. Thanks.
- Jonathan Ness, MSRC Engineering
*Postings are provided “AS IS” with no warranties, and confers no rights.*