Un metodo di attacco chiamato TunnelVision è stato presentato, consentendo, in presenza di accesso alla rete locale o controllo su una rete wireless, di reindirizzare il traffico della vittima al proprio host bypassando il VPN (invece di inviare tramite VPN, il traffico verrà inviato in chiaro senza tunneling al sistema dell'attaccante). Questo problema colpisce qualsiasi client VPN che non utilizza spazi dei nomi di rete isolati (network namespace) durante il reindirizzamento del traffico nel tunnel o che non imposta regole di filtraggio dei pacchetti durante la configurazione del tunnel per vietare la routing del traffico VPN attraverso interfacce di rete fisiche esistenti.
L'essenza dell'attacco sta nel fatto che l'attaccante può avviare il proprio server DHCP e utilizzarlo per inviare al client informazioni per modificare la routing. In particolare, l'attaccante può sfruttare l'opzione 121 fornita nel protocollo DHCP (RFC-3442, adottata nel 2002), destinata a trasmettere informazioni su rotte statiche, per intervenire nella tabella di routing della macchina della vittima e reindirizzare il traffico. VPNIl reindirizzamento viene effettuato impostando una serie di rotte per le sottoreti con prefisso /1, che hanno una priorità più elevata rispetto alla rotta predefinita con prefisso /0 (0.0.0.0/0), per cui il traffico invece di essere indirizzato all'interfaccia di rete virtuale VPN designata, sarà instradato attraverso l'interfaccia di rete fisica verso l'host dell'attaccante nella rete locale.
L'attacco può essere effettuato in qualsiasi sistema operativo che supporti l'opzione 121 del DHCP, tra cui Linux, Windows, iOS e macOS, indipendentemente dal protocollo VPN utilizzato (Wireguard, OpenVPN, IPsec) e dall'insieme di cifrature. La piattaforma Android non è vulnerabile all'attacco, poiché non gestisce l'opzione 121 nel DHCP. Tuttavia, l'attacco consente di accedere al traffico, ma non fornisce la possibilità di interferire nelle connessioni o di determinare il contenuto trasmesso utilizzando protocolli di livello applicativo protetti, come TLS e SSH; ad esempio, l'attaccante non può determinare il contenuto delle richieste HTTPS, ma può capire a quali server vengono inviate.
Per proteggersi dall'attacco, si può vietare a livello di filtraggio dei pacchetti l'invio di pacchetti destinati all'interfaccia VPN attraverso altre interfacce di rete; bloccare i pacchetti DHCP con l'opzione 121; utilizzare VPN all'interno di una macchina virtuale separate (o contenitore) isolata dalla rete esterna, oppure applicare modalità di configurazione speciali dei tunnel che utilizzano spazi dei nomi in Linux (network namespace). È stato pubblicato un insieme di script per esperimenti con l'attacco.
Vale la pena notare che l'idea di modifica locale della routing non è nuova ed è stata storicamente utilizzata in attacchi mirati alla sostituzione del server DNS. In un attacco simile, TunnelCrack, dove il reindirizzamento del traffico avveniva attraverso la sostituzione del gateway predefinito, il problema colpiva tutti i client VPN verificati per iOS, il 87,5% dei client VPN per macOS, il 66,7% per Windows, il 35,7% per Linux e il 21,4% per Android. Nel contesto delle VPN e del DHCP, il metodo era già stato menzionato in precedenza; ad esempio, è stato dedicato uno dei dibattiti alla conferenza USENIX 2023 dello scorso anno (lo studio ha mostrato che il 64,6% dei 195 client VPN testati era vulnerabile all'attacco).
Per la sostituzione delle rotte era stato proposto in passato di utilizzare una chiavetta USB appositamente progettata che simula il funzionamento di un adattatore di rete e che, una volta collegata al computer tramite DHCP, si presenta come gateway. Inoltre, con il controllo sul gateway (ad esempio, collegando la vittima a una rete wireless controllata dall'attaccante) è stata sviluppata una tecnica di iniezione di pacchetti nel tunnel, percepiti nel contesto dell'interfaccia di rete VPN.
Flussi di dati durante l'utilizzo del VPN:
Flussi di dati dopo l'attuazione dell'attacco:
Fonte: opennet.ru
