Skip to content
Permalink
Browse files

bof

  • Loading branch information...
uf0o committed Jul 19, 2019
1 parent 6c40adc commit c5dae7d6617890a4f4e24b230cf3422e5be644c0
Showing with 11 additions and 7 deletions.
  1. +1 −0 content/hacks.md
  2. +10 −7 content/tutorials/buffer_overflow.md
@@ -19,6 +19,7 @@ Here are some contributions to the MSF framework and the exploit-db:
##### <a target="_blank" href="https://www.exploit-db.com/exploits/45565"style="text-decoration: none;">Free MP3 CD Ripper 2.8 - '.wma' Buffer Overflow (SEH) (DEP Bypass) </a>
##### <a target="_blank" href="https://www.exploit-db.com/exploits/45259"style="text-decoration: none;">CuteFTP 5.0 - Buffer Overflow </a>
### [Metasploit modules & payloads]
##### <a target="_blank" href="https://github.com/rapid7/metasploit-framework/blob/master/modules/payloads/singles/linux/x86/shell_reverse_tcp_ipv6.rb"style="text-decoration: none;">Linux Command Shell, Reverse TCP Inline (IPv6)</a> <br>
@@ -7,12 +7,15 @@ aliases = ["about-us","about-hugo","contact"]
name = "Matteo Malvica"
+++
---

# Intro

This post is not meant to cover all the inner details about how the stack works behind the scene.
However, this can be a starting point for anyone willing to understand basic fuzzing and debugging, and how a simple buffer overflow exploit can be crafted.<br>
By definition, fuzzing is an "automated software testing technique that involves providing invalid, unexpected, or random data as inputs to a computer program".
<br><br>

### Fuzzing
## Fuzzing
For instance, we can begin to fuzz a vulnerable server program with the below skeleton code, which is taking as argument an IP address and the listening port.<br>
The python fuzzer will probe the server and send bigger data, 10 bytes each time.<br>
Both <i>max_buffer</i> and <i>increment</i> variable can be tuned to change the fuzzer behavior (faster vs more granular).
@@ -61,15 +64,15 @@ for string in buff:
sys(exit)
{{< / highlight >}}
<br>
### What's up EIP?
## What's up EIP?
If everything goes well we should see the EIP written with four times x41, which is the character 'A' in hexadecimal.<br>
So, why do we care if the EIP get overwritten?<br>
The EIP is one of many extended 32 bit registers part of the original <a target="_blank" href="https://en.wikipedia.org/wiki/Intel_8086#Registers_and_instructions">8086</a>
16 bit architecture, which is responsible for executing the next program instruction. <br>
As you might have guessed, replacing the EIP value means hijacking the application flow, which can in turn lead to arbitrary code execution.
<br><br>
### Measuring EIP offset
## Measuring EIP offset
So, if we want to rewrite the EIP we must know the exact distance between our start buffer and the EIP itself.<br>
A nice Ruby tool named 'pattern create', which is pre-installed in Kali Linux, can come to our aid.<br>
Given a 'crasing buffer size' it will generate different pattern every 4 bytes, so the EIP will be colored with a specific pattern.<br>
@@ -134,7 +137,7 @@ Great, so 1328 bytes is the offset needed to predictably overwrite the EIP.



### EIP, obey your master!
## EIP, obey your master!

Let's rewrite the script buffer variable to accommodate our new learned pattern offset + EIP value + room to fill the crash buffer<br>
Our new buffer starts with a sequence of 1328 'A's, a special value to mark the EIP ('ABBA') and fill remaining space with a trail of 'C's.<br>
@@ -150,7 +153,7 @@ We now run again the script and verify that the EIP gets 'ABBA' as a value, whic
The ESP is a register that points to the beginning of our stack and is important to verify its location in memory with the debugger: in the best case scenario, as soon as our program stops at our newly rewritten EIP value, we should note that our 'C' trails is present right after execution.
This means that if we could overwrite the EIP with a 'jump to ESP' instruction...<br><br>

### Oh, what a badchar!
## Oh, what a badchar!

Before jumping to shellcode, let's test if there are any well known bad character, by including them all as a hex string variable in our PoC.<br>
A bad char is simply an ascii character that can break code execution, such as 0x00 (Null) or 0x0A (line feed).<br>
@@ -175,7 +178,7 @@ buff = "A"*1328 + "ABBA" + badchars
After testing, we have discovered these two bad chars: x00 and x04 <br><br>
### Jump here, not there!
## Jump here, not there!
What is missing now is the return address used to overwrite the EIP, which will point to ESP to point to ESP each time the program is loaded. <br>
However, the ESP value could change at runtime, due to stack based threaded behavior of some application or presence or <a target="_blank" href="https://security.stackexchange.com/questions/18556/how-do-aslr-and-dep-work">ASLR/DEP</a>
@@ -208,7 +211,7 @@ Address=65226385 Message= 0x64246683 : "\xff\xe4" | {PAGE_EXECUTE_READ} [example
{{< / highlight >}}
So we found our return address to be 65226385, which will be stored in little endian format in our proof of concept script.<br><br>
### Enter the shellcode
## Enter the shellcode
Since we might have enough room to fit our shellcode in the ‘C’ place, we can proceed generating one with msfvenom, taking into account platform and architecture, in addition to bad characters discovered previously.
The below code is spawning a reverse shell by connecting to the attacker address on TCP port 4444.<br>

0 comments on commit c5dae7d

Please sign in to comment.
You can’t perform that action at this time.