Breaking the Windows Server 2003 SP2 Stack

1. ============================================================================
2.   Breaking the Windows Server 2003 SP2 Stack
4.   by Nikolaos Rangos aka kcope/eliteb0y in 2008 / kcope2(at)googlemail.com
5. ============================================================================
7. In this tutorial you can learn how to circumvent the 
8. stack protection of Windows Server 2003.
10. It has to be said that the technique presented in this paper
11. works on Service Pack 2 of the Windows Server 2003 Operating System.
12. I don't claim that the information in this paper is something new.
13. The described technique has been documented in the paper entitled
14. "Advanced exploitation in exec-shield (Fedora Core case study)"
15. by "dong-hun you" [1]. This paper describes circumventing the
16. exec-shield protections of Linux systems but can also be applied
17. to Windows Server systems.
19. Normal exploitation of Windows stack based overflows is done by
20. either redirecting EIP (the instruction pointer) to an attacker
21. defined return address jumping onto the stack or through the 
22. SEH handler (Structured Exception Handler) method where the
23. SEH chain is overwritten. 
25. Both exploitation methods only seem to work on Windows (Server) 2000 
26. systems or even older Windows Operating systems.
28. The exploitation method I want to present is a special return-into-libc
29. technique.
30. An example exploit using this technique is the "Bea Weblogic -- Apache 
31. Connector Remote Exploit" [2]. In this exploit the described technique 
32. is implemented.
34. The first thing to do is to redirect EIP to 0x41414141 (Here we
35. have to be careful to not overwrite the SEH chain).
36. Now normally one would search for an address which allows to jump 
37. on the stack and execute the shellcode which is on the stack. 
38. Now for this new technique we will NOT search for a JMP ESP in memory 
39. space. 
40. When the executable is loaded into the OllDbg [3] debugger and the
41. access violation kicks in because 0x41414141 is not an executable
42. address the stack layout may look like the following:
44. -overwritten addresses-
45. -overwritten addresses-
46. .......................
47. .......................
48. .......................
49. .......................
50. .......................
51. .......................
52. Pointer to our buffer
53. .......................
54. .......................
56. The goal is to shift the "Pointer to our buffer" upwards in the stack
57. layout just below a call to WinExec().
59. Ideally the stack layout would look like the following:
61. -overwritten addresses-
62. -overwritten addresses-
63. Call to WinExec()
64. Pointer to our buffer (can be "cmd.exe /c ...")
65. .......................
66. .......................
68. If there is a call to WinExec() with the parameter "Pointer to our
69. buffer" we have our code execution.
71. Now how can we shift our buffer just below a call to WinExec() ?
72. This is quite easy to do. We search the memory space of our process
73. for POP+ret instructions.
75. As an example there would be POP+POP+POP+RET instructions at 0x10020EBF:
76. (Such instruction sets are very easy to find in the processes address 
77. space. The addresses used here are just examples)
79. 10020EBF   5F               POP EDI
80. 10020EC0   5D               POP EBP
81. 10020EC1   5E               POP ESI
82. 10020EC2   C3               RETN
84. If we now set our return address to 0x10020EBF instead of 0x41414141
85. the process will jump to that address and shift the stack.
86. The RET instruction will return to the next bytes in our attack buffer:
87. The address right after 0x10020EBF (which was 0x41414141 before).
88. To illustrate that we can look at the Bea Weblogic exploit and it's
89. attack buffer:
91. --- snip ---
92. #### STACKBREAKING WITH WINEXEC() ON WINDOWS
94. my $c = "C" x 97 . pack("L", 0x10013930) x 3 . pack("L", 0x10013930) . 
95.     pack("L", 0x10013931) . pack("L",0x77EA411E);
96. my $a = $cmds . "A" x (4000-length($cmds)) . $c;
98. ---snip---
100. There we have four times called the address at 0x10013930 and
101. once the address at 0x10013931. These addresses are pointing to POP+RET 
102. instructions. After those instructions are called there is a call
103. to WinExec(). It's address is at 0x77EA411E as seen in the attack
104. string.
106. When we call the POP+RET instructions at 0x10013930 and RETurn from
107. that address there is a direct call to 0x10013930 again because this
108. is the place the epilog (POP+RET instructions) will return, namely
109. returning to our string again.
111. So the described technique is nothing but shifting/adjusting the 
112. stack frame and when the "Pointer to our buffer" is reached 
113. a call to WinExec() (or ShellExecute/CreateProcess) to execute 
114. our commands.
116. That's it - nothing more to say - it's pretty straightforward.
119. References
121. [1] Advanced exploitation in exec-shield (Fedora Core case study) by
122.     "dong-hun you", http://www.milw0rm.com/papers/151
123. [2] Bea Weblogic Remote Exploit, http://www.milw0rm.com/exploits/6089
124. [3] OllyDbg, http://www.ollydbg.de