Detekce porušení pomocí forenzní analýzy souborového systému Linux

Forenzní analýza obrazu disku Linux je často součástí reakce na incidenty, aby se zjistilo, zda došlo k porušení. Linux forenzní je jiný a fascinující svět ve srovnání s Microsoft Windows forenzní. V tomto článku analyzuji obraz disku z potenciálně kompromitovaného systému Linux, abych určil, kdo, co, kdy, kde, proč a jak incidentu, a vytvořím časové osy událostí a souborového systému. Nakonec z obrazu disku extrahuji zajímavé artefakty.

V tomto tutoriálu použijeme některé nové nástroje a některé staré nástroje v kreativních, nových způsobech provádění forenzní analýzy obrazu disku.

Scénář

Další zdroje pro Linux

• Cheat pro příkazy Linuxu
• Cheat sheet pro pokročilé příkazy systému Linux
• Bezplatný online kurz:Technický přehled RHEL
• Síťový cheat pro Linux
• Cheat sheet SELinux
• Cheat pro běžné příkazy pro Linux
• Co jsou kontejnery systému Linux?
• Naše nejnovější články o Linuxu

Premiere Fabrication Engineering (PFE) má podezření, že došlo k incidentu nebo kompromitaci týkající se hlavního serveru společnosti s názvem pfe1. Domnívají se, že server mohl být zapojen do incidentu a mohl být kompromitován někdy mezi prvním březnem a posledním březnem. Zapojili mé služby jako soudního znalce, aby prošetřili, zda byl server kompromitován a zapojen do incidentu. Vyšetřování určí, kdo, co, kdy, kde, proč a jak stojí za možným kompromisem. Společnost PFE si navíc vyžádala moje doporučení ohledně dalších bezpečnostních opatření pro jejich servery.

Obrázek disku

K provedení forenzní analýzy serveru žádám společnost PFE, aby mi poslala obraz forenzního disku pfe1 na USB disku. Souhlasí a říkají:"USB je v poště." Přichází USB disk a já začínám zkoumat jeho obsah. K provedení forenzní analýzy používám virtuální stroj (VM) s distribucí SANS SIFT. SIFT Workstation je skupina bezplatných a open source nástrojů pro odezvu na incidenty a forenzních nástrojů navržených k provádění podrobných digitálních forenzních zkoumání v různých prostředích. SIFT má širokou škálu forenzních nástrojů, a pokud nemá nástroj, který chci, mohu si jej bez větších problémů nainstalovat, protože jde o distribuci založenou na Ubuntu.

Po prozkoumání jsem zjistil, že USB neobsahuje obraz disku, ale kopie hostitelských souborů VMware ESX, což jsou soubory VMDK z hybridního cloudu PFE. Tohle nebylo to, co jsem očekával. Mám několik možností:

1. Mohu kontaktovat společnost PFE a vyjádřit se jasněji k tomu, co od ní očekávám. Na začátku takového zasnoubení to nemusí být to nejlepší.
2. Mohu načíst soubory VMDK do virtualizačního nástroje, jako je VMPlayer, a spustit jej jako živý virtuální počítač pomocí jeho nativních linuxových programů k provedení forenzní analýzy. Existují minimálně tři důvody, proč to nedělat. Nejprve se při spuštění souborů VMDK jako živého systému změní časová razítka souborů a obsahu souborů. Za druhé, protože server je považován za kompromitovaný, každý soubor a program souborového systému VMDK musí být považován za kompromitovaný. Za třetí, použití nativních programů na kompromitovaném systému k provedení forenzní analýzy může mít nepředvídatelné následky.
3. K analýze souborů VMDK bych mohl použít balíček libvmdk-utils, který obsahuje nástroje pro přístup k datům uloženým v souborech VMDK.
4. Lepším přístupem je však převést formát souboru VMDK do formátu RAW. To usnadní spouštění různých nástrojů v distribuci SIFT na souborech v obraze disku.

Pro převod z VMDK do formátu RAW používám utilitu qemu-img, která umožňuje vytvářet, převádět a upravovat obrázky offline. Následující obrázek ukazuje příkaz pro převod formátu VMDK do formátu RAW.

Dále potřebuji vypsat tabulku oddílů z obrazu disku a získat informace o tom, kde každý oddíl začíná (sektory) pomocí nástroje mmls. Tento nástroj zobrazuje rozložení oddílů v systému svazků, včetně tabulek oddílů a štítků disků. Poté použiji počáteční sektor a dotazuji se na podrobnosti spojené se souborovým systémem pomocí nástroje fsstat, který zobrazuje podrobnosti spojené se souborovým systémem. Obrázky níže ukazují mmls a fsstat příkazy v provozu.

Z mmls jsem se dozvěděl několik zajímavých věcí výstup:Primární oddíl Linuxu začíná v sektoru 2048 a má velikost přibližně 8 gigabajtů. Oddíl DOS, pravděpodobně spouštěcí oddíl, má velikost přibližně 8 megabajtů. Nakonec je zde odkládací oddíl o velikosti přibližně 8 gigabajtů.

Spuštění fsstat říká mi mnoho užitečných věcí o oddílu:typ souborového systému, poslední zápis dat do souborového systému, zda byl souborový systém čistě odpojen a kam byl souborový systém připojen.

Jsem připraven připojit oddíl a zahájit analýzu. K tomu potřebuji přečíst tabulky oddílů na specifikovaném surovém obrazu a vytvořit mapy zařízení přes detekované segmenty oddílů. Mohl bych to udělat ručně s informacemi z mmls a fsstat —nebo bych to mohl udělat za mě pomocí kpartx.

Používám možnosti k vytvoření mapování pouze pro čtení (-r ), přidejte mapování oddílu (-a ) a poskytnout podrobný výstup (-v ). loop0p1 je název souboru zařízení pod /dev/mapper Mohu použít pro přístup k oddílu. Chcete-li jej připojit, spustím:

$ mount -o ro -o loop=/dev/mapper/loop0p1 pf1.raw /mnt

Všimněte si, že připojuji oddíl jako pouze pro čtení (-o ro ), aby se zabránilo náhodné kontaminaci.

Po připojení disku zahájím svou forenzní analýzu a vyšetřování vytvořením časové osy. Někteří soudní znalci nevěří ve vytvoření časové osy. Místo toho, jakmile mají připojený oddíl, plíží se souborovým systémem a hledají artefakty, které by mohly být relevantní pro vyšetřování. Tyto soudní znalce označuji jako „popínavé rostliny“. I když je to jeden ze způsobů forenzního vyšetřování, není zdaleka opakovatelný, je náchylný k chybám a může chybět cenné důkazy.

Věřím, že vytvoření časové osy je zásadním krokem, protože obsahuje užitečné informace o souborech, které byly upraveny, zpřístupněny, změněny a vytvořeny ve formátu čitelném pro člověka, známém jako MAC (modified, accessed, Changed) time evidence. Tato aktivita pomáhá identifikovat konkrétní čas a pořadí, kdy se událost uskutečnila.

Poznámky k souborovým systémům Linux

Linuxové souborové systémy jako ext2 a ext3 nemají časová razítka pro vytvoření/zrození souboru. Časové razítko vytvoření bylo zavedeno v ext4. KnihaForensic Discovery (1. vydání) od Dana Farmera a Wietse Venemy nastiňuje různá časová razítka.

• Čas poslední úpravy: U adresářů se jedná o poslední přidání, přejmenování nebo odebrání záznamu. U ostatních typů souborů je to poslední čas, kdy byl soubor zapsán.
• Čas posledního přístupu (čtení): U adresářů se toto prohledávalo naposledy. U ostatních typů souborů je to poslední čas čtení souboru.
• Poslední změna stavu: Příklady změn stavu jsou změna vlastníka, změna oprávnění k přístupu, změna počtu pevných odkazů nebo explicitní změna libovolného času MAC.
• Čas smazání: ext2 a ext3 zaznamenávají čas odstranění souboru v dtime časové razítko, ale ne všechny nástroje jej podporují.
• Čas vytvoření: ext4fs zaznamenává čas vytvoření souboru v crtime časové razítko, ale ne všechny nástroje jej podporují.

Různá časová razítka jsou uložena v metadatech obsažených v inodech. Inody jsou podobné číslu záznamu MFT ve světě Windows. Jedním ze způsobů, jak číst metadata souboru v systému Linux, je nejprve získat číslo inodu pomocí příkazu ls -i file pak použijte istat proti zařízení oddílu a zadejte číslo inodu. Zobrazí se vám různé atributy metadat, včetně časových razítek, velikosti souboru, skupiny vlastníka a ID uživatele, oprávnění a bloků, které obsahují skutečná data.

Vytvoření super časové osy

Mým dalším krokem je vytvoření super časové osy pomocí log2timeline/plaso. Plaso je přepsání perlu založeného nástroje log2timeline založeného na Pythonu původně vytvořeného Kristinn Gudjonsson a vylepšeného dalšími. Je snadné vytvořit super časovou osu pomocí log2timeline, ale interpretace je obtížná. Nejnovější verze enginu plaso dokáže analyzovat ext4 a také různé typy artefaktů, jako jsou zprávy syslog, audit, utmp a další.

Pro vytvoření super časové osy spustím log2timeline proti složce připojeného disku a použiji linuxové analyzátory. Tento proces nějakou dobu trvá; až to skončí, mám časovou osu s různými artefakty ve formátu databáze plaso, pak mohu použít psort.py převést databázi plaso do libovolného počtu různých výstupních formátů. Chcete-li zobrazit výstupní formáty, které psort.py podporuje, zadejte psort -o list . Použil jsem psort.py vytvořit super časovou osu ve formátu Excel. Na obrázku níže jsou uvedeny kroky k provedení této operace.

(Poznámka:z obrázků byly odstraněny nadbytečné čáry)

Super časovou osu importuji do tabulkového procesoru, abych usnadnil prohlížení, třídění a vyhledávání. Zatímco super časovou osu můžete zobrazit v tabulkovém procesoru, je snazší s ní pracovat ve skutečné databázi, jako je MySQL nebo Elasticsearch. Vytvořím druhou super časovou osu a odešlu ji přímo do instance Elasticsearch z psort.py . Jakmile bude super časová osa indexována pomocí Elasticsearch, mohu vizualizovat a analyzovat data pomocí Kibana.

Vyšetřování pomocí Elasticsearch/Kibana

Jak řekl seržant Farrell:"Díky připravenosti a disciplíně jsme pány svého osudu." Během analýzy se vyplatí být trpělivý a pečlivý a nebýt popínavý. Jedna věc, která pomáhá super analýze časové osy, je mít představu o tom, kdy k incidentu mohlo dojít. V tomto případě (zamýšlená slovní hříčka) klient říká, že k incidentu mohlo dojít v březnu. Stále zvažuji možnost, že se klient ohledně časového rámce mýlí. Vyzbrojen těmito informacemi začínám zkracovat časový rámec super časové osy a zužovat jej. Hledám zajímavé artefakty, které mají "časovou blízkost" s předpokládaným datem incidentu. Cílem je znovu vytvořit to, co se stalo, na základě různých artefaktů.

Abych zúžil rozsah super časové osy, používám instanci Elasticsearch/Kibana, kterou jsem nastavil. S Kibanou mohu nastavit libovolný počet složitých řídicích panelů pro zobrazení a korelaci forenzních událostí, které mě zajímají, ale této úrovni složitosti se chci vyhnout. Místo toho vyberu indexy zájmu pro zobrazení a vytvořím sloupcový graf aktivity podle data:

Dalším krokem je roztažení velkého pruhu na konci grafu:

5. března je k dispozici velký bar. Rozbalím tento pruh, abych viděl aktivitu k danému datu:

Když se podívám na aktivitu souboru protokolu ze super časové osy, vidím, že tato aktivita byla z instalace/upgradu softwaru. V této oblasti činnosti je k nalezení velmi málo.

Vrátím se do Kibana, abych viděl poslední sadu aktivit v systému a našel to v protokolech:

Jednou z posledních činností v systému byl, že uživatel john nainstaloval program z adresáře s názvem xingyiquan. Xing Yi Quan je styl čínských bojových umění podobný Kung Fu a Tai Chi Quan. Zdá se zvláštní, že by uživatel John instaloval program pro bojová umění na firemní server ze svého vlastního uživatelského účtu. K nalezení dalších instancí xingyiquan v souborech protokolu používám vyhledávací schopnost Kibana. Našel jsem tři období aktivity kolem řetězce xingyiquan 5. března, 9. března a 12. března.

Dále se podívám na záznamy protokolu pro tyto dny. Začínám 5. března a nacházím důkazy o tom, že jsem pomocí prohlížeče Firefox a vyhledávače Google hledal na internetu rootkit s názvem xingyiquan. Vyhledávání Google nalezlo existenci takového rootkitu na packetstormsecurity.com. Poté prohlížeč přešel na packetstormsecurity.com a stáhl soubor s názvem xingyiquan.tar.gz z tohoto webu do adresáře pro stahování uživatele John.

I když se zdá, že uživatel john šel na google.com vyhledat rootkit a poté na packetstormsecurity.com, aby si rootkit stáhl, tyto záznamy v protokolu neoznačují uživatele, který za vyhledáváním a stahováním stojí. Musím se na to podívat blíže.

Prohlížeč Firefox uchovává informace o své historii v databázi SQLite pod .mozilla adresář v domovském adresáři uživatele (tj. uživatel john) v souboru s názvem places.sqlite . Pro zobrazení informací v databázi používám program s názvem sqlitebrowser. Je to GUI aplikace, která uživateli umožňuje proniknout do databáze SQLite a prohlížet si tam uložené záznamy. Spustil jsem sqlitebrowser a importoval places.sqlite z .mozilla adresář pod domovským adresářem uživatele john. Výsledky jsou uvedeny níže.

Číslo ve sloupci zcela vpravo je časové razítko pro aktivitu vlevo. Jako test kongruence jsem převedl časové razítko 1425614413880000 na lidský čas a dostal 5. března 2015, 20:00:13.880. To se těsně shoduje s časem 5. března 2015, 20:00:00 000 z Kibana. Můžeme s rozumnou jistotou říci, že uživatel john hledal rootkit s názvem xingyiquan a stáhl soubor z packetstormsecurity.com s názvem xingyiquan.tar.gz do adresáře pro stahování uživatele john.

Zkoumání s MySQL

V tuto chvíli jsem se rozhodl importovat super časovou osu do databáze MySQL, abych získal větší flexibilitu při vyhledávání a manipulaci s daty, než umožňuje samotný Elasticsearch/Kibana.

Vytvoření xingyiquan rootkitu

Načtu super časovou osu, kterou jsem vytvořil z databáze plaso, do databáze MySQL. Z práce s Elasticsearch/Kibana vím, že uživatel john si stáhl rootkit xingyiquan.tar.gz z packetstormsecurity.com do adresáře pro stahování. Zde je důkaz aktivity stahování z databáze časové osy MySQL:

Krátce poté, co byl rootkit stažen, zdroj z tar.gz archiv byl extrahován.

S rootkitem se nic nedělalo až do 9. března, kdy si ten zlý herec přečetl soubor README pro rootkit pomocí programu More a poté rootkit zkompiloval a nainstaloval.

Historie příkazů

Načtu historii všech uživatelů na pfe1, kteří mají bash historie příkazů do tabulky v databázi MySQL. Po načtení historie je mohu snadno zobrazit pomocí dotazu jako:

select * from histories order by recno;

K získání historie pro konkrétního uživatele používám dotaz jako:

select historyCommand from histories where historyFilename like '%<username>%' order by recno;

Našel jsem několik zajímavých příkazů z bash uživatele john Dějiny. Konkrétně uživatel john vytvořil účet johnn, smazal jej, vytvořil jej znovu, zkopíroval /bin/true na /bin/false , dal hesla k účtům whoopsie a lightdm, zkopíroval /bin/bash na /bin/false , upravili heslo a soubory skupin, přesunuli domovský adresář uživatele johnn z johnn na .johnn , (což je skrytý adresář), změnil soubor s hesly pomocí sed po vyhledání, jak používat sed a nakonec nainstalovali xingyiquan rootkit.

Dále se podívám na bash historie příkazů pro uživatele johnn. Nevykazoval žádnou neobvyklou aktivitu.

Všimněte si, že uživatel john zkopíroval /bin/bash na /bin/false , otestuji, zda to byla pravda, zkontrolováním velikostí těchto souborů a získáním MD5 hash souborů. Jak je uvedeno níže, velikosti souborů a hodnoty hash MD5 jsou stejné. Soubory jsou tedy stejné.

Zkoumání úspěšných a neúspěšných přihlášení

Abych odpověděl na část otázky „kdy“, načtu soubory protokolu obsahující údaje o přihlášení, odhlášení, spouštění systému a vypínání do tabulky v databázi MySQL. Pomocí jednoduchého dotazu jako: 

select * from logins order by start

Našel jsem následující aktivitu:

Z tohoto obrázku vidím, že uživatel john se přihlásil do pfe1 z IP adresy 192.168.56.1 . O pět minut později se uživatel johnn přihlásil do pfe1 ze stejné IP adresy. Dvě přihlášení uživatelem lightdm následovala o čtyři minuty později a další o minutu později, poté se uživatel johnn přihlásil o méně než minutu později. Poté byl pfe1 restartován.

Při pohledu na neúspěšné přihlášení najdu tuto aktivitu:

Uživatel lightdm se opět pokusil přihlásit do pfe1 z IP adresy 192.168.56.1 . Ve světle falešných účtů přihlašujících se do pfe1 bude jedním z mých doporučení PFE zkontrolovat systém s IP adresou 192.168.56.1 pro důkaz kompromisu.

Zkoumání souborů protokolu

Tato analýza úspěšných a neúspěšných přihlášení poskytuje cenné informace o tom, kdy k událostem došlo. Obracím svou pozornost na zkoumání souborů protokolů na pfe1, zejména autentizační a autorizační aktivity v /var/log/auth* . Načtu všechny soubory protokolu na pfe1 do tabulky databáze MySQL a použiji dotaz jako:

select logentry from logs where logfilename like '%auth%' order by recno;

a uložte to do souboru. Otevřu tento soubor pomocí svého oblíbeného editoru a vyhledám 192.168.56.1 . Následuje část aktivity:

Tato část ukazuje, že uživatel john se přihlásil z IP adresy 192.168.56.1 a vytvořili účet johnn, odstranili účet johnn a vytvořili jej znovu. Poté se uživatel johnn přihlásil do pfe1 z IP adresy 192.168.56.1 . Dále se uživatel johnn pokusil stát se uživatelem whoopsie s su příkaz, který selhal. Poté bylo změněno heslo pro uživatele whoopsie. Uživatel johnn se dále pokusil stát se uživatelem lightdm s su příkaz, který také selhal. To koreluje s aktivitou zobrazenou na obrázcích 21 a 22.

Závěry z mého vyšetřování

• Uživatel john vyhledal, stáhl, zkompiloval a nainstaloval rootkit s názvem xingyiquan na server pfe1. Rootkit xingyiquan skrývá procesy, soubory, adresáře, procesy a síťová připojení; přidává zadní vrátka; a další.
• Uživatel john vytvořil, odstranil a znovu vytvořil další účet na pfe1 s názvem johnn. Uživatel john vytvořil z domovského adresáře uživatele johnn skrytý soubor, aby zakryl existenci tohoto uživatelského účtu.
• Uživatel john zkopíroval soubor /bin/true přes /bin/false a poté /bin/bash přes /bin/false pro usnadnění přihlášení k systémovým účtům, které se běžně nepoužívají pro interaktivní přihlášení.
• Uživatel john vytvořil hesla pro systémové účty whoopsie a lightdm. Tyto účty obvykle nemají hesla.
• Uživatelský účet johnn byl úspěšně přihlášen a uživatel johnn se neúspěšně pokusil stát se uživateli whoopsie a lightdm.
• Server pfe1 byl vážně ohrožen.

Moje doporučení pro PFE

• Přestavte server pfe1 z původní distribuce a aplikujte na systém všechny relevantní opravy, než jej vrátíte do provozu.
• Nastavit centralizovaný server syslog a mít všechny systémy v protokolu hybridního cloudu PFE na centralizovaný server syslog a do místních protokolů, aby se sloučila data protokolu a zabránilo se manipulaci se systémovými protokoly. Použijte produkt pro monitorování bezpečnostních informací a událostí (SIEM), abyste usnadnili kontrolu a korelaci bezpečnostních událostí.
• Implementujte bash časová razítka příkazů na všech firemních serverech.
• Povolte protokolování auditu kořenového účtu na všech serverech PFE a směrujte protokoly auditu na centralizovaný server syslog, kde je lze korelovat s dalšími informacemi protokolu.
• Prozkoumejte systém s IP adresou 192.168.56.1 pro porušení a kompromisy, protože byl použit jako stěžejní bod v kompromisu pfe1.

Pokud jste použili forenzní analýzu vašeho linuxového souborového systému na kompromisy, podělte se o své tipy a doporučení v komentářích.

Gary Smith letos vystoupí na LinuxFest Northwest. Podívejte se na hlavní body programu nebo se přihlaste k účasti.