67 lines
4.6 KiB
Markdown
67 lines
4.6 KiB
Markdown
Buffer Overflow = using more memory than allocated
|
|
Stack = LIFO structure where CPU registers are stored at and retrieved from
|
|
ESP register points to top of stack
|
|
EIP register useful to store when doing CALL command
|
|
Address of next instruction to be executed and stored.
|
|
Can inject malicious code using buffer overflow
|
|
|
|
# Fuzzing
|
|
|
|
- Sending malformed data into application input and watching for unexpected crashes. Unexpected crash indicated application might not filter certain input correctly.
|
|
- To develop an exploit for application X on OS Y,
|
|
- X, Y and debugger needed on same VM
|
|
- Another VM to fuzz the target VM
|
|
- Cant do remotely on running server (though if developed correctly, exploit should work on any instance of application X running on OS Y)
|
|
|
|
## SLMail
|
|
|
|
Using a python script, we can repeatedly connect to the POP3 server, attempting to send varying length growing buffer to the password field each time
|
|
Unauthenticated user can attempt to login providing a long password.
|
|
|
|
Using Immunity Debugger, attaching the SLMail process, and running the debugger before the script, then running the script, we can see the fuzzer sends larger and larger passwords to the POP3 server.
|
|
This is about 2900 bytes long when ID pauses and can see the stack has been overwritten by user input.
|
|
The EIP register has been overwritten with opur input buffer of A's (\\x41)
|
|
As EIP register controls execution flow of application, if we make our exploit buffer carefully, could divert execution of the program to a place in memory where reverse shell code can be introduced in memory.
|
|
|
|
## Controlling EIP
|
|
|
|
- Getting control of the EIP register is an important part of exploit development
|
|
- Need to find out which A characters ended up in the EIP and identify the location of 4 unique bytes that overwrite the EIP Register.
|
|
- Can send 2900 bytes of unique non-repeating characters.
|
|
- User pattern_create.rb script in Kali to generate such a string:
|
|
- `/usr/share/metasploit-framework/tools/exploit/pattern_create.rb -l 2900`
|
|
- Using this unique stream of characters, instead of our 2900 A's into our python script, check EIP overwrite in debugger.
|
|
- Note ESP and EIP register values in next crash
|
|
- EIP has been replaced by the 39694438 hex characters, equivalent to 8Dj9
|
|
- We need to find exact position of these characters.
|
|
- Can now use the pattern_offset.rb script along with the create script to discover the offset of these specific 4 bytes in our unique byte string.
|
|
- `/usr/share/metasploit-framework/tools/exploit/pattern_offset.rb -l 2900 -q 39694438`
|
|
- Sending this new buffer to SLMail POP3 server produces a crash in the debugger.
|
|
- Check ESP and EIP registers
|
|
- This time ESP has different value to first crash
|
|
- EIP register cleanly overwritten by B's (42424242H), showing that we can now control the EIP of the SLMail application.
|
|
- How to direct execution flow?
|
|
- Would like to include our own shell code inside buffer and redirect program flow to execute our shell code.
|
|
|
|
### Find Space in Memory for Shell Code
|
|
|
|
- By dumping memory at time of crash, ESP register points directly to beginning of our buffer of C's. Seems like a convenient location to place shellcode as easily accessible through EIP register.
|
|
- Metasploit framework can automatically generate shellcode payloads, standard Reverse Shell payload requires around 350-400 bytes of space.
|
|
- Need to increase length of buffer to make room for reverse shell.
|
|
- buffer = A * 2606 + B * 4 + C * (3500-2606-4)
|
|
- Then test this still overwrites EIP
|
|
|
|
### Bad Characters
|
|
|
|
- Now enough space, can use shell code generator from metasploit to generate payload. Generated shell code might have many different hex characters that might effect execution of shell code.
|
|
- Depending on application, vuln type, and protocols, there may be certain characters that are considered bad and should not be used in our buffer, return address or shell code.
|
|
- Common example is null (0x00). Characters truncate shellcode in memory
|
|
- Easy way to check this is sending all possible characters, from 0x00 to 0xff as a part of our buffer and see how these characters are dealt with by the application after the crash occurs.
|
|
- A file containing all the possible hex characters can be found on Blackboard.
|
|
- When including these in python exploit code, we will see the characters that get truncated in Immunity Debugger
|
|
- One observation is that resulting memory dump for the ESP register shows that the character 0x0A seems to have truncated the rest of the buffer than comes after it.
|
|
|
|
### Generating Shellcode Payload
|
|
|
|
- Metasplot Framework provides us with tools and utilities that make generating complex payloads a simple task.
|