This time we will need to return to the library...
...C. ;) To do that we will start here:
When VM is ready, let's start the program (stack6) in gdb:
As you can see when I'm using gdb I like to set up 2 more parameters:
- disassembly-flavor (and)
- pagination
Let's try next call - getpath:
To check 'how this program works' I decided to set a breakpoint (bp) in ret instruction (0x080484f9 in my case):
As you can see I used shell command (inside gdb) to 'escape' to bash for a moment and prepare a file with our payload (in /tmp/ because defaut user is not able to write to /opt/protostar/ directory). Running stack6 with our payload should take us directly to the breakpoint ("Breakpoint 1, 0x... in getpath() at stack6/stack6.c:23").
Let's examine ESP:
We can see some part of our 'payload'. Let's continue now:
Checking registers:
So far, so good. Looks like we can overwrite EIP address. This should be a 'good indicator' that the program can be hijacked. ;) Let's prepare some more interesting payload (to get the proper offset to overflow) using pattern_create and pattern_offset from Metasploit:
As you can see (on x.180 VM - Protostar) I started preparing a small skeleton of the poc. We will use it during this case.
Checking:
Now we will use generated ('b') file in 2nd window where is running our gdb:
As you can see we overflowed EIP with the new address (for my case it was): 0x37634136. Let's use this value in pattern_offset now:
Let's update our skeleton-poc:
Good.
According to the 'About' section (where you can find few hints about the bug in stack6) we can use ret2libC to exploit this program. Let's try to do that.
We will need to modify our exploit to add:
- base address of the program
- address of system() function
- address of exit() function
- argument for system().
Let's go:
1) to get base address we will use readelf tool (already used in few cases described here or here):
Let's use the -l switch:
As you can see, (LOAD) you can find the base address for stack6 in VirtAddr column. We will use it later.
(By the way, you can use gdb to check it. Try this:
But it's your choice how you will get it. ;))
2) address of system() function
This is pretty easy. In your running gdb just type:
gdb> p system
3) address of exit() function
We will get it in the same way as we used for system() function, so:
gdb> p exit
4) argument for system()
We will use "/bin/sh". To get this I used strings for libC found in output of info proc map (gdb):
Let's put all of those pieces together:
Almost Neo... ;] Again!
I decided to change the way of getting address values and this time I used readelf again:
Checking - still nope. So Neo? Maybe during return-into-lib-C b you will use _lib_C_ base address, hm? ;)
Again (and maybe set the payload-puzzle in a proper way too, ok?):
Better. ;]
I hope you find it useful. Other stack challenges from Protostar CTF you can find described here. In case of any questions (or bugs in text(s)) feel free to drop me an email or DM @twitter.
See you soon.
Cheers
Brak komentarzy:
Prześlij komentarz