angrebsmetode (CVE-2019-14899), der muliggør udskiftning, ændring eller indføring af pakker i TCP-forbindelser, der ledes gennem VPN-tunneler. Problemet berører Linux, FreeBSD, OpenBSD, Android, macOS, iOS og andre Unix-lignende systemer. Linux understøtter mekanismen rp_filter (reverse path filtering) for IPv4, hvis aktivering i 'Strict'-tilstand neutraliserer dette problem.
Metoden giver mulighed for at udskifte pakker på TCP-forbindelsesniveau, der går inden i den krypterede tunnel, men tillader ikke indblanding i forbindelser, der anvender yderligere krypteringslag (f.eks. TLS, HTTPS, SSH). De anvendte krypteringsalgoritmer i VPN er ligegyldige, da de falske pakker kommer fra den eksterne grænseflade og behandles af kerne som pakker fra VPN-grænsefladen. Det mest sandsynlige mål for angrebet er indgreb i ukrypterede HTTP-forbindelser, men at angrebet også anvendes til at manipulere med DNS-svar.
Succesfuld pakkeudskiftning er demonstreret for tunneler oprettet ved hjælp af OpenVPN, WireGuard og IKEv2/IPSec. Tor er ikke påvirket af problemet, da det bruger SOCKS til at videreføre trafik og binder til loopback-grænsefladen. For IPv4 er angrebet muligt, hvis rp_filter sættes til 'Loose' (sysctl net.ipv4.conf.all.rp_filter = 2). Oprindeligt var 'Strict'-tilstand den generelle indstilling i de fleste systemer, men fra , udgivet i december sidste år, blev standardindstillingen ændret til 'Loose', og denne ændring afspejles i standardindstillingerne for mange Linux-distributioner.
rp_filter-mekanismen , der sikrer yderligere kontrol af pakkernes rute for at forhindre spoofing af kildeadresser. Når det er indstillet til 0, udføres der ikke kontrol af kildeadressen, og enhver pakke kan frit videresendes mellem netværksgrænseflader. Tilstand 1 'Strict' aktiverer kontrol af hver indkommende pakke udefra i forhold til routingtabellen, og hvis netværksgrænsefladen, som pakken blev modtaget gennem, ikke er knyttet til den optimale rute for levering af svaret, kasseres pakken. Tilstand 2 'Loose' letter kontrollen for at muliggøre drift med belastningsbalancere eller asymmetrisk routing, hvor
svarruten kan gå via en anden netværksgrænseflade end den, som den indkommende pakke blev modtaget igennem.
I tilstand «Loose» bliver den indgående pakke kontrolleret for at overensstemme med routingtabelen, men betragtes som gyldig, hvis kildeadressen kan nås via enhver tilgængelig netværksgrænseflade. Den foreslåede angrebsmetode bygger på, at angriberen kan sende en pakke med en forfalsket kildeadresse, der svarer til VPN-grænsefladen, og selvom denne pakke kommer ind i systemet via den eksterne netværksgrænseflade og ikke via VPN, vil en pakke i rp_filter-tilstand «Loose» ikke blive forkastet.
For at gennemføre angrebet skal angriberen kontrollere gatewayen, som brugeren går online gennem (for eksempel via en MITM-organisation, når offeret forbinder til en trådløs adgangspunkts kontrol af angriberen eller gennem ). Ved at kontrollere gatewayen, som brugeren er tilsluttet netværket, kan angriberen sende falske pakker, der vil blive opfattet i konteksten af VPN-netværksgrænsefladen, men svarene vil blive sendt gennem tunnelen.
Ved at generere en strøm af falske pakker, hvor IP-adressen for VPN-grænsefladen indsættes, forsøges det at påvirke den forbindelse, som klienten har etableret, men effekten af disse pakker kan kun observeres gennem en passiv analyse af den krypterede trafikstrøm, der relaterer til tunnelens drift. For at gennemføre angrebet er det nødvendigt at kende den tildelte IP-adresse for netværksgrænsefladen i tunnelen fra VPN-serveren samt at bestemme, at der i øjeblikket er en aktiv forbindelse til en bestemt vært gennem tunnelen.
For at bestemme IP-adressen for den virtuelle VPN-netværksgrænseflade anvendes der en sendelse af SYN-ACK pakker til offerets system, hvor hele området af virtuelle adresser gennemgås en ad gangen (primært adresser, der bruges som standard i VPN, for eksempel anvender OpenVPN subnettet 10.8.0.0/24). Eksistensen af en adresse kan skønnes ud fra modtagelsen af et svar med RST-flagget.
Tilsvarende bestemmes tilstedeværelsen af en forbindelse til et bestemt websted og portnummeret på klientsiden - ved at gennemgå portnumre sendes en SYN-pakke til brugeren med webstedets IP-adresse som kildes adresse, mens destinationsadressen er den virtuelle IP fra VPN. Serverporten kan forudses (80 for HTTP), men portnummeret på klientsiden kan beregnes ved iteration, hvor man analyserer ændringen i intensiteten af ACK-svarene i kombination med fraværet af en pakke med RST-flagget.
På dette stadium kender angriberen alle fire elementer af forbindelsen (IP-adresser/port for kilden og IP-adresse/port for destinationen), men for at generere en falsk pakke, som offerets system vil anerkende, skal angriberen bestemme sekvens- og bekræftelsesnumre (seq og ack) for TCP-forbindelsen. For at bestemme disse parametre sender angriberen kontinuerligt falske RST-pakker, mens der testes med forskellige sekvensnumre, indtil en svarende ACK-pakke registreres, hvis ankomst indikerer, at nummeret falder inden for TCP-vinduet.
Derefter bekræfter angriberen nøjagtigheden af denne bestemmelse ved at sende pakker med det samme nummer og observere ankomsten af ACK-svar, hvorefter det præcise nummer for den aktuelle sekvens vælges. Opgaven kompliceres ved, at svarene sendes inden for en krypteret tunnel, og analysen af deres tilstedeværelse i den opfangede trafikstrøm kan kun foretages indirekte. Faktisk sendes en ACK-pakke adresseret til VPN-serveren af klienten baseret på størrelsen og forsinkelsen af de krypterede svar, der korrelerer med afsendelsen af de falske pakker. For eksempel indikerer en krypteret pakke med størrelsen 79 for OpenVPN, at der med rimelighed kan antages, at indholdet indeholder en ACK-bekræftelse.
Før beskyttelsen mod angrebet blev tilføjet til operativsystemets kerne, var en midlertidig metode til at blokere problemet ved hjælp af en pakke-filtre i "preroute"-kæden til at blokere pakker, hvor den virtuelle IP-adresse for tunnelen er angivet som destinationsadresse.
iptables -t raw -I PREROUTING ! -i wg0 -d 10.182.12.8 -m addrtype ! --src-type LOCAL -j DROP
eller for 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'
For protection when using tunnels with IPv4 addresses, it is sufficient to set rp_filter to "Strict" ("sysctl net.ipv4.conf.all.rp_filter = 1"). On the VPN side, the method of determining the sequence number can be blocked by adding padding to the encrypted packets, making the size of all packets the same.
Kilde: opennet.ru
