GitBook: [master] one page and 37 assets modified

offensive-security/code-injection-process-injection/binary-exploitation/seh-based-buffer-overflow.md

@@ -98,23 +98,23 @@ dt _EXCEPTION_REGISTRATION_RECORD 00cff2cc
 From this point the`ExceptionList` address changed from `00cff2cc` to `00cff274` due to the deugging program being restarted. This may happen multiple time throughout the labs.
 {% endhint %}
 
-![Start of the SEH chain at 00cff274](../../../.gitbook/assets/image%20%28989%29.png)
+![Start of the SEH chain at 00cff274](../../../.gitbook/assets/image%20%28990%29.png)
 
 Below gif demonstrates how we can get the address of the head of the SEH chain with `!teb` command and by inspecting the `ExceptionList`. We can then walk through all the registered SEH records in the SEH chain and observe how the last SEH record indicates that the next SEH records is at `0xffffffff`: \(meaning, it is actually the last record and there's no next SEH record in the chain\):
 
 ![Walking through the SEH chain in WinDBG](../../../.gitbook/assets/teb-seh-chain.gif)
 
 Note, however, that these SEH records are the exception handlers defined in the ntdll and not in our compiled binary:
 
-![](../../../.gitbook/assets/image%20%281005%29.png)
+![](../../../.gitbook/assets/image%20%281006%29.png)
 
 In order to see the SEH records defined by our program, we need it to execute the `try` / `catch` code block that we have in the `main()` function. Let's see the CPU instructions at our program's entry point:
 
 ```text
 u $exentry
 ```
 
-![A bunch of jmp instructions in our seh-overflow.exe entry point](../../../.gitbook/assets/image%20%281015%29.png)
+![A bunch of jmp instructions in our seh-overflow.exe entry point](../../../.gitbook/assets/image%20%281019%29.png)
 
 At this point, I do not know what the deal is with all the jmps, but let's try setting a breakpoint at `00e1911d` \(2nd `jmp` instruction\), right after the first `jmp` at `00e19118` and continue with execution:
 
@@ -123,11 +123,11 @@ bp $exentry + 5
 g
 ```
 
-![Breakpoint hit at the Image Entry](../../../.gitbook/assets/image%20%281006%29.png)
+![Breakpoint hit at the Image Entry](../../../.gitbook/assets/image%20%281007%29.png)
 
 Let's now see where the SEH head is at:
 
-![SEH chain starts at 00bbfb2c](../../../.gitbook/assets/image%20%281000%29.png)
+![SEH chain starts at 00bbfb2c](../../../.gitbook/assets/image%20%281001%29.png)
 
 We can now see that the start of the SEH chain has changed and is at `00bbfb2c`, so let's check the first SEH record:
 
@@ -143,21 +143,25 @@ The exception handler for the first SEH record is at `0x00e220f0`. Let's see whi
 u 0x00e220f0
 ```
 
-![0x00e220f0 is the 1st exception handler of seh-overflow.exe](../../../.gitbook/assets/image%20%281009%29.png)
+![0x00e220f0 is the 1st exception handler of seh-overflow.exe](../../../.gitbook/assets/image%20%281010%29.png)
 
 The above image confirms that `0x00e220f0` is inside our seh-overflow.exe image and we're inspecting the SEH chain from our seh-overflow.exe.
 
-We can more easily discover SEH records using xdbg by inspecting the SEH tab as shown below:
+WinDBG has a command to explore SEH chains `!exchain`:
 
-![Inspecting SEH chains using xdbg](../../../.gitbook/assets/image%20%28992%29.png)
+![](../../../.gitbook/assets/image%20%281012%29.png)
+
+We can also easily discover SEH records using xdbg by inspecting the SEH tab as shown below:
+
+![Inspecting SEH chains using xdbg](../../../.gitbook/assets/image%20%28993%29.png)
 
 Below shows how SEH records 1 to 4 \(right\) are organized on the program's stack \(left\):
 
 ![SEH chain on the stack](../../../.gitbook/assets/image%20%28986%29.png)
 
 If we updated our very first diagram showing where SEH chain is located and how it looks like with actual memory addresses, it would now look like this:
 
-![TEB / TIB / SEH chain with actual memory addresses](../../../.gitbook/assets/image%20%281016%29.png)
+![TEB / TIB / SEH chain with actual memory addresses](../../../.gitbook/assets/image%20%281020%29.png)
 
 Note that the exception handler at `0x00e220f0`, when we identified it previously using WinDbg after executing the first `jmp` inside the seh-overflow.exe entry point, was the first SEH record in the chain, however, inspecting the SEH chain in xdbg, we can see that the handler `0x00e220f0` actually belongs to the second SEH record, which suggests that executing the first `jmp` was not enough to set up the full SEH chain. That, however, does not prevent us from moving this lab further into the exploitation phase, but it's just something to note if you're playing along.
 
@@ -178,27 +182,27 @@ The following exploitation steps will not be detailed, since they can be found i
 
 Let's open RGUI.exe in xdbg and hit F9 as many times as we need in order to get the program's GUI to show up:
 
-![RGUI showing up after launching it via xdbg](../../../.gitbook/assets/image%20%281004%29.png)
+![RGUI showing up after launching it via xdbg](../../../.gitbook/assets/image%20%281005%29.png)
 
 Let's generate some garbage data that we will send to the RGUI in order to confirm we can crash it:
 
 ```python
 python -c "print('A'*3000)" | clip.exe
 ```
 
-![Generating garbage data using python](../../../.gitbook/assets/image%20%28991%29.png)
+![Generating garbage data using python](../../../.gitbook/assets/image%20%28992%29.png)
 
 Open the RGUI configuration editor and paste the garbage data generated into the "Language for menus and messages" input box as shown and click OK and then OK once more:
 
 ![Sending garbage data to RGUI to confirm we can crash it and check if it's vulnerable to overflows](../../../.gitbook/assets/crashing-rgui.gif)
 
 At this point, looking at xdbg, we can confirm the program crashed and is vulnerable to a classic buffer overflow as we were able to overwrite the EIP register with our AAAA \(0x41414141\):
 
-![Program is vulnerable to a classic buffer overflow - EIP is overwritten](../../../.gitbook/assets/image%20%281001%29.png)
+![Program is vulnerable to a classic buffer overflow - EIP is overwritten](../../../.gitbook/assets/image%20%281002%29.png)
 
 More, importantly, however, we confirm that the program is also vulnerable to the SEH overflow by inspecting the SEH chain tab:
 
-![Program confirmed to be vulnerable to SEH overflow - SEH record is overwrriten](../../../.gitbook/assets/image%20%281018%29.png)
+![Program confirmed to be vulnerable to SEH overflow - SEH record is overwrriten](../../../.gitbook/assets/image%20%281022%29.png)
 
 Note from above screenshot that the first SEH record was overwritten in the following manner:
 
@@ -218,21 +222,21 @@ We also know that SEH records are stored on the stack and each one is an 8 byte
 
 Based on the above, in order to confirm the SEH record offset, we should generate a dummy payload that is structured like so:
 
-![Payload structure high level view](../../../.gitbook/assets/image%20%28995%29.png)
+![Payload structure high level view](../../../.gitbook/assets/image%20%28996%29.png)
 
 Following the [Finding EIP offset](stack-based-buffer-overflow.md#finding-eip-offset) technique, we identity that the SEH record offset into the stack is `1012`.
 
 Based on all of the above, our payload for testing, if we can correctly overwrite the SEH record \(its pointer to the next SEH record and current SEH record's handler\), should now look like this:
 
-![Payload structure with offset to the SEH record](../../../.gitbook/assets/image%20%281019%29.png)
+![Payload structure with offset to the SEH record](../../../.gitbook/assets/image%20%281023%29.png)
 
 Let's create the above payload:
 
 ```python
 python -c "print('A'*1012 + 'BBBB' + 'CCCC')" | clip.exe
 ```
 
-![](../../../.gitbook/assets/image%20%281002%29.png)
+![](../../../.gitbook/assets/image%20%281003%29.png)
 
 ...and send it to the vulnerable program and see if we can overwrite the SEH record, located at `0141e768` correctly:
 
@@ -251,15 +255,15 @@ From the above screenshote we can see that we can overwrite the SEH record corre
 
 ### POP POP RET
 
-Next, we will need to find a memory address in the vulnerable program that contains `pop pop ret` gadget. Let's see why we need this ROP gadget.
+Next, we will need to find a memory address in the vulnerable program that contains `pop pop ret` gadget. Let's see why we need this ROP gadget - hint: so that we can jump to the next SEH record in the chain, that we in fact can control, from which we can jump to the shellcode.
 
 Useful notes about ROP gadgets:
 
 {% page-ref page="rop-chaining-return-oriented-programming.md" %}
 
 Let's send `1012*A` to the vulnerable program and upon crashing it, inspect the SEH chain:
 
-![SEH chain at time of the crash](../../../.gitbook/assets/image%20%28996%29.png)
+![SEH chain at time of the crash](../../../.gitbook/assets/image%20%28997%29.png)
 
 Note the first SEH record is at address `0141E768` and its handler is at `76275680`.
 
@@ -269,9 +273,9 @@ Again, it is important to remember / realize that we control/can overwrite the S
 
 Let's set a breakpoint on the handler at `76275680`, continue execution until that breakpoint is hit, then inspect the SEH chain and the stack's contents:
 
-![Breakopoint hit at 76275680. 0141E768 is the SEH record we control and it's 3 values below the top of the stack](../../../.gitbook/assets/image%20%28998%29.png)
+![Breakopoint hit at 76275680. 0141E768 is the SEH record we control and it's 3 values below the top of the stack](../../../.gitbook/assets/image%20%28999%29.png)
 
-Once the breakpoint is hit at `76275680`, we can see that the address `0141E768`, which is the address of the next SEH record \(which we control\) is on the stack and it's just 3 values below the top of the stack. This means that if we could overwrite the current SEH record's `0141E768` handler, currently pointing to `76275680`, to a memory address that contains `pop pop ret` instructions, we could transfer the program's execution control to `0141E768` and from there, execute our shellcode. We will test this in a moment.
+Once the breakpoint is hit at `76275680`, we can see that the address `0141E768`, which is the address of the next SEH record \(which we control\) is on the stack and it's just 3 values below the top of the stack. This means that if we could overwrite the current SEH record's `0141E768` handler, currently pointing to `76275680`, to a memory address that contains `pop pop ret` instructions, we could transfer the program's execution control to `0141E768` \(a SEH record that we control\) and from there, execute our shellcode. We will test this in a moment.
 
 ### Finding POP POP RET
 
@@ -281,15 +285,19 @@ To find memory addresses containing `pop pop ret` instructions, we can search al
 Any other byte pattern that translates to `pop pop ret` should work too.
 {% endhint %}
 
-![Finding pop pop ret instructions using byte pattern search in all modules](../../../.gitbook/assets/image%20%281014%29.png)
+![Finding pop pop ret instructions using byte pattern search in all modules](../../../.gitbook/assets/image%20%281018%29.png)
 
 There are multiple results found as shown below. Let's chose the first one that contains executable instructions at `0x637412c8` and set a breakpoint on it by hitting F2:
 
-![Breakpoint is set at 0x637412c8, it contains pop pop ret instructions](../../../.gitbook/assets/image%20%281013%29.png)
+![Breakpoint is set at 0x637412c8, it contains pop pop ret instructions](../../../.gitbook/assets/image%20%281016%29.png)
 
 ### Overwriting SEH Record and Subverting Code Execution Flow
 
-Let's now start our python exploit skeleton as shown below:
+We now know that our payload should look like this:
+
+![](../../../.gitbook/assets/image%20%281017%29.png)
+
+So wen can start building our python exploit skeleton as shown below:
 
 {% code title="exploit.py" %}
 ```python
@@ -316,7 +324,7 @@ Executing `exploit.py` will create `payload.txt` with our payload, which when se
 
 Below shows the `payload.txt` file contents:
 
-![Payload.txt contents](../../../.gitbook/assets/image%20%28987%29.png)
+![Payload.txt contents](../../../.gitbook/assets/image%20%28988%29.png)
 
 Let's send that payload to the RGUI:
 
@@ -330,7 +338,11 @@ Note from the above gif the key points:
 
 ### Adding Shellcode
 
-Let's modify our exploit skeleton slightly, to include the shellcode that pops a calculator:
+We're now ready to start suplementing our payload with shellcode. Our payload should now look like this:
+
+![](../../../.gitbook/assets/image%20%28987%29.png)
+
+Let's modify our exploit skeleton to include some shellcode that pops a calculator:
 
 {% code title="exploit.py" %}
 ```python
@@ -377,7 +389,7 @@ f.close()
 
 ...and send it to RGUI. Observe the crash, continue running the program until the breakpoint at `0x637412c8` is hit and inspect the memory at `0141E768`, where our SEH record, that we've just overflowed, lives. This is where we will jump to after the `pop pop ret` instructions will complete at `0x637412c8`:
 
-![Payload is organized in program's memory](../../../.gitbook/assets/image%20%281008%29.png)
+![Payload is organized in program's memory](../../../.gitbook/assets/image%20%281009%29.png)
 
 From the above screenshot, we can derive the following key point - once we land on `0141E768` \(red zone\), which contains the 4 bytes representing our string `BOOM`, we need to jump over to our shellcode in the blue zone.
 
@@ -392,6 +404,10 @@ payload += b"\xeb\x06\x90\x90"
 
 Note that even though we say we're jumping over 6 bytes into the code, but in fact, we are jumping over 8 bytes, because the `jmp` instruction itself is 2 bytes, so therefore 2+6=8. Essentially, we are jumping over the SEH record itself after which our shellcode lives.
 
+Our payload visually should now look like this:
+
+![](../../../.gitbook/assets/image%20%281014%29.png)
+
 ### Exploit
 
 Let's see the full updated exploit code now:
@@ -441,7 +457,7 @@ f.close()
 
 Let's send the payload to RGUI and observe the stack once the payload is sent to the program:
 
-![Stack memory layout after the payload is sent to the program](../../../.gitbook/assets/image%20%28993%29.png)
+![Stack memory layout after the payload is sent to the program](../../../.gitbook/assets/image%20%28994%29.png)
 
 Below gif captures the full exploitation process:
 
@@ -457,7 +473,7 @@ From above screenshot, note the following key points:
 
 We can summarize that SEH overflow exploitation at a high level works as shown in the below diagram:
 
-![SEH overflow exploitation process overview](../../../.gitbook/assets/image%20%281007%29.png)
+![SEH overflow exploitation process overview](../../../.gitbook/assets/image%20%281008%29.png)
 
 1. Payload makes the program throw an exception;
 2. SEH handler kicks in, which has been overwritten with a memory address in the program that contains `pop pop ret` instructions;
@@ -466,7 +482,7 @@ We can summarize that SEH overflow exploitation at a high level works as shown i
 
 We can update the above diagram with memory addresses that we observed in this lab like so:
 
-![SEH overflow exploitation process as observed in the labs](../../../.gitbook/assets/image%20%28988%29.png)
+![SEH overflow exploitation process as observed in the labs](../../../.gitbook/assets/image%20%28989%29.png)
 
 ## References