IIS 6 / IIS 5 / IIS 5.1+ Webdav auth bypass [Final]
| 0 comments ]


Table of Contents

  1. Updates
  2. Bulletins
  3. Am I at risk ?
  4. Tools
  5. 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 : Microsoft SRD Team gives more insight and details (Must read)
Update : Microsoft advisory : 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.

You are not at risk if : (Source : Microsoft SRD Team)
  • 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.
You are at risk : (Source Microsoft SRD Team, except italics by myself)
  • IF an IIS 5, 5.1, or 6.0 webserver is running with WebDAV enabled (default for IIS5);
  • 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.
4 Test tools
  • Specificaly for this vulnerability: Metasploit added test script to the trunk
  • Webdav network scanner here
  • Nmap script
IDS/IPS Signatures
  • 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.
Recommendation : until the impact is 100% clear you should temporarily disable Webdav or follow the mitigation recommendations from Microsofts SRD team


5. Details

Kingcope 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:
  1. Webdav is not enabled by default on IIS6, IIS7 + Webdav is not affected
  2. IIS 5 and IIS 5.1 are also affected.
  3. Enabling Webdav applies to all websites and doesn't have to be enabled per site.
  4. 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)
  5. This seems to have a similar (root cause) then the 2001 Unicode IIS4/5 bug , but not exactly the same
  6. "Translate:f" is required for GET requests, PROPFIND works without the translate optiion.
Mitigation :
  1. 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.

The path traversal was possible due to Microsoft's introduction of UNICODE support into IIS. The flaw was by design, a typical logical fallacy. Unicode 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 here.

MS01-26 - 2001
Here 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:

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

Here is how it was implemented :



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.

Fast forward 2009 - Kingcope releases a similar vulnerability.

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")%>
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 :
  1. IUSR_Anonymous has write access to the folder in question
  2. 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)



0 comments

Post a Comment