SSL není bezpečné, ukazuje případ Comodo

4. 4. 2011
Doba čtení: 8 minut

Sdílet

Internetové vody rozvířil případ společnosti Comodo, jejíž napadení umožnilo do světa rozeslat podvržené SSL certifikáty. Ty mohou sloužit pro prakticky neodhalitelné man-in-the-middle útoky. Jeden bezpečnostní incident ukázal několik výrazných slabin celého SSL (HTTPS) a jeho principiálních děr.

Následující případ krásně ukázal, jak je možné z konkrétního vyvodit obecné. Jeden poměrně běžný bezpečnostní incident jedné firmy totiž ukázal na slabiny systému jako celku a dokázal, že i SSL má své velké principiální slabiny. Abychom pochopili celý problém, je třeba pochopit princip SSL (znalci prominou).

Šifruji, tedy jsem

Aby nebylo možné jednoduše na síti odposlouchávat běžící informace, je potřeba je před odesláním do prostoru zašifrovat. Dnes se k tomu nejčastěji používají asymetrické šifry, které zajišťují, že přenos šifrovacích klíčů nechráněnými kanály není žádným problémem. Veřejný klíč se veřejným kanálem dostane ke druhé straně a ta s ním šifruje komunikaci, která může být rozšifrována soukromým klíčem, který nikdy neopustil své původní místo.

Tento princip je dobře znám a jeho výhodou je především pohodlné předávání šifrovacích klíčů, které nevyžaduje žádná další bezpečnostní opatření. Všechny potřebné kroky k zahájení komunikace řeší SSL, ale kromě toho se zabývá také další podstatnou věcí – autentizací.

V praxi nám totiž nestačí „jen tak šifrovat“, ale musíme vědět, jestli jsme skutečně obdrželi veřejný klíč toho, s kým jsme si přáli komunikovat. Pokud bychom autentizaci nezajistili, kdokoliv na trase by se mohl vydávat za naši protistranu, podstrčit nám své klíče a my bychom zahájili komunikaci s ním. Pokud by dokázal během následujícího rozhovoru úspěšně předstírat, že je někdo jiný, dokázal by z nás získat všechny informace.

V praxi se takové útoky provádějí například na uživatele bank nebo e-mailových účtů. Útočník se postaví mezi obě strany a uživateli na vyžádání ukáže přihlašovací stránku, naprosto shodnou s tou, kterou používá banka. Uživatel do ní vloží své přihlašovací údaje a nevědomky je tak předá útočníkovi. Ten na pozadí naváže spojení se skutečnou bankou a klidně uživatele přihlásí a předá mu odpověď od banky. Uživatel tak vůbec nezaznamená, že se stalo něco podezřelého.

Všichni věříme jemu, on věří mě

Aby bylo možné autentizaci v SSL provádět, byl vymyšlen takzvaný řetězec důvěry. Zjednodušeně jde o to, že byly stanoveny jisté „certifikační autority“, kterým uživatelé věří. Tyto autority mají mandát v ověřování dalších subjektů a přidělování certifikátů, které slouží jako doklad pravosti. Vlastně říkají „já, autorita, potvrzuji, že tento subjekt je pravý“.

Poměrně dobře se dají certifikáty přirovnat k občanským průkazům. V takové představě pak český stát vystupuje jako certifikační autorita, která na základě ověření vystavuje doklad o pravosti. Pokud nám někdo takový doklad předloží, my jej považujeme za pravý, protože je vydaný autoritou, které důvěřujeme (teoreticky). Samozřejmě si takový doklad může v zásadě vyrobit kdokoliv, ale tím pro nás tento doklad ztratí na důvěryhodnosti, protože jej nevystaví důvěryhodná autorita.

Přesně tímto způsobem funguje i SSL. Každá aplikace má k dispozici seznam „kořenových certifikátů“ – tedy certifikátů certifikačních autorit. Ty v nich potvrzují samy sebe a aplikace ve vašem operačním systému automaticky těmto autoritám věří. Pokud se setkají s jakýmkoliv dalším certifikátem, zkontrolují, zda jej vystavil někdo, komu věří (jehož kořenový certifikát je k dispozici a označen jako důvěryhodný). Pokud ano, je zkoumaný certifikát bez řečí přijat, protistrana je autentizovaná a může se začít komunikovat.

Aby vůbec bylo možné takový certifikát vystavit, žadatel se musí autoritě prokázat reálnými dokumenty, které dokazují jeho pravost. Obvykle je třeba odeslat notářsky ověřené dokumenty, u vyšších typů certifikátů je prověřování ještě složitější. Platí tedy: pokud nedokážeš, že jsi pravý, my ti potvrzení (certifikát) nevystavíme. Získat falešný certifikát je tak poměrně obtížné (i když ne nemožné).

Součástí certifikátu jsou navíc další informace o platnosti, o vystaviteli, o certifikovaném subjektu a podobně. Poměrně snadno je tak možné ověřit, kdo příslušné potvrzení vydal a na „čí jméno“ je vystaveno. Uživatel se tak může v případě podezření snadno ujistit, že je vše v pořádku, šifrování probíhá a protistrana je tím, za koho se vydává.

Případný podvodník si sice může vytvořit svůj vlastní certifikát, který si sám podepíše (self-signed), ale už není schopen si vytvořit certifikát potvrzený důvěryhodnou autoritou. Tím je zajištěna bezpečnost celé komunikace včetně autentizace. Na tomto prvku stojí celé SSL.

Případ Comodo

Bohužel se ukazuje, že tento princip stojí na jediném pilíři – certifikačních autoritách. Pokud totiž některá z nich začne vydávat platné certifikáty někomu, komu by neměla, celý výše popsaný systém zkolabuje. Vše závisí na tom, zda mechanismy autority fungují správně, zda neexistují žádné bezpečnostní mezery a zda není možné zneužít žádnou technickou chybu.

Autority tak vytvářejí kritický prvek selhání (single point of failure), protože se jednoduše doufá v to, že jsou nenapadnutelné a vše v nich funguje zcela správně. Tedy, že nevystavují certifikáty někomu cizímu. A přesně to společnost Comodo udělala – devětkrát.

Firma 15. března přiznala, že došlo k vážnému narušení bezpečnosti. Přes účet jednoho z partnerů (InstantSSL.it, později byli kompromitováni další dva) byl založen účet nový a na ten bylo vystaveno devět neověřených certifikátů. Celkem se jedná o certifikáty vystavené na sedm domén:

  • mail.google.com
  • login.live.com
  • www.google.com
  • login.yahoo.com (tři certifikáty)
  • login.skype.com
  • addons.mozilla.org
  • global trustee

Útoky přišly z různých IP adres, ale především z Íránu (IP adresa 212.95.136.18), útočník byl velmi dobře připravený, rychle napadl systém, rychle vytvořil potřebné certifikáty a zmizel. Útočník požádal celkem o devět certifikátů, ale Comodo netuší, zda si všechny vyzvedl. Jisté je, že certifikát na login.yahoo.com byl v praxi použit.

Později se k útoku přihlásil člověk pod přezdívkou ComodoHacker, který na Pastebin odeslal důkazy o svém činu. Kromě jiného vylíčil princip útoku, který byl velmi jednoduchý – podařilo se mu uhádnout heslo zmíněného partnera firmy Comodo. Uživatelské jméno bylo gtadmin a heslo globaltrust. Školácká chyba na takto kritickém místě mu umožnila vstup do systému.

Na serveru pak našel knihovnu, která se starala o vyřizování žádostí u Comodo a pomocí dekompilace z ní získal příslušná hesla k účtům. Pak už mu nic nebránilo v odeslání vlastních žádostí o certifikáty. Pravost útočníka je předmětem debat, podstatné ale je, že se „něco podobného“ zcela jistě stalo.

Útočník se tak může za pomocí certifikátů vydávat za kterýkoliv ze zmíněných sedmi serverů a počítač oběti to nepozná. I přes použití šifrování tak bude veškerá komunikace pro útočníka otevřená a on bude moci dešifrovat uživatelská jména, hesla, ale i obsah přenášených informací. Skrze podvržený server addons.mozilla.org je možné například nainstalovat vlastní rozšíření obsahující zákeřný kód. Možnosti zneužití jsou velmi široké.

Revokace neplatných certifikátů

SSL je poměrně chytře navržený systém, který počítá i s takovou alternativou. Umí se vyrovnat s takto fatálním únikem pomocí velmi jednoduchého mechanismu. Každý kořenový certifikát zabudovaný do operačního systému nebo třeba webového prohlížeče obsahuje URL, na které je k nalezení seznam revokovaných certifikátů (Certificate Revocation List, CLR). Na tento seznam jsou umístěny certifikáty, které autorita považuje za neplatné a klienti už jej nemají nadále používat.

Každá aplikace, která provádí ověření přijatého certifikátů, je povinna si tento seznam stáhnout a prověřit, zda na něm zkoumaný certifikát není. Pokud ano, je certifikát automaticky odmítnut a už nikdy nebude považován za platný. Až potud se může zdát, že revokační mechanismus je dobře navržený a velmi účinný, ale má jednu výraznou slabinu.

Pokud totiž při ověření dostane počítač informaci o tom, že server s revokačním seznamem je nedostupný (500 interní chyba), nezareaguje dočasným zablokováním certifikátů, ale naopak kontrolu ukončí a považuje certifikáty automaticky za platné. Pokud může útočník manipulovat na síti s jedním serverem a vydávat se za něj, může stejně tak pro uživatele vyřadit z provozu jiný server a zabránit tak zneplatnění svého těžce nabytého certifikátu.

Toto je samozřejmě známý fakt a tvůrci nejohroženějšího software – webových prohlížečů – se s klasickou revokací samozřejmě nespokojili a nasadili vlastní protiopatření. Vývojáři Firefoxu 4 vydali neplánovanou RC verzi, která natvrdo zablokovala zmíněné certifikáty a podobně postupoval také Google s Chrome. Pokud by se některý z falešných certifikátů objevil, prohlížeč jej automaticky podle sériového čísla zamítne. Také Microsoft už vydal potřebnou záplatu pro všechny podporované operační systémy. Podstatně horší to ale bude například u mobilních zařízení, kde často není dostupná automatická a jednoduchá aktualizace a vše je ponecháno na uživateli, který by proto měl aktualizovat systém ve svém přístroji sám.

Když je důvěra zrazena

Není to poprvé, kdy se objevil podobný problém s vystavováním certifikátů. V roce 2001 se například neznámému útočníkovi podařilo z VeriSignu vylákat certifikáty vydané na Microsoft a mohl s nimi pak podepisovat například podvržené aplikace. Objevily se i další nedostatky v řetězci důvěry, které ohrožují bezpečnost. Tento útok je ovšem svou podstatou dalekosáhlejší než ty předchozí. Kvůli problémům s revokací se budeme s jeho následky setkávat ještě dlouhou dobu.

Ukazuje se tak, že absolutní předání důvěry certifikačním autoritám není bezpečné a vytváří řadu potenciálních bodů selhání. V takové situaci pak stačí prolomit jediný z nich a celý systém naprosto selhává. Vzniká tak situace, kdy celý internet bezmezně důvěřuje několika firmám, jejichž bezpečnost může být kdykoliv narušena.

ict ve školství 24

Pravděpodobně tak vznikne tlak na nahrazení stávajícího absolutistického systému důvěry něčím méně závislým na jednotlivých bodech. Do úvahy tak přichází web of trust známý z PGP/GPG nebo třeba umisťování certifikátů do DNS záznamů, které komplikuje útok na konkrétní domény. Další možností jsou krátkodobé certifikáty, které bude potřeba pravidelně na serverech automaticky obměňovat. Pokud dojde k podobnému incidentu, uživatelský počítač bude automaticky upozorněn na problém.

Tento případ ukazuje, že situace není dlouhodobě udržitelná a je potřeba ji změnit. I to však bude běh na dlouhou trať a objeví se řada technických překážek. Zároveň se budou autority bránit jakékoliv změně, protože aktuální stav jim přináší nemalé zisky z jejich podnikání a narušení „monopolu na důvěru“ by pro ně znamenalo pochopitelnou ztrátu.

Odkazy

Autor článku

Petr Krčmář pracuje jako šéfredaktor serveru Root.cz. Studoval počítače a média, takže je rozpolcen mezi dva obory. Snaží se dělat obojí, jak nejlépe umí.