Názory k článku JavaScript může přistoupit do vnitřní sítě a obejít same-origin policy

> Byl objeven nový způsob, kterým může být JavaScript na libovolném webu zneužit pro útok na vnitřní sít okolo uživatelova počítače.

Prošel jsem článek, našel jsem několik zajímavých a méně známých útoků, které pro mě ale nebyly úplně novinkou. Co je tedy onen „nový způsob“?

To byla samozřejmě chyba, dál v článku je napsáno, že to nové není. Díky, opraveno.

Vždy hlavní linií obrany je bránit se příchozím útokům. V LAN je to problematičtější, ale ne nemožné. Když pominu stanice, u kterých mě víceméne moc nezajímá, co se s nimi stane, tak na serverech je vždy firewall i v rámci LAN. Dokonce jsem zastáncem nastavení, aby na serverech byla filtrována i nová odchozí spojení.

Metody, které brání šíření hrozeb - což je mimo jiné téma tohoto článku, nebo i právě blokování odchozích spojení na serveru, jsou až druhá linie obrany. Ta sníží rizika, ale nikdy je nemůže snížit na takovou úroveň, jako je příchozí ochrana.

Ať už na konci tohoto článku, nebo i v jiných souvislostech, vždy dojdeme k tomu, že je nutné počítat s tím, že nějaké zařízení v LAN bude napadeno a pak se může snažit šířit dál i v rámci LAN. To je zejména kvůli tomu, že na switchi nebývají kontroly jako na hraničních routerech / firewallech, tím, že rychlost a odezvy v rámci LAN jsou bleskové, a že dlouho nemusí dojít k zaznamenání problému (oproti tomu, kdyby nákaza vytížila externí linku - toho si admin všimne dřív).

Firewall Vám moc nepomůže, pokud se klient může legitimně připojit na daný server. Někdy se dokonce může připojit i z prohlížeče. Pak firewall nemusí umět rozlišit legitimní a útočný paket. Dokonce oba mohou přijít v rámci téhož TCP streamu.

Na DNS rebind pomůže na serveru kontrolovat doménové jméno. Útočník v rámci DNS rebind attacku by neměl mít šanci například zfalšovat hlavičku Host. Ledaže by někdo měl archaický prohlížeč, což ale bude nejspíš samo o sobě větší problém.

S osaháváním sítě je to složitější – tam asi bude nejlepší to považovat za vlastnost a počítat s tím. Ostatně, pokud s tím nepočítáte, jde nejspíš o security by obscurity.

Bránit by tomu mohl firewall na samotné stanici a kontrolovat odchozí provoz. Browser sice může mít globálně povolený http/https provoz, ale již ne další porty. Měl by pak ideálně mít povolený provoz do internetu, ale ne do celé vnitřní sítě.

Jenže pokud ten browser používáte ke správě zařízení ve vnitřní síti (přes různá klikací webová rozhraní například), těžko mu můžete vnitřní síť zakázat.
To samé platí ovšem i pro různé další programy, například pro multimediální přehrávač, který si "parsuje" internetové zdroje informací o multimédiích, přehrávaných z vnitřní sítě (via WebDAV). Ten by sice neměl JS spouštět - ale věřte tomu...

Jak rozliší prohlížeč obecně, co je „internet“ a co vnitřní síť? U IPv4 by to mohly být neveřejné adresy, ale jak u IPv6? Neboli je to vůbec koncepční řešení?

Nejsem expert na IPv6, ale neveřejné adresy tam IMHO jsou: https://en.m.wikipedia.org/wiki/Private_network

K nim byste ovšem potřeboval ještě rovnák na ten ohejbák, tedy překlad adres. A to nikdo nedělá - proč taky, když je IPv6 adres dost?
Celé to spíš zdůrazňuje to, že ani v IPv4 s NAT nesmíte ten NAT považovat za náhradu firewallu. Tohle je jen další způsob, jak přes NAT projít a tedy i lokální služby si zaslouží řádné zabezpečení.

> K nim byste ovšem potřeboval ještě rovnák na ten ohejbák, tedy překlad adres.

Pokud budete chtít z těch strojů ven a nespokojíte se s proxy (což je ale vlastně jen převlečenej překlad adres), pak to asi bez něj nepůjde. Ono to je vždy něco za něco. Můžeme mít:

a. Veřejné IP adresy, pak sice firewallem můžeme omezit přístup na ně zvenku, ale ztíží nám to filtrování odrazových můstků. Tedy, pokud se mi někdo dostane třeba do aplikace pro přehrávání hudby (která „nemá přístup k ničemu citlivému), těžko mu pak zabráním přístupu do lokální sítě. Zvlášť pokud z téhož počítače tam přístup potřebuju. Ledaže bych blacklistoval rozsahy IP pro konkrétní síť, pak mi ale ten NAT přijde jako menší zlo.
b. Lokální IP adresy, pak pro přístup ven potřebujete NAT/proxy nebo něco podobného (případně přístup ven můžete zcela zakázat), ale máte větší šance uhlídat přístup zvenku.
c. Veřejné IP adresy a omezit různé sandboxy, protože takový „virtuální stroj s přístupem k Internetu bez přístupu do lokální sítě“ bude iluzí. Nepřijde mi to moc praktické, sandboxy mají význam pro bezpečnost i pro pohodlí.

Já jsem pro řešení bezpečnosti na každém endpointu a jsem rozhodně proti přístupu „toto je v lokální síti, tam nic nehrozí“. Když už se tak ale někdo rozhodne, měl by to vzít do důsledků:

* Dávat veřejnou IP stroji nedostupnému zvenku sice lze, ale není pak praktické vše uhlídat. Ostatně i laikovi by kombinace veřejné IP a stroje nedostupného zvenku mohla přijít jako protimluv. Ostatně čemu vadí NAT u případů, kde chceme síť omezit?
* Je potřeba si být vědom útoků jako DNS rebind a podobných.
* Útok na jakýkoli „nedůležitý“ stroj je pak potenciálně útokem na celou síť.

A proč to rozlišovat obecně? Administrátor nastavující firewall na pracovní stanici přece ví, který rozsah je vnitřní síť.

Good point. Záleží na scénáři. Já si tak třeba nastavil svůj notebook a kamkoli ho připojím, jen vybrané virtuálky mají přístup do vnitřní sítě. Pokud chcete řešit přístup do jediné sítě (a jinde je vám to jedno), pak můžete postupovat zmíněným způsobem.

Já se spíše těším na ten humbuk okolo elektronického podpisu PDF. Během dubna bude o čem psát. :-)

Článek mi přijde trochu podobný tomuto = https://www.bleepingcomputer.com/news/security/assessing-internal-network-with-javascript-despite-same-origin-policy/

Což je logické, protože oba vycházejí ze stejného odkazovaného dokumentu.

teda jak sis to dovolil pouzit stejnej zdroj jako jinej clanek? :-))

pfSense má obranu proti DNSRebind attakům viz:

https://docs.netgate.com/pfsense/en/latest/dns/dns-rebinding-protections.html

Konkrétně: rejects and logs addresses from upstream nameservers which are in the private IP ranges.

Když jsme dělali PoC a pak přímo úlohy pro CTF, tak jsme právě tuhle funkcionalitu museli vypínat, jinak by PoC neprošlo :-)

Kam ten firewall nasadíte, koho tím ochráníte a co tím zboříte?

* Nasadit na stanici znamená zbořit lokální DNS. (Myšleno DNS záznamy, které legitimně ukazují do lokální sítě.) Ledaže bychom je nějak whitelistovali.
* Nasadit někam do sítě je sice kompatibilní s lokálním DNS (pokud někdo lokální DNS ovšem neobejde), ale pro přenosná zařízení to není 100 % – útok mohu začít v cizí síti a dokončit ve firemní, kde už nepotřebuju DNS.
* Navíc tu je jinde nastíněný problém s IPv6…