Vážná bezpečnostní chyba v BestCrypt Volume Encryption
Už několikrát jsem se na tomto blogu zabýval otázkami informační bezpečnosti a bezpečnostních rizik. Články jsou poměrně populární, ale z mého pohledu mají jednu chybu: vesměs jde o články, které jen shrnují zjištění jiných lidí. Včera ale konečně došlo k průlomu – podařilo se mi najít závažnou bezpečnostní chybu, o které nikdo jiný nevěděl. Týká se programu BestCrypt Volume Encryption (všech verzí) a za určitých okolností může vést k tomu, že útočník získá přístup k odpojeným šifrovaným diskům, aniž by znal heslo.
Kdo je v ohrožení
Každý, kdo používá BestCrypt Volume Encryption (libovolnou verzi až do 2.15 včetně) a jeho funkci „mount at boot time“ pro připojení datových disků při startu systému.
Dopad slabiny
Útočník může získat přístup k odpojenému svazku, pokud získa šifrovací klíč svazku systémového. To se mu může podařit docela snadno.
Obrana
V současné době existují dvě možnosti, jak se proti bezpečnostní slabině bránit:
1) Při každém odchodu od počítače tento úplně vypnout, nespokojit se s odpojením datových disků.
2) Nepoužívat (vypnout) funkci „mount at boot time“.
Momentálně s firmou Jetico spolupracuji na vytvoření opravy, která by umožnila využívání funkce „mount at boot time“, ale netrpěla popsanou chybou. Naštěstí není náprava nijak zvlášť složitá, takže očekávám, že opravená verze BCVE bude na světě co nevidět. Až to bude, tak sem samozřejmě napíšu výsledek.
Podrobnosti
Celé to začalo, když se uživatel IneedH3lp na fóru Smokey’s Security Forums (které je i oficiálním podpůrným fórem společnosti Jetico, která BCVE vyrání) bezelstně zeptal, jak funguje vlastnost „mount at boot time“ (zajišťuje, že se při startu systému kromě systémového svazku automaticky připojí i libovolné množství svazků datových). Odpověď Jetica zněla, cituji:
When you set option „Mount at boot time“ for a non-system volume, BCVE will ask you to enter password for the volume and then encrypt encryption key for the volume with encryption key used for boot/system volume. Then, as soon as you enter password at boot time all other encryption keys will be decrypted and the volumes will be mounted (although every of them may have different passwords).
Tedy v mém neumělém překladu:
Když na nesystémový svazek poprvé použijete funkci „připojit při bootu“, BCVE se zeptá na heslo k tomuto svazku a pak zašifruje šifrovací klíč svazku šifrovacím klíčem bootovacího svazku. Když potom při bootu vložíte heslo, budou všechny tyto šifrovací klíče dešifrovány a svazky budou připojeny (přestože každý může mít jiné heslo).
Zní to nevinně, ale je v tom skryt zásadní háček, který až dosud všem, včetně vývojářů, utekl:
Uvažujme tuto situaci: V počítači mám dva diskové svazky (volume) šifrované programem BCVE: Systémový, který obsahuje operační systém, a datový. Vzhledem k tomu, jak BCVE pracuje, má každý svazek jiný šifrovací klíč (a případně i jiné heslo, to ale není nezbytné).
Datový svazek chci mít přístupný hned po spuštění systému (jsem líný, nebo se z něj spouští nějaké služby, například), takže pro něj použiji funkci „mount at boot time“. BCVE se mě zeptá na heslo k datovému svazku, s jeho pomocí se dostane k šifrovacímu klíči, ten zašifruje klíčem k systémovému svazku a zapíše na disk.
Slabina spočívá v tom, že pokud se útočník dostane k šifrovacímu klíči systémového svazku, dokáže s jeho pomocí dešifrovat tyto uložené „mount at boot time“ klíče a s nimi pak dešifrovat datový svazek. A přitom vůbec nezáleží na tom, v jakém stavu ten datový svazek zrovna je – klidně může být odpojený, což je za normálních okolností synonymní s „bezpečný“. V případě BCVE ne.
Zásadní problém je, že k šifrovacímu klíči se útočník dostane docela snadno. Proč? Protože po celou dobu běhu operačního systému musí být systémový svazek dostupný. Aby byl jakýkoliv svazek dostupný, musí být v paměti přítomen jeho šifrovací klíč. No a ačkoliv se vesměs mlčky předpokládá, že v paměti je klíč relativně bezpečný, není to vůbec pravda – existuje celá řada způsobů, jak se s větší či menší námahou k takovému šifrovacímu klíči dostat. Asi nejjednodušší to je, pokud útočník získá fyzický přístup k počítači (což je vždycky problém, ale tady obzvlášť – pokud vás to zajímá, podívejte se na Cold boot attack nebo Firewire DMA Attack), ale jsou naprosto myslitelné i útoky vzdálené a čistě softwarové (pokud se vám podaří propašovat uživateli spustitelný kód, stačí využít vhodnou díru v operačním systému, která umožní eskalaci přístupových práv a následně zablokování bezpečnostních mechanismů BCVE a přečtení klíče).
Co ostatní programy?
Momentálně nemám žádné informace, jestli jsou i další šifrovací programy postižené touto chybou. Jediná určitá informace je, že TrueCrypt touto vadou netrpí vzhledem k tomu, že jeho obdoba funkce „mount at boot time“ funguje na úplně jiném principu (vychází z toho, že program zkusí pomocí jediného bootovacího hesla připojit všechny disky; tzn. zabezpečení datových disků není vázané na zabezpečení systémového disku, což je sice fajn, ale zrovna moc bezpečné to také není – když prozradíte heslo k jednomu disku, zpřístupní se útočníkovi všechny…).
A na závěr drobný šťouchanec k zastáncům open-source jakožto záruce bezpečnosti: Tohle je přesně ten typ bezpečnostních chyb, které ze zdrojového kódu nejsou nijak vidět, pokud je cíleně nehledáte. Ostatně, k odhalení slabiny jsem zdrojový kód nepotřeboval – stačilo se zeptat… (Ve skutečnosti se to dalo odvodit už jen z toho, jak se BCVE chová, položená otázka a odpověď jen soustředily pozornost.)
Takže potvrzeno, verze 2.15.01 to řeší. Je tam ale jedna zrada: Zatím není nikde zdokumentováno, že nestačí přeinstalovat BCVE novou verzí, ale je nezbytné rozšifrovat systémový disk a znovu ho zašifrovat. Tím se aktivuje nový loader, který už popsanou bezpečnostní chybou netrpí.
Verze 2.15.01, která dnes vyšla, prý problém řeší.
No tak například mu chybí tokeny nebo keyfiles, když pominu ptákoviny typu grafické okno pro zadávání hesla.
BCVE to řeší tak, že si vystačí s jediným sektorem. Skutečný boot-loader je uložen kdekoliv na disku, klidně i na nesouvisejících sektorech. Přístup k němu je řešen přes mapu sektorů (první sektor loaderu je na LBA 123, druhý sektor na LBA 124, třetí na 456…), kterou si ten jednoduchý kód v MBR dokáže přečíst a tak si z ní poskládat celý boot-loader. Pro uživatele to má tři výhody: Za prvé, velikost boot-loaderu není prakticky omezena, takže není potřeba ořezávat nějakou funkčnost. Za druhé, tím, že se boot-loader vejde do jednoho sektoru, se pro zašifrování partition dá použít jakýkoliv „volný“ sektor, typicky MBR nebo boot sektor, a není potřeba partition napřed měnit velikost, aby se udělalo místo na bootovací kód. Za třetí, BCVE je díky tomu kompatibilní i s programy, které žijí ve fantastické představě, že když není obsah první stopy disku definován, tak si s ním můžou dělat, co chtějí (např. za účelem ochrany proti kopírování).
Jak přesně to řeší DCPP nevím, ale vzhledem k tomu, že podporuje i ty grafické bootovací obrazovky, tak skoro jistě používá nějaký obdobný systém.
Ja myslel tohle: „5.1 – This version also reduced the minimum memory requirements for the TrueCrypt Boot Loader (AES) from 42 KB to 27 KB in Windows“, nevim kolik to zere pak, ale s 27KB je to schopny bootovat ze zasifrovanyho disku. Je to jenom boot-loader, ale co pak jeste chybi? Zajimalo by me taky jak je to s tou podstatne rozumnejsi strukturou (tvoje clanky o TC a BC jsem cetl).
Pozor, těch 30 KB je velikost na disku (ne v paměti) a platí jen pro TrueCrypt – ostatní programy mají díky podstatně rozumnější struktuře systémové části velikost prakticky neomezenou.
Ja bych rekl, ze to zere dost malo. S RAM je to tak, ze TrueCrypt (BestCrypt neznam, predpokladam ze tez) se v minimalni verzi (jen jedna sifra) vleze asi do 30kB, coz je potreba aby se dalo ze zasifrovanyho disku bootovat.
Pro moderni comp je sifrovani ne uplne ale skoro „zdarma“. Muj fake raid zvlada 200MB/s pri sekvencnim cteni, a to mi plne vytizi 2 jadra. Krome kopirovani souboru toto sotva kdy nastane. Vse se neustale zrychluje, ale CPU vic nez HD, tedy do budoucna neni co resit. Jinak plne potvrzuji co napsal Pepak.
Díky za vstřícnost a rychlou odpověď. Váš web jsem objevil poměrně nedávno, ale máte zajímavé nápady na témata a je vidět, že se tomu skutečně věnujete. Už mám v oblíbených:)
To je poměrně obtížná otázka. Teoreticky to jde přesně změřit nějakým vhodným benchmarkem, prakticky se to ale zásadně liší v různých situacích a tak jako tak žádný „vhodný“ benchmark neznám. Subjektivní dojem z provozu je takový, že:
* Výrazně je poznat kopírování větších souborů – využití procesoru vylétne nahoru, přenosové rychlosti padnou.
* Myslím si, že je šifrování dost poznat i na práci s mnoha malými soubory (spouštění programů napsaných v Javě, například). Stoprocentně to ale říct nemůžu, protože už pěkných pár let hrnu všechno, co se spouští častěji, na ramdisk.
* Naopak u běžné práce (např. když už mám spuštěný Open Office a začnu v něm otvírat a zpracovávat dokumenty, nebo když už spustím přehrávač médií a pustím v něm video) je prakticky nerozlišitelné, jestli je na šifrovaném nebo nešifrovaném disku.
Zjímalo by mě (nikdy jsem to nepoužíval, v podstatě nemám důvod), kolik takové šifrování zabírá systémových prostředků (cpu, ram, čas)? Děkuji
Ano.
Chapu to dobre, ze ta jednoducha oprava spociva v tom, ze se klic k datovymu disku zasifruje pomoci jinyho klice, taktez odvozenyho z uzivatelskyho hesla pro systemovy disk?
Ono by to slo lehce zobecnit tak, ze by mohla existovat libovolna M:N relace mezi hesly a disky, napr. zadanim hesla 1 odsifruju vsecko, zadanim hesla 2 odsifruju disky 1 a 3, …