4. Metodologia di fingerprinting.

Ci sono molte, molte tecniche che possono essere usate per fare il finger printing degli stack di networking. Basilarmente, potete già cercare le cose che differiscono tra i sistemi operativi e scrivere una prova per la differenza. Se combinate abbastanza prove, potete limitare strettamente i S.O. Per esempio nmap può, in maniera affidabile distinguere Solaris 2.4 da Solaris 2.5-2.51 e da Solaris 2.6. Esso può anche riconoscere il kernel Linux 2.0.30 dal 2.0.31-34 o dal 2.0.35. Ecco qui alcune tecniche:

La prova FIN

Qui mandiamo un pacchetto FIN (o ogni pacchetto senza un flag ACK o SYN) a una porta aperta e aspettiamo per la risposta. Il corretto comportamento secondo l'RFC 793 è di non rispondere, ma molte implementazioni lo violano, come ad esempio MS Windows, BSDI, CISCO, HP/UX, MVS e IRIX mandano indietro un RESET. La maggior parte delle utility di scan correnti utilizzano questa tecnica.

La prova del flag BOGUS

Queso è, il primo scanner che ho visto usare questo test intelligente. L'idea è di impostare un "flag" (64 o 128) nell'header TCP di un pacchetto SYN. Le macchine Linux precedenti al 2.0.35 mantengono il flag impostato nella loro risposta. Non ho trovato nessun altro S.O. che abbia questo bug. Tuttavia, alcuni sistemi operativi sembrano resettare la connessione quando essi prendono un pacchetto SYN+BOGUS. Questo comportamento potrebbe essere utile nell'identificarli.

Il campionamento TCP ISN

L'idea qui è trovare dei pattern nella successione iniziale di numeri (ISN), scelti dalle implementazioni TCP quando rispondono a una richiesta di connessione. Queste possono essere categorizzate in molti gruppi come ad esempio il tradizionale 64K (molte vecchie macchine UNIX), incrementi casuali, in inglese random increments (le nuove versioni di Solaris, IRIX, FreeBSD, Digital UNIX, Cray, e molti altri), true "random", ovvero casualità pura,(Linux 2.0.*, OpenVMS, le nuove versioni di AIX, ecc). Le macchine Windows (e poche altre) usano un modello "tempo dipendente", dove l'ISN è incrementato da una piccola quantità fissata ogni periodo di tempo. Non c'è necessità di dirlo, questo comporatamento è tanto facile da sconfiggere quanto il vecchio comportamento 64K. Certamente la mia tecnica preferita è la costante. Le macchine usano sempre lo stesso esatto ISN:). Ho visto questo su alcuni hub della 3Com (usano 0x803) e le stampanti Apple Laserwriter (usano 0xc7001).

Potete anche suddividere i gruppi in ulteriori classi, come ad esempio incremento casuale da variazioni di calcolo, massimi comun divisori, e altre funzioni su un insieme di successioni di numeri e le differenze tra i numeri. Dovrebbe essere noto che la generazione di ISN ha importanti implicazioni sulla sicurezza. Per ulteriori informazioni, contattate l'"esperto" di sicurezza Tsutomu "Shimmy" Shimomura alla SDSC e chiedetegli come lo ha scoperto.

Bit "Non Frammentare"

Molti sistemi operativi stanno iniziando a impostare il bit "non frammentare" IP su alcuni dei pacchetti che mandano. Questo da diversi benefici sulle prestazioni (però può essere annoiante - questo è il perchè gli scan di frammentazione di nmap non funzionano dalle macchine Solaris). In ogni casi, non tutti i S.O. fanno questo [N.d.T. impostano il bit non frammentare nei pacchetti IP] e alcuni lo fanno in casi differenti, cosí facendo attenzione a questo bit possiamo ottenere ulteriori informazioni sul S.O. Precedentemente non ho visto neppure uno scanner, sfruttare questa tecnica.

Finestra Iniziale TCP

Questo comporta semplicemente il controllo della dimensione della finestra sui pacchetti di ritorno. I vecchi scanner usavano semplicemente una finestra non-zero su un pacchetto RST per voler dire "derivato BSD". Gli scanner più recenti, come ad esempio queso e nmap mantengono traccia della finestra esatta in quanto essa è attualmente piuttosto costante a seconda del tipo di S.O. Questo test attualmente ci dà molte informazioni, siccome alcuni sistemi operativi possono essere unicamente identificati dalla finestra da sola (per esempio, AIX è il solo S.O. che ho visto, il quale usa 0x3F25). Nel suo stack "completamente riscritto" per NT5, Microsoft usa 0x402E. La cosa interessante è che questo numero è lo stesso usato da OpenBSD e FreeBSD.

Valore dell'ACK

Sebbene vorreste pensare che questo sia completamente standard, le implementazioni differiscono nel valore che usano per il campo ACK in alcuni casi. Per esempio, diciamo che voi mandate un FIN|PSH|URG a una porta TCP chiusa. Molte implementazioni imposteranno l'ACK per essere lo stesso della vostra successione numerica iniziale (ISN), anche se Windows e alcune stampanti stupide manderanno indietro la vostra successione+1. Se mandate SYN|FIN|URG|PSH a una porta aperta,Windows è molto inconsistente. Talvolta manda indietro la vostra successione, altre volte manda S++ (dove S, è la vostra succ.), e ancora altre volte manda indietro un valore apparentemente casuale. Uno ha da meravigliarsi di quale razza di codice MS stia scrivendo per fare in modo che abbia un comportamento come questo.

Messaggi di errore ICMP

Alcuni (intelligenti) sistemi operativi seguono il suggerimento della RFC 1812 per limitare il tasso al quale i diversi messaggi sono mandati. Per esempio, il kernel di Linux (in net/ipv4/icmp.h) limita la generazione dei messaggi unreachable di destinazione a 80 per 4 secondi, con 1/4 di secondo di penalità se si eccede questo limite. Un modo di testare questo è mandare dei pacchetti ad alcune porte alte casuali UDP e contare il numero dei unreachable ricevuti. Prima questo non l'ho visto usato e infatti non l'ho aggiunto a nmap(eccetto per l'uso dello scanning delle porte UDP).

Questo test renderebbe il rilevamento del S.O. un pó più lungo in quanto avete bisogno di mandare dei pacchetti e aspettare, che ritornino. Anche trattare la possibilità dei pacchetti spersi nella rete potrebbe essere una scocciatura.

Riferimento dei Messaggi ICMP

Le RFC specificano che i messaggi di errore ICMP fanno riferimento ad alcune piccole somme di un messaggio ICMP che causa diversi errori. Per un messaggio di porta unreachable, quasi tutte le implementazioni mandano indietro solo l'header IP richiesto + 8 bytes. Tuttavia, Solaris manda indietro un bit in piú, e Linux manda anche piú di quello. La bellezza con questo è che esso [N.d.T. il fatto che un Linux e Solaris non rispondino in maniera standard] permette a nmap di riconoscere Linux e Solaris, anche se non hanno alcuna porta in ascolto.

Integrità dell'echoing del messaggio d'errore ICMP.

Ho preso questa idea da qualcosa che Theo De Raadt (sviluppatore capo di OpenBSD) aveva postato al comp.security.unix. Come menzionato prima, le macchine devono inoltre mandare indietro parte del vostro messaggio originale con errore di porta unreachable. Ancora altre macchine tendono ad usare i vostri header come spazio improvvisato durante l'elaborazione iniziale e cosí essi sono un pó aumentati dalla volta che li avete ricevuti. Per esempio, AIC e BSDI mandano indietro il campo IP total length che è 20 bytes superiore. Alcuni BSDI, FreeBSD, OpenBSD, ULTRIX, e VAXen si fottono l'ID IP che gli avete mandato. Mentre il checksum ha intenzione di cambiare in quanto è cambiato TTL in ogni caso, ci sono macchine (AIX,FreeBSD,ecc..) che mandano indietro un checksum inconsistente o 0. Stessa cosa accade con il checksum UDP. Nmap fa nove test differenti sugli errori ICMP per fare lo sniff su subdole differenze come queste.

Tipo del Servizio

Per i messaggi di porta unreachable (irraggiungibile) ICMP, ho guardato il valore del tipo di servizio (TOS) [N.d.T. TOS = type of service, tipo di servizio] mandato indietro. Quasi tutte le implementazioni usano 0 per questo errore ICMP sebbene Linux usi 0xC0. Questo non indica uno dei valori standard TOS, ma invece è parte del campo di precedenza non usato (AFAIK). Non so perchè questo sia impostato, ma se i valori cambiano a 0 noi saremo in grado di ottenere l'identificazione delle versioni vecchie e saremo in grado di distinguere tra vecchie e nuove.

Gestione della frammentazione

Questa è la tecnica preferita di Thomas H.Ptacek della Secure Network, Inc.,(ora posseduta da un gruppo di utenti Windows alla NAI). Essa prende vantaggio dal fatto che implementazioni differenti spesso gestiscono frammenti IP sovrapposti differentemente. Alcuni sovrascriveranno le vecchie porzioni con le nuove, e in altri casi la cosa vecchia ha la precedenza. Ci sono molte prove differenti che potete usare per determinare come il pacchetto è stato riassemblato. Non ho aggiunto questa caratteristica in quanto so che non v'è un modo portabile per mandare frammenti IP (in particolare, è una cosa tremenda su Solaris). Per ulteriori informazioni sui frammenti sovrapposti potete leggere la loro relazione sugli IDS ( www.secnet.com).

Opzioni TCP

Queste sono veramente una miniera d'oro in termini di perdita di informazioni. La bellezza di queste opzioni è che:

1. Esse sono generalmente opzionali(uff!) :) cosí non tutti gli host le implementano.
2. Sapete se un host le implementa mandando una query con un insieme di opzioni. La macchina a cui le avete mandate mostra generalmente il supporto di una opzione impostandola nella risposta.
3. Potete mettere un intero insieme di opzioni in un pacchetto per fare il test un unica volta.

Nmap manda queste opzioni con quasi ogni pacchetto di prova:

Window Scale=10; NOP; Max Segment Size=265; Timestamp; End of Ops;

Quando ottenete la vostra risposta, date uno sguardo a quali opzioni sono restituite e quali supportate. Alcuni sistemi operativi come le macchine FreeBSD supportano tutte le opzioni sopra descritte, mentre altri come ad esempio Linux 2.0.X ne supportano molto poche. Gli ultimi kernel Linux 2.1.X supportano tutte le opzioni dette sopra. D'altra parte, esse sono vulnerabili alla predizione della successione TCP. Anche se diversi sistemi operativi supportano lo stesso insieme di opzioni, potete talvolta distingurle dai valori delle opzioni.

Per esempio, se mandate un piccolo MSS a una macchina Linux, essa generalmente vi restituirà quel MSS indietro. Altri host vi daranno valori diversi. E anche se ottenete lo stesso insieme di opzioni supportate e gli stessi valori, potete ancora differenziare attraverso l'ordine in cui le opzioni sono date, e dove il padding viene applicato. Per esempio Solaris restituisce NNTNWME che significa:

     <no op><no op><timestamp><no op><window scale><echoed MSS>

Mentre Linux 2.1.22 restituisce MENNTNW. Le stesse opzioni, stessi valori, ordine differente! Non ho visto altre utility di rilevamento S.O., che utilizzino le opzioni TCP, ma sono molto utili.

Cronologia dell'Exploit

Anche con tutti i test fatti sopra, nmap è incapace di distinguere tra gli stack TCP di Win95, WinNT, o Win98. Questo è piuttosto sorprendente specialmente in quanto Win98 venne rilasciato circa 4 anni dopo Win95. Penserete che essi [N.d.T la Microsoft] abbiano migliorato lo stack in qualche modo (come per esempio supportando ulteriori opzioni TCP) e cosí noi saremmo stati in grado di distinguere i sistemi operativi. Sfortunatamente, non è questo il caso. Lo stack NT è apparentemente lo stesso schifoso stack, che Microsoft ha messo in Win95. E non hanno pensato di aggiornarlo nemmeno in Win98.

Ma non perdete la speranza, per questo esiste la soluzione. Potete semplicemente iniziare con i primi attacchi DoS sulla macchina Windows (Ping of Death, Winnuke, ecc.) e per spostarvi poi su ulteriori attacchi come ad esempio Teardrop e Land.

Dopo ogni attacco, fate il ping della macchina target per vedere se è andata in crash. Quando in fine avete mandato la loro macchina in crash, avrete probabilmente ristretto quello che era in esecuzione ad un service pack o ad un hot fix. Non ho aggiunto questa funzionalità sebbene io stesso ammetto che sia molto accattivante.

Resistenza al SYN Flood

Alcuni sistemi operativi non accetteranno nuove connessioni se voi gli mandate troppo pacchetti SYN contraffatti (la contraffazione dei pacchetti comporta guai con il vostro kernel resettando le connessioni). Molti sistemi operativi possono gestire solo 8 pacchetti. I kernel Linux recenti( tra gli altri sistemi operativi) permettono diversi metodi, come ad esempio i SYN cookies, per prevenire che questo [N.d.T. il SYN Flood, per ulteriori riferimenti vedi Phrack 48 - Project Neptune] diventi un problema serio. Cosí potete imparare qualcosa sul vostro S.O. mandando 8 pacchetti da una sorgente contraffatta a una porta aperta e poi testando se potete stabilire da voi stessi un connessione a quella porta. Questo non è, stato implementato in nmap in quanto alcune persone si irritano, quando gli fai un SYN flood. Anche spiegandogli che voi state semplicemente provando a determinare quale sistema operativo stanno usando, potrebbe non aiutarli a calmarli.