Analiza memorijskog dumpa i kernela na Windows i Unix sustavima

Informatec Digital » Sredstva » Analiza memorijskog dumpa i kernela na Windows i Unix sustavima

Kada operativni sustav "paničari" ili se sruši, jedini način da se shvati što se dogodilo jest da se napravi analiza memorijskog dumpa kernela . Ovi dumpovi bilježe unutarnje stanje sustava u trenutku kvara i ključni su za otklanjanje pogrešaka u složenim sustavima, istraživanje sigurnosnih incidenata ili provođenje forenzičkih ispitivanja.

Iako možda zvuči vrlo "niskorazinsko", analiza memorijskog dumpa nije isključivo dostupna programerima kernela. Administratori sustava, inženjeri podrške, pa čak i sigurnosni revizori mogu imati koristi od nje ako poznaju prave alate, različite vrste dumpa i osnovne tehnike interpretacije . Provest ćemo vas kroz sve ovo na Windowsima, Unixu/Linuxu i BSD-u, koristeći alate poput WinDbg, crash, kgdb i LiME.

Što je izvadak memorije kernela i zašto ga vrijedi analizirati?

Izvadak memorije kernela (često nazvan izvadak rušenja kernela ili jednostavno izvadak rušenja ) je datoteka koja sadrži kopiju, potpunu ili djelomičnu, memorije u trenutku kada sustav pretrpi kritičan kvar, kao što je panika kernela u Unixu/Linuxu ili plavi ekran smrti (BSOD) u Windowsima.

U praksi, dump ove vrste sprema interne strukture kernela, stogove poziva, kontekst procesa i učitane upravljačke programe . Zahvaljujući tome, nakon katastrofe može se provesti post mortem analiza koja je vrlo slična otklanjanju pogrešaka u živom sustavu, ali bez pritiska dodirivanja produkcijskog stroja dok ne radi ispravno.

Razlozi za duboko istraživanje kernel dumpova su raznoliki: od otklanjanja pogrešaka naizgled nasumičnih grešaka i povremenih rušenja sustava do istraživanja je li sustav zlonamjerno manipuliran ili je li rušenje sustava ostavilo tragove osjetljivih informacija na disku.

Uz potpune core dumpove, postoji mogućnost izrade dumpova pojedinačnih procesa (klasični core dumpovi ), koji su vrlo korisni kada želimo ograničiti problem na određenu aplikaciju ili provjeriti utjecaj na povjerljivost usluge poput klijenta za e-poštu ili razmjenu poruka.

Vrste memorijskih dumpova u sustavu Windows i njihova korisnost

Na Windows sustavima, sam operativni sustav može generirati različite vrste izvatka kada se pojavi STOP pogreška. Svaka vrsta uključuje različitu razinu detalja, stoga je ključno znati koja vam je vrsta izvatka potrebna ovisno o problemu i ograničenjima prostora na disku.

Jedan od najčešćih formata u korisničkim okruženjima i mnogim poslužiteljima je mali memorijski dump (minidump)To je onaj koji zauzima najmanje prostora i obično se nalazi u %SystemRoot%\Minidump, s datotekama stila MiniMMDDYG-01.dmp.

Ovaj mini dump sadrži vrlo specifične, ali važne informacije: kod STOP pogreške i njegove parametre , popis upravljačkih programa učitanih u trenutku kvara, kontekst procesora koji je zaustavljen (PRCB), kontekste uključenog procesa i niti (strukture EPROCESS i ETHREAD) i stog poziva kernel-mode te niti.

Zahvaljujući ovim osnovnim strukturama, čak i s minidumpom često je moguće identificirati koji upravljački program ili modul uzrokuje pad sustava, iako neće uvijek biti moguće pratiti cijeli trag ako problem potječe daleko od niti koja se izvodila u trenutku pada sustava, a dostupne kontekstualne informacije su ograničene.

Windows također može generirati izvatke memorije kernela i mnogo veće potpune izvatke koji sadrže dijelove ili cijelu fizičku memoriju. To je posebno korisno za analizu niske razine, forenzičke istrage i napredno otklanjanje pogrešaka upravljačkih programa ili samog sustava.

Konfigurirajte i otvorite memorijske dumpove u sustavu Windows pomoću WinDbg-a i KD-a

Da biste iskoristili prednosti sistemskih izvatka u sustavu Windows, prvi korak je pravilno konfiguriranje opcija pokretanja i oporavka . Na upravljačkoj ploči, u naprednim svojstvima sustava, možete odabrati vrstu izvatka koji želite generirati u slučaju kvara: na primjer, "Mali izvatak memorije (256 KB)" i putanju gdje će se pohraniti.

Sustavu je također potrebna datoteka za pohranu podataka na volumenu za pokretanje od najmanje nekoliko megabajta za zapisivanje izvatka. U modernim verzijama sustava Windows, svaki pad sustava stvara novu datoteku, a povijest se održava u konfiguriranoj mapi, što omogućuje jednostavan pregled prošlih incidenata.

Nakon generiranja, postoji nekoliko načina za provjeru ispravnosti dumpova. Klasični uslužni program je Dumpchk.exe , koji vam omogućuje provjeru osnovnog integriteta datoteke i ispis sažetih informacija. Za napredniju analizu koriste se alati za otklanjanje pogrešaka u sustavu Windows , uključujući WinDbg (grafičko sučelje) i KD (verzija s naredbenim retkom).

Nakon instaliranja paketa za otklanjanje pogrešaka s Microsoftove web stranice, alati će se obično nalaziti u mapi kao što je C:\Program Files\Debugging Tools for Windows . Odatle možete otvoriti naredbeni redak i učitati datoteku s izvatkom pomoću WinDbg-a ili KD-a, navodeći datoteku s parametrom -z .

windbg -y <RutaSimbolos> -i <RutaBinarios> -z <RutaDump>

Putanja simbola može pokazivati ​​na poslužitelj simbola s lokalnim predmemoriranjem , na primjer:

srv*C:\Symbols*https://msdl.microsoft.com/download/symbols

Iako je binarni put obično nešto poput C:\Windows\I386 ili mapu u koju smo kopirali izvršne datoteke sustava koje odgovaraju verziji koja je generirala dump. To je važno jer Minidumps ne uključuje sve binarne datoteke, samo reference na njih, pa ih debugger mora moći pronaći.

Osnovna analiza izvatka o rušenju kernela u sustavu Windows

Nakon što se izvadak učitava pomoću WinDbg-a ili KD-a, analiza izvadka kernela nakon rušenja sustava prilično je slična sesiji otklanjanja pogrešaka nakon analize. Prva naredba koju gotovo svi pokreću je `!analyze` , koja pokreće automatiziranu analizu i generira početno izvješće.

Naredba !analyze -show pokazati kod za provjeru grešaka i njegovi parametriDok !analyze -v Proizvodi puno detaljniji izlaz: sumnjivi modul, stog poziva, kontekstualne informacije i, u mnogim slučajevima, prijedloge o mogućim uzrocima ili dijagnostičkim koracima.

Kao nadopuna toj analizi, naredba .bugcheck ponovno ispisuje kod pogreške i povezane parametre, koji se mogu usporediti s Microsoftovom referencom koda za provjeru grešaka kako bi se saznalo točno značenje svake vrijednosti i tipični uzroci.

Naredba lm N T (popis modula) vam omogućuje da vidite Popis učitanih modula s njihovom putanjom, adresama i statusomOvo pomaže potvrditi je li upravljački program identificiran automatskom analizom doista u memoriji i koja je verzija. Ovaj popis je posebno koristan kada sumnjamo na upravljačke programe trećih strana ili sigurnosne komponente koje komuniciraju s jezgrom.

Po želji, možemo pojednostaviti učitavanje dumpa stvaranjem batch datoteke koja prima putanju do dumpa i pokreće KD ili WinDbg s odgovarajućim parametrima. Na taj način, trebamo napisati samo kratku naredbu koja uključuje samo lokaciju datoteke, a skripta se brine za sve ostalo.

Korištenje WinDbg-a za duboke izvatke kernela

Za memorijske dumpove u kernel modu, WinDbg također nudi mogućnost rada s više datoteka i sesija. Dumpovi se mogu otvoriti iz naredbenog retka s -z ili iz grafičkog sučelja pomoću izbornika Datoteka > Otvori memorijski dump ili prečaca na tipkovnici Ctrl+D.

Ako je WinDbg već otvoren u pasivnom načinu rada, jednostavno odaberite datoteku u dijaloškom okviru "Otvori izvadak iz sustava", navodeći putanju ili pregledavajući disk. Nakon učitavanja, možete pokrenuti sesiju naredbom "g" (Go) u određenim scenarijima ili izravno pokrenuti početne naredbe za analizu.

Osim klasičnog !analyzePreporučljivo je upoznati se s odjeljak s referencom naredbe za ispravljanje pogrešakaOvo opisuje sve dostupne naredbe za čitanje unutarnjih struktura, ispitivanje memorije, interpretiranje stoga i još mnogo toga. Mnoge od ovih tehnika primjenjive su i na sesije uživo i na offline dumpove.

WinDbg vam također omogućuje rad s više paralelnih dumpovaU naredbeni redak možemo dodati više parametara -z, svaki nakon kojeg slijedi različito ime datoteke, ili dodati nove ciljeve pomoću naredbe .opendumpOtklanjanje pogrešaka na više odredišta korisno je za usporedbu ponavljajućih kvarova ili ulančanih incidenata.

U nekim okruženjima, memorijski dumpovi se pakiraju u CAB datoteke radi uštede prostora ili olakšavanja prijenosa. WinDbg može izravno otvoriti .cab s dumpom unutra, i korištenjem -z i s .opendumpiako će čitati Izvući će samo jednu od izvučenih datoteka i neće izvući ostale datoteke. to bi moglo ići u isti paket.

Izvještaji o rušenju sustava u Unixu i Linuxu: uslužni programi, alati i zahtjevi

U Unix i GNU/Linux sustavima, filozofija je slična, ali ekosustav alata se znatno razlikuje. Većina Unix-sličnih kernela nudi mogućnost spremanja kopije memorije kada se dogodi katastrofalan događaj , što je poznato kao izvadak jezgre ili izvadak rušenja kernela.

Iako im je primarna namjena razvoj kernela i upravljačkih programa, ovi dumpovi imaju jasan sigurnosni aspekt. Pad sustava mogu uzrokovati programske pogreške, ali i neuspješne zlonamjerne radnje, pokušaji manipuliranja komponentama sustava ili nespretno iskorišteni uvjeti utrke.

U dobro konfiguriranom Unix sustavu, dnevni rušenja su rijetka, ali kada se dogode, preporučljivo je imati infrastrukturu za izradu izvatka, kao što su Kdump, LKCD ili druga rješenja koja omogućuju snimanje sistemske memorije. Međutim, ključno je odvagnuti dijagnostičku vrijednost izvatka u odnosu na rizik da sadrži vrlo osjetljive podatke.

Jedan od najopsežnijih i najčešće korištenih alata za ovu vrstu analize u Linuxu je crash , koji je izvorno razvio Red Hat. Ovaj uslužni program postao je praktički de facto standard za ispitivanje kernel dumpova, a također i za analizu pokrenutih sustava.

Rušenje može djelovati protiv žive memorije sustava kroz /dev/mem ili, u Red Hatu i izvedenim distribucijama, korištenjem specifičnog uređaja /dev/crashUnatoč tome, uobičajena je praksa da se alatu dostavlja datoteka s dumpom koju generiraju mehanizmi kao što su Kdump, datoteka za izradu dumpa, Ispis diska ili izvatke specifične za arhitekturu poput s390/s390x ili xendump u virtualiziranim okruženjima.

Uloga rušenja i važnost vmlinuxa u Linuxu

Uslužni program za rušenje stvoren je, dijelom, kako bi se prevladala ograničenja korištenja gdb izravno na /proc/kcoreIzmeđu ostalog, pristup toj pseudo-slici memorije može biti ograničen, a osim toga, određene opcije kompilacije kernela otežavaju pravilnu interpretaciju unutarnjih struktura ako imamo samo komprimiranu izvršnu binarnu datoteku.

Da bi rušenje ispravno funkcioniralo, potrebna su dva ključna elementa: kompilirana vmlinux datoteka sa simbolima za otklanjanje pogrešaka (obično sa zastavicama poput -g) i sam kernel dump. Ova kombinacija omogućuje alatu mapiranje memorijskih adresa na funkcije, strukture i retke koda.

Važno je razlikovati između vmlinux i vmlinuzNa većini sustava vidljiv je samo vmlinux, što je komprimirana, bootabilna verzija kernela. Za rušenje sustava potreban je simbolički dekomprimirani vmlinux; bez njega, pri pokušaju učitavanja dumpa ili /dev/mem Naići ćemo na greške tipa Ne mogu pronaći pokrenutu jezgru — unesite argument popisa imena.

Iako je moguće ručno izdvojiti vmlinuz, proces nije uvijek jednostavan i u praksi je često puno praktičnije ponovno kompajlirati kernel kako bi se istovremeno dobili i vmlinux i vmlinuz. U ozbiljnim administratorskim okruženjima dobra je praksa održavati zaseban vmlinuz paket za svaku implementiranu verziju kernela, posebno za ove situacije.

Nakon što su zahtjevi ispunjeni, pokretanje crasha na dump datoteki je relativno jednostavno: odredite odgovarajuću vmlinux i dump datoteku, a alat otvara interaktivnu sesiju iz koje možete istraživati ​​strukture kernela, popisivati ​​procese, pregledavati stogove poziva i izdvajati forenzičke informacije . Oni koji žele dublje istražiti mogu konzultirati specijaliziranu dokumentaciju, kao što je dobro poznati tehnički dokument o crashovima.

Ograničenja /dev/mem i prvi pristupi u Linuxu

Prije pribjegavanja određenim alatima, mnogi administratori su povijesno pokušavali dobiti izvadak memorije. čitanje izravno s uređaja /dev/memOvaj pristup se činio jednostavnim: koristiti alat poput izvadak memorije (što ispisuje taj uređaj na STDOUT) ili povlači iz dd if=/dev/mem of=volcado.mem.

Međutim, moderne jezgre nude opcije kompajliranja kao što su CONFIG_STRICT_DEVMEMkoji ozbiljno ograničavaju pristup iz korisničkog prostora do /dev/memTipičan rezultat je da se čitanje prekida nakon malog bloka (npr. 1 MB) ili, u najgorem slučaju, greška u toj interakciji može završiti kernel panika trenutno i ponovno pokretanje stroja.

Ova zaštita ima savršenog smisla sa sigurnosnog stajališta, ali nas prisiljava da tražimo druge načine za dobivanje pouzdanog i potpunog dumpa bez oslanjanja u potpunosti na generičke uređaje koji više nisu toliko dostupni kao prije.

Stoga je trenutni trend oslanjanje na specifične module ili integrirane infrastrukture za izvještaje o rušenju sustava, umjesto jednostavnog pokušaja "struganja memorije" alatima korisničkog prostora koji nisu dizajnirani za koegzistiranje s modernim politikama zaštite kernela.

LiME Forensics: Ekstrakcija memorije u Linuxu i Androidu

Vrlo moćna alternativa u forenzičkom svijetu je LiME (Linux Memory Extractor) , kernel modul dizajniran upravo za kontrolirano snimanje nestabilne memorije i bez ograničenja koja utječu na /dev/mem. LiME radi u kernel prostoru, tako da može puno izravnije pristupiti RAM-u.

LiME se distribuira sa svojim izvornim kodom i kompajlira se protiv zaglavlja kernela u upotrebiProces kompilacije generira modul .ko specifičan za verziju kernela u koju će se učitati. Nakon kompajliranja, možemo ga provjeriti alatima kao što su file kako bismo osigurali da je ELF modul koji odgovara našoj arhitekturi ispravno generiran.

Za korištenje LiME-a, jednostavno učitajte modul s insmod iz korijena i proslijedite mu odgovarajuće opcije, na primjer navođenjem odredište mrežnog dumpa pomoću TCP-a i sirovog formata:

insmod lime-3.x.y.ko "path=tcp:4444 format=raw"

Paralelno, na računalu koje će primiti dump, slušamo konfigurirani port pomoću alata poput ncpreusmjeravanje izlaza u datoteku:

nc <IP_origen> 4444 > volcado.mem

Nakon nekoliko minuta, ovisno o količini RAM-a i performansama mreže, imat ćemo datoteku čija veličina odgovara fizičkoj memoriji izvornog sustava. Ovo je potpuni RAM dump koji možemo analizirati forenzičkim alatima ili čak pomoću nizova znakova ili drugih uslužnih programa kao prvi korak u lociranju zanimljivih nizova znakova.

Rizici izbacivanja podataka iz procesa i izlaganja podataka

Potpuni kernel dump je izuzetno informativan, ali može biti i pretjeran kada nas zanima samo određeni proces. U tom slučaju ima puno smisla pribjeći... pojedinačni dumpovi procesa pomoću alata poput gcore u Unixu/Linuxu.

Ovi poprocesni dumpovi su puno manji i lakše upravljivi te vam omogućuju da usmjerite svoju analizu na određene aplikacije kao što su klijent za razmjenu poruka (npr. Skype) ili klijent e-pošte (npr. Thunderbird), gdje je relativno lako pronaći lozinke u običnom tekstu, tokene sesije ili podatke o kontaktu istraživanjem memorijskih nizova.

Iz perspektive razvoja, ovi osnovni dumpovi pomažu u lociranju programskih pogrešaka, curenja memorije ili nekonzistentnih stanja u usluzi. Međutim, iz perspektive sigurnosti, problem nastaje kada se ovi dumpovi rutinski generiraju i pohranjuju na lokacijama dostupnim drugim korisnicima , bilo na samom sustavu ili na dijeljenim mrežnim resursima.

Ako korisnik zakaže, na primjer, zadatak cron Periodičnim snimanjem izvatka osjetljivih procesa i njihovim ostavljanjem u globalno čitljivom direktoriju, napadač otvara ogromna vrata za otkrivanje kritičnih informacija. U mnogim scenarijima revizije, analiza ovih datoteka omogućuje napadaču oporavak vjerodajnice, popisi kontakata, povijest komunikacije i drugi privatni podaci uz relativno mali napor.

Stoga je u svakoj ozbiljnoj reviziji Unix sustava preporučljivo posvetiti nekoliko minuta provjeri generiraju li se dumpovi (potpuni ili djelomični), gdje se pohranjuju, koje imaju dozvole i postoji li neki automatizirani proces koji ostavlja kopije memorije izvan dohvata neovlaštenih korisnika.

Post mortem analiza dumpova u FreeBSD-u s kgdb

U BSD svijetu, a posebno u FreeBSD-u, pristup post mortem analizi uključuje Omogućite izvatke iz sustava i kompajlirajte kernel sa simbolima za otklanjanje pogrešakaOvo se kontrolira iz direktorija za konfiguraciju kernela, obično u /usr/src/sys/<arq>/conf.

U odgovarajućoj konfiguracijskoj datoteci, generiranje simbola može se omogućiti linijom poput ove:

makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols

Nakon izmjene konfiguracije, kernel se mora ponovno kompajlirati. Neki objekti će biti regenerirani (npr. trap.o) zbog promjene u datotekama za izgradnju. Cilj je dobiti kernel s isti kod kao onaj koji ima problema, ali s dodavanjem potrebnih informacija za otklanjanje pogrešakaPreporučljivo je usporediti stare i nove veličine pomoću naredbe size kako bi se osiguralo da nije došlo do neočekivanih promjena u binarnoj datoteci.

Nakon što je kernel sa simbolima instaliran, možemo pregledati dumpove pomoću kgdb-a kako je opisano u službenoj dokumentaciji. Ne moraju svi simboli biti potpuni, a neke funkcije mogu se pojaviti bez brojeva redaka ili informacija o argumentima, ali u većini slučajeva razina detalja je dovoljna za praćenje problema.

Ne postoji apsolutno jamstvo da će analiza riješiti sve incidente, ali u praksi ova strategija prilično dobro funkcionira u visokom postotku scenarija , posebno kada se izvješćivanja o padu sustava kombiniraju s dobrim pregledom nedavnih promjena u sustavu.

Najbolje prakse za analizu i dokumentiranje pogrešaka jezgre

Bez obzira na operativni sustav, analiza kernel dump-a obično se završava pozivanjem na tehničku dokumentaciju, baze znanja, specijalizirane forume ili čak sam izvorni kod kernela kako bi se interpretirale poruke, kodovi pogrešaka i nepoznati simboli.

U Linuxu je vrlo korisno osloniti se na službeno stablo izvornog koda, ugrađenu dokumentaciju i resurse zajednice. Mnoge poruke o pogreškama kernela mogu se pratiti do točne datoteke iz koje potječu, što pomaže u razumijevanju konteksta u kojem se određeni BUG() ili WARN() aktivira.

U sustavu Windows, Microsoftova dokumentacija, baza znanja (KB) i tehnički forumi pružaju detaljna objašnjenja kodova za provjeru grešaka, preporuke za rješavanje problema i poznate obrasce pogrešaka . Kombiniranjem ovih informacija s izvješćima iz !analyze -v moguće je razviti razuman plan ublažavanja.

Prava vrijednost izvatka o padu sustava proizlazi kada se sve te informacije usporede s dobrim razumijevanjem operativnog sustava i specifičnog okruženja u kojem se kvar dogodio . Tek tada se mogu razviti trajna rješenja i, prije svega, spriječiti ponavljanje istog problema u budućnosti s ozbiljnijim posljedicama.

Analiza kernel dumpa je, u konačnici, spoj znanosti i umijeća: zahtijeva odgovarajuće alate, prethodnu konfiguraciju (simbole, opcije dumpa, sigurnu pohranu) i mnogo iskustva u čitanju stogova, struktura i kodova grešaka. Savladavanje ovih tehnika omogućuje nam ne samo otklanjanje pogrešaka u složenim incidentima, već i dramatično povećanje sigurnosti i otpornosti sustava kojima upravljamo.