V sobotu 26. května se v Praze na FIT ČVUT konal další ročník konference Cryptofest. Opět na něm zazněla řada aktuálních témat z oblasti bezpečnosti a kryptografie. Projděte s námi to nejpodstatnější, co zaznělo.
Ondřej Caletka: plně šifrovaný disk na moderním systému
Přednáška se věnovala fyzické bezpečnosti, tedy bezpečnosti dat vypnutého počítače. Když je počítač zapnutý a útočník se k němu dostane, může si data přečíst a šifrování vám nepomůže. Zároveň nesupluje šifrování kritických uživatelských dat, například privátních klíčů a hesel. Například klíče k SSH nebo GPG. Musíte si uvědomit, že k souborům na disku má přístup každá vaše aplikace, pokud nepoužíváte pokročilé řízení práv."
Šifrování naopak chrání proti odcizení zařízení nebo vyčtení dat například při servisním zásahu. V tomto případě stačí obyčejné šifrování důležitých souborů. Existují další podobné útoky, například cold-boot nebo evil-maid. Zlá pokojská přijde v hotelu k vašemu počítači a nahradí nešifrovanou část operačního systému svou vlastní a když se pak přihlásíte, pošlete jí své klíče.
Šifrování sebou nese dopad na výkon, otázkou je, jak velký vliv můžeme skutečně pozorovat. Dnešní moderní procesory mají možnost šifrovat hardwarově, takže dopady nejsou zase tak významné. Šifrovat je možné na úrovni souborů nebo blokového zařízení, musíme také rozhodnout, zda šifrujeme jen uživatelská data nebo celý disk.
Bezpečný start počítače začíná u UEFI, který je chytřejší než starý BIOS a umí například číst souborový systém FAT. Potřebuje EFI System Partition, takže alespoň jeden oddíl musí být nešifrovaný. Zbytek pak zašifrovat můžeme a k tomu směřuje takhle přednáška. Pokud má počítač UEFI, umí i SecureBoot, takže je možné podepsat zavaděč a jiný pak počítač nespustí.
Přednáška se pak zabývala šifrováním celého disku, což vyžaduje zadání hesla při bootu. Počítač ale pak nelze nastartovat vzdáleně a odemknout ho přes síť. Je možné to ale udělat pomocí initramfs. Ale vyžaduje to nešifrovaný kernel i initramfs, tomu jsem se ale chtěl vyhnout.
Řešení se skrývá v moderním zavaděči GRUB, který dnes umí pracovat se šifrovanými oddíly, rozumí Btrfs a LVM. Všechno je tedy připraveno, jen bootloader musí být nešifrovaný na EFI oddílu. Ale pokud použijeme Secure Boot, máme ho podepsaný a nikdo ho nemůže změnit. Musíme už jen vyřešit jeden problém: zavaděč neumí nijak předat jádru klíč k disku, takže se jádro ptá na stejné heslo uživatele znovu. To by bylo velmi nepraktické, proto můžeme do šifrovaného initramfs uložit šifrovací klíč, který tak jádro při svém startu má k dispozici a může bez dalšího dotazu nastartovat."
Použité řešení používá šifrovaný disk, ve kterém je LVM s oddíly pro swap a Btrfs. V Btrfs si pak můžu vytvářet subvolumes pro další linuxové distribuce. Mám vedle sebe Gentoo a Fedoru, oba systémy sdílejí stejnou strukturu disku a funguje to krásně. Ondřej Caletka slíbil, že o celém procesu napíše podrobný článek, který bude sloužit jako kuchařka.
Marcus Meissner: ohlédnutí za bezpečnostními událostmi loňského roku
Bezpečnostní tým v SUSE se zabývá především reakcemi na hlášené bezpečnostní incidenty, koordinuje činnosti od začátku do konce – tedy opravu balíčků, kontrolu zdrojových kódů nebo testování QA. Všechna hlášení procházejí našim veřejným systémem, najdete tam popis, odkazy, patche i informaci o tom, kdo problém řeší.
Bezpečnostní problémy jsou vkládány do ticketovacího systému SMASH, jsou roztříděny podle závažnosti a podle toho je rozhodnuto, zda se jimi bude tým zabývat okamžitě nebo je naplánováno, kdy se tak stane. Dříve jsme měli výrazně menší množství otevřených bezpečnostních bugů, v roce 2013 ale začalo jejich množství růst až na dnešních průměrných 30 za týden. Důvodem je, že se Linuxem zabývá více odborníků a za velkým nárůstem stojí také automatické testování.
Tým se stará také o aktualizaci informací u jednotlivých hlášeních, přidává důležitá metadata, kontroluje funkčnost patchů a předává výsledné balíčky QA týmu. K uživatelům se pak samozřejmě dostávají samotné balíčky s aktualizacemi, dále pak e-mailové notifikace o aktualizacích, CVRF data a také automaticky generovaná data z CVE a OVAL. Vytváříme data ve formátu čitelném pro uživatele, ale také pro strojové zpracovávání. Umožňuje vám to pak používat nástroje, které automatizovaně zjistí, zda je váš systém konkrétní chybou zasažen a musíte záplatovat.
V roce 2017 bylo zpracováno 3203 CVE, na jejich základě pak bylo otevřeno 2529 bugů. Z toho 266 jich bylo v linuxovém jádře, 261 v balíčcích ImageMagick a GraphicsMagic, 117 v prohlížeči Firefox, 58 v balíčcích tiff a 42 ve Wiresharku. Na tyto balíčky je zaměřeno hodně pozornosti, protože jsou hodně vidět. Proto se v nich také často hledají chyby. Výsledkem celého procesu bylo 1021 opravených balíků pro SLE a 626 pro openSUSE. Celkem jsme v loňském roce opravili 2329 CVE.
Některé chyby vyčnívají nad ostatními a vyžadují velmi rychlou reakci: Heartbleed, Shellshock, Logjam, Meltdown a další. Spojuje je to, že je velmi snadné je zneužít a obtížné je opravit. Vyžadují více komunikace s uživateli a podrobnější dokumentaci. Konkrétně Meltdown vyžadoval velmi rozsáhlé změny v jádře a Spectre je úplně nová třída chyb, která má různé varianty s různými způsoby opravy. Stále ještě komunikujeme s upstreamem a pracujeme na různých opravách.
Vedle reaktivní bezpečnosti se tým zabývá také tou proaktivní a používá automatické kontroly během sestavování systému. Hlídají se binárky se setuid, služby používající DBUS, pravidla pro Polkit, správná nastavení PAM a podobně. Postupně se ladí také parametry pro kompilátor, který také dokáže nasadit ochrany proti některým typům chyb. Většina této práce pro SLE se dělá také pro openSUSE.
TLS je kryptografický protokol, který dovoluje sestavit zabezpečený kanál přes internet. Je velmi rozšířený a používá se v mnoha oblastech: HTTP, e-mail, VPN, VoIP a dalších. Používá asymetrickou krytpografii a Public Key Infrastructure. Uživateli nabízí autentikaci, soukromí a integritu. Všechny modifikace mohou být detekovány a spojení může být ukončeno.
Od roku 1999 tu máme TLS 1.0, v roce 2006 pak přišla verze 1.1 a o dva roky později TLS 1.2. Letos prochází standardizací TLS 1.3. Starší verze protokolu, označované ještě jako SSL, jsou považovány za nebezpečné a neměly by se používat. Používají slabé hašovací funkce pro MAC a chybí jim některé funkce týkající se bezpečnosti a rozšiřitelnosti. Verze 3.0 zabil pes jménem POODLE, který ukázal exploit CBC módu."
Proti TLS je možné také provádět některé typy útoků, například na CBC, Mac-Then-Encrypt, kompresi, slabé šifrovací algoritmy a podobně. Existují i implementační bugy, které souvisí s tím, že se protokol stal v průběhu let velmi komplikovaným. Díky těmto chybám existují útoky jako Heartbleed, BERserk a další. Problémy shrnují RFC 7457 a RFC 7525.
Vývoj TLS 1.3 začal před čtyřmi lety a zabral delší čas, než se předpokládalo. Celý vývoj probíhá velmi otevřeně. Specifikace protokolu je dostupná na GitHubu. Hlavními cíli jsou čistota, bezpečnost, soukromí, výkon a kontinuita. Vývojáři se snaží, aby bylo možné nový protokol bez problémů backportovat, protože existují nasazení, kde je aktualizace velký problém.
Celý protokol byl zjednodušen, což se dotklo například handshake, obnovení spojení bylo spojeno s PSK a byly odstraněny staré šifry a některé překonané mechanismy. Tím se podařilo zabránit celé řadě chyb, na které byly náchylné starší verze protokolu.
Velkou změnou také je, že autentizace a výměna klíčů jsou oddělené. Pro výměnu klíčů se používá výhradně kryptografie eliptických křivek, pro autentizaci zůstala také RSA. Komunikace pak probíhá pomocí symetrické kryptografie s algoritmy AES nebo ChaCha. TLS 1.3 posiluje také koncept Perfect Forward Secrecy, všechny šifry používají výměnu klíčů s DHE, stejně jako PSK-ECDHE. Používáme pre-shared key zároveň s Diffie-Hellmanem.
Nový standard se snaží udržet zpětnou kompatibilitu kvůli různým middleboxům, které z bezpečnostních důvodů zkoumají obsah TLS spojení. Ty novou verzi neznají, protože často nebývají dobře spravované a aktualizované. Řešením je zamaskovat TLS 1.3 tak, aby vypadal jako TLS 1.2. Informace o verzi protokolu, PSK a KeyShare jsou nyní součástí rozšíření.
V současné době se ukončuje standardizace protokolu, Draft 28 byl už přijat a brzy se z něj stane RFC. Důležité knihovny už se na příchod připravuje: OpenSSL připravuje verzi 1.1.1, GnuTLS 3.6.3, NSS od Mozilly už protokol podporuje, Secure Transport od Apple také, SChannel od Microsoftu zatím ne. Podobně jsou na tom implementace v prohlížečích: Chrome a Firefox už TLS 1.3 podporují, Edge zatím ne.
Panos Georgiadis: bezpečnost kontejnerů
Kontejnery nejsou nová věc, měli jsme tu jails, chroot a LXC. Docker k tomu jen dodal jednoduché utility a ekosystém, takže už nemusíte číst hromady dokumentace a trávit noci nad kafem a pivem, abyste si kontejnery zprovoznili. Dnes to dokáže každý, což je také důvod, proč všichni kopírují neznámé příkazy do terminálu a pak skončí s hesly na GitHubu.
Spousta lidí se o kontejnery zajímá, ale ne o to, jak fungují uvnitř. Jdou slepě na Docker Hub, kde si stáhnou neznámý image a spustí ho. Uvnitř je zabalený celý souborový systém, ve kterém jsou utility a knihovny, které mají svoje verze a bezpečnostní chyby. Rozdíl proti plné virtualizaci je v tom, že kontejnery sdílejí společné jádro a mohou být výrazně menší.
Provoz neznámých kontejnerů je problematický v tom, že je možné na nich zneužít bezpečnostní chybu a pak zaútočit na hostitelské jádro. Na Docker Hub může nahrát kdokoliv cokoliv, takže vám může doručit třeba miner, který na vašem počítači bude těžit kryptoměny. Proto jsou na Docker Hubu nyní zobrazeny také informace o bezpečnosti jednotlivých obrazů.
Řada společností dnes spouští kontejnery v Kuberenetes. Je to velmi užitečná platforma, ale je potřeba ji dobře zabezpečit. Pokud se vám někdo dostane do infrastruktury, máte velký problém a bezpečnost kontejnerů nezachráníte. Konkrétně byl zmíněn incident v jedné bance, která Kubernetes používala bez zabezpečeného účtu správce. Jak se to stalo? Rozhodli se nezaměstnat dinosaury, kteří rozumí unixu, ale nabrali nové progresivní lidi, kteří přece všechno ví. Podle YouTube se to dá nastavit za chvíli.
Z hlediska bezpečnosti jsou zajímavé takzvané Kata kontejnery, které hodně prosazuje Intel. Jde o běh kontejneru ve virtualizovaném prostředí. Bere si to nejlepší z obou světů: flexibilitu a oddělení od zbytku systému. Dalším zajímavým směrem jsou takzvané rootless kontejnery, kdy se uvnitř kontejneru nepoužívá uživatel root a software běží pod právy běžného uživatele.
Uživatelé kontejnerů se vůbec nezabývají bezpečností. Když připravují kontejnery a spouštějí na nich testy, vůbec nepíší testy zabývající se bezpečností. Řešením je zabývat se sebevzděláním v oblasti kontejnerů, aby jejich uživatelé věděli, jak vlastně fungují.
Karel Kočí vyvíjí v projektu Turris aktualizační software, který zajišťuje automatické stahování nových verzí balíčků. Vypadá to jako jednoduchá úloha, ale je tam spousta problémů, jak bezpečně doručit balíček, aby nemohl být podvržen někým, kdo vám chce doručit malware.
Balíček obsahuje meta informace, samotné soubory a haše jednotlivých souborů. Balíčky jsou pak uloženy v repozitářích, které obsahují haše balíčků a jejich meta informace. V repozitáři může pak být řada dalších doplňkových informací.
Prvním zmíněným způsobem útoku je podvržení repozitářů s balíčky. Útočník si vytvoří vlastní server s upravenými balíčky a poté oběti kompromituje připojení k internetu. Variant je celá řada, je možné ovlivnit DNS server oběti, zaútočit na router a změnit nastavení a podobně. Obranou je podpis všech balíčků a ověření pomocí před-distribuovaného klíče.
Další možností je podvržení starší verze repozitářů, které dříve distributor balíčku běžným způsobem nainstaloval. Můžete v něm nabídnout starší verze balíčků, které obsahují známé zranitelnosti. Proti tomu částečně chrání to, že většina distribucí odmítá balíček downgradovat. Ale co aktualizace systému, na který dlouho nikdo nesahal? Nebo instalace nového balíčku? Od podvrženého serveru pak můžete skutečně dostat novější verzi, ale ne tu úplně nejnovější. Ochranou je zajistit ověření repozitáře pomocí TLS certifikátu.
Útočník má ale stále možnost spustit si vlastní repozitář na jiném doménovém jméně a pro něj získat certifikát. Můžete omezit počet důvěryhodných certifikátů a ponechat jen několik vybraných autorit. My jsme se ale u Turrisu spálili, vybrali jsme dvě běžné autority a třetí vlastní jako fallback. Běžíme nakonec na té vlastní, protože ty ostatní selhaly.
Zaútočit je možné na DNS server a tím útočník uživatele přesměruje na vlastní IP adresu. Řešení existuje, jmenuje se DNSSEC a je škoda, že je po světě tak málo rozšířené. Správce domény může DNS záznamy podepsat a klient pak může ověřit, že získané údaje jsou pravdivé. Problém je, že o tom uživatelé často neví a nasadit to musí správce sítě. Tohle bohužel nemůže vynutit aplikace.
Je možné jít ještě na nižší úroveň a pomocí BGP leaku ovlivnit směrování na danou IP adresu. Pokud nabídnete kratší cestu, routery k vám budou ochotně posílat provoz. Uživatel nemá šanci nic poznat. Opět si může stáhnout balíček z podvrženého repozitáře se staršími balíky. Ochranou je znovu digitální podpis, konkrétně pomocí protokolu RPKI. Opět to ale nemůže vynutit uživatel a záleží to na provozovateli sítě. Ovšem výrazně to komplikuje útok.
Platí, že by uživatel měl udržovat svůj software vždy aktuální. Měli byste také zajistit, že váš poskytovatel nebo vy sami ověřujete DNSSEC podpisy."