una tecnica di attacco (CVE-2019-14899) che consente di sostituire, modificare o inserire pacchetti nelle connessioni TCP, passando attraverso tunnel VPN. Il problema interessa Linux, FreeBSD, OpenBSD, Android, macOS, iOS e altri sistemi Unix-like. Linux supporta il meccanismo rp_filter (reverse path filtering) per IPv4; attivarlo in modalità «Strict» neutralizza questo problema.
Il metodo consente la sostituzione dei pacchetti a livello delle connessioni TCP che transitano all'interno di un tunnel crittografato, ma non permette di infiltrarsi in connessioni che utilizzano ulteriori strati di crittografia (ad esempio, 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'interferenza con le connessioni HTTP non crittografate, ma e l'uso dell'attacco per manipolare le risposte DNS.
Una sostituzione pacchetti riuscita è stata dimostrata per tunnel creati utilizzando OpenVPN, WireGuard e IKEv2/IPSec. Tor non è soggetto a questo problema, poiché utilizza SOCKS per l'inoltro del traffico e la connessione all'interfaccia loopback. Per IPv4, l'attacco è possibile nel caso in cui il rp_filter sia impostato in modalità "Loose" (sysctl net.ipv4.conf.all.rp_filter = 2). Inizialmente, nella maggior parte dei sistemi, era utilizzata la modalità "Strict", ma a partire da , rilasciato a dicembre dello scorso anno, la modalità operativa predefinita è stata cambiata in "Loose" e questa modifica si è riflessa nelle impostazioni predefinite di molte distribuzioni Linux.
Meccanismo rp_filter per un controllo aggiuntivo dei percorsi dei pacchetti per prevenire lo spoofing dell'indirizzo sorgente. Se impostato su 0, non viene effettuato alcun controllo dell'indirizzo sorgente e ogni pacchetto può essere inoltrato senza limitazioni tra le interfacce di rete. La modalità 1 «Strict» include il controllo di ogni pacchetto in arrivo dall'esterno per verificare la corrispondenza con la tabella di routing, e se l'interfaccia di rete attraverso la quale è stato ricevuto il pacchetto non è collegata al percorso ottimale per la consegna della risposta, il pacchetto viene scartato. La modalità 2 «Loose» allenta il controllo per consentire il funzionamento con bilanciatori di carico o instradamento asimmetrico, in cui
il percorso di risposta potrebbe non passare attraverso l'interfaccia di rete tramite la quale è stato ricevuto il pacchetto in ingresso.
In modalità 'Loose', il pacchetto in arrivo viene controllato per verificare la corrispondenza con la tabella di routing, ma è considerato valido se l'indirizzo di origine è raggiungibile tramite qualsiasi interfaccia di rete disponibile. L'attacco proposto si basa sull'idea che l'attaccante possa inviare un pacchetto con un indirizzo di origine mascherato, corrispondente all'interfaccia VPN, e sebbene questo pacchetto arrivi nel sistema tramite un'interfaccia di rete esterna anziché tramite la VPN, in modalità rp_filter 'Loose' tale pacchetto non verrà scartato.
Per eseguire l'attacco, l'aggressore deve controllare il gateway attraverso cui l'utente accede alla rete (ad esempio, tramite un attacco MITM, collegando la vittima a un punto di accesso Wi-Fi controllato dall'attaccante o attraverso ). Controllando il gateway attraverso il quale si connette alla rete l'utente, l'attaccante può inviare pacchetti fasulli che saranno interpretati nel contesto dell'interfaccia VPN, ma le risposte verranno instradate attraverso il tunnel.
Generando un flusso di pacchetti fittizi, in cui viene inserito l'indirizzo IP dell'interfaccia VPN, si tenta di influenzare la connessione stabilita dal cliente, ma si può osservare l'impatto di questi pacchetti solo attraverso un'analisi passiva del flusso di traffico crittografato correlato al funzionamento del tunnel. Per effettuare un attacco, è necessario conoscere l'indirizzo IP dell'interfaccia di rete del tunnel assegnato dal server VPN, nonché determinare che al momento attraverso il tunnel è attiva una connessione a un determinato host.
Per determinare l'IP dell'interfaccia di rete virtuale VPN si inviano pacchetti SYN-ACK al sistema della vittima, esaminando sequenzialmente l'intero intervallo degli indirizzi virtuali (in particolare, vengono esaminati prima gli indirizzi utilizzati di default nel VPN, ad esempio, in OpenVPN si utilizza la sottorete 10.8.0.0/24). L'esistenza di un indirizzo può essere dedotta in base alla ricezione di una risposta con il flag RST.
In modo analogo si determina la connessione a un determinato sito e il numero di porta lato client: inviando un pacchetto SYN, vengono esplorati i numeri di porta verso l'utente utilizzando come indirizzo sorgente l'IP del sito e come indirizzo di destinazione un IP virtuale VPN. La porta del server può essere prevista (80 per HTTP), mentre il numero di porta lato client può essere calcolato mediante un tentativo di esplorazione, analizzando per diversi numeri la variazione nell'intensità delle risposte ACK in combinazione con l'assenza di pacchetti con flag RST.
In questa fase, l'attaccante conosce tutti e quattro gli elementi della connessione (indirizzi/porte IP sorgente e indirizzi/porte IP di destinazione), ma per generare un pacchetto fittizio che il sistema della vittima percepirà, l'attaccante deve determinare i numeri di sequenza e di conferma (seq e ack) della connessione TCP. Per determinare questi parametri, l'attaccante invia continuamente pacchetti RST falsi, esplorando diversi numeri di sequenza, finché non riceve un pacchetto ACK di risposta, il cui arrivo indica che il numero rientra nella finestra TCP.
Successivamente, l'attaccante verifica la correttezza della definizione inviando pacchetti con lo stesso numero e osservando l'arrivo delle risposte ACK, dopodiché determina il numero esatto della sequenza attuale. La situazione è complicata dal fatto che le risposte vengono inviate all'interno di un tunnel crittografato e la loro presenza nel flusso di traffico intercettato può essere analizzata solo con metodi indiretti. Il fatto che il cliente invii un pacchetto ACK indirizzato al server VPN è determinato dalla dimensione e dalla latenza delle risposte crittografate, che correlano all'invio di pacchetti falsi. Ad esempio, per OpenVPN, un pacchetto crittografato di dimensione 79 permette di dedurre con certezza che al suo interno si trova una conferma ACK.
Prima che la protezione contro gli attacchi venga aggiunta al kernel del sistema operativo, come metodo temporaneo per bloccare il problema utilizzando un filtro di pacchetti nella catena 'preroute' per bloccare il passaggio di pacchetti 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 garantire la protezione quando si utilizzano tunnel con indirizzi IPv4, è sufficiente impostare rp_filter in modalità «Strict» («sysctl net.ipv4.conf.all.rp_filter = 1»). Da parte del VPN, il metodo per determinare il numero di sequenza può essere bloccato aggiungendo padding ai pacchetti crittografati, rendendo dimensioni di tutti i pacchetti uniformi.
Fonte: opennet.ru
