napadna tehnika (CVE-2019-14899) koja omogućava zamjenu, promjenu ili dodavanje paketa u TCP vezama koje prolaze kroz VPN tunele. Problem se odnosi na Linux, FreeBSD, OpenBSD, Android, macOS, iOS i druge Unix-slične sustave. Linux podržava mehanizam rp_filter (reverse path filtering) za IPv4, čije uključivanje u 'Strict' režim neutralizira ovaj problem.
Metoda omogućava umetanje paketa na razini TCP veza unutar šifriranog tunela, ali ne omogućava provale u veze koje koriste dodatne slojeve šifriranja (npr. TLS, HTTPS, SSH). Primijenjeni algoritmi šifriranja u VPN-u nisu bitni, jer lažni paketi dolaze s vanjskog sučelja, a jezgra ih obrađuje kao pakete iz VPN sučelja. Najvjerojatnija meta napada su nezaštićene HTTP veze, ali i korištenje napada za manipulaciju DNS odgovorima.
Uspješno zamjenjivanje paketa demonstrirano je za tunele stvorene pomoću OpenVPN, WireGuard i IKEv2/IPSec. Tor nije podložan ovom problemu, jer koristi SOCKS za prosljeđivanje prometa i vezanje na loopback sučelje. Za IPv4 napad je moguć ako se rp_filter prebaci u 'Loose' režim (sysctl net.ipv4.conf.all.rp_filter = 2). Prvotno je većina sustava koristila 'Strict' režim, ali od , objavljenog u prosincu prošle godine, zadani način rada je promijenjen u 'Loose', a ova promjena odražava se u zadanim postavkama mnogih Linux distribucija.
Mehanizam rp_filter za dodatnu provjeru putanja prolaska paketa kako bi se spriječila lažna adresa izvora. Kada se postavi na 0, provjera adrese izvora se ne vrši i svaki paket može bez ograničenja prolaziti između mrežnih sučelja. Režim 1 'Strict' uključuje provjeru svakog paketa izvan koji dolazi u skladu s rutnom tablicom, a ako mrežno sučelje putem kojeg je paket primljen nije povezano s optimalnom rutom za isporuku odgovora, paket se odbacuje. Režim 2 'Loose' ublažava provjeru kako bi omogućio rad pri korištenju balansiranja opterećenja ili asimetrične rutiranja, gdje
ruta odgovora može prolaziti ne kroz onaj mrežni sučelje kroz koje je primljen ulazni paket.
U načinu rada „Loose“, dolazni paket se provjerava na odgovarajućnost tablici usmjeravanja, ali se smatra prihvatljivim ako je izvorna adresa dostupna putem bilo kojeg postojećeg mrežnog sučelja. Predloženi napad se temelji na tome da napadač može poslati paket s lažnom izvorno adresom koja odgovara VPN sučelju, a iako će ovaj paket u sustav ući preko vanjskog mrežnog sučelja, a ne putem VPN-a, u načinu rada rp_filter „Loose“ takav paket neće biti odbijen.
Za izvršenje napada, napadač mora kontrolirati gateway putem kojeg korisnik izlazi na mrežu (na primjer, putem MITM napada, pri povezivanju žrtve na kontroliranu napadačem bežičnu pristupnu točku ili preko ). Kontrolirajući gateway putem kojeg je povezan korisnik, napadač može slati lažne pakete koji će se doživjeti u kontekstu VPN mrežnog sučelja, ali će odgovori biti usmjereni kroz tunel.
Generiranjem toka lažnih paketa, u kojima se zamjenjuje IP adresa VPN sučelja, pokušava se utjecati na uspostavljenu vezu od strane klijenta, no promatrati učinak ovih paketa može se samo putem pasivnog analize šifriranog toka prometa koji se odnosi na rad tunela. Za izvršenje napada potrebno je saznati dodeljenu IP adresu mrežnog sučelja tunela od strane VPN servera, kao i utvrditi da je trenutno aktivna veza ka određenom hostu kroz tunel.
Za određivanje IP-a virtualnog mrežnog sučelja VPN koristi se slanje SYN-ACK paketa na sustav žrtve, postupno pretražujući cijeli raspon virtualnih adresa (prvo se pretražuju adrese koje se po defaultu koriste u VPN-u, na primjer, u OpenVPN se koristi podmreža 10.8.0.0/24). O postojanju adrese može se suditi na temelju primanja odgovora s RST oznakom.
Na sličan način se utvrđuje postojanje veze sa određenom web stranicom i broj porta na strani klijenta — iterirajući kroz brojeve portova, šalje se SYN paket s IP adresom web stranice kao izvorom, dok je adresa odredišta virtualna IP VPN. Serverski port može se predvidjeti (80 za HTTP), a broj porta na strani klijenta može se izračunati pretraživanjem, analizirajući promjene intenziteta ACK odgovora za različite brojeve u kombinaciji s nedostatkom paketa s RST zastavicom.
U ovoj se fazi napadač zna sva četiri elementa veze (izvora/destinacije IP adrese/portovi), ali da bi generirao lažni paket koji će sustav žrtve prihvatiti, napadač mora odrediti brojeve sekvenci i potvrde (seq i ack) TCP veze. Da bi odredio te parametre, napadač kontinuirano šalje lažne RST pakete, isprobavajući različite brojeve sekvenci, dok ne zabilježi odgovor ACK paketa, čija pojava ukazuje da broj spada unutar TCP prozora.
Nakon toga napadač potvrđuje točnost odredbe slanjem paketa s istim brojem i promatrajući dolazak ACK odgovora, nakon čega odabire točan broj trenutne sekvence. Zadatak je otežan činjenicom da se odgovori šalju unutar šifriranog tunela i njihovo prisustvo u presretnutom prometu može se analizirati samo posredno. Činjenica slanja ACK paketa namijenjenog VPN serveru od strane klijenta utvrđuje se na temelju veličine i latencije šifriranih odgovora, koji koreliraju s slanjem lažnih paketa. Na primjer, za OpenVPN šifrirani paket veličine 79 omogućuje točno određivanje da unutar njega postoji ACK potvrda.
Prije nego što zaštita od napada bude dodana u jezgru operativnog sustava, kao privremena metoda blokiranja problema pomoću paketnog filtra u lancu „preroute“ blokirati pristup paketima u kojima je kao odredišna adresa navedena virtualna IP adresa tunela.
iptables -t raw -I PREROUTING ! -i wg0 -d 10.182.12.8 -m addrtype ! --src-type LOCAL -j DROP
ili za 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'
Za zaštitu prilikom korištenja tunela s IPv4 adresama, dovoljno je prebaciti rp_filter u režim „Strict“ („sysctl net.ipv4.conf.all.rp_filter = 1“). S VPN strane, metoda određivanja broja sekvenci može biti blokirana dodavanjem dodatnog ispunjavanja enkriptiranim paketima, što čini sve pakete istih dimenzija.
Izvor: opennet.ru
