Samotný útok byl proveden ve více fázích a byl poměrně zajímavý. Pojďme se podívat na jednotlivé fáze útoku – co se stalo, jak to fungovalo a co by se dalo udělat, aby to příště útočníci neměli tak jednoduché.
Co se dozvíte v článku
Fáze 1 – převzetí kontroly nad SOHO routerem
Útok byl na počátku zaměřen na SOHO routery s jediným cílem: změnit adresu používaného DNS resolveru. Pokud byla tato fáze úspěšná, její výsledek nebyl snadno detekovatelný. Uživatelé se mohli dál připojovat k internetu a pracovat z domova jako vždy. Nic zjevně podezřelého se nedělo. Mohlo to zmást některé load-balancery založené na DNS, ale nečekal bych, že by to mělo výrazně postřehnutelný dopad.
Jeden konkrétní útok, o kterém se v této souvislosti hodně mluví, je útok na routery TP-Link WR841N prostřednictvím zranitelnosti CVE-2023–50224. Tato zranitelnost se dostala do středu pozornosti již loni na podzim. Byla opravena v aktualizaci určené pro některé revize tohoto routeru. Hlavním problémem však už tehdy bylo, že existovalo mnoho zařízení, která již neměla podporu, ale byla stále aktivně používána (a některé obchody je dokonce stále měly skladem). Zároveň existovalo i nemálo zařízení, pro která sice oprava k dispozici byla, ale nebyla aplikována.
To ukazuje, proč útok cílil právě na SOHO routery. V podnikovém prostředí bývá IT oddělení, které zajistí, že všechna zařízení mají stále podporu od dodavatele a že jsou na ně vždy aplikovány nejnovější záplaty. Doma tomu lidé tolik pozornosti nevěnují. Obzvlášť v případě routerů. Všimnou si, když je jejich telefon pomalejší, a vyměňují televize za větší modely s vyšším rozlišením. Ale router? To je malá krabička, která si spokojeně bliká někde v koutě a poskytuje připojení k internetu. Dokud svou práci odvádí použitelně, nikdo jí nevěnuje pozornost. Nikoho nezajímá, jak je stará, a nikdo pravidelně nekontroluje aktualizace.
Samozřejmě, zastaralý a zranitelný firmware není jediný způsob, jak si pozvat útočníka domů. Existují i další, například používání výchozího hesla nebo zpřístupnění webového rozhraní routeru z internetu. Ale ani firewall nemusí stačit. Zmiňované CVE bylo zneužíváno dokonce i pomocí škodlivého JavaScriptu běžícího v prohlížeči některého zařízení v lokální síti.
Jak zabránit útokům z první fáze?
Teoreticky je to jednoduché. Alespoň pokud jde o to, jak výrazně snížit počet snadno napadnutelných zařízení. Nejde přitom o nic technicky složitého, spíše o základní opatření.
Ujistěte se, že vaše zařízení je stále podporováno výrobcem
I zpráva z minulého podzimu upozorňuje na to, že část problému byla v tom, že zasaženy byly i routery, které se stále doprodávaly v některých obchodech, ale zároveň je už jejich výrobce nepodporoval. S příchodem CRA se to snad alespoň v Evropě zlepší. Každé zařízení prodávané v EU bude muset mít garantováno alespoň pět let bezpečnostních aktualizací.
Pokud je očekávaná doba používání delší, mělo by dostávat aktualizace ještě déle. CRA už sice vstoupil v platnost, jeho hlavní povinnosti se ale začnou uplatňovat až později. Mezitím si zkontrolujte, zda jsou vaše zařízení stále podporována výrobcem. Pokud ne, je lepší poohlédnout se po novém modelu.
Ujistěte se, že je aktualizované
Starost o aktualizace není úplně zábavná, ale je to základ veškeré bezpečnosti. Proto jsme se v Turrisu rozhodli pro automatické aktualizace už před více než deseti lety, když jsme začali vyrábět routery, a proto lidem doporučujeme tuto funkci využívat. Pokud nemáte router Turris od CZ.NIC, možná budete muset aktualizace kontrolovat a aplikovat ručně. Pokud to má uživatel dělat ručně, snadno na to zapomene, nebo to prostě odloží. Naštěstí se dnes už objevují i další routery, které automatické aktualizace podporují.
Takže až budete příště kupovat nový router, zkontrolujte si, jak dlouho bude podporován a zda umožňuje zapnout automatické aktualizace.
Nepoužívejte výchozí hesla nebo výchozí nastavení obecně
Za mých mladých let, když jste se prošli městem, tak jste viděli množství Wi-Fi sítí pojmenovaných podle různých výrobců routerů. Občas i bez hesla, často určitě s tím výchozím. Dnes už to tak běžné naštěstí není, přeci jen lidé přišli na to, že sdílet Wi-Fi se sousedy jí na rychlosti nepřidá. Ale i na druhou stranu, v malých rodinných hotýlcích a různých BnB pořád narazíte na sítě, kde máte dostupné administrátorské rozhraní routeru přímo vybízející k zadání kombinace admin/admin. I proto se různá výchozí hesla často objevují v top 10 v Turris Sentinel view.
Abychom se tomuto zlozvyku vyhnuli, při návrhu svých routerů jsme úmyslně nepoužili žádné výchozí heslo a zakázali jsme přístup k internetu, dokud si uživatel nenastaví vlastní. Protože pokud router vybalíte, zapojíte a všechno funguje bez jakéhokoliv nastavování, je to sice uživatelsky velmi přívětivé, ale pravděpodobně ne až tak bezpečné.
Kromě hesel může pomoci i nastavení IP adresy routeru na jinou hodnotu než 192.168.1.1. Jak již bylo zmíněno, existoval javascriptový útok, který cílil právě na tuto IP adresu.
Omezte přístup k administračnímu rozhraní
Dokonce i levné routery dnes podporují Wi-Fi pro hosty. Povolte ji a používejte pro zařízení, kterým nedůvěřujete. Nikdy neotevírejte administrační rozhraní do internetu. Pokud potřebujete router spravovat vzdáleně, nastavte si VPN. To nemusí být obecně snadné, ale je možné to zvládnout.
Fáze 2 – předávání DNS požadavků a špionáž
Když útočníci převzali kontrolu nad domácími routery, provedli v jejich nastavení jednu drobnou změnu: přesměrovali veškerý DNS provoz na své resolvery. Internet stále fungoval, všechno je dnes šifrované, takže to na první pohled nezní jako zásadní problém. Nebo ano? Háček je v tom, že používáním cizího DNS resolveru v podstatě dáváte jeho provozovateli k dispozici velkou část své historie. Nevidí jednotlivé webové stránky, jen názvy serverů. Ale i to může být poměrně citlivé. Obzvlášť pokud tyto informace předáte skupině útočníků, která si hledá vhodný cíl.
Pokud si to chcete vyzkoušet, zkuste si na počítači spustit tcpdump -i any port 53 -v a nechat si vystup logovat do nějakého souboru. Uvidíte, zda byste chtěli tyto informace veřejně zpřístupnit.
Typicky má tyto informace k dispozici váš poskytovatel připojení. Pokud chcete více soukromí, můžete použít například DNS over TLS a některý z otevřených resolverů dostupných na internetu. Pak vaši historii uvidí vámi vybraný poskytovatel a můžete se rozhodnout, zda důvěřujete společnostem jako Google a Cloudflare, nebo nebo někomu jako Quad9 a CZ.NIC.
Šifrované DNS si můžete nastavit i přímo ve svém prohlížeči nebo mobilu, takže nemusíte být odkázáni na resolver, který vám doporučí router.
Fáze 3 – útok MitM
Jakmile byly oběti vytipovány, následoval útok typu Man-in-the-Middle. V podstatě platí, že jakmile má útočník kontrolu nad vaším resolverem, může vybrat zajímavé domény a nechat je resolvovat na IP adresy pod svou kontrolou. Tímto způsobem nemusí být fyzicky „uprostřed“ komunikace, a dokonce nemusí být ani nikde poblíž. Zároveň si může snadno vybrat pouze zajímavé služby. Zbytek vašeho internetu funguje beze změny. Podobný přístup ve skutečnosti používají různá bezpečnostní řešení založená na DNS. Znemožní vám připojit se k „závadnému“ serveru a místo toho vás přesměrují na server s chybovou zprávou.
Lze se proti tomuto typu útoku bránit? Tedy v případě, že váš resolver obsahuje podvržené záznamy? Samozřejmě. Už dlouhou dobu existuje jednoduché řešení: DNSSEC. Vlastník zóny v takovém případě podepisuje všechny její záznamy a vy tak máte možnost ověřit si jejich pravost. Doména .cz je v této oblasti dlouhodobým průkopníkem.
Existují routery, které mají ověřování pomocí DNSSEC zapnuté ve výchozím nastavení, takže ani při dotazování resolveru pod kontrolou útočníků nehrozí přesměrování na podvrženou adresu. Bohužel se tato funkce objevuje u routerů spíše vyjímečně. Existuje i možnost používat plně rekurzivní resolver přímo na routeru – nemusíte dotazy nikam přesměrovávat a můžete se spolehnout jen sami na sebe, ale tento setup je ještě vzácnější než DNSSEC.
Další možností, jak zajistit ověřování pomocí DNSSEC, je nastavit ověřování přimo ve vašem OS. Podívejme se na typický příklad – Linuxu se systemd. Systemd je dnes nejběžnější init systém mezi linuxovými distribucemi. Jednou z jeho služeb je systemd-resolved — lokální DNS resolver, jehož vhodným nastavením můžete ověřování DNSSEC vynutit. Ve stejném démonu lze také zapnout použití DNS over TLS pro větší soukromí.
Níže můžete vidět příklad konfigurace, kterou lze vložit do konfiguračního souboru /etc/systemd/resolved.conf.d/dns-tweaks.conf. Zajistí použití DNSSEC, pokusí se použít DNS over TLS, kdykoli je to možné, a jako záložní DNS resolvery použije ODVR od CZ.NIC.
[Resolve] DNSSEC=true DNSOverTLS=opportunistic FallbackDNS=193.17.47.1 185.43.135.1 2001:148f:ffff::1 2001:148f:fffe::1
Fáze 4 – sběr přihlašovacích údajů
Doteď jste mohli vidět, jak útok začal a jak postupoval. Jak postupně gradoval. Pravděpodobně očekáváte, stejně jako já, velké finále. Realita je bohužel mnohem všednější.
Nakonec se útočníkům podařilo ukrást přihlašovací údaje, především k účtům MS Outlook. Udělali to prostřednictvím útoku Man-in-the-Middle zmíněného ve třetí fázi.
Když jsem se o tom dozvěděl, byl jsem opravdu zvědavý. Dnes je TLS normou a každá slušná stránka, včetně Outlooku, používá HSTS. S těmito technologiemi je opravdu těžké nevšimnout si, že se děje něco podezřelého. Na HSTS jsem narazil i já. Zjistil jsem, že na moderním systému je opravdu obtížné ignorovat chyby TLS, když jsem si rozbil nastavení webu na vlastním serveru. Jak se to tedy útočníkům podařilo?
Snadno. Prostě spoléhali na to, že lidé jsou vytrvalí, ignorují varování a své přihlašovací údaje jim pošlou i tak. Protože v bezpečnosti platí, že uživatel musí být bdělý pořád, ale útočníkovi stačí nachytat ho jen jednou. I když moderní systémy dělají maximum pro to, aby vás upozornily, že posílat přihlašovací údaje na stránku s neplatným certifikátem není dobrý nápad, lidé to stejně udělají.
Umíme se bránit
Viděli jsme, jak útok začal a jak postupoval. Existují technologie, které by proti němu mohly pomoci? Ano. Je důležité zajistit, aby lidé používali zařízení, která jejich výrobci stále podporují, a instalovali nejnovější aktualizace. To by výrazně snížilo počáteční dopad. Použití DNSSEC na klientech by zase zabránilo útoku Man-in-the-Middle.
Ve finální fázi byla už ale veškerá potřebná technologie na místě. Měla poslednímu útoku zabránit — a fungovala. Koncoví uživatelé se však dostatečně snažili ignorovat všechna varování. Ano, technologie mohla výrazně pomoci, ale nakonec zůstává nejzranitelnějším dílem celé skládačky člověk za počítačem, který se navzdory všem varováním rozhodne s útočníky spolupracovat.
