============================================================================ Breaking the Windows Server 2003 SP2 Stack by Nikolaos Rangos aka kcope/eliteb0y in 2008 / kcope2(at)googlemail.com ============================================================================ In this tutorial you can learn how to circumvent the stack protection of Windows Server 2003. It has to be said that the technique presented in this paper works on Service Pack 2 of the Windows Server 2003 Operating System. I don't claim that the information in this paper is something new. The described technique has been documented in the paper entitled "Advanced exploitation in exec-shield (Fedora Core case study)" by "dong-hun you" [1]. This paper describes circumventing the exec-shield protections of Linux systems but can also be applied to Windows Server systems. Normal exploitation of Windows stack based overflows is done by either redirecting EIP (the instruction pointer) to an attacker defined return address jumping onto the stack or through the SEH handler (Structured Exception Handler) method where the SEH chain is overwritten. Both exploitation methods only seem to work on Windows (Server) 2000 systems or even older Windows Operating systems. The exploitation method I want to present is a special return-into-libc technique. An example exploit using this technique is the "Bea Weblogic -- Apache Connector Remote Exploit" [2]. In this exploit the described technique is implemented. The first thing to do is to redirect EIP to 0x41414141 (Here we have to be careful to not overwrite the SEH chain). Now normally one would search for an address which allows to jump on the stack and execute the shellcode which is on the stack. Now for this new technique we will NOT search for a JMP ESP in memory space. When the executable is loaded into the OllDbg [3] debugger and the access violation kicks in because 0x41414141 is not an executable address the stack layout may look like the following: -overwritten addresses- -overwritten addresses- ....................... ....................... ....................... ....................... ....................... ....................... Pointer to our buffer ....................... ....................... The goal is to shift the "Pointer to our buffer" upwards in the stack layout just below a call to WinExec(). Ideally the stack layout would look like the following: -overwritten addresses- -overwritten addresses- Call to WinExec() Pointer to our buffer (can be "cmd.exe /c ...") ....................... ....................... If there is a call to WinExec() with the parameter "Pointer to our buffer" we have our code execution. Now how can we shift our buffer just below a call to WinExec() ? This is quite easy to do. We search the memory space of our process for POP+ret instructions. As an example there would be POP+POP+POP+RET instructions at 0x10020EBF: (Such instruction sets are very easy to find in the processes address space. The addresses used here are just examples) 10020EBF 5F POP EDI 10020EC0 5D POP EBP 10020EC1 5E POP ESI 10020EC2 C3 RETN If we now set our return address to 0x10020EBF instead of 0x41414141 the process will jump to that address and shift the stack. The RET instruction will return to the next bytes in our attack buffer: The address right after 0x10020EBF (which was 0x41414141 before). To illustrate that we can look at the Bea Weblogic exploit and it's attack buffer: --- snip --- #### STACKBREAKING WITH WINEXEC() ON WINDOWS my $c = "C" x 97 . pack("L", 0x10013930) x 3 . pack("L", 0x10013930) . pack("L", 0x10013931) . pack("L",0x77EA411E); my $a = $cmds . "A" x (4000-length($cmds)) . $c; ---snip--- There we have four times called the address at 0x10013930 and once the address at 0x10013931. These addresses are pointing to POP+RET instructions. After those instructions are called there is a call to WinExec(). It's address is at 0x77EA411E as seen in the attack string. When we call the POP+RET instructions at 0x10013930 and RETurn from that address there is a direct call to 0x10013930 again because this is the place the epilog (POP+RET instructions) will return, namely returning to our string again. So the described technique is nothing but shifting/adjusting the stack frame and when the "Pointer to our buffer" is reached a call to WinExec() (or ShellExecute/CreateProcess) to execute our commands. That's it - nothing more to say - it's pretty straightforward. References [1] Advanced exploitation in exec-shield (Fedora Core case study) by "dong-hun you", http://www.milw0rm.com/papers/151 [2] Bea Weblogic Remote Exploit, http://www.milw0rm.com/exploits/6089 [3] OllyDbg, http://www.ollydbg.de