È stato proposto al pubblico un metodo di attacco TunnelVision, che consente, in presenza di accesso alla rete locale o controllo sulla rete wireless, di reindirizzare il traffico della vittima verso il proprio host, aggirando il VPN (invece di inviare tramite VPN, il traffico sarà inviato in chiaro senza tunneling sul sistema dell'attaccante). Sono vulnerabili alla problematica tutti i client VPN che non utilizzano spazi dei nomi isolati del sottosistema di rete (network namespace) per indirizzare il traffico nel tunnel o che non implementano regole di filtraggio dei pacchetti durante la configurazione del tunnel che vietano il routing del traffico VPN attraverso gli interfaccia di rete fisici esistenti.
Il cuore dell'attacco è che l'attaccante può avviare il proprio server DHCP e utilizzarlo per trasmettere al client informazioni per modificare il routing. In particolare, l'attaccante può sfruttare l'opzione 121 fornita nel protocollo DHCP (RFC-3442, adottata nel 2002), destinata a fornire informazioni su rotte statiche, per apportare modifiche alla tabella di routing sulla macchina della vittima e deviare il traffico. VPNIl reindirizzamento avviene impostando una serie di rotte per sottoreti con prefisso /1, che hanno una priorità maggiore rispetto alla rotta predefinita con prefisso /0 (0.0.0.0/0), quindi il traffico, invece di passare attraverso l'interfaccia di rete virtuale riservata al VPN, sarà diretto attraverso l'interfaccia di rete fisica verso l'host dell'attaccante nella rete locale.
L'attacco può essere effettuato su qualsiasi sistema operativo che supporti l'opzione 121 del DHCP, inclusi Linux, Windows, iOS e macOS, indipendentemente dal protocollo VPN utilizzato (Wireguard, OpenVPN, IPsec) e dal set di cifratura. La piattaforma Android non è vulnerabile all'attacco, poiché non gestisce l'opzione 121 nel DHCP. Questo attacco consente di accedere al traffico, ma non offre la possibilità di infiltrarsi nelle connessioni o di determinare il contenuto trasmesso tramite protocolli protetti a livello di applicazione, come TLS e SSH; ad esempio, l'attaccante non può determinare il contenuto delle richieste HTTPS, ma può comprendere a quali server vengono inviate.
Per proteggersi da un attacco, è possibile vietare a livello di filtro pacchetti l'invio di pacchetti indirizzati all'interfaccia VPN attraverso altre interfacce di rete; bloccare i pacchetti DHCP con l'opzione 121; utilizzare la VPN all'interno di una macchina virtuale separata (o di un container), isolata dalla rete esterna, o applicare modalità di configurazione speciali dei tunnel che utilizzano gli spazi dei nomi in Linux (network namespace). Per esperimenti con l'esecuzione di attacchi è stato pubblicato un insieme di script.
Si può notare che l'idea di modificare localmente il routing non è nuova e in passato era comunemente usata in attacchi mirati alla sostituzione del server DNS. In un attacco simile come TunnelCrack, in cui il reindirizzamento del traffico avveniva tramite la sostituzione del gateway predefinito, il problema riguardava 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 di VPN e DHCP, il metodo è stato menzionato anche in precedenza, ad esempio, è stato dedicato uno degli interventi alla conferenza USENIX 2023 dell'anno scorso (la ricerca ha mostrato che il 64,6% dei 195 client VPN testati era vulnerabile all'attacco).
Per l'inserimento dei percorsi era stato proposto in precedenza 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 dichiara come gateway. Inoltre, con il controllo del gateway (ad esempio, collegando la vittima a una rete wireless controllata dall'attaccante), è stata sviluppata una tecnica per l'inserimento di pacchetti nel tunnel, percepiti nel contesto dell'interfaccia di rete VPN.
Flussi di dati durante l'uso della VPN:
Flussi di dati dopo l'attacco:
Fonte: opennet.ru
