Hack the box
Jemand richtet einen Computer, eine sog. "Box" ein, den die anderen versuchen zu hacken.
Windows 2000 Server
Eigenlich sollte die Box den Namen "blue box" bekommen ;)
P6 500Mhz, Windows 2000 Server, alle aktuellen Sicherheitspatches, später wurde dann auch Oracle installiert.
Wir waren bei den vielen Bluescreens oft nicht sicher, ob es an maroder HW, oder den laufenden Angriffen lag. Da immer wieder mga.dll den Kernel in die Tiefe zog, tauschten wir die Grafikkarte. Ab da an sorgte dann die vga.dll für blaue Bildschirme. Die langsame Installation von Oracle wurde durch die Crashes immer wieder abgebrochen, erst nach vielleicht 6 Versuchen, und ohne Netzwerkkabel war sie dann abgeschlossen.
Hier erstmal der TCP und UDP portscan:
# nmap -p 1-65535 192.168.23.150 Starting Nmap 4.01 ( http://www.insecure.org/nmap/ ) at 2006-02-18 21:19 CET Interesting ports on fnord-150.ewerk.erlangen.ccc.de (192.168.23.150): (The 65495 ports scanned but not shown below are in state: closed) PORT STATE SERVICE 7/tcp open echo 9/tcp open discard 13/tcp open daytime 17/tcp open qotd 19/tcp open chargen 21/tcp open ftp 25/tcp open smtp 80/tcp open http 88/tcp open kerberos-sec 119/tcp open nntp 135/tcp open msrpc 139/tcp open netbios-ssn 389/tcp open ldap 443/tcp open https 464/tcp open kpasswd5 515/tcp open printer 548/tcp open afpovertcp 563/tcp open snews 593/tcp open http-rpc-epmap 636/tcp open ldapssl 1026/tcp open LSA-or-nterm 1029/tcp open ms-lsa 1037/tcp open unknown 1045/tcp open unknown 1058/tcp open nim 1083/tcp open ansoft-lm-1 1084/tcp open ansoft-lm-2 1099/tcp open unknown 1521/tcp open oracle 1755/tcp open wms 2030/tcp open device2 3268/tcp open globalcatLDAP 3269/tcp open globalcatLDAPssl 3372/tcp open msdtc 5560/tcp open isqlplus 5580/tcp open unknown 6666/tcp open irc-serv 7007/tcp open afs3-bos 7778/tcp open unknown 9138/tcp open unknown MAC Address: 00:03:47:4D:B2:DF (Intel) Nmap finished: 1 IP address (1 host up) scanned in 4.011 seconds
# nmap -v -sU -O 192.168.23.150 Starting Nmap 4.01 ( http://www.insecure.org/nmap/ ) at 2006-02-18 19:03 CET Initiating ARP Ping Scan against 192.168.23.150 [1 port] at 19:03 The ARP Ping Scan took 0.00s to scan 1 total hosts. DNS resolution of 1 IPs took 0.00s. Mode: Async [#: 1, OK: 1, NX: 0, DR: 0, SF: 0, TR: 1, CN: 0] Initiating UDP Scan against fnord-150.ewerk.erlangen.ccc.de (192.168.23.150) [1482 ports] at 19:03 Discovered open port 7/udp on 192.168.23.150 Discovered open port 13/udp on 192.168.23.150 Discovered open port 19/udp on 192.168.23.150 Discovered open port 17/udp on 192.168.23.150 The UDP Scan took 1.40s to scan 1482 total ports. Warning: OS detection will be MUCH less reliable because we did not find at least 1 open and 1 closed TCP port Host fnord-150.ewerk.erlangen.ccc.de (192.168.23.150) appears to be up ... good. Interesting ports on fnord-150.ewerk.erlangen.ccc.de (192.168.23.150): (The 1461 ports scanned but not shown below are in state: closed) PORT STATE SERVICE 7/udp open echo 9/udp open|filtered discard 13/udp open daytime 17/udp open qotd 19/udp open chargen 88/udp open|filtered kerberos-sec 123/udp open|filtered ntp 135/udp open|filtered msrpc 137/udp open|filtered netbios-ns 138/udp open|filtered netbios-dgm 161/udp open|filtered snmp 389/udp open|filtered ldap 464/udp open|filtered kpasswd5 500/udp open|filtered isakmp 1028/udp open|filtered ms-lsa 1059/udp open|filtered nimreg 1645/udp open|filtered radius 1646/udp open|filtered radacct 1812/udp open|filtered radius 1813/udp open|filtered radacct 3456/udp open|filtered IISrpc-or-vat MAC Address: 00:03:47:4D:B2:DF (Intel) Too many fingerprints match this host to give specific OS details TCP/IP fingerprint: SInfo(V=4.01%P=i686-pc-linux-gnu%D=2/18%Tm=43F76187%O=-1%C=-1%M=000347) T5(Resp=Y%DF=N%W=0%ACK=S++%Flags=AR%Ops=) T6(Resp=Y%DF=N%W=0%ACK=O%Flags=R%Ops=) T7(Resp=Y%DF=N%W=0%ACK=S++%Flags=AR%Ops=) PU(Resp=Y%DF=N%TOS=0%IPLEN=38%RIPTL=148%RID=E%RIPCK=E%UCK=E%ULEN=134%DAT=E) Nmap finished: 1 IP address (1 host up) scanned in 5.857 seconds Raw packets sent: 1512 (43.5KB) | Rcvd: 1481 (83KB)
Erstaunlicherweise hatten wir den ersten echten Erfolg in Sachen hacking mit einem Portscan mit einer älteren nmap-Version. Die Lücke tat sich allerdings am falschen Ende der Leitung auf:
# nmap -v -sU -O 192.168.23.150 Starting nmap 3.83.DC13 ( http://www.insecure.org/nmap/ ) at 2006-02-18 18:41 CET Initiating ARP Ping Scan against 192.168.23.150 [1 port] at 18:41 The ARP Ping Scan took 0.00s to scan 1 total hosts. Initiating UDP Scan against fnord-150.ewerk.erlangen.ccc.de (192.168.23.150) [1480 ports] at 18:41 Discovered open port 17/udp on 192.168.23.150 Discovered open port 13/udp on 192.168.23.150 Discovered open port 19/udp on 192.168.23.150 Discovered open port 7/udp on 192.168.23.150 The UDP Scan took 1.39s to scan 1480 total ports. Warning: OS detection will be MUCH less reliable because we did not find at least 1 open and 1 closed TCP port Host fnord-150.ewerk.erlangen.ccc.de (192.168.23.150) appears to be up ... good. Interesting ports on fnord-150.ewerk.erlangen.ccc.de (192.168.23.150): (The 1457 ports scanned but not shown below are in state: closed) PORT STATE SERVICE 7/udp open echo 9/udp open|filtered discard 13/udp open daytime 17/udp open qotd 19/udp open chargen 88/udp open|filtered kerberos-sec 123/udp open|filtered ntp 135/udp open|filtered msrpc 137/udp open|filtered netbios-ns 138/udp open|filtered netbios-dgm 161/udp open|filtered snmp 389/udp open|filtered ldap 464/udp open|filtered kpasswd5 500/udp open|filtered isakmp 1028/udp open|filtered ms-lsa 1059/udp open|filtered nimreg 1645/udp open|filtered radius 1646/udp open|filtered radacct 1650/udp open|filtered nkd 1812/udp open|filtered radius 1813/udp open|filtered radacct 1990/udp open|filtered stun-p1 3456/udp open|filtered IISrpc-or-vat MAC Address: 00:03:47:4D:B2:DF (Intel) Too many fingerprints match this host to give specific OS details TCP/IP fingerprint: SInfo(V=3.83.DC13%P=i686-pc-linux-gnu%D=2/18%Tm=43F75C55%O=-1%C=-1%M=000347) T5(Resp=Y%DF=N%W=0%ACK=S++%Flags=AR%Ops=) T6(Resp=Y%DF=N%W=0%ACK=O%Flags=R%Ops=) T7(Resp=Y%DF=N%W=0%ACK=S++%Flags=AR%Ops=) PU(Resp=Y%DF=N%TOS=0%IPLEN=38%RIPTL=148%RID=E%RIPCK=E%UCK=E%ULEN=134%DAT=E) caught SIGSEGV signal, cleaning up Aborted #
nmap 3.83.DC13 war also verwundbar gegen die Serverantworten.
Recht intensiv wurde das grossartige scapy verwendet, um diverse Protokolle zu fuzzen. Wir konnten keinen felhlenden Service identifizieren. Allerdings war das auch nicht so einfach wie gedacht, da man das Windows Ereignisprotokoll im Wesentlichen abschalten musste.
Mit pktgen kann man gut eine Ethernetleitung fluten. Dabei ging die Kernellast unserer Box bis auf beinahe 100%, und es ist schwer zu sagen, ob pktgen für so einige Bluescreens verantwortlich zeichnet, wir hatten keine Aufzeichnungen (tcpdump-logs) um das mittels replays zu Testen.