Hlavní navigace

SSL divočina aneb jak se chovají „důvěryhodné“ CA

20. 12. 2011
Doba čtení: 6 minut

Sdílet

Uplynulý rok byl bohatý na bezpečnostní incidenty týkající se certifikačních autorit. Kompromitace, slabé klíče, nerevokovatelné certifikáty. Situace vedla k návrhu nových nástrojů a protokolů na pozitivní straně a k ohrožení mnoha lidí na negativní straně. Praktický význam slova „důvěryhodný“ se posunul jinam.

Napadené certifikační autority

Rok 2011 byl bohatý na medializované případy napadených certifikačních autorit. Mezi obecně známé patří Comodo, DigiNotar, Gemnet, StartCom a GlobalSign. V posledních třech uvedených případech nedošlo údajně k vydání podvodných certifikátů.

Podle záznamů v CRL dojdeme k jiným číslům. Při revokaci certifikátu je možné uvést důvod revokace, jedním z důvodů je „CA Compromise“. Peter Eckersley spočítal CA, které uváděly kompromitaci organizace jako důvod k revokaci. Podle jeho dat z října počet vychází na čtyři CA kompromitované od června a 14 celkově. Podle stejné metodiky jsme v listopadu získali výsledky v následující tabulce:

Kompromitované CA podle CRL
od června 2011 rok 2011 celkově
důvěryhodné 3 6 14
„nedůvěryhodné“ 2 2 2

Výsledek je téměř totožný, rozdíl jedné CA je způsoben buď opomenutím nebo rozdílnou „deduplikací“ (mapování certifikátů na skutečné organizace). V řádku „důvěryhodné“ je počet CA, které se „řetězí“ k některé autoritě důvěrované softwarem firem Mozilla nebo Microsoft. Za „nedůvěryhodné“ jsou pak považovány ty ostatní. Jedna z uvedených „nedůvěryhodných“ se pravděpodobně brzy stane „důvěryhodnou“. Jména CA záměrně neuvádím.

Tato čísla jsou ale spodní odhad – případy, kdy CA přiznaly důvod a věděly, jak ho uvést v CRL. Část „věděly, jak ho uvést“ není vtip, operátoři mnoha CA to prý nevědí a je to jeden z důvodů, proč existuje tolik CRL bez uvedeného důvodu revokace a nebo je jako důvod uveden „NULL“. Celkový počet je ovlivněn faktem, že staré revokace se mažou z CRL – především kvůli tomu, aby jejich velikost příliš nerostla.

Například v případě GlobalSign jejich zpráva uvádí, že certifikát pro ‚www.globalsig­n.com‘ byl revokován. V CRL není uveden důvod. Ve stejném období byla revokována další asi desítka certifikátů patřících přímo serverům GlobalSignu (zpráva o tom ale mlčí). V CRL se rovněž důvod neuvádí.

A teď si ještě představte CA, kam přijde exekutor a zabaví HSM s podepisovacími klíči. Podobný případ se skutečně stal a pak už nezbyl skutečně nikdo se schopností vydat CRL. Jméno CA je bohužel tajné (člověk znalý případu podepsal NDA).

Malware podepsán faktorizovanými klíči

Existence mnoha platných certifikátů s 512bitovými klíči vydaných důvěryhodnými CA je dlouho známá, ale ještě potrvá, než je začne software odmítat jako slabé. Po prvních kouscích malware podepsaného ukradenými klíči (Stuxnet, Duqu) přišla větší vlna.

Pro všechny podpisy byly použity certifikáty s 512bitovými RSA klíči od různých CA, z čehož se usuzuje, že klíče byly nejspíš faktorizovány. Těžko říct, proč si útočníci vybrali faktorizaci, když mohli koupit ukradené klíče. Možná vyšla faktorizace levněji nebo zanechala méně stop po pachatelích. Cena „okamžité“ faktorizace 512-bit RSA klíče na EC2 cloudu vyjde pod 150 dolarů.

Ne každý certifikát je použitelný na podepisování kódu. Schopnost závisí na X.509v3 rozšířeních Key Usage (KU) a Extended Key Usage (EKU). Nepřítomnost rozšíření se interpretuje „všechno je dovoleno“. Certifikáty zneužity v útoku měly v Key Usage nastaveno „digital signature“ a neměly EKU. Výjimkou byl jeden certifikát neobsahující „digital signature“ v KU, ale nepovedlo se ověřit jestli by podpis byl považován za platný. Podle dokumentace by podpis platný být neměl, ale nezkoušel jsem, co všechno Windows CryptoAPI skutečně povolí.

Tento incident byl jedním z důvodů, proč byla „pohřbena“ malajská certifikační autorita Digicert Sdn. Bhd. (podobnost názvu s americkým Digicertem je náhodná). Mezi další prohřešky patří výdej nerevokovatelných certikátů (chybějící odkazy na CRL a OCSP).

Každopádně jsme našli další nerevokované certifikáty se slabými klíči potenciálně zneužitelné pro podobný útok (uvedené certifikáty jsou již dlouho veřejně známé). První byl před pár dny revokován (15. prosince, 18 dní po notifikaci CA), důvod v CRL/OCSP: „cessation of operation“.

Man-in-the-middle s podporou CA

Mnoho firem prodává zařízení navržené pro SSL man-in-the-middle útok (MitM). Několik lze nalézt v dokumentech publikovaných organizací Wikileaks, je jich ale ještě více. Existuje i specializovaná konference prezentující zařízení a postupy – ISS World Training.

Samotná „MitM krabička“ není ale příliš užitečná dokud útočník nemůže generovat certifikáty vypadající „důvěryhodně“ bez kooperace s „důvěryhodnou“ CA, která by vydala pro tento účel certifikát (buďto koncový nebo sub-CA certifikát). Ví se, že takové CA existují, ale osoby s důkazy podepsaly dohodu o mlčenlivosti, tudíž nemohou ukázat, které CA to jsou.

Jak najít a bránit se proti CA „přítulné k Man-in-the-middle“

Většina lidí se nesetká se sofistikovaným SSL MitM útokem, kde by se objevil certifikát od „důvěryhodné“ CA vydán k MitM účelu. Mnohem běžnější jsou tzv. captive portals, miskonfigurace nebo „nesofistikovaný“ útočník s self-signed certifikátem. Když už se CA-MitM certifikát objeví, bude to nejspíš buď zákonný odposlech nebo síť velké korporace. Nicméně většina korporací v případě využití MitM vydá vlastní CA a nainstaluje CA certifikát na klientské stanice. Ironií je, že v závislosti od modelu a konfigurace lze na „MitM krabičku“ zvenčí provést MitM útok, který nebude viditelný na straně klienta.

Mezi současně známé nástroje na prevenci a detekci MitM patří Perspectives, Convergence a Certificate Patrol. Všechny tři jsou rozšíření pro Firefox, i když existuje alpha port Perspectives pro Chrome. Kromě některých čistě technických záležitostí (např. Convergence a Certificate Patrol nelze kombinovat; firewall/proxy může blokovat kontaktování notářů) existuje problém, který autoři nemůžou ovlivnit: software nemá jak vědět, jestli viděl všechny certifikáty pro dané DNS jméno nebo IP. Tento CDN efekt je vidět především u velkých serverových farem, např. Google.

Nicméně lze celkem dobře CDN efekt změřit. Z výsledků scanování cca 1,6 milionu strojů jsme jich našli několik tisíc, které odpovídaly definici CDN služby: stroj pošle certifikát A, pak certifikát B, později opět certifikát A. Scanování probíhalo jednou denně po dobu 40 dní.

Výsledky měření CDN efektu:

CSV soubory mají formát:
FQDN|db_id|issuer organization|issuer CN|first seen|last seen.
Sloupec db_id je interní databázové ID a slouží k nalezení konkrétního řetězce certifikátů. Exportované certifikáty jsou dostupné v komprimovaném CSV (25,4 MB). Formát je jednoduchý, ID následované certifikáty v base64 kódovaní, oddělovač je „|“. V datech lze nalézt skutečné CDN služby stejně jako případy chyb v konfiguraci. Na některých místech je bez dalších informací nemožné rozlišit miskonfiguraci od možného útoku.

Další otázka, kterou zmíněné nástroje neumí zodpovědět, je které CA používají administrátoři serveru, např. v případě, že získali nový certifikát od jiné CA před skončením platnosti starého certifikátu. Nicméně z dostupných dat lze říci, že algoritmus použitý rozšířením Certificate Patrol je rozumný a poskytuje dobré výsledky s nízkým procentem falešných poplachů. Podobně to platí pro Perspectives a Convergence.

Předešlou otázku „která CA může vystavit certifikáty pro daný server“ řeší návrhy několika nových protokolů – většinou se jedná o různé varianty techniky certificate pinning. O nových protokolech si řekneme příště.

CS24_early

Závěr

Perlička na závěr: mezi „důvěryhodné“ CA patří i organizace SAIC, která vedla pro NSA projekt Trailblazer. Cílem projektu bylo zkonstruovat „odpočúvadlo“:

Výborný článek (i když rozsáhlý) o historii a současnosti podobných NSA projektů lze nalézt v článku časopisu New Yorker, kde o nich mluví bývalý vysoce postavený pracovník NSA. SAIC v minulosti také byla vlastníkem společnosti Network Solutions, LLC, provozující „důvěryhodnou“ CA. Network Solutions také nemá úplně čistou pověst (viz linkovaný wiki článek). Ale pochybné praktiky bychom nalezli u mnoha dalších CA.

Byl pro vás článek přínosný?

Autor článku

Autor textu pracuje jako programátor pro výzkum a vývoj v Laboratořích CZ.NIC, výzkumném a vývojovém centru správce české národní domény.