narnia3.c<\/code>.<\/p>\n\n\/*\n This program is free software; you can redistribute it and\/or modify\n it under the terms of the GNU General Public License as published by\n the Free Software Foundation; either version 2 of the License, or\n (at your option) any later version.\n\n This program is distributed in the hope that it will be useful,\n but WITHOUT ANY WARRANTY; without even the implied warranty of\n MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the\n GNU General Public License for more details.\n\n You should have received a copy of the GNU General Public License\n along with this program; if not, write to the Free Software\n Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA\n*\/\n\n#include <stdio.h>\n#include <sys\/types.h>\n#include <sys\/stat.h>\n#include <fcntl.h>\n#include <unistd.h>\n#include <stdlib.h>\n#include <string.h>\n\nint main(int argc, char **argv){\n\n int ifd, ofd;\n char ofile[16] = \"\/dev\/null\";\n char ifile[32];\n char buf[32];\n\n if(argc != 2){\n printf(\"usage, %s file, will send contents of file 2 \/dev\/null\\n\",argv[0]);\n exit(-1);\n }\n\n \/* open files *\/\n strcpy(ifile, argv[1]);\n if((ofd = open(ofile,O_RDWR)) < 0 ){\n printf(\"error opening %s\\n\", ofile);\n exit(-1);\n }\n if((ifd = open(ifile, O_RDONLY)) < 0 ){\n printf(\"error opening %s\\n\", ifile);\n exit(-1);\n }\n\n \/* copy from file1 to file2 *\/\n read(ifd, buf, sizeof(buf)-1);\n write(ofd,buf, sizeof(buf)-1);\n printf(\"copied contents of %s to a safer place... (%s)\\n\",ifile,ofile);\n\n \/* close 'em *\/\n close(ifd);\n close(ofd);\n\n exit(1);\n}\n<\/code><\/pre>\n\nStatic Code Analysis<\/h2>\n\n
I won’t go over the already known preprocessor directives. For information regarding them check out the last post. I will however, go over the new ones we see here.<\/p>\n\n
#include <sys\/types.h>\n#include <sys\/stat.h>\n#include <fcntl.h>\n#include <unistd.h>\n<\/code><\/pre>\n\nThe first preprocessor directive #include <sys\/types.h><\/code> contains some of the more common data types that are used in the system. Although these are meant to be used within the kernel, most of the system data types are accessible also to user code. Check out more information on this header file here<\/a>. Or, look over the header file yourself with this command: less \/usr\/include\/x86_64-linux-gnu\/sys\/types.h<\/code> <\/p>\n\nNext, we have #include <sys\/stat.h><\/code> and this header file defines the structure of the data that is returned by the stat()<\/em>, fstat()<\/em>, and lstat()<\/em> functions. Check out more information on this header file here<\/a>. The header file is located here: \/usr\/include\/x86_64-linux-gnu\/sys\/stat.h<\/code><\/p>\n\nThe #include <fcntl.h><\/code> directive shall define the following requests and arguments for use by the functions fcntl()<\/em> and open()<\/em>. This is mostly used to retrieve or modify open file flags given a file descriptor. Check out more information on this header file here<\/a>. The header file is located here: \/usr\/include\/fcntl.h<\/code><\/p>\n\nLastly, we have #include <unistd.h><\/code> and this directive provides access to the Portable Operating System Interface (POSIX) operating system API. Check out more information on this header file here<\/a>. The header file is located here: \/usr\/include\/unistd.h<\/code><\/p>\n\nAs we can clearly see from the preprocessor directives, this is a much more robust program. We still have the same main()<\/em> function declaration which tells us that we will need to supply an argument. We also have more variables declared than prior levels.<\/p>\n\n int ifd, ofd;\n char ofile[16] = \"\/dev\/null\";\n char ifile[32];\n char buf[32];\n<\/code><\/pre>\n\nFirst we have two integers declare, ifd<\/em> and ofd<\/em>. Then we have three arrays, ofile[16]<\/em>, ifile[32]<\/em>, and buf[32]<\/em>. Immediately we see an issue here with the variable ofile[16]<\/em> only having 16 bytes in value and the other two arrays having 32. Ok, getting an idea here. Let’s continue.<\/p>\n\nThe next line is an if-statement telling us if the command-line argument, argc<\/em> is not equal to 2 then print usage, %s file, will send contents of file 2 \/dev\/null\\n<\/code>. Then an exit(-1)<\/code>? What?! We know that exit(0)<\/code> is a successful program termination and exit(1)<\/code> is an indication of an unsuccessful program termination. Looking ahead we see that the other if-statements both return the same exit(-1)<\/code> while the end of the main()<\/em> exits with a exit(1)<\/code>. Let’s keep moving forward.<\/p>\n\n if(argc != 2){\n printf(\"usage, %s file, will send contents of file 2 \/dev\/null\\n\",argv[0]);\n exit(-1);\n }\n<\/code><\/pre>\n\nNext is a function called strcpy()<\/em> which is actually kind of famous. Check out the man<\/code> page for strcpy()<\/em> with the command man strcpy<\/code> and press Shift+gg<\/code>.<\/p>\n\n\n 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 unnecessary 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.<\/p>\n<\/blockquote>\n\n
Alright, so this function is known to cause buffer overflows and we can add this to our arsenal of possibilities. Looking at the function it accepts two arguments, ifile<\/code> and argv[1]<\/code> and we know from the variable declaration that ifile[32]<\/code> has a value of 32 bytes and argv[1]<\/code> is a pointer to the first command line argument supplied. <\/p>\n\n \/* open files *\/\n strcpy(ifile, argv[1]);\n<\/code><\/pre>\n\nThen we have another if-statement that states if the variable ofd<\/code> equals the open()<\/em> function with the variable ofile<\/code> filed and O_RDWR<\/code> flag set is less than 0 then print error opening %s\\n<\/code>. The O_RDWR<\/code> is the File Access Mode<\/code> flag for the open()<\/em> function. This is necessary to read and write to the file. Read more about it here<\/a>. <\/p>\n\n if((ofd = open(ofile,O_RDWR)) < 0 ){\n printf(\"error opening %s\\n\", ofile);\n exit(-1);\n }\n<\/code><\/pre>\n\nThe next if-statement is similar however, the open()<\/em> function is opening the ifile<\/code> variable and the File Access Mode<\/code> flag is set to O_RDONLY<\/code> which is Read-Only and being compared to the ifd<\/code> variable.<\/p>\n\n if((ifd = open(ifile, O_RDONLY)) < 0 ){\n printf(\"error opening %s\\n\", ifile);\n exit(-1);\n }\n<\/code><\/pre>\n\nSo, from what we can tell we will be opening two files and the first command-line argument will be copied into the ifile<\/code> variable. \nNext we have the heavy lifting of the program. First is the read()<\/em> function taking three arguments, the ifd<\/code> variable, the buf<\/code> variable, and then sizeof(buf)-1<\/code>. To better understand this we need to look at the read()<\/em> function, man read<\/code>. <\/p>\n\nREAD(2)\n\nNAME\n read - read from a file descriptor\n\nSYNOPSIS\n #include <unistd.h>\n\n ssize_t read(int fd, void *buf, size_t count);\n\nDESCRIPTION\n read() attempts to read up to count bytes from file descriptor fd into the buffer starting at buf.\n<\/code><\/pre>\n\nSo the last portion of the function sizeof(buf)-1<\/code> is the count bytes. So the function will read the file up to the size of buf<\/code> which is 32 minus 1 making is 31. The same goes for the write()<\/em> function as well. Then finally the files are closed and the program exits. Easy enough.<\/p>\n\n \/* copy from file1 to file2 *\/\n read(ifd, buf, sizeof(buf)-1);\n write(ofd,buf, sizeof(buf)-1);\n printf(\"copied contents of %s to a safer place... (%s)\\n\",ifile,ofile);\n\n\n \/* close 'em *\/\n close(ifd);\n close(ofd);\n\n exit(1);\n}\n<\/code><\/pre>\n\nExploit Staging<\/h2>\n\n
With our static code analysis finished it’s time to start working on our exploitation of this program. We know the exploit will be a buffer overflow. What else do we know? We know that strcpy()<\/em> will take everything from argv[1]<\/code> and copy to ifile[32]<\/code>. However, the buffer for ifile[32]<\/code> is only 32 bytes. If we supply an argument for argv[1]<\/code> that was longer than 32 bytes then we would have our buffer overflow condition. Ok, now we’re getting somewhere. We need a file that is larger than 32 bytes. \nTo make our file and to ensure that we are able to read and write to it I am going to create my file in the \/tmp\/<\/code> directory using python<\/code>. The file, including the \/tmp\/<\/code> need to equal 32 charcters. <\/p>\n\npython -c 'print(len(\"\/tmp\/\" + \"A\"*27))'\nmkdir -p $(python -c 'print (\"\/tmp\/\" + \"A\"*27 + \"\/tmp\")')\ncd $(python -c 'print (\"\/tmp\/\" + \"A\"*27 + \"\/tmp\")')\n<\/code><\/pre>\n\nThis creates a directory in \/tmp\/<\/code> named AAAAAAAAAAAAAAAAAAAAAAAAAAA<\/code> which contains another \/tmp\/<\/code> directory. Now we can test our exploit theory by passing our current working directory to the narnia3<\/code> binary.<\/p>\n\n\/narnia\/narnia3 `pwd`\/abc\n<\/code><\/pre>\n\n![\"\"](\"https:\/\/i0.wp.com\/hackmethod.com\/wp-content\/uploads\/2019\/04\/Narnia3-3.png?w=1080&ssl=1\")
<\/p>\n\n
We receive an error which tells us that our argument is too large however, the error did not provide the entire working directory. Lets examine and disassemble the binary to find out what is getting overrun. To do this we can use gdb<\/code> like before in the previous Narnia write ups or we can use objdump<\/code>.<\/p>\n\nA little bit about objdump<\/code>. If you have not used objdump<\/code> before then I would suggest playing around with this great tool. objdump<\/code> is a great command-line tool that can be used for a wide variety of things. Such as, listing headers for an executable, disassembling an executable and even display debug information. This doesn’t do objdump<\/code> justice and there are many more use cases. For more information check out the man<\/code> page here<\/a> or type man objdump<\/code>. Now back to exploiting the narnia3<\/code> binary.<\/p>\n\nTo disassemble the binary with objdump<\/code> we will be issuing the -d<\/code> flag. Futhermore, we will set our disassembly flavor to into with the -M<\/code> flag followed by intel<\/code> and then the path to the binary. <\/p>\n\nobjdump -d -M intel \/narnia\/narnia3\n<\/code><\/pre>\n\nRunning the above command will fill the screen with the entire binary disassembled and might be a bit overwhelming. We will be focusing on the <main><\/code> function.\n![\"\"](\"https:\/\/i0.wp.com\/hackmethod.com\/wp-content\/uploads\/2019\/04\/Narnia3-1.png?w=1080&ssl=1\")
<\/p>\n\nUsing the above screenshot as a reference because your memory addresses may be different. The first two operations are used to build the stack frame and you will typically see these at the beginning of every function.<\/p>\n\n
804850b: 55 push ebp\n 804850c: 89 e5 mov ebp,esp\n<\/code><\/pre>\n\nThen we have the stack pointer esp<\/code> with the value 0x58<\/code> which is the hex value 88. This is the space needed for our variables. Then we have the mov<\/code> operand to move a pointer to ebp-0x18<\/code> the hex value 24, then ebp-0x14<\/code> the hex value 20, then ebp-0x10<\/code> hex value 16, the ebp-0xc<\/code> the hex value 12, and lastly ebp-0x8<\/code> the hex value of 8 but this operand isn’t a mov<\/code> but rather a cmp<\/code>. The cmp<\/code> operand is used to compare the first source operand with the second source operand. Which all add up to 80 leaving room for local variables. <\/p>\n\nExploit Development<\/h2>\n\n
So what do we know? We know that ifile[32]<\/code> is copied at 0x0804855a<\/code>. We also know from the source code that ifile<\/code> is copied from argv[1]<\/code> which is then copied into ofile<\/code>. So, in order for us to overflow ofile<\/code> the value must exceed 32 characters. Then we have 16 characters for ofile<\/code> which contains “\/dev\/null”. Let’s provide the executable an input file which contains or references the password and an output file which we control. To solve this, I created a folder within \/tmp<\/code> called AAAAAAAAAAAAAAAAAAAAAAAAAAA<\/code>. The total length of the following string is 32 bytes. Therefore, anything that follows the above path will overwrite the output file. To solve that, I created an output file within \/tmp<\/code> named output<\/code>. I also created an input file named output<\/code> within a folder named tmp which nests under \/tmp\/AAAAAAAAAAAAAAAAAAAAAAAAAAA\/tmp<\/code>. If we symbolically link this file to the password file, we can use it as the input file and the output file will be re-written to \/tmp\/output<\/code> which is a file we can view.<\/p>\n\n![\"\"](\"https:\/\/i0.wp.com\/hackmethod.com\/wp-content\/uploads\/2019\/04\/Narnia3-2.png?w=1080&ssl=1\")
<\/p>\n\n\n\n
<\/p>\n\n\n\n
If you missed out on Narnia Level 2 click the button on the left to check it out. If you\u2019re all caught up and want to see more, check out the Narnia Level 3 by clicking the button on the right. <\/p>\n\n\n\n
<\/p>\n\n\n\n
\n\n