

Table of Contents

Updates Bulletins Am I at risk ? Tools Technical details



0.1 Personal message

Several news stories seem to allude that Microsoft is artificially downplaying the threat, citations of myself are used to underline the headline in an "us against Microsoft" kind of way. I want to clarify that I have the utmost respect of the MSRC team and I don't suspect Microsoft to willingly downplay anything. They also claim I am from Belgium, I am obviously from Luxembourg. The bug also is not the same as the IIS4/5 one, it's root cause is similar. That's about it.









About:

The video above shows the different Webdav settings and the different impacts they have. Note that code execution is only possible if these pre-conditions are met. I am not sure how often this kind of setup exists, if I had to guess i'd say not often. Credit: Rangos.



1. Updates



25/05/2009 - Update: As Nicolaos wrote in the comment section of this post. IP/Domain filters can be bypassed the same way. In other words if you have a filter for certain IP adresses, you can bypass them.

Update : Todd Manning over at Breakpoint labs did comprehensive tests on which Unicode encodings work. The answer is a lot - IPS/IPS vendors should update their signatures.

Update : Sharepoint and OWA are not affected by this bug - more info here

Update : Skull security has a good write up here , they patched cadaver to exploit this vulnerability. Nmap script here.

Update: Video detailing the different settings and the different impacts (up to remote code execution) Credit: Rangos

Update: Nmap IIS6 Webdav scanner added to tools section.

Update: Webdav Network scanner added to tools section.

Update : Update : Microsoft SRD Team gives more insight and details (Must read)Update : http://www.microsoft.com/technet/security/advisory/971492.mspx

Update : For IIS 6 : Write access is not allowed per default - as such you can only "upload" content if IUSR_anonymous is granted write access. This is not the case per default.

Update : IIS5 and IIS7 are NOT affected - IIS5 and 5.1 are affected (according to MS

Update : It is unclear how this affects Exchange 2003 (which allows access to inboxes over webdav)

2. Bulletins

3. Am I at risk ?

Below is a summary by Microsofts SRD Team, please note that the below enumeration leads to think that the chances that your setup is vulnerable is VERY unlikely. IMHO this is not the case, take a standard install of IIS6, enable Webdav, setup a protected folder requiring basic auth. And that's it, you are vulnerable

not at risk

An IIS server not running WebDAV is safe.

The Windows Server 2003 IIS (version 6) shipped with WebDAV disabled by default.

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.

You are at risk

IF an IIS 5, 5.1, or 6.0 webserver is running with WebDAV enabled (default for IIS5) ;

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;

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;

file system access is granted for the restricted content to the IUSR_[MachineName] 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.

4 Test tools

Specificaly for this vulnerability: Metasploit added test script to the trunk

Webdav network scanner here

Nmap script

For PROPFIND the "translate:f" option is NOT required (only for GET requests)

Breakpoint labs analysed how the various UTF encodings affected the flaw - lot of variations work.

5. Details

Webdav is not enabled by default on IIS6, IIS7 + Webdav is not affected IIS 5 and IIS 5.1 are also affected. Enabling Webdav applies to all websites and doesn't have to be enabled per site. You can actually upload content to the web server, if the IUSR_anonymous has write access to webdav folders. (To any other folder if the account has write access to other folders)

This seems to have a similar (root cause) then the 2001 Unicode IIS4/5 bug , but not exactly the same "Translate:f" is required for GET requests, PROPFIND works without the translate optiion.

Temporary disable Webdav. This is not easy if you have Sharepoint services running. See here

Backround

In 2001 a path traversal bug was found in IIS4 and IIS5 that lead to a series of serious compromised and massive exploitation (MS01-026). It was bad really bad, the simple path traversal was used to compromise systems remotely mainly through calling (t)ftp.exe to upload arbitrary content.





nicode conversion was added AFTER the security checks and not before , resulting in the path "..%c0%af.." to be considered a VALID path, yet it is nothing else then "../.." in ascii. More details can be found The path traversal was possible due to Microsoft's introduction of UNICODE support into IIS. The flaw was by design, a typical logical fallacy. U, resulting in the path "..%c0%af.." to be considered a VALID path, yet it is nothing else then "../.." in ascii. More details can be found here

Figure1 IIS4/5 how the security check was supposed to work (click to enlarge)

Figure 2 - IIS4/5 how the security check was implemented (click to enlarge)



In other words Microsoft, certainly through the late addition of Unicode support to IIS, failed to realize that converting chars to Unicode representation should happen before any "security" checks. So the flaw was one of logic, Unicode conversion after the security check.

MS09-

971492

- 2009

The bug discovered by Rangos seems to suffer from a similar logic mistake when requesting source (translate:f) that has been introduced in the Webdav component. It appears that unicode characters are removed after the security checks.

Figure 3 - IIS6 Webdav component Unicode replacement (click to enlarge)



Details



Example: Uploading arbritary content to an asp page - Creating ASP files only works if "Script Source Access" is enabled and IUSR_Anonymous has write access to the folder. Creating INC files works even if with "script source access disabled". (Source : Hubert.Seiwert)

PUT /protected %c0%af /hello.asp HTTP/1.1

Host: 192.168.171.142

Translate: f

Content-Length: 27

<%response.write("hello")%> Example: Uploading arbritary content to an asp page - Creating ASP files only works if "Script Source Access" is enabledIUSR_Anonymous has write access to the folder. Creating INC files works even if with "script source access disabled". (Source : Hubert.Seiwert)

IUSR_Anonymous has write access to the folder in question If you map the root (or any other) WWW folder to the webdav folder (an hence can issue a simply GET request to the uploaded file)

You areif : (Source : Microsoft SRD Team): (Source Microsoft SRD Team, except italics by myself)IDS/IPS SignaturesRecommendation : until the impact is 100% clear you should temporarily disable Webdav or follow the mitigation recommendations from Microsofts SRD teamKingcope a.k.a Nicolaos Rangos released another pwnie grade vulnerability yesterday and it's resemblance to the IIS unicode flaw from 2001 was so similar that my jaw first dropped.Here are a few facts, these are subject to modifications as the news unfolds:Mitigation :- 2001Here is the logic flaw that lead to the vulnerability in 2001. I quickly drafted this in Visio, below is the way it was supposed to work:Here is how it was implemented :Fast forward 2009 - Kingcope releases a similar vulnerability.The server will however not execute this asp page - currently no code execution is known to be possible, even if write access is enabled (see exception below). The reason is that you can't simply issue a GET request to the asp page you just created - it's password protected and execution over webdav fails.However code execution would be possible in scenarios where :