SEH Overflow Vuln Server (GMON)

Hey friends. Let's deep dive into a structured exception handler overflow on Vuln server.

Playing with the vuln server with ncat we can see the commands it takes and that it takes inputs. I decided on GMON. I then fired up IDA pro.

I quickly find GMON via the strings search and begin my static analysis.

First, we walk the program with the help of Windbg and Ida pro. We first discover the requirement of "GMON " The space after GMON is required as denoted in the 5 bytes prior to the GMON check. TLDR...... the space is important.

Next, we see a compare of our user input for 2fh. Which is ascii is a "/". This is yet another requirement to take the path to our desired buffer.

We now see another logic gate checking string length of our user input vs 0f6E.

A little calculator-fu reveals it requires our input to be at least 3950 bytes in length to reach GMON buffer.

Which leads us to our vulnerable function STRCPY which doesn't do bounds checking of user input, leading to buffer overflow.

Now let's exploit it. Over to our Kali Linux we go.

We send an evil buffer of "GMON" a "/" and 5000 A's.

Back over to our windows 10 lab. We set up Vuln Server and attach WinDbg. We then set a break point on the receive function. This will allow us to see if our data has been accepted by the server.

Our break point has been hit! We know we can hit the recv() function. We hit continue to see if the buffer overflows.

We get a first chance access violation. However, we do not have control of EIP. EDX appears to point to our controlled buffer of A's (41 in hex).

It appears to be a SEH overflow. I hit !exchain to check the exception handlers of this specific thread. It verifies I have overwritten the structed exception handler. Fun!

Control of EIP. We have a structured exception handler overflow on our hands.

So, what's a SEH? Let's dive in.

What occurred was a hardware exception. The Vuln Server went to read its exception handler and came across an invalid address of 41414141; our A's. The SEH handles software and hardware exceptions and is a nested list that sits inside the Thread execution block at offset 0, which is nt_tib(NT Thread information block).

if we dump the NT_TIB we find the exception registration record.

Dumping that structure we find the SEH. As you can see, we have the handler (SEH) and next. If the current handler cannot continue execution after the exception, it goes down through the list via next until it finds a way to handle the exception. We have overwritten this structure and now have control of EIP.

Back to Kali.

Next, we need to find the size of the buffer we just overflowed. Using MSF-Pattern-create we create a unique string of ASCII characters that we will attach to our evil buffer. Whatever overwrites the EIP we will copy and put into MSF-Pattern_offset to determine the size of our buffer.

Let's put it into an exploit and send it to our vuln server. This time I won't set a break point I'll just hit continue until it overflows EIP.

Our buffer overflows and EIP holds the unique string 356f4534.

Placed in pattern offset we discover our buffer is 3554 bytes.

Let's build our skeleton exploit. We use "GMON " and "/" . I set a skeleton of "BBBB" for the NSEH overwrite. I place CCCC in place of our SEH which will later hold a pop pop ret gadget. My D's is a placeholder for my future shellcode.

We have done our math correctly and EIP (SEH) is overwritten with our skeleton script of C's (43434343).Our Next SEH is overwritten with our B's. Life is good.

Next let's check for bad characters.

Our new script has a list of characters that may cause problems with our input. Most of us know of x00 being a null terminator that we cannot have in our shellcode or gadgets. However, many characters may cause truncation of your payload and is very much buffer dependent. Let's send a list and see what characters make it through to our buffer.

We look at the third address down from ESP to the establisher frame. We discover our space after the SEH is very tiny. We cannot hold a shellcode here as we first anticipated. We split our bad character buffer into 30 bytes and discover only 00 is a problem. Now we know what characters we cannot have in our shellcode or gadgets. This is also a great time to explain my need for a POP POP RET gadget. At crash we pop the Execute handler (008dec80) and Nseh(008dec84) off the stack and return into the establisher frame (008dec88). The first character in the buffer as you can see is 42424242 which is our NSEH and 43434343 our SEH. We will place a short jump of 6 bytes on NSEH(42424242) which will jump over our SEH 43's into our small but controlled buffer.

I have a ton of space within the buffer for a shellcode. I can use some NOP's /x90 and a near jump after the short jump to jump back into my shellcode. Let's do it!

Next, we search vuln servers' memory for pop pop ret sequences. Once we run it in WinDbg we get some hits!!

Unpacking the gadgets we see a few options we can use to pop two things off the stack and move the ESP into the establisher frame. This gadget will pop two things off the stack into EAX register and return into the establisher frame.

We place our shellcode inside our buffer. We add our pop pop ret gadget to our SEH. We set up a short jump on the NSEH of 6 bytes to jump over SEH. It jumps into our nops of the establisher frame and then our -400 byte near jump back into our main buffer. This lands us in our shellcode nops and we pwn the server!!!!

We set a break point on our pop pop ret gadget which we will hit first; and send our exploit.

SUCCESS!!! We hit our first exception. When SEH is hit sets off our pop pop ret gadget. We return into our establisher frame and hit our NSEH which has our short jump eb6. This jumps over the SEH and into our controlled buffer. We hit our nops and into a near jump backward to 00a1fde9. Unpacked we can see we are into our shellcode nops!!

We set up a listener and resend our payload. Full Meterpreter shell! Server pwned.