Mona ASLR Bypass: Rebase SafeSEH

TL;DR

If Mona modules consistently report “Rebase SafeSEH ASLR True”, it means the target process’s image base is randomised, but the Safe Exception Handler (SafeSEH) isn’t. This makes exploitation harder. We can bypass this by finding a suitable address for our shellcode and using techniques like ROP to control execution.

Solution Guide

1. Understand the Problem
   • ASLR (Address Space Layout Randomisation): This randomises where modules load in memory, making it harder to predict addresses.
   • SafeSEH: A security feature that protects against overwriting exception handlers. If ASLR is enabled but SafeSEH isn’t randomised, it can be a vulnerability.
   • Rebase SafeSEH ASLR True: Mona indicates the image base *is* randomising, but SafeSEH remains at a fixed address. This limits exploitation options.
2. Confirm ASLR Status

   Double-check ASLR is enabled on the target system using tools like Process Explorer (Windows) or by examining process flags in a debugger.

3. Identify SafeSEH Address

   Use Mona to find the fixed address of the SafeSEH. Run Mona with the appropriate options:

   mona sehc

   Note down the reported SafeSEH address.

4. Find a Suitable Shellcode Location

   We need to find an executable region in memory where we can place our shellcode. This could be:

   • Heap: Often writable, but less predictable.
   • Stack: Easier to control initially, but smaller and potentially non-executable (DEP).
   • Existing Modules: Look for executable sections within loaded modules that have sufficient space.
5. ROP Chain Construction

   Since direct shellcode execution might be difficult, we’ll likely need a Return-Oriented Programming (ROP) chain.

   • Find ROP Gadgets: Use tools like ropper or rp++ to find useful gadgets in loaded modules. Look for gadgets that:
     • Pop registers with values we need (e.g., address of shellcode, arguments).
     • Call functions (e.g., VirtualProtect to make memory executable).
     • Control program flow.
   • Build the Chain: Assemble a sequence of gadget addresses that achieves our goal – typically making shellcode executable and then jumping to it.
6. Exploit Development (Example – Simplified)

   This is a highly simplified example. Actual exploitation will be more complex.

   • Vulnerable Function: Identify the function with the buffer overflow vulnerability.
   • Overflow Payload: Construct a payload that overwrites the return address on the stack with:
     1. Address of the first ROP gadget (e.g., to pop an address onto the stack).
     2. Address of our shellcode location.
     3. Address of a second ROP gadget (e.g., VirtualProtect call).
     4. Arguments for VirtualProtect (address, size, flags).
     5. Address of another gadget to jump to the shellcode.
7. Bypass DEP/NX

   If Data Execution Prevention (DEP) is enabled, you’ll need to use ROP to change memory permissions before executing your shellcode.

   • VirtualProtect: A common gadget used to make a region of memory executable.
8. Testing and Refinement

   Test the exploit in a controlled environment (e.g., a virtual machine). Debugging is crucial to identify issues with ROP chain construction or address calculations.