támadási technika (CVE-2019-14899), amely lehetővé teszi a csomagok hamisítását, módosítását vagy helyettesítését a VPN-alagutakon keresztül továbbított TCP-kapcsolatokban. A probléma Linux, FreeBSD, OpenBSD, Android, macOS, iOS és más Unix-szerű rendszereket érint. A Linux támogatja az rp_filter (fordított útvonalú szűrés) mechanizmust az IPv4-hez, ha „Szigorú” módban kapcsolja be, semlegesíti ezt a problémát.
A módszer lehetővé teszi a csomagok helyettesítését a titkosított alagútban áthaladó TCP-kapcsolatok szintjén, de nem teszi lehetővé a további titkosítási rétegeket (például TLS, HTTPS, SSH) használó kapcsolatokba való beékelődést. A VPN-ben használt titkosítási algoritmusok nem számítanak, mivel a hamisított csomagok a külső interfészről származnak, és a kernel a VPN interfészről érkező csomagokként dolgozza fel őket. A támadás legvalószínűbb célpontja a titkosítatlan HTTP-kapcsolatok zavarása, de és támadást használnak a DNS-válaszok manipulálására.
Az OpenVPN, a WireGuard és az IKEv2/IPSec használatával létrehozott alagutak esetében sikeres csomaghamisítást mutattak be. A Tor nem érzékeny a problémára, mivel SOCKS-t használ a forgalom továbbítására, és visszacsatolási felülethez van kötve. IPv4 esetén a támadás akkor lehetséges, ha az rp_filter „Laza” módra van állítva (sysctl net.ipv4.conf.all.rp_filter = 2). Kezdetben a legtöbb rendszer a „szigorú” módot használta, de kezdetben , amely tavaly decemberben jelent meg, az alapértelmezett működési mód „Laza”-ra változott, és ez a változás számos Linux-disztribúció alapértelmezett beállításaiban is megmutatkozott.
rp_filter mechanizmus a csomagútvonalak további ellenőrzéséhez a forráscím-hamisítás megelőzése érdekében. Ha 0-ra van állítva, akkor nem történik forráscím-ellenőrzés, és bármely csomag korlátozás nélkül továbbítható a hálózati interfészek között. Az 1. „Szigorú” mód magában foglalja minden kívülről érkező csomag ellenőrzését, hogy megfelelnek-e az útválasztási táblázatnak, és ha a hálózati interfész, amelyen keresztül a csomag érkezett, nincs hozzárendelve az optimális válaszkézbesítési útvonalhoz, akkor a csomag eldobásra kerül. A 2. mód "Laza" lazítja az ellenőrzést, hogy lehetővé tegye a terheléselosztók vagy az aszimmetrikus útválasztás működését
A válaszútvonal más hálózati interfészen is áthaladhat, mint amelyen a bejövő csomag érkezett.
Laza módban a bejövő csomagokat a rendszer ellenőrzi az útválasztási táblával, de akkor tekinthető érvényesnek, ha a forráscím bármely elérhető hálózati interfészen keresztül elérhető. A javasolt támadás azon alapul, hogy a támadó a VPN-interfésznek megfelelő, hamisított forráscímű csomagot küldhet, és annak ellenére, hogy ez a csomag a külső hálózati interfészen, nem pedig a VPN-en keresztül jut be a rendszerbe, a rp_filter „Laza” módban egy ilyen csomag nem kerül eldobásra.
A támadás végrehajtásához a támadónak ellenőriznie kell azt az átjárót, amelyen keresztül a felhasználó hozzáfér a hálózathoz (például egy MITM-szervezeten keresztül, amikor az áldozat csatlakozik egy támadó által vezérelt vezeték nélküli hozzáférési ponthoz, vagy ). Azzal az átjáróval, amelyen keresztül a felhasználó csatlakozik a hálózathoz, a támadó hamis csomagokat küldhet, amelyek a VPN hálózati interfész kontextusában észlelhetők, de a válaszok az alagúton keresztül lesznek továbbítva.
A VPN interfész IP-címét helyettesítő fiktív csomagok folyamának generálásával megpróbálják befolyásolni a kliens által létrehozott kapcsolatot, de ezeknek a csomagoknak a hatása csak a kapcsolódó titkosított forgalom passzív elemzésével figyelhető meg. az alagút működésével. A támadás végrehajtásához meg kell találnia a VPN-kiszolgáló által hozzárendelt alagúthálózati interfész IP-címét, és azt is meg kell határoznia, hogy az alagúton keresztül aktív-e a kapcsolat egy adott gazdagéppel.
A VPN virtuális hálózati interfész IP-címének meghatározásához SYN-ACK csomagokat küldenek az áldozat rendszerébe, amelyek sorban felsorolják a virtuális címek teljes tartományát (elsősorban a VPN-ben használt címek vannak felsorolva alapértelmezés szerint, például OpenVPN a 10.8.0.0/24 alhálózatot használja). A cím megléte az RST jelzővel ellátott válasz beérkezése alapján ítélhető meg.
Hasonló módon kerül meghatározásra egy adott telephellyel való kapcsolat megléte és a kliens oldalon lévő portszám - a portszámok válogatásával a felhasználónak forráscímként egy SYN csomagot küldenek, amelyben az oldal Az IP helyére kerül, és a célcím egy virtuális IP VPN. Megjósolható a szerver portja (HTTP esetén 80), a kliensoldali portszám pedig nyers erővel számítható ki, különböző számokra elemezve az ACK válaszok intenzitásának változását az RST-vel rendelkező csomag hiányával kombinálva. zászló.
Ebben a szakaszban a támadó ismeri a kapcsolat mind a négy elemét (forrás IP-cím/port és cél IP-cím/port), de ahhoz, hogy egy fiktív csomagot generáljon, amelyet az áldozat rendszer elfogad, a támadónak meg kell határoznia a TCP-szekvenciát, nyugtázási számok (seq és ack) - kapcsolatok. Ezen paraméterek meghatározásához a támadó folyamatosan hamis RST-csomagokat küld, különböző sorszámokkal próbálkozva, amíg nem észlel egy ACK válaszcsomagot, amelynek megérkezése jelzi, hogy a szám a TCP ablakba esik.
Ezután a támadó tisztázza a definíció helyességét az azonos számú csomagok elküldésével és az ACK válaszok érkezésének megfigyelésével, majd kiválasztja az aktuális sorozat pontos számát. A feladatot nehezíti, hogy a válaszokat egy titkosított alagútban küldik, és jelenlétük az elfogott forgalomban csak közvetett módszerekkel elemezhető. Azt, hogy egy kliens küld-e ACK-csomagot a VPN-kiszolgálónak, a titkosított válaszok mérete és késleltetése határozza meg, amelyek korrelálnak a hamisított csomagok küldésével. Például az OpenVPN esetében a 79-es titkosított csomagméret lehetővé teszi, hogy pontosan meg tudja ítélni, hogy van-e benne ACK.
Mindaddig, amíg a támadás elleni védelmet nem adják hozzá az operációs rendszer kerneléhez a probléma ideiglenes blokkolására az „előútvonal” láncban található csomagszűrő használatával blokkolja azon csomagok áthaladását, amelyekben az alagút virtuális IP-címe van megadva célcímként.
iptables -t raw -I PREROUTING ! -i wg0 -d 10.182.12.8 -m addrtype ! --src-type LOCAL -j DROP
vagy az nftables számára
nft táblázat hozzáadása ip raw
nft add chain ip raw prerouting ‘{ type filter hook prerouting priority 0; }'
nft add szabály ip raw prerouting ‘iifname != “wg0” ip daddr 10.182.12.8 fib saddr type != local drop’
Az IPv4-című alagutak használatakor az rp_filtert állítsa „Szigorú” módba (“sysctl net.ipv4.conf.all.rp_filter = 1”), hogy megvédje magát. A VPN oldalon a sorszám-észlelési módszer blokkolható a titkosított csomagok extra kitöltésével, így az összes csomag azonos méretű.
Forrás: opennet.ru