Last updated
Last updated
Windows 7 32bit VM
.Net 4.5
SLMail Application
Immunity Debugger
Mona.py Immunity Plugin
DEP & ASLR Disabled
Stack buffer overflows occurs when a program writes to a memory address on the program's call stack outside of the intended data structure, which is usually a fixed-length buffer. Overfilling a buffer on the stack is more likely to derail program execution than overfilling a buffer on the heap because the stack contains the return addresses for all active function calls. - Wikipedia
Instruction Pointer: “Program Counter”
EIP – Register that contains the memory address of the next instruction to be executed by the program. EIP tells the CPU what to do next.
Stack Pointer: ESP – Register pointing to the top of the stack at any time
Base Pointer: EBP – Stays consistent throughout a function so that it can be used as a placeholder to keep track of local variables and parameters.
EAX – “accumulator” normally used for arithmetic operations
EBX – Base Register
ECX – “counter” normally used to hold a loop index
EDX – Data Register
ESI/EDI – Used by memory transfer instructions
ESP – Points to last item on the stack
To combat buffer overflows memory protections were introduced in operating systems. Address Space Layout Randomisation (ASLR) is a technology used to randomly offset the location of modules and certain in-memory structures while Data Execution Prevention (DEP) prevents certain memory sectors of the stack, from being executed.
Install .Net 4.5, SLMail (say yes to all defaults), Immunity Debugger & EMET. To successfully complete the lab you must also disable some memory protections such as DEP & ASLR. In the requirements section you downloaded the Enhanced Mitigation Experience Toolkit (EMET) from Microsoft. Open it as admin, and confirm you have a setup similar to below:
The program will ask you reboot after closing.
After rebooting Once you firing up Immunity with admin privs, we can attach ourselves to a running slmail service. Click File > Attach and then select the SLMail program (slmail.exe). Then press the F9 button once or click play so the program is no longer in a paused state.
Crash the input by fuzzing until you have over written the EIP address (right click follow in dump).
To do this we will send A's in increments of 200 into the password field until we observe a crash.
It looks like the program crashed somewhere between 2700 & 2900 bytes. To confirm we will send 2700 A's into the password field.
Now that we know where the application crashed (2700 bytes) we will need to find which exact 4 bytes we have overwritten the EIP. To determine this we will use the pattern_create tool within the Metasploit Framework.
We can now modify our exploit to send this unique value and crash the application.
After crashing the application using the pattern__create tool we need to observe the unique value of the EIP that is now overwritten. We then feed this value into our pattern_offset tool to determine the exact size of the string when the application crashes.
In our next fuzzing attempt we will send 2606 A's, 4 B's, and 90 C's for a total of 2700 bytes. This allows us to confirm that the 4 B's overwrite the EIP at the time of the crash now that we know the offset.
If we have fuzzed successfully we should see that 42424242 or BBBB has overwritten the EIP. We also adjust our total buffer to 3500 bytes to have room for our shellcode.
An important step in exploit development is the concept of locating bad characters. These character when inserted into our shellcode will be ignored and not processed by the OS. To handle this hurtle we feed the program the bad characters instead of our C's and observe if the program skips any of them when executing. We update our exploit code to send the bad characters.
Now that we have a better understanding of how the program will execute our shellcode we need to find a memory address in the program that contain the instruction to return to top of the stack and begin processing code. This is also known as a JMP ESP instruction or op code. Next in building our exploit we can utilize the !mona modules that are ready installed in Immunity Debugger to search for addresses with no DEP, ASLR, and bad characters. It looks like we have a winner with a JMP ESP that can used is with in the SLMFC.dll.
Now that we have found a DLL with no DEP, ASLR, and bad characters, we must locate a JMP ESP opcode. Do accomplish this we use a tools called nasm_shell. This tool provides an easy way to see what opcodes are associated with various x86 instructions.
Now using the mona modules we can search for the a JMP ESP instruction included with the SLMFC.dll with : mona find -s "\xff\xe4" -m smlfc.dll and confirm the located address contains a JMP ESP instruction.
Now that we know the memory location of the JMP ESP instruction (5FA358F) we must copy this address and insert it backwards (Little Endian Format) in our exploit code.
After observing and confirming the program crashed at the correct address, we must now generate our shellcode to exclude bad characters. Note that you MUST include EXITFUNT=thread if you do not want the program to crash after getting a shell.
Due to the fact the ESP register points to the beginning of our payload, the Metasploit Framework decoder cause an error by overwriting the first few bytes of our shellcode during the decoding process. We can avoid this by adding few No Operation (NOP) instructions (0x90) at the beginning of our shellcode. We then update our exploit code to include a NOP Sled.
And Finally!! We can send our exploit and receive a working shell!