Exploit-DB #2
Description: Microsoft IIS 5.0 - WebDAV Remote
Type: remote
Platform: windows
Date: 2003-03-24
Author: RoMaNSoFt

Exploit:
/*************************************/
/* IIS 5.0 WebDAV -Proof of concept- */
/* [ Bug: CAN-2003-0109 ] */
/* By Roman Medina-Heigl Hernandez */
/* aka RoMaNSoFt <roman@rs-labs.com> */
/* Madrid, 23.Mar.2003 */
/* ================================= */
/* Public release. Version 1. */
/* --------------------------------- */
/*************************************/
/* ====================================================================
* --[ READ ME ]
* 
* This exploit is mainly a proof of concept of the recently discovered ntdll.dll bug (which may be
* exploited in many other programs, not necessarily IIS). Practical exploitation is not as easy as
* expected due to difficult RET guessing mixed with possible IIS crashes (which makes RET brute
* forcing a tedious work). The shellcode included here will bind a cmd.exe shell to a given port
* at the victim machine so it could be problematic if that machine is protected behind a firewall.
* For all these reasons, the scope of this code is limited and mainly intended for educational
* purposes. I am not responsible of possible damages created by the use of this exploit code.
* 
* The program sends a HTTP request like this:
* 
* SEARCH /[nop] [ret][ret][ret] ... [ret] [nop][nop][nop][nop][nop] ... [nop] [jmpcode] HTTP/1.1
* {HTTP headers here}
* {HTTP body with webDAV content}
* 0x01 [shellcode]
* 
* IIS converts the first ascii string ([nop]...[jmpcode]) to Unicode using UTF-16 encoding (for
* instance, 0x41 becomes 0x41 0x00, i.e. an extra 0x00 byte is added) and it is the resultant
* Unicode string the one producing the overflow. So at first glance, we cannot include code here
* (more on this later) because it would get corrupted by 0x00 (and other) inserted bytes. Not at
* least using the common method. Another problem that we will have to live with is our RET value
* being padded with null bytes, so if we use 0xabcd in our string, the real RET value (i.e. the
* one EIP will be overwritten with) would be 0x00ab00cd. This is an important restriction.
* 
* We have two alternatives:
*
* 1) The easy one: find any occurrences of our ascii string (i.e. before it gets converted to
* the Unicode form) in process memory. Problem: normally we should find it by debugging the
* vulnerable application and then hardcode the found address (which will be the RET address)
* in our exploit code. This RET address is variable, even for the same version of OS and app
* (I mean, different instances of the same application in the same machine could make the
* guessed RET address invalid at different moments). Now add the restriction of RET value
* padded with null-bytes. Anyway, the main advantage of this method is that we will not have
* to deal with 0x00-padded shellcode.
* 
* 2) The not so-easy one: you could insert an encoded shellcode in such a way that when the app
* expands the ascii string (with the encoded shellcode) to Unicode, a valid shellcode is
* automagically placed into memory. Please, refer to Chris Anley's "venetian exploit" paper
* to read more about this. Dave Aitel also has a good paper about this technique and indeed
* he released code written in Python to encode shellcode (I'm wondering if he will release a
* working tool for that purpose, since the actual code was released as part of a commercial
* product, so it cannot be run without buying the whole product, despite the module itself
* being free!). Problem: it is not so easy as the first method ;-) Advantage: when the over-
* flow happens, some registers may point to our Unicoded string (where our Unicoded-shellcode
* lives in), so we don't need to guess the address where shellcode will be placed and the
* chance of a successful exploitation is greatly improved. For instance, in this case, when
* IIS is overflowed, ECX register points to the Unicode string. The idea is then fill in
* RET value with the fixed address of code like "call %ecx". This code may be contained in
* any previosly-loaded library, for example).
* 
* Well, guess it... yes... I chose the easy method :-) Perhaps I will rewrite the exploit
* using method 2, but I cannot promise that.
* 
* Let's see another problem of the method 1 (which I have used). Not all Unicode conversions
* result in a 0x00 byte being added. This is true for ascii characters lower or equal to 0x7f
* (except for some few special characters, I'm not sure). But our shellcode will have bytes
* greater than 0x7f value. So we don't know the exact length of the Unicoded-string containing
* our shellcode (some ascii chars will expand to more than 2 bytes, I think). As a result,
* sometimes the exploit may not work, because no exact length is matched. For instance, if you
* carry out experiments on this issue, you could see that IIS crashes (overflow occurs) when
* entering a query like SEARCH /AAAA...AAA HTTP/1.1, with 65535 A's. Same happens with 65536.
* But with different values seems NOT to work. So matching the exact length is important here!
* 
* What I have done, it is to include a little "jumpcode" instead of the shellcode itself. The
* jumpcode is placed into the "critical" place and has a fixed length, so our string has always
* a fixed length, too. The "variable" part (the shellcode) is placed at the end of the HTTP
* request (so you can insert your own shellcode and remove the one I'm using here, with no apparent
* problem). To be precise, the end of the request will be: 0x01 [shellcode]. The 0x01 byte marks
* the beginning of the shellcode and it is used by the jumpcode to find the address where shell-
* code begins and jump into it. It is not possible to hardcode a relative jump, because HTTP
* headers have a variable length (think about the "Host:" header and you will understand what
* I'm saying). Well, really, the exploit could have calculated the relative jump itself (other
* problems arise like null-bytes possibly contained in the offset field) but I hav