Idle scan
L'idle scan è una tecnica di port scanning TCP piuttosto sofisticata che fa uso fraudolento di un host inattivo remoto, chiamato zombie, per lanciare un attacco verso un altro host creando così una triangolazione che maschera del tutto l'attaccante.
La storia[modifica | modifica wikitesto]
L'attacco è stato teorizzato da Salvatore Sanfilippo (noto anche come antirez), che si occupa di Web 2.0[1] ed è autore dell'utility hping[2] e sviluppatore di Redis.
La teoria[modifica | modifica wikitesto]
Quando un host invia un pacchetto IP sulla rete, esso valorizza con un identificativo numerico univoco (per esso) il campo identification dell'header. Questo campo è utilizzato per riassemblare il pacchetto originale a partire dagli eventuali frammenti in cui può essere diviso durante la trasmissione, in quanto i vari frammenti includono sempre il campo identification del pacchetto originale.
In generale il sistema operativo genera il valore per questo campo in maniera sequenziale per ogni pacchetto trasmesso, per cui esso cambia solo quando un host trasmette pacchetti (mentre rimane inalterato se non ne trasmette)[3].
La tecnica[modifica | modifica wikitesto]
L'attaccante interroga lo zombie per verificarne l'inattività e per sapere qual è il valore che sta usando per il campo identification. L'attaccante invia poi un pacchetto alla porta della vittima che intende sondare, specificando però un IP sorgente pari a quello dello zombie (tramite ip spoofing). Il risultato ottenuto può essere uno dei seguenti:
- la vittima ha la porta aperta: in questo caso la vittima reagisce inviando allo zombie un pacchetto con i flag SYN/ACK. Lo zombie lo riceve, ma trattandosi di un pacchetto fuori sequenza, e quindi inatteso, esso risponde alla vittima trasmettendole un pacchetto con il flag RST.
- la vittima ha la porta chiusa: in questo caso la vittima reagisce trasmettendo allo zombie un pacchetto ICMP di tipo Destination Unreachable specificando che la porta non è raggiungibile. Lo zombie lo riceve, ma non fa nulla perché si tratta di una risposta inattesa ad una richiesta di connessione che esso non aveva inviato.
- la vittima scarta il traffico in ingresso sulla porta (ad esempio tramite un firewall): il pacchetto viene ignorato, e non vi sono risposte ICMP verso lo zombie.
A questo punto l'attaccante interroga di nuovo lo zombie e può osservare uno di questi due comportamenti:
- il valore di identification dello zombie è variato, quindi deduce che la porta della vittima era aperta.
- il valore di identification dello zombie non è variato, e quindi deduce che la porta della vittima era chiusa oppure filtrata.
La tecnica è piuttosto imprecisa e richiede che ci sia un host zombie totalmente inattivo, ma ha il vantaggio di essere completamente anonima alla vittima, impedendo quindi qualsiasi contromisura e facendo scattare un allarme in un eventuale IDS che però indica l'indirizzo dell'idle host.
Un esempio con hping[modifica | modifica wikitesto]
Il metodo hping per lo idle scanning fornisce un esempio a basso livello di come si possa eseguire. In questo esempio l'host della vittima (172.16.0.100) viene analizzato usando un host zombie (172.16.0.105) appartenente alla stessa sottorete di classe C. È mostrato quindi lo scenario verificate una porta aperta ed una porta chiusa per vedere come ciascuno scenario si svolge.
In primo luogo, stabilito che lo zombie sia effettivamente inattivo, si inviano i pacchetti usando il comando hping2 e si osserva che i valori di identification aumentano incrementalmente di 1. Se essi crescono casualmente, l'host zombie non è effettivamente inattivo.
[root@localhost hping2-rc3]# ./hping2 -S 172.16.0.105 HPING 172.16.0.105 (eth0 172.16.0.105): S set, 40 headers + 0 data bytes len=46 ip=172.16.0.105 ttl=128 id=1371 sport=0 flags=RA seq=0 win=0 rtt=0.3 ms len=46 ip=172.16.0.105 ttl=128 id=1372 sport=0 flags=RA seq=1 win=0 rtt=0.2 ms len=46 ip=172.16.0.105 ttl=128 id=1373 sport=0 flags=RA seq=2 win=0 rtt=0.3 ms len=46 ip=172.16.0.105 ttl=128 id=1374 sport=0 flags=RA seq=3 win=0 rtt=0.2 ms len=46 ip=172.16.0.105 ttl=128 id=1375 sport=0 flags=RA seq=4 win=0 rtt=0.2 ms len=46 ip=172.16.0.105 ttl=128 id=1376 sport=0 flags=RA seq=5 win=0 rtt=0.2 ms len=46 ip=172.16.0.105 ttl=128 id=1377 sport=0 flags=RA seq=6 win=0 rtt=0.2 ms len=46 ip=172.16.0.105 ttl=128 id=1378 sport=0 flags=RA seq=7 win=0 rtt=0.2 ms len=46 ip=172.16.0.105 ttl=128 id=1379 sport=0 flags=RA seq=8 win=0 rtt=0.4 ms
Viene quindi inviato un pacchetto spoofed SYN all'host della vittima sulla porta che si suppone sia aperta. Per l'esempio viene usata la porta 22 (ssh):
# hping2—spoof 172.16.0.105 -S 172.16.0.100 -p 22 -c 1 HPING 172.16.0.100 (eth0 172.16.0.100): S set, 40 headers + 0 data bytes --- 172.16.0.100 hping statistic --- 1 packets tramitted, 0 packets received, 100% packet loss round-trip min/avg/max = 0.0/0.0/0.0 ms
Poiché è stato effettuato lo spoofing del pacchetto, l'attaccante non riceve risposte e quindi hping restituisce il 100% di pacchetti persi. L'host della vittima risponde direttamente all'host zombie con un pacchetto avente i flag SYN/ACK. L'attaccante controlla quindi l'host zombie per vedere se il valore di identification è variato.
# hping2 -S 172.16.0.105 -p 445 -c 1 HPING 172.16.0.105 (eth0 172.16.0.105): S set, 40 headers + 0 data bytes len=46 ip=172.16.0.105 ttl=128 DF id=1381 sport=445 flags=SA seq=0 win=64320 rtt=0.3 ms --- 172.16.0.105 hping statistic --- 1 packets tramitted, 1 packets received, 0% packet loss round-trip min/avg/max = 0.3/0.3/0.3 ms
Da notare che il valore di identification dell'host zombie cresce di due unità, da id=1379 a id=1381, in quanto il valore 1380 è stato usato quando l'host zombie ha risposto al pacchetto con i flag SYN/ACK della vittima con un pacchetto con il flag RST, per cui si deduce che la porta della vittima era aperta.
L'intero processo viene ora ripetuto con una porta della vittima che si suppone sia chiusa. Per l'esempio che segue viene usata la porta 23 (telnet).
# hping2 -S 172.16.0.105 -p 445 -c 1 HPING 172.16.0.105 (eth0 172.16.0.105): S set, 40 headers + 0 data bytes len=46 ip=172.16.0.105 ttl=128 DF id=1382 sport=445 flags=SA seq=0 win=64320 rtt=2.1 ms --- 172.16.0.105 hping statistic --- 1 packets tramitted, 1 packets received, 0% packet loss round-trip min/avg/max = 2.1/2.1/2.1 ms # hping2—spoof 172.16.0.105 -S 172.16.0.100 -p 23 -c 1 HPING 172.16.0.100 (eth0 172.16.0.100): S set, 40 headers + 0 data bytes --- 172.16.0.100 hping statistic --- 1 packets tramitted, 0 packets received, 100% packet loss round-trip min/avg/max = 0.0/0.0/0.0 ms # hping2 -S 172.16.0.105 -p 445 -c 1 HPING 172.16.0.105 (eth0 172.16.0.105): S set, 40 headers + 0 data bytes len=46 ip=172.16.0.105 ttl=128 DF id=1383 sport=445 flags=SA seq=0 win=64320 rtt=0.3 ms --- 172.16.0.105 hping statistic --- 1 packets tramitted, 1 packets received, 0% packet loss round-trip min/avg/max = 0.3/0.3/0.3 ms
Si nota che in questo caso il valore di identification dello zombie non varia (o meglio, varia solo da 1382 a 1383 per via della risposta all'attaccante) perché la porta della vittima era chiusa oppure filtrata. Quando l'attaccante invia il pacchetto "modificato" (spoofed) alla vittima, essa non risponde affatto, o risponde allo zombie con un pacchetto con il flag RST che non provoca variazioni nel valore di identification.
Un esempio con nmap[modifica | modifica wikitesto]
Nmap non fornisce strumenti per identificare se un host è inattivo. Per questo scopo può essere utilizzato hping. Consultando l'help di nmap si trovano le istruzioni per attivare un idle scan:
SCAN TECHNIQUES: -sS/sT/sA/sW/sM: TCP SYN/Connect()/ACK/Window/Maimon scans -sU: UDP Scan -sN/sF/sX: TCP Null, FIN, and Xmas scans—scanflags <flags>: Customize TCP scan flags -sI <zombie host[:probeport]>: Idle scan -sO: IP protocol scan -b <FTP relay host>: FTP bounce scan—traceroute: Trace hop path to each host—reason: Display the reason a port is in a particular state
Quindi definito idlehost.domain1.it l'host in stato inattivo, victimhost.domain2.it l'host vittima la scansione avviene in questo modo:
hackhost:~$ sudo nmap -sI idlehost.domain1.it:80 victimhost.domain2.it -PN Starting Nmap 4.75 ( https://nmap.org/ ) at 2009-03-17 09:34 CET Idle scan using zombie idlehost.domain1.it (1.2.3.4); Class: Incremental Interesting ports on victimhost.domain2.it (10.20.30.40): Not shown: 984 closed|filtered ports PORT STATE SERVICE 88/tcp open kerberos-sec 135/tcp open msrpc 139/tcp open netbios-ssn 389/tcp open ldap 445/tcp open microsoft-ds 464/tcp open kpasswd5 593/tcp open http-rpc-epmap 636/tcp open ldapssl 1026/tcp open LSA-or-nterm 1027/tcp open IIS 1041/tcp open unknown 2301/tcp open compaqdiag 2381/tcp open unknown 3268/tcp open globalcatLDAP 3269/tcp open globalcatLDAPssl 3389/tcp open ms-term-serv MAC Address: XX:XX:XX:XX:XX:XX Nmap done: 1 IP address (1 host up) scanned in 19.58 seconds hackhost:~$
Altri tipi di scan[modifica | modifica wikitesto]
Note[modifica | modifica wikitesto]
- ^ Intervista a Salvatore “antirez” Sanfilippo, su blog.tagliaerbe.com. URL consultato il 17 marzo 2009.
- ^ Introduzione ad hping (PDF) [collegamento interrotto], su security.dsi.unimi.it. URL consultato il 16 marzo 2009. credit a Sanfilippo a pagina 3
- ^ Introduzione ad hping (PDF) [collegamento interrotto], su security.dsi.unimi.it. URL consultato il 16 marzo 2009. Una utility, hping, per testare l'attacco dell'idle scan sul sito dell'Università di Milano - Andrea Lanzi, Davide Marrone, Roberto Paleari - Facoltà di Scienze Matematiche, Fisiche e Naturali - Corso di Laurea in Informatica - 10 gennaio 2007
Collegamenti esterni[modifica | modifica wikitesto]
- Insecure.org/nmap/idlescan - Articolo su idle scanning
- Insecure.org - Sito ufficiale di nmap
- Nmap idlescan - Pagina di nmap sull'idlescan
- Hping.org Archiviato il 12 marzo 2007 in Internet Archive. - Sito ufficiale di Hping
- Nmap-Online.com - Nmap scanner online
- Techtarget.com - Un articolo su idle scanning
- Seclists.org - Il post originale di bugtraq
