technika útoku (CVE-2019-14899), která umožňuje podvrhnout, změnit nebo dodat pakety v TCP spojení, procházejícími VPN tunely. Problém se týká systémů Linux, FreeBSD, OpenBSD, Android, macOS, iOS a dalších Unix-podobných systémů. Linux podporuje mechanismus rp_filter (filtrace zpětné cesty) pro IPv4, jehož zapnutí v režimu „Strict“ neutralizuje tento problém.
Metoda umožňuje podvržení paketů na úrovni TCP spojení procházejících šifrovaným tunelem, ale neumožňuje zasahovat do spojení, která používají další vrstvy šifrování (například TLS, HTTPS, SSH). Použité šifrovací algoritmy v VPN nejsou rozhodující, neboť podvržené pakety přicházejí z externího rozhraní a jádro je zpracovává jako pakety z VPN rozhraní. Nejpravděpodobnější cílem útoku je zasahování do nezašifrovaných HTTP spojení, ale i na možnost použití útoku k manipulaci s odpověďmi DNS.
Úspěšné podvržení paketů bylo demonstrováno pro tunely vytvářené pomocí OpenVPN, WireGuard a IKEv2/IPSec. Tor není tímto problémem postižen, protože používá SOCKS k přesměrování provozu a vazbu na loopback rozhraní. Pro IPv4 je útok možný v případě přepnutí rp_filter do režimu „Loose“ (sysctl net.ipv4.conf.all.rp_filter = 2). Původně byl v většině systémů použit režim „Strict“, ale od , vydaného v prosinci minulého roku, byl režim práce ve výchozím stavu změněn na „Loose“ a tato změna se projevila v nastavení výchozích hodnot mnoha distribucí Linuxu.
Mechanismus rp_filter pro dodatečné ověření cest průchodu paketů za účelem prevence podvržení adresy zdroje. Pokud je nastaven na hodnotu 0, není prováděno ověření adresy zdroje a jakýkoli paket může být neomezeně přesměrován mezi síťovými rozhraními. Režim 1 „Strict“ zahrnuje ověření každého příchozího externího paketu na odpovídající záznam v routovací tabulce, a pokud není síťové rozhraní, přes které byl paket přijat, spojeno s optimální cestou pro doručení odpovědi, je paket odmítnut. Režim 2 „Loose“ zmírňuje kontrolu, aby umožnil funkčnost při použití vyrovnávačů zátěže nebo asymetrického směrování, kdy
cesta odpovědi může procházet jiným síťovým rozhraním, než přes které přišel příchozí paket.
V režimu 'Loose' se příchozí paket kontroluje podle směrovací tabulky, ale je považován za platný, pokud je adresa zdroje dosažitelná přes jakékoli dostupné síťové rozhraní. Navrhovaný útok spočívá v tom, že útočník může poslat paket se změněnou adresou zdroje, odpovídající rozhraní VPN, a i když tento paket dorazí do systému přes vnější síťové rozhraní, nikoli přes VPN, v režimu rp_filter 'Loose' nebude takový paket odmítnut.
K provedení útoku musí útočník kontrolovat bránu, přes kterou se uživatel připojuje k síti (například prostřednictvím MITM útoku, když se oběť připojuje k bezdrátovému přístupovému bodu ovládanému útočníkem, nebo přes ). Kontrolováním brány, přes kterou je uživatel připojen k síti, může útočník posílat falešné pakety, které budou vnímány ve kontextu síťového rozhraní VPN, ale odpovědi budou směrovány přes tunel.
Generováním toku falešných paketů, ve kterých je vkládána IP adresa rozhraní VPN, se pokoušejí ovlivnit zřízené spojení, avšak vliv těchto paketů lze sledovat pouze pasivní analýzou šifrovaného toku dat souvisejícího s provozem tunelu. K provedení útoku je nutné zjistit přidělenou IP adresu síťového rozhraní tunelu ze strany VPN a také zjistit, že v současnosti existuje aktivní spojení s určitým hostitelem.
Pro stanovení IP virtuálního síťového rozhraní VPN se na systém oběti posílají SYN-ACK pakety, přičemž se postupně procházejí celý rozsah virtuálních adres (nejprve se procházejí adresy používané ve VPN výchozím způsobem, například v OpenVPN se používá podsíť 10.8.0.0/24). O existenci adresy lze usuzovat na základě přijetí odpovědi s příznakem RST.
Podobně se určuje existence spojení s konkrétní stránkou a číslo portu na straně klienta - procházením čísel portů se na uživatelském straně odesílá SYN paket, přičemž jako zdrojová adresa je použita IP adresa stránky a cílová adresa je virtuální IP VPN. Serverový port lze předpokládat (80 pro HTTP), zatímco číslo portu na straně klienta lze vypočítat procházením a analýzou změn intenzity ACK odpovědí v kombinaci s absencí balíčku s flagem RST.
V této fázi útočník zná všechny čtyři prvky spojení (adresy/port IP zdroje a adresu/port IP cíle), ale aby mohl vygenerovat falešný paket, který systém oběti akceptuje, musí útočník určit čísla sekvence a potvrzení (seq a ack) TCP spojení. K určení těchto parametrů útočník neustále odesílá falešné RST pakety, přičemž prochází různá čísla sekvence, dokud nezaznamená odpovědní ACK paket, jehož příjem naznačuje, že číslo leží v TCP okně.
Následně útočník ověřuje správnost určení odesíláním paketů se stejným číslem a sleduje příjem ACK odpovědí, přičemž následně určuje přesné číslo aktuální sekvence. Úkol je ztížen tím, že odpovědi jsou odesílány uvnitř šifrovaného tunelu a jejich analýza v zachyceném toku dat je možná jen nepřímými metodami. Skutečnost odeslání ACK paketu adresovaného VPN serveru klientem je určena na základě velikosti a zpoždění šifrovaných odpovědí, které korelují s odesláním falešných paketů. Například pro OpenVPN šifrovaný paket o velikosti 79 umožňuje přesně usoudit, že uvnitř je obsažena ACK potvrzení.
Předtím, než bude ochrana proti útoku přidána do jádra operačního systému, jako dočasná metoda blokování problému pomocí paketového filtru v řetězci „preroute“ blokovat průchod paketů, ve kterých je jako cílová adresa uvedena virtuální IP adresa tunelu.
iptables -t raw -I PREROUTING ! -i wg0 -d 10.182.12.8 -m addrtype ! --src-type LOCAL -j DROP
nebo pro nftables
nft add table ip raw
nft add chain ip raw prerouting '{ type filter hook prerouting priority 0; }'
nft add rule ip raw prerouting 'iifname != "wg0" ip daddr 10.182.12.8 fib saddr type != local drop'
Pro ochranu při používání tunelů s adresami IPv4 stačí přepnout rp_filter do režimu „Strict“ („sysctl net.ipv4.conf.all.rp_filter = 1“). Z pohledu VPN může být metoda určení čísel sekvencí blokována přidáním doplňkového vyplnění k zašifrovaným paketům, což zajistí, že všechny pakety budou mít stejnou velikost.
Zdroj: opennet.ru
