Kwetsbaarheid in Linux-distro's, Android en iOS maakt kapen vpn mogelijk

Onderzoekers hebben een kwetsbaarheid in op Linux en op Unix gebaseerde besturingssystemen gevonden die het mogelijk maakt om vpn-verbindingen te kapen en willekeurige code in dataverkeer te injecteren.

De kwetsbaarheid krijgt de aanduiding CVE-2019-14899. Het lek maakt het volgens beveiligingsonderzoekers van Breakpointing Bad mogelijk om te bepalen dat een gebruiker een actieve vpn-verbinding heeft, en welk virtueel ip-adres ze toegewezen hebben gekregen van de vpn-aanbieder. Vervolgens kunnen aanvallers de sequentie- en acknowledge-nummers bepalen door de versleutelde pakketjes te tellen en hun grootte af te leiden. Daarna kunnen ze de tcp-sessie in de vpn-tunnel kapen en via het lek willekeurige payloads in versleutelde connecties injecteren, beschrijven de onderzoekers.

De methode werkt volgens hen op Linux, FreeBSD, OpenBSD, macOS, iOS en Android. In ieder geval Linux-distro's met systemd-versies van ná 28 november 2018 zijn kwetsbaar. Bij deze versie is de Reverse Path-filteringmodus van Strict naar Loose gezet. De kwetsbaarheid is echter niet beperkt tot deze versies. De onderzoekers hebben het probleem getest met Ubuntu 19.10, Fedora, Debian 10.2, Arch 2019.05, Manjaro 18.1.1, Devuan, MX Linux 19, Void Linux, Slackware 14.2, Deepin, FreeBSD en OpenBSD. Wat vpn's betreft hebben zij OpenVPN, WireGuard en IKEv2/IPSec getest, maar volgens de deskundigen maakt de gebruikte vpn-technologie niet uit voor de kwetsbaarheid.

Het probleem is te verhelpen door Reverse Path-filtering in te schakelen, Bogon-filtering te activeren of door de versleutelde pakketjes van dezelfde omvang te maken. De onderzoekers beloven meer details bekend te maken zodra er betere workarounds zijn.

Reacties (66)

[Verwijderd]

Wat ik gek vind is dat Devuan nu net een Debian based Linux distro is die er prat op gaat dat ze geen systemd componenten gebruiken. Dat is nu net waarvoor Devuan begonnen is. Om van systemd af te geraken.

Maar toch zijn zij ook affected?

Hoe komt het dan dat systemd betrokken is?

[swhnld]

Gewoon slecht overgenomen, bron artikel zegt:

so distributions using a version of systemd without modified configurations after this date are now vulnerable. Most Linux distributions we tested which use other init systems leave the value as 0, the default for the Linux kernel.

Kortom, hangt van de instelling af die gezet wordt door het init system, ongeacht welke het is.

[magic45]

Ze schrijven zelf:

Most of the Linux distributions we tested were vulnerable, especially
Linux distributions that use a version of systemd pulled after November
28th of last year which turned reverse path filtering off. However, we
recently discovered that the attack also works against IPv6, so turning
reverse path filtering on isn't a reasonable solution, but this was how
we discovered that the attack worked on Linux.

Alle appels zijn fruit, niet al het fruit is een appel.

Dat het met bepaalde systemd versies gelukt is zegt niet dat het alleen met systemd lukt.

Verder zeggen ze;

This attack did not work against any Linux distribution we tested until
the release of Ubuntu 19.10, and we noticed that the rp_filter settings
were set to “loose” mode. We see that the default settings in
sysctl.d/50-default.conf in the systemd repository were changed from
“strict” to “loose” mode on November 28, 2018, so distributions using a
version of systemd without modified configurations after this date are
now vulnerable. Most Linux distributions we tested which use other init
systems leave the value as 0, the default for the Linux kernel.

[Reactie gewijzigd door magic45 op 23 juli 2024 16:35]

[Jory]

Als Reverse Path Filtering op "strict" staat is een systeem niet kwetsbaar. Reverse path filtering is een feature van de kernel.

In systemd versies van na 28 oktober 2018 staat deze feature uit op "loose".

Distos die geen systemd gebruiken hebben natuurlijk ook een instelling voor reverse path filtering - het is immers een feature van de kernel, niet van systemd. Blijkbaar heeft (de geteste versie van) Devuan daar ook "loose" (of in ieder geval niet "strict"), waardoor zij ook kwetsbaar zijn.

[Reactie gewijzigd door Jory op 23 juli 2024 16:35]

[Verwijderd]

Aha, dus systemd voorziet via een kernel-instelling een mitigatie van het probleem. Maar systemd is niet betrokken bij het onstaan van het probleem. Devuan heeft systemd helemaal niet. En dus mitigeert Devuan het probleem dan ook niet.

Belangrijke nuancering. Want dat is dan meteen ook het argument tegen iedereen die weer van leer gaat geven tegen systemd. Dat wordt namelijk veel te gemakkelijk en met veel te weinig kennis van zaken gedaan.

[CAPSLOCK2000]

Aha, dus systemd voorziet via een kernel-instelling een mitigatie van het probleem. Maar systemd is niet betrokken bij het onstaan van het probleem.

Tegenwoordig zet systemd het goed, oudere versies van systemd stelde het verkeerd in. Het is inderdaad niet de direct oorzaak van het probleem, maar het maakte de situatie wel erger.

Om het te vergelijken met en inbreker: systemd heeft een ladder in de tuin laten staan waarmee er bij de buren is ingebroken. Dat het dakraam bij de buren open staat is niet de schuld van systemd en de ladder kan er ook niet veel aan doen, maar het die ladder buiten opslaan was toch niet zo'n goed idee.

[mg794613]

Niet echt.
0 = geen filtering, 1 = filtering, 2 =verzwakte filtering.
Default van kernel zelf is 0, default van meeste configuraties was 1. SystemD heeft het in een commit ooit op 2 gezet omdat problemen met networkmanager er voor zorgde dat je op wifi en kabel netwerk tegelijk z'n route niet altijd kon maken.
Dit is geen verstandige default, wellicht voor sommige desktop systemen, maar het zou beter een expliciete keus zijn.
En omdat Devuan SystemD niet gebruikt, het daarom ook het probleem niet mitigeert vind ik een rare uitspraak?

[bryanhonof]

Ik geloof dat dit niet direct iets te maken heeft met systemd, maar eerder met de netwerk stack .

Zoals gezegd wordt door de maker van WireGuard in deze post:
"this isn't a WireGuard vulnerability, but rather something in the routing table code and/or TCP code on affected operating systems."

Dus ik denk dat er gewoon niet veel verschil is tussen de netwerk stack in systemd-based distros en non-systemd-based distros.

[rbr320]

Dus ik denk dat er gewoon niet veel verschil is tussen de netwerk stack in systemd-based distros en non-systemd-based distros.

Correct, ik vermoed dat zowel Linux als BSD-gebaseerde systemen grote delen van de netwerk stack geërfd hebben van het oorspronkelijke Unix. Zelfs als het niet om de daadwerkelijke code gaat dan nog steeds wel de implementatie van de interface en de instellingen die beschikbaar zijn. Daar heeft systemd niets aan veranderd want de netwerk stack is een onderdeel van de kernel. Systemd is slechts een system management laag.

[Reactie gewijzigd door rbr320 op 23 juli 2024 16:35]

[CAPSLOCK2000]

De "oorspronkelijke Unix" had geen netwerk-stack. Dat was misschien wel de belangrijkste toevoeging van BSD. De Linux netwerk-stack is daar niet direct gebaseerd op BSD, al zijn er echt wel stukjes geleend. Een ander bekend OS dat wel ooit de BSD netwerk-stack heeft overgenomen is Windows (ooit, heeel lang geleden). Niet dat er nu nog iets van over is, maar zo is het ooit begonnen.

[blorf]

In XP kon je lokale hostname/ip combinaties aangeven in een hosts bestand ergens in de systeemdirectories in dezelfde opmaak als FreeBSD's /etc/hosts. Ooit gebruikt om hardnekkige reclame te blokkeren in IE6...

[CAPSLOCK2000]

Voor zover ik weet kan dat nog steeds met Windows 10. Kijk eens in C:\Windows\System32\Drivers\etc\hosts.txt

[Verwijderd]

Zonder .txt

Niet alle bestanden met tekst als inhoud hebben een extensie nodig.

[Z80]

hosts
Dus zonder de .txt Het is wel een platte tekst bestand. En ja dit werkt nog steeds in de laatste versie van Windows

[StGermain]

Werkt nog steeds in W10, ik gebruik het om de reclame in skype for windows niet door te laten komen.

[batjes]

Pas met Windows 8 is die netwerk-stack die Microsoft van BSD geleend heeft vervangen met hun eigen netwerk stack.

[GekkePrutser]

Dan nog zou een goede VPN dit af kunnen schermen met zijn HMAC. Die zou moeten voorkomen dat een pakket niet afkomstig van de VPN peer geaccepteerd wordt. Ik snap niet helemaal hoe de kernel dit omzeilt. Misschien injecteren ze de ongeencrypte pakketjes direct in de virtuele netwerk interface op een of andere manier? Dat moet haast wel omdat het op zoveel verschillende VPN's werkt die enorm anders in elkaar zitten. Ik moet me er nog op inlezen

[Reactie gewijzigd door GekkePrutser op 23 juli 2024 16:35]

[Guru Evi]

Inderdaad, dat is hoe het werkt, de pakketten worden geinjecteerd voor de encryptie gebeurt. Redelijk makkelijk om te blokkeren ook met een degelijke iptables script voor de laatste 20-of-zo jaren (en niet de zwakke FirewallD soep)

[blorf]

Ik begrijp het ook niet helemaal. FreeBSD heeft rc.d, dat lijkt niet op systemd. Hoe kan het er mee te maken hebben?

Trouwens, voor zover ik weet zijn het allebei configuratie-frameworks die alleen maar uit een daemon en textfiles bestaan en root vereisen voor aanpassingen. Die zijn te beinvloeden van buitenaf? Dat is nogal een lek dan...

[Reactie gewijzigd door blorf op 23 juli 2024 16:35]

[Verwijderd]

Welja, systemd zal services opstarten. Want dat is wat systemd doet (het is, zeg maar, het equivalent van "Services" in Windows). Als dan één van die services (laten we bijvoorbeeld de VPN service nemen) een probleem heeft, dan zal systemd die service met dat probleem opstarten en op die manier het probleem "veroorzaken".

Maar op die manier is dan de Start knop van Windows 95 verantwoordelijk voor nagenoeg alle bugs en fouten die er ooit op Windows waren. Want de meeste mensen gebruiken dat start-menu om programma's op hun desktop op te starten. De oplossing zou dan zijn om dat start-menu te verwijderen. Of zo? (ja, /sarcasm he)

De Reverse Path-filteringmodus is een instelling die in de .service file (configuratie hoe de service opgestart moet worden door systemd) van de getroffen VPN software staat? Dat is dan equivalent aan dat het .lnk betand (is een snelkoppeling uit de Windows-wereld) van het start-menu een instelling kan hebben die het probleem mitigeert. Maar dat een bepaalde versie deze mitigatie niet heeft opstaan. Of zo iets.

Ik vind dat op een techneuten site zoals deze hier enige aandacht aan mag gegeven worden. Maar anderzijds vind ik zoveel en heb ik wel vaker een gekke mening (over oa. mijn vakgebied).

[blorf]

Wat ik vaak mis is een beschijving van de positie van een mogelijke aanvaller. Als die lokaal raw netwerkdata van systeemprocessen kan analyseren en/of omleiden is het verder kinderspel. Wat moet iemand buiten allemaal eerst doen om dit voor elkaar te krijgen? Alleen al ongezien de betreffende data in handen krijgen vereist het een en ander...

[Reactie gewijzigd door blorf op 23 juli 2024 16:35]

[CAPSLOCK2000]

Wat ik vaak mis is een beschijving van de positie van een mogelijke aanvaller. Als die lokaal raw netwerkdata van systeemprocessen kan analyseren en/of omleiden is het verder kinderspel. Wat moet iemand buiten allemaal eerst doen om dit voor elkaar te krijgen? Alleen al ongezien de betreffende data in handen krijgen vereist het een en ander...

Een klein stukje uit de melding:

There are 3 steps to this attack:

1. Determining the VPN client’s virtual IP address
2. Using the virtual IP address to make inferences about active
connections
3. Using the encrypted replies to unsolicited packets to determine the
sequence and acknowledgment numbers of the active connection to hijack
the TCP session


There are 4 components to the reproduction:

1. The Victim Device (connected to AP, 192.168.12.x, 10.8.0.8)
2. AP (controlled by attacker, 192.168.12.1)
3. VPN Server (not controlled by attacker, 10.8.0.1)
4. A Web Server (not controlled by the attacker, public IP in a real-
world scenario)

The victim device connects to the access point, which for most of our
testing was a laptop running create_ap. The victim device then
establishes a connection with their VPN provider.

The access point can then determine the virtual IP of the victim by
sending SYN-ACK packets to the victim device across the entire virtual
IP space (the default for OpenVPN is 10.8.0.0/24). When a SYN-ACK is
sent to the correct virtual IP on the victim device, the device
responds with a RST; when the SYN-ACK is sent to the incorrect virtual
IP, nothing is received by the attacker.

[blorf]

Volgens mij moet je voor stap 1 of op afstand een online datastroom aftappen of het systeem binnendringen en de data gewoon ophalen. Dan ben je al voorbij het doel toch?
En: moet je er een wifi accespoint voor faken (dus binnen 30 meter van je doelwit zitten)? Dan zit daar toch de kwetsbaarheid?

[Reactie gewijzigd door blorf op 23 juli 2024 16:35]

[JAVE]

Als je via een public accesspoint het internet op gaat (Wifi van je hotel ofzo), kan je dus niet meer vertrouwen op de veiligheid van je VPN verbinding.

Natuurlijk is dit geen punt als je vanaf thuis naar je werk verbdindt met een VPN, want dan zitten er (als het goed is) geen apparaten die je niet onder eigen controle hebt in het pad.

[CAPSLOCK2000]

Welja, systemd zal services opstarten. Want dat is wat systemd doet (het is, zeg maar, het equivalent van "Services" in Windows). Als dan één van die services (laten we bijvoorbeeld de VPN service nemen) een probleem heeft, dan zal systemd die service met dat probleem opstarten en op die manier het probleem "veroorzaken".

Ik denk het niet, systemd doet veel meer dan services opstarten en bemoeit zich ook met je netwerkconfiguratie. Daarbij was een minder optimale keuze gemaakt.

[rbr320]

De kwetsbaarheid betreft ook diverse BSD-gebaseerde systemen en Android, die allen geen gebruik maken van systemd. Ook staat er duidelijk in het artikel (emphasis mine):

Linux-distro's met systemd-versies van ná 28 november 2018 zijn kwetsbaar. De kwetsbaarheid is echter niet beperkt tot deze versies.

Blijkbaar is er dus geen andere relatie tussen deze kwetsbaarheid en systemd dan dat systemd de instelling voor Reverse Path-filtering op een systeem kan beheren. Op andere systemen wordt dit blijkbaar op een andere manier geconfigureerd.

[xmenno]

Ik denk dat het niet echt uit maakt hoe, maar meer wat je zet in sysctl. Ik vind het vreemder dat ze van strict naar loose zijn gegaan, dat helpt niet echt mee om het internet een veiligere plek te maken voor ons allemaal.

[Eonfge]

Komt uiteindelijk door een bepaalde *nix kernel functionaliteit, welke in bepaalde configuraties deze fout introduceren.

Systemd systemen hebben standaard deze afwijkende configuratie, maar het kan best dat Devuan bij toeval deze config ook heeft.

[Jerie]

Binnen Debian is men bezig om alternatieve init systemen te ondersteunen, naast systemd. Als dat van de grond komt is Devuan overbodig.

[tweaknico]

systemd doet iets meer dan alleen services starten/stoppen en bewaken. Tegenwoordig is ook DNS resolving, time synchronizing etc. een onderdeel van de diensten en dat zullen er alleen maar meer worden.
Ook instellingen op systemen worden aangepast om systemd "beter" te laten werken.

Het is niet het eerste probleem binnen system, het zal zeker ook niet het laatste zijn naarmate het meer om zich heen graait.

(Hier is een referentie op genomen naar een system setting waarin reverse patch check uitgezet is).
https://www.slashroot.in/...gs-reverse-path-filtering

Zie ook link in reactie van ripperke.

[Reactie gewijzigd door tweaknico op 23 juli 2024 16:35]

[mg794613]

Even wat verduidelijking. De verbinding kan niet ingezien worden. Echter kan er wel meegelift worden.
Klein maar belangrijk verschil.
Ook is de oorsprong nogal beschamend.
De default was "1" (filtered), maar omdat networkmanager niet goed overweg kon met tegelijk een netwerk en wifi verbinding is dit versoepelt naar "2"
Hoe dit zijn weg heeft kunnen vinden naar server systemen is schandelijk.

[rbr320]

Daar is niets schandelijks aan. Zoals @ripperke in zijn post vermeld breekt "strict mode" een aantal veel voorkomende scenario's die reguliere thuisgebruikers tegen komen, zoals bijvoorbeeld schakelen tussen WiFi en een kabel. De ontwikkelaars van systemd komen dus de gewone gebruiker tegemoet door deze instelling te wijzigen. Je zou nog kunnen beargumenteren dat het de taak is van de diverse distributies om in hun server image deze instelling terug te zetten naar strict, maar lang niet alle distributies hebben een apart image voor server installaties. Ook mag je er vanuit gaan dat servers in een vertrouwd netwerk staan zonder andere machines die gaan proberen deze kwetsbaarheid uit te buiten. Daarnaast zou deze instelling tijdens de hardening van je nieuwe server, waarvan anno 2019 toch wel verwacht mag worden dat dit volautomatisch gebeurd bij elke uitrol, correct gezet moeten worden.

[Olaf van der Spek]

Je zou nog kunnen beargumenteren dat het de taak is van de diverse distributies om in hun server image deze instelling terug te zetten naar strict, maar lang niet alle distributies hebben een apart image voor server installaties.

Secure-by-default is veiliger.. desktop distro's kunnen de beveiliging dan versoepelen.
Omgekeerd krijg je, keer op keer, security issues als deze.

[CAPSLOCK2000]

Tja, het is wel een van de verwijten die systemd wel vaker gemaakt wordt, namelijk dat systemd zich te veel focussed op desktops en eindgebruikers en daarbij het leven moeilijk maakt voor servers en professionele gebruikers.

Dat dit probleem bij een goede hardening wordt voorkomen is waar, maar geen excuus.

[HollowGamer]

Kan je hier ook voorbeelden in noemen? systemd werkt bij mij prima op servers en je kan eenvoudig een service aanpassen naar je eigen smaak. Ik zou nooit meer terug willen naar de tijd waarin het echt onduidelijk was met levels en het patchen van die services.

[Guru Evi]

Niet helemaal juist, je kan wel degelijk multi-homing implementeren zonder rp_filter te veranderen, het probleem zit in NetworkManager (een ander deel, en imho een van de slechtste onderdelen van SystemD) dat niet overweg kan met het testen van de verbinding zonder de standaard route te veranderen (alhoewel dit maar een paar if/then/else zou mogen zijn, we deden het voor systemd wel degelijk correct)

De verandering is dan ook zonder discussie aanvaard geweest door Poettering. Dit gebeurt veel met SystemD, Poettering maakt veranderingen en aanvaardt veranderingen van allerlei bronnen zonder deze door te denken, zonder documentatie of informatie en zonder bij de grotere gebruikersgroepen zich te verantwoorden.

Daardoor krijg je dus bugs en lekken, vooral in de netwerkdelen van SystemD, omdat Poettering niet veel kent van netwerken en dus denkt even snel een oplossing in elkaar te steken (eg. NetworkManager en de lekke DNS client in SystemD). De RFC is anders heel duidelijk over Reverse Path Filtering in multi-homing - strict is standaard sinds 2004 want we weten dat deze aanvallen mogelijk zijn.

[Reactie gewijzigd door Guru Evi op 23 juli 2024 16:35]

[tweaknico]

hoe dit zijn weg heeft kunnen vinden naar gebruikers systemen ZONDER bewuste keuze van de eindgebruiker voor verlaging van beveiliging ten gunste van sporadisch netwerk gemak is schandelijk.

Juist van een RedHat gerelateerd (deel) systeem mag je meer verwachten.

[jerheij]

De default was "1" (filtered), maar omdat networkmanager niet goed overweg kon met tegelijk een netwerk en wifi verbinding is dit versoepelt naar "2".

Ik heb net op een VPS en een home server gekeken naar de sysctl *.rp_filter waardes en die staan bij beiden voor al mijn verbindingen op 1, ik zie nergens een 2 staan. Zit ik te derpen en naar de verkeerde waarde te kijken?

[ASP]

Laten we dit gelijk eens aanzetten, dacht ik. Te beginnen met reverse path-filtering. Zal wel een (Open)VPN instelling zijn. Niet dus:

Also, you will find it necessary to disable reverse path filtering by the kernel,
for f in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 0 > $f; done

I would place this command in your up script, and the reverse one
for f in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 1 > $f; done

Niet dus, dat wordt dus voor en na de (Open)VPN verbinding een scriptje starte. Iemand anders nog ideeën om dit eenvoudig voor elkaar te krijgen?

Zie bijv.: https://superuser.com/que...ot-working-correctly?rq=1

Toevoeging na een uur lezen:

Hier staat uitgelegd hoe je reverse path-filtering system wide aan of uit kan zetten:
https://www.slashroot.in/...gs-reverse-path-filtering

door deze entry in de sysctl.conf aan te passen:
net.ipv4.conf.all.rp_filter = 1 ( 0, 1, of 2 zie hieronder)

op de plek van all zet kun je ook een specifieke netwerk adapter neerzetten. Op Ubuntu kreeg ik via:
ls -las /proc/sys/net/ipv4/conf/*/rp_filter

deze mogelijkheden:
0 -rw-r--r-- 1 root root 0 dec 6 16:10 /proc/sys/net/ipv4/conf/all/rp_filter
0 -rw-r--r-- 1 root root 0 dec 6 16:10 /proc/sys/net/ipv4/conf/default/rp_filter
0 -rw-r--r-- 1 root root 0 dec 6 16:11 /proc/sys/net/ipv4/conf/ens33/rp_filter
0 -rw-r--r-- 1 root root 0 dec 6 16:11 /proc/sys/net/ipv4/conf/lo/rp_filter
0 -rw-r--r-- 1 root root 0 dec 6 16:11 /proc/sys/net/ipv4/conf/tun0/rp_filter

Wel even opletten welke sysctl.conf je neemt, want de ene override de ander (ik heb /etc/ufw/sysctl.conf genomen).

De drie mogelijke waarden zijn:
The 3 values that can be set for the key rp_filter are:
0 No source address validation is performed and any packet is forwarded to the destination network
1 Strict Mode as defined in RFC 3074. Each incoming packet to a router is tested against the routing table and if the interface that the packet is received on is not the best return path for the packet then the packet is dropped.
2 Loose mode as defines in RFC 3074 Loose Reverse Path. Each incoming packet is tested against the route table and the packet is dropped if the source address is not routable through any interface. The allows for asymmetric routing where the return path may not be the same as the source path

Dat introduceert een nieuw probleem: geen Source Address Verification meer. Dus of je hier nu echt wat mee opschiet...

[Reactie gewijzigd door ASP op 23 juli 2024 16:35]

[CAPSLOCK2000]

Laten we dit gelijk eens uitzetten, dacht ik. Te beginnen met reverse path-filtering. Zal wel een (Open)VPN instelling zijn. Niet dus:

Uitzetten? Volgens mij doe je het verkeerd om en moet je het juist AAN zetten.

Ik citeer:

The 3 values that can be set for the key rp_filter are:
0 No source address validation is performed and any packet is forwarded to the destination network
1 Strict Mode as defined in RFC 3074. Each incoming packet to a router is tested against the routing table and if the interface that the packet is received on is not the best return path for the packet then the packet is dropped.
2 Loose mode as defines in RFC 3074 Loose Reverse Path. Each incoming packet is tested against the route table and the packet is dropped if the source address is not routable through any interface. The allows for asymmetric routing where the return path may not be the same as the source path

Loose mode is niet goed genoeg, je hebt 'strict' nodig. Helemaal niet controleren heb je natuurlijk ook niks aan. Mode 1 dus.

De makkelijkste manier om dit te doen is een file maken in genaamd "/etc/sysctl.d/51-rpfilter.conf "

met als inhoud:

net.ipv4.conf.all.rp_filter=1

[Reactie gewijzigd door CAPSLOCK2000 op 23 juli 2024 16:35]

[Wim-Bart]

Op zich gaat dit wel werken, maar het grappige is, er wordt een vergelijk tegen de routing table aangehouden. En op basis van een gelijk pad zal er niet gedropt worden. Wat inhoud dat twee IP Adressen, van de zelfde Router dus gewoon alsnog geaccepteerd worden. Persoonlijk zou ik liever zien dat zowel router als source vergeleken worden inclusief TCP sessie ID.

Maar tja, de hele oplossing is natuurlijk dramatisch en zelfs de strict maakt het mogelijk om TCP sessies te kapen zolang je als aanvaller maar op de zelfde interface binnen komt en de zelfde router hebt. Hang een machine in het netwerk, neem router MAC over en GW ip nummer en je kan sessie overnemen terwijl je IP nummer anders is. Kwestie van session ID aanpassen. Metasploit heeft daar hele mooie plugins voor.

Probleem is dat deze oplossing bedoeld is om roaming van end devices te vereenvoudigen zonder sessie te verliezen met alle gevolgen van dien.

[Reactie gewijzigd door Wim-Bart op 23 juli 2024 16:35]

[ASP]

Klopt, aangepast + jou tabel bij mij post erbij gezet om de waarden te verduidelijken.

[Eonfge]

Zakelijk of thuis gebruik?

Voor thuis negeer ik het probleem nu even en wacht ik wel op de officiële patch. De aanval is moerdijk uit te voeren dus de kans dat het jou overkomt is klein.

Zakelijk... Kan het problemen geven als er binnen de VPN veel onbeveiligde TCP communicatie plaats vind, en wanneer aanvallers genoeg pakketten kunnen onderscheppen en injecteren. Tenzij jouw bedrijf permanent gevestigd is in een schimmig Russisch hotel, dan zal ik voor nu nog niet actie ondernemen.

[ASP]

Zakelijk, maar na wat verder gelezen te hebben gaat het om het meeliften op de VPN verbinding, en niet om de data zelf. Ik zit regelmatig in een schimmig hotel in Dubai dus tot er een patch is, lift er hooguit een Emirati mee op m'n lijn naar Nederland. Ik ben gerustgesteld.

[Mikanzana]

Misschien wel zo goed om te vermelden dat dit
1) alleen kan als je in hetzelfde netwerk zit;
2) er geen data leesbaar is met deze kwetsbaarheid daar er alleen data geïnjecteerd kan worden, en;
3) je als aanvaller redelijk wat moeite moet doen om de daadwerkelijke aanval uit te voeren. 'The attacker must spoof resets to different blocks across the entire sequence number space until one triggers an encrypted challenge ACK.'

Het klinkt dus wel akelig maar dat valt in de praktijk alles mee.

[Reactie gewijzigd door Mikanzana op 23 juli 2024 16:35]

[HollowGamer]

In ieder geval Linux-distro's met systemd-versies van ná 28 november 2018 zijn kwetsbaar. Bij deze versie is de Reverse Path-filteringmodus van Strict naar Loose gezet.

Wat is precies de reden waarom dit van Strict naar Loose is gezet?

[ripperke]

https://github.com/systemd/systemd/pull/10971


This switches the RFC3704 Reverse Path filtering from Strict mode to Loose
mode. The Strict mode breaks some pretty common and reasonable use cases,
such as keeping connections via one default route alive after another one
appears (e.g. plugging an Ethernet cable when connected via Wi-Fi).

The strict filter also makes it impossible for NetworkManager to do
connectivity check on a newly arriving default route (it starts with a
higher metric and is bumped lower if there's connectivity).

[PPie]

Klinkt als een mooie smoes om het 'loose' te zetten en daarmee deze kwetsbaarheid te krijgen.
Wijziging gecommit door de NSA?

[mg794613]

Nee, overvloeing van belangen.
Lennart Poettering, werkt hard aan een bepaald pad om Linux zo monolithisch mogelijk te maken.
Zeg maar het tegenovergestelde waar MS Windows het afgelopen decennia aan gewerkt heeft.

Voor de wat minder ingelezen:
Er was eens... een gebrek aan alternatieven voor init systemen (het boot proces van je OS).
Nu zat iedereen te springen op een alternatief, want het meestvoorkomende (sysinit) was wellicht aan een update toe.
Een wildgroei aan init systemen volgde, dit was een goede zaak, immers; keuze!

Een van deze voorgestelde systemen, was SystemD, van de makers van bijv. Pulseaudio en Avahi.
Nu is er sinds de introductie van SystemD een aantal dingen voorgevallen, die men heeft zien aankomen.
In plaats van het init systeem vervangen, werd er via "feature creep", steeds meer van userland naar binnengehaald, aangepast, incompatibel gemaakt. (Administratie, Logging, ..)
Dit zorgt voor een steeds verder vallende reputatie, welke ook niet geholpen wordt door de communicatie hieromtrent, waar bijvoorbeeld bugreports snel afgevlagd worden,

Nu is Systemd niet alleen maar ellendigheid. Het werkt best aardig, maar het er zijn behoorlijk wat aanpassingen nodig om het bijvoorbeeld modulair en compatibel te maken, iets waar de hoofddeveloper absoluut geen oren naar heeft.

Dit is jammer voor een aantal redenen.
- Als je tussen SystemD en een ander init systeem kiest, moet je gehele systeem hierop aangepast worden.
- Maar omdat veel distributies zijn overgestapt op SystemD, nu ook een soort gebonden zitten hieraan.
- Het primair focust op "user experience", wat an sich geweldig, maar om alle machines te versimpelen naar mobiele telefoon interface is ook niet het antwoord.
- Het defaults kiest die overduidelijk niet toepasbaar zijn op alle machines/situaties.

Nu heb ik eerder het argument gelezen in de trant van "Als je deze waarde niet in je configuration management system hebt staan, doe je het fout".
Je hebt echt niet alle waardes in je systeem staan, daar zijn het f%&!g defaults voor!

[Munchie]

Daarna kunnen ze de tcp-sessie in de vpn-tunnel kapen en via het lek willekeurige payloads in versleutelde connecties injecteren, beschrijven de onderzoekers.

Misschien een stomme vraag, maar als ik gebruik maak van een UDP protocol ipv TCP, ben ik dan ook kwetsbaar ?

[oko2708]

Volgensmij niet, want het UDP protocol werkt niet met acknowledgements.

Ik snap dan ook het probleem niet helemaal. Waarom zou je TCP gebruiken voor je VPN. Wanneer een pakketje via UDP niet aankomt is het foetsie, maar het onderliggende (versleutelde) TCP protocol zal dan toch gewoon dat pakket opnieuw versleuteld versturen via UDP of mis ik hier iets?

[Wim-Bart]

UDP is niet te gebruiken voor VPN. Wanneer je 1 pakketje mist breekt je tunnel. Daarnaast gaat er binnen de tunnel van alles, van ICMP, TCP, UDP en ieder ander protocol.

De VPN is echter altijd TCP eventueel in combinatie met bijvoorbeeld GRE.

UDP zou tevens deze hack vereenvoudigen. Want dan stuur je gewoon een pakket naar de VPN virtual interface en hoef je niet eens een connectie te faken. Nu kapen ze een TCP sessie wanneer ik het zo lees en laten ze deze "downgraden" naar een state waarbij data is te lezen/schrijven. Wanneer VPN gebruik maakt van UDP hoeven ze dus minder moeite te doen.

Je zou eigenlijk een VPN over een VPN moeten draaien om dit moeilijker te maken. Dus bijvoorbeeld IPSec op basis van certificaten over een VPN tunnel. Of gewoon HTTPS door de VPN heen.

[_JGC_]

UDP wordt juist wel gebruikt voor VPN. Zowel OpenVPN als IPSec gebruiken UDP (ipsec alleen bij NAT traversal).
Het idee bij UDP is dat het protocol binnen de tunnel foutcorrectie doet. TCP getunneld in UDP doet foutcorrectie zoals gewenst, UDP getunneld in TCP doet ook foutcorrectie, wat niet gewenst is (anders had je immers wel TCP gebruikt)

[Wim-Bart]

https://www.paessler.com/it-explained/vpn
Natuurlijk heb je ook varianten van IKE en IKEv2. Die gaan over UDP poort 500 maar zijn eigenlijk geen UDP.
Een kleine opsoming.
https://www.vpnunlimiteda...e-about-vpn/vpn-protocols

[Reactie gewijzigd door Wim-Bart op 23 juli 2024 16:35]

[oko2708]

Kan je dit iets verder toelichten of eventueel verwijzen naar een aantal externe bronnen?

Waar ik op doelde was inderdaad wat @_JGC_ zei en dat is volgensmij ook hoe het werkt. Bij mijn VPN kies ik altijd trouw voor het UDP protocol en dat spreek jou reactie dus tegen. Misschien hebben we het over twee verschillende dingen?

[Kek]

Het gaat om een tcp sessie binnen de tunnel, niet hoe de tunnel zelf is opgezet

[Mikanzana]

Nee, de kwetsbaarheid is gebaseerd op hoe TCP werkt.

[xmenno]

Bij UDP heb je geen ack dus in theorie niet, maar dat is meteen ook weer het zwakke van UDP. Je hebt dan nog minder controle over de juistheid van het pakket.

[Eonfge]

Belangrijk detail welke de journalisten van The Register benoemen: de aanval is in de praktijk moeilijk uit te voegen. Er moet namelijk behoorlijk wat data onderschept worden om de juiste volgorde van berichten en codes te ontrafelen.

[michielRB]

Een beetje VPN provider genereert BERGEN met data... Niet dat je daar als privaat persoon bij kan, maar een beetje dienst geeft dit enorme hoeveelheden met informatie. Niets zo gevaarlijk als _denken_ dat je veilig bent, terwijl er anderen stiekem meekijken.

[desalniettemin]

Zoals gewoonlijk zal dat snel gepatched worden. En ik gebruik geen VPN.

[Verwijderd]

Even een one-liner om snel te controleren of rp_filter aanstaat op al je netwerk interfaces:
sudo sysctl --all | grep rp_filter

Nogmaals 1 is aan en 0 is uit, dus je wilt het liefst 1 zien. Let wel arp_filter != rp_filter

[Klojum]

Zojuist een update van de NordVPN applicatie ontvangen voor op een Ubuntu-machine, en meteen was de networkconfiguratie naar de kl0te... Gelukkig heb ik een backup, maar je zou denken dat e.e.a. voorafgaande aan een release getest wordt.