Distinguere le porte UDP aperte da quelle filtrate
Nel caso della scansione Felix, tutte le porte tranne le treopen|filtered erano closed. Questo non è sempre il caso. L’esempio 5.5 mostra una scansione UDP contro il sito pesantemente filtrato Scanme.
Esempio 5.5. Esempio di scansione UDP
krad# Starting Nmap ( http://nmap.org )All 1000 scanned ports on scanme.nmap.org (64.13.134.52) are open|filteredNmap done: 1 IP address (1 host up) scanned in 5.50 seconds
In questo caso, la scansione non ha affatto ristretto le porte aperte: tutte le 1000 sono open|filtered. È necessaria una nuova strategia.
La tabella 5.3, “Come Nmap interpreta le risposte a una sonda UDP” mostra che lo stato open|filtered si verifica quando Nmap non riesce a ricevere alcuna risposta dalle sue sonde UDP a una particolare porta, ma mostra anche che, in rare occasioni, il servizio UDP in ascolto su una porta risponde, dimostrando che la porta è aperta. La ragione per cui questi servizi non rispondono spesso è che i pacchetti vuoti che Nmap invia sono considerati non validi. Sfortunatamente, i servizi UDP definiscono generalmente la propria struttura di pacchetti piuttosto che aderire ad un formato generale comune che Nmap potrebbe sempre inviare. Un pacchetto SNMP sembra completamente diverso da un pacchetto di richiesta SunRPC, DHCP o DNS.
Per inviare il pacchetto corretto per ogni servizio UDP popolare, Nmap avrebbe bisogno di un grande database che definisca i loro formati di sonda.Fortunatamente, Nmap ce l’ha sotto forma dinmap-service-probes, che fa parte del sottosistema di rilevamento dei servizi e delle versioni descritto nel Capitolo 7, Rilevamento delle versioni dei servizi e delle applicazioni.
Quando la scansione delle versioni è abilitata con -sV (o-A), invierà sonde UDP ad ogni portaopen|filtered (oltre a quelle noteopen). Se una delle sonde ottiene una risposta da una porta open|filtered, lo stato viene cambiato in open. I risultati dell’aggiunta di-sV alla scansione di Felix sono mostrati nell’esempio 5.6.
Esempio 5.6. Miglioramento dei risultati della scansione UDP di Felix con il rilevamento della versione
krad# Starting Nmap ( http://nmap.org )Nmap scan report for felix.nmap.org (192.168.0.42)Not shown: 997 closed portsPORT STATE SERVICE VERSION53/udp open domain ISC BIND 9.2.167/udp open|filtered dhcpserver111/udp open rpcbind 2 (rpc #100000)MAC Address: 00:02:E3:14:11:02 (Lite-on Communications)Nmap done: 1 IP address (1 host up) scanned in 1037.57 seconds
Questa nuova scansione mostra che le porte 111 e 53 sono sicuramente aperte, ma il sistema non è perfetto: la porta 67 è ancora open|filtered. In questo caso particolare, la porta è aperta ma Nmap non ha una sonda di versione funzionante per DHCP.Un altro servizio difficile è SNMP, che di solito risponde solo quando viene data la corretta stringa di comunità. Molti dispositivi sono configurati con la stringa di comunità public, ma non tutti lo sono.Mentre questi risultati non sono perfetti, imparare il vero stato di due delle tre porte testate è ancora utile.
Dopo il successo nel disambiguare i risultati di Felix, Ereetturns la sua attenzione indietro a Scanme, che ha elencato tutte le porte come open|filtered l’ultima volta. Prova di nuovo con il rilevamento della versione, come mostrato nell’esempio 5.7.
Esempio 5.7. Migliorare i risultati della scansione UDP di Scanme con il rilevamento della versione
krad# Starting Nmap ( http://nmap.org )Nmap scan report for scanme.nmap.org (64.13.134.52)Not shown: 999 open|filtered portsPORT STATE SERVICE VERSION53/udp open domain ISC BIND 9.3.4Nmap done: 1 IP address (1 host up) scanned in 3691.89 seconds
Mentre Ereet alla fine ha trovato la porta aperta, ha fatto un errore a non aggiornare prima la versione di Nmap. Le versioni 5.10BETA1 e più recenti di Nmap hanno un sistema di payload che invia richieste di protocollo di servizio appropriate a più di tre dozzine di porte UDP ben note, se sono selezionate per la scansione delle porte o il rilevamento degli host. Anche se non è completo come il rilevamento della versione, avrebbe identificato rapidamente la porta 53 aperta nell’esempio 5.5.
Questo risultato ha richiesto un’ora, contro i cinque secondi della scansione precedente di Scanme, ma questi risultati sono effettivamente utili. Il sorriso di Ereet si allarga e gli occhi brillano a questa prova di un ISC BINDnameserver aperto su una macchina che vuole compromettere. Quel software ha una lunga storia di falle nella sicurezza, quindi forse può trovare una falla in questa recente versione.
Ereet concentrerà i suoi attacchi UDP sulla porta 53, poiché è confermata aperta, ma non si dimentica delle altre 999 porte elencate comeopen|filtered. Come abbiamo visto con la porta dhcpserver su Felix, certi servizi UDP aperti possono nascondersi anche dal rilevamento della versione di Nmap. Ha anche scansionato solo le porte predefinite finora, ce ne sono altre 64529 che potrebbero essere aperte. Per esempio, 53 è l’unica porta UDP aperta su Scanme.
Mentre questa tecnica di rilevamento della versione è l’unico modo per Nmap di disambiguare automaticamente le porte open|filtered, ci sono un paio di trucchi che possono essere provati manualmente. A volte un traceroute specializzato può aiutare. Potresti fare un traceroute contro una porta TCP o UDP conosciuta con Nmap o uno strumento come Nping, e poi provare lo stesso contro la porta UDP dubbia. Le differenze nel numero di hop possono distinguere le porte aperte da quelle filtrate. Ereet tenta questo contro Scanme nell’esempio 5.8. Il primo comando esegue un traceroute UDP contro la porta 53 conosciuta e aperta. Il secondo comando fa la stessa cosa contro la porta 54 presunta-chiusa. I primi hop sono stati omessi per risparmiare spazio.
Esempio 5.8. Tentativo di disambiguazione delle porte UDP con discrepanze TTL
krad# Starting Nping ( http://nmap.org/nping )SENT (7.0370s) UDP 192.168.0.21:53 > 64.13.134.52:53 ttl=8 id=4826 iplen=28RCVD (7.1010s) ICMP 4.69.134.222 > 192.168.0.21 TTL=0 during transit (type=11/code=0) ttl=248 id=38454 iplen=56SENT (8.0400s) UDP 192.168.0.21:53 > 64.13.134.52:53 ttl=9 id=38166 iplen=28RCVD (8.1050s) ICMP 4.68.18.204 > 192.168.0.21 TTL=0 during transit (type=11/code=0) ttl=247 id=39583 iplen=56SENT (9.0420s) UDP 192.168.0.21:53 > 64.13.134.52:53 ttl=10 id=6788 iplen=28RCVD (9.1080s) ICMP 4.59.4.78 > 192.168.0.21 TTL=0 during transit (type=11/code=0) ttl=246 id=59897 iplen=56SENT (10.0440s) UDP 192.168.0.21:53 > 64.13.134.52:53 ttl=11 id=366 iplen=28RCVD (10.1100s) ICMP 69.36.239.221 > 192.168.0.21 TTL=0 during transit (type=11/code=0) ttl=243 id=42710 iplen=56SENT (11.0470s) UDP 192.168.0.21:53 > 64.13.134.52:53 ttl=12 id=63478 iplen=28SENT (12.0490s) UDP 192.168.0.21:53 > 64.13.134.52:53 ttl=13 id=56653 iplen=28Max rtt: 73.003ms | Min rtt: 0.540ms | Avg rtt: 48.731msRaw packets sent: 13 (364B) | Rcvd: 10 (560B) | Lost: 3 (23.08%)Tx time: 12.02836s | Tx bytes/s: 30.26 | Tx pkts/s: 1.08Rx time: 13.02994s | Rx bytes/s: 42.98 | Rx pkts/s: 0.77Nping done: 1 IP address pinged in 13.05 secondskrad# Starting Nping ( http://nmap.org/nping )SENT (7.0370s) UDP 192.168.0.21:53 > 64.13.134.52:54 ttl=8 id=56481 iplen=28RCVD (7.1130s) ICMP 4.69.134.214 > 192.168.0.21 TTL=0 during transit (type=11/code=0) ttl=248 id=22437 iplen=56SENT (8.0400s) UDP 192.168.0.21:53 > 64.13.134.52:54 ttl=9 id=23264 iplen=28RCVD (8.1060s) ICMP 4.68.18.76 > 192.168.0.21 TTL=0 during transit (type=11/code=0) ttl=247 id=50214 iplen=56SENT (9.0430s) UDP 192.168.0.21:53 > 64.13.134.52:54 ttl=10 id=9101 iplen=28RCVD (9.1070s) ICMP 4.59.4.78 > 192.168.0.21 TTL=0 during transit (type=11/code=0) ttl=246 id=880 iplen=56SENT (10.0450s) UDP 192.168.0.21:53 > 64.13.134.52:54 ttl=11 id=35344 iplen=28RCVD (10.1110s) ICMP 69.36.239.221 > 192.168.0.21 TTL=0 during transit (type=11/code=0) ttl=243 id=44617 iplen=56SENT (11.0470s) UDP 192.168.0.21:53 > 64.13.134.52:54 ttl=12 id=53857 iplen=28SENT (12.0490s) UDP 192.168.0.21:53 > 64.13.134.52:54 ttl=13 id=986 iplen=28Max rtt: 76.488ms | Min rtt: 0.546ms | Avg rtt: 48.480msRaw packets sent: 13 (364B) | Rcvd: 11 (616B) | Lost: 2 (15.38%)Tx time: 12.02908s | Tx bytes/s: 30.26 | Tx pkts/s: 1.08Rx time: 13.03165s | Rx bytes/s: 47.27 | Rx pkts/s: 0.84Nping done: 1 IP address pinged in 13.05 seconds
In questo esempio, Ereet è stato in grado di raggiungere solo l’undicesimo hop di entrambe le porte aperte e chiuse. Quindi questi risultati non possono essere usati per distinguere gli stati delle porte contro questo host. Valeva la pena provare, e funziona in un numero significativo di casi. È più probabile che funzioni in situazioni in cui il firewall di screening è almeno uno o due hop prima dell’host di destinazione. Scanme, d’altra parte, sta eseguendo il proprio firewall basato su Linuxiptableshost. Quindi non c’è differenza di hop count tra le porte filtrate e quelle aperte.
Un’altra tecnica è quella di provare strumenti specifici per applicazioni contro porte comuni. Per esempio, si potrebbe provare un cracker di stringhe di comunità SNMP a forza bruta contro la porta 161. Man mano che il database delle sonde di rilevamento delle versioni di Nmap cresce, la necessità di aumentare i suoi risultati con strumenti specializzati esterni si riduce. Saranno ancora utili per casi speciali, come i dispositivi SNMP con una stringa di comunità personalizzata.