Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

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.

Door Olaf van Miltenburg

Nieuwscoördinator

06-12-2019 • 15:04

66 Linkedin Google+

Submitter: Le Mol

Reacties (66)

Wijzig sortering
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?
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.
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 6 december 2019 15:32]

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 6 december 2019 15:23]

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.
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.
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.
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 6 december 2019 15:44]

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.
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... :)
Voor zover ik weet kan dat nog steeds met Windows 10. Kijk eens in C:\Windows\System32\Drivers\etc\hosts.txt
Zonder .txt

Niet alle bestanden met tekst als inhoud hebben een extensie nodig.
Werkt nog steeds in W10, ik gebruik het om de reclame in skype for windows niet door te laten komen.
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 6 december 2019 15:45]

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 6 december 2019 15:26]

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).
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 6 december 2019 15:55]

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.
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 6 december 2019 17:17]

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.
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.
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.
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.
Binnen Debian is men bezig om alternatieve init systemen te ondersteunen, naast systemd. Als dat van de grond komt is Devuan overbodig.
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 6 december 2019 16:12]

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.
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.
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.
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.
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.
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 7 december 2019 05:41]

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.
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 6 december 2019 16:42]

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 6 december 2019 16:42]

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 6 december 2019 21:18]

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.
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.
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 6 december 2019 15:32]

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?
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).
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 ?
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?
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)
Het gaat om een tcp sessie binnen de tunnel, niet hoe de tunnel zelf is opgezet
Nee, de kwetsbaarheid is gebaseerd op hoe TCP werkt.
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.
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.
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.
Zoals gewoonlijk zal dat snel gepatched worden. En ik gebruik geen VPN.

Op dit item kan niet meer gereageerd worden.


Apple iPhone 11 Microsoft Xbox Series X LG OLED C9 Google Pixel 4 CES 2020 Samsung Galaxy S20 4G Sony PlayStation 5 Nintendo Switch Lite

'14 '15 '16 '17 2018

Tweakers vormt samen met Hardware Info, AutoTrack, Gaspedaal.nl, Nationale Vacaturebank, Intermediair en Independer DPG Online Services B.V.
Alle rechten voorbehouden © 1998 - 2020 Hosting door True