aanvalstechniek (CVE-2019-14899) waarmee pakketten in TCP-verbindingen kunnen worden vervangen, gewijzigd of toegevoegd, die door VPN-tunnels worden geleid. Het probleem heeft betrekking op Linux, FreeBSD, OpenBSD, Android, macOS, iOS en andere Unix-achtige systemen. Linux ondersteunt het mechanisme rp_filter (reverse path filtering) voor IPv4, waarvan het inschakelen in de 'Strict'-modus dit probleem neutraliseert.
De methode maakt het mogelijk om pakketten te vervangen op het niveau van TCP-verbindingen die binnen een versleutelde tunnel verlopen, maar staat niet toe om zich in verbindingen te mengen die extra versleutelingslagen gebruiken (zoals TLS, HTTPS, SSH). De toegepaste versleutelingstechnieken in VPN's zijn niet van belang, aangezien de vervalste pakketten van de externe interface komen, maar door de kernel worden behandeld als pakketten van de VPN-interface. Het meest waarschijnlijke doel van de aanval is het ingrijpen in onvercijferde HTTP-verbindingen, maar van het gebruik van de aanval voor manipulatie van DNS-antwoorden.
Succesvolle vervangingen van pakketten zijn aangetoond voor tunnels die zijn gemaakt met OpenVPN, WireGuard en IKEv2/IPSec. Tor is hier niet vatbaar voor, omdat het SOCKS gebruikt voor het doorsturen van verkeer en moet worden gebonden aan de loopback-interface. Voor IPv4 is de aanval mogelijk als rp_filter wordt overgezet naar de 'Loose'-modus (sysctl net.ipv4.conf.all.rp_filter = 2). Aanvankelijk werd in de meeste systemen de 'Strict'-modus gebruikt, maar met de komst van , uitgebracht in december vorig jaar, werd de standaardmodus gewijzigd naar 'Loose', en deze wijziging is weerspiegeld in de standaardinstellingen van veel Linux-distributies.
Het rp_filter-mechanisme voert een extra controle uit van de padhistorie van pakketten om het vervalsen van het bronadres te voorkomen. Bij een instelling van 0 wordt het bronadres niet gecontroleerd en kan elk pakket zonder beperkingen tussen netwerkinterfaces worden omgeleid. Modus 1 'Strict' controleert elk binnenkomend pakket van buiten op overeenstemming met de routeringstabel. Als de netwerkinterface waarmee het pakket is ontvangen, niet is verbonden met de optimale route voor de respons, wordt het pakket afgewezen. Modus 2 'Loose' verlicht de controle om het gebruik van load balancers of asymmetrische routering toe te staan, waarbij
de route voor de respons mogelijk niet via die netwerkinterface loopt waarmee het binnenkomende pakket is ontvangen.
In de "Loose" modus wordt het binnenkomende pakket gecontroleerd op overeenstemming met de routeringstabel, maar het wordt als geldig beschouwd als het brondschema bereikbaar is via een van de beschikbare netwerkinterfaces. De voorgestelde aanval is gebaseerd op het feit dat de aanvaller een pakket kan versturen met een gemanipuleerd brondschema dat overeenkomt met de VPN-interface, en hoewel dit pakket het systeem binnendringt via een externe netwerkinterface en niet via de VPN, zal een pakket in de "Loose" rp_filter modus niet worden afgewezen.
Om de aanval uit te voeren, moet de aanvaller de gateway beheersen waaronder de gebruiker het netwerk binnengaat (bijvoorbeeld via een MITM-organisatie, wanneer het slachtoffer zich verbindt met een door de aanvaller beheerde draadloze toegangspunt of door ). Door de gateway te controleren waaronder de gebruiker met het netwerk is verbonden, kan de aanvaller vervalste pakketten verzenden die worden waargenomen in de context van de VPN-interface, maar de antwoorden worden via de tunnel verzonden.
Door een stroom van vervalste pakketten te genereren, waarin het IP-adres van de VPN-interface wordt ingevoerd, worden pogingen ondernomen om invloed uit te oefenen op de verbinding die door de klant is ingesteld, maar de invloed van deze pakketten kan alleen worden waargenomen door passieve analyse van de versleutelde stroom verkeer dat verband houdt met de werking van de tunnel. Voor het uitvoeren van de aanval is het noodzakelijk om het IP-adres van de netwerkinterface van de tunnel, toegewezen door de VPN-server, te achterhalen en vast te stellen dat er op dat moment een actieve verbinding naar een bepaalde host via de tunnel bestaat.
Om het IP van de virtuele netwerkinterface van de VPN te bepalen, worden SYN-ACK-pakketten naar het systeem van het slachtoffer verzonden, waarbij het hele bereik van virtuele adressen systematisch wordt doorlopen (in de eerste plaats worden de adressen doorlopen die standaard in de VPN worden gebruikt, bijvoorbeeld in OpenVPN wordt het subnet 10.8.0.0/24 gebruikt). Het bestaan van een adres kan worden vastgesteld aan de hand van een binnenkomend antwoord met de RST-vlag.
Op dezelfde manier wordt de connectie met een bepaalde website en het poortnummer aan de kant van de client bepaald - door poortnummers te doorlopen, wordt er een SYN-pakket verzonden met het IP-adres van de website als bronadres en het virtuele IP van de VPN als bestemmingsadres. De serverpoort kan worden voorspeld (80 voor HTTP), terwijl het poortnummer aan de kant van de client kan worden berekend door het doorlopen van verschillende nummers, waarbij de verandering in de intensiteit van ACK-antwoorden wordt geanalyseerd in combinatie met de afwezigheid van een pakket met de RST-vlag.
In deze fase kent de aanvaller alle vier de elementen van de verbinding (IP-bronadressen/poort en IP-bestemmingsadressen/poort), maar om een nep-pakket te genereren dat door het systeem van het slachtoffer wordt waargenomen, moet de aanvaller de volgorde- en bevestigingsnummers (seq en ack) van de TCP-verbinding bepalen. Om deze parameters te bepalen, stuurt de aanvaller continu valse RST-pakketten en doorloopt verschillende volgordenummers totdat hij een ACK-pakket ontvangt, wat aangeeft dat het nummer binnen het TCP-venster valt.
Daarna verifieert de aanvaller de nauwkeurigheid van de bepaling door pakketten met hetzelfde nummer te verzenden en de ontvangst van ACK-antwoorden te observeren, waarna hij het exacte nummer van de huidige volgorde aanpast. De taak wordt bemoeilijkt doordat de antwoorden binnen een versleutelde tunnel worden verzonden en het alleen met indirecte methoden mogelijk is om hun aanwezigheid in de onderschepte verkeersstroom te analyseren. Het feit dat een naar de VPN-server geadresseerd ACK-pakket door de client is verzonden, wordt bepaald op basis van de grootte en de vertraging van de versleutelde antwoorden, die correleren met de verzending van valse pakketten. Bijvoorbeeld, voor OpenVPN laat een versleuteld pakket van 79 bytes nauwkeurig concluderen dat het een ACK-bevestiging bevat.
Voordat de bescherming tegen aanvallen aan de kernel van het besturingssysteem wordt toegevoegd, kan als tijdelijke methode het probleem worden geblokkeerd door met een pakketfilter in de 'preroute'-keten te verhinderen dat pakketten worden doorgelaten waarin het virtuele IP-adres van de tunnel als bestemmingsadres is opgegeven.
iptables -t raw -I PREROUTING ! -i wg0 -d 10.182.12.8 -m addrtype ! --src-type LOCAL -j DROP
of voor 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'
Voor bescherming bij het gebruik van tunnels met IPv4-adressen is het voldoende om rp_filter in de "Strict" modus te zetten ("sysctl net.ipv4.conf.all.rp_filter = 1"). Vanuit de VPN kan de methode om het volgnummer te bepalen worden geblokkeerd door extra opvulling toe te voegen aan de versleutelde pakketten, waardoor de grootte van alle pakketten gelijk is.
Bron: opennet.ru
