een aanvalstechniek (CVE-2019-14899) waarmee pakketten kunnen worden vervalst, gewijzigd of vervangen in TCP-verbindingen die via VPN-tunnels worden doorgestuurd. Het probleem treft Linux, FreeBSD, OpenBSD, Android, macOS, iOS en andere Unix-achtige systemen. Linux ondersteunt het rp_filter-mechanisme (reverse path filtering) voor IPv4; het inschakelen ervan in de “Strict”-modus neutraliseert dit probleem.
De methode maakt pakketvervanging mogelijk op het niveau van TCP-verbindingen die binnen een gecodeerde tunnel passeren, maar staat geen wiggen toe in verbindingen die extra coderingslagen gebruiken (bijvoorbeeld TLS, HTTPS, SSH). De encryptie-algoritmen die in de VPN worden gebruikt, doen er niet toe, omdat de vervalste pakketten afkomstig zijn van de externe interface en door de kernel worden verwerkt als pakketten van de VPN-interface. Het meest waarschijnlijke doel van de aanval is het verstoren van niet-versleutelde HTTP-verbindingen en het gebruik van een aanval om DNS-reacties te manipuleren.
Succesvolle pakketspoofing is aangetoond voor tunnels die zijn gemaakt met OpenVPN, WireGuard en IKEv2/IPSec. Tor is niet gevoelig voor dit probleem, omdat het SOCKS gebruikt om verkeer door te sturen en gebonden is aan een loopback-interface. Voor IPv4 is een aanval mogelijk als rp_filter is ingesteld op de “Loose”-modus (sysctl net.ipv4.conf.all.rp_filter = 2). Aanvankelijk gebruikten de meeste systemen de “Strikte” modus, maar vanaf , afgelopen december uitgebracht, werd de standaard bedieningsmodus gewijzigd in "Loose" en deze verandering werd weerspiegeld in de standaardinstellingen van veel Linux-distributies.
rp_filter-mechanisme voor extra verificatie van pakketpaden om spoofing van bronadressen te voorkomen. Indien ingesteld op 0, wordt er geen controle van het bronadres uitgevoerd en kan elk pakket zonder beperkingen tussen netwerkinterfaces worden doorgestuurd. Modus 1 'Strikt' omvat het controleren van elk pakket dat van buitenaf komt op naleving van de routeringstabel, en als de netwerkinterface via welke het pakket is ontvangen niet is gekoppeld aan de optimale responsafleveringsroute, wordt het pakket weggegooid. Modus 2 "Loose" versoepelt de controle zodat load balancers of asymmetrische routering kunnen werken wanneer
De responsroute kan via een andere netwerkinterface lopen dan die waardoor het binnenkomende pakket arriveerde.
In de Loose-modus wordt een binnenkomend pakket gecontroleerd aan de hand van de routeringstabel, maar wordt het als geldig beschouwd als het bronadres bereikbaar is via een beschikbare netwerkinterface. De voorgestelde aanval is gebaseerd op het feit dat de aanvaller een pakket kan verzenden met een vervalst bronadres dat overeenkomt met de VPN-interface, en ondanks het feit dat dit pakket het systeem binnenkomt via de externe netwerkinterface en niet via de VPN, in de rp_filter “Loose” modus zal een dergelijk pakket niet worden weggegooid.
Om een aanval uit te voeren moet de aanvaller controle hebben over de gateway waarmee de gebruiker toegang krijgt tot het netwerk (bijvoorbeeld via een MITM-organisatie, wanneer het slachtoffer verbinding maakt met een door de aanvaller beheerd draadloos toegangspunt, of via ). Door de gateway te controleren waarmee een gebruiker met het netwerk is verbonden, kan een aanvaller valse pakketten verzenden die worden waargenomen in de context van de VPN-netwerkinterface, maar de antwoorden worden via de tunnel gerouteerd.
Door een stroom fictieve pakketten te genereren waarin het IP-adres van de VPN-interface wordt vervangen, worden pogingen ondernomen om de door de client tot stand gebrachte verbinding te beïnvloeden, maar de invloed van deze pakketten kan alleen worden waargenomen door middel van passieve analyse van de bijbehorende gecodeerde verkeersstroom. met de exploitatie van de tunnel. Om een aanval uit te voeren, moet u het IP-adres van de tunnelnetwerkinterface achterhalen dat door de VPN-server is toegewezen, en ook vaststellen dat er momenteel een verbinding met een specifieke host actief is via de tunnel.
Om het IP-adres van de virtuele VPN-netwerkinterface te bepalen, worden SYN-ACK-pakketten naar het slachtoffersysteem verzonden, waarbij achtereenvolgens het volledige bereik van virtuele adressen wordt opgesomd (in de eerste plaats worden de adressen die in de VPN worden gebruikt standaard opgesomd, bijvoorbeeld OpenVPN gebruikt het 10.8.0.0/24-subnet). Het bestaan van een adres kan worden beoordeeld op basis van de ontvangst van een antwoord met de RST-vlag.
Op een vergelijkbare manier worden de aanwezigheid van een verbinding met een bepaalde site en het poortnummer aan de clientzijde bepaald - door de poortnummers te sorteren, wordt een SYN-pakket naar de gebruiker gestuurd, als bronadres, waarin het IP-adres van de site wordt vervangen en het bestemmingsadres is een virtuele IP VPN. De serverpoort kan worden voorspeld (80 voor HTTP), en het poortnummer aan de clientzijde kan worden berekend met brute kracht, waarbij voor verschillende getallen de verandering in de intensiteit van ACK-reacties wordt geanalyseerd in combinatie met de afwezigheid van een pakket met de RST vlag.
In dit stadium kent de aanvaller alle vier de elementen van de verbinding (bron-IP-adressen/poort en doel-IP-adres/poort), maar om een fictief pakket te genereren dat het slachtoffersysteem accepteert, moet de aanvaller de TCP-volgorde bepalen en bevestigingsnummers (seq en ack) - verbindingen. Om deze parameters te bepalen, verzendt de aanvaller voortdurend valse RST-pakketten, waarbij hij verschillende volgnummers probeert, totdat hij een ACK-antwoordpakket detecteert, waarvan de aankomst aangeeft dat het nummer binnen het TCP-venster valt.
Vervolgens verduidelijkt de aanvaller de juistheid van de definitie door pakketten met hetzelfde nummer te verzenden en de aankomst van ACK-antwoorden te observeren, waarna hij het exacte nummer van de huidige reeks selecteert. De taak wordt gecompliceerd door het feit dat antwoorden binnen een gecodeerde tunnel worden verzonden en dat hun aanwezigheid in de onderschepte verkeersstroom alleen kan worden geanalyseerd met behulp van indirecte methoden. Of een client een ACK-pakket verzendt dat is geadresseerd aan de VPN-server, wordt bepaald op basis van de grootte en latentie van de gecodeerde antwoorden, die correleren met het verzenden van vervalste pakketten. Voor OpenVPN kunt u met een gecodeerde pakketgrootte van 79 bijvoorbeeld nauwkeurig beoordelen of er een ACK in zit.
Totdat aanvalsbescherming aan de kernel van het besturingssysteem wordt toegevoegd als een tijdelijke methode om het probleem te blokkeren blokkeer met behulp van een pakketfilter in de “preroute”-keten de doorgang van pakketten 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 adrestype ! --src-type LOKAAL -j DROP
of voor nftables
nft voeg tabel ip raw toe
nft add chain ip raw prerouting '{ type filter hook prerouting prioriteit 0; }'
nft regel toevoegen ip raw prerouting 'iifname != "wg0" ip daddr 10.182.12.8 fib saddr type != local drop'
Om uzelf te beschermen bij het gebruik van tunnels met IPv4-adressen, stelt u rp_filter gewoon in op de “Strikte” modus (“sysctl net.ipv4.conf.all.rp_filter = 1”). Aan de VPN-kant kan de volgnummerdetectiemethode worden geblokkeerd door extra opvulling aan de gecodeerde pakketten toe te voegen, waardoor alle pakketten even groot worden.
Bron: opennet.ru