Cloudbleed: Jak se s tím vypořádat

Tavis Ormandy (Tavis Ormandy) z projektu Google Zero odhalil hlavní zranitelnost ve službě internetové infrastruktury Cloudflare. Webové požadavky na weby podporované Cloudflare v podstatě obdržely odpovědi, které obsahovaly náhodné informace z jiných webů podporovaných Cloudflare! Tyto informace mohou potenciálně zahrnovat důvěrné informace (soukromé zprávy na seznamovacích serverech, e-maily), informace o totožnosti uživatele (informace umožňující identifikaci osob (PII)) a případně v kontextu zdravotní péče, chráněné informace o zdraví (PHI) nebo údaje o pověření uživatele, aplikace nebo zařízení (hesla, klíče API, autentizační tokeny atd.)

Project Zero i Cloudflare jednaly rychle. Chyba byla nahlášena v letech 2017–02–17 a během jedné hodiny došlo ke zmírnění. Veřejné oznámení bylo vydáno 2017–02–23.

Doba trvání (2016–209–22–20–20–20–20–2020) a potenciální šířka vystavených informací je obrovská - Cloudflare má ve své síti více než 2 miliony webových stránek a údaje z nich jsou potenciálně odkryté. Cloudflare uvedl, že skutečný dopad je relativně malý, takže se domnívám, že bylo skutečně šířeno pouze omezené množství informací. V podstatě byla potenciálně ohrožena široká škála údajů, ale riziko pro jakýkoli jednotlivý údaj bylo velmi nízké. Bez ohledu na to, pokud nelze přesvědčivě prokázat, že vaše data NENÍ ohrožena, bylo by rozumné zvážit možnost, že byla ohrožena.

Zatímco služba Cloudflare byla rychle opravena, aby byla tato chyba odstraněna, data před tímto okamžikem neustále unikala - měsíce. Některá z těchto dat byla veřejně uložena do mezipaměti ve vyhledávačích, jako je Google, a jsou odstraňována. Další data mohou existovat v jiných mezipaměti a službách po celém internetu a samozřejmě není možné koordinovat mazání na všech těchto místech. Vždy existuje možnost, že někdo škodlivý software tuto chybu zabezpečení objevil nezávisle a před Tavisem, a možná ji aktivně zneužíval, ale neexistují žádné důkazy, které by tuto teorii podporovaly. Bohužel je také obtížné přesvědčivě vyvrátit.

Nejcitlivější únikové informace jsou autentizační informace a pověření. Kompromis těchto údajů může mít trvalé a pokračující důsledky, dokud nebudou pověření zrušena a nahrazena.

Z individuálního hlediska je to jednoduché - nejúčinnějším zmírněním je změna vašich hesel. I když to není pravděpodobné (je nepravděpodobné, že by byla vaše hesla vystavena při tomto incidentu), absolutně to zlepší vaši bezpečnost jak z tohoto potenciálního kompromisu, tak z mnoha dalších, mnohem pravděpodobnějších bezpečnostních problémů. Cloudflare stojí za mnoha z největších spotřebitelských webových služeb (Uber, Fitbit, OKCupid,…), takže spíše než se snažit zjistit, které služby jsou v Cloudflare, nej opatrnější je použít to jako příležitost k otočení VŠECH hesel na všech vašich webech . Tím se zlepší vaše bezpečnost, i když primárním přínosem jsou hrozby nesouvisející s tímto incidentem.

(Doporučeným postupem je použití dlouhého náhodného řetězce pro každé heslo, které je jedinečné pro každý web, a správu této kolekce pomocí „správce hesel“, jako je 1Password, LastPass nebo vestavěných správců hesel v moderních webových prohlížečích. měli byste se od této aktualizace také odhlásit a přihlásit se do svých mobilních aplikací. Pokud jste u toho, pokud je to možné, je možné použít 2FA nebo 2SV s weby, které považujete za důležité (pomocí něco jako TOTP / Google Authenticator nebo U2F), to je smysluplné bezpečnostní upgrade.)

Pro operátory stránek používající Cloudflare: i když to může být rušivé, měli byste vážně zvážit dopad na vaše uživatele. Využijte tento incident jako příležitost k uplatnění vašeho postupu při řešení incidentů - diskutujte o konkrétním dopadu na vaši aplikaci a o tom, jaká reakce má největší smysl (je pravděpodobné, že se liší pro každé místo nebo aplikaci.) Musíte vyvážit neznámé, ale malé riziko vs - ostatní náklady. Dávejte pozor, abyste je nevystrašili, ale může být rozumné jednat. Minimálně bych připravil „odpověď na akci“ na podporu tohoto incidentu a v kontextu podniku nebo b2b aktivně komunikoval se zákazníky o rozsahu incidentu a jeho dopadu na vaši aplikaci a jejich data. Pro drtivou většinu webů v cloudflare to samo o sobě postačuje.

Vynucení změny hesla uživatele je velmi reálné - uživatelé mohou ztratit důvěru ve vaši službu a je to nepříjemné. Nezdá se, že by bylo ohroženo velké množství pověřovacích údajů, takže pro služby zákazníkům s omezeným rizikem ohrožených účtů nemusí být snaha hromadně zneplatňovat hesla a nutit změnu. Pro pověření správce nebo pro všechny weby, které zpracovávají vysoce citlivé informace prostřednictvím Cloudflare, nedostatek kvantifikovatelné maximální expozice pravděpodobně znamená, že stojí za to vynutit si aktualizaci hesla. Pokud byste měli nějaké další důvody, proč byste chtěli zaslat aktualizaci hesla všem svým uživatelům, bude to samozřejmě další faktor při rozhodování.

Weby by měly zrušit platnost ověřovacích údajů pro mobilní aplikace a jiné komunikace mezi stroji (zařízení IoT atd.), Což by uživatele mělo nutit k opětovnému zápisu aplikací a zařízení, pokud používají Cloudflare jako poskytovatele infrastruktury. Pokud si nepřejete vynucovat změnu hesel, proveditelným mezikrokem by mohlo být zneplatnění autentizačních tokenů, což nutí uživatele, aby se znovu přihlásili pomocí svých stávajících hesel; protože autentizační tokeny jsou mezi prohlížečem a serverem častěji předávány, je mnohem pravděpodobnější, že v úniku náhodné paměti ze serveru budou existovat více než hrubá hesla, a vynucení nového přihlášení je minimální dopad na uživatele a nemusí vyžadovat žádné specifické zprávy. nebo oznámení.

Kromě toho by všechny weby, které nepoužívají Cloudflare, ale se spoustou uživatelů, kteří používají weby hostované v Cloudflare (v podstatě jakékoli velké nebo spotřebitelské weby na internetu), měli zvážit nutnost změn hesla uživatele v případě, že jejich uživatelé znovu použili stejná hesla na každém webu . Pravděpodobně to není zaručeno pro velkou většinu webů (kdokoli, kdo potřebuje zabezpečení tak vysoko, že by to mělo smysl, měl by být autentizační infrastruktura mnohem silnější než uživatelská hesla, jinak je téměř jisté, že uživatelé znovu používají hesla s ohroženým webem). ), ale může to být možnost. Osobně bych ji v takovém případě využil jako příležitost pro upgrade své celkové infrastruktury pro ověřování - nasazení 2FA (ideálně U2F nebo lepší, nebo uživatelsky volitelné TOTP / HOTP, nikoli SMS), monitorování činnosti účtu atd. - spíše než spěchání změna jako zneplatnění hesel. Samostatná hesla na internetu již nepředstavují nejlepší postup ověřování uživatelů.

Pokud se vaše aplikace nebo web nachází na cloudflare a podléhá průmyslovým nebo národním předpisům, může se jednat o incident podléhající hlášení. (příklady by se týkaly zdravotní péče / ochrany osobních údajů v souvislosti s HIPAA). Vaše týmy pro bezpečnost a shodu by měly vyhodnotit. Úplný soulad s platnými předpisy je samozřejmě nezbytnou součástí bezpečnosti.

Subjektivně se domnívám, že se jedná o závažný bezpečnostní problém, a měla by být vyhodnocena každou významnou službou využívající Cloudflare. Pravděpodobně to není „konec světa“ v závažnosti, protože pokud by nedošlo ke koordinovanému škodlivému vykořisťování, zranitelná data jsou pravděpodobně spravedlivě distribuována po internetu náhodně, ale přítomnost dat v prohledávatelných mezipaměti by mohla umožnit využití v malém měřítku. Vzhledem k tomu, že zmírnění u koncových uživatelů je obecně dobrou radou (použijte správce hesel, používejte jedinečná náhodná hesla na jednotlivých webech, střídejte se při jakémkoli kompromisu), jedná se o „žádnou inteligenci“ pro většinu koncových uživatelů, kteří si uvědomují bezpečnost. Pro operátory stránek rozhoduje skutečně vaše konkrétní uživatelská základna a úroveň jejich sofistikovanosti zabezpečení a tolerance rizik. Velmi oceňuji jak probíhající práci projektu Google Zero (zejména Tavis), tak rychlou reakci společnosti Cloudflare na tento problém.