Letošní rok je na kostlivce ve skříni obzvláště bohatý. Někteří ještě nestihli zareagovat na Shellshock a už máme ve frontě záplaty na další kritickou bezpečnostní díru. Další černý puntík vyhrává letos už po několikáté SSL. Chyba není sice tak závažná jako Heartbleed, ale je o to zajímavější tím, že se v podstatě nedá přímo opravit, ale přesto jistý způsob opravy existuje již 15 let.

Dějepis

V roce 1994 výzkumná skupina Netscape Communications přišla s protokolem, který měl zajistit bezpečnost při surfování po webu. Nazvali jej SSL (Secure Socket Layer), ale první verze se k široké veřejnosti vinou své nedokonalosti nikdy nedostala. Výzkumná skupina pokračovala ve své práci sérií úprav a vylepšení, jak po stránce bezpečnosti, tak i po stránce použitelnosti, a o rok později vypustila na světlo světa SSL 2.0. I to mělo daleko k dokonalosti a několik bezpečnostních nedostatků bylo odhaleno relativně krátce po jeho uvedení, takže celý milý protokol SSL byl přepracován víceméně od základu a v roce 1996, tedy před 18 lety, bylo vyvinuto SSL 3.0. Tohle všechno se dělo v období žabomyších válek mezi Netscape a Microsoftem, kdy se každá ze společností snažila prosadit si svůj standard na každou kravinu, takže není divu, že i Microsoft pracoval na své verzi bezpečného spojení, jmenovitě pak na protokolech PCT (Private Communications Technology) a STLP (Secure Transport Layer Protocol), ale ty se nikdy nepodařilo protlačit do chřtánu zákazníkům a spotřebitelům. Po vydání SSLv3 se chvilku celkem nic moc zajímavého nedělo, až v roce 1999, kdy se „vývoj internetu“ přesunul z rukou korporací k institucím jako IETF nebo W3C bylo jen tak mimochodem standardizováno TLS (Transport Layer Security, RFC 2246), které bylo na SSLv3 založeno.

A pak se začaly dít věci

V roce 2001 si jeden z profesorů švýcarského technologického institutu všiml možné zranitelnosti v paddingu používaném v CBC (Cipher Block Chaining) módu u SSLv3, ale v té době se tato zranitelnost z důvodu časové a výpočetní náročnosti zdála nepoužitelná při skutečném útoku. O rok později byla publikována práce, která poukazovala na možný chosen-plaintext útok v případě, že útočník zná inicializační vektor nebo je schopen jej předvídat. Opět se však nejednalo o praktický útok. Ten byl demonstrován až v roce 2006. Okamžitou reakcí byla úprava protokolu a vydání TLS 1.1 (RFC 4346), který obě dosud objevené zranitelnosti odstranil. To ovšem znamenalo, že od této chvíle na světě existuje několik milionů počítačů, jejichž bezpečně přenášené informace nejsou vůbec v bezpečí. V roce 2008 pak byl standardizován protokol TLS 1.2 (RFC 5246), který sice pár dalších, méně významných zranitelnostní také opravoval, ale hlavně se postrčil kupředu, aby držel krok se současnými kryptografickými algoritmy. V roce 2011 pořádně přituhlo. Útokem, který se deset let předtím zdál příliš komplikovaný, se díky posunu ve vývoji hardware podařilo úspěšně zaútočit na špatnou kryptografickou implementaci v Microsoftím frameworku ASP.NET. A ta samá dvojice výzkumníků pak i předvedla novou a lepší metodu útoku využívající slabin inicializačních vektorů, která vešla v dějiny jako BEAST attack. Podotýkám, že oba problémy již byly opraveny v TLS 1.1 před pěti lety, ale nikdo se příliš neobtěžoval jej ve svých produktech implementovat. Udává se, že v té době bylo zranitelných cca 75% internetu, což je samozřejmě průser jak mraky. Jen díky tomu, se situace trochu rozhýbala a vývojáři software začali ve velkém implementovat novější verze TLS a zahazovat staré a ošklivé SSL. V roce 2013 pak byla vylepšena další zranitelnost týkající se CBC módu SSL a jeho náchylnosti na timing-attack. A pak, 14. 10. 2014, kluci z Google popsali POODLE attack.

Pudl, který štěká, kouše

Co je tedy vlastně za problém? SSL je přece od roku 2006 mrtvé, protože všichni už podporují TLS 1.1 a 1.2 a všechno je v pořádku, ne? Ne. Problém tkví v tom, že SSLv3 je sice obludně zastaralý protokol, který už měl dávno zmizet ze světa, ale nezmizel. Pořád existuje a pořád je spoustou software podporovaný. A pak se nám ten problém větví dál. Na jedné straně jsou uživatelé, kteří jsou příliš sexy na to, aby se naučili svůj počítač udržovat aktualizovaný (schválně, kolik pitomců, kteří nechtějí opustit WinXP znáte?) a na straně druhé jsou to vývojáři, kteří sice mají dobré úmysly a chtějí, aby jejich aplikace poskytovala co největší kompatibilitu, ale dělají to tak nešťastně, že tím své uživatele vystavují nebezpečí.

Jádro pudla i POODLE je totiž v tom, že SSL i TLS podporují věc zvanou protocol downgrade. To v praxi znamená, že když klient umí TLS 1.2, ale server jen TLS 1.1, je klient schopen snížit své nároky a pokračovat protokolem, kterým se obě strany domluví. Za normálních okolností je takové opětovné vyjednání úplně v pořádku. Průser vznikne, až když si programátor prosadí svou a do programu sesmolí i takový downgrade, který není protokolem přímo podporován. A to je právě případ nemalého počtu aplikací, v čele se všemi webovými prohlížeči (vyjma Opery). TLS totiž nepodporuje downgrade na SSL, protože i přesto, že jsou si podobné, z hlediska IETF se jedná o dva různé protokoly, takže nedává smysl takový downgrade umožnit. Vývojáři jsou však úžasní tvorové, takže si downgrade z TLS 1.0 na SSL 3.0 dobastlí sami. A průser je na světě. Pak totiž už jen stačí nějaký man-in-the-middle, který do handshake bude kecat tak dlouho, až se prohlížeč rozhodne poslat požadavek po SSL a voila, hesla k bankovnictví, soukromá pošta a jiné facebooky se jen sypou.

Jak to vlastně funguje

POODLE (Padding Oracle On Downgraded Legacy Encryption) využívá slabiny v paddingu CBC módu pro man-in-the-middle attack. Blokové módy, jakým je třeba ono CBC, fungují principiálně tak, že zprávu rozkouskují do bloků o pevně stanovené velikosti a jednotlivé bloky postupně šifrují. V závislosti na použitém módu je možno bloky i řetězit a vytvářet různé vazby, takže například pokud příjemci bude jeden blok chybět, nebude moct kus zprávy dekódovat. Takových módů je kýbl a CBC byl ještě do nedávna jedním z nejčastěji používaných, protože docela obstojně řešil poměr rychlosti, chybovosti a výpočetní složitosti. Samozřejmě zpráva je málokdy tak dlouhá, že lze rozdělit do bloků beze zbytku, takže poslední blok je třeba „vycpat“ nějakými bajty tak, aby doplnily blok do jeho stanovené délky. K tomu je tu onen nešťastný padding. TLS s paddingem zachází jinak než SSL, což je důvod, proč je zranitelné pouze SSL 3.0, ale TLS 1.0 na něm založené už ne. V TLS je padding pevně daný, takže každý bajt vycpávky musí nést hodnotu která je rovna velikosti paddingu a na straně příjemce je pak díky ní možno ověřit, zda s blokem zprávy po cestě někdo nezkoušel dělat nějaké nekalosti. Naproti tomu SSL do paddingu cpe náhodná data, takže útočník může vycpávaný blok jakkoliv změnit a bude mít šanci 1:256, že se trefí, MAC (Message Authentication Code) bude pasovat a blok bude úspěšně přijat. Pak už si útočník podle algoritmu vypočítá, jaký tedy musel být poslední bajt šifry. Poté nechá klienta prodloužit odesílaná data a ten samý postup opakuje na následující blok a tak pořád dokola, dokud postupně metodou pokus-omyl z takto upravovaných dat nezíská šifrovací klíč.

Efektivně pak takový útok lze provést, pokud je útočník schopen ovlivnit jaká data oběť posílá, tedy jí například v prohlížeči vnutit javascript, který bude pořád dokola odesílat stejná data. Je tedy zřejmé, že se jedná o podstatně menší problém než třeba u Heartbleedu, kdy mohl kdokoliv poslat vtipně upravený požadavek přímo serveru a donutit jej tím vysypat kus paměti. POODLE tedy může uspět, pouze pokud existuje nějaké vhodné místo na síti nebo v TCP/IP stacku pro uhnízdění útočníka a pokud je oběť donucena posílat data, která útočník následně zachytí. Kolaps internetu se tedy nekoná, protože takovýto scénář spíš odpovídá chování nějakého malware.

(P)oprava

Protože se jedná o chybu v návrhu SSL 3.0, neexistuje oprava, která by odstranila chybu a zároveň umožnila SSL protokol nadále používat. Navíc ve své podstatě jde o problém na straně klienta, resp. jeho volném výkladu implementace protocol downgrade, takže se nedá jednoduše říct, které produkty jsou nebo nejsou ovlivněny. Pokud tedy nepotřebujete zachovat podporu předpotopních klientů, doporučuje se SSLv3 prostě a jednoduše vypnout. Pokud vaše systémy SSLv3 stále potřebují, evidentně vám na nějaké bezpečnosti nesejde, takže si běžte za roh naliskat. Pak si můžete třeba aktualizovat verzi OpenSSL, která onen problém s downgradem řeší poněkud šalamounsky. Přidává totiž jakousi signální hodnotu TLS_FALLBACK_SCSV, která se projeví jako nový druh šifry v seznamu podporovaných šifer, které si klient se serverem předávají. Pokud je tato hodnota podporována na straně klienta i serveru, downgrade na SSLv3 bude odmítnut a pokus o navázání spojení selže.

Když to vezmu kolem a kolem, ono se vlastně vůbec nejedná o bezpečnostní chybu. Největší chyba je v úsudku a v myšlenkových pochodech lidí, kterým je nějaká bezpečnost úplně ukradená a kteří se nezajímají o to jak věci fungují, ale stačí jim, že prostě nějak fungují.