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.

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.
Video detailing the different settings and the different impacts (up to remote code execution) Credit: Rangos
Nmap IIS6 Webdav scanner added to tools section.
Webdav Network scanner added to tools section.Update : Microsoft SRD Team gives more insight and details (Must read)
Update :
Microsoft advisory :
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
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)


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
Translate: f
Content-Length: 27
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)


nikos said... @ 16 May, 2009 01:06

Nice pictures, hope to get pwnied :)

Vinícius K-Max said... @ 16 May, 2009 01:52

Very nice post.

PS: figure 1 and figure 2 are inverted? Maybe influence of pharmaceutical drugs :D

j0rd4n14n.r1z said... @ 16 May, 2009 02:49
This comment has been removed by a blog administrator.
thotho said... @ 16 May, 2009 15:53

no one talked about the uploading part and how it should work .
and another thing is there any way to know if a server has webdav installed or not ?


WBS said... @ 16 May, 2009 17:27
This comment has been removed by a blog administrator.
Anonymous said... @ 17 May, 2009 01:11

You can see if it is installed by checking Add/Remove programs | Add/Remove windows components | IIS | WWW service

Hubert said... @ 18 May, 2009 00:05

Figure 3 is a dupe of Figure 1?

Anonymous said... @ 19 May, 2009 00:21

Last weekend on 15/5/09 our web server folders were injected with new files (default.htm, index.htm,etc...) owned by the internet guest account. No log files indicate this activity. Could this be the same issue. We run 2 servers on the same domain and one of them is running exchange?

odogg said... @ 19 May, 2009 11:55

Official Advisory is published:

Andrew said... @ 21 May, 2009 06:02

Good info here.

@thotho, I was able to get upload working on IIS 6.0, also there are some updates to the nmap script (grab the latest svn) that does WebDAV detection.

What I'm really looking for is info on how IIS 5.0 is vulnerable, I couldn't reproduce it in a lab. I could reproduce IIS 6.0 and IIS 5.1 however and posted about it at


nikos said... @ 23 May, 2009 00:28

+The bug bypasses IP- and Domain-Based Access Restrictions.

bykedar said... @ 02 June, 2009 11:14

Are Tipping Point IPS , Jubiper IDP signatures available for these vulnerabilities

betrader said... @ 05 December, 2010 19:15

très bon travail,de très grandes qualités,en plus du talent indéniable!

Lisa said... @ 31 March, 2011 19:05

Nice pictures, thanks for sharing.

muondo said... @ 28 May, 2011 17:35

génial bravo continue!

diary said... @ 18 October, 2011 20:56

bravo j'aime beaucoup ton blog, le contenu est toujours d'excellente facture!

uruk said... @ 04 November, 2011 02:27

génial bien que je ne comprends pas tout merci de toute tes infos!

jimcircus said... @ 06 November, 2011 10:40

bravo un très bon blog très bien fourni!

hopkins richard said... @ 09 November, 2011 20:47

un très bon blog très bien expliqué et assez bien fourni!

lila scott said... @ 08 April, 2012 13:03

nice blog, a great job!

EAP-TTLS said... @ 15 December, 2012 14:02

Configuring your client adapter with a static wired equivalency private (WEP) key improves the security of your wireless transmissions. The access point is configured with the same 40 bit or 128 bit WEP key and during association those encrypted keys are compared. The issue is hackers can intercept wireless packets and decode your WEP key.

Post a Comment