Das Erkennen von Betriebssystemen mittels TCP/IP Stack FingerPrinting
von Fyodor <[email protected]> (insecure.org)
Erstellt: 18. Oktober 1998
Zuletzt geaendert: 10. April 1999
[Franzoesische Uebersetzung von Arhuman <arhuman&at&francemel.com>]
[Portugisische Uebersetzung von Frank Ned <frank&at&absoluta.org>]
[Italienische Uebersetzung von Rige <rigel&at&penguinpowered.com>]
[Russische Uebersetzung von Alex Volkov <alex&at&nmap.ru>]
[Spanische Uebersetzung von Marco Barbosa <mabs&at&hotmail.com>]
[Deutsche Uebersetzung von Stefan Maly <stefan&at&maly.de>]
Dieses Papier darf frei weitergegeben werden. Die jeweils neueste
Ausfertigung sollte immer an folgender Stelle zu finden sein:
http://nmap.org/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 <no op> stattfindet. Solaris
zum Beispiel gibt die Reihenfolge 'NNTNWME' zurueck, was
ausgeschrieben bedeuetet:
<no op><no op><timestamp><no op><window scale><echoed MSS>
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:
<MSS (not echoed)><NOP><Window scale><NOP><NOP><Timestamp>
> 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://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 <Ihr Lieblings Mist-
Betriebssystem> Benutzer als die Penner, die sie sind zu entlarven :)!
Der in diesem Beispielen verwendete Kommandozeilenbefehl war:
nmap -sS -p 80 -O -v <host>
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
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 [email protected] (falls das
aus irgend einem Grund nicht klappen sollte, verwenden Sie bitte
[email protected]) gesendet werden. Nmap koennen sie hier bekommen:
http://insecure.org/nmap
