Aanvallers kunnen vpn-verkeer afluisteren met TunnelVision-aanval

Een nieuwe aanval genaamd TunnelVision laat aanvallers niet-versleuteld verkeer afluisteren, terwijl het voor de gebruiker lijkt alsof er gebruik wordt gemaakt van een veilige vpn-verbinding. Vrijwel alle besturingssystemen en vpn-diensten zijn kwetsbaar.

Voor de aanval wordt misbruik gemaakt van een dhcp-server in het netwerk. Die beheert de ip-adressen die verbinding maken met het netwerk in kwestie. Via optie 121 op een apparaat krijgt de dhcp-server echter de mogelijkheid om de standaard routingregel te veranderen, schrijven onderzoekers van Leviathan Security, dat de aanval ontdekte. Daardoor wordt al het vpn-verkeer van een beoogd slachtoffer direct naar een lokaal netwerk of malafide gateway gestuurd en komt het nooit in een versleutelde vpn-tunnel terecht.

Daarvoor is wel vereist dat de dhcp-server op hetzelfde netwerk draait als de beoogde vpn-gebruiker. Dit kan bijvoorbeeld een openbaar wifinetwerk in een hotel of op een vliegveld zijn. Vervolgens wordt de dhcp-configuratie zo ingesteld dat deze zichzelf als gateway gebruikt. Maakt een apparaat verbinding met deze server en bereikt het verkeer de gateway, dan wordt het alsnog doorgezet naar een legitieme gateway. Zo denken slachtoffers dat hun verbinding goed beveiligd is, maar in werkelijkheid kunnen aanvallers het verkeer afluisteren.

Volgens de onderzoekers werkt de aanval het beste als de dader administratorrechten op het netwerk heeft, want dan kan de aanvaller dhcp-optie 121 gewoon aanzetten. Maar Leviathan benadrukt dat de aanval ook ingezet kan worden als iemand die rechten niet heeft. Een kwaadwillende kan zelf een dhcp-server opzetten op een netwerk en zo de aanval uitvoeren. In principe zijn alle grote besturingssystemen kwetsbaar, behalve Android, dat geen ondersteuning heeft voor dhcp-optie 121. Op Linux kan de impact via de instellingen beperkt worden, maar niet volledig uitgesloten worden.

Leviathan Security deelt in zijn rapport diverse mitigerende maatregelen die vpn-gebruikers kunnen inzetten om aanvallen te voorkomen. Zo wordt geadviseerd vpn-clients zo te configureren dat al het inkomend en uitgaand verkeer dat de vpn-interface niet gebruikt, geweigerd wordt. Ook luidt het advies om systemen zo te configureren dat dhcp-optie 121 genegeerd wordt als er verbinding is gemaakt met een vpn.

Door Eveline Meijer

Nieuwsredacteur

Feedback • 09-05-2024 11:05
95 • submitter: wildhagen

09-05-2024 • 11:05

95 Linkedin Whatsapp

Submitter: wildhagen

Lees meer

AWS, Google en tientallen andere bedrijven beloven veiligere producten te maken
AWS, Google en tientallen andere bedrijven beloven veiligere producten te maken Nieuws van 9 mei 2024
Vpn-dienst Mullvad waarschuwt voor dns-lekken op Android
Vpn-dienst Mullvad waarschuwt voor dns-lekken op Android Nieuws van 3 mei 2024
Google weerde 2,3 miljoen foute apps uit Play Store in 2023
Google weerde 2,3 miljoen foute apps uit Play Store in 2023 Nieuws van 2 mei 2024
Microsoft: Windows-beveiligingsupdate zorgt voor vpn-problemen
Microsoft: Windows-beveiligingsupdate zorgt voor vpn-problemen Nieuws van 1 mei 2024
Mandiant: spionnen vallen steeds vaker 'edge'-tools zoals firewalls en vpn's aan
Mandiant: spionnen vallen steeds vaker 'edge'-tools zoals firewalls en vpn's aan Nieuws van 25 april 2024
Meer producten en artikelen
Beveiliging en antivirus Dhcp Security Vpn

Reacties (95)

-Moderatie-faq
95
94
49
3
0
35
Wijzig sortering
Jimbolino
9 mei 2024 19:24
Wel raar dat het OS een hogere prioriteit geeft aan routes die via een dhcp message worden gezet, dan routes die door software op het apparaat zelf worden gezet.

Denk dat de impact van de "aanval" maar klein is. Als je serieus niet afgeluisterd wil worden, dan gebruik je Tor browser en/of Tails OS.
Ook andere vpn clients die je als browser plugin installeert zijn niet vatbaar voor dit probleem, want die bepalen zelf welk verkeer er over de vpn tunnel gaat.

Er is tegenwoordig nog maar weinig unencrypted verkeer op internet, dus zelfs op een compromised netwerk, is de kans klein dat je iets zinvols kunt afluisteren.
Reageer
Armada651
@Jimbolino • 10 mei 2024 04:52
VPNs worden niet alleen gebruikt voor privacy. Het wordt ook gebruikt door bedrijven om diensten af te schermen van de rest van het internet. Vaak zijn deze diensten unencrypted omdat er vanuit wordt gegaan dat de VPN de verbinding beveiligd.
Reageer
vliegendekat
@Jimbolino • 10 mei 2024 22:52
Wel raar dat het OS een hogere prioriteit geeft aan routes die via een dhcp message worden gezet, dan routes die door software op het apparaat zelf worden gezet.
Nee dat is niet vreemd, want het verkeer dat door de VPN heen gaat moet ook ergens heen.
Als het netwerk A waar de VPN-gebruiker op zit toevallig dezelfde IPv4 space heeft als het IPv4 netwerk aan de andere kant van de VPN (Netwerk B), dan moet het VPN verkeer eerst door netwerk A heen om zo bij netwerk C te komen dat netwerk A en B met elkaar verbindt.
Netwerk C is meestal overigens het internet, maar het kan net zo goed een afgeschermd netwerk zijn.

De crux is dat je eerst van netwerk A naar C moet komen en als netwerk A dan dezelfde ip-space heeft als netwerk B, dan kan er verwarring ontstaan in de software. Echter zal het OS altijd prioriteit moeten geven aan de regels van netwerk A als het OS het VPN-verkeer dat bedoelt is voor netwerk B de deur uit wilt krijgen.
Denk dat de impact van de "aanval" maar klein is. Als je serieus niet afgeluisterd wil worden, dan gebruik je Tor browser en/of Tails OS.
Ook andere vpn clients die je als browser plugin installeert zijn niet vatbaar voor dit probleem, want die bepalen zelf welk verkeer er over de vpn tunnel gaat.
Bovenstaande zal altijd gebeuren, ook in Tails OS, tenzij er door de gebruiker lokaal keihard iets anders is ingesteld en de opdracht gegeven is om de route-announcements van DHCP te negeren.

De Tor-browser zal het waarschijnlijk WEL goed doen, maar dat komt omdat die browser het verkeer rechtstreeks zijn ingebouwde VPN in slingert en verder binnen de tunnel niet zoveel met IP-adressen te maken heeft.
Er is tegenwoordig nog maar weinig unencrypted verkeer op internet, dus zelfs op een compromised netwerk, is de kans klein dat je iets zinvols kunt afluisteren.
Dat kopt, maar onderschat niet hoeveel informatie er alsnog vergaard kan worden uit een versleutelde verkeersstroom.
Reageer
RxTweak
9 mei 2024 11:10
is dit niet gewoon een backdoor? Wat is anders een legitieme functie van dhcp-optie 121?

[Reactie gewijzigd door RxTweak op 9 mei 2024 11:11]

Reageer
Bor
@RxTweak • 9 mei 2024 11:16
Nee dit is geen backdoor. DHCP optie 121 is gewoon een legitieme DHCP optie voor classless statische routering.

Zie de RFC voor meer uitleg: RFC3442

Option 121—Classless route option. It specifies a list of classless static routes (the destination network addresses in these static routes are classless) that the requesting client should add to its routing table.
Classless Route Option Format

The code for this option is 121, and its minimum length is 5 bytes.
This option can contain one or more static routes, each of which
consists of a destination descriptor and the IP address of the router
that should be used to reach that destination.

Code Len Destination 1 Router 1
+-----+---+----+-----+----+----+----+----+----+
| 121 | n | d1 | ... | dN | r1 | r2 | r3 | r4 |
+-----+---+----+-----+----+----+----+----+----+

Destination 2 Router 2
+----+-----+----+----+----+----+----+
| d1 | ... | dN | r1 | r2 | r3 | r4 |
+----+-----+----+----+----+----+----+

In the above example, two static routes are specified.

Destination descriptors describe the IP subnet number and subnet mask of a particular destination using a compact encoding. This encoding consists of one octet describing the width of the subnet mask, followed by all the significant octets of the subnet number.

The width of the subnet mask describes the number of one bits in the mask, so for example a subnet with a subnet number of 10.0.127.0 and a netmask of 255.255.255.0 would have a subnet mask width of 24.

The significant portion of the subnet number is simply all of the octets of the subnet number where the corresponding octet in the subnet mask is non-zero. The number of significant octets is the width of the subnet mask divided by eight, rounding up, as shown in the following table:

Width of subnet mask Number of significant octets
0 0
1- 8 1
9-16 2
17-24 3
25-32 4

The following table contains some examples of how various subnet number/mask combinations can be encoded:

Subnet number Subnet mask Destination descriptor
0 0 0
10.0.0.0 255.0.0.0 8.10
10.0.0.0 255.255.255.0 24.10.0.0
10.17.0.0 255.255.0.0 16.10.17
10.27.129.0 255.255.255.0 24.10.27.129
10.229.0.128 255.255.255.128 25.10.229.0.128
10.198.122.47 255.255.255.255 32.10.198.122.47

Local Subnet Routes

In some cases more than one IP subnet may be configured on a link. In such cases, a host whose IP address is in one IP subnet in the link could communicate directly with a host whose IP address is in a
different IP subnet on the same link. In cases where a client is being assigned an IP address on an IP subnet on such a link, for each IP subnet in the link other than the IP subnet on which the client has been assigned the DHCP server MAY be configured to specify a router IP address of 0.0.0.0.

For example, consider the case where there are three IP subnets configured on a link: 10.0.0/24, 192.168.0/24, 10.0.21/24. If the client is assigned an IP address of 10.0.21.17, then the server could
include a route with a destination of 10.0.0/24 and a router address of 0.0.0.0, and also a route with a destination of 192.168.0/24 and a router address of 0.0.0.0.

A DHCP client whose underlying TCP/IP stack does not provide this capability MUST ignore routes in the Classless Static Routes option whose router IP address is 0.0.0.0. Please note that the behavior
described here only applies to the Classless Static Routes option, not to the Static Routes option nor the Router option.

[Reactie gewijzigd door Bor op 9 mei 2024 11:17]

Reageer
The Zep Man
@Bor • 9 mei 2024 12:27
Nee dit is geen backdoor. DHCP optie 121 is gewoon een legitieme DHCP optie voor classless statische routering.
Legitiem, maar hoe vaak zou het negeren van die optie in de praktijk problemen opleveren?
Reageer
Annihlator
@The Zep Man • 9 mei 2024 13:45
Vaker dan je zou verwachten.

Dit komt bijvoorbeeld ook voor bij dubbele NAT (classless static routes), en héél veel mensen doen dat zonder dit te beseffen.

[Reactie gewijzigd door Annihlator op 9 mei 2024 13:45]

Reageer
The Zep Man
@Annihlator • 9 mei 2024 14:26
Nu is NAT sowieso al een workaround voor een groter probleem, en kan je een dubbel NAT ook zodanig inrichten dat enkel default gateways nodig zijn (twee routers).

De implicatie is: over op exclusief IPv6, en vertrouw dergelijke opties niet meer.
Reageer
RobertMe
@The Zep Man • 9 mei 2024 15:13
Bij IPv6 kan juist elk device IPv6 router advertisements het netwerk in gooien. Waaronder RAs die alleen maar routing informatie bevatten (dit is iets dat ikzelf gebruik op mijn thuisserver waarbij Docker containers hun eigen prefix gebruiken, en de server publiceert dus een RA met "voor subnet fd00:1234:5678::/64 moet je bij mij zijn").

Met IPv6 is dit probleem in publieke netwerken met een malafide client dus alleen maar groter. Bij IPv4 is er immers een DHCP server nodig op dat malafide apparaat en moet de client toevallig de DHCP response van dat malafide apparaat gebruiken (50% kans dat of de echte router of het malafide apparaat antwoord). Terwijl bij IPv6 er dus 100% kans is dat de RA van het malafide gebruikt wordt (de echte router kan prima een RA sturen met een IPv6 prefix, routing info, etc, en dat daarnaast een ander (malafide) apparaat ook een RA stuurt, met alleen routing info).

En in het geval van een malafide netwerk / router / beheerder maakt IPv4 vs IPv6 uiteraard helemaal geen verschil in deze.
Reageer
Annihlator
@The Zep Man • 9 mei 2024 14:37
Dat heeft natuurlijk ook weer zn eigen implicaties en juist waar je de dubbele NAT tegenkomt lost dat het probleem ook niet op.

Ook zéker bij die categorie klanten moet je gewoon niet willen dat er een 1-op-1 relatie is naar een intern apparaat... al helemaal als je erbij stilstaat hoevaak nog steeds aangeraden wordt UPNP en NAT-STUN áán te laten
Reageer
CaptainKansloos
@Bor • 9 mei 2024 13:02
Uit de blogpost van de onderzoekers zelf:
The attacker changes the DHCP configuration to push option 121 classless static routes (RFC3442) to the victim.

As an attacker, we can control the IP or ranges we want to leak by adjusting the prefix length of the route we push. I.e. a /32 vs /1 prefix length.

The routing table of the victim adds the route from DHCP automatically.

The highest prefix length match is chosen. I.e. a /32 route has a higher prefix length than a /1 route.
DHCP routes are automatically configured to go over the same interface as the DHCP server.
Routing decisions happen before the traffic can be encrypted (see appendix diagrams), so traffic will be unencrypted.
It does not matter what VPN protocol is in use or the strength of its encryption.
Punt is dus dat je door routes te injecteren met een hogere prefix length je verkeer naar een andere interface dan de VPN tunnel zou kunnen leiden.

In hetzelfde artikel staat onderaan in de diagrams ook een oplossing door het implementeren van correcte firewall rules.

https://github.com/leviathansecurity/TunnelVision

Volgens mij ben je dan beschemd, maar werkt bij een aanval je verbinding dus maar half of niet. De routerings tabel klopt niet, maar het verkeer loopt stuk op de FW ipv dat het door de juiste interface gaat.
Reageer
CAPSLOCK2000
@RxTweak • 9 mei 2024 14:08
is dit niet gewoon een backdoor? Wat is anders een legitieme functie van dhcp-optie 121?
Ik vind het inderdaad een klassieke backdoor in de ouderwetse betekenis van een extra route. Tegenwoordig gebruiken we de term vooral voor stiekem ingeboud gat, maar het hoeft niet met opzet te zijn gedaan. Het is ook geen geheim dat je huis een achterdeur heeft, die heeft de architect er bewust ingebouwd. Het probleem is dat mensen vergeten dat ze hun achterdeur net zo goet moeten beveiligen als de voordeur.

Dus ik vind het niet gek om het een backdoor te noemen maar in de pers en media heeft het woord een zeer negatieve lading gekregen en wordt gessocieerd met misdaad en dat is hier niet echt van toepassing.

Dat is echter vooral een taalkundigprobleem. Hierboven kun je zien dat mensen het anders uitleggen en het geen backdoor noemen omdat het ook/vooral legitieme toepassingen heeft. Voor de veiligheid maakt het niet uit welke naam we er op plakken.

[Reactie gewijzigd door CAPSLOCK2000 op 9 mei 2024 14:09]

Reageer
cariolive23
@CAPSLOCK2000 • 10 mei 2024 05:40
Met een backdoor wordt een verborgen achterdeurtje bedoelt, daar is hier geen sprake van. Optie 121 is een bekende optie, staat keurig gedocumenteerd.
Reageer
oef!
9 mei 2024 11:13
Wat is de impact in de praktijk? Het meeste verkeer zal toch versleuteld zijn.
Reageer
RobertMe
@oef! • 9 mei 2024 11:32
In combinatie met een rogue DNS server zou wellicht het een en ander kunnen. Als je bv op een publiek netwerk met VPN zit zal jou DNS en overige internetverkeer over de VPN gaan. Als je vervolgens bv de website van jouw bank bezoekt zal de DNS query over de VPN gaan naar jou vertrouwde DNS server, en het internet verkeer zelf gaat dan ook over de VPN heen.

Als die publieke wifi echter dit trucje toepast zou bv het DNS verkeer onderschept kunnen worden met een Man-in-the-Middle aanval. Waarna de DNS query voor bv ing.nl niet het IP adres van ing.nl teruggeeft maar van een phishing site. Waarna je dus ook verbinding probeert te maken met die phishing site, wat ook dan weer buiten de VPN om gaat. En die phishing site zou dan bv ook gewoon geen HTTPS kunnen toepassen.

Echter wordt je hierdoor ook weer (gedeeltelijk) beschermd door HSTS, HTTP Strict Transport Security. Dit is gedeeltelijk een lijst, ingebakken in de browser, van domeinnamen die altijd HTTPS moeten gebruiken, en aangevuld door websites die middels een header zelf aangeven dat HTTPS gebruikt moeten worden (als deze niet preloaded is). Dus als je zo'n site minimaal eenmalig bezocht hebt (en als de domeinnaam preloaded is hoef je deze helemaal niet bezocht te hebben) zal de browser HTTPS afdwingen en ook geen mogelijkheid geven om te bezoeken als het maar HTTP is noch de mogelijkheid geven een ongeldig / verlopen certificaat te negeren.
Reageer
Triblade_8472
@RobertMe • 9 mei 2024 12:01
Volgens mij gebruiken de meeste banken certificate pinning. Dan heeft het nog weinig zin.
Reageer
RobertMe
@Triblade_8472 • 9 mei 2024 12:07
Apps? Ja. Browser heeft AFAIK geen mogelijkheid hiertoe. Immers zou de bank dan de fingerprint bij de browser maker moeten kunnen aanleveren en updaten. En je wilt ook niet dat iemand met een verouderde browser ineens de bank website niet meer kan openen omdat het certificaat is gewijzigd (want IIRC is het de fingerprint van een specifiek certificaat, dus bij het vernieuwen (tegen de vervaldatum / ...) zal er ook weer een nieuwe fingerprint zijn).
En bij apps speelt dat probleem uiteraard ook, maar een app bevat dan de fingerprint van 1 site. Een browser zou dan de fingerprints van honderden als niet duizenden sites moeten bevatten. Waarbij er altijd wel weer een site een nieuw certificaat heeft/krijft en dus de browser geupdate zou moeten worden met dr bijgewerkte fingerprint(s).
Reageer
latka
@RobertMe • 9 mei 2024 13:18
Chrome doet aan certificate pinning voor de Google certs. Dat was hoe men er achter kwam dat (ik meen) Iran iets deed met fake certificaten voor haar burgers.
Reageer
tedades
@Triblade_8472 • 9 mei 2024 12:22
Certificate pinning is inderdaad een goed idee. Ik heb vroeger een eigen http-proxy opgezet met geldig certificaat en zo kon ik al het HTTPS verkeer inzien. In combinatie met een HTTP permanent redirect naar het IP van deze proxy werkte dit ook als iemand van terug schakelde van wifi naar een mobiele verbinding. Apps met certificate pinning waren hier tegen bestand. Tegenwoordig werkt die methode niet meer, deels omdat alles nu HTTPS verwacht en omdat iPhones volgens mij die permanent redirect niet permanent onthouden.
Reageer
jcbvm
@RobertMe • 9 mei 2024 14:50
Voorkomt een dnssec niet een man in the middle attack bij dns?
Reageer
thomas_n
@oef! • 9 mei 2024 11:55
Volgens deze onderzoekers (quote uit dit artikel van Ars Technica, dikgedrukt door mij):
Pushing a route also means that the network traffic will be sent over the same interface as the DHCP server instead of the virtual network interface. This is intended functionality that isn’t clearly stated in the RFC. Therefore, for the routes we push, it is never encrypted by the VPN’s virtual interface but instead transmitted by the network interface that is talking to the DHCP server. As an attacker, we can select which IP addresses go over the tunnel and which addresses go over the network interface talking to our DHCP server.
(...)
We now have traffic being transmitted outside the VPN’s encrypted tunnel. This technique can also be used against an already established VPN connection once the VPN user’s host needs to renew a lease from our DHCP server. We can artificially create that scenario by setting a short lease time in the DHCP lease, so the user updates their routing table more frequently. In addition, the VPN control channel is still intact because it already uses the physical interface for its communication. In our testing, the VPN always continued to report as connected, and the kill switch was never engaged to drop our VPN connection.
Het verkeer is dan dus niet versleuteld.
Reageer
oef!
@thomas_n • 9 mei 2024 12:19
HTTPS en andere versleutelde protocollen binnen een encrypted VPN zijn versleuteling binnen versleuteling. Als de VPN laag wegvalt zal TLS nog steeds in place zijn.
Reageer
CaptainKansloos
@thomas_n • 9 mei 2024 12:35
Het heeft te maken met het toestaan van 'localnet' adressen buiten de VPN interface om aldus Mullvad:https://mullvad.net/en/bl...he-impact-of-tunnelvision

Op de meeste platforms werkt dat voor de Mullvad client kennelijk niet; vrijwel alles wordt gewongen de tunnel in gerouteerd. IOS is een uitzondering kennelijk.

Ik vraag me wel af in hoeverre de prioriteit van de interface (VPN of niet) binnen het OS nog van invloed is. Op zich kan een VPN tunnel best verkeer naar lokale netwerken blokkeren (met een firewall), tenzij het lager op de routering prio lijst van het OS belandt. Dan heeft een andere interface voorrang.
Reageer
SillieWous
@oef! • 9 mei 2024 11:22
Dat zou natuurlijk zo moeten zijn. Maar het zou mij niks verbazen dat er nog veel industriële apparatuur dit niet heeft (en bijv telnet gebruikt). Waar dan wordt uit gegaan dat versleuteling via VPN gaat.

Maar goed dan zou je geen verbindingen moeten toestaan van onbekende netwerken, zoals een publiek netwerk van een cafe o.i.d.
Reageer
jvanhambelgium
@SillieWous • 9 mei 2024 12:37
Sowieso veel industrieel spul dat ik tegenkom in gebouw-technische systemen (plc's , luchtgroepen, knx , geothermisch,...) werken zelden met DHCP trouwens. Ze "kunnen" het mischien wel protocol-matig, maar tijdens implementatie is het veelal statisch. (weeral een zwakke schakel minder in de ketting). Als je een goed IP-plan opzet kom je al een héél eind.
Reageer
FrankHe
@jvanhambelgium • 9 mei 2024 17:51
Inderdaad, zodra je een VPN-tunnel opzet naar statisch IP-adres dan heb je dit probleem dus niet.
Reageer
CAPSLOCK2000
@oef! • 9 mei 2024 14:14
Wat is de impact in de praktijk? Het meeste verkeer zal toch versleuteld zijn.
Dat ligt er nogal aan wat het doel van je VPN is.

Een van de toepassingen van VPN is juist het toevoegen van versleuteling aan netwerkverkeer van applicaties die dat zelf niet kunnen. Als dat wegvalt is het natuurlijk direct een probleem.

Een andere toepassing is verbergen waar verkeer echt vandaan komt of naar toe gaat. Een VPN verbergt het IP-adres van bron en/of doel. Dan doet het er niet zo toe of payload verpakt is. Als je ziet dat het IP-adres hoort bij een kerk, geheime dienst, concurrerend bedrijf of criminele organisatie dan weet je misschien al genoeg.
Reageer
michielRB
9 mei 2024 11:11
Een kwaadwillende kan zelf een dhcp-server opzetten op een netwerk en zo de aanval uitvoeren.
Misschien ben ik heel erg old-school maar er zijn toch mechanismen die er voor zorgen dat IP adressen van rogue DHCP-servers niet geaccepteerd worden?

[Reactie gewijzigd door michielRB op 9 mei 2024 11:12]

Reageer
stappel_
@michielRB • 9 mei 2024 11:23
DHCP guard en DHCP snooping aanzetten.
Reageer
Blokker_1999
@stappel_ • 9 mei 2024 12:01
Maar daar heb je als eindgebruiker dan weer geen vat op want vanop je eigen machine kan je je er niet tegen beschermen. Je kan alleen maar hopen dat het netwerk waarmee je verbonden bent de nodige maatregelen heeft getroffen.
Reageer
xxs
@stappel_ • 9 mei 2024 11:50
Dat doe je server-side niet client-side en bij het gebruik van een hotspot heb jij hopelijk geen toegang tot die router/dhcp server.

Sorry, ik zat in de hotspot mode, op je eigen netwerk kan het het natuurlijk voorkomen.

[Reactie gewijzigd door xxs op 9 mei 2024 11:53]

Reageer
NielsFL
@michielRB • 9 mei 2024 16:03
Absoluut. Een rogue DHCP server die de verkeerde adressen uitdeelt is voldoende om een netwerk plat te leggen.

Er zijn verschillende manieren om dit te filteren. Zelf blokkeer ik op alle switch poorten UDP/68, behalve op de switch poort waar de echte DHCP server aan hangt.
Reageer
wica
9 mei 2024 11:28
Lijkt heel veel op een aanval uit 08-2023
https://tunnelcrack.mathyvanhoef.com/
Reageer
banaj
9 mei 2024 11:30
Als een aanvaller een rogue DHCP-server op je netwerk draait zijn er grotere problemen dan corner case "ik kan een VPN re-routen"...
Reageer
kodak
9 mei 2024 11:32
Als je uitgangspunt is dat je lokale netwerk niet te vertrouwen is (bijvoorbeeld omdat je de administrator niet vertrouwd) dan is de regel dat je dus hoe dan ook maatregelen treft om niet zomaar het netwerk te vertrouwen. Dat was dus al niet simpel het gebruiken van een vpn, maar ook van juiste aanpassing van wat je nodig hebt om de verbinding te vertrouwen. Wat dat betreft heeft het security bedrijf dus niets nieuws ontdekt, ze bevestigen vooral dat dit nodig is. Maar dat kunnen we net zo goed stellen voor alle andere opties die een goede vpn geeft maar op het verkeerde moment niet gebruikt worden door te veel vertrouwen of onwil.
Reageer
watabstract
9 mei 2024 16:01
Dat is dan meteen een hele goeie extra reden om als de bliksem over te stappen op IPv6. Dan kun je DHCP bij het grofvuil zetten en is dit probleem opgelost.
Reageer
trab_78
9 mei 2024 12:00
Dit geldt alleen als je VPN gebruikt voor anoniem surfen of het omzeilen van geoblocking. Een VPN tunnel naar een privaat netwerk is niet kwetsbaar voor deze aanval.
Reageer
RobertMe
@trab_78 • 9 mei 2024 12:21
Als ik je goed begrijp, dan ja / nee. Het grootste probleem ontstaat als je alle verkeer over de VPN laat gaan. Immers wordt dan een default route ingesteld, die makkelijk te overrulen is met routes voor 0.0.0.0/1 en 128.0.0.0/1. En als dit de enige overrule van de aanvaller is dan zal een VPN inzet voor alleen het benaderen van een privaat netwerk, dus bv met een route voor 10.0.0.0/24, niet kwetsbaar zijn doordat deze route prefix kleiner is en daardoor de gekozen route zal zijn. Echter kan de aanvaller ook veel meer kleinnere routes (laten) instellen, dus bv 10.0.0.0/28 en 10.0.0.128/28, waardoor jouw eigen 10.0.0.0/24 toch weer "onderdrukt" wordt.

Waarbij de door jouw aangehaalde "voor anoniem surfen of het omzeilen van geoblocking" vs "een privaat netwerk" wel erg beperkt is. Bedrijven bv zullen vaak genoeg een VPN toepassen op roaming apparaten. Niet alleen om de medewerker toegang te geven tot systemen / ... op het bedrijfsnetwerk, maar ook om alle verkeer over de tunnel te sturen zodat het verkeer ook gecontroleerd of gelogd kan worden (bv een uitgebreidere firewall of deep packet inspection), of voor het benaderen van ("publieke") systemen met een whitelist. Bv publieke servers waarop SSH alleen open staat voor het IP adres "van kantoor".
Er kunnen dus 1000-en-1 redenen zijn om een VPN te willen gebruiken waar alle verkeer overheen gaat, en niet alleen anoniem surfen of omzeilen georestricties. Waarbij omzeilen georestricties juist ook nog eens zou kunnen door weer alleen de IP adressen van die dienst / ... over de VPN te routeren (dus wat jij noemt onder "private netwerken", alleen dan gewoon "een klein deel van het publieke internet")
Reageer
trab_78
@RobertMe • 9 mei 2024 17:33
Dat is een goede toevoeging.

Overigens: als de aanvaller meerdere kleinere routes aanmaakt en je benadert een private server, dan zal je dat gegarandeerd merken. De kans dat de aanvaller namelijk precies dezelfde server op hetzelfde adres draait is natuurlijk erg klein.
Reageer
themadone
@trab_78 • 9 mei 2024 12:24
Dit is een heel belangrijke toevoeging, dit hoort in het artikel te staan.

Enige verkeer wat "afgeluisterd" wordt is verkeer naar publiek toegankelijke plekken zoals websites etc.

Deze aanval zal voor de meeste zakelijke gebruikers eerder leiden tot een niet functionerende vpn dan een afgeluisterde. Immers internal resources zijn op deze manier ook niet meer te benaderen.
Reageer
Bor
@trab_78 • 9 mei 2024 13:09
Even plat gezegd; Een VPN is een VPN. Wat je daar mee doet maakt niet uit. Er is ook geen verschil tussen een "VPN voor anoniem surfen" of een andersoortige VPN. Het enige verschil zit hem in wat de aanvaller logischerwijs kan doorsturen (en wat dus blijft werken).

[Reactie gewijzigd door Bor op 9 mei 2024 13:10]

Reageer
trab_78
@Bor • 9 mei 2024 17:35
Nee. Het verschil is met name of je al het verkeer over de VPN leidt, of alleen het verkeer naar je eigen servers. Dat laatste gebeurt veel bij VPNs die alleen nodig zijn om bepaalde servers te benaderen.
Reageer
Bor
@trab_78 • 9 mei 2024 18:19
Waar je op doelt is split tunneling. Dat is bij deze aanval niet geheel relevant. Ook bij een split tunnel zou je deze aanval kunnen toepassen.
Reageer
localhost
9 mei 2024 11:22
Het is natuurlijk zo dat de VPN Client in de lead is om te bepalen hoe het verkeer je PC verlaat. De VPN Client moet er vervolgens voor zorgen dat alleen met een valide Endpoint (VPN Server) contact mag worden gelegd. Met bv een SSL VPN kan het certificaat gecontroleeerd worden voordat de VPN verbinding tot stand komt. Als dat allemaal geregeld is, lijkt me dat DHCP optie 121, ondanks dat die in het netwerk zit, weinig kans van slagen heeft.
Reageer
BrZ
@localhost • 9 mei 2024 11:43
De VPN client is niet in de lead, dat is je routing tabel. Je VPN client past de routing tabel aan op het moment dat je verbinding maakt, zodat het verkeer via de VPN verbinding gerouteerd wordt.

De VPN connectie wordt met deze "exploit" dan ook normaal opgezet, alleen zorgt de DHCP optie 121 dat je routing zo gemanipuleerd wordt dat je verkeer helemaal niet over de VPN loopt, maar gewoon via de normale gateway, en dus niet geencrypt wordt.
Reageer
fopjurist
@localhost • 9 mei 2024 11:49
Het nieuws is juist dat je verkeer kunt afluisteren ondanks dat de VPN-client verbinding maakt met alle controles die jij noemt. Nadat de verbinding tot stand komt, versleutelt een VPN-client alleen verkeer dat via de VPN-verbinding loopt. Door de routetabel aan te passen kun je ervoor zorgen dat verkeer niet via de VPN-server loopt.

Stel dat je IP-adres van je netwerkinterface 192.168.0.101 is, van je VPN-interface 10.10.10.2, en dat de VPN-server het publieke IP-adres 12.34.56.78 heeft. Dan heb je normaal een default gateway als 10.10.10.1, en een routeregel dat verkeer naar 12.34.56.78/32 via 192.168.0.1 loopt. Als je via een DCHP-aanval extra routeregels toevoegt die verkeer naar 0.0.0.0/1 en naar 128.0.0.0/1 via 192.168.0.102 leiden, dan wordt de default gateway niet meer gebruikt omdat er specifiekere routes bestaan (/1 ipv /0), en gaat al het netwerkverkeer onversleuteld naar 192.168.0.102 ipv over de VPN-interface.
Reageer
CAPSLOCK2000
@localhost • 9 mei 2024 14:39
Het is natuurlijk zo dat de VPN Client in de lead is om te bepalen hoe het verkeer je PC verlaat. De VPN Client moet er vervolgens voor zorgen dat alleen met een valide Endpoint (VPN Server) contact mag worden gelegd. Met bv een SSL VPN kan het certificaat gecontroleeerd worden voordat de VPN verbinding tot stand komt. Als dat allemaal geregeld is, lijkt me dat DHCP optie 121, ondanks dat die in het netwerk zit, weinig kans van slagen heeft.
Nee, zo werkt het niet. De VPN-client kan het OS vragen om de routes aan te passen, maar niet dwingen.

Uiteindelijk staat het OS boven de VPN-client, en de beheerder staat boven het OS (in ieder geval op Linux, de commerciele OSen gaan hard de andere kant op).

Ik heb verschillende VPNs actief en ben heel bij dat die elkaar onderling met rust laten en dat ik zelf kan bepalen hoe het verkeer gerouteerd wordt. Sommig verkeer mag alleen naar het VPN van mijn werkgever, ander verkeer mag alleen naar mijn vrienden in China.

De een z'n bug is de ander z'n feature.
Reageer
NielsFL
@localhost • 9 mei 2024 16:05
Er zijn VPN clients die dat inderdaad zo doen. Dat levert echter allerlei andere problemen op, zoals het niet kunnen bereiken van lokale printers en file-servers.

De meeste VPN clients vervangen daarom alleen de 'default route' en laten lokale routes ongemoeid.
Reageer
1 2


Om te kunnen reageren moet je ingelogd zijn

Tweakers maakt gebruik van cookies

Tweakers plaatst functionele en analytische cookies voor het functioneren van de website en het verbeteren van de website-ervaring. Deze cookies zijn noodzakelijk. Om op Tweakers relevantere advertenties te tonen en om ingesloten content van derden te tonen (bijvoorbeeld video's), vragen we je toestemming. Via ingesloten content kunnen derde partijen diensten leveren en verbeteren, bezoekersstatistieken bijhouden, gepersonaliseerde content tonen, gerichte advertenties tonen en gebruikersprofielen opbouwen. Hiervoor worden apparaatgegevens, IP-adres, geolocatie en surfgedrag vastgelegd.

Meer informatie vind je in ons cookiebeleid.

Sluiten

Toestemming beheren

Hieronder kun je per doeleinde of partij toestemming geven of intrekken. Meer informatie vind je in ons cookiebeleid.

Functioneel en analytisch

Deze cookies zijn noodzakelijk voor het functioneren van de website en het verbeteren van de website-ervaring. Klik op het informatie-icoon voor meer informatie. Meer details

janee

    Relevantere advertenties

    Dit beperkt het aantal keer dat dezelfde advertentie getoond wordt (frequency capping) en maakt het mogelijk om binnen Tweakers contextuele advertenties te tonen op basis van pagina's die je hebt bezocht. Meer details

    Tweakers genereert een willekeurige unieke code als identifier. Deze data wordt niet gedeeld met adverteerders of andere derde partijen en je kunt niet buiten Tweakers gevolgd worden. Indien je bent ingelogd, wordt deze identifier gekoppeld aan je account. Indien je niet bent ingelogd, wordt deze identifier gekoppeld aan je sessie die maximaal 4 maanden actief blijft. Je kunt deze toestemming te allen tijde intrekken.

    Ingesloten content van derden

    Deze cookies kunnen door derde partijen geplaatst worden via ingesloten content. Klik op het informatie-icoon voor meer informatie over de verwerkingsdoeleinden. Meer details

    janee