WireGuard / CVE-2019-14899: quanto è veramente sicuro il protocollo?
Ho utilizzato i tunnel OpenVPN e SSH per una moltitudine di scenari nel corso degli anni e recentemente ho guadagnato molto clamore sulla semplicità e la sicurezza di WireGuard. Ora ho trovato alcune informazioni preoccupanti su CVE-2019-14899 :
Un utente malintenzionato che controlla il tuo collegamento L2 (ad esempio, il tuo WiFi o LAN) può inviare pacchetti appositamente predisposti al tuo dispositivo. L'autore dell'attacco può quindi utilizzare quei pacchetti per sondare attivamente determinate proprietà delle connessioni TCP originate dal dispositivo. In altre parole, controllando il punto di accesso di un dispositivo a Internet, un utente malintenzionato può dedurre se l'utente è connesso a un host e una porta specifici.
Inoltre, se una connessione TCP non è crittografata all'interno del tunnel VPN (se visiti una pagina che utilizza HTTP invece di HTTPS, ad esempio), l'aggressore può iniettare pacchetti in quello specifico flusso non crittografato. Ciò consentirebbe a un utente malintenzionato di fornire al tuo dispositivo contenuti HTML falsi per quel particolare flusso. Sarebbe pericoloso, ma come affermato in precedenza, l'attaccante deve prendere di mira una specifica connessione TCP, quindi non è una semplice vulnerabilità da sfruttare.
Fonte: https://protonvpn.com/blog/statement-on-cve-2019-14899/
- Queste informazioni sono tecnicamente corrette?
- Alcune fonti sul web affermano inoltre che chiunque controlli la WAN del server potrà anche trarre vantaggio da questa falla. È vero? L'ISP del server può sfruttarlo?
Supponendo che le informazioni siano corrette:
- Perché è importante se la "connessione TCP non è crittografata all'interno del tunnel VPN"? In teoria si usa una VPN esattamente per aggirare questo problema - per assicurarsi che nessuno possa vedere i contenuti della comunicazione tra due macchine;
- Se qualcuno che controlla la LAN del client può iniettare pacchetti, come viene considerato un protocollo sicuro? Dalla mia minimizzazione della convalida dell'autenticità è un must in scenari come questo. Il server dovrebbe essere in grado di controllare l'autenticità dei nuovi dati invece di accettarli ciecamente ... Non c'è una sorta di scambio di chiavi per questo?
- Secondo il sito web di Wireguard "imita il modello di SSH e Mosh; entrambe le parti hanno le chiavi pubbliche l'una dell'altra , e quindi sono semplicemente in grado di iniziare a scambiare pacchetti attraverso l'interfaccia". In che modo una terza parte (che non ha le chiavi giuste) è in grado di impersonare il client , inviare dati e quindi come il server li decrittografa utilizzando la chiave reale del client senza errori?
Grazie in anticipo.
Risposte
Queste informazioni sono tecnicamente corrette?
Sì, ma tieni presente che è stata apportata una modifica all'attacco precedente che non può essere interrotta dalle mitigazioni raccomandate in precedenza - consulta le domande frequenti sulla divulgazione degli attacchi ciechi / sul percorso .
Alcune fonti sul web affermano inoltre che chiunque controlli la WAN del server potrà anche trarre vantaggio da questa falla. È vero? L'ISP del server può sfruttarlo?
Questo è uno scenario completamente diverso. La connessione dall'endpoint VPN al server non è comunque protetta dalla VPN. Se l'attaccante controlla questa parte molto più facilmente e sono possibili attacchi più pericolosi.
Perché è importante se la "connessione TCP non è crittografata all'interno del tunnel VPN"? In teoria si utilizza una VPN esattamente per aggirare questo problema, per assicurarsi che nessuno possa vedere i contenuti della comunicazione tra due macchine
L'attacco è in grado di iniettare pacchetti in una connessione TCP esistente. Una normale connessione TCP ha solo una protezione limitata contro questo (cioè porta sorgente casuale e numeri di sequenza) che vengono aggirati dall'attacco. Se la connessione è ulteriormente protetta dalla crittografia, questa iniezione non funzionerà più. Si noti che la "crittografia" in realtà non è né richiesta né sufficiente, ma il punto è la protezione dell'integrità. Ma i protocolli di crittografia appropriati come TLS includono anche la protezione dell'integrità.
Se qualcuno che controlla la LAN del client può iniettare pacchetti, come viene considerato un protocollo sicuro? Dalla mia minimizzazione della convalida dell'autenticità è un must in scenari come questo. Il server dovrebbe essere in grado di controllare l'autenticità dei nuovi dati invece di accettarli ciecamente ... Non c'è una sorta di scambio di chiavi per questo?
Dal punto di vista del server i dati non sembrano sbagliati, ovvero qui non è possibile rilevare nulla.
Secondo il sito web di Wireguard "imita il modello di SSH e Mosh; entrambe le parti hanno le chiavi pubbliche l'una dell'altra, e quindi sono semplicemente in grado di iniziare a scambiare pacchetti attraverso l'interfaccia". In che modo una terza parte (che non ha le chiavi giuste) è in grado di impersonare il client, inviare dati e quindi come il server li decrittografa utilizzando la chiave reale del client senza errori?
Questo non è affatto un attacco contro la crittografia. L'attacco originale CVE-2019-14899 ha funzionato dal client accettando dati semplici su un'interfaccia diversa e trattandoli allo stesso modo dei dati decrittografati dall'interfaccia del tunnel VPN, rendendo così possibile l'iniezione. Ecco perché l'attacco è anche indipendente dall'effettiva tecnologia VPN di livello 3 utilizzata.
In altre parole: il sistema operativo (non la VPN) unisce i dati attendibili che escono dall'interfaccia VPN (dopo la decrittazione) con i dati non attendibili (controllati da un utente malintenzionato) provenienti da un'interfaccia di rete diversa. Non è un attacco contro il livello VPN in sé, ma come la VPN è integrata nel sistema operativo.