Sorgente Immagine: http://www.androidworld.it
Tranquilli non voglio parlare di nessun virus, epidemia, o serie tv (anche se The Walkin Dead ve la consiglio).
L’argomento di oggi è l’IDLE SCAN, ovvero una tecnica sofisticata di port scanning TCP ideata da Salvatore Sanfilippo, il quale permette di rilevare servizi attivi su un determinato host camuffando il proprio indirizzo sorgente (spoofing).
Come viene nascosto l’ip sorgente?
Impersonando un terzo host della rete il cui stato è dormiente (idle, zombie), infatti la tecnica coinvolge tre interpreti:
- L’attaccante
- Un host nella rete in stato dormiente(idle, zombie)
- L’obbiettivo della scansione
Il vantaggio di questo metodo di scansione sta nel fatto che l’attaccante comunicherà soltanto con l’host zombie, e quest’ultimo con l’obbiettivo finale.
Requisiti
- Conoscenze minime dei protocolli, in particolare Internet Protocol
- Conoscenze minime di Linux
- Conoscenze minime Framework Metasploit
Teoria
Per capire come funziona l’idle scan, suddiviso in due fasi, è necessario analizzare il protocollo IP durante lo scambio di pacchetti tra due host, in particolare l’header.
Quando l’host A contatta l’host B, invia un pacchetto con un identificativo numerico univoco (ID). 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.
Ogni volta che un pacchetto viene scambiato il sistema operativo incrementa di 1 il numero id, quindi in assenza di traffico il valore rimane invariato.
In questo modo è possibile predire il sequence number di un determinato host e capire se è in stato di idle o meno.
Nota Bene Nella maggior parte dei sistemi operativi moderni è stata applicata una patch che genera l’id header dei pacchetti in maniera casuale, quindi non più utilizzabili come zombie. Qusto non esclude però la buona riuscita della scansione, infatti molti network device tipo switch, access point,o print server risultano vulnerabili (vedere in seguito l’esempio pratico).
Fase 1 – Individuazione Host Zombie
L’attaccante invia una serie di pacchetti verso uno o più host di rete, se le risposte avranno nell’header ip il valore id incrementato in maniera sequenziale, l’host può essere considerato uno zombie.
E’ importante che lo zombie risponda sempre con un id sequenziale altrimenti si andrebbe a incappare in una scansione con falsi positivi.
Fase 2 – Esecuzione Idle Scan
L’attaccante interroga lo zombie per individuare il suo l’identification number (es. 13370) , tramite un tools di spoofing invia alla vittima un pacchetto modificato dove nel source address inserisce l’ip dello zombie e nella destination port la porta tcp interessata.
A questo punto si possono aprire tre scenari:
PORTA APERTA: la vittima invia 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 variando il proprio identification number (13371).
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 (identification number non varia).
PORTA BLOCCATA: 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 (identification number non varia).
L’attaccante re-interroga l’host zombie traendo le seguenti conclusioni:
- il valore di identification dello zombie è variato (13371), 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.
Pratica
Finalmente mettiamo in pratica le due fasi dell’idle scan:
Fase 1 – Individuazione Host Zombie
Per individuare hosts zombie è possibile utilizzare il famoso Framework Metasploit che troverete già a bordo di alcune distribuzione dedite a Penetration Test e Vulnerability Assessment tipo BackBox, Kalilinux o BlackArch.
Eseguire metasploit tramite mfsconsole e caricare il tool scanner ipidseq:
msf auxiliary(ipidseq) > use auxiliary/scanner/ip/ipidseq
msf auxiliary(ipidseq) > show options
Module options (auxiliary/scanner/ip/ipidseq):
Name Current Setting Required Description
---- --------------- -------- -----------
INTERFACE eth0 no The name of the interface
RHOSTS yes The target address range or CIDR identifier
RPORT 80 yes The target port
SNAPLEN 65535 yes The number of bytes to capture
THREADS 1 yes The number of concurrent threads
TIMEOUT 500 yes The reply read timeout in milliseconds
msf auxiliary(ipidseq) > set RHOSTS 10.0.0.0/24
RHOSTS => 10.0.0.0/24
msf auxiliary(ipidseq) > set THREADS 50
THREADS => 50
msf auxiliary(ipidseq) > run
[*] 10.0.0.2's IPID sequence class: Incremental!
[*] 10.0.0.10's IPID sequence class: All zeros
[*] Scanned 39 of 256 hosts (15% complete)
[*] 10.0.0.69's IPID sequence class: Unknown
[*] 10.0.0.68's IPID sequence class: All zeros
[*] Scanned 55 of 256 hosts (21% complete)
[*] Scanned 88 of 256 hosts (34% complete)
[*] Scanned 105 of 256 hosts (41% complete)
[*] Scanned 130 of 256 hosts (50% complete)
[*] Scanned 155 of 256 hosts (60% complete)
[*] Scanned 183 of 256 hosts (71% complete)
[*] Scanned 206 of 256 hosts (80% complete)
[*] Scanned 235 of 256 hosts (91% complete)
[*] Scanned 256 of 256 hosts (100% complete)
[*] Auxiliary module execution completed
msf auxiliary(ipidseq) >
Come si può notare dopo aver caricato il tool scanner, ho controllato le opzioni (SHOW OPTIONS) per verificare i parametri da utilizzare.
Ho modificato l’opzione RHOST inserendo la classe interessata da scansionare, poi ho modificato il numero THREADS in 50 così da velocizzare la scansione, infine ho fatto partire la scansione tramite RUN.
L’esito della scansione è un host zombie, con precisione l’ip 10.0.0.2 .
Approfondiamo la questione, tramite nmap vediamo di scoprire qualcosa di più su questo ip:
msf auxiliary(ipidseq) > nmap 10.0.0.2
[*] exec: nmap 10.0.0.2
Starting Nmap 6.47 ( http://nmap.org ) at 2015-08-20 16:58 CEST
Nmap scan report for 10.0.0.2
Host is up (0.052s latency).
Not shown: 998 closed ports
PORT STATE SERVICE
80/tcp open http
4242/tcp open vrml-multi-use
MAC Address: 04:A1:51:9D:A5:48 (Netgear)
Nmap done: 1 IP address (1 host up) scanned in 165.17 seconds
msf auxiliary(ipidseq) >
Adesso sappiamo che lo switch Netgear, in particolare il modello GS108T, può essere utilizzato come zombie.
Fase 2 – Esecuzione Idle Scan
I tre interpreti:
- Attaccante 10.0.0.64 (Mio Notebook)
- Host Zombie 10.0.0.2 (Switc Netgear)
- Obbiettivo Scansione 10.0.0.1 (Firewall Linux)
Per eseguire un idle scan e “spoofare” l’ip sorgente possiamo utilizzare sempre nmap:
msf auxiliary(ipidseq) > nmap -PN -sI 10.0.0.2 10.0.0.1
[*] exec: nmap -PN -sI 10.0.0.2 10.0.0.1
Starting Nmap 6.47 ( http://nmap.org ) at 2015-08-20 17:19 CEST
Idle scan using zombie 10.0.0.2 (10.0.0.2:80); Class: Incremental
Nmap scan report for firewall.firewall (10.0.0.1)
Host is up (0.21s latency).
Not shown: 996 closed|filtered ports
PORT STATE SERVICE
53/tcp open domain
81/tcp open hosts2-ns
222/tcp open rsh-spx
444/tcp open snpp
MAC Address: 00:0D:B9:1A:B7:68 (PC Engines GmbH)
Nmap done: 1 IP address (1 host up) scanned in 41.10 seconds
msf auxiliary(ipidseq) >
Per eseguire con nmap una scansione idle è necessario specificare lo switch “-sI“, l’ip dell’host zombie, ed infine l’ip dell’obbiettivo.
La scansione è andata a buon fine, ma accertiamoci lato firewall (10.0.0.1) se i pacchetti sono arrivati dallo zombie (10.0.0.2) o dall’ip dell’attaccante (10.0.0.64).
Prima di eseguire la scansione, mi sono collegato sul firewall e tramite lo sniffer di rete tcpdump mi sono messo in ascolto sulla porta 444:
[root@firewall ~]# tcpdump -i green0 -nn port 444
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on green0, link-type EN10MB (Ethernet), capture size 262144 bytes
17:19:51.165926 IP 10.0.0.2.80 > 10.0.0.1.444: Flags [S], seq 2243717062, win 1024, options [mss 1460], length 0
17:19:51.166097 IP 10.0.0.1.444 > 10.0.0.2.80: Flags [S.], seq 451041702, ack 2243717063, win 29200, options [mss 1460], length 0
17:19:51.167873 IP 10.0.0.2.80 > 10.0.0.1.444: Flags [R], seq 2243717063, win 0, length 0
17:19:51.597329 IP 10.0.0.2.80 > 10.0.0.1.444: Flags [S], seq 2243717062, win 1024, options [mss 1460], length 0
17:19:51.597539 IP 10.0.0.1.444 > 10.0.0.2.80: Flags [S.], seq 457782928, ack 2243717063, win 29200, options [mss 1460], length 0
...
...
Come si può notare le richieste sono arrivate dall’ip dello zombie (Netgear 10.0.0.2) e non dal Notebook dell’attaccante (10.0.0.64)
Per info o delucidazioni non esistate a contattarmi o a commentare il post!