Útoky na operační paměť

Máte v počítači disky zašifrované nějakým silným systémem, jako je TrueCrypt nebo FreeOTFE? To je prima. A vypínáte ho, když od něj odcházíte? Jestli ne, vystavujete svoje data některému z mnoha útoků na operační paměť, protože šifrovací klíč musí pro neodpojené (přimountované) disky v paměti zůstat a šikovný útočník ho z té paměti dokáže přečíst. Ve článku rozebírám způsoby, jak toho může útočník dosáhnout, i možné způsoby obrany.

Do začátku bych chtěl připomenout několik skutečností:

  • Všem útokům tohoto typu lze zabránit dodržováním jednoduché zásady: Bez zajištěné fyzické bezpečnosti nelze dosáhnout ani bezpečnosti informační. Pokud se útočník vůbec k chráněnému počítači nedostane, může ho jen velmi složitě napadnout. A naopak, pokud se k němu dostane, má k dispozici tolik způsobů, jak na něj zaútočit, že je prakticky nemožné je všechny odstínit – útočník samozřejmě bude útočit tam, kde je vaše ochrana nejslabší.

    Potíž s fyzickou bezpečností je ovšem v tom, že je velmi obtížně realizovatelná. Ve vojenských zařízeních nebo v nukleární elektrárně ji (doufám) zajistit dokážeme, snad se jí jde aspoň přiblížit v komerčním prostředí, ale přiznejme si na rovinu, že v domácím prostředí je prakticky nedosažitelná – většina z nás si nemůže dovolit nepřetržitou strážní službu nebo zalití celého počítače do betonového bloku…

    Z tohoto pohledu se všechny naznačené způsoby ochrany stávají spíš myšlenkovým cvičením než skutečným řešením problému. Je každopádně lepší je mít než nemít, ale rozhodně bych doporučoval mít na paměti, že i přes všechna opatření jsou informace napadnutelné.

  • V dalším textu předpokládám počítač, který z nějakého důvodu musí běžet samostatně i s připojenými disky. Může jít o server, který má poskytovat služby, i když u něj uživatel nesedí, možná jen chcete, aby pravidelně kontroloval poštu nebo zálohoval. To je jedno: podstatné je, že běží, i když ho nemáte pod přímou fyzickou kontrolou.

  • Soustředím se na počítač zašifrovaný, protože za prvé bez šifrování se informační bezpečnost zajistit nedá (s ním mnohdy také ne, ale to už je jiný problém), a za druhé, šifrovací programy mají důvody i snahu co nejlépe chránit svůj šifrovací klíč. Všechny prezentované útoky lze ale použít i na počítač nešifrovaný, i kdyby to mělo být jen proto, aby kolega vaším jménem a z vašeho počítače poslal šéfovi vulgární e-mail.

DMA útoky

Technika DMA („Direct Memory Access“, přímý přístup do paměti) je už mnoho let využívána k urychlení přenosů dat ze zařízení do paměti a opačně – zařízení si řekne DMA řadiči o přesun určitého bloku dat a řadič ho, už bez dalšího obtěžování procesoru, provede. Problém nastává v okamžiku, kdy se zařízení dokáže domluvit s řadičem na přenosu, aniž by s tím musel souhlasit operační systém. Na konferenci PacSec 2004 na to upozornil Maximillian Dornseif v prezentaci 0wned by an iPod, kde předvedl hacknutý iPOD s vlastním softwarem pro čtení paměti počítače. Další demonstrace následovaly, pěkný popis je v práci Hacking in Physically Addressable Memory – A Proof of Concept Davida Piegdona, ve které naleznete mimo jiné postup, jak v paměti nalézt proces, o který vám jde, a v něm pak nějakou konkrétní informaci (Piegdon hledal privátní klíče pro SSH server). A co víc, Piegdon ukázal ještě hrozivější věc – jak do paměti běžícího počítače zapsat svůj vlastní kód, včetně možnosti přepsat část existujícího kódu a získat plnou vládu nad systémem.

Zařízení, která jsou schopná provést tento útok, je poměrně hodně – DMA je součástí všech možných běžně používaných rozhraní včetně PCI. Firewire je zajímavé v tom, že 1) jsou pro něj snadno dostupná zařízení schopná útoku, 2) umožňuje hot-plug (tzn. bezpečné připojení k už běžícímu počítači), 3) specifikace přímo vyžaduje přítomnost zneužitelného DMA, a 4) DMA je skutečně často povoleno. Tudíž je poměrně snadné útok provést. Trocha Googlení snadno odhalí řadu snadno použitelných skriptů – zkuste třeba winlockpwn, nástroj pro prolomení lock-screenu Windows. Pokud máte ve svém počítači Firewire a umožníte útočníkovi fyzický přístup k běžícímu stroji, dokáže i obyčejný script-kiddie všechna vaše bezpečnostní opatření uvnitř počítače snadno překonat.

Komplexní obrana proti DMA útoku je poměrně problematická, protože DMA je skoro všudypřítomné a zablokovat úplně všechny možnosti nejspíš vůbec nejde. Existující návody se soustředí alespoň na zablokování Firewire, právě proto, že Firewire je tak snadno zneužitelné.

Na prvním místě je tu možnost zablokovat Firewire úplně. Zejména pokud nepoužíváte žádné Firewire zařízení, je tato možnost evidentní, problém je ale v tom, že se velmi špatně uskutečňuje: Dokonce i když váš počítač Firewire rozhraní vůbec nemá nebo je nezapojené (typicky u základní desky s Firewire konektorem na samostatné desce tuto desku vůbec nezapojíte), může útočník snadno získat Firewire přístup tím, že připojí nějaké hot-plug zařízení, které interface vytvoří – populární jsou v tomto směru zejména PCMCIA karty pro notebooky.

Většina běžných uživatelů proto nejspíše sáhne po Firewire Blockeru, který se nainstaluje jako ovladač na pozadí a pak sleduje, co se děje s počítačem. V okamžiku, kdy zjistí, že byl počítač uzamčen, tak Firewire zablokuje, po odemčení počítač zase Firewire povolí. To je velmi praktické v tom, že 1) to funguje automaticky, a 2) nezbavujete se podpory Firewire úplně, vypínáte ho jen v okamžiku, kdy byste ho stejně nemohli používat. Trochu otázkou je, jestli to skutečně funguje.

Druhou možností je odstranit z operačního systému podporu pro Firewire úplně. V zásadě stačí smazat soubory ovladače, konkrétně 1394bus.sys, 1394ohci.sys a ohci1394.sys (a nejspíš ještě sbp2port.sys). Prakticky narazíte na jisté potíže:

  • Windows XP tyto soubory nikde samostatně nemají, nacházejí se jako součást balíků driver.cab, sp2.cab a sp3.cab v adresáři Windows\Driver Cache\i386. Smazat je znamená balíky rozbalit, soubory vymazat a pak zbytek souborů zase zakomprimovat. Jednodušší cesta je v adresáři Windows\Inf smazat soubory začínající na 1394, které obsahují jen informace o ovladači (zejména o tom, pro která zařízení je určen a jak ho nainstalovat).

  • Windows 7 má soubory ovladače pěkně v Windows\System32\Drivers a brání se jejich smazání tím, že na to žádný běžný uživatel nemá práva. Ani jako administrátor si moc nepomůžete, musíte napřed převzít vlastnictví souboru, pak si přidat práva a teprve potom můžete soubory smazat. Na příkazové řádce tedy:

    cd /d C:\Windows\System32\Drivers
takeown /f 1394bus.sys
cacls 1394bus.sys /G Administrator:F /E
del 1394bus.sys

    To celé pak ještě dvakrát pro druhé dva soubory ovladače. Celé to bude fungovat pouze tehdy, pokud pracujete pod administrátorským účtem, a je velká neznámá, jak se to bude chovat se zapnutým UAC („User Account Control“, řízení uživatelských účtů).

    A když už budete ten ovladač mazat, tak nezapomeňte také na celý adresář C:\Windows\System32\DriverStore\FileRepository\1394.inf_amd64_neutral_0b11366838152a76, který obsahuje záložní kopii souborů a také .inf soubory. (Je možné, že se u vás bude adresář jmenovat jinak, ale snadno se dá najít hledáním souborů začínajících na 1394.)

  • Ostatní systémy jsem nezkoušel, lze ale očekávat, že pro ně bude fungovat jeden z předcházejících postupů, podle toho, jestli mají blíž k Windows XP nebo k Windows 7.

Informace týkající se těchto souborů v systémovém registru sice znějí hrůzostrašně (jsou umístěny ve větvích jako „CriticalDeviceDatabase“), ale Windows mi i bez nich docela dobře běží a nestěžují si. Ale pro jistotu jsem ty soubory stejně jen přejmenoval, co kdyby…

Třetí možností je využít postupů v Microsoftí Knowledge bázi ve článku Blocking the SBP-2 driver and Thunderbolt controllers to reduce 1394 DMA and Thunderbolt DMA threats to BitLocker. To je patrně nejčistší metoda, její délka mě ale od zkoušení odradila.

Cold-boot útoky

Útoky typu „cold-boot“ vycházejí z následující úvahy: Mám před sebou počítač, v jehož paměti jsou data, která mě zajímají. Počítač je chráněný tak, že se do té paměti prostě nemohu dostat. Co by se stalo, kdybych počítač restartoval?

Ukazuje se, že restart počítače řeší většinu problémů, které útočníkovi v získání obsahu paměti bránily: ukončí se operační systém i všechny ochranné mechanismy a místo toho se aktivuje BIOS, který je přímo dělaný k tomu, aby umožnil spustit uživatelský kód. A co je podstatné, typický restart neprovádí přepsání paměti – za normálních okolností se přepíše několik málo oblastí, které jsou potřeba pro start systému (BIOS například inicializuje tabulku vektorů od adresy nula nebo na adresu 0x7c00 nahraje první sektor bootovacího disku a vzápětí tento sektor spustí), ale velká většina paměti zůstane přesně v tom stavu, ve kterém byla před resetem. Stačí spustit nějaký mini-systém, který paměť zapíše na nějaké médium nebo třeba odešle po síti do jiného počítače.

A tady nastupuje slovo „cold“ z „cold-boot“: Pokud by proběhl obyčejný legitimní restart, tak by operační systém mohl paměť před svým vypnutím promazat. A když to neudělá operační systém, tak by to rozhodně měla udělat každá aplikace, která si v paměti udržuje citlivá data (např. BestCrypt Volume Encryption to podle svých autorů dělá, FreeOTFE také, TrueCrypt to dělá v omezené míře (všechny klíče kromě klíče k systémovému disku). Pokud ale počítač zrestartujeme tlačítkem, nemá žádný z programů šanci se o tom ani dozvědět, natož na to nějak zareagovat. Tudíž všechny informace zůstanou v paměti a útočník si je odtud může po restartu vytáhnout.

Obrana proti tomuto typu útoku je poměrně problematická, protože zabránit tvrdému resetu nebo na něj zareagovat zřejmě nejde. Musel by pomoci BIOS tím, že by napřed paměť smazal a teprve potom předal řízení uživatelskému operačnímu systému. Před lety to BIOSy základních desek uměly, volba se jmenovala „Perform Full POST“ nebo „Perform Memory Test On POST“ a podobně, postupně ale začala v zájmu co nejrychlejšího startu systému mizet a dnes mi není známa žádná moderní deska, která by tuto funkci měla. Existuje specifikace TCG Platform Reset Attack Mitigation Specification, což je specifikace řešící přesně tento útok, ale opět neznám základní desku, která by tuto specifikaci splňovala.

Velký zájem o cold-boot útoky vyvolali v roce 2008 pracovníci a studenti Univerzity v Princetonu, USA, ve své studii Lest We Remember: Cold Boot Attacks on Encryption Keys, ve které celou věc dotáhli ještě o krok dál: Zjistili, že navzdory všeobecnému očekávání si běžná paměť RAM udrží svůj obsah ještě nějakou dobu po vypnutí napájení (řádově sekundy až desítky sekund, podle typu paměti), že obsah se neztrácí okamžitě, ale postupně, přičemž tento proces je předvídatelný a lze rekonstruovat původní data, a v neposlední řadě že při značném podchlazení pamětí se doba „rozpadu“ podstatně zpomalí a paměť si udrží značnou část své informace i hodiny po vypnutí napájení.

Což ještě dále ztěžuje ochranu proti cold-boot útokům, protože teď už nepomůže ani použití základní desky se specifikací TCG – útočník prostě podchladí paměti, celý systém vypne, a pak paměti přesune do svého prostředí, kde mazání určitě zapnuté mít nebude.

V současné době je mi znám jediný spolehlivý způsob, jak citlivá data proti cold-boot útokům ochránit, a to je „citlivá data v paměti vůbec nemít“. Do jisté míry je to realizovatelné, jak si ukážeme níže u systému TRESOR, ale plně funkční to stále není.

Spuštění vlastního kódu

Jedním z nejsnáze proveditelných útoků proti operační paměti je útok vedený zevnitř systému – procesem, který už v systému běží. Každý běžící proces totiž už z principu musí mít aspoň nějaký přístup k operační paměti, a typicky i k dalším prostředkům systému. Jde jen o to, jak ten přístup rozšířit – moderní operační systémy (tzn. všechny za posledních přinejmenším 20 let) se snaží přidělovat procesům paměť tak, aby každý proces měl svůj vyhrazený blok paměti, se kterým si může dělat co chce, ale do kterého mu nebudou zasahovat ostatní procesy. Toto rozdělení pak operační systém vynucuje několika mechanismy, mimo jiné i na úrovni procesoru a jeho způsobu práce s pamětí (už od procesoru i80386; podrobnosti viz kapitola 3 „Protected-Mode Memory Management“ v Intel 64 and IA-32 Architectures Software Developer’s Manual, Volume 3).

Vložení svého kódu do cizího procesu

Teoreticky tedy proces nemůže ovlivňovat paměť ostatních procesů – ani do ní zapisovat, ani do ní psát. Praxe ovšem ukazuje, že přinejmenším ve Windows to jde docela snadno – samotný operační systém poskytuje prostředky, jak číst nebo zapisovat paměť cizího procesu na stejné úrovni oprávnění: útočník může zkusit přímo číst paměťový prostor cizího procesu funkcí ReadProcessMemory, spolehlivější je ale použít tzv. „injection“ technik a 1) alokovat si paměť v prostoru cizího procesu funkcí VirtualAllocEx, 2) pomocí WriteProcessMemory do této paměti zapsat svůj vlastní kód, a nakonec pomocí CreateRemoteThread tento kód spustit v kontextu cizího procesu, tzn. útočníkův kód se stane součástí cizího kódu se všemi právy a omezeními – tedy třeba právem číst a zapisovat paměť.

Samozřejmě, až tak úplně jednoduché to není – injektovaný kód musí být napsaný poměrně speciálním způsobem, aby byl plně realokovatelný (=schopný běžet na jakékoliv adrese v paměti), ale to není nic, co by se nedalo s trochou znalosti assembleru zvládnout. Případně lze použít už hotové knihovny, které špinavou práci udělají za vás (LoadLibrary replacement například jako jeden ze svých vedlejších efektů dokáže načíst DLL knihovnu a realokovat její kód na libovolnou adresu paměti; pokud chcete vysloveně user-friendly řešení, tak lze doporučit knihovnu EasyHook).

Druhá překážka spočívá v tom, že cízí thready tvořené pomocí CreateRemoteThread jsou antivirům a firewallům známy již delší dobu a některé jim i dokáží bránit. Naštěstí pro útočníka (a bohužel pro obránce) se ukazuje, že udělat tuto ochranu skutečně neprůstřelně je značně složité a navíc pak nejdou používat ani mnohé legitimní aplikace, takže pokud už se s ochranou setkáte, tak obvykle ve vypnutém stavu „protože mě příliš obtěžovalo, mít ji zapnutou“.

Třetí překážka je, že tímto způsobem lze přistupovat jen k procesům na stejné úrovni oprávnění. Tzn. pokud si spustím svoji záškodnickou aplikaci, tak mohu napadat další aplikace, ale nedostanu se tak k paměti ovladače TrueCryptu (který běží jako modul jádra, ne jako uživatelská aplikace). Ovšem doporučuji důsledně sledovat a instalovat bezpečnostní záplaty – k 29.9.2012 hlásí Microsoft Security Bulletins mezi 25 nejnovějšími záplatami (to mimochodem odpovídá období posledních tří měsíců) 9 slabin typu „Elevation of Privilege“, z toho čtyři přímo v jádře.

Malware

Samozřejmě není nezbytně nutné nořit se hned do assembleru. Proti vám to jistě fungovat nebude, ale drtivé většině uživatelů lze vlastní kód do počítače dostat standardními, časem prověřenými sociálně-technickými prostředky – nejlépe pomocí e-mailu („Tady technická podpora, nainstalujte si prosím okamžitě přiloženou aplikaci, opravuje vážně chyby ve vaší aplikaci. Pokud se vás systém zeptá, že to je potenciálně nebezpečné a jestli opravdu chcete opravu nainstalovat, odpovězte, že ano.“). Tímto způsobem do systému snadno dostanete přímo ovladač jádra, který si může vynutit přístup kamkoliv do paměti.

Útoky na běžící procesy

Další jednoduchý a funkční způsob, jak do počítače dostat svůj kód, spočívá ve využití zranitelnosti některého z běžících procesů. Typický způsob využívá útoků typu přetečení bufferu (buffer overflow), při kterém útočník pošle speciálně zkonstruovaný vstup, se kterým tvůrce programu nepočítal a neošetřil ho. To může v důsledku vést až ke spuštění útočníkova kódu v kontextu napadeného procesu. V tu chvíli se pak nabízí využití slabin operačního systému k navýšení oprávnění, viz výše.

Velkou výhodou je, že tento typ útoku jde často provést i na dálku (přes internet).

Prolomení Lock-screen

Na konec jsem si nechal otázku, jestli a jak lze prolomit lock-screen Windows (obrazovka, která se objeví po stisknutí kombinace WIN+L nebo vybráním volby Uzamknout tento počítač po stisku CTRL+ALT+DEL (myšleno prolomit jinak než pomocí Firewire, se kterém už víme, že to jde). Lock-screen je totiž běžně používaná ochrana u počítačů, u kterých uživatel nemůže sedět, ale zároveň je nechce nebo nemůže vypnout (typicky různé servery, ale také běžná pracovní stanice při odchodu na oběd). Pokud by během uživatelovy nepřítomnosti útočník k počítači přišel a nějakým způsobem lock-screen překonal, získal by do počítače stejný přístup jako přihlášený uživatel a tedy i možnost přímo spustit vlastní kód.

Jednoznačný závěr, jestli lock-screen představuje nebo nepředstavuje zranitelnost, neexistuje. Jednoznačně platí, že existují situace, kdy žádnou ochranu nepředstavuje: Pokud je uživatelské heslo nalepené na papírku na monitor, pokud je heslo snadno uhádnutelné (pozor, stačí heslo k některému z účtů na tomto počítači, nemusí to být nutně účet přihlášeného uživatele), tak lock-screen nechrání. Právě tak je lock-screen k ničemu, pokud není šifrovaný systémový disk počítače (útočník napřed restartuje počítač, to jde vždycky, pak spustí svůj operační systém z CD nebo klíčenky, vytvoří na disku nového uživatele nebo přepíše heslo existujícího uživatele, a nakonec znovu restartuje počítač a spustí nainstalovaný operační systém).

Otázka spíš je, jestli lze prolomit lock-screen jako takový. K tomu bohužel jednoznačná odpověď neexistuje – ta paranoidnější část internetové populace předpokládá, že existuje nějaké univerzální heslo, které zamknutý systém otevře, není mi ale známo, že by někdo takový kód demonstroval v praxi. Dokud k tomu nedojde a/nebo dokud se o vás nezačnou zajímat tajné služby USA, je myslím poměrně bezpečné spolehnout se na to, že lock-screen prolomit nejde.

TRESOR

Zajímavým nástrojem pro ochranu šifrovacích klíčů před paměťovými útoky představuje systém TRESOR („TRESOR Runs Encryption Securely Outside RAM“) pro operační systémy Linux. Vychází z předpokladu, že když nelze šifrovací klíč v operační paměti ochránit, tak bude nejlepší ho tam nedávat a uložit ho místo toho v nějakém místě, které ochránit jde. TRESOR pro tento účel používá ladící registry procesoru DR0 až DR3, u kterých z principu nelze provádět DMA útoky a u kterých je ověřeno, že se po restartu procesoru (ať už studeném nebo teplém) vynulují.

Myšlenka je to zajímavá, nesdílím ale nadšení autorů, že jde o řešení bezpečné. TRESOR sice dobře chrání proti některým typům útoků, zároveň ale má několik slabých míst vůči jiným typům útoků a/nebo vůči způsobům použití počítače:

  • TRESOR je extrémně zranitelný útoky zevnitř systému (viz kapitola Spuštění vlastního kódu): Celá jeho bezpečnost stojí a padá s tím, že se nikomu nepodaří přečíst obsah registrů, které obsahují šifrovací klíč. To lze rozumně zajistit u procesů běžících v kontextu uživatele, ale už ne u komponent jádra. Jakmile útočník nainstaluje jeden kernelový ovladač, je celý TRESOR zkompromitován. Situace je pak dokonce ještě horší než u běžných systémů s klíči v RAM, protože u TRESORu útočník přesně ví, kde klíč najde – nemusí více či méně složitě krokovat šifrovací subsystém a hledat, kde v paměti je klíč uložen.

  • Ladící registry nejsou v procesoru bezdůvodně, mají určitý účel. Pokud je TRESOR využije pro uložení klíče, logicky už tyto registry nelze použít k účelu původnímu, to jest k ladění, protože první zápis do ladících registrů by nenávratně přepsal klíč, který už by nešlo obnovit (protože v paměti nikde není). TRESOR se náhodnému přepsání brání tím, že modifikuje systémovou funkci ptrace tak, aby přístup k ladícím registrům odmítla. Nelze ale zabránit jinému modulu v režimu jádra, aby registry modifikoval přímo. Důsledek je zřejmý – uživatel si musí vybrat, jestli chce používat TRESOR nebo jestli chce používat ladící prostředek využívající debug registry, nesmí obě aplikace kombinovat. Dobrou zpravou ale je, že ani debuggery běžně nepoužívají ladící registry, takže to není až taková ztráta.

  • „Volně použitelné“ ladící registry jsou pouze čtyři, DR0 až DR3. Registry jsou 32 nebo 64bitové, podle režimu, ve kterém běží procesor, tzn. lze chránit maximálně dva 128bitové klíče AES. Což je právě akorát k tomu, aby šlo provozovat šifrování jednoho disku v šifrovacím režimu LRW nebo XTS nebo dvou disků v režimu CBC nebo CTR. Rozhodně ale nepřichází v úvahu, použít TRESOR pro sestavy, ve kterých je víc šifrovaných kontejnerů, leda že by se pro všechny použil stejný klíč (což ale nelze považovat za bezpečné). To bude možné až v nějaké budoucí verzi TRESORu, která bude mít diskové klíče uloženy v paměti, zašifrované hlavním klíčem, který bude uložen v ladících registrech. Pak půjde chránit v zásadě neomezené množství šifrovacích klíčů, ovšem za cenu drasticky zpomaleného přístupu k nim.

Pro uživatele je největším problémem TRESORu, že zatím není znám způsob, jak něco podobného zprovoznit pod Windows. Pokud to vůbec kdy půjde – kritickým místem je zejména ochrana před přepsáním ladících registrů (druhý bod výše) a možnost po dobu výpočtu šifry zablokovat context switch (přepnutí procesů při multitaskingu).

Návrh řešení pro AES

Definitivní řešení ochrany klíčů v paměti RAM podle mě nejde zajistit čistě softwarovými prostředky. Bude vyžadovat úpravu hardware, nejspíš nějakou další generaci instrukční sady AES-NI. Ta bude muset obsahovat speciální oblast paměti, která nebude dostupná mimo procesor, a pro uživatelský přístup k ní budou existovat pouze zapisovací instrukce (AESSETKEY nastaví klíč) a interně bude používána v implementaci rundovních instrukcí AESENC, AESENCLAST, AESDEC a AESDECLAST. Bude nutné zajistit, že jako parametr instrukcí vystupuje adresa v paměti klíčů a ne přímo rundovní klíč, a bude nutné přidat nové instrukce AESENCFIRST a AESDECFIRST, už jen proto, že před první rundou AES probíhá XOR otevřeného textu na prvních 128 bitů klíče (u kterého ale chceme záruku, že neopustí procesor).

Otázkou zůstává, jestli takové řešení bude ekonomicky schůdné a jestli bude odolné vůči útokům postranními kanály.

Závěr

Toto jsou veškeré informace, které k problematice útoků na paměť RAM mám. Pokud znáte nějaký další, velmi uvítám, když mě na něj upozorníte – nedělám si moc iluze, že bych se proti němu dokázal také ubránit, ale přinejmenším mě zajímá z teoretického hlediska. Právě tak uvítám upozornění v případě, že v tomto článku narazíte na nějakou chybnou informaci – velkou většinu popsaných útoků nedokážu prakticky vyzkoušet, takže je klidně možné, že mi nějaká dílčí věc unikla. Globální chyby tu doufám nejsou.

Z hlediska ochrany počítače se šifrovaným diskem před útoky bych doporučoval následující tři body, v tomto pořadí:

  1. Postarejte se o náležité zabezpečení operačního systému. Sledujte a instalujte jeho záplaty, používejte kvalitní aplikační firewall schopný zablokovat rizikové operace (jako je spouštění cizích threadů), a udělejte, co musíte, abyste maximálně omezili možnost napadení malwarem.

  2. Zablokujte firewire.

  3. Pokud to jen trochu půjde, podívejte se na zajištění fyzické bezpečnosti počítače. Přinejmenším zkuste najít základní desku, jejíž BIOS lze zaheslovat (snad všechny), umožňuje přepsat při startu celou paměť (žádný moderní neznám) a umožňuje vynutit jediné bootovací médium (bohužel už dnes asi takový neexistuje, všechny mě známé dovolí na nějakou klávesovou zkratku vybrat zdroj bootování). A kdyby někdo věděl o drátěné kleci, do které by šlo počítač na nějaký pořádný zámek zamknout, tak mi určitě dejte vědět.

Použitá literatura

  1. BÖCK, Benjamin. Firewire-based Physical Security Attacks on Windows 7, EFS and BitLocker [online]. 2009-08-13 [cit. 2012-09-29]. Dostupné na internetu: http://www.securityresearch.at/publications/windows7_firewire_physical_attacks.pdf
  2. BÖCK, Benjamin. FirewideBlocker: A Software Defense against Firewire-based Physical Security Attacks on Windows Systems [online]. 2009-08-12 [cit. 2012-09-29]. Dostupné na internetu: http://www.securityresearch.at/publications/windows_firewire_blocker.pdf
  3. DORNSEIF, Maximillian. 0wned by an iPod [online]. 2004-11-12 [cit. 2012-09-29]. Dostupné na internetu: http://md.hudora.de/presentations/#firewire-pacsec
  4. HERMANN, Uwe. Physical memory attacks via Firewire/DMA – Part 1: Overview and Mitigation [online]. 2008-08-16 [cit. 2012-09-29]. Dostupné na internetu: http://www.hermann-uwe.de/blog/physical-memory-attacks-via-firewire-dma-part-1-overview-and-mitigation
  5. MÜLLER, Tilo. FREILING, Felix C. DEWALD, Andreas. TRESOR Runs Encryption Securely Outside RAM [online]. 2011 [cit. 2012-09-29]. Dostupné na internetu: http://www1.informatik.uni-erlangen.de/tresorfiles/tresor.pdf
  6. PIEGDON, David Rasmus. Hackin in physically addressable memory: A proof of concept [online]. 2006-02-21 [cit. 2012-09-29]. Dostupné na internetu: http://eh2008.koeln.ccc.de/fahrplan/attachments/1068_SEAT1394-svn-r432-slides.pdf
  7. WITHERDEN, Freddie. Memory Forensics over the IEEE 1394 Interface [online]. 2010-09-07 [cit. 2012-09-29]. Dostupné na internetu: https://freddie.witherden.org/pages/ieee-1394-forensics.pdf
  8. kolektiv autorů. Lest We Remember: Cold Boot Attacks on Encryption Keys [online]. 2008-02-21 [cit. 2012-09-29]. Dostupné na internetu: http://citp.princeton.edu/pub/coldboot.pdf
  9. „metacortex88“. WinlockPWN [online]. 2008-03-21 [cit. 2012-09-29]. Dostupné na internetu: http://www.youtube.com/watch?v=t_T_GWmaGCk
  10. „Spazzarama“. EasyHook: The reinvention of Windows API Hooking [online]. 2009-03-08 [cit. 2012-09-29]. Dostupné na internetu: http://easyhook.codeplex.com/
  11. Intel Corporation. Intel 64 and IA-32 Architectures Software Developer’s Manual: Combined Volumes 1, 2A, 2B, 2C, 3A, 3B and 3C [online]. 2012-08 [cit. 2012-09-29]. Dostupné na internetu: http://download.intel.com/products/processor/manual/325462.pdf
  12. Microsoft. Blocking the SBP-2 driver and Thunderbolt controllers to reduce 1394 DMA and Thunderbolt DMA threats to BitLocker [online]. 2012-08-08 [cit. 2012-09-29]. Dostupné na internetu: http://support.microsoft.com/kb/2516445
  13. Microsoft. Step-By-Step Guide to Controlling Device Installation Using Group Policy [online]. 2007-06 [cit. 2012-09-29]. Dostupné na internetu: http://technet.microsoft.com/en-us/library/bb530324.aspx
  14. Microsoft. Microsoft Security Bulletins [online]. 2012-09-21 [cit. 2012-09-29]. Dostupné na internetu: http://technet.microsoft.com/en-us/security/bulletin
  15. OSDev Wiki. MBR (x86) [online]. 2012-03-05 [cit. 2012-09-29]. Dostupné na internetu: http://wiki.osdev.org/MBR_(x86)
  16. Security4all. Partytricks: a winlockpwn tutorial or how to log into a computer without the password [online]. 2008-03-29 [cit. 2012-09-29]. Dostupné na internetu: http://blog.security4all.be/2008/03/partytricks-winlockpwn-tutorial-or-how.html
  17. TrueCrypt.org. Unencrypted Data in RAM [online]. 2012-02-07 [cit. 2012-09-29]. Dostupné na internetu: http://www.truecrypt.org/docs/unencrypted-data-in-ram
  18. Trusted Computing Group. PC Client Work Group Plaform Attack Mitigation Specification, Version 1.0 [online]. 2008-05-15 [cit. 2012-09-29]. Dostupné na internetu: https://www.trustedcomputinggroup.org/resources/pc_client_work_group_platform_reset_attack_mitigation_specification_version_10/
  19. Wikipedia. Cold boot attack [online]. 2012-08-31 [cit. 2012-09-29]. Dostupné na internetu: http://en.wikipedia.org/wiki/Cold_boot_attack
  20. Wikipedia. DMA attack [online]. 2012-09-27 [cit. 2012-09-29]. Dostupné na internetu: http://en.wikipedia.org/wiki/DMA_attack

Podobné příspěvky:

Posted in bezpečnost by , 13. 10. 2012 08:42

7 Responses to “Útoky na operační paměť”

  1. avatar pepak napsal:
    12. 8. 2014 (06:02)

    Marek: Těžko. A to už z toho důvodu, že nemáme žádné spolehlivé důkazy o tom, že by TPM čip skutečně byl bezpečným úložištěm klíčů; zato už se vyskytly případy, které ukazují opak. Druhý problém by byl ve výkonu, který by nejspíš byl nepřijatelný.

  2. avatar Marek napsal:
    11. 8. 2014 (23:24)

    Co takhle pouzit TPM cip, pomohlo by to? To reseni s ladicimi registry zni dost strasidelne. Sorry za chybejici diakritiku.

    Marek.

  3. avatar pepak napsal:
    24. 6. 2014 (20:19)

    kurovec: Lokální kopie

  4. avatar kurovec napsal:
    22. 6. 2014 (15:58)

    Po softvéru „Firewire Blocker“ se slehla zem. Ani po intenzivním googlení se mi nepodařilo najít instalační soubor.

  5. avatar Kamil napsal:
    22. 10. 2012 (14:43)

    Krásný článek, díky za něj.

  6. avatar Alda napsal:
    15. 10. 2012 (00:21)

    Hned teď jsem šel vypnout firewire. Ale zjistil jsem, že ho mám dávno vypnuté :). Ale z trochu iného důvodu: kdysi jsem experimentoval s vypínáním zařízení kvůli spotřebě.

    PS: mohl bys zmínit USB Switchblade.

  7. avatar pepak napsal:
    14. 10. 2012 (16:08)

    Kdyby snad měl někdo pocit, že jde o pustou teorii a/nebo paranoiu, tak doporučuji mrknout na Inception.

Leave a Reply

Themocracy iconWordPress Themes

css.php