The offset and memory addresses shown here refer to a newly installed Win2k Server SP4 (English) system (with no hot fixes separately installed).
The software version used for these tests is 5.00.11 SP3 Unregistered File Version 5.0.13.0.The buffer overflow allows malicious code to overwrite EIP and consequently to cause a deviation in the process execution flow after the filling of the SELECTcommand’s
static buffer with 230 bytes. A string like the following overwrites the EIP with the not-valid memory address 0x42424242.
" SELECT " . ("A"x232) . ("B"x4)."\r\n";
The attacker, as in most typical stack overflows, has complete control over the EIP reg-istry.
The purpose is now to find out how to use the EIP control in order to allow our exploit to execute the code provided by the attacker.
Usually, on Windows-based operating systems, the stack overflow exploit is used by overwriting the EIP registry with an assembly instruction of type jmp reg,call reg, or push reg ret. Reg is the registry under our control. Overwriting EIP with a memory address from the stack where our nopsled resides, followed by the shell code is not, in fact, a possible technique (as on Linux) because the Windows ESP is not as stable as on a Linux-UNIX platform.
In our case, the registry that points to the attacking string is the EDI, as shown in Figure 7.1.
Figure 7.1 EDI Register Points to Our String
A memory address overwriting EIP with an assembly instruction such as jmp edi,call edi, or push edi retwould divert the program toward our payload.There are several libraries where these instructions exist. As an example, inside the advadpi32.dllwe can find the
instruction jmp edi at the memory address 0x7c2ec81b, while inside kernel32.dll the same instruction can be found at address 0x7c4efc92.
The memory address 0x0040c1b2 inside mcrimap4.exewould be an even more preferable choice: finding the instruction call ediinside the same executable could let us have a uni-versal return address that is always usable with any Windows system, regardless of its patching level.
A typical universal return address is the one used by the exploit BadBlue 2.5.
Unfortunately, there are some limits and issues to be considered. Inserting the shellcode inside the buffer before reaching the EIP doesn’t allow us enough available space to execute a remote shell on Windows.
Using the default metasploit encoder with a UNIX-restricted character generates a pay-load of at least 317 bytes. Hard-coded shellcode notwithstanding, the resulting code exceeds the space available to us by almost 100 bytes.
We might also insert the shellcode AFTER EIP, but a debug session shows us that only 57 bytes are usable in the stack.This is recognizable in esp, whereas memory address with the assembly instructions jmp esp,call esp, or push esp retwould allow us to jump that code.
Of course, we could also inject a first shellcode (egg) that, once recognized by a second payload (egghunt), would be then executed, but we can also follow a different option: using the copy of our string that can be found in other memory areas. On Windows, memory addresses usually begin with 0x00xxxxxx. At first site, might look like a problem.
The functions are typically subject to buffer overflows similar to that ok strcpy(). Let’s consider the opcode 0x00 as the end of the given string, whereas any code put after that opcode would be considered as a string ending, and then ignored. It’s not by chance, that our code has, among its BadCodes, the 0x00 opcode itself. If I overwrite the EIP with an address starting with 0x00, the string is truncated, and we obtain nothing as a result. But an alternate solution is possible. A simple test shows that if, instead of overwriting all of the four EIP bytes, we overwrite only three, then the fourth one (aka, the most important byte) is replaced by the opcode 0x00.
Consider the following sequence:
SELECT . ("A"x232) . ("B"x4)."\r\n";
overwrites the 0x42424242 memory address, then the string
SELECT . ("A"x231) . ("B"x4)."\r\n";
obtains, as a return address, 0x00424242.
The shellcode, here represented by 400 capital “c”, can be provided after the EIP with this string:
SELECT . ("A"x231) . ("B"x4)."\r\n".("\x90"x250)("C"x400)."\r\n";
A copy of the hexadecimal character \x43 (C) is present inside the memory address 0x0013e600. This means that if we provide a string as the one in the preceding example with the EIP pointing to that memory address where our code is present, then we have our remote shellcode (or something different, since we can obtain different payloads with metasploit).
Though it is not possible to jump inside the 400 bytes placed below the return address (see the Note that follows this paragraph), it is instead possible to do it inside another memory area, where the corresponding hexadecimal code can be found around the address 0x0013e50b, as shown in Figure 7.2.
N
OTEA copy of the shellcode can also be found inside the stack, and there could probably be ways to reach it, but we preferred to use a quicker, simpler option.
Figure 7.2Our String in Memory
Once this code is found, some of the characters cannot be sent to the attacked program (the BadChars from the code reported in this section). If, instead of the 400 “C”, we insert our nopsled, followed by the shellcode by overwriting EIP with the right return address, then our code will be executed.
Here’s how the final attack string will look like:
SELECT . ("A"x231) . (0x4313e50b)."\r\n".$nop.$shellcode."\r\n";
becomes
SELECT . ("A"x231) . (0x0013e50b)."\r\n".$nop.$shellcode."\r\n";
EIP is overwritten by the 0x0013e50b address, which points to the nopsled and then to the shellcode.
The nopsled can be made by a variable amount of chars (64, 100, 250, etc.), while the hex char “\x43” could be replaced by any other.
The debugger also shows how two instances of the same shellcode live inside the process space.Tests shows that it is possible to execute the payload sent using the EIP, which points to the 0x001414c8 memory address.