Analys

När data är insamlade är det dags för dig att sätta dig ner och tänka igenom vad som hänt, varför det hänt och hur du kan hindra att det händer igen. I den bästa av världar skulle du kunna göra detta i lugn och ro, och ha tillgång till all den information som gick att få. I verkligheten är det ofta mera komplicerat:

• Det kan vara nödvändigt att börja analysera det inträffade tidigt, innan du samlat på dig alla data du egentligen vill ha, till exempel för att du måste bestämma om det inträffade är ett intrång eller inte, eller för att avgöra om fler system kan vara drabbade.

• Du kan under analysen upptäcka att du saknar data som du borde ha tillgång till. Då får du skaffa fram detta, ifall det inte är redan förstört, och försöka komma ihåg samma sak från början nästa gång.

• Under analysen kan du inse att flera system är drabbade, och tvingas börja utreda dessa också.

Det gäller att känna till de aktuella systemen när du jobbar med analysen. Om du inte är bekant med operativsystemet, tillämpningarna och så vidare, så är det ju inte lätt att veta vad som är normalt och vad som är tecken på intrång. Ett sätt att klara detta är att jobba i par: en person som har erfarenhet av analysarbetet som sådant och en person med mera ingående kunskaper om systemen.

Vid analys av enklare händelser kan det räcka med att titta på de data du samlat in. Med hjälp av intuition och erfarenhet från tidigare händelser inser du någorlunda direkt vad som hänt. När det är frågan om mera komplicerade händelser behöver du jobba mera systematiskt, till exempel genom att göra en tidslinje. Tidslinje

Att göra en tidslinje över incidenten är ett bra sätt att börja nysta i det data du har tillgängligt. Du tvingar din hjärna att fundera över det inträffade utan att bli överväldigad av allt på en gång, och dokumenterar samtidigt det inträffade på att sätt som du kan använda senare.

En av de främsta poängerna är att du sammanställer data från olika källor. Om incidenten berör flera system så sammanställer du också data från de olika systemen på ett och samma ställe, och kan se mönster som inte synts tidigare.

Exampel på källor som kan sammanställas till en tidslinje:

• Filåtkomsttider från MAC-time-analys (se nedan)

• Loggar för drabbade system (helst från en fristående logg-server som inte har påverkats av incidenten).

• Inloggningsinformation ("last -a" på Unix-system)

• Loggar från andra system som de drabbade haft kontakt med (till exempel loggar från epost-server som visar när epost skickats)

• Historiefiler från kommandoskal (som dock sällan har tiddstämplar för varje kommando)

• Information om nätverkstrafik om sådan finns, till exempel från brandväggar, IDS-system, flow-statistik, argus

• Manuella observationer (till exempel när någon upptäckte att en dator betett sig underligt)

• Mera exotisk information (till exempel information från DNS-uppslagsserver som visar när en viss adress först slogs upp, diverse applikationsspecifika möjligheter, med mera)

Tidslinjen behöver inte vara krångligare än en fil (exempelvis ett kalkylark eller TAB-separerad textfil) med datum och tid i början (så att du enkelt kan sortera på detta) och sedan information om vad som hänt vid den aktuella tidpunkten. Då flera system är drabbade kan det vara smidigt att ha ett särskilt fält som talar om vilket system som raden gäller.

I enklare fall kan du sammanställa tidslinjen manuellt, men när det blir mera komplicerat underlättar det att ta hjälp av datorn för att sammanställa de olika källorna och sortera ihop dem. Du kan behöva små program för att till exempel omvandla loggfiler från syslog-format till det format du valt för tidslinjen.

Oavsett hur sammanställningen sker behöver du försöka göra ett urval, så att du filtrerar bort information som inte har med intrånget att göra, så att den relevanta informationen inte drunknar bland skräp. Du får kanske börja med att ta med all slags information från loggarna, och sedan successivt ta bort sådan information som du är någorlunda säker på inte har med intrånget att göra.

När information från flera källor sammanställs till en tidslinje är det givetvis viktigt att tiderna inte blir fel så att tidslinjen ger fel uppfattning om vilken ordning olika händelser inträffade. Här finns två olika anledningar till problem:

• Klockorna på de drabbade systemen gick fel jämfört med varandra och/eller normaltid. Detta ger ofta små fel på några sekunder eller minuter, men det kan ju räcka för att tidslinjen ska bli fel.

• Tiderna blev fel vid själva datainsamlingen (till exempel för att datorn startades med en boot-CD som utgick från att amerikansk tidszon gällde).

För att kunna rätta till eventuella fel behöver du information om hur fel eller rätt tiderna är. Denna information kan antingen komma från datainsamlingsfasen då du tog reda på det, eller genom att du lyckas jämföra två händelser som du vet inträffat samtidigt och som syns i flera källor.

Om du vet att tiderna för en viss datakälla är fel så kan du ta hjälp av ett litet program för att korrigera tidsstämplarna till normaltid innan den källan sorteras in i tidslinjen.

Ett näraliggande problem är att olika datakällor kan ha olika upplösning på tidsinformationen. MAC-time-datat och vissa loggar kan ha sekundupplösning, medan andra loggar bara har minutupplösning. När du sorterar ihop detta till en tidslinje måste du på något sätt hantera detta, så du inte lurar dig (eller andra) att tro att något som hände mellan 14:05:00 och 14:05:59 hände exakt 14:05:00.

Historiefiler från kommandoskal (.bash_history med flera) som inte raderats kan ofta ge värdefull information om vad som hänt. Tyvärr är det vanligt att tidsstämplar saknas per kommando, vilket gör det svårt att sortera ihop informationen här med resten av tidslinjen. Har du tur kan du knyta ihop kommandona här med andra händelser som du har tider på, till exempel genom att du ser ett kommando som påverkar en fil på ett sätt som du kan se i MAC-time-datat, eller genom att du ser ett kommando som resulterar i loggar på andra system eller nättrafik som du har tidsinformation om. Diagram

Som ett komplement till tidslinjen kan det vara nyttigt att rita ett diagram över de inblandade systemen (både de du utreder och de externa datorer som är inblandade). Olika slags pilar mellan datorerna får symbolisera olika händelser (portskanningar, inloggningar, filsystemsmonteringar, med mera).

Var noga med att inte missa de andra system som ser ut att vara inblandade. Attacker mot system och inloggningar från knäckta system kommer ju ofta från system som i sin tur är utsatta för intrång. Om det är interna kan du behöva undersöka dessa också. Om de är externa så behöver du varna systemadministratörerna för dessa system (om du inte misstänker att de är inkräktarnas egna maskiner).

Du får räkna med att diagrammet blir ganska kladdigt och krångligt efter ett tag, men det gör ofta inte så mycket: det är inte slutresultatet som är det viktiga, utan stödet du får medan du arbetar med analysen. Skulle ett snyggt diagram behövas på slutet får du rita om det. MAC-time-analys

En av informationskällorna som nämns ovan är MAC-time-analys. Den bygger på att varje fil på systemet har ett antal tidsstämplar. På ett typiskt Unix-system (där tekniken utvecklades) finns tre olika:

• Modify (M): Sätts när filens innehåll modifieras. Visas av "ls -l".

• Access (A): Sätts när filens innehåll läses. Visas av "ls -lu".

• Status Change (C): Sätts när status-informationen i filens så kallade i-nod modifieras. Detta kan ske utan att innehållet påverkas, t.ex. då rättigheterna ändras på filen. Visas av "ls -lc".

På Windows (NTFS) finns också M, A och C-tider, men C betyder här "creation".

Idén bakom analysen är att samla på sig MAC-tiderna för alla filer. För varje fil skapas sedan tre rader, en för varje typ av tidsstämpel. Sedan sorterar man raderna efter tiderna, och presenterar resultatet.

Första gången du gör en MAC-time-analys blir du förhoppningsvis positivt överraskad av hur mycket information detta ger. Tack vare sorteringen på tidpunkt kan du se samband som annars inte hade framgått. Exempel:

• Inkräktare brukar försöka gömma filer på konstiga ställen och i bibliotek med konstiga namn (ofta inkluderande punkter i början och mellanslag på slutet). Om filer och kataloger skapas vid en tidpunkt du vet att incidenten pågick så syns dessa tydligt i MAC-time-analysen under denna period.

• Kompilering av C-program syns ofta genom att access-tiden på olika include-filer uppdateras när det sker. Tack vare att olika program behöver olika uppsättningar include-filer så kan du ofta se flera kompileringar, inte bara den senaste.

Det finns dock ett antal brister att ta hänsyn till:

• Det är alltid bara senaste ändringen/åtkomsten du ser. Om programmet "hax0rdasyst3mz" körts sjutton gånger så ser du inte de sexton första körningarna genom att bara titta på access-tiden på programfilen.

• Inkräktarna kan ändra tidsstämplarna om de vill. Detta är till exempel vanligt då rootkit byter ut systemprogram som "ls" och "ps" mot egna versioner. Tidsstämplarna på de nya programmen ändras för att stämma med de som fanns på de tidigare. Ofta kan du i sådana fall ändå se att något är galet ifall inkräktarna glömt att ändra modifieringstiden för biblioteket filerna ligger i.

• Inkräktare brukar ibland packa ihop och ta med sig filer från andra system (till exempel källkod, färdiga program, konfigureringsfiler men även loggar och "skräpfiler" som bara råkade ligga där vid hoppackningen) och packa upp på det nyknäckta. Om arkivprogrammet bevarar tidsstämplar så behåller de nyskapade filerna dessa från det tidigare systemet.

• Periodiska jobb på systemet (till exempel sådana som körs varje natt) kan ändra tidsstämplarna efter att inkräktarna gjort det.

• Du eller kollegor kan själva ha ändrat tidsstämplarna under datainsamlingen, till exempel innan ni insett att det handlade om ett intrång. När själva MAC-tidsdatat samlas in gäller det att göra detta så tidigt som möjligt och i en ordning som gör att man inte förstör datat innan man läst det.

• Det händer att uppdatering av access-tiden stängs av på filsystem med mycket läsningar (för att slippa skriva information till disken när saker bara läses). Detta kan vara nödvändigt, men du ska vara medveten om att detta gör att mycket information går förlorad inför en MAC-time-analys.

The Coroners Toolkit (TCT) populariserade denna teknik. Numera används ofta efterföljaren The Sleuth Kit (TSK). MAC-time-analys på deras sätt delas ofta upp i två delar:

• Insamling av MAC-time-information till en "body"-fil. Detta kan göras med "grave-robber" från TCT (som också samlar in en massa annan information) eller "mac-robber" från samma ställe som TSK (samlar bara in MAC-time-data). Programmen "fls" och "ils" i TSK kan också användas.

• Sortering och presentation baserat på "body"-filen. Detta görs med "mactime" från TSK eller TCT. För att namn på användare och grupper ska presenteras korrekt behövs group- och passwd-filerna också.

Inblandade filer

En viktig del av en analys är att hitta och undersöka de filer som har med incidenten att göra. Dessa filer kan vara av olika slag, exempelvis:

• Utbytta program: Inkräktare byter ofta ut programfiler av en rad olika skäl. Det kan handla om root-kit som döljer intrång genom att modifierade "ls", "ps", "netstat" osv inte visar vissa filer, processer och nätuppkopplingar. Det kan också handla om bakdörrar i serverprogram som släpper in inkräktaren, om trojaner som samlar lösenord när användaren kör programmet för att logga in någon annanstans, med mera. Det händer också att de fixar säkerhetshålet de själva tog sig in via (för att slippa fler inkräktare att dela maskinen med, och för att systemadministratörerna inte ska ägna uppmärksamhet åt systemet).

• Ändrade konfigurationsfiler, exempelvis: Nytillagda användare, tillagt förtroende (till exempel "den här användaren/nyckeln får logga in som användare X") borttagna säkerhetskontroller, start av inkräktarens program vid systemstart.

• Nya program: Inkräktare installerar ofta program på datorn, till exempel för att leta efter lokala säkerhetshål, scanna efter säkerhetshål på andra system på nätet, manipulera loggar, installera rootkit, sniffa tangentbord och nätverk, fjärrstyra systemet, utföra attacker mot andra system, sköta IRC-kanaler, reläa uppkopplingar för att försvåra spårande, skicka spam, fuskklicka på reklamlänkar, dela ut tveksamma filer och en rad annat.

• Loggfiler: Samtidigt som inkräktarna gärna friserar eller raderar systemets vanliga loggar, så lämnar deras egna program ibland loggar efter sig. Vanliga exempel är loggar från snifferprogram (som inkräktarna återvänder för att vittja efter ett tag), resultat från scanningar efter sårbarheter på andra system och loggar från program som delar ut filer.

• Utdelade filer: Om syftet med intrånget varit att skaffa sig ett system att dela ut filer från, så måste dessa filer lagras någonstans på systemet, och de tar ofta stor plats.

• Arbetsmaterial: Slarviga inkräktare lämnar ofta efter sig "arbetsmaterial" i form av filer som använts under intrånget. Det kan till exempel vara källkod till program som installerats eller filer med utdata från program som körts.

Hur hittar du då de filer som är intressanta i sammanhanget?

• MAC-time-analys visar filer som skapats, modifierats eller lästs vid intressanta tidpunkter under incidenten. Dessa filer undersöker du, och kontrollerar även relaterade filer (till exempel de i samma katalog).

• Checksummor kan användas för att kontrollera om filer ändrats. Detta förutsätter att du vet vilka checksummor som filerna borde ha, till exempel för att du kör ett program som lagrar och kontrollerar checksummor (Tripwire, Aide, Samhain, med flera). På Linux-system med RPM kan du också jämföra filernas checksummor mot de som sparades vid installationen av paketet som filen ingår i; inkräktare brukar konstigt nog inte bry sig om att rätta till detta.

• Filer kan givetvis också kontrolleras (rakt av eller via checksummor) mot motsvarande filer på ett system som inte är drabbat.

• Kataloger där oprivilegierade användare har skrivrätt är alltid intressanta att undersöka då du misstänker intrång utifrån mot en nättjänst som inte körs med hög behörighet.

• Inkräktare döper ofta filer och kataloger på underliga sätt för att försvåra upptäckt eller borttagning. På Unix-system kan detta innebära att man låter namnet börja med punkter (som ju inte visas normalt) eller innehålla mellanslag på diverse ställen. Ett exempel på detta kan vara "..." eller ".. " som katalognamn. På Windows-system är det vanligt att försöka gömma saker i "papperkorgen" (RECYCLER) och låta namnen innehålla "reserverade namn" som "COM1". En fördel med sådana namn är att det ju är uppenbart för dig att något är galet när du hittar det.

• En annan strategi som används är att gömma filer djupt ner i en kataloghierarki bland legitima filer. Det gäller för dig att inte gå upp några nivåer ovanför när du letar efter dem.

• Filer (särskilt program) kan också döpas till namn som är identiska med eller liknar legitima dito. Istället för att kalla snifferprogrammet "sniffer", så får det heta "cron", "svchost.exe" eller något annat som inte sticker ut allt för mycket i den lokala miljön. För att inte gå på detta behöver du god kunskap om hur systemet normalt ska se ut.

• På Unix-system är det också intressant att kontrollera programfiler som har setuid/setgid-flaggorna satta. Inkräktare som har tagit sig in om en vanliga användare och knäckt sig vidare till root sparar gärna en kopia av skalet ägd av root med setuid satt någonstans i filssytemet. På så sätt kan de bli root igen nästa gång bara genom att köra det programmet.

• Glöm inte att kontrollera filer på eventuella filservrar åtkomliga från det drabbade systemet. Förutom att filer kan hamna där bara för att hemkataloger råkar ligga där, så kan det också vara en del av en medveten attack: inkräktaren skaffar sig systemprivilegier på ett system, byter användare där, och försöker läsa och skriva filer som den användaren på ett monterat filsystem.

• Historiefiler från kommandoskal är alltid intressant att titta på, oavsett om de innehåller skumma saker eller har tömts på skumt sätt.

• Vissa operativsystem tillåter att data som hör till en fil lagras vid sidan om filens huvudinnehåll. Detta kallas "fork" i Mac OS, och ADS (Alternate Data Streams) i Windows, men motsvarande möjligheter finns även i Netware och en del Unix-filsystem. Inkräktare kan använda detta för att dölja data på systemet.

Raderade filer kan innehålla intressanta saker (till exempel loggfiler som inkräktarna raderat, källkod till program de kompilerat, exploitprogram de kört för att få privilegier). Försök återställa raderade eller gå igenom det innehåll på disken som inte hör till några filer (se programmet "dls" i TSK).

Hur gör du då när du hittat skumma filer och inte vet vad de gör?

• Undvik att köra skumma programfiler! Om du skulle behöva göra det, så gör det på en speciell "offerdator" med begränsad nätkontakt och som du sedan kan rensa (en virtuell dator i VMware eller liknande kan duga).

• Undersök filen med Unix-kommandot "file" för att se vad den detekteras som: kompilerat program? program i något skriptspråk? datafil på känt format? okänt?

• Packa upp filen om den är packad med något känt program.

• Titta på filen med en textfilsvisare eller editor om den verkar vara läslig.

• Kör "strings" på filen för att kontrollera vilka strängar som finns i den om filen inte är läslig rakt av. Jämför med utmatningen från samma operation på en "ren" fil om du till exempel misstänker att det rör sig om en ändrad kopia av ett legitimt program.

• Disassemblera kompilerade program om du kan den typen av analys eller är tillräckligt desperat för att försöka lära dig på vägen.

• Försök förstå vad filens syfte är och hur den hänger ihop med andra filer och händelser i samband med incidenten.

• Alla filer du hittar behöver inte vara "meningsfulla" och ha med den aktuella incidenten att göra. Det händer ju att inkräktare har med sig sin "verktygslåda" men inte utnyttjar allt.

Vägen in

En viktig del av analysen är att klarlägga varför intrånget kunde ske. Ibland är det uppenbart baserat på loggar och filer, men vid andra tillfällen får man gissa en del och sedan försöka bevisa att hypotesen stämmer eller att den inte kan vara sann. Exempel på saker att tänka på:

• Kontrollera hur väl uppdaterat systemet är med patchar för säkerhetshål i operativsystem och attacker. Ju fler sårbarheter, desto fler attackmöjligheter kan ha använts.

• Om intrånget ser ut att ha skett direkt utifrån (inte via en lokal användares konto): försök att se vilka tjänster som varit åtkomliga utifrån.

• Det är vanligt att inkräktare som brutit sig in på ett system försöker använda samma metod för att ta sig vidare. Om det utsatta systemet verkar ha scannat andra datorer efter ett sårbart program på port X, så ligger det nära tillhands att misstänka att samma sårbarhet användes för intrånget mot detta system. Om inkräktarna installerar program för att spela in lösenord är det troligt att man tagit sig in via ett stulet lösenord.

• Ta reda på vilka attacker som är populära mot aktuellt operativsystem och aktuella applikationer just nu.

Tänk på att attacken kan ha kommit via ett användarkonto. En inkräktare som "redan är inne på systemet" kan såklart göra betydligt mer saker än en som tvingas nöja sig med att angripa nättjänster utifrån. Exempel på metoder som kan ha använts för att få ett konto att missbruka:

• Gissande av lösenord för kända användare, eller rent av gissande av både användarnamn och lösenord. Detta är till exempel en vanlig strategi mot SSH på Unixdatorer.

• Inspelning av lösenord på andra datorer via trojaniserade klientprogram.

• Sniffning av knapptryckningar på en infekterad klientdator.

• Avlyssning av okrypterad eller bristfälligt krypterad nättrafik på en dator som sitter på ett känsligt ställe av nätet.

• Utnyttjande av det faktum att samma lösenord använts på ett annat system där det lagrats i klartext eller där inkräktaren haft möjlighet att köra ett lösenordsknäckningsprogram

• Manipulation av användarens hemkatalog på en filserver (exempel: ändring av ~/.ssh/authorized_keys på Unix-system) från ett annat knäckt system.

Gissande av lösenord brukar ge avtryck i loggfiler på det aktuella systemet, men om någon av de andra metoderna använts kan det vara omöjligt att få reda på hur lösenordet kommit på avvägar, bara genom att analysera data från det systemet. Rapport

Förhoppningsvis har du efter att ha jobbat aktivt med det som beskrivs ovan skapat dig en uppfattning om vad som har hänt och varför det kunnat ske.

Sista steget i analysen är att dokumentera resultatet på något sätt. Omfattningen kan vara allt från några rader i ett ärendehanteringssystem till en komplett skriftlig rapport avsedd för ledning, polisanmälan eller dylikt.

En någorlunda ambitiös rapport kan innehålla:

• Information om händelseförloppet vid upptäckt, datainsamling, analys och ev. återställningsarbete som påbörjats. Detta är hårda, konkreta fakta om vad som skett och vad du och kollegorna gjort.

• Analys av incidenten som sådan. Här kan du behöva göra antaganden eller rent av gissningar, men det är viktigt att du tydligt talar om vad som är hårda fakta och vad som är dina bedömningar och antaganden. Tidslinje och diagram kan bifogas som bilagor.

• Analys av anledning till incidenten. Förhoppningsvis vet du orsaken på lägsta nivå (till exempel: "Programvara X var inte uppdaterad för säkerhetshål Y, som kunde utnyttjas över nätet" eller "Användare Zs lösenord var på avvägar och användes för att logga in"), men det kan också vara intressant att fundera över orsaker på högre nivå ("Varför uppdaterades inte programvara X?", "Hur kunde Zs lösenord vara på drift?" och så vidare).

• Förslag till åtgärder. Vad behöver ske för att en liknande incident inte ska inträffa igen? Här kan det finnas både kortsiktiga åtgärder och mera långsiktiga.

Läs mer

• Forensic Discovery, av Dan Farmer och Wietse Venema. Addison-Wesley/Pearson Education, 2005. ISBN 0-201-63497-X.

• http://www.sleuthkit.org/ (The Sleuth Kit och mac-robber)