Remote OS detectie met TCP/IP Stack FingerPrinting
door Fyodor <[email protected]> (insecure.org)
18 oktober 1998
Laatste Wijziging: 11 juni 2002
Nederlandse vertaling door Michael Jonker <majonker&at&euronet.nl>
Dit artikel mag vrij gedistribueerd worden. De laatste versie is beschikbaar op
http://nmap.org/nmap-fingerprinting-article.html
INLEIDING
Dit artikel handelt over het verzamelen van waardevolle informatie over
een netwerk-computer door zijn IP-stack te bevragen.
Eerst schrijf ik iets over de "klassieke" methoden om het OS van een
computer te bepalen zonder gebruik te maken van stack-vingerafdrukken,
daarna beschrijf ik de huidige "state of the art" stack-vingerafdruk
tools. Daarop volgt een beschrijving van de vele manieren waarop een
computer informatie kan lekken over zichzelf.
Ten slotte beschrijf ik mijn (nmap) implementatie hiervan, gevolgd door een
kort overzicht van resultaten van nmap dat laat zien welk OS verschillende
populaire websites draaien.
REDENEN
Het achterhalen van het OS van een netwerk-computer kan een heel
waardelvolle verkennings-tool zijn omdat veel beveiligings-lekken
afhankelijk zijn van een bepaalde versie van het gebruikte OS.
Stel, je doet een penetratie-test en ontdekt dat poort 53 open is.
Als dit een kwetsbare versie van Bind is, dan heb je maar éÂén kans
om hier gebruik van te maken want een mislukte poging zal de service
waarschijnlijk laten crashen.
Met een goeie TCP/IP vingerafdruk zal je snel ontdekken dat deze
machine draait op "Solaris 2.51" of "Linux 2.0.35" en daar je
shell-script op kunnen aanpassen.
Een ergere mogelijkheid is iemand die vantevoren 500.000 computers
scanned om te zien welk OS er draait en welke poorten open staan.
Dan post iemand (bv.) een root-hole in Sun's comsat-service, en
onze kleine cracker kan zijn lijstje greppen op "UDP/512" en
"Solaris 2.6" en hij heeft gelijk pagina's vol met kwetsbare machines.
Overigens moet gezegd dat dit SCRIPT KIDDIE gedrag is. Je hebt geen
bekwaamheid laten zien en niemand is ook maar enigszins onder de indruk
van je vondst van een kwetsbare .edu die niet op tijd een patch had
uitgevoerd. Mensen zullen nog minder onder de indruk zijn als je
de verkregen toegang gebruikt om de website te bekladden met een
zelfverheerlijkende tekst over hoe goed je eigenlijk bent en hoe
dom de systeembeheerders.
Nog een manier is gebruik maken van de goed-gelovigheid van mensen
(social engineering). Je scant een bedrijf en Nmap meldt dat er een
"Datavoice TxPORT PRISM 3000 T1 CSU/DSU 6.22/2.06" in gebruik is.
De hacker zou nu dat bedrijf op kunnen bellen en zich voordoen als
een service-medewerker van Datavoice en zaken bespreken over de PRISM
3000. "We gaan een beveiligings-lek aankondigen maar eerst willen we
al onze klanten een patch laten installeren. Ik heb de patch net
naar jullie gemaild". Sommige naïeve systeembeheerders kunnen denken
dat alleen personeel van Datavoice zo veel kan weten over hun CSU/DSU.
Nog een mogelijke toepassing is het doorlichten van bedrijven waar
je misschien zaken mee wil gaan doen. Voordat je een provider kiest
scan je ze eerst om te kijken welke apparatuur ze gebruiken. Dan klinkt
een aanbieding van Â99 per jaar ineens heel anders als je hebt
uitgevonden dat ze slechte routers gebruiken en PPP services aanbieden
die draaien op een paar Windows-machines.
KLASSIEKE TECHNIEKEN
Stack-vingerafdrukken lost het probleem van OS identificatie op een
unieke manier op. Ik denk dat deze techniek veelbelovend is, al zijn
er op dit moment vele andere oplossingen. Helaas is dit nog steeds een
van de meest effectieve manieren van deze technieken:
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:
Het is zinloos om alle moeite te doen voor een vingerafdruk als een
machine dmv. een banner openlijk aan de wereld bekend maakt wat er op draait!
Helaas zijn er veel leveranciers die dit soort systemen leveren
en zijn er veel systeembeheerders die deze banners niet uitzetten.
Alleen omdat er andere manieren zijn om uit te vinden welk OS er draait
(zoals vingerafdrukken maken), betekent dat nog niet dat we zomaar
aan elke onverlaat die een connectie maakt bekend hoeven te maken
welk OS we draaien en op welke architectuur.
Het probleem van vertrouwen op deze techniek is dat steeds meer mensen
de banners uitzetten, dat veel systemen heel weinig informatie geven en
het is heel eenvoudig om in de banner te "liegen".
Zelfs als je de banners uitzet zullen veel applicaties je graag dit soort
informatie geven als je er maar om vraagt. Laten we bv. een kijken naar
een FTP server:
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
Ten eerste geeft dit ons systeem-details in de standaard banner.
Dan geven we het "SYST" commando en we krijgen zelfs nog meer informatie.
Als anonieme FTP wordt toegestaan kunnen we vaak /bin/ls
of andere binaire bestanden downloaden en bepalen voor welke
architectuur het gecompileerd is.
Veel andere applicaties zijn ook vrijgevig met informatie. Neem bv een
webserver:
playground> echo 'GET / HTTP/1.0\n' | nc hotbot.com 80 | egrep '^Server:'
Server: Microsoft-IIS/4.0
playground>
Hmmm ... ik ben heel benieuwd wat hier voor OS zou draaien.
Andere klassieke technieken zijn het opvragen van DNS host info records
(zelden effectief) en goed-gelovigheid (social engineering). Als een
machine luistert op poort 161/UDP (snmp) dan krijg je bijna gegarandeerd
een hoop gedetailleerde informatie door "snmpwalk" te gebruiken uit de
CMU SNMP tools distributie en "public" als de community naam.
HUIDIGE VINGERAFDRUK PROGRAMMA'S
Nmap is niet het eerste OS herkenningsprogramma dat gebruik maakt
van TCP/IP vingerafdrukken.
De IRC spoofer sirc van Johan bevat de beginselen van vingerafdruk-
technieken sinds versie 3 (of eerder). Het probeert een computer in de
klassen "Linux", "4.4BSD", "Win95" of "Unknown" te plaatsen dmv. een
paar simpele TCP flag tests.
Nog zo'n programma is checkos, publiekelijk uitgebracht in januari van
dit jaar door Shok in Confidence Remains High #7. De gebruikte techniek
is hetzelfde als in sirc en zelfs de code is op een aantal plaatsen
identiek. Checkos was al lange tijd privaat beschikbaar voor het publiek
werd uitgebracht en ik heb geen idee wie de code van wie heeft. Maar ze
geven elkaar in elk geval geen credit voor de code. Iets wat checkos
extra heeft, is het controleren van de telnet-banner. Dat is handig maar
met de eerder genoemde problemen. [ Update: Shok liet me weten dat checkos
nooit bedoeld was om publiek uit te brengen en dat hij daarom nooit de
moeite heeft genomen credits op te nemen voor de code uit sirc.]
Su1d heeft ook een OS-identificatie programma geschreven. Het heet SS
en vanaf versie 3.11 kan het 12 verschillende OS typen herkennen. Ik heb
hier min of meer deel aan omdat hij credits heeft opgenomen voor
stukken uit de netwerk-code van mijn Nmap-programma :).
Dan is er ook nog queso. Dit programma is het nieuwste en is een grote
sprong voorwaarts tov. de andere programma's. Niet alleen introduceert
het een aantal nieuwe tests maar was het ook de eerste die de vingerafdrukken
uit de code haalde. In de andere programma's staat code zoals:
/* from ss */
if ((flagsfour & TH_RST) && (flagsfour & TH_ACK) && (winfour == 0) &&
(flagsthree & TH_ACK))
reportos(argv[2],argv[3],"Livingston Portmaster ComOS");
In plaats daarvan verplaatst queso dit naar een configuratie bestand
wat uiteraard veel beter schaalbaar is en het maakt het toevoegen van
een OS zo simpel als het toevoegen van een paar regels aan een
vingerafdruk-bestand.
Queso is geschreven door Savage, een van de mensen van Apostols.org.
Het probleem met alle bovengenoemde programma's is dat ze allemaal beperkt
zijn in het aantal vingerafdruk-tests en dat beperkt de fijnmazigheid van
de antwoorden. Ik wil juist meer weten dan alleen "deze machine draait
OpenBSD, FreeBSD, of NetBSD", ik wil precies weten welke van de drie het is
en ook nog een idee krijgen om welke versie het gaat. Op dezelfde manier
zie ik liever "Solaris 2.6" dan alleen "Solaris". Om deze fijnmazigheid te
bereiken ben ik gaan werken aan een aantal vingerafdruk-technieken die ik
hieronder beschrijf.
VINGERAFDRUK METHODEN
Er zijn heel veel manieren die gebruikt kunnen worden om een
vingerafdruk van een netwerk-stack te maken. In principe ga je kijken
naar de dingen die per operating systeem verschillend zijn en die
verschillen leg je vast. Als je genoeg van die verschillen combineert
dan kan je het aantal mogelijke operating systemen behoorlijk minimaliseren.
Bv. Nmap kan een betrouwbaar onderscheid maken tussen Solaris 2.4,
Solaris 2.5-2.51 en Solaris 2.6. Nmap ziet ook het verschil tussen
Linux kernel 2.0.30, 2.0.31-34 of 2.0.35. Hier zijn een aantal technieken:
De FIN test -- Hier zenden we een FIN-pakketje (of welk ander pakketje
dan ook zonder de ACK of SYN vlag) naar een open poort en wachten op
een antwoord. De correcte manier is om NIET te antwoorden, maar veel
slechte implementaties zoals MS Windows, BDSI, CISCO, HP/UX, VMS en
IRIX zenden een RESET terug. De meeste tools gebruiken deze techniek.
De BOGUS vlag test -- Queso is het eerste programma wat ik zag die deze
slimme test gebruikt. Het idee is om een ongedefinieerde TCP vlag
(bit 7 of 8, tellend van links) te zetten in de header van een
SYN-pakketje. Linux machines voor versie 2.0.35 zetten deze vlag
ook in hun antwoord. Ik ken geen ander OS met deze bug. Hoe dan ook,
sommige operating systemen lijken de connectie te verbreken als ze
een SYN+BOGUS pakketje ontvangen. Dit gedrag kan bruikbaar zijn voor
identificatie. Update: bit 8 (en 9) worden nu gebruikt als het ECN-veld
voor TCP-congestie-regeling.
TCP ISN sampling -- Het idee hier is om patronen te vinden in de eerste
sequence-nummers die gekozen worden door TCP implementaties als er
een connectie-verzoek ontvangen wordt. Ze kunnen in veel groepen
ingedeeld worden zoals de traditionele 64K (veel oude UNIX
machines), willekeurige verhogingen (nieuwere versies van Solaris,
IRIX, FreeBSD, Digital UNIX, Cray en vele anderen), volledig
willekeurig (Linux 2.0.x, OpenVMS, nieuwere AIX, etc). Windows
machines (en enkele anderen) gebruiken een tijd-afhankelijk model
waar de ISN elke tijds-periode met een kleine, vaste hoeveelheid wordt
verhoogt. Het behoeft geen uitleg dat dit net zo makkelijk te herkennen
is als de oude 64k methode. Uiteraard is mijn favoriete methode de
"constante". Deze machines gebruiken ALTIJD exact hetzelfde ISN :).
Ik ben dit tegengekomen op sommige 3Com hubs (gebruikt 0x803) en
Apple LaserWriter printers (gebruikt 0xC7001).
Je kunt ook sub-klassen maken van groepen zoals willekeurige
verhoging door variaties te berekenen, grootste gemene delers of
andere functies uitvoeren op de verzameling sequence-getallen en
de verschillen tussen de sequence-getallen. Het moet gezegd dat
het genereren van sequence-getallen belangrijke implicaties heeft
voor beveiliging. Nmap is het eerste programma dat ik ken dat van
deze techniek gebruik maakt voor OS-identificatie.
IPID sampling -- De meeste operating systemen verhogen een centrale
IPID waarde voor elk pakket dat ze verzenden. Anderen, zoals
OpenBSD, gebruiken een willekeurig IPID en sommige systemen
(zoals Linux) gebruiken een IPID van 0 in veel gevallen waar
de "don't fragement"-vlag niet gezet is. Windows zet de IPID
niet in netwerk-volgorde dus het verhoogd met 256 voor elk pakket.
Nmap heeft ook categoriën voor constante, willekeurige positieve
integraal en onbekende sequence klassen. Voorspelbare IPID-klassen
hebben belangrijke consequenties die verder gaan dan OS-detectie.
De Nmap "Idlescan" (-sI) optie is een voorbeeld.
TCP Timestamp -- Een ander getal dat gebruikt kan worden voor OS-detectie
is de TCP timestamp waarde. Sommige systemen ondersteunen deze optie
niet, anderen verhogen deze waarde met frequenties van 2Hz, 100Hz of
1000Hz en weer anderen geven 0 terug. Nmap gebruikt deze informatie
ook om de uptime van het systeem te bepalen.
Don't Fragment bit -- Veel operating systemen zetten tegenwoordig het
"Don't Fragment bit in sommige pakketjes die ze verzenden. Dit
geeft verschillende prestatie voordelen (maar het kan ook behoorlijk
irritant zijn -- daarom werken Nmap fragmentation scans niet op
Solaris machines). In elk geval, niet alle OS'en doen dit en sommigen
doen het in verschillende gevallen, dus op dit bit letten geeft ons
weer meer informatie over het bewuste OS. Ook deze techniek ben ik nog
niet eerder tegengekomen.
TCP Initial Window -- Dit is eenvoudigweg het controleren van de window size
op de terugkomende pakketjes. Oudere scanners gebruiken simpelweg een
window-size die niet nul is om "BSD 4.4 afgeleide" aan te geven. Nieuwere
scanners zoals queso en Nmap houden de exacte window-size bij omdat het
vrij constant per OS is. Deze test geeft eigenlijk heel veel informatie
over het gebruikte OS omdat sommige OS'en 100% herkend kunnen worden aan
hun window-size (bv. AIX is het enige OS dat ik ken die een window-size
van 0x3F35 gebruikt). In de "compleet herschreven" TCP stack van NT5
gebruikt Microsoft 0x402E. Stom toevallig is dat precies de waarde
die gebruikt wordt door OpenBSD en FreeBSD.
ACK Value -- Je zou denken dat deze sequence-waarde standaard zou zijn maar
implementaties verschillen in de waarde die ze gebruiken voor het
ACK-veld in sommige gevallen. Je stuurt bv. een FIN|PSH|URG naar
een gesloten poort. De meeste implementaties zullen ACK zenden met
het initiële sequence getal, maar Windows en sommige stomme printers
zenden je seq + 1 terug. Als je SYN|FIN|URG|PSH naar een open
poort stuurt, is Windows zeer inconsequent. Soms zendt het je initiële
seq-getal terug, een andere keer zendt het s++ en weer andere keren
zendt het een ogenschijnlijk willekeurig nummer terug. Iemand moet
zich toch afvragen wat voor soort code MS schrijft dat het zo vaak
van gedachten veranderd.
ICMP Error Message begrenzing -- Sommige (slimme) operating systemen
volgen de suggestie van RFC 1812 om de hoeveelheid foutmeldingen
die verzonden wordt te begrenzen. Bv. de Linux-kernel (in
net/ipv4/icmp.h) begrenst het zenden van "destination unreachable"
tot 80x per 4 seconden met een 1/4 seconde penalty als die grens
overschreden wordt. Een van de manieren om dit te testen is om een
aantal pakketjes naar een hoge UDP-poort te sturen en het aantal
"unreachable"-pakketjes te tellen. Ik heb dit nog niet gezien dat
dit gebruikt werd en heb het ook nog niet toegevoegd aan Nmap (behalve
voor UDP-poort scannen). Deze test maakt het detecteren van het
OS wel langzamer omdat je eerst een aantal pakketjes moet versturen
en moet wachten op antwoord. Het wordt nog vervelender als er
pakketjes onderweg gedropt worden.
ICMP Message Quoting -- De RFC's specificeren dat ICMP foutmeldingen een
stukje moeten quoten van het ICMP-pakket dat de fout veroorzaakt.
Voor een "destination unreachable" sturen bijna alle implementaties
de verplichte IP header + 8 bytes terug. Echter Solaris zend net
iets meer terug en Linux zend nog meer terug. Het mooie hiervan is
dat het Nmap in staat stelt om Linux en Solaris te herkennen,
zelfs als er geen enkele poort open staat.
ICMP Error message echo integriteit -- Ik kreeg dit idee van iets wat
Theo de Raedt (hoofd OpenBSD ontwikkelaar) schreef in comp.security.unix.
Zoals gezegd moeten machines een deel van het orginele bericht
terugsturen met een unreachable foutmelding. Maar sommige machines
hebben de neiging om jouw headers te gebruiken als kladpapier
tijdens de eerste verwerking en dus zijn ze een beetje vervormd
tegen de tijd dat je ze terug krijgt. AIX en BSDI bv. zenden een
IP "totale lengte"-veld terug dat 20 bytes te lang is. Sommige
BSDI, FreeBSD, OpenBSD, ULTRIX and VAX'en vernaggelen het IPID
dat je ze gestuurd hebt. Ondanks dat de checksum toch al veranderd
door de veranderde TTL zijn er machines die een inconsistente of
0-checksum terugsturen. Hetzelfde geldt voor de UDP checksum.
Al met al, Nmap voert negen verschillende tests uit op ICMP
foutmeldingen om dit soort subtiele verschillen uit te vissen.
Type of Service -- Voor ICMP "port unreachable" berichten kijk ik naar
de Type of Service waarde (TOS) van het teruggestuurde pakket. Bijna
alle implementaties gebruiken 0 voor deze ICMP foutmelding, al
gebruikt Linux 0xC0. Dit is niet een van de standaard TOS waarden
maar maakt deel uit van het ongebruikte (voor zover ik weet)
"precedence"-veld. Ik weet niet waarom dit zo is maar als ze het
veranderen in 0 kunnen we de oude versies blijven identificeren
en kunnen we ook het onderscheid maken tussen oud en nieuw.
Fragmentation Handling -- Dit is de favoriete techniek van Thomas
H Ptacek van Secure Networks Inc. (nu eigendom van een stel
Windows gebruikers bij NAI). Dit maakt gebruik van het feit dat
verschillende implementaties vaak verschillend omgaan met
overlappende IP-fragmenten. Sommigen overschrijven de oude
fragmenten met de nieuwe en in andere gevallen worden de oude
fragmenten gehandhaafd. Er zijn veel verschillende manieren
om te testen hoe de pakketjes opnieuw samengesteld worden.
Ik heb dit niet geïmplementeerd omdat ik geen manier weet
om met portable code IP-fragmenten te sturen (vooral op Solaris
is het lastig). Voor meer informatie over overlappende
fragmenten kan je het IDS-artikel lezen op www.secnet.com.
TCP Options -- Dit is een echte goudmijn voor wat betreft informatie
lekken. Het mooie van deze opties is dat:
1) ze meestal optioneel zijn (duh!) :) dus dat niet elk computer
het implementeerd.
2) je weet of een computer het implementeerd door een pakketje
te sturen waarin je een optie meegeeft. Het doel-systeem geeft
meestal aan dat het ondersteund wordt door de optie ook in het
antwoord aan te zetten.
3) je een heleboel opties tegelijk aan kan zetten in een pakketje
om alles in een keer te testen.
Nmap zendt deze opties met bijna alle test-pakketjes mee:
Window Scale=10; NOP; Max Segment Size = 265; Timestamp; End of Ops;
Als je een antwoord krijgt, kijk je welke opties mee terug gestuurd
zijn en welke dus ondersteund worden. Sommige operating systemen
zoals recente FreeBSD versies ondersteunen alle bovenstaande opties
terwijl anderen zoals Linux 2.0.x er maar weinig ondersteunen. De
laatste Linux 2.1.x kernels ondersteunen bovenstaande opties wel.
Aan de andere kant zijn die weer wel kwetsbaarder voor wat betreft
het voorspellen van TCP sequence nummers. Zoek het maar uit.
Zelfs als meerdere operating systemen dezelfde set opties ondersteunen
kan je ze soms onderscheiden door de waarden van de opties. Als je bv.
een kleine MSS waarde naar een Linux-machine stuurt, zal het die MSS
waarde naar je terug sturen. Andere machines geven je een andere waarde.
En zelfs als je dezelfde set ondersteunde opties EN dezelfde waarden
terug krijgt, dan nog kan je onderscheid maken door de volgorde waarin
ze gegeven worden en waar opvulling is toegepast. Solaris bv stuurt
"NNTNWME", wat neer komt op:
<no op><no op><timestamp><no op><window scale><echoed MSS>
Terwijl Linux 2.1.122 MENNTNW terug geeft. Dezelfde opties, dezelfde
waarden, maar een andere volgorde!
Ik heb nog geen andere OS-detectie tools gezien die gebruik maken
van TCP options, maar het is erg bruikbaar.
Er zijn nog een paar andere bruikbare opties waar ik op zou kunnen
testen, zoals T/TCP en selectieve ACK's.
Exploit Chronologie -- Zelfs met alle bovenstaande tests is het met Nmap
niet mogelijk om onderscheid te maken tussen Win95, WinNT en Win98.
Dat is nogal verrassend, vooral omdat Win98 zo'n 4 jaar later werd
uitgebracht dan Win95. Je zou denken dat ze de moeite hadden genomen
om de stack op de een of andere manier te verbeteren (zoals het
ondersteunen van TCP opties) en dat we in staat zouden zijn om
die verandering te detecteren en zo het onderscheid kunnen maken
tussen deze operating systemen. Helaas is dit niet het geval.
De NT stack is blijkbaar dezelfde troep die ze in Win95 hebben
gestopt. En ze vonden upgraden voor 98 ook niet nodig.
Maar geef de hoop niet op, want er is een oplossing. Je kunt
eenvoudigweg beginnen met vroege Windows DOS aanvallen (Ping of
Death, Winnuke, etc) en zo telkens een iets nieuwere, naar aanvallen
zoals Teardrop en Land. Na elke aanval ping je ze om te kijken of
de machine gecrashed is. Als je ze uiteindelijk crashed heb je
het terug gebracht tot wat ze draaien en met welk service pack
of hotfix.
Ik heb deze functionaliteit niet aan nmap toegevoegd al moet ik
toegeven dat het erg verleidelijk is :).
SYN Flood Resistance -- Sommige operating systemen accepteren geen nieuwe
connecties meer als je ze te veel vervalste SYN pakketjes stuurt
(het vervalsen van de pakketjes voorkomt dat je kernel de connecties
gaat resetten). Veel OS'en kunnen niet meer dan 8 pakketjes aan.
Recente Linux kernels (en andere OS'en) hebben verschillende methoden
zoals SYN cookies om te voorkomen dat dit een groot probleem wordt.
Je kunt dus iets te weten komen over je doel-OS door 8 pakketjes van
een vervalste bron naar een open poort te sturen en dan zelf proberen
een connectie te maken naar die poort. Dit is niet geïmplementeerd in
Nmap omdat sommige mensen kwaad worden als je ze een SYN flood stuurt.
Zelfs uitleggen dat je alleen maar probeerde te achterhalen welk OS ze
draaien kan ze soms niet kalmeren.
NMAP IMPLEMENTATIE EN RESULATEN
Ik heb een referentie implementatie gemaakt van de OS detectie technieken
die hierboven beschreven zijn (zonder de genoemde uitzonderingen). Ik heb ze
toegevoegd aan mijn Nmap scanner met als voordeel dat die al weet
welke poorten open en dicht zijn voor een vingerafdruk dus dat hoef
ik niet opnieuw duidelijk te maken. De implementatie is portable tussen
Linux, *BSD, Solaris 2.51 en 2.6 en een aantal andere operating systemen.
De nieuwe versie van Nmap leest een bestand met vingerafdruk-gegevens volgens
een simpele syntaxis. Hier is een voorbeeld:
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)
Laten we kijken naar de eerste regel (ik voeg ">" quote markering toe):
> FingerPrint IRIX 6.2 - 6.3 # Thanks to Lamont Granquist
Dit zegt eenvoudigweg dat deze vingerafdruk de IRIX versies 6.2 - 6.3
beslaat en het commentaar geeft aan dat Lamont Granquist zo vriendelijk
was om me de IP-adressen of vingerafdrukken van de geteste IRIX-machines
te sturen.
> TSeq(Class=i800)
Dit betekent ISN sampling de machine in de klasse "i800" stopte. Dat houdt
in dat elk nieuw sequence nummer een veelvoud van 800 groter is dan
het vorige nummer.
> T1(DF=N%W=C000|EF2A%ACK=S++%Flags=AS%Ops=MNWNNT)
Deze test heet T1 (als in test1, slim he?). In deze test zenden we een
SYN pakket met een stel TCP opties naar een open poort. DF=N betekent
dat het "Don't fragment"-bit van het antwoord niet gezet moet zijn.
W=C000|EF2A betekent dat het Window dat we ontvangen 0xC000 of 0xEF2A
moet zijn. ACK=S++ betekent dat het ontvangen ACK ons initiële
sequence-nummer + 1 heeft. Flags = AS betekent dat ACK en SYN verzonden
werden in het antwoord. Ops = MNWNNT betekent dat de TCP opties in het
antwoord als volgt moeten zijn (in deze volgorde):
<MSS (not echoed)><NOP><Window scale><NOP><NOP><Timestamp>
> T2(Resp=Y%DF=N%W=0%ACK=S%Flags=AR%Ops=)
Test 2 heeft betrekking op een NULL met dezelfde opties naar een open
poort. Resp=Y betekent dat er een antwoord moet komen. Ops= betekent
dat er geen opties gezet mogen zijn in het antwoordpakketje. Als we
"%Ops=" in zijn geheel hadden weggelaten dan zou elke optie een match
opleveren.
> T3(Resp=Y%DF=N%W=400%ACK=S++%Flags=AS%Ops=M)
Test 3 is een SYN|FIN|URG|PSH met opties naar een open poort
> T4(DF=N%W=0%ACK=O%Flags=R%Ops=)
Dit is een ACK naar een open poort. Merk op dat we hier geen Resp= hebben
Dat betekent dat een match niet gediskwalificeerd zal worden als er geen
antwoord komt (gedropt in het netwerk of door een kwaadaardige vuurmuur)
terwijl de andere tests een match opleveren. We doen dit omdat in essentie
elk OS een antwoord stuurt dus het ontbreken van een antwoord heeft in het
algemeen te maken met netwerk-condities en niet met het OS zelf.
We zetten de Resp tag in test 2 en 3 omdat sommige operating systemen
deze pakketjes wel droppen zonder een antwoord.
> 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=)
Deze tests zijn een SYN, een ACK en een FIN|PSH|URG respectievelijk
naar een gesloten poort. Telkens met dezelfde opties. Maar dat is
overduidelijk met deze heldere namen "T5", "T6" en "T7" :).
> PU(DF=N%TOS=0%IPLEN=38%RIPTL=148%RID=E%RIPCK=E%UCK=E%ULEN=134%DAT=E)
Deze draak van een regel is de "port unreachable" foutmelding test.
Je zou de DF=N nu wel moeten herkennen. TOS=0 betekent dat het
"IP Type Of Service"-veld 0 was. De volgende twee velden geven de
hex-waarden van het "IP total length"-veld en de "total lenght" die
terug ontvangen werd. RID=E betekent dat de RID-waarde was zoals
verwacht (Expected) dus gelijk was aan de waarde die wij verstuurden.
RIPCK=E betekent dat ze de checksum niet verklooid hebben (anders zou
er RIPCK=F hebben gestaan). UCK=E betekent dat de UDP checksum ook
goed was. Daarna volgt de UPD lengte en die was 0x134. DAT=E betekent
dat ons UDP pakket correct werd terug gestuurd. Omdat de meeste
implementaties geen UDP data terug sturen krijgt dit standaard DAT=E.
De versie van Nmap met deze functionaliteit is nu beschikbaar op
http://nmap.org/.
POPULAIRE SITES SNAPSHOTS
En hier is het plezierige resultaat van al ons werk. We kunnen nu
willekeurige websites nemen en bepalen welk OS ze gebruiken. Veel van
deze mensen hebben de telnet banners etc. verwijderd om deze informatie
geheim te houden. Maar dat heeft geen zin met onze nieuwe vingerafdrukken-
tool. Het is ook een geweldige manier om de <hier jouw favoriete pruts-OS>
gebruikers te zeggen wat een sukkels het zijn :)!
Het commando dat gebruikt is in de voorbeelden: nmap -sS -p 80 -O -v <host>
De meeste van deze scans zijn gedaan op 18-10-1998 dus sommige van
deze sites kunnen sinds die tijd veranderd zijn.
Oh ja, ik ben niet van elke site hier een fan.
# "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 :) (its because UAlberta
# is hosting them)
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
Opmerkingen: In hun security-whitepaper zegt Microsoft over hun lakse
beveiliging: "deze aanname is met de jaren veranderd sinds Windows NT
aan populariteit wint, grotendeels vanwege de beveiligingsmogelijkheden".
Hmmm, als ik het zo bekijk is Windows niet erg populair bij de
Beveiligings-community :). Ik zie maar twee Windows machines in de hele
lijst en Windows is makkelijk te herkennen omdat het zo vreselijk
brak is (vanuit standaarden gezien dan).
En natuurlijk is er nog een site die we moeten checken. Dat is de website
van de ultra-geheime Transmeta corporation. Opmerkelijk is dat het bedrijf
voor het grootste gedeelte wordt gefinancieerd door Paul Allen van Microsoft,
maar het heeft Linus Torvalds in dienst. Blijven ze trouw aan Paul en
gebruiken NT of kiezen ze de kant van de rebellen en doen ze mee aan de
Linux revolutie? 's Even kijken:
We gebruiken het volgende commando:
nmap -sS -F -o transmeta.log -v -O www.transmeta.com//24
Dit betekent een SYN-scan voor bekende poorten (uit /etc/services),
log de resultaten naar transmeta.log, geef een uitgebreide log,
bepaal het OS en scan het klasse C netwerk waar www.transmeta.com
zich op bevindt. Hier is de strekking van de 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 )
Nou, ik denk dat dat onze vraag wel heel duidelijk beantwoord :).
MET DANK AAN
De enige reden dan Nmap op dit moment zoveel verschillende operating
systemen kan herkennen is dat een hoop mensen van het besloten
beta-team een hoop moeite hebben gestoken in het nemen van
vingerafdrukken van veel interessante machines.
In het bijzonder 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, en Pluvius
hebben ladingen IP-adressen en/of vingerafdrukken gestuurd van
machines die al dan niet vanaf het internet bereikbaar waren.
Vragen en opmerkingen kan je (in het engels) sturen naar
[email protected]. Nmap kan je downloaden van
http://insecure.org/nmap .
