Rilevamento remoto del S.O. tramite TCP/IP stack fingerprinting <author>Fyodor <htmlurl url="mailto:fyodor@DHP.com" name="fyodor@DHP.com"> <date> 10, Aprile 1999. <abstract> Questa relazione discute come ottenere informazioni preziose su un host interrogando il suo stack TCP/IP. Prima presento alcuni dei metodi "classici" per determinare il S.O. di un host, che non comportino lo stack fingerprinting.Poi descrivo lo "stato dell'arte" corrente nelle utility di stack fingerprinting. Successivamente viene una descrizione di molte tecniche, che fanno si che un host remoto tralasci informazioni su se stesso. In fine spiego nei dettagli la mia (<bf>nmap</bf>) implementazione di queste tecniche, seguita da una istantanea ottenuta da nmap che rivela quale S.O. è in esecuzione in molti siti Internet popolari. Tradotto in italiano da Simone Righi. E-mail: <htmlurl url="sarata@cyberspace.org" name="sarata@cyberspace.org">. </abstract> </titlepag> <toc> <sect>Motivi <p>Penso che l'utilità di determinare quale S.O. è in esecuzione su un sistema sia abbastanza ovvia, cosí questa sezione sarà breve. Uno degli esempi piú efficaci di questa utilità è che molti <it>buchi</it> nella sicurezza sono dipendenti dalla versione del S.O. Diciamo che state facendo un test di penetrazione e trovate la porta 53 aperta. Se questa è una versione di Bind vulnerabile ottenete solo una possibilità di <it>exploitarlo</it> [N.d.T. sfruttare questa vulnerabilità] in quanto un tentativo fallito manderà in crash il demone. <p> Con un buon fingerprinter TCP/IP troverete velocemente che questa macchina sta eseguendo "Solaris 2.6" o "Linux 2.0.35" e potete adattare di conseguenza il vostro codice. <p> Una possibilità peggiore è che qualcuno stia scannando 500.000 host allo scopo di vedere quale S.O. è in esecuzione e quali porte sono aperte. Poi quando qualcuno <it>posta</it> (dice) un "buco" di root [N.d.T. un bug che consente di ottenere i privilegi dell'utente root, ovvero dell'amministratore] nel demone comsat della Sun, il nostro piccolo cracker potrà fare il grep della sua lista per `UDP/512' e `Solaris 2.6' e immediatamente ha pagine e pagine di macchine con possibilità di accesso root. Dovrebbe essere noto che questo è il comportamento da <bf>SCRIPT KIDDIE</bf>. Voi non avete dimostrato alcuna abilità, e nessuno è rimasto neanche remotamente impressionato da fatto che voi siate in grado di trovare alcuni .edu che non abbiano rimediato il "buco" in tempo. Inoltre, le persone saranno anche meno impressionate se voi usate il vostro accesso appena trovato per deturpare il sito web del dipartimento con una declamazione di auto-ingrandimento su come maledettamente bravi siete e come l'amministratore di sistema deve essere stupido. <p> Un altro possibile uso è per l'ingeneria sociale. Diciamo che state facendo lo scan della vostra compagnia bersaglio e <bf>nmap</bf> riporta un "Datavoice TxPORT PRISM 3000 T1 CSU/DSU 6.22/2.06". L'hacker potrebbe ora chiamarla e presentarsi come "l'assistenza Datavoice" e discutere alcuni problemi sul loro PRISM 3000. <it>"Noi abbiamo intenzione di annunciare un grave problema alla sicurezza al più presto,</it> <it>ma prima vogliamo che tutti i vostri attuali clienti installino la patch </it> <it>- Glielo appena spedita....".</it> Alcuni amministratori ingenui potrebbero pensare che solo un ingegnere autorizzato da Datavoice sappia così sul loro CSU/DSU. Un altro potenziale uso di questa possibilità è la valutazione delle compagnie con le quali potete fare affari. Prima di scegliere un nuovo ISP, fategli lo scan e vedete che apparecchiatura è in uso. Quei "$99/annui" non sembrano ben spesi se scoprite che l'ISP ha router schifosi e offre servizi PPP su un paio di macchine Windows. <sect> Tecniche classiche. <p>Lo stack fingerprinting risolve il problema dell'identificazione di un S.O. in un unica maniera. Penso che questa tecnica mantenga la promessa maggiore, ma esistono attualmente molte altre soluzioni. Tristemente, questa è ancora una delle più efficenti di queste tecniche: <p> <tscreen> <verb> playground~> telnet hpux.u.aizu.ac.jp Trying 163.143.103.12 ... Connected to hpux.u-aizu.ac.jp. Escape character is '^]'. HP-UX hpux B.10.01 A 9000/715 (ttyp2) login: </verb> </tscreen> <p> Non c'è motivo di incansinarsi nel fingerprinting se la macchina annuncerà in maniera cosí appariscente al mondo cosa è in esecuzione! Tristemente, molti rivenditori mettono nei sistemi correnti questo genere di banner e molti amministratori non li disattivano. Solo perchè ci sono altri modi per scoprire quale S.O. sia in esecuzione (come ad esempio il fingerprinting), non significa che dovremmo già annunciare il nostro S.O. e architettura a ogni tipo che prova a connettersi. <p>I problemi nell'affidarsi a questa tecnica sono che molti sistemi non danno molte informazioni, ed è semplice per qualcuno "mentire" nei propri banner. Nondimeno, la lettura dei banner è tutto quello che ottenete per S.O. e controllo versione S.O. se spendete milioni sullo scanner commerciale ISS. Scaricate nmap o queso invece e risparmiate i vostri soldi:). <p> Anche se disattivate i banner, molte applicazioni daranno felicemente questo genere di informazioni, quando richieste. Per esempio guardiamo un server FTP: <p> <tscreen> <verb> payfonez> telnet ftp.netscape.com 21 Trying 207.200.74.26 ... Connected to ftp.netscape.com Escape character is '^]'. 220 ftp29 FTP server (UNIX(r) System V Release 4.0) ready. SYST 215 UNIX Type:L8 Version:SUNOS </verb> </tscreen> <p>Prima di tutto, esso ci da dettagli del sistema nel suo banner di default. Poi se noi diamo il comando <bf>SYST</bf> esso ci restituisce felicemente ulteriori informazioni. Se il FTP anonimo è supportato, spesso possiamo scaricare /bin/ls o altri eseguibile e determinare per quale archittetura sono stati costruiti. <p>Molte altre applicazioni ci danno informazioni troppo gratuite. Prendete i server web, per esempio: <p> <tscreen> <verb> playground> echo 'GET / HTTP/1.0\n'| nc hotbot.com 80 | egrep ' Server:' Server: Microsoft-IIS/4.0 playground> </verb> </tscreen> <p>Hmm. Mi meraviglio del S.O. che questi lamer stanno usando. <p> Altre tecniche classiche includono i record info del DNS dell'host(raramente efficace) e l'ingegneria sociale- Se la macchina sta in ascolto sulla porta 161/udp (snmp) vi siete garantiti un paio di info dettagliate usando 'snmpwalk' della distribuzione delle utility CMU SNMP e il nome della comunità 'public'. <sect> Attuali programmi di fingerprinting. <p> <bf>Nmap</bf> non è il primo programma per il riconoscimento del S.O. usando il fingerprinting TCP/IP. Il comune spoofer IRC <bf>sirc</bf> creato da Johan ha incluse tecniche molto rudimentali di fingerprinting sin dalla versione 3 (o precedente). Esso tenta di collocare un host nelle classi "Linux", "4.4BSD","Win95", o "Unknown" usando pochi semplici test sui flag TCP. <p>Un altro di tali programmi è <bf>checkos</bf>, rilasciato pubblicamente nel Gennaio di quest'anno da Shok in <it>Confidence Remains High Issue #7</it>. Le tecniche di fingerprinting sono esattamente le stesse di sirc, e anche il codice è identico in molte parti. <bf>Checkos</bf> era privatamente disponibile per lungo tempo precedente alla release pubblica, cosí io non ho nessuna idea su chi ha soffiato il codice e a chi. Ma nessuno dei due sembra attribuirlo all'altro. Una cosa che fa in piú checkos è il controllo del banner telnet, che è, utile ma ha i problemi descritti prima.[Aggiornamento: Shok scrisse di dire che non era mai stata sua intenzione rendere pubblico checkos e questo è il motivo perchè gli secca attribuire a sirc parte del codice]. <p>Anche Su1d scrisse un programma per determinare il S.O. Il suo è, chiamto <bf>SS</bf> e la versione 3.11 può identificare 12 tipi differenti di S.O. Sono piuttosto parziale in questo in quanto Su1d attribuisce al mio programma <bf>nmap</bf> del codice di networking:). <p>Poi c'è <bf>queso</bf>. Questo programma è il più nuovo ed rappresenta un enorme balzo in avanti rispetto agli altri programmi. Non solo fa quello che fanno gli altri e introduce un paio di test nuovi, ma esso è il primo (che ho visto) a spostare le fingerprint di un S.O. fuori dal codice. Gli altri scanner includono codice come: <tscreen> <verb> /*da SS */ if ((flagsfour & TH_RST) && (flagsfour & TH_ACK) && (winfour == 0) && (flagsthree & TH_ACK)) reportos(argv[2],argv[3], "Livigston Portmaster ComOS") ; </verb> </tscreen> <p>Invece <bf>queso</bf> sposta questo in un file di configurazione, che ovviamente è, molto meglio e rende l'aggiunta di un S.O. tanto facile quanto fare l'<tt>append</tt> ad un file di fingerprint con poche linee. Queso è stato scritto da Savage, uno della bella gente di Apostol.org. <p> Un problema con tutti i programmi descritti sopra è che essi sono molto limitati nel numero di test di fingerprinting, il che limita la granularità delle risposte. Voglio sapere molto di più che solo 'questa macchina è OpenBSD, FreeBSD, o NetBSD', desidero sapere esattamente sia quale di queste è, che il numero di versione della release. Allo stesso modo, vorrei piuttosto vedere 'Solaris 2.6' che semplicemente 'Solaris'. Per ottenere questa granularità nel risultato, ho lavorato su un numero di tecniche fingerprinting, le quali sono descritte nella prossima sezione. <sect>Metodologia di fingerprinting. <p> 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 <bf>nmap</bf> 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: <descrip> <tag><bf>La prova FIN</bf></tag> 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. <tag><bf>La prova del flag BOGUS</bf></tag> <bf>Queso</bf> è, 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. <tag><bf>Il campionamento TCP ISN</bf></tag> 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 <it>random increments</it> (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 <bf>sempre</bf> lo stesso esatto ISN:). Ho visto questo su alcuni hub della 3Com (usano 0x803) e le stampanti Apple Laserwriter (usano 0xc7001). <p>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. <tag>Bit "Non Frammentare"</tag> <p>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 <bf>nmap</bf> 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. <tag>Finestra Iniziale TCP</tag> 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 <bf>queso</bf> e <bf>nmap</bf> 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. <tag>Valore dell'ACK</tag> 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. <tag>Messaggi di errore ICMP</tag> 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 <tt>net/ipv4/icmp.h</tt>) limita la generazione dei messaggi <it>unreachable</it> 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 <it>unreachable</it> ricevuti. Prima questo non l'ho visto usato e infatti non l'ho aggiunto a <bf>nmap</bf>(eccetto per l'uso dello scanning delle porte UDP). <p>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. <tag>Riferimento dei Messaggi ICMP</tag> <p> 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 <it>unreachable</it>, 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 <bf>nmap</bf> di riconoscere Linux e Solaris, anche se non hanno alcuna porta in ascolto. <tag>Integrità dell'<it>echoing</it> del messaggio d'errore ICMP.</tag> Ho preso questa idea da qualcosa che Theo De Raadt (sviluppatore capo di OpenBSD) aveva postato al <tt>comp.security.unix.</tt> Come menzionato prima, le macchine devono inoltre mandare indietro parte del vostro messaggio originale con errore di porta <it>unreachable</it>. Ancora altre macchine tendono ad usare i vostri header come <it>spazio improvvisato</it> 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 <it>total length</it> 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. <bf>Nmap</bf> fa nove test differenti sugli errori ICMP per fare lo <it>sniff</it> su subdole differenze come queste. <tag>Tipo del Servizio</tag> Per i messaggi di porta <it>unreachable</it> (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. <tag>Gestione della frammentazione</tag> 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 (<htmlurl url="http://www.secnet.com/papers/IDS.PS" name="www.secnet.com">). <tag>Opzioni TCP</tag> Queste sono veramente una miniera d'oro in termini di perdita di informazioni. La bellezza di queste opzioni è che: <enum> <item> Esse sono generalmente opzionali(uff!) :) cosí non tutti gli host le implementano. <item> 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. <item> Potete mettere un intero insieme di opzioni in un pacchetto per fare il test un unica volta. </enum> <p><bf>Nmap</bf> manda queste opzioni con quasi ogni pacchetto di prova: <tscreen> <verb> Window Scale=10; NOP; Max Segment Size=265; Timestamp; End of Ops; </verb> </tscreen> <p>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. <p>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 <bf>e</bf> gli stessi valori, potete ancora differenziare attraverso l'ordine in cui le opzioni sono date, e dove il <it>padding</it> viene applicato. Per esempio Solaris restituisce <bf>NNTNWME</bf> che significa: <tscreen> <verb> <no op><no op><timestamp><no op><window scale><echoed MSS> </verb> </tscreen> <p>Mentre Linux 2.1.22 restituisce <bf>MENNTNW</bf>. 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. <tag>Cronologia dell'Exploit</tag> <p>Anche con tutti i test fatti sopra, <bf>nmap</bf> è 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. <p>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. <p>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. <tag>Resistenza al SYN Flood</tag> <p>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 <bf>nmap</bf> 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. </descrip> <sect>Implementazione di nmap e risultati <p> Ho creato una implementazione di riferimento delle tecniche di rilevamento S.O. menzionati sopra (eccetto quelle che ho detto che sono state esclude). Ho aggiunto questo al mio scanner <bf>Nmap</bf>, il quale ha il vantaggio che riconosce già quali porte sono aperte e chiuse per il fingerprinting, cosí non dovete dirglielo. Esso è pure portabile tra Linux, *BSD, Solaris 2.51 e 2.6, e alcuni altri sistemi operativi. <p>Le nuove versioni di nmap leggono un file riempito con i template di fingerprint, che seguono una grammatica semplice. Ecco qui un esempio: <tscreen> <verb> FingerPrint IRIX 6.2 - 6.4 # Grazie a Lamont Granquist TSeq(Class=i800) T1(DF=N%W=C000|EF2A%ACK=S++%Flags=AS%Ops=MNWNNT) T2(Resp=Y%DF=N%W=0%ACK=S%Flags=AR%Ops=) T3(Resp=Y%DF=N%W=C000|EF2A%ACK=O%Flags=A%Ops=NNT) T4(DF=N%W=0%ACK=O%Flags=R%Ops=) T5(DF=N%W=0%ACK=S++%Flags=AR%Ops=) T6(DF=N%W=0%ACK=O%Flags=R%Ops=) T7(DF=N%W=0%ACK=S%Flags=AR%Ops=) PU(DF=N%TOS=0%IPLEN=38%RIPTL=148%RID=E%RIPCK=E%UCK=E%ULEN=134%DAT=E) </verb> </tscreen> <p>Diamo un'occhiata alla prima linea (sto aggiungendo <bf>></bf> come marcatori): <p><bf>></bf> <tt>FingerPrint IRIX 6.2 - 6.3 # Grazie a Lamont Granquist </tt> <p>Questo semplicement dice che il fingerprint riguarda IRIX dalla versione 6.2 alla 6.3 e il commento dichiara che Lamont Granquist gentilmente mi ha mandato gli indirizzi IP o le fingerprint delle macchine IRIX testate. <p><bf>></bf> <tt>TSeq(Class=i800)</tt> <p>Questo significa che il campionamento ISN lo mette [N.d.T. l'host al cui abbiamo fatto lo scan di nmap] nella classe i800. Questo significa che ciascun nuovo numero della successione è un multiplo di 800 più dell'ultimo numero. <p><bf>></bf> <tt>T1(DF=N%W=C000|EF2A%ACK=S++%Flags=AS%Ops=MNWNNT)</tt> <p>Il test è denominato T1 (che sta per test1, intelligente no?). In questo test mandiamo un pacchetto SYN con un paio di opzioni TCP a una porta aperta.<tt>DF=N</tt> significa che il bit "non frammentare" della risposta non deve essere impostato. <tt>W=C000|EF2A</tt> significa che la "finestra" avvertimento che abbiamo ricevuto deve essere 0xC000 o EF2A.<tt>ACK=S++</tt> significa che il riconoscimento, che riceviamo deve essere il nostro numero di successione iniziale piú 1. <tt>Flags = AS</tt> significa che il flag ACK e SYN sono stati mandati nella risposta.<tt> Ops = MNWNNT</tt> significa che lo opzioni nella risposta devono essere (in questo ordine): <tscreen> <verb> <MSS (not echoed)><NOP><Window scale><NOP><NOP><Timestamp> </verb> </tscreen> <p><bf>></bf><tt> T2(Resp=Y%DF=N%W=0%ACK=S%Flags=AR%Ops=)</tt> <p> Il test 2 comporta un NULL con le stesse opzioni a una porta aperta. <tt> Resp=Y</tt> significa che possiamo ottenere una risposta. <tt>Ops= </tt> significa che non ci deve essere alcuna opzione inclusa nel pacchetto risposta. Se noi togliamo completamente '%Ops=' allora ogni opzione mandata dovrebbe corrispondere. <p><bf>></bf><tt> T3(Resp=Y%DF=N%W=400%ACK=S++%Flags=AS%Ops=M)</tt> <p>Il test 3 è un SYN|FIN|URG|PSH c/opzioni a una porta aperta. <p><bf>></bf> T4(DF=N%W=0%ACK=O%Flags=R%Ops=) <p>Questo è un ACK a una porta aperta. Notate che noi non abbiamo un Resp= qui. Questo significa che la mancanza di una risposta (ad esempio il pacchetto è stato lasciato cadere sulla rete o ci troviamo davanti a un firewall) non renderà incapace un match (o corrispondenza) purchè tutti gli altri testi "matchino" [N.d.T. ovvero siano in grado di creare una corrispondenza]. Facciamo questo perchè virtualmente ogni S.O. manderà una risposta, così una mancanza di risposta è generalmente un attributo delle condizioni dirette e non del S.O. in se stesso. Mettiamo il tag Resp nei test 2 e 3 perchè alcuni sistemi operativi scartano questi [N.d.T i pacchetti] senza rispondere. <p><bf>></bf> <tt> T5(DF=N%W=0%ACK=S++%Flags=AR%Ops=)</tt> <p><bf>></bf> <tt> T6(DF=N%W=0%ACK=O%Flags=R%Ops=)</tt> <p><bf>></bf> <tt> T7(DF=N%W=0%ACK=S%Flags=AR%Ops=)</tt> <p>Questi test sono un SYN,ACK, e FIN|PSH|URG, rispettivamente, a una porta chiusa. Le stesse opzioni come sempre sono impostate. Certamente tutto questo è, probabilmente ovvio dati i nomi descrittivi 'T5', 'T6', e 'T7' :). <p><bf>></bf><tt> PU(DF=N%TOS=0%IPLEN=38%RIPTL=148%RID=E%RIPCK=E%UCK=E%ULEN=134%DAT=E) </tt> <p> Questa frase è il test di "porta <it>unreachable</it>" (porta non raggiungibile). Dovreste riconoscere <tt>DF=N</tt>, l'abbiamo visto prima. <tt>TOS=0</tt> significa che il campo del tipo del servizio IP era 0. I due campi successivi danno il valore (esadecimale) del campo della lunghezza totale (total length) IP del messaggio header IP e la lunghezza totale data nel header IP, che ha fatto "echoing" indietro verso di noi. [N.d.T.In altre parole a cui l'host, che precedentemente era stato sottoposto allo scan, ha inoltrato verso di noi.] (<tt>RID=E</tt> significa che il valore RID che abbiamo indietro nella copia del nostro pacchetto originale UDP è stata aspettata (per esempio è uguale a quella che abbiamo mandato). <tt>RIPCK=E</tt> significa che non hanno [N.d.T i pacchetti mandati] fottuto il checksum (se lo avessero fatto, diremmo <tt>RIPCK=F</tt>). <tt> UCK=E</tt> significa che il checksum UDP è ancora corretto. Poi viene la lunghezza UDP che era <tt>0x134</tt> e <tt>DAT=E</tt> significa che essi hanno fatto l'echoing dei nostri dati in maiera corretta . In quanto la maggior parte delle implementazioni (inclusa questa) non manda ciascuno dei nostri dati UDP indietro, essi prendono DAT=E di default. <p>La versione di nmap con questa funzionalità è correntemente nel sesto ciclo beta privato. Potrebbe essere rilasciata nel momento in cui hai letto questo articolo in Phrack. Ma potrebbe pure non esserlo. Vedi <htmlurl url="http://www.insecure.org/nmap/" name="http://www.insecure.org/nmap/"> per l'ultima versione di <bf>nmap</bf>. <sect>Istantanee su Siti Internet Popolari <p>Ecco qui il divertente risultato di tutti i nostri sforzi. Possiamo ora prendere casualmente siti Internet e determinare quale S.O. stanno usando. Molte persone hanno eliminato i banner telnet, ecc. per mantenere questa imformazione privata. Ma il fatto di aver eliminato i banner è inutile grazie al nostro nuovo fingerprinter! Inoltre questo è un buon modo di esporre sia il <S.O. vostro favorito da schifezza> che quanto sono lamer alcuni utenti :)! <p>Il comando usato in questi esempi era: nmap -sS -p 80 -O -v <host> <p>Altra nota è che la maggior parte di questi scan è stata fatta 18/10/98. Alcune di queste persone possono avere upgradato/cambiato i server da allora. Notate che non tutti i siti posti qui mi piacciono. <p> <tscreen> <verb> # Siti "hacker" sites o (in un paio di casi) siti che pensano di esserlo: www.l0pht.com => OpenBSD 2.2 - 2.4 www.insecure.org => Linux 2.0.31-34 www.rhino9.ml.org => Windows 95/NT # No comment :) www.technotronic.com => Linux 2.0.31-34 www.nmrc.org => FreeBSD 2.2.6 - 3.0 www.cultdeadcow.com => OpenBSD 2.2 - 2.4 www.kevinmitnick.com => Linux 2.0.31-34 # Free Kevin! www.2600.com => FreeBSD 2.2.6 - 3.0 Beta www.antionline.com => FreeBSD 2.2.6 - 3.0 Beta www.rootshell.com => Linux 2.0.35 # Cambiato a OpenBSD dopo # che l'hanno comprato. # Consulenza, rivenditori per la Sicurezza, ecc. www.repsec.com => Linux 2.0.35 www.iss.net => Linux 2.0.31-34 www.checkpoint.com => Solaris 2.5 - 2.51 www.infowar.com => Win95/NT # Rivenditori fedeli ai loro S.O. www.li.org => Linux 2.0.35 # Linux International www.redhat.com => Linux 2.0.31-34 # Mi meraviglio, che distribuzione :) www.debian.org => Linux 2.0.35 www.linux.org => Linux 2.1.122 - 2.1.126 www.sgi.com => IRIX 6.2 - 6.4 www.netbsd.org => NetBSD 1.3X www.openbsd.org => Solaris 2.6 # Ahem :) www.freebsd.org => FreeBSD 2.2.6-3.0 Beta # Lega Ivy www.harvard.edu => Solaris 2.6 www.yale.edu => Solaris 2.5 - 2.51 www.caltech.edu => SunOS 4.1.2-4.1.4 # Ciaoo! Sveglia! Questi sono gli anni 90 :) www.stanford.edu => Solaris 2.6 www.mit.edu => Solaris 2.5 - 2.51 # Coincidenza che a cosi tante scuole ottime # piaccia Sun? # Forse è il 40% # di sconto sugli .edu :) www.berkeley.edu => UNIX OSF1 V 4.0,4.0B,4.0D www.oxford.edu => Linux 2.0.33-34 # Continuate cosí! # Siti Lamers www.aol.com => IRIX 6.2 - 6.4 # Nessuna meraviglia se essi sono così insicuri :) www.happyhacker.org => OpenBSD 2.2-2.4 # Sick of being owned, Carolyn? # # Anche il S.O più sicuro, # è inutile nelle mani di # un amministratore incompetente. # Misc www.lwn.net => Linux 2.0.31-34 # Questo è sito delle notizie Linux, continuate # cosí! www.slashdot.org => Linux 2.1.122 - 2.1.126 www.whitehouse.gov => IRIX 5.3 sunsite.unc.edu => Solaris 2.6 </verb> </tscreen> <p>Note: Nella relazione sulla sicurezza, Microsoft ha detto sulla sua trascurata sicurezza: " questa assunzione è stata cambiata negli anni in quanto Windows NT ha ottenuto popolarità principlamente a causa delle sue caratteristiche di sicurezza." Uhm, dove sto io non sembra Windows NT molto popolare tra la communità, che si occupa di sicurezza :). Io vedo solo 2 macchine Windows da un intero gruppo, e Windows è facile da distinguere per nmap in quanto esso molto scorretto (rispetto ai modi standard) [N.d.T. cioè ha un modo anomalo e al di là degli standard di comportarsi]. E certamente, c'è un sito in piú che dobbiamo controllare. Questo è il sito web della ultra-segreta Transmeta corporation. Cosa interessante è che la compagnia fu fondata da Paul Allen di Microsoft, ma dà lavoro a Linus Torvalds. Cosí essi supportano Paul e hanno in esecuzione NT o si allineano con i ribelli e si associano alla rivoluzione Linux ? Vediamo: <p>Usiamo il comando: <p><tt>nmap -sS -F -o transmeta.log -v -O www.transmeta.com//24</tt> <p>Questo significa fai un SYN scan per le porte conosciute (da /etc/services), logga i risultati e scrivili sul file <tt>trasmeta.log</tt>, si prolisso su esso, fai uno scan S.O., e "scanna" la classe 'C' dove www.transmeta.com risiede. Ecco l'elenco dei risultati: <p> <tscreen> <verb> neon-best.transmeta.com (206.184.214.10) => Linux 2.0.33-34 www.transmeta.com (206.184.214.11) => Linux 2.0.30 neosilicon.transmeta.com (206.184.214.14) => Linux 2.0.33-34 ssl.transmeta.com (206.184.214.15) => Linux versione sconosciuta linux.kernel.org (206.184.214.34) => Linux 2.0.35 www.linuxbase.org (206.184.214.35) => Linux 2.0.35 ( possilmente la stessa macchina di sopra) </verb> </tscreen> <p>Bene, penso che questo risponde alla nostre domanda abbastanza chiaramente:). <sect>Riconoscimenti. <p> La sola ragione per cui Nmap è in grado di rilevare cosí tanti differenti S.O. è che molte persone nella beta privata fecero tanti sforzi per ricercare nuove e eccitanti macchine su cui fare il fingerprint! In particolare, Jan Koum, van Hauser, Dmess0r, David O'Brien, James W. Abendschan, Solar Designer, Chris Wilson, Stuart Stock, Mea Culpa, Lamont Granquist, Dr. Who, Jordan Ritter, Brett Eldridge, e Pluvius hanno mandato tonnellate di indirizzi IP e/o fingerprint di macchine non raggiungibili attraverso Internet. <p>Grazie a Richard Stallman per aver scritto GNU Emacs. Questo articolo non sarebbe cosi ben word-wrapped se avessi usato vi o cat e ^D. <p> Domande e commenti possono essere mandati a <htmlurl url="mailto:fyodor@DHP.com" name="fyodor@DHP.com"> (se non funziona per qualche ragione, usate <htmlurl url="mailto:fyodor@insecure.org" name="fyodor@insecure.org">. Nmap può essere scaricato a <htmlurl url="http://www.insecure.org/nmap" name="http://www.insecure.org/nmap"> <sect> Note della versione Italiana <p> La traduzione italiana, non è l'unica esitono anche di questo eccellente documento le versioni Francese a cura di Arhuman <htmlurl url="mailto:arhuman@francemel.org" name="arhuman@francemel.org"> e quella portoghese a cura di Frank Ned <htmlurl url="mailto:frank@absoluta.org" name="frank@absoluta.org">. Io in quanto traduttore spero di aver fatto un buon lavoro, per ogni refuso contattatemi al <htmlurl url="mailto:sarata@cyberspace.org" name="sarata@cyberspace.org">, ci tengo. </article>