tecnica di attacco (CVE-2019-14899) che permette di sostituire, modificare o inserire pacchetti nelle connessioni TCP inoltrate tramite tunnel VPN. Il problema interessa Linux, FreeBSD, OpenBSD, Android, macOS, iOS e altri sistemi simili a Unix. Linux supporta il meccanismo rp_filter (reverse path filtering) per IPv4, la cui attivazione in modalità 'Strict' neutralizza questo problema.
Il metodo consente di effettuare la sostituzione dei pacchetti a livello delle connessioni TCP che passano all'interno di un tunnel crittografato, ma non permette di infiltrarsi nelle connessioni che utilizzano strati di crittografia aggiuntivi (come TLS, HTTPS, SSH). Gli algoritmi di crittografia utilizzati nelle VPN non hanno importanza, poiché i pacchetti falsi provengono dall'interfaccia esterna e vengono elaborati dal kernel come pacchetti provenienti dall'interfaccia VPN. L'obiettivo più probabile dell'attacco è l'intercettazione delle connessioni HTTP non crittografate, ma anche l'utilizzo dell'attacco per manipolare le risposte DNS.
Sostituzioni di pacchetti con successo sono state dimostrate per i tunnel creati utilizzando OpenVPN, WireGuard e IKEv2/IPSec. Tor non è vulnerabile, poiché utilizza SOCKS per il passaggio del traffico e è legato all'interfaccia di loopback. Per IPv4, l'attacco è possibile se il rp_filter viene impostato in modalità 'Loose' (sysctl net.ipv4.conf.all.rp_filter = 2). Inizialmente, nella maggior parte dei sistemi era attivata la modalità 'Strict', ma a partire da , rilasciato a dicembre dello scorso anno, la modalità predefinita è stata cambiata in 'Loose' e questa modifica ha influenzato le impostazioni predefinite di molte distribuzioni Linux.
Il meccanismo rp_filter per un ulteriore controllo dei percorsi di passaggio dei pacchetti al fine di prevenire il spoofing dell'indirizzo sorgente. Se impostato a 0, il controllo dell'indirizzo sorgente non viene effettuato e ogni pacchetto può essere reindirizzato senza restrizioni tra le interfacce di rete. La modalità 1 'Strict' attiva il controllo di ciascun pacchetto in arrivo dall'esterno rispetto alla tabella di instradamento, e se l'interfaccia di rete tramite la quale è stato ricevuto il pacchetto non è associata al percorso ottimale per la consegna della risposta, il pacchetto viene scartato. La modalità 2 'Loose' attenua il controllo per consentire il funzionamento con bilanciatori di carico o instradamenti asimmetrici, in cui
Il percorso della risposta può non passare attraverso l'interfaccia di rete da cui è arrivato il pacchetto in ingresso.
In modalità "Loose", il pacchetto in ingresso viene controllato rispetto alla tabella di routing, ma è considerato valido se l'indirizzo sorgente è raggiungibile tramite qualsiasi interfaccia di rete disponibile. L'attacco proposto si basa sul fatto che l'attaccante può inviare un pacchetto con un indirizzo sorgente contraffatto, corrispondente all'interfaccia VPN, e nonostante il pacchetto arrivi al sistema attraverso un'interfaccia di rete esterna e non attraverso la VPN, in modalità rp_filter "Loose" tale pacchetto non verrà scartato.
Per eseguire l'attacco, l'aggressore deve controllare il gateway attraverso il quale l'utente accede alla rete (ad esempio, tramite un'organizzazione MITM, collegando la vittima a un punto di accesso wireless controllato dall'attaccante o tramite ). Controllando il gateway a cui è connesso l'utente nella rete, l'attaccante può inviare pacchetti falsi che saranno interpretati nel contesto dell'interfaccia di rete VPN, ma le risposte verranno inviate attraverso il tunnel.
Generando un flusso di pacchetti falsi, in cui viene inserito l'indirizzo IP dell'interfaccia VPN, si fanno tentativi di influenzare la connessione stabilita dal client, ma l'influenza di questi pacchetti può essere osservata solo attraverso un'analisi passiva del flusso di traffico crittografato associato al funzionamento del tunnel. Per condurre l'attacco è necessario conoscere l'indirizzo IP dell'interfaccia di rete del tunnel assegnato dal server VPN, oltre a verificare che al momento ci sia una connessione attiva tramite il tunnel verso un determinato host.
Per determinare l'IP dell'interfaccia di rete virtuale VPN si inviano al sistema della vittima pacchetti SYN-ACK, eseguendo una scansione sistematica dell'intero intervallo di indirizzi virtuali (si esaminano prima gli indirizzi utilizzati di default nella VPN, ad esempio in OpenVPN si utilizza la sottorete 10.8.0.0/24). L'esistenza dell'indirizzo può essere dedotta sulla base della ricezione di una risposta con il flag RST.
Allo stesso modo, viene determinata la presenza di una connessione a un sito specifico e il numero di porta dal lato del client: eseguendo una scansione dei numeri di porta verso l'utente viene inviato un pacchetto SYN, utilizzando come indirizzo di origine l'IP del sito e come indirizzo di destinazione l'IP virtuale VPN. Il numero di porta del server può essere previsto (80 per HTTP), mentre il numero di porta dal lato del client può essere calcolato per tentativi, analizzando per diversi numeri la variazione dell'intensità delle risposte ACK in combinazione con l'assenza di pacchetti con il flag RST.
A questo punto, l'attaccante conosce tutti e quattro gli elementi della connessione (indirizzi/porta IP di origine e indirizzo/porta IP di destinazione), ma per generare un pacchetto falsificato che verrà percepito dal sistema della vittima, l'attaccante deve determinare i numeri di sequenza e di riconoscimento (seq e ack) della connessione TCP. Per determinare questi parametri, l'attaccante invia continuamente pacchetti RST falsi, provando diversi numeri di sequenza, fino a quando non riceve un pacchetto ACK di risposta, la cui ricezione indica che il numero rientra nella finestra TCP.
Successivamente, l'attaccante verifica la correttezza della determinazione inviando pacchetti con lo stesso numero e osservando l'arrivo delle risposte ACK, dopo di che individua il numero esatto della sequenza corrente. Il compito è complicato dal fatto che le risposte vengono inviate all'interno di un tunnel crittografato e la loro analisi nella corrente di traffico interceptata può essere effettuata solo con metodi indiretti. Il fatto che un pacchetto ACK indirizzato al server VPN venga inviato dal client viene determinato sulla base della dimensione e del ritardo delle risposte crittografate, che correlano con l'invio di pacchetti falsi. Ad esempio, per OpenVPN, un pacchetto crittografato di dimensione 79 permette di concludere con certezza che al suo interno si trova una conferma ACK.
Prima che la protezione contro l'attacco venga aggiunta al kernel del sistema operativo, come metodo temporaneo per bloccare il problema di bloccare il passaggio dei pacchetti utilizzando un filtro dei pacchetti nella catena "preroute", in cui l'indirizzo di destinazione è l'indirizzo IP virtuale del tunnel.
iptables -t raw -I PREROUTING ! -i wg0 -d 10.182.12.8 -m addrtype ! —src-type LOCAL -j DROP
oppure per nftables
nft add table ip raw
nft add chain ip raw prerouting '{ type filter hook prerouting priority 0; }'
nft add rule ip raw prerouting 'iifname != "wg0" ip daddr 10.182.12.8 fib saddr type != local drop'
Per proteggere l'uso di tunnel con indirizzi IPv4, è sufficiente impostare rp_filter in modalità "Strict" ("sysctl net.ipv4.conf.all.rp_filter = 1"). Dalla parte VPN, il metodo di determinazione del numero di sequenza può essere bloccato aggiungendo riempimenti ai pacchetti crittografati, rendendo la dimensione di tutti i pacchetti identica.
Fonte: opennet.ru
