TunnelCrack contro TunnelVision: cosa rompe davvero ciascuno

Due nomi di ricerca vengono usati indifferentemente per qualsiasi traffico VPN che esce dal tunnel, ma i meccanismi che stanno dietro non sono gli stessi. TunnelCrack descrive due famiglie di eccezioni di instradamento; TunnelVision descrive una rotta fornita da DHCP sull’endpoint. Nessuno dei due rompe la crittografia, e nessuno dei due vi dice cosa fa oggi una specifica versione del client. Cinque verifiche separano i meccanismi dai titoli.

Primo passo: nominate il meccanismo che state esaminando

La divulgazione di TunnelCrack di agosto 2023 descrive due famiglie di attacchi. Nel caso della rete locale, il traffico che il client considera appartenente alla rete locale prende un’eccezione di accesso locale ed esce dal tunnel. Nel caso dell’indirizzo del server, la rotta che il client deve usare per raggiungere il server VPN stesso è fuori dal tunnel, e un avversario che controlla quell’indirizzo può sfruttare l’eccezione.

TunnelVision è un rapporto separato sulle rotte statiche senza classe fornite da DHCP. Un server DHCP ostile può consegnare all’endpoint rotte che cambiano il percorso del traffico, compreso il percorso verso il server VPN. Il rapporto riconosce lavori precedenti su effetti di instradamento correlati, il che ricorda che il meccanismo sottostante è più vecchio del nome.

Tenete i nomi legati ai loro meccanismi. Applicare una correzione per uno perché l’altro è nelle notizie è il modo in cui una revisione produce movimento senza copertura.

Secondo passo: guardate l’eccezione di accesso locale

La maggior parte dei client esenta il traffico della rete locale perché stampanti, trasmissione e condivisione di file continuino a funzionare mentre il tunnel è attivo. Quell’eccezione è una decisione di politica con un costo di sicurezza: un avversario sulla stessa rete può presentarsi come host locale, e il traffico che lo raggiunge non è mai entrato nel tunnel.

Chiedete se il profilo distribuito abbia davvero bisogno dell’eccezione. Una forza lavoro remota che non usa mai il rilevamento locale spesso può disattivarla, e i servizi locali rimanenti si raggiungono tramite un percorso documentato. Dove l’eccezione è necessaria, indicate quali destinazioni copre invece di descriverla come traffico locale.

La verifica è una questione di configurazione, non una cattura di pacchetti. Leggete l’impostazione del profilo e la documentazione del client per la versione che distribuite, perché il valore predefinito differisce tra prodotti e tra versioni dello stesso prodotto. Scrivete la risposta accanto al profilo, così il revisore successivo non debba dedurla dal comportamento. Un’eccezione che nessuno ha documentato è un’eccezione che nessuno esamina.

Terzo passo: guardate come viene appreso l’indirizzo del server

Il client deve raggiungere il server VPN prima che esista qualsiasi tunnel, quindi quella destinazione è instradata fuori dal tunnel per progetto. Se l’indirizzo viene appreso da un nome, il passo di risoluzione fa parte del percorso di fiducia, e un avversario che può rispondere a quella query può indirizzare il client verso un host che controlla.

Fissare l’indirizzo, usare un certificato verificato con il nome corretto e rifiutare di ricadere su un server non verificato riducono tutti l’esposizione. Nessuno di essi elimina la necessità di raggiungere il server fuori dal tunnel; cambiano chi può rispondere di quell’indirizzo.

resolvectl query vpn.lab.example
ip route get 198.51.100.24
ip rule show

La ricerca della rotta mostra l’interfaccia che il client userebbe per l’indirizzo del server, ed è l’eccezione in forma concreta. Se quella ricerca restituisce l’interfaccia del tunnel, il client non può nemmeno stabilire il tunnel, quindi una rotta esterna è attesa e la domanda è solo come viene scelta la sua destinazione.

Quarto passo: guardate le rotte fornite da DHCP

Le rotte statiche senza classe permettono a un server DHCP di distribuire voci della tabella di instradamento, e l’endpoint di solito le accetta senza chiedere. Su una rete in cui un avversario può rispondere al DHCP più rapidamente del server legittimo, quelle voci possono reindirizzare traffico che l’utente crede dentro il tunnel.

Confrontate le rotte sull’endpoint con quelle che vi aspettate. Una rotta predefinita o un prefisso ampio che punta al gateway locale mentre il tunnel è attivo è la firma che vale un’indagine, ed è visibile senza alcun traffico d’attacco.

ip route show table all
ip route get 203.0.113.55
nmcli -g ipv4.ignore-auto-routes con show "Wired connection 1"

L’ultima impostazione è il controllo lato endpoint che molti client e piattaforme espongono in qualche forma: ignorare le rotte fornite dalla rete. Disattivare l’accettazione automatica delle rotte è un compromesso, perché disattiva anche l’instradamento diviso legittimo da un server DHCP aziendale, quindi decidete per classe di rete e non globalmente.

Quinto passo: separate l’avviso dalla versione attuale

Un attacco pubblicato descrive un comportamento osservato su particolari versioni del client in un particolare momento. Non stabilisce che il portatile davanti a voi sia interessato, e non stabilisce che sia stato corretto. Entrambe le affermazioni richiedono il numero di build effettivo e l’avviso attuale del fornitore.

Annotate la versione del client, la piattaforma, le impostazioni del profilo che governano le eccezioni sopra e la data in cui avete verificato. Quel registro invecchia onestamente, mentre una nota che dice che la VPN è stata corretta per TunnelCrack no. Rileggetelo a ogni aggiornamento del client, perché un valore predefinito del profilo può cambiare sotto una versione che non avete toccato.

Quando validate davvero, usate un piano approvato contro il vostro endpoint e una destinazione innocua. Riprodurre l’attacco contro altri utenti su una rete condivisa non è un test, e disattivare la verifica dei pari o la cifratura dell’applicazione per facilitare un’osservazione rimuove la protezione che cercavate di misurare.

Infine, tenete la protezione a livello applicativo nel quadro. Un’eccezione di instradamento può esporre traffico che il tunnel avrebbe portato, e il TLS dell’applicazione protegge ancora quel traffico da estremo a estremo. I due livelli falliscono in modo indipendente, ed è per questo che un canale di controllo connesso non è prova che ogni flusso abbia preso il percorso previsto.