Multi-Stage EIP redirection Buffer Overflow -- Win API / Socket Reuse

Kali Linux

Windows Vista

Vulnerable application: vulnserver.exe (KSTET)

Vulnserver.exe is meant to be exploited mainly with buffer overflows vulnerabilities. More info about this application and where to download it can be found here:

http://www.thegreycorner.com/2010/12/introducing-vulnserver.html

//*****//

We get the initial crash using the following fuzzer.

...and we get a pretty vanilla EIP overwrite buffer overflow.

Calculating the offset as usual using Metasploit's pattern_offset.rb and pattern_create.rb

We have our offset value so at this point we will need to find JMP ESP address and redirect EIP to it. We will use address 0x625011AF.

Note that you can use Immunity Debugger's mona.py or just search it manually.

Updated POC with the offset value and JMP ESP address.

As we examine the crash in Immunity Debugger, we can see the correct offset value and hit our JMP ESP address however, once the jump is taken, our Cs have been truncated. As a result, this only gives us a space of about 20 bytes.

That said, we will use the C buffer space to do a reverse jmp to A's address space which allowed for roughly about 66 bytes of address space.

Reverse jump EB B8 and will jump as from address 0x00D0F9E0 to 0x00D0F99A

We update and send our exploit...then take the jump.

Once again, we examine the crash and see that we have successfully landed on A's address space.

Now the fun part begins..thanks to https://purpl3f0xsec.tech/2019/09/04/Vulnserver-KSTET-Socket-Reuse.html for pointing out this type of vector.

Stolen from purpl3f0xsec...the diagram below shows how the socket connection is established between the client and the vulnserver.

Basically, we will utilize (reuse) the recv() function call. The idea is to utilize the established socket() connection and use the recv() as the first stage payload. Once the recv() function is up and running, we will then send our second stage payload.

The second stage payload will not overflow the buffer so it will not get truncated.

More information about the recv() can be found here: https://docs.microsoft.com/en-us/windows/win32/api/winsock/nf-winsock-recv

To set up recv(), we need the following parameters.

Socket = socket descriptor

Buffer = memory location for our second stage payload

BufferSize = memory space allocation for our second stage payload

Flags = Socket flags…can be set to Null

These are the parameters will need to be pushed to the stack (don't forget reverse order).

Before I populated the parameters, I grabbed the address of recv() which can be done by going in to the .text entry point and if we scroll down, we will find the functions.

Address 0x00401953 has the recv() but if you double click it...it shows the actual address which is 0x0040252C

I set a breakpoint at address 0x0040252C.

Once we hit our breakpoint, if you look at the stack, we can see the parameters that are currently loaded in the stack.

Note that at this point...both EAX and EBX registers have the socket descriptor value of 0x00000050. This is because of the instructions at these addresses: 0x0040194A and 0x00401950

0x0040194A - MOV EAX, DWORD PTR SS: [EBP-420]

This is a pointer to [EBP-420] so whatever the value loaded in [EBP-420] gets mov into EAX

We can see that EBP currently points to address 0x00EEFF88 so subtracting 420 should get us to the address that holds the socket descriptor.

As expected, if we jump to address 0x00EEFB68...we can see the value 0x00000050 loaded in.

Now, address 0x00401950 has the following instructions..

0x00401950 - MOV DWORD PTR SS:[ESP], EAX

This basically just loads the socket descriptor value stored in EAX, to the the [ESP] pointer. We can verify this by following ESP in the stack which currently points to address 0x011CF9E0

Next, we will load the value of socket descriptor to EAX. ASLR is enabled we will to do some math and ee will use ESP's address as a reference point.

We know that EBP register holds the socket descriptor located at address 0x00EEFB68. This means that we will need to do following:

0x00EEFB68 (EBP) - 0x00EEF9E0 (ESP) = 188 (in hex)

Great..so we will need to add 188 to ESP. We will do this by pushing ESP into stack, and pop it to EAX then add 188 to EAX. If our calculation is correct, we should have the socket descriptor address (0x00EEFB68) loaded to EAX.

We run the following instuctions:

PUSH ESP

POP EAX

ADD AX, 188

And we can see that address 00EEFB68 is now loaded in EAX which contains the socket descriptor value of 0x00000050 as shown in the stack.

Great...now we have the socket descriptor easily accessible!

Re-aligning ESP

At this point, we will have to re-align ESP so that we don't arbitrarily overlap with our first stage instructions. As we push more instructions to the stack, especially in a small address space, we risk overlaping our first stage with ESP.

That said, we need to move our ESP below where our first stage will be loaded.

We use the following instructions to adjust ESP:

SUB ESP, 6C ;SUB 108 from ESP

This makes ESP points to 0x00EEF974

***Note that towards the end of the exploit development, I found that ESP needed to point directly below the recv() parameters. That meant I had to adjust ESP and only subtracted 64 which pointed it to address 0x00EEF97C instead.

At this point, we have accomplished the following:

1. Located the address for the recv() function

2. Located the address that holds the socket descriptor value

3. Loaded the socket descriptor value to EAX

4. Aligned the stack to ensure our first stage does not overlap with ESP

Now we are ready to populate the parameters for our recv() function call.

Note that we need 4 parameters for the this function call pushed to the stack in reverse order.

0x1 - Param #4 (Flags)

Since we are not setting any flags, we will set this parameter to NULL.

Using the EBX register...we zero it out using XOR instruction before pushing it to the stack

XOR, EBX, EBX

PUSH EBX

0x2 - Param #3 (Buffer Size)

For the buffer size, I picked about 1024 bytes of buffer space which is a lot more than what we need.

Utilizing the EBX register again which is already set to zero...we will add 400 (in hex) to it.

ADD BH, 4

PUSH EBX

0x3 - Param # 2 (Buffer Location)

I initialy pointed the buffer location to beginning of the Cs (0x00EEF9E4), however, it didn't work so I had to point it directly right after the four parameters. In this case, the buffer location has to be pointed to address 0x00EEF97C

We can use the ESP address again...load the address into EBX then do some math which in this case I had to add 120 to ESP (HEX 78)

PUSH ESP

POP EBX

ADD EBX, 78

PUSH EBX

0x4 - Param #1 (Socket Descriptor)

Finally, for the socket descriptor we will need to access the value currently stored in EAX (not EAX address itself)

EAX is still pointing to 0x00EEFB68 that holds the socket descriptor value of 0x00000050

We can simply push the value stored in EAX using the following instruction:

PUSH DWORD PTR DS:[EAX]

...and we are done with the parameters.

At this point, we should have the following parameters.

Socket descriptor = 0x00000050

Buffer location = beginning of our C's (NOTE: this was adjusted to address 0x00EEF97C)

Buffer size = 400 (1024 in dec)

Flags = 0

Calling the RECV()

With the parameters set, we are now ready to call our RECV() function. Note that RECV() function is at adddress 0x0040252C

As you can see the recv() address contains null bytes which we will need to be removed. I learned something new from https://purpl3f0xsec.tech/2019/09/04/Vulnserver-KSTET-Socket-Reuse.html as to how to remove these null bytes.

We simply use an arbitrary address such as removing the null bytes and adding 90 for the lowest byte: 0x40252C90 instead of 0x0040252C

So we move this arbitrary address to EAX:

MOV EAX, 40252C90

Then we shift to right by 8 bits which removes the last 8 bits (0x90) and adds 00 to the first 8 bits

SHR EAX, 8

Finally, we simply CALL EAX

Here just right before we execute CALL EAX, we can see that it currently points to the recv() address

That is the entire first stage...and we update our POC as shown below

We fire up the exploit one more, step through the stager, and we can see that we have all 4 parameters ready to go…they are followed with the address of where our payload will be loaded.

Second Stage / Reverse Shell

With our RECV() function ready, we can send our second stage payload.

We update our POC and see if we can add the Ds to memory.

Noe that I added a sleep(5) in between first and second stage. This ensures that our RECV() fucntion is ready before we send the second stage payload.