Podvodné certifikáty pro *.google.com od TURKTRUST

Byly odhaleny 2 podvodné certifikáty pro *.google.com vydané zprostředkujícími certifikačními autoritami patřícími pod TURKTRUST. Certifikáty byly zneužity k phishingovým útokům. Bezpečnostní záplaty aktualizující seznamy "důvěryhodných" certifikačních autorit ve webových prohlížečích jsou postupně vydávány. Více například na Krebs on Security. Nejedná se o první případ vydání podvodných certifikátů. Připomenout lze například kauzy Comodo nebo DigiNotar.

4.1.2013 02:05 | Ladislav Hagara | Bezpečnostní upozornění

Komentáře

[xkucf03]

Trochu mi tu chybí informace, kolik uživatelů bylo reálně ohroženo a jak útok probíhal. Byl v tom namočen nějaký ISP, který přesměrovával klienty na IP adresy útočníka? Nebo se používal virus, který upravil např. /etc/hosts soubor oběti? Nebo to byly napadené DNS servery?

[petr_p]

Já myslím, že v případě Turecka je situace jasná.

[Foo Bar]

No, Vám by také pomohlo přečíst si odkazovaný článek...

Každopádně je to mnohem veselejší:

"TURKTRUST told us that based on our information, they discovered that in August 2011 they had mistakenly issued two intermediate CA certificates to organizations that should have instead received regular SSL certificates. On December 26, we pushed another Chrome metadata update to block the second mistaken CA certificate and informed the other browser vendors.”

Takže ze strany TURKTRUSTu nešlo o zlý úmysl, ale jenom o hloupost...

[petr_p]

Za prvé jsem reagoval na to, jak se v Turecku řeší spolupráce s ISP. Za druhé Türktrustu vysvětlení věřit můžete, nebo nemusíte. (Iniciátorem aféry stále byla třetí strana.) Za třetí je nanejvýš podezřelé, jak se může CA bit nastavit omylem. To totiž znamená, že autorita vedle koncových certifikátů vydává i certifikáty pro podautority, které mají stejný certifikát vydavatele. A vzhledem k tomu, že v X.509 neexistuje způsob, jak do certifikátu zakódovat certifikační politiku (například omezení na DN nebo SubjectAltName), znamená taková praxe bianco certifikát, protože útočníkovi pak stačí do TLS handshaku poslat celý řetěz důvěry.

[xkucf03]

A vzhledem k tomu, že v X.509 neexistuje způsob, jak do certifikátu zakódovat certifikační politiku (například omezení na DN nebo SubjectAltName)

RFC 5280: Name Constraints?

[petr_p]

Vida. Nějak ale nechápu, jak by se udělalo omezení na konkrétní hostname. Omezení pomocí dNSName obsahuje všechny poddomény. Omezení pomocí uniformResourceIdentifier umí přesný hostname, ale to zase vyžaduje, aby alternativní jméno certifikátu bylo URI, protože omezení se uplatňují jen na jména stejného typu. A popravdě v praxi všude vidám jména jen typu dNSName. Uniká mi něco?

[xkucf03]

Omezení pomocí dNSName obsahuje všechny poddomény.

A je to reálný problém? Potřebuješ CA, která může vydávat certifikáty jen pro xxx.example.com, ale už ne pro zzz.xxx.example.com?

[.]

kazdopadne pokud je vznesena domenka opodstatnena a pokud doslo ke koordinaci turktrustu s patricnou agenturou s pravomoci odposlechu, tak meli dostatecne dlouhe okno na posbirani prihlasovacich udaju a nasledny sber osobnich dat z dane sluzby uz je nezavisly na platnosti nebo neplatnosti certifikatu.

[more info]

The Opera Rootstore - Erroneous Certificates

[Foo Bar]

Opravdu jste tak líný si prokliknout na odkazovaný článek?

[xkucf03]

Článek jsem ráno jen v rychlosti prohledal na klíčová slova… a taky píšu:

Trochu mi tu chybí informace

Tzn. tady na Ábíčku. Předpokládám, že autor zprávičky ten článek četl a tudíž by sem mohl napsat shrnutí, co se stalo a jaký to mělo praktický dopad. A ne jen bulvární výkřik typu: „CA jsou špatné“ (na ty začínám být už pomalu alergický).

[David Jaša]

A ne jen bulvární výkřik typu: „CA jsou špatné“ (na ty začínám být už pomalu alergický).

Tak ony špatné jsou a ne že ne. Špatné nebudou až tehdy, kdy se bude platnost certifikátu ověřovat i přes DNSSEC/DANE, a takovýhle "průlom" do CA útočníkovi k ničemu nebude.

[Heron]

To je přece složitější. CA nejsou špatné proto, že jsou to CA. Moje CA je pro mě ta nejdůvěryhodnější a rozhodně ji nepouvažuji za špatnou.

Za aktuální stav podle mě mohou především výrobci prohlížečů a to je něco, co se s příchodem DANE moc nezmění.

[David Jaša]

Moje CA je pro mě ta nejdůvěryhodnější a rozhodně ji nepouvažuji za špatnou.

Jenže to je ti bez DNSSEC plat prdný v situaci, kdy nějaká jiná CA vystaví certifikát pro tvou mašinu a podvrhne DNS. To je to, co je na PKI rozbitý. DNSSEC samo o sobě tohle zarazí, a spolu s DANE zarazí i útoky, kdy se někdo na cestě "podívá" na routování.

Pro klasické CA vidím v budoucnu místo prakticky jenom u EV certifikátů nebo v podnikových prostředích - a to opět jen ve spojení s DANE.

[Heron]

DNSSEC ani DANE nezavrhuji, právě naopak, to jen pro pořádek. Připadá mi nesmyslené platit 1700Kč Thawte jen za to, že mají root crt v prohlížečích ... a zpět k těm prohlížečům .

Co se stane, když jdeš poprvé na nějaký ssh server? No chce to po tobě ověřit fingerprint, pakliže jsi si neimportoval hostkey toho serveru. Takže si ověříš fingeprint. Když se změní (což může být v pořádku nebo taky útok), co udělá ssh? Rozhodně se mu to nelíbí a nepustí tě tam. A hlavně napíše, co všechno může být špatně.

Jak se v takovém případě zachová prohlížeč? V základu je tam naimportována spousta známých i neznámých root ca. Při první návštěvě https se stane co? Nic, pustí tě to. Bez ověření fingerprintu. Co se stane v případě změny crt a to klidně i od zcela jiné CA? Nic. Pustí tě to.

Doplněk Certificate Patrol se to alespoň trochu snaží napravit.

Za to když jdeš na https prohlížeči neznámé CA? Zobrazí varování jak vrata ... kde typicky není vůbec napsané, co dělat. Ono totiž kdyby si uživatel po ověření fingerprintu naimportoval třeba i ten selfigned key, tak pro bezpečnost udělá daleko více, než když slepě věří výchozím root ca.

Osobně vidím chybu jednoznačně v prohlížečích. Preferují (mizerné) výchozí CA, fakticky zabraňují udělat si vlastní (minimálně nepředkládají uživateli správný postup) CA a ještě nevarují při změně serverového crt.

[David Jaša]

Osobně vidím chybu jednoznačně v prohlížečích. Preferují (mizerné) výchozí CA, fakticky zabraňují udělat si vlastní (minimálně nepředkládají uživateli správný postup) CA a ještě nevarují při změně serverového crt.

To není jen věc prohlížečů, ale všeho, co se snaží používat systémové certifikáty (viz ca-bundle.crt). Aby je tam dodával jen správce je nereálné a když je tam dodává někdo zvenku, trpí bezpečnost. Nedokážu si představit, jak tohle bez DANE vyřešit.

[petr_p]

DANE ovšem není úplné řešení. V podstatě jen zavádí „nezávislý“ strom autorit. To je samozřejmě významné zlepšení, ale rozhodně to není úplné řešení.

[Jendа]

Příloha:

• ff-ca.png (29435 bytů)

Takže si ověříš fingeprint. Když se změní (což může být v pořádku nebo taky útok), co udělá ssh? Rozhodně se mu to nelíbí a nepustí tě tam.

A že oboje uživatel řeší a určitě jen nedá yes a pak neodstraní inkriminovaný řádek z known_hosts nebo rovnou nesmaže known_hosts celý.

fakticky zabraňují udělat si vlastní (minimálně nepředkládají uživateli správný postup) CA

Já teda když vlezu s Firefoxem na certifikát neznámé CA, tak se zobrazí až děsivě přívětivé okýnko, kde stačí zaškrtnout čekboks a kliknout na Budiž. Je to tak jednoduché, až se děsím toho, že až moje vláda začne provádět MITM na HTTPS, naprostá většina BFU najde řešení té otravné firefoxí hlášky, kde se musí asi 15x kliknout, aby se přidala výjimka. „Tady to zaškrtneš a pak ti budou všecky stránky normálně fungovat.“ Viděl jsem, jak rychle se spolužáci naučili vypínat HTTPS na Facebooku a webmailech, když nám ve škole blokli tcp/443.

a ještě nevarují při změně serverového crt

Posledně když jsem tady předkládal řešení problému s CA, tak jsem byl za toto sepsut, že serverový klíč se může změnit a co pak bude chudák uživatel dělat.

[Heron]

A že oboje uživatel řeší a určitě jen nedá yes a pak neodstraní inkriminovaný řádek z known_hosts nebo rovnou nesmaže known_hosts celý.

Zřejmě se naše představy o bezpečnosti poněkud rozcházejí. Bavit se o uživatelích, kteří to chtějí dělat za každou cenu nebezpečně asi nemá smysl. Co má smysl je podle mě vést uživatele k tomu, aby věděl co je potřeba udělat a proč. Nevím v jakém prostředí se pohybuješ nebo o jaké škole mluvíš, ale v mém okolí není až takový problém někomu vysvětlit co a jak. Sice to asi nechápou úplně na kost (ne každý ve škole implementoval alg. RSA), ale alespoň netápou ve tmě. Navíc mnoho uživatelů už nějaký certifikát používá (účetní pro odeslání údajů na ČSSZ například) a tak nějak vlastním způsobem chápou, o co jde. Většinou to stačí jen doladit.

[Jendа]

Bavit se o uživatelích, kteří to chtějí dělat za každou cenu nebezpečně asi nemá smysl. Co má smysl je podle mě vést uživatele k tomu, aby věděl co je potřeba udělat a proč. Nevím v jakém prostředí se pohybuješ nebo o jaké škole mluvíš, ale v mém okolí není až takový problém někomu vysvětlit co a jak.

Tak to máš dobré uživatele. Já jsem ještě mimo lidi z IT neviděl, aby někdo někdy řešil nějaké fingerprinty.

Navíc mnoho uživatelů už nějaký certifikát používá (účetní pro odeslání údajů na ČSSZ například) a tak nějak vlastním způsobem chápou, o co jde.

Opravdu to chápou, nebo jenom vědí, že musí kliknout tady a tady? Tj. když na ně vyskočí varování, že identitu protistrany nelze ověřit, kliknou na Pokračovat nebo na Zrušit a zavolají tě?

Mluvím o nic moc netechnické střední.

[Heron]

Já jsem ještě mimo lidi z IT neviděl, aby někdo někdy řešil nějaké fingerprinty.

A co má co člověk mimo IT dělat na ssh serveru?

Opravdu to chápou, nebo jenom vědí, že musí kliknout tady a tady? Tj. když na ně vyskočí varování, že identitu protistrany nelze ověřit, kliknou na Pokračovat nebo na Zrušit a zavolají tě?

Zrovna účetní je zvláštní tvor . Co jsem se setkal, tak stačí říct co mají dělat a oni to fakt dělají. Ať se to týče zálohování nebo i třeba toho crt pro čssz. Nevím, jak probíhá výuka / výchova účetních, ale přijde mi, že jsou zvyklí dělat věci podle pravidel. Jestli to opravdu chápou nevím, ale úplně blbí ti lidé také nejsou.

[Jendа]

A co má co člověk mimo IT dělat na ssh serveru?

No zdálo se mi, že když to srovnáváš s HTTPS, tak by se ti možná líbilo, kdyby se HTTPS klienty chovaly (je to neživotné, ne?) podobně.

[xkucf03]

A co má co člověk mimo IT dělat na ssh serveru?

U nás lidi takhle pracovali s účetním programem – akorát to nebylo SSH, ale telnet po SSL.

ale přijde mi, že jsou zvyklí dělat věci podle pravidel. Jestli to opravdu chápou nevím, ale úplně blbí ti lidé také nejsou.

[xkucf03]

To je to, co je na PKI rozbitý. DNSSEC samo o sobě tohle zarazí, a spolu s DANE

To je donebevolající naivita, věřit, že to DNSSEC/DANE nějak zázračně „opraví“* Akorát to znamená, že všichni budeme věřit jedné monopolní CA (resp. jedné pro každou TLD) a jejím registrátorům (těch jsou spousty a o jejich důvěryhodnosti bych si nedělal iluze – často bude nižší než u běžné CA).

*) ve skutečnosti ani nic rozbitého není, protože PKI funguje přesně tak, jak má – když si nějakou CA dáš do důvěryhodných (s tím, že v X.509 rozšířeních má, že může vydávat certifikáty pro libovolné domény), tak prostě certifikáty vydávat může a tvůj klientský program naváže spojení a zobrazí ikonu, že je to OK – tzn. očekávatelný a správný výsledek.

[xkucf03]

Spíš bych řekl, že je chyba na straně klientských programů (nejviditelnější je to u WWW prohlížečů):

• Příliš tolerantní při přidávání CA do seznamu důvěryhodných.
• Chybí rozdělení na více tříd důvěryhodnosti (základní a EV je celkem málo).
• Chybí tlak na omezování působnosti – řada CA by mohla mít povoleno vydávat certifikáty jen pro svou TLD doménu (státní a místní autority) nebo jen pro svoje firemní domény (velké firmy typu Google, Microsoft atd.)
• Uživatel by měl možnost přidat si svoje vlastní omezení – i když CA má obecně povoleno vydávat certifikáty pro libovolnou doménu, já bych si stanovil, že jí věřím jen pro určité (pod)domény.
• Rozšíření typu CertificatePatrol by mělo být standardní součástí programu.
• Lepší GUI: varování při překročení platnosti certifikátu o pár dní by mělo vypadat úplně jinak než varování u neznámé CA nebo neodpovídajícího předmětu certifikátu. (a mnoho dalších věcí, které by zasluhovaly vylepšit)

[allstar]

Modlím se za to, aby co nejdříve TURKTRUSTu byly permanentně odebrány kořenové certifikáty ze všech prohlížečů.

[balki]

+1

[LuděkS]

+1

[mtmr]

Po instalaci prohlížeče si důvěryhodné certifikačí autority vždy ručně zreviduji. A TURKTRUST sítem neprošel :) (ale není to 100% dělám to podle citu).

[Karel]

Kurvy turecke smazane, hajzli pice

[Jendа]

To je pravda, žádným jiným CA se tohle nikdy nestalo ani stát nemůže.