Chrome omezí webům přístup do místní sítě: brání útokům dle standardu PNA

Vývojáři prohlížeče Chrome minulý týden oznámili, že začnou webovým stránkám zakazovat přímý přístup do místní sítě. Tato aktivita je součástí velkého balíku změn, které mají za cíl zabránit útokům na síťová zařízení skrze webový prohlížeč.

Změna se nedotkne přístupu prohlížeče do místní sítě, uživatelé budou moci stále přistupovat ke svým zařízením a třeba spravovat je skrze webové rozhraní. Cílem je chránit uživatele před útoky typu cross-site request forgery (CSRF), které cílí na směrovače a další zařízení v síti, případně na služby spuštěné na stejném stroji jako prohlížeč.

Nejde o teoretický útok, ale takto už byly napadeny stovky tisíc uživatelů, kteří byli například následně přesměrováni na podvržené webové stránky. Útočník je schopen takto z prohlížeče oslovit například místní směrovač, zneužít známé zranitelnosti či výchozích přihlašovacích údajů a změnit uživatelem používaný DNS resolver. V roce 2014 bylo objeveno 300 000 zařízení napadených tímto způsobem. Šlo o směrovače značek Asus, D-Link, Cisco, Linksys, Micronet,  Netgear, Tenda a TP-Link. Jde ale o obecný typ útoku, kterým je možné oslovovat libovolné zařízení uvnitř sítě, přestože je za firewallem. Prohlížeč pak funguje jako nezamýšlená proxy.

Příklad útoku CSRF

Řekněme, že v cílové síti je jednoduchý domácí směrovač, který umožňuje konfigurovat DNS pomocí webového rozhraní. To není díky firewallu dostupné z internetu, takže uživatele ani nenapadne, že by mohlo dojít k napadení. Útočník ovšem připraví zákeřnou stránku a uživatele na ni nějakým způsobem přivede.

Součástí této stránky je také následující kód:

<iframe href="https://admin:admin@router.local/set_dns?server1=123.123.123.123">
</iframe>

Prohlížeč se bude snažit obsah zobrazit, pomocí Multicast DNS přeloží místní adresu na IP adresu a požadavek na ni odešle. Pokud jsou přihlašovací údaje správné, zařízení dostane požadavek z vnitřní sítě a provede jej. Uživatel nic nezaznamená, přesto mu právě útočník překonfiguroval DNS resolver a může ho přesměrovávat na své servery.

Většina uživatelů pravděpodobně ani netuší, že je takový útok možný. Existují podstatně sofistikovanější varianty, které například využívají metody zvané DNS rebinding. Ta dovoluje obejít same-origin policy a JavaScriptem kontaktovat z libovolného webu libovolný jiný zdroj. Vyžaduje spolupracující autoritativní DNS server, který pro jedno doménové jméno nejprve vrátí veřejnou adresu serveru s útočným skriptem a při dalším požadavku pak provede překlad na místní adresu. Protože prohlížeč kontroluje pouze doménové jméno, povolí skriptu kontaktovat adresu v místní síti.

Podobným typům útoků není možné zabránit, pokud prohlížeč nebude k místním zdrojům přistupovat jinak něž k těm veřejným. Právě proto ve W3C vzniká standard Private Network Access (dříve CORS-RFC1918), kterým se brzy začne Chrome řídit.

Co je to místní síť?

Nejprve je potřeba si říct, co je v tomto případě považováno za místní síť. Přehledně to shrnuje následující tabulka uvedená ve zmíněném standardu:

Připravované omezení se týká síťových požadavků, které směřují z méně soukromého adresního rozsahu do rozsahu soukromějšího. Například požadavek pocházející z dokumentu získaného z veřejného rozsahu, který směruje do naší privátní sítě. Nebo požadavek z privátní sítě do localhostu.

Autor: Google

Vztah mezi veřejnou, soukromou a místní sítí ve standardu PNA

Autoři standardu uznávají, že toto jednoduché rozdělení má své nevýhody spočívající ve falešné pozitivitě i negativitě. Například můžeme mít přístup ke dvěma privátním sítím, přičemž by bylo legitimní, abychom uvnitř těchto sítí požadavky předávali. Standard to ale přechází s tím, že jde o pragmatické řešení, které bude vyhovovat většině běžných síťových prostředí.

Předletová kontrola

Pokud se tedy dokument (webová stránka) načtený z veřejné adresy pokouší poslat požadavek na některou z neveřejných adres, přichází standard PNA s novým síťovým požadavkem (preflight), kterým si prohlížeč vyžádá explicitní povolení ke kontaktování privátního zdroje.

Prohlížeč tedy vyšle směrem na cíl požadavek, jehož součástí bude hlavička:

Access-Control-Request-Private-Network: true

Místní cíl pak může předat povolení tím, že v odpovědi odešle hlavičku:

Access-Control-Allow-Private-Network: true

Tyto hlavičky jsou odesílány bez ohledu na použitou metodu a jsou odesílány také při požadavcích splňujících pravidlo same-origin, pokud je cílová adresa soukromější než původní zdrojová. Tento mechanismus brání zmíněnému útoku DNS rebinding.

Naopak stránka má možnost proaktivně zahodit oprávnění přístupu k soukromým adresním rozsahům. Prohlížeč k ní pak bude přistupovat, jako by pocházela z veřejného adresního rozsahu, přestože byla stažena z místního zdroje. Provedeme to pomocí direktivy treat-as-public-address v hlavičce CSP. Pokud takto označený dokument bude chtít kontaktovat místní adresy, musí pro něj prohlížeč získat výše popsané povolení.

Co se mění v Chrome

Vývojáři a uživatelé prohlížeče Chrome se na změnu připravují už nějakou dobu. Kód je už součástí Chrome 96, ale bude aktivován postupně, aby bylo možné se na změnu připravit. Od Chrome verze 98 bude aktivován v testovacím režimu, kdy začnou být odesílány zmíněné požadavky preflight. Při neobdržení povolení ještě nedojde k žádnému omezení komunikace, ale ve vývojářské konzoli už se budou objevovat varování.

Autor: Google

Důrazné varování ve vývojářské konzoli

Pokud chcete vše vyzkoušet naostro a otestovat, jak se bude váš web chovat po zapnutí blokace, můžete Chrome spustit s následujícím parametrem, který vynutí respektování testu:

--enable-features=PrivateNetworkAccessRespectPreflightResults

Pokud se neobjeví neočekávané problémy v této testovací fázi, měla by být od Chrome verze 101 naplno aktivována zmíněná ochrana. Pokud se tedy stránka z veřejného zdroje pokusí kontaktovat lokální zdroj, bude k tomu muset dostat explicitní povolení.

Správci mohou svým uživatelům v síti tuto vlastnost vypnout použitím politiky InsecurePrivateNetworkRequ­estsAllowed. Případně je možné dočasně se přihlásit k výjimce a než vaši vývojáři připraví potřebné změny, je možné do web serverů přidávat hlavičku  Origin-Trial: $token. Tato možnost ale definitivně skončí v květnu. Pokud vás tato možnost zajímá, přečtěte si podrobnou dokumentaci.

Co bude dál

Jak už bylo řečeno, tato změna je součástí širšího plánu na vylepšení bezpečnosti týkající se místní sítě. V první fázi budou omezovány pouze požadavky z veřejných adres, které budou směřovat na místní adresy či localhost.

Standard PNA ale hovoří o tom, že problémem jsou i požadavky z místních adres směrem na localhost. Časem proto bude omezen i tento typ komunikace, ale vyžaduje to vyřešit některé problémy. Zejména to, že místní servery často nedisponují doménovým jménem, takže není možné stejným způsobem nabídnout správcům možnost výjimky.

Chrome také zatím blokuje jen sub-požadavky vycházející z načtených veřejných stránek. Neřeší ale navigaci na privátní adresy – například pomocí přesměrování. Standard PNA ovšem mezi těmito dvěma typy požadavků nerozlišuje, protože i požadavek při přesměrování by mohl vést k útoku typu CSRF. Vývojáři počítají s tím, že i tento typ požadavků se tedy časem stane předmětem stejných omezení.