Idle scan

Da Wikipedia, l'enciclopedia libera.

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 sorgente]

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].

La teoria[modifica | modifica sorgente]

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 sorgente]

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 sorgente]

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 sorgente]

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 ( http://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 sorgente]

Note[modifica | modifica sorgente]

  1. ^ Intervista a Salvatore “antirez” Sanfilippo, URL consultato in data 17 marzo 2009.
  2. ^ Introduzione ad hping, URL consultato in data 16 marzo 2009. credit a Sanfilippo a pagina 3
  3. ^ Introduzione ad hping, URL consultato in data 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 sorgente]