Traffico VPN può essere svelato: vediamo in quali casi con l'attacco TunnelVision

Una “Routing-Based VPN” è un tipo di VPN che instrada il traffico dati in base alle informazioni contenute nelle tabelle di routing dei dispositivi di rete coinvolti nelle comunicazioni. Con questo tipo di approccio, i pacchetti dati transitano attraverso una serie di nodi intermedi lungo un percorso predefinito per raggiungere la destinazione finale.

Le VPN basate su routing utilizzano le tabelle citate in precedenza per determinare il percorso migliore per instradare i dati degli utenti. Le tabelle di routing possono essere configurate manualmente o dinamicamente attraverso protocolli di routing come OSPF (Open Shortest Path First) o BGP (Border Gateway Protocol).

TunnelVision: l’attacco che svela il traffico VPN

Il “decloaking” delle VPN Routing-Based consiste in una tipologia di attacco che sfrutta vulnerabilità nelle configurazioni di rete per esporre il traffico VPN, rendendolo visibile agli aggressori. Questo significa che, sebbene l’utente utilizzi un servizio VPN per proteggere la connessione e i dati trasmessi su Internet, un aggressore postosi sulla stessa rete può comunque intercettare e visualizzare il traffico dati.

Nel caso delle VPN Routing-Based, gli attaccanti possono sfruttare varie tecniche, come il controllo del server DHCP o l’ARP spoofing, per manipolare le tabelle di routing e deviare il traffico VPN attraverso un percorso non protetto, bypassando così la crittografia e l’anonimato offerti da molti servizi.

Il meccanismo del decloaking può essere utilizzato per raccogliere informazioni riservate e dati personali o credenziali di accesso oppure per condurre altri tipi di attacchi, come il furto di identità o il monitoraggio delle attività online degli utenti.

I ricercatori di Leviathan Security Group hanno acceso un faro sulla problematica che, come facilmente intuibile, ha un impatto concreto sulla sicurezza e la privacy degli utenti e dei loro dati. Nel complesso, le problematiche evidenziate sono state battezzate TunnelVision ed è stato assegnato loro un identificativo univoco: CVE-2024-3661.

Saltano la crittografia e la protezione offerte dai servizi VPN

Il problema di sicurezza TunnelVision fa sì che il traffico VPN sia instradato attraverso un percorso non protetto anziché attraverso il tunnel crittografato offerto dalla VPN stessa.

I servizi VPN coinvolti sono quelli che si basano esclusivamente sull’uso di tabelle di routing per gestire il traffico degli utenti. Tra di esse ci sono VPN che si servono di protocolli come OpenVPN e IPsec, così come quelle che si basano su soluzioni personalizzate di routing VPN.

Poiché la problematica risiede nella configurazione di rete dei dispositivi degli utenti piuttosto che nel protocollo VPN specifico, TunnelVision può teoricamente influenzare qualsiasi VPN che non adotti misure di sicurezza adeguate per proteggere le tabelle di routing e le impostazioni DHCP da utenti malevoli al lavoro sulla medesima rete locale.

Per attenuare i rischi derivanti da TunnelVision, utenti e aziende sono chiamati a implementare misure di sicurezza aggiuntive, come l’uso di firewall per bloccare il traffico non autorizzato, l’adozione di autenticazione multi-fattore e l’implementazione di protocolli di sicurezza avanzati. A questo proposito, gli esperti di Leviathan caldeggiano l’adozione di VPN basate su tunneling crittografato end-to-end, come ad esempio WireGuard.

L’aggressione può partire solo all’interno della rete locale LAN

“The sky is not falling (yet)“, come direbbero dall’altro lato dell’oceano. In altre parole, TunnelVision non è una falla di sicurezza che interessa immediatamente e indistintamente tutti gli utilizzatori di servizi VPN. Spieghiamo meglio.

Nel contesto di TunnelVision, gli attaccanti devono infatti esercitare la loro azione malevola nella stessa rete locale degli utenti vulnerabili per sferrare l’attacco con successo. Ciò significa che gli aggressori devono avere accesso fisico o logico alla LAN utilizzata dagli utenti della VPN. Possono essere situati all’interno dello stesso edificio, ufficio, campus o servirsi del medesimo hotspot WiFi pubblico.

Una volta guadagnato l’accesso alla rete locale, gli attaccanti possono utilizzare le tecniche già citate per manipolare le impostazioni di rete, ad esempio aggiungendo un server DHCP malevolo o alterare il contenuto delle tabelle di routing. In questo modo si concretizza l’instradamento del traffico VPN su percorsi non protetti anziché attraverso il tunnel crittografato della VPN, esponendo così i dati personali degli utenti all’intercettazione e alla successiva analisi.

Le situazioni in cui gli utenti di VPN Routing-Based sono più esposti ai rischi di attacco

Leviathan cita alcuni scenari concreti in cui le vittime, utenti di servizi VPN, potrebbero essere esposti all’attacco TunnelVision. Le casistiche più emblematiche sono le seguenti:

• Un attaccante compromette un server DHCP/access point. In questo scenario, un aggressore ottiene il controllo di un server DHCP o di un hotspot WiFi all’interno della rete locale. Ciò consente all’attaccante di manipolare le risposte DHCP e le tabelle di routing per instradare il traffico VPN degli utenti attraverso percorsi non protetti.
• Un amministratore malintenzionato gestisce l’infrastruttura. Qui si ipotizza che un “amministratore di rete infedele” abbia accesso e controllo sui dispositivi di rete all’interno dell’infrastruttura.
• Un attaccante configura un access point wireless “evil twin“. In questa situazione, un aggressore crea un punto di accesso WiFi malevolo, noto come “evil twin“, che si presenta come access point legittimo. Gli utenti vulnerabili potrebbero connettersi inconsapevolmente a questo punto di accesso compromesso, consentendo all’attaccante di eseguire l’attacco TunnelVision sulla rete.
• Simulazione di un attacco basato su host adiacente. Si tratta di una situazione che gli esperti di Leviathan implementeranno ricorrendo a uno strumento chiamato ArcaneTrickster. I ricercatori intendono dimostrare che l’attacco TunnelVision può essere eseguito anche senza disporre di un accesso privilegiato e senza un router. L’host adiacente deve essere soltanto in grado di scambiare dati con il dispositivo oggetto di aggressione.

Credit immagine in apertura: iStock.com – da-kuk