IIS 5.0 WebDAV - Proof of concept - shellcode included

/*************************************/
/* 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