Das Erkennen von Betriebssystemen mittels TCP/IP Stack FingerPrinting von Fyodor (www.insecure.org) Erstellt: 18. Oktober 1998 Zuletzt geaendert: 10. April 1999 [Franzoesische Uebersetzung von Arhuman ] [Portugisische Uebersetzung von Frank Ned ] [Italienische Uebersetzung von Rige ] [Russische Uebersetzung von Alex Volkov ] [Spanische Uebersetzung von Marco Barbosa ] [Deutsche Uebersetzung von Stefan Maly ] Dieses Papier darf frei weitergegeben werden. Die jeweils neueste Ausfertigung sollte immer an folgender Stelle zu finden sein: http://www.insecure.org/nmap/nmap-fingerprinting-article.html UEBERSICHT Dieses Dokument behandelt, wie man durch geeignete Abfragen des TCP/IP- Stacks wertvolle Informationen ueber ein System erhalten kann. Zuerst erlaeutere ich einige Methoden, das Betriebssystem des Systems ohne einen Fingerabdruck herauszufinden. Dann beschreibe ich die aktuellen "state of the art" Methoden von Tools, die Fingerabdruecke eines Systems erstellen. Danach folgt eine beschreibung der vielen Techniken, die ein Remote-System dazu veranlassen koennen, Informationen ueber sich selbst herauszugeben. Schliesslich erlaeutere ich im Detail meine Implementation dieser Techniken in NMAP, gefolgt von einem Schnapp- schuss einiger populaerer Internet Sites, bezueglich deren Betriebssystem. GRUENDE Ich glaube, der Nutzen, herausfinden zu koennen, mit welchem Betriebssystem man es zu tun hat, ist ziemlich offensichtlich. Also werde ich mich in diesem Abschnitt kurz fassen. Eines der besten Beispiele fuer den Nutzen ist die Tatsache, dass viele Sicherheits- luecken von bestimmten Releasestaenden der Betriebssysteme abhaengig sind. Nehmen wir einmal an, dass Sie einen Penetrationstest machen und den Port 53 (DNS) offen finden. Sollte es sich bei dem hinter dem Port liegenden Programm um eine verwundbare Version von BIND handeln, erhalten Sie nur eine einzige Chance sie auszunutzen, da der demon anschliessend abstuerzt. Mit einem guten TCP/IP fingeprinter werden sie schnell herausfinden, dass auf dieser Maschine 'Solaris 2.51' oder 'Linux 2.0.35' laeuft und sind in der Lage, Ihre Shell-Skripten entsprechend anzupassen. Eine schlimmere Moeglichkeit ist jemand, der vorab 500.000 hosts scannt, um zu sehen, welches Betriebssystem dort laeuft und welche Ports offen sind. Wenn spaeter eine Sicherheitsluecke, z.B. in Sun's comsat Daemon bekannt werden sollte, kann unser kleiner Hacker diese Liste mit einem grep 'UDP/512' und 'Solaris 2.6' bearbeiten und erhaelt auf der Stelle Seite um Seite von Systemen, auf denen er root werden kann. Es sollte an dieser Stelle darauf hingewiesen werden, dass dies ein kindisches Vorgehen ist. Sie haben weder besondere Fertigkeiten bewiesen, noch wird jemand auch nur im Entferntesten beeindruckt sein, dass Sie in der Lage waren, einen Haufen verwundbarer .edu-Systeme zu finden, auf denen niemand rechtzeitig die Sicherheitsluecke stopfen konnte. Noch weniger werden die Leute beeindruckt sein, sollten Sie diese Luecke nun nutzen, die dort angesiedelten Websites mit von Ihnen angefertigten Seiten zu verunzieren, die das einzige Ziel haben, darauf hinzuweisen wie bloede die dortigen Systemadministratoren und wie gut Sie selbst sind. Eine andere moegliche Verwendung ist "social engineering". Nehmen wir einmal an, dass Sie ihre Ziel-Firma scannen und nmap Ihnen einen 'Datavoice TxPORT PRISM 3000 T1 CSU/DSU 6.22/2.06' anzeigt. Ein Hacker koennte nun als 'Datavoice Support' anrufen und ueber Probleme mit ihrem PRISM 3000 sprechen: "Wir werden in Kuerze einige Sicherheits- luecken bekanntgeben. Zuerst wollen wir aber sicherstellen, dass die meisten unserer Kunden die Patches bereits installiert haben, bevor wir diese Information veroeffentlichen. -- Der entsprechende Patch ist Ihnen bereits per Mail zugegangen." Einige naive Administratoren koennten nun glauben, dass nur ein autorisierter Techniker von Datavoice so viel ueber ihre CSU/DSU wissen kann. Eine andere Moeglichkeit, das fingerprinting zu nutzen, ist die Beurteilung und Evaluation von Firmen, mit denen Sie beabsichtigen Geschaefte zu machen. Bevor Sie beispielsweise einen neuen ISP waehlen, koennten Sie diesen scannen und sehen, welche Systeme er verwendet. Vielleicht sehen dann diese perfekten Angebote der Art "10 DM pro Monat" nicht mehr ganz so gut aus, nachdem Sie herausgefunden haben, dass sie aeusserst schlechte Router haben und PPP ueber einen Haufen von Windows-Kisten anbieten. KLASSISCHE TECHNIKEN Stack fingerprinting loest das Problem der Identifikation des Betriebssystems auf eine besondere Weise. Ich denke, dass diese Technik die zukunftstraechtigste ist, es gibt jedoch zur Zeit auch eine Vielzahl anderer Loesungen. Leider ist die folgende Moeglichkeit immer noch eine der effektivsten: 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: Es macht keinen Sinn, all die Schwierigkeiten eines fingerprintings auf sich zu nehmen, wenn das Zielsystem die exakte Information in alle Welt hinausposaunt! Leider liefern die Hersteller auch heute noch Systeme, die diese Art von Begruessungstexten haben und viele Administratoren schalten einen solchen Text nicht ab. Nur weil es auch andere Wege gibt, das Betriebssystem herauszufinden (wie z.B. fingerprinting), heisst das doch noch lange nicht, dass man diese Informationen aller Welt offen bekannt machen sollte. Die Probleme beim Rueckgriff auf diese Methode sind, dass eine zunehmende Zahl von Personen die Begruessungen abschaltet, viele Systeme keine detaillierte Information ausgeben und es aeusserst einfach ist, dort falsche Angaben zu machen. Nichtsdestoweniger ist das Lesen eben dieser Begruessungstexte alles, was sie von kommerziellen Tools erhalten, nachdem Sie tausende von Mark in diese investiert haben. Laden Sie sich stattdessen lieber nmap oder queso und sparen Sie Ihr Geld :). Selbst wenn Sie die Begruessungstexte ausgeschaltet haben, werden viele Applikationen nur zu gerne diese Art von Informationen bereitstellen, sobald sie gefragt werden. Schaun wir uns beispielsweise einen FTP- Server an: 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 Zunaechst einmal erhalten wir Details ueber das System im Standard- Begruessungstext. Dann, nachdem wir das 'SYST'-Kommando verwenden, liefert uns das bereitwillig weitere Informationen. Falls anonymes FTP unterstuetzt wird, koennen wir haeufig /bin/ls oder andere Binaerdateien herunterladen und herausfinden, fuer welche Betriebssystemarchitektur diese erzeugt wurden. Viele andere Applikationen gehen zu freizuegig mit Informationen um. Nehmen wir z.B. Webserver: playground> echo 'GET / HTTP/1.0\n' | nc hotbot.com 80 | egrep '^Server:' Server: Microsoft-IIS/4.0 playground> Hmmm ... was fuer ein Betriebssystem koennten diese Penner verwenden? Andere klassische Techniken beinhalten DNS host info records (selten erfolgreich) und social engineering. Falls das System auf Port 161/udp (snmp) antwortet, werden wir fast garantiert einen Haufen Detaillinfos mit einem 'snmpwalk' aus der CMP SNMP tools distribution und dem Community-Namen 'public' erhalten. AKTUELLE FINGERPRINTING PROGRAMME Nmap ist nicht das erste Programm, das Betriebssysteme mittels TCP/IP fingerprinting erkennt. Der bekannte IRC spoofer sirc von Johan beinhaltete bereits aeusserst rudimentaeres fingerprinting seit Version 3 (oder frueher). Es versucht, ein System in die Klassen "Linux", "4.4BSD", "Win95", oder "Unknown" einzuordnen, indem es ein paar einfache TCP flag Tests durchfuehrt. Ein weiteres solches Programm ist checkos, dass im Januar 1998 von Shok in der Ausgabe #7 von Confidence Remains High herausgegeben wurde. Die fingerprinting-Techniken sind genau die gleichen wie die von SIRC und sogar der Code aehnelt sich an vielen Stellen. Checkos gab es inoffiziell lange bevor es offiziell herausgegeben wurde. Daher habe ich keine Ahnung, wer hier von wem abgeschrieben hat. Jedoch hat anscheinend keiner den anderen dankend erwaehnt. Eine Sache, die checkos zum Scan hinzugefuegt hat ist die Analyse von Telnet Begruessungs- texten, was zwar nuetzlich ist, jedoch die oben beschriebenen Probleme aufweist. [ Update: Shok hat mir geschrieben, um mitzuteilen, dass es nie geplant war, checkos oeffentlich verfuegbar zu machen und dass dies der Grund dafuer ist, dass er sich keine Muehe gegeben hat, SIRC fuer einen Teil des Programmcodes zu danken. ] Suld hat ebenfalls ein Programm zum Pruefen der Betriebssystemversion geschrieben. Der Name seines Programms ist SS und in Version 3.11 kann es 12 unterschiedliche Typen von Betriebssystemen unterscheiden. Ich will mich nicht naeher dazu auslassen, nachdem er nmap als Quelle eines Teils seines Netzwerk-Codes nennt :). Darueberhinaus gibt es queso. Dieses Programm ist das neueste und stellt gegenueber den anderen Programmen einen gigantischen Sprung nach vorn dar. Es fuehrt nicht nur eine Reihe neuer Tests ein, sondern war auch das erste (dass ich gesehen habe), das die Fingerabdruecke aus dem Programmtext herausgeloest hat. Waehrend die anderen Scanner Code wie: /* from ss */ if ((flagsfour & TH_RST) && (flagsfour & TH_ACK) && (winfour == 0) && (flagsthree & TH_ACK)) reportos(argv[2],argv[3],"Livingston Portmaster ComOS"); enthalten, hat queso dies in eine Konfigurationsdatei ausgelagert, die offensichtlich besser fuer Anpassungen geeignet ist und das Hinzufuegen eines Betriebssystems zum Hinzufuegen von ein paar Zeilen in der Datei mit den Fingerabdruecken macht. Queso wurde von Savage geschrieben, einer der hervorragenden Leute bei Apostols.org . Ein Problem bei all den oben beschriebenen Programmen ist, dass sie in der Anzahl der fingerprinting Tests sehr eingeschraenkt sind, was die Exaktheit der Antworten ebenfalls stark einschraenkt. Ich moechte einfach mehr wissen als nur 'diese Maschine hat OpenBSD, FreeBSD oder NetBSD', ich will genau wissen, welches davon es ist und ausserdem eine Idee davon haben, welche Versionsnummer es sein koennte. Genauso wuerde ich lieber 'Solaris 2.6' als 'Solaris' sehen. Um diese Exaktheit bei den Antworten zu erhalten, habe ich an eine Anzahl von fingerprinting Techniken gearbeitet, die alle im folgenden Abschnitt beschrieben sind. METHODEN FUER DAS FINGERPRINTING Es gibt viele, viele Techniken, die es ermoeglichen, einen Fingerabdruck von networking stacks zu erzeugen. Im Prinzip suchen Sie nach Dingen, die sich zwischen verschiedenen Betriebssystemen unterscheiden und schreiben ein Programmstueck, das entsprechende Unterschiede testet. Wenn Sie ausreichend Tests kombinieren, koennen sie die Betriebssysteme mit hoher Wahrscheinlichkeit erkennen. Zum Beispiel kann nmap zwischen Solaris 2.4, Solaris 2.5-2.51 und Solaris 2.6 verlaesslich unterscheiden. Hier sind ein paar Techniken dazu: Die FIN probe -- Hier senden wir ein FIN Paket (oder irgend ein Paket ohne ein ACK oder SYN flag) an einen offenen Port und warten auf eine Antwort. Das korrekte in RFC 793 spezifizierte Verhalten ist, nicht zu antworten, jedoch gibt es eine ganze Reihe von verkorksten Implementationen die wie z.B. MS Windows, BSDI, CISCO, HP/UX, MPS und IRIX stattdessen ein RESET zurueckschicken. Die meisten aktuellen Tools verwenden diese Technik. Der BOGUS flag Test -- Queso ist der erste Scanner, den ich gesehen habe, der diesen cleveren Test verwendet. Die Grundidee ist, ein undefiniertes TCP "flag" ( 64 oder 128) im TCP header eines SYN Pakets zu verwenden. Linux Kisten vor 2.0.35 uebernehmen die Flag Einstellung in ihren Antworten. Ich habe kein anderes Betriebssystem gefunden, dass diesen Fehler ebenfalls aufweist. Allerdings scheinen einige Betriebssysteme die Verbindung zu resetten, sobald sie ein SYN+BOGUS Paket erhalten. Auch dieses Verhalten kann nuetzlich sein, sie zu identifizieren. Sammeln von TCP Sequenznummern -- Die Grundidee ist hier, Muster in den zu Beginn der Kommunikation verwendeten TCP Seriennummern zu finden. Die hier verwendeten Nummern koennen in viele Gruppen, wie z.B. 64K (viele alte UNIX Kisten), zufaellige Erhoehungen (neuere Versionen von Solaris, IRIX, FreeBSD, Digital UNIX, Cray und viele andere), "tatsaechliche" Zufallszahlen (Linux 2.0.*, OpenVMS, neuere AIX, etc). Windows Kisten (und ein paar andere) verwenden ein "zeitbasiertes" Modell, bei dem die Seriennummer je Zeiteinheit um eine, festgelegte Zahl erhoeht wird. Unnoetig zu sagen, dass dies fast ebensoleicht ueberlistet werden kann als die alte 64K Methode. Natuerlich ist mir die Verwendung von "konstanten" Zahlen am allerliebsten. Diese Maschinen verwenden immer die exakt gleiche Seriennummer zu Beginn einer Kommunikation. :) Ich habe das bei ein paar 3Com hubs (verwenden 0x803) und Apple LaserWriter Druckern (verwenden 0xC7001) gesehen. Die so gebildeten Gruppen wie z.B. Zufallszahl koennen nach Varianz, groessten gemeinsamen Teilern und anderen Funktionen, die auf die Folge der Sequenznummern und auf ihre Differenz angewendet werden, weiter unterklassifiziert werden. Es sollte beachtet werden, dass die Erzeugung von Seriennummern einige wichtige Auswirkungen auf die Sicherheit hat. Fuer weiterfuehrende Informationen zu diesem Thema, kontaktieren Sie bitte den "Sicherheitsexperten" Tsutomu "Shimmy" Shimomura bei der Firma SDSC und fragen ihn, wie er angestellt wurde. Nmap ist das erste Programm, das ich gesehen habe, welches diesen Effekt fuer die Identifizierung von Betriebssystemen verwendet. Don't Fragment bit -- Viele Betriebssysteme beginnen, das 'Don't Fragment' Bit in einigen Paketen zu setzen. Dies fuehrt zu den unterschiedlichsten Performance-Vorteilen (obwohl dies auch zu Problemen führen kann -- das ist der Grund, weshalb nmaps Fragmentierungs-Scans nicht von Solaris Kisten aus funktionieren). Auf jeden Fall tun das nicht alle Betriebssysteme und einige nur in bestimmten Faellen, daher erhalten wir durch Beobachten dieses Bits sogar noch mehr Informationen ueber das Ziel-Betriebssystem. Auch diese Methode habe ich bisher sonst noch nirgendwo gesehen. TCP Initial Window -- Dies hat einfach mit der Ueberpruefung der TCP Fenstergroesse (window size) von Antwortpaketen zu tun. Aeltere Scanner verwendeten einfach nur eine Fenstergroesse ungleich Null bei einem RST-Paket, um "BSD 4.4 derived" auszugeben. Neuere Scanner, so wie queso und nmap behalten die exakte Fenstergroesse im Auge, da diese pro Betriebssystem ziemlich konstant bleibt. Dieser Test liefert uns tatsaechlich eine ganze Menge Information, da manche Betriebssysteme sogar durch die Fenstergroesse allein identifiziert werden koennen (z.B. ist AIX das einzige Betriebs- system, das ich hier mit dem Wert 0x3F25 gesehen habe). In ihrem "voellig neu geschriebenen" TCP-Stack fuer NT5 verwendet Microsoft den Wert 0x402E. Interessanterweise ist das genau der Wert, den auch OpenBSD und FreeBSD verwenden. ACK Sequenznummern - Obwohl man vermuten koennte, dass dies komplett standardisiert ist, unterscheiden sich die Implementationen hier manchmal in den verwendeten Werten. Nehmen wir beispiels- weise einmal an, Sie senden ein FIN|PSH|URG an einen geschlossenen TCP port. Die meisten Implementationen werden die Sequenznummer im ACK-Paket auf den gleichen Wert setzen wie Ihre eigene Sequenz- nummer. Windows jedoch und einige "dumme" Drucker werden Ihnen Ihre Sequenznummer+1 zurueckgeben. Falls Sie ein SYN|FIN|URG|PSH an einen offenen Port senden, ist Windows sehr inkonsistent. Manchmal erhalten Sie ihre Sequenznummer zurueck, manchmal diese um Eins erhoeht und manchmal eine scheinbar zufaellige Nummer. Man muss sich schon fragen, was fuer eine Art Programmcode MS hier schreibt, damit dieser seine Meinung auf diese Weise aendert. ICMP Error Message Quenching -- Manche (schlauen) Betriebssysteme folgen dem in RFC 1812 gemachten Vorschlag, die Wiederholungsrate zu begrenzen, mit der unterschiedliche Fehlernachrichten gesendet werden. Der Linux Kernel beispielsweise beschraenkt (in net/ipv4/icmp.h) die Erzeugung von "destination unreachable" Nachrichten auf ein Maximum von 80 innerhalb von 4 Sekunden mit einer 1/4 Sekunde Zwangspause, falls diese Zahl ueberschritten wird. Eine Moeglichkeit, dies zu testen ist, einen Haufen Pakete an irgend einen hohen UDP Port zu senden und die Anzahl von ICMP destination unreachables zu zaehlen, die daraufhin empfangen werden. Ich habe einen solchen Test bislang nicht gesehen und habe es tatsaechlich auch nicht in nmap eingebaut (ausser bei UDP port scanning). Dieser Test wuerde die Erkennung des Betriebs- system ein wenig langsamer machen, da hierzu ein Haufen Pakete gesendet werden muesste und anschliessend eine Weile auf Antwort gewartet wird. Ausserdem waere die Behandlung von im Netzwerk verlorengegangenen Paketen eine Zumutung. ICMP Message Quoting -- Die RFCs geben vor, dass ICMP Fehlermeldungen eine Beschreibung sowie einen Teil der Paketdaten desjenigen Pakets enthalten muessen, welches den Fehler verursacht hat. Im Fall einer "port unreachable" Nachricht geben jedoch fast alle Implementationen nur den benoetigten IP-Header+8 Bytes zurueck. Solaris sendet hier ein wenig mehr und Linux sogar noch mehr. Das Schoene daran ist, dass dieser Effekt es nmap erlaubt, Linux und Solaris sogar dann zu erkennen, wenn keine Ports offen sind. Integritaet von Antworten auf ICMP-Fehlermeldungen -- Ich habe diese Idee durch Nachrichten bekommen, die The De Raadt (ein Chefent- wickler von OpenBSD) an comp.security.unix gesendet hat. Wie bereits zuvor erwaehnt, muessen Systeme einen Teil der Original- nachricht im Fall einer "port unreachable"-Nachricht in der Antwort zurueckschicken. Jedoch verwenden einige Systeme diese Header als Pufferspeicher waehrend der anfaenglichen Verarbeitung. Daher werden diese ein wenig in Mitleidenschaft gezogen, bevor Sie sie zurueckerhalten. AIX und BSDI senden Ihnen beispielsweise ein 'total length' Feld zurueck, das 20 Bytes zu viel anzeigt. Ein paar BSDI, FreeBSD, OpenBSD, ULTRIXe und VAXes zerstoeren die IP ID, die sie gesendet haben. Waehrend sich die Pruefsumme aufgrund der geaenderten TTL sowieso aendert, gibt es einige Systeme (AIX, FreeBSD und andere), die eine inkonsistente oder auf 0 lautende Pruefsumme zurueckgeben. Alles in allem fuehrt nmap neun unterschiedliche Tests auf ICMP Fehler durch, um gering- fuegige Unterschiede wie diese herauszufinden. Type of Service -- Fuer die meisten ICMP port unreachable Nachrichten habe ich mir den TOS Wert des zurueckgegebenen Pakets angesehen. Beinahe alle Implementationen verwenden 0 fuer diesen ICMP-Fehler, obwohl Linux 0xC0 verwendet. Dies bedeutet keinen der herkoemm- lichen TOS-Werte sondern stattdessen einen Teil des (so viel ich weiss) unbenutzten precedence Felds. Ich habe keine Ahnung, weshalb dieser Wert gesetzt wird, aber wenn Linux mal zu 0 zurueckfinden wird, wird uns das ermoeglichen, alte Versionen zu erkennen und zwischen alt und neu zu unterscheiden. Die Behandlung von Fragmenten -- Das ist die bevorzugte Technik von Thomas H. Ptacek von Secure Networks, Inc (jetzt von einem Haufen Windows-Benutzer bei NAI aufgekauft). Hier wird die Tatsache ausgenutzt, dass unterschiedliche Implementationen haeufig ueberlappende IP-Fragmente auf unterschiedliche Weise handhaben. Ein paar ueberschreiben die bereits empfangenen Teile mit den neuen, in anderen Faellen wird das bisher empfangene hoeher bewertet. Es gibt viele unterschiedliche Tests, die man verwenden kann, wie das Paket wieder zusammengesetzt wurde. Ich habe diese Faehigkeit nicht eingebaut, da ich keine portable Moeglichkeit kenne, IP-Fragmente zu senden (speziell auf Solaris ist das beinahe ein Ding der Umoeglichkeit). Fuer weiterfuehrende Informationen zu ueberlappenden Fragmenten koennen sie das IDS Papier (www.secnet.com) lesen. TCP Optionen -- Diese sind im wahrsten Sinne des Wortes eine Goldmine beim unfreiwilligen Herausgeben von Information. Das Schoene dabei ist: 1) Die Implementation ist freiwillig (tada!) :) und wird daher nicht auf allen Systemen implementiert. 2) Sie finden heraus, ob ein System sie implementiert, indem Sie eine Anfrage mit einer gesetzten Option senden. Das Zielsystem signalisiert Ihnen die Unterstuetzung der Option grundsaetzlich dadurch, dass sie auch im Antwortpaket enthalten ist. 3) Ausserdem koennen alle moeglichen Optionen gleichzeitig in ein einziges Paket verpackt werden, so dass alles auf einmal getestet werden kann. Nmap sendet diese Optionen in fast jedem Testpaket: Window Scale=10; NOP; Max Segment Size = 265; Timestamp; End of Ops; Beim Erhalten der Antwort, wird geprueft, welche Optionen unter- stuetzt und damit zurueckgesendet werden. Einige Betriebssysteme wie z.B. die neuesten FreeBSD Kisten unterstuetzten alles oben genannte, waehrend andere, wie z.B. Linux 2.0.x nur einige wenige unterstuetzen. Die neuesten Linux 2.1.x Kernals unterstuetzen alles oben genannte. Auf der anderen Seite sind sie anfaelliger fuer das Vorhersagen von TCP Sequenznummern. Urteilen Sie selbst. Selbst wenn mehrere Betriebssysteme die gleiche Auswahl von Optionen untestuetzen, koennen Sie sie manchmal daran unterscheiden, wie die Werte dieser Optionen gesetzt werden. Wenn Sie beispiels- weise einen kleinen MSS-Wert an eine Linux Kiste schicken, wird diese generell diese MSS (max segment size) zu ihnen zuruecksenden. Andere Hosts werden einen anderen Wert zurueckgeben. Und selbst wenn Sie die gleiche Auswahl von Optionen mit genau den gleichen Werten zurueckerhalten, koennen sie immer noch die Reihenfolge unterscheiden, in der die Optionen zurueckgegeben werden und wie das Auffuellen mit stattfindet. Solaris zum Beispiel gibt die Reihenfolge 'NNTNWME' zurueck, was ausgeschrieben bedeuetet: Linux 2.1.122 hingegen gibt 'MENNTNW' zurueck. Die gleichen Optionen, die gleichen Werte aber eine andere Reihenfolge! Ich habe keine anderen Tools zum Erkennen von Betriebssystemen gesehen, die TCP Optionen verwenden, aber es ist aeusserst nuetzlich. Es gibt ein paar weitere nuetzliche Optionen, die ich bei Gelegenheit ausprobieren werde, so wie z.B. T/TCP und selektive acknowledgements. Ausnutzen der zeitlichen Abfolge -- Selbst durch all die oben genannten Tests, kann nmap die Stacks von Win95, WinNT oder Win98 nicht unterscheiden. Dies ist eher ueberraschend, insbesondere wenn man bedenkt, dass Win98 ca. 4 Jahre nach Win95 herausgekommen ist. Man sollte meinen, dass sie den Stack verbessert haben (z.B. indem sie mehr TCP-Optionen unterstuetzen) und dass wir so in der Lage waeren, Unterschiede festzustellen. Leider ist das jedoch nicht der Fall. Sogar der NT-Stack ist das gleiche mistige Zeug, das sie in '95 gepackt haben. Und sie haben sich auch nicht bemueht, es fuer '98 zu verbessern. Aber nur nicht die Hoffnung aufgeben, es gibt eine Loesung. Sie koennen einfach mit fruehen Windows DOS (denial of service) An- griffen beginnen (Ping of Death, Winnuke, etc) und ein wenig weitermachen mit neueren Angriffen wie Teardrop und Land. Nach jedem Angriff pruefen Sie, ob Sie das System noch pingen koennen oder ob es bereits zusammengebrochen ist. Nachdem das System dann zusammengebrochen ist, koennen Sie ziemlich genau, Art, Releasestand und eventuell sogar Service Pack oder Hotfix bestimmen. Ich habe diese Funktionalitaet nicht in nmap integriert, obwohl ich zugeben muss, dass es eine Versuchung ist :). Widerstandsfaehigkeit gegen SYN Flooding -- Manche Betriebssysteme hoeren auf, auf neue Verbindungen anzunehmen, wenn Sie zu viele gefaelschte SYN Packete auf einmal erhalten (das Faelschen von Paketen vermeidet das Problem, dass Ihr eigener Kernel die Verbindungen wieder zuruecksetzen muss). Viele Betriebssysteme koennen nur 8 Pakete gleichzeitig handhaben. Die neuesten Linux Kernels (und andere Betriebsysteme) bieten die unterschiedlich- sten Methoden wie SYN cookies, um zu verhindern, dass dies zu einem ernsten Problem wird. Somit koennen Sie etwas ueber das Zielbetriebssystem erfahren, indem sie nur 8 Pakete mit gefaelschter Absendeadresse an einen offenen Port senden und anschliessend testen, ob Sie anschliessend noch mit dem System kommunizieren koennen. Auch das ist nicht in nmap uebernommen worden, da viele Leute sich darueber aufregen, mit einem SYN-Flood-Angriff konfrontiert zu werden. Auch wenn Sie erklaeren, dass Sie lediglich versucht haben, das Betriebssystem herauszu- finden, das sie laufen haben, wird nicht sonderlich zu ihrer Beruhigung beitragen. DIE VERWENDUNG VON NMAP UND DIE ERGEBNISSE Ich habe eine Referenzimplementation fuer die oben erwaehnten Techniken zum Erkennen der Betriebssysteme (ausser denjenigen, die ich wie bereits erwaehnt nicht eingebaut habe) erstellt. Diese Informationen habe ich nmap hinzugefuegt, was den Vorteil hat, dass nmap bereits weiss, welche Ports offen oder geschlossen sind und Sie ihm also nichts vorgeben muessen. Ausserdem ist nmap portabel auf Linux, *BSD und Solaris 2.51 und 2.6, sowie ein paar anderen Betriebssystemen. Die neue Version von nmap liest eine Datei mit Fingerabdruecken ein, die einer einfachen Grammatik unterworfen sind. Hier ein Beispiel: FingerPrint IRIX 6.2 - 6.4 # Thanks to 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) Sehen wir uns einmal die erste Zeile an. (ich fuege '>' als Kommentar- zeichen hinzu): > FingerPrint IRIX 6.2 - 6.3 # Thanks to Lamont Granquist Das bedeutet einfach nur, dass dieser Fingerabdruck IRIX in den Versionen 6.2 bis 6.3 abdeckt, der Kommentar gibt an, dass Lamont Granquist so freundlich war, mir die IP-Adressen oder Fingerabdruecke von getesteten IRIX Kisten geschickt hat. > TSeq(Class=i800) Dies bedeutet, dass das Ermitteln von zu Beginn der Kommunikation verwendeten Seriennummern (ISN) es in die "i800 Klasse" eingeordnet haben. Das bedeutet, dass jede neue Sequenznummer ein Vielfaches von 800 groesser ist als die vorausgehende. > T1(DF=N%W=C000|EF2A%ACK=S++%Flags=AS%Ops=MNWNNT) Der Test hat den Namen T1 (fuer Test1, clever nicht wahr?). In diesem Test senden wir ein SYN Paket mit einem Haufen von TCP-Optionen an einen offenen Port. DF?N bedeutet, dass das 'don't fragment' Bit in der Antwort nicht gesetzt sein darf. W=C000|EF2A bedeutet, dass das angebotene Fenster entweder 0xC000 oder 0xEF2A sein muss. ACK=S++ bedeutet, dass die Bestaetigung die eigene Seriennummer+1 enthalten muss. Flags=AS bedeutet, dass SYN und ACK Flags in der Antwort enthalten sein muessen. Ops = MNWNNT bedeutet, dass die Optionen in der Antwort in dieser Abfolge enthalten sein muessen: > T2(Resp=Y%DF=N%W=0%ACK=S%Flags=AR%Ops=) Test 2 beinhaltet das senden eines Null-Pakets mit den gleichen Optionen an einen offenen Port gesendet. Resp=Y bedeutet, dass wir auf jeden Fall eine Antwort erhalten muessen. Ops= bedeutet, dass im Antwortpaket keine Optionen enthalten sein duerfen. Wuerden wir '$Ops=' herausnehmen, wuerden jegliche gesendeten Optionen passen. > T3(Resp=Y%DF=N%W=400%ACK=S++%Flags=AS%Ops=M) Test 3 ist ein SYN|FIN|URG|PSH mit Optionen gesendet an einen offenen Port. > T4(DF=N%W=0%ACK=O%Flags=R%Ops=) Dies ist ein ACK, das an einen offenen Port gesendet wird. Bitte beachten Sie, dass wir kein Resp= haben. Das bedeutet, dass das Fehlen einer Antwort (so wie zum Beispiel wenn das Paket auf dem Netz verlorengeht oder von einer Firewall verworfen wird) wird das Zusammenpassen nicht verhindern, solange die anderen Bedingungen des Fingerabdrucks alle erfuellt sind. Wir tun dies, weil so ziemlich jedes Betriebssystem hier eine Antwort sendet, was wiederum bedeutet, dass das Fehlen einer Antwort generell eher ein Zeichen fuer die Qualitaet des Netzwerks und nicht fuer das Betriebssystem selbst ist. Wir haben Resp in die Tests 2 und 3 gepackt, weil ein paar Betriebssysteme diese Pakete wegwerfen, ohne zu antworten. > 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=) Diese Tests sind SYN, ACK, und FIN|PSH|URG, jeweils an einen geschlos- senen Port gesendet. Die gleichen Optionen werden jeweils gesetzt. Natuerlich ist dies ziemlich klar, da ja die Namen 'T5', 'T6', und 'T7' aeusserst sprechend sind :). > PU(DF=N%TOS=0%IPLEN=38%RIPTL=148%RID=E%RIPCK=E%UCK=E%ULEN=134%DAT=E) Dieses Riesenbaby ist der 'port unreachable' Test. Sie sollten das DF=N bereits kennen. TOS=0 bedeutet, dass das 'IP type of service' Feld auf 0 gesetzt wird. Die naechsten zwei Felder geben die (Hex-)Werte der Felder 'ip total length' des gesendeten und des daraufhin empfangenen Pakets wieder. RID=E bedeutet, dass der RID Wert, den wir in der Kopie unseres urspruenglich gesendeten UDP-Pakets gesendet haben erwartet wurde (expected) und gleich bleiben muss. RIPCK=E bedeutet, dass die andere Seite die Pruefsumme nicht versaubeutelt hat (anderenfalls waere es RIPCK=F gewesen). UCK=E bedeutet, dass die UDP Pruefsumme ebenfalls korrekt ist. Als naechstes kommt die UDP Laenge, welche 0x134 war und DAT=E was bedeutet, dass unsere UDP-Daten korrekt zurueckgesendet werden. Nachdem die meisten Implementationen (und so auch diese) keine Daten zurueckschicken, erfuellen sie die Bedingung DAT=E ebenfalls per Default. Die Version von nmap mit dieser Funktionalitaet ist momentan im 6. privaten Beta-Testzyklus. Es kann durchaus sein, dass sie bereits herausgegeben wurde, wenn Sie diesen Artikel in Phrack lesen. Vielleicht aber auch nicht. Schaun sie unter http://www.insecure.org/nmap nach, um die neuste Version zu finden. MOMENTAUFNAHMEN POPULAERER SITES Hier ist das vergnuegliche Ergebnis all unserer Bemuehungen. Wir koennen jetzt zufaellig ausgewaehlte Internet-Sites hernehmen und feststellen, welches Betriebssystem sie verwenden. Ein Haufen dieser Leute hat die Telnet-Begruessungstexte usw. geloescht, um diese Informationen geheim zu halten. Aber das hat keine Wirkung mit unserem Fingeabdruck-System! Ausserdem ist das eine gute Moeglichkeit, unsere Benutzer als die Penner, die sie sind zu entlarven :)! Der in diesem Beispielen verwendete Kommandozeilenbefehl war: nmap -sS -p 80 -O -v Bitte beachten Sie, dass die meisten dieser Scans am 18.10.1998 gemacht wurden. Ein paar dieser Leute koennten Ihre Server geaendert oder verbessert haben seit damals. Beachten Sie, dass ich nicht jede hier aufgefuehrte Site mag. # "Hacker" sites or (in a couple cases) sites that think they are 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 # Changed to OpenBSD after # they got owned. # Security vendors, consultants, etc. 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 # Vendor loyalty to their OS www.li.org => Linux 2.0.35 # Linux International www.redhat.com => Linux 2.0.31-34 # I wonder what distribution :) 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 # Ivy league www.harvard.edu => Solaris 2.6 www.yale.edu => Solaris 2.5 - 2.51 www.caltech.edu => SunOS 4.1.2-4.1.4 # Hello! This is the 90's # :) www.stanford.edu => Solaris 2.6 www.mit.edu => Solaris 2.5 - 2.51 # Coincidence that so many # good # schools seem to like Sun? # Perhaps it is the 40% # .edu discount :) www.berkeley.edu => UNIX OSF1 V 4.0,4.0B,4.0D www.oxford.edu => Linux 2.0.33-34 # Rock on! # Lamer sites www.aol.com => IRIX 6.2 - 6.4 # No wonder they are so # insecure :) www.happyhacker.org => OpenBSD 2.2-2.4 # Sick of being owned, Carolyn? # Even the most secure OS is # useless in the hands of an # incompetent admin. # Misc www.lwn.net => Linux 2.0.31-34 # This Linux news site rocks! www.slashdot.org => Linux 2.1.122 - 2.1.126 www.whitehouse.gov => IRIX 5.3 sunsite.unc.edu => Solaris 2.6 Anmerkungen: In Ihrem Whitepaper ueber Sicherheit, hat Microsoft ueber Ihre laxe Einstellung zu Sicherheitsfragen geschrieben: "Diese An- nahme hat sich ueber die Jahre hinweg geaendert, nachdem Windows NT sich aufgrund seiner Sicherheits-Features wachsender Beliebtheit erfreuen konnte." Hmm. Aus meiner sicht sieht es eigentlich so aus, als ob Windows nicht sonderlich beliebt ist in der Gemeinschaft derer, die sich mit Sicherheit befassen :). Ich kann nur 2 Windows Kisten in der gesamten Gruppe finden und Windows ist fuer nmap leicht zu unterscheiden, weil es (vom Gesichtpunkt der Standards aus) so verkorkst ist. Und natuerlich muessen wir eine weitere Site pruefen. Es ist die Web- Site der ultra geheimen Transmeta Corporation. Interessanterweise wurde diese Firma im wesentlichen von Paul Allen von Microsoft gegruendet, hat jedoch Linus Torvalds als Angestellten. Werden sie also Paul die Stange halten und NT verwenden oder auf der anderen Seite bei den Rebellen stehen und der Linux Revolution beitreten? Mal sehen: Wir verwenden den Befehl: nmap -sS -F -o transmeta.log -v -O www.transmeta.com//24 Das bedeutet SYN scan auf bekannten Ports (von /etc/services), die Resultate in 'transmeta.log' speichern, viele Details (verbose), einen Betriebssystem-scan machen und das gesamte C-Netz ueberpruefen, wo 'www.transmeta.com' liegt. Hier ist das Wesentliche zusammengefasst aus den Resultaten: 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 unknown version linux.kernel.org (206.184.214.34) => Linux 2.0.35 www.linuxbase.org (206.184.214.35) => Linux 2.0.35 ( possibly the same machine as above ) Nun, ich denke, dass dies eine ziemlich klare Beantwortung unserer Frage ist :). DANKSAGUNGEN Der einzige Grund, weshalb nmap heute in der Lage ist, so viele unterschiedliche Betriebssysteme zu erkennen, ist, dass viele Leute im privaten Beta-Team eine Menge Aufwand hineingesteckt haben, um neue und aufregende Kisten zu finden, von denen ein Fingerabdruck gemacht werden konnte! Insbesondere 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 und Pluvius haben Tonnen von IP-Adressen verrueckter Kisten und/oder Fingerabdruecke von Systemen eingesendet, die nicht ueber das Internet erreichbar sind. Herzlichen Dank an Richard Stallman fuer das Schreiben von GNU Emacs. Dieser Artikel waere nicht so schoen umgebrochen, wenn ich vi oder cat und ^D haette verwenden muessen. Fragen und Kommentare koennen in Englisch an fyodor@insecure.org (falls das aus irgend einem Grund nicht klappen sollte, verwenden Sie bitte fyodor@insecure.org) gesendet werden. Nmap koennen sie hier bekommen: http://www.insecure.org/nmap