támadási technika (CVE-2019-14899), amely lehetővé teszi TCP-kapcsolatokban a csomagok hamisítását, módosítását vagy behelyezését, VPN-alagútakon keresztül. A probléma érinti a Linuxot, FreeBSD-t, OpenBSD-t, Androidot, macOS-t, iOS-t és más Unix-alapú rendszereket. A Linux támogatja az rp_filter (fordított útvonal szűrés) mechanizmust az IPv4 számára, amelynek „Strict” módba állítása semlegesíti ezt a problémát.
A módszer lehetővé teszi csomagok behelyettesítését TCP-kapcsolatok szintjén, amelyek titkosított alagúton belül haladnak, de nem engedi, hogy beilleszkedjenek az olyan kapcsolatokba, amelyek további titkosítási rétegeket alkalmaznak (például TLS, HTTPS, SSH). A VPN-ben használt titkosítási algoritmusoknak nincs jelentősége, mivel a hamis csomagok a külső interfészből érkeznek, és a kernel VPN-interfészként kezeli őket. A támadás legvalószínűbb célpontja a titkosítatlan HTTP kapcsolatok megzavarása, de a támadás DNS-válaszok manipulálására is.
A csomagok sikeres hamisítását OpenVPN, WireGuard és IKEv2/IPSec által létrehozott alagútok esetében demonstrálták. A Tor nem érintett a problémával, mivel SOCKS-t használ a forgalom átirányítására és ciklusba zárt interfészhez köti azt. Az IPv4 esetében a támadás akkor lehetséges, ha az rp_filter-t „Loose” módba kapcsolják (sysctl net.ipv4.conf.all.rp_filter = 2). Eredetileg a legtöbb rendszer „Strict” módban működött, de a , amelyet tavaly decemberben adtak ki, az alapértelmezett módot „Loose”-ra cserélte, és ez a változás tükröződik számos Linux disztribúció alapbeállításaiban.
Az rp_filter mechanizmus az útvonalak további ellenőrzésére a csomagok forráscímének hamisítása elleni védelem érdekében. Ha 0-ra van állítva, a forráscím ellenőrzése nem történik meg, és bármely csomag korlátozás nélkül átirányítható a hálózati interfészek között. Az 1-es „Strict” mód bekapcsolja az összes külső, bejövő csomag ellenőrzését a routing táblának való megfelelés szempontjából, és ha az a hálózati interfész, amelyen a csomaget fogadták, nem kapcsolódik az optimális válasz-elérési útvonalhoz, akkor a csomagot elvetik. A 2-es „Loose” mód enyhíti az ellenőrzést, hogy lehetővé tegye a működést terheléselosztók vagy aszimmetrikus útvonalkezelés alkalmazása során, amikor
a válasz útvonala nem a hálózati interfészen keresztül haladhat, amelyen a bejövő csomag érkezett.
A 'Loose' policy checks the incoming packet against the routing table, but considers it valid if the source address is reachable through any available network interface. The proposed attack is based on the premise that the attacker can send a packet with a spoofed source address corresponding to the VPN interface, and despite the fact that this packet arrives through an external network interface rather than through the VPN, in 'Loose' rp_filter mode, such a packet will not be discarded.
To carry out the attack, the attacker must control the gateway through which the user accesses the network (for example, through a MITM organization, when the victim connects to a wireless access point controlled by the attacker or through ). By controlling the gateway to which the user is connected, the attacker can send fake packets that will be perceived in the context of the VPN network interface, but responses will be sent through the tunnel.
By generating a stream of fake packets with the VPN interface IP address substituted in, attempts are made to influence the connection established by the client, but the impact of these packets can only be observed through passive analysis of the encrypted traffic stream associated with the operation of the tunnel. To carry out the attack, it is necessary to know the IP address assigned by the VPN server to the tunnel's network interface, as well as to determine that a connection to a specific host is currently active through the tunnel.
To determine the IP of the virtual VPN network interface, SYN-ACK packets are sent to the victim's system, sequentially testing the entire range of virtual addresses (first testing addresses commonly used in VPN by default, such as the subnet 10.8.0.0/24 in OpenVPN). The existence of an address can be inferred from receiving a response with the RST flag.
Hasonlóképpen határozzák meg a kapcsolat meglétét egy adott webhellyel és a port számot az ügyfél oldalán — a port számokat végigpróbálva, a felhasználó felé egy SYN-csomagot küldenek, amelyben a forráscím a webhely IP-címe, a célcím pedig a virtuális VPN IP. A szerver portját meg lehet jósolni (80 a HTTP-hez), míg az ügyfél oldalán a port számát véletlen próbálkozással lehet meghatározni, elemezve a különböző számok esetében az ACK-válaszok intenzitásának változását, miközben a RST jelzésű csomag hiánya is figyelembe vehető.
Ezen a ponton a támadó már ismeri a kapcsolat négy elemét (forrás IP/cím/port és cél IP/cím/port), de ahhoz, hogy létrehozzon egy hamis csomagot, amelyet az áldozat rendszere érzékel, a támadónak meg kell határoznia a TCP kapcsolat sorozatszámát és megerősítési számát (seq és ack). E paraméterek meghatározásához a támadó folyamatosan hamis RST-csomagokat küld, variálva a sorozatszámokat, amíg meg nem kap egy válasz ACK-csomagot, amely jelzi, hogy a szám beleesik a TCP ablakába.
Ezután a támadó megerősíti a pontos azonosítást azzal, hogy csomagokat küld ugyanazzal a számmal, és figyeli az ACK-válaszok beérkezését, majd pontosan meghatározza az aktuális sorozatszámot. A feladatot megnehezíti, hogy a válaszokat titkosított alagútban küldik, és ezek jelenlétét az elfogott forgalmi adatfolyamban csak közvetett módszerekkel lehet elemezni. A VPN-kiszolgáló felé címzett ACK-csomag elküldése a kliens által a titkosított válaszok mérete és késése alapján állapítható meg, amelyek korrelálnak a hamis csomagok küldésével. Például az OpenVPN esetében a 79-es méretű titkosított csomag pontosan arra utal, hogy belül egy ACK-megerősítés található.
Mielőtt a támadás elleni védelem hozzá lenne adva az operációs rendszer kerneljéhez, ideiglenes megoldásként blokkolni kell a problémát csomagszűrő segítségével a „preroute” láncban blokkolva a csomagok áthaladását, amelyek célcímeként a tunél virtuális IP-címét adják meg.
iptables -t raw -I PREROUTING ! -i wg0 -d 10.182.12.8 -m addrtype ! —src-type LOCAL -j DROP
vagy nftables esetén
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’
Az IPv4 címekkel használt alagutak védelméhez elegendő az rp_filter-t „szigorú” módra állítani (a „sysctl net.ipv4.conf.all.rp_filter = 1” parancs segítségével). A VPN oldaláról a szekvenciaszám meghatározásának módszere blokkolható, ha kiegészítő kitöltést adunk a titkosított csomagokhoz, így az összes csomag mérete azonos lesz.
Forrás: opennet.ru
