============================================================================
  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