Hlavní navigace

Cloudbleed: únik dat sdíleného proxy serveru

Ondřej Caletka

Společnost Cloudflare oznámila chybu ve své infrastruktuře, jejíž následky jsou velmi podobné zranitelnosti Heartbleed v OpenSSL. Díky podrobné zprávě o incidentu si můžeme přečíst, co se přesně stalo.

Začalo to celé nenápadně, v pátek 17. února odpoledne, kdy bezpečnostní výzkumník z Google, Tavis Ormandy, napsal na Twitter status, který předznamenával něco velkého.

Během analýzy výsledků tzv. fuzzingu, tedy testování kódu velkou množinou různých vstupů, narazil na podivný webový obsah, který obsahoval evidentně kusy neinicializované paměti. Záhy se ukázalo, že problém je v proxy serverech služby Cloudflare. Když se mu ho podařilo izolovat a reprodukovat, snažil se jej co nejrychleji předat bezpečnostnímu týmu Cloudflare.


Tavis Ormandy

Ukázka uniklých dat – data známé aplikace Uber

První pomoc

Bezpečnostní tým Cloudflare okamžitě pochopil, že jde o vážnou situaci. První, co udělal, bylo vypnutí doplňkových služeb, které nejspíše problém způsobovaly. Konkrétně šlo o služby obfuskace e-mailových adres, server-side excludes a automatických přepisů odkazů z http  na https. Podle zprávy o incidentu byly také okamžitě sestaveny týmy pro řešení incidentu – jeden v San Franciscu a druhý v Londýně tak, aby se mohly střídat po 12hodinových směnách v nepřetržitém provozu. K vypnutí e-mailové obfuskace, která způsobovala nejvíce úniků, došlo už 47 minut po nahlášení, ke kompletnímu vypnutí všech funkcí, které únik způsobovaly, došlo 7 hodin po nahlášení.

Hledání příčiny

Od začátku bylo zřejmé, že chyba je ve funkcích, které v proxy serverech za běhu upravují HTML kód stránek. K tomuto účelu v Cloudflare dlouho používali vlastní parser napsaný v jazyce Ragel. Před časem však došli k závěru, že tento kód je příliš složitý a těžko udržovatelný, a tak začali vyvíjet nový, cf-html. Oba parsery jsou provedeny jako moduly pro webový server NGINX a během přechodného období jsou aktivní oba.

Další vyšetřování ukázalo, že chyba byla ve starém kódu přítomna mnoho let, teprve kombinace s novým modulem ji však dokázala vyvolat. Přímou příčinou byla nedostatečná kontrola přetečení ukazatele za konec řetězce v kódu, generovaném kompilátorem jazyka Ragel:

/* generated code */
if ( ++p == pe )
    goto _test_eof; 

Je třeba zdůraznit, že nejde o chybu v kompilátoru jazyka Ragel, ale o chybu ve zdrojovém kódu v tomto jazyce, jehož autorem je Cloudflare.

Podmínka ve výše uvedeném kódu kontroluje pouze rovnost s koncovou zarážkou. Dojde-li z nějakého důvodu k přeskočení ukazatele za zarážku, není konec vstupu detekován a program čte z paměti bezprostředně následující za bufferem. V této paměti se mohou nacházet různá data z předchozích komunikací. Jelikož je infrastruktura Cloudflare sdílená mezi různými zákazníky, je možné získat data i jiných webových stránek, než těch, které jsou problémem postiženy. Princip čtení přes hranice alokované paměti je velmi podobný chybě Heartbleed z roku 2014.


Tavis Ormandy

Ukázka uniklých dat – data fitness náramku Fitbit

Spící zranitelnost

Chyba čtení za hranice byla v kódu přítomna nejspíše od samého počátku. K jejímu vyvolání došlo vyvoláním chyby parseru na samém konci posledního bufferu, například, když HTML kód na zdrojovém serveru končil takovouto neukončenou značkou:

<script type= 

Chyba se však nemohla projevit, dokud tento modul pracoval v NGINX samostatně. Je to způsobeno stylem, jakým NGINX předává modulu data. Teprve v okamžiku, kdy byl k původnímu modulu přidán nový cf-html, byly splněny podmínky k tomu, aby chyba v původním kódu začala škodit.

K prvnímu nasazení cf-html došlo 22. září 2016, kdy byla do cf-html zmigrována funkce automatického přepisování http na https. Zákazníci, kteří měli tuto funkci zapnutou a zároveň splnili podmínku nevalidně ukončeného HTML, mohli způsobovat únik dat už od té doby. Tato funkce však není podle slov Cloudflare příliš používaná.

Dalším nasazením cf-html byla funkce Server-Side Excludes, k jejíž migraci došlo 30. ledna 2017. Tato funkce je však aktivována pouze pro IP adresy se špatnou reputací a slouží k filtrování potenciálně citlivých údajů. Pro běžný provoz se neprojeví. Největší vliv tak měla zatím poslední ze série migrací, která proběhla 13. února, tedy pouhých pár dní před zjištěním incidentu. Jednalo se o migraci funkce obfuskace e-mailových adres, která je naopak používána velmi často.

Identifikace poškození

Cloudflare provozuje pro různé úrovně zpracování webového obsahu samostatné instance webserveru NGINX. Proces, ve kterém byla chyba, je součástí zpracování HTML a je zcela oddělen od procesů terminace TLS, rekomprese obrázků a kešování. Je tedy jisté, že touto zranitelností nemohlo dojít ke kompromitaci privátních klíčů od zákaznických certifikátů. Mohlo však dojít k vyzrazení šifrovacích klíčů, kterými Cloudflare šifruje komunikaci mezi jednotlivými servery v rámci datacentra. Toto šifrování bylo zavedeno v reakci na informace Edwarda Snowdena o masivním monitorování.

Největším problémem ale je únik částí HTTP komunikace jiných zákazníků, kteří používali stejný proxy server. Taková komunikace může obsahovat uživatelská jména a hesla, nebo přinejmenším cookie sezení, které je možné zneužít ke kompromitaci cizích identit.

Zamořené keše

Zásadním problémem také je, že k vyvolání úniku dat nebyla zapotřebí (na rozdíl třeba od Heartbleedu) žádná sofistikovaná činnost, stačilo pouze stahovat webové stránky. To je činnost, která je bezpochyby nejčastější internetovou aktivitou vůbec a kromě koncových uživatelů ji provádějí automaticky nejrůznější roboti.

Uniklá data se tak objevila v keších všemožných vyhledávačů a webových archivů. Společnost Cloudflare vyjednala s několika vyhledávači odstranění podobných dat, můžeme se však jen dohadovat, zda se všechna data najít povedlo a zda někde stále neleží. Je celkem pravděpodobné, že nějaké úniky budou k nalezení i v lokálních keších webových prohlížečů v počítačích a mobilech celého světa.

Uniklá data na prodej

Teprve po nasazení nové verze HTML parserů s opravenou zranitelností, ke kterému došlo večer v úterý 21. února, a odstranění všech nalezených úniků z výsledků vyhledávání, byla informace o zranitelnosti zveřejněna. Kromě již zmíněné post mortem analýzy na blogu Cloudflare byl také zpřístupněn tiket, ve kterém Tavis Ormandy dokumentoval postup opravy problému, včetně ukázek úniků. Společnost Cloudflare také rozseslala všem zákazníkům hromadný e-mail, ve kterém upozorňuje na to, že postižených bylo pouze přibližně 150 zákazníků, nicméně doporučuje zneplatnit a vyměnit všechna dlouhodobá tajemství, jakými jsou třeba cookie sezení.

Počet 150 zákazníků se zdá velmi podhodnocený, neboť jde pouze o počet unikátních doménových jmen, ve kterých byly nalezené uniklé informace prostřednictvím vyhledávačů. Není přitom zřejmé, zda se bezpečnostním expertům podařilo identifikovat, komu patřila vlastní uniklá data. Každý, kdo provozuje webserver za Cloudflare proxy, by tedy měl minimálně zrušit všechna uložená sezení. Ideálně pak také vyzvat uživatele k preventivní změně hesla. Ostatně, netrvalo dlouho a temný web začal nabízet k prodeji soubory uniklých dat. Těžko říct, zda jde o skutečný únik nebo o jednoduchý podvod, přiživující se na aktuální zprávě.

Zneplatněná přihlášení Google s problémem nesouvisí

Shodou okolností minulý týden Google zneplatnil uložená přihlášení velké části uživatelů. Vypadá to jako souvislost, ale nedává to úplně smysl, protože Google služby určitě Cloudflare nepoužívají a je tedy nepravděpodobné, že by cookies, které slouží k autentizaci vůči Google, byly v jakémkoli nebezpečí. Tavis Ormandy na přímý dotaz odpovídá, že incidenty nemají nic společného, na fóru Google je pouze zpráva, že v průběhu rutinní údržby došlo k odhlášení některých uživatelů. Nejspíš tedy opravdu jde o pouhou shodu okolností.

Maximální otevřeností k minimalizaci škod

Na celé události je zajímavý především způsob, jakým společnost Cloudflare o problému informovala. Přestože se jedná o komerční firmu, a chyba se objevila v proprietárním softwaru, který je součástí firemního know-how, množství informací zásadně překračuje obvyklé strohé sdělení typu: „V našich systémech se vyskytla chyba, už jsme ji opravili, změňte si prosím heslo.“

Překvapující je také rychlost, s jakou byla společnost schopna úniky dat zastavit (i za cenu omezení služeb) i jak rychle byla nainstalována oprava. Škoda jen, že zpráva nejspíše podceňuje počet obětí. V haldě podrobných technických informací se také ztrácí krátká a jednoduchá informace pro zákazníky, co mají se svou službou za Cloudflare dělat, aby vliv případných úniků minimalizovali.

Našli jste v článku chybu?
27. 2. 2017 17:55

Připomíná to, že mít SSL ve stejném procesu, jako všechno ostatní, není dobrý nápad. V tomhle případě sice privátní klíče k SSL neunikly, protože se náhodou SSL terminuje na jiných instancích, ale bylo to spíš štěstí než záměr.

Neřeší některý z mnoha forků OpenSSL právě tohle, tj. zachování API OpenSSL ale oddělení implementace do samostatného procesu? Vlastně takové „softwarové HSM“ – klíče by se držely v samostatném procesu, který by pro hlavní proces prováděl šifrování a dešifrování. Protože…

28. 2. 2017 7:14

Žádná jiná knihovna nezabrání kompromitaci privátního klíče, pokud bude klíč držen v paměti hlavního procesu a jakýkoli kód v tom hlavním procesu bude omylem číst a odesílat cizí paměť. Může to být chyba v parseru HTML,jako tentokrát, nebo v čemkoli jiném – v parseru HTML, v generátoru obrázků, v kompresní nebo dekompresní knihovně, ve frameworku, ve vlastní webové aplikaci…