Home page logo
/
Intro Reference Guide Book Install Guide
Download Changelog Zenmap GUI Docs
Bug Reports OS Detection Propaganda Related Projects
In the Movies In the News

Sponsors


Remote OS detectie met TCP/IP Stack FingerPrinting


         Remote OS detectie met TCP/IP Stack FingerPrinting
           door Fyodor  (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:
    

    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):



> 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 
gebruikers te zeggen wat een sukkels het zijn :)!

Het commando dat gebruikt is in de voorbeelden: nmap -sS -p 80 -O -v 

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
fyodor@insecure.org. Nmap kan je downloaden van
http://insecure.org/nmap .



[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]