L’uso di una VPN (Virtul Private Network – rete virtuale privata) è una pratica comoda e diffusissima per creare canali sicuri tra dispositivi. Tanto da risultare una tecnologia fondamentale per l’accesso da remoto.

Proviamo a sintetizzare il concetto di base: dato che una connessione (TCP in particolare, ma anche UDP) è fatta per trasportare dati, questi possono essere pacchetti criptati di una rete. Solo il client e il server di questa connessione li potranno decriptare e ricostruire i dati, mentre chiunque provi a intercettare o duplicare questi pacchetti sapranno solo che c’è una comunicazione in corso tra due dispositivi.
Il risultato è quindi la costruzione di un tunnel: due dispositivi sono in contatto con un mezzo (rete) che vedono solo loro (privata), creato via software (virtuale) e che sfrutta un mezzo diverso (come Internet) per il trasporto.

Settimana scorsa, sulla newsletter dedicata alla sicurezza dell’open-source, è apparso un messaggio che descrive una vulnerabilità (e il modo per sfruttarla) presente in tutte le VPN di Linux. Già, perché si dice esplicitamente che il problema riguarda sia vari software per VPN (e in particolare OpenVPN, WireGuard e IPSec, uno degli standard de facto), sia vari sistemi operativi.

Here is a list of the operating systems we have tested which are vulnerable to this attack:

Ubuntu 19.10 (systemd)
Fedora (systemd)
Debian 10.2 (systemd)
Arch 2019.05 (systemd)
Manjaro 18.1.1 (systemd)

Devuan (sysV init)
MX Linux 19 (Mepis+antiX)
Void Linux (runit)

Slackware 14.2 (rc.d)
Deepin (rc.d)
FreeBSD (rc.d)
OpenBSD (rc.d)

This list isn’t exhaustive, and we are continuing to test other distributions, but made usere to cover a variety of init systems to show this is not limited to systemd.

Qui una lista dei sistemi operativi che abbiamo testato e che sono vulnerabili a questo attacco:

[…]

La lista non è esaustiva, e continuiamo a testare altre distribuzioni, ma ci siamo assicurati di coprire una varietà di sisitemi di init per mostrare che non è limitato a systemd.

Il riferimento a systemd nasce dal fatto che ad una prima analisi il problema sembrava introdotto dalla modifica di un parametro del Kernel (rp_filter) portata proprio da questo sistema di init, ma come si vede la cosa non è affatto limitata ad esso. Tanto che più sotto, nel messaggio, si citano anche MacOS ed Android . Non viene citato Windows, ma è possibile che ne sia colpito anch’esso.

Il messaggio descrive con dettaglio il problema: noi vi daremo una spiegazione sommaria.
Un gateway (il computer attraverso cui accediamo ad Internet) usato da un eventuale attaccante, non solo è in grado di veder il traffico passante relativo ad una VPN che il client (obbiettivo dell’attacco) ha instaurato con un server, ma è in grado di ricavare informazioni specifiche di questa connessione (sequential e acknowledge number) tali da poter introdurre pacchetti (hijacking) creati apposta per essere accettate dal client, con contenuto arbitrario.
Notate bene: le informazioni sono criptate, e non vengono mai decifrate, ma solo dedotte con delle tecniche apposite.
Questi pacchetti potrebbero avere come contenuto altri programmi malevoli, che possono eventualmente sfruttare altre vulnerabilità. Inoltre, questi pacchetti sarebbero già accettati dal computer client: le difese contro connessioni non volute (come un firewall) sarebbero già state superate.
Questo accade perché non viene fatto un controllo forte sull’origine di un pacchetto IP: basta che sembri valido (IP e porta di origine, IP e porta di destinazione, numero sequenziale) per essere accettabile. E anche se non è il comportamento di default dei Kernel Linux (gestito appunto dal parametro rp_filter, modifato da systemd), è quello trovato in molte distribuzioni come default.

Quindi la vulnerabilità non riguarda direttamente la compromissione della VPN, ma la possibilità di sfruttarla per ottenere un accesso non desiderato: un’intrusione. Dato che normalmente una VPN viene instaurata proprio per avere un collegamento sicuro tra il proprio computer ed un server attraverso un ambiente ostile, questa vulnerabilità risulta particolarmente critica. Se poi aggiungiamo che non dipende dal sistema operativo o dalla VPN usata, ma deriva dal comportamento di molte distribuzioni (e non solo Linux), la situazione risulta piuttosto comune.

Cosa fare, quindi? Cominciamo col dire che sebbene la vulnerabilità esista, richiede anche molto lavoro per essere sfruttata: la diffusione di attacchi del genere sarà (presumibilmente) limitata.

Un modo per limitare l’attacco è quello di non permettere l’accettazione dei pacchetti creati ad hoc: un eventuale attaccante potrà ancora ricavare le informazioni per crearli, ma non avrà modo di farli accettare.
Controlliamo che il parametro del kernel in questione sia settato a ‘1’, in modo da attivare il controllo:

$ sysctl -ar '\.rp_filter' 
net.ipv4.conf.all.rp_filter = 2 
net.ipv4.conf.default.rp_filter = 0 
net.ipv4.conf.enp1s0.rp_filter = 0 
net.ipv4.conf.lo.rp_filter = 0

Potete notare come l’impostazione sia presente anche per singola interfaccia di rete. Uno ‘0’ indica nessun controllo, mentre un ‘2’ (come nell’esempio) indica un controllo debole: verrà accettato qualsiasi IP sorgente collegato direttamente al sistema, anche se non su quell’interfaccia, cosa che – per quel che ci serve – è troppo debole. OpenBSD sembra aver già avviato la modifica del valore di default.
A macchina accesa è possibile modificare il valore al volo:

# sysctl -w net.ipv4.conf.all.rp_filter=1  
net.ipv4.conf.all.rp_filter = 1

Per rendere persistente la modifica, va modificato il file che controlla quest’impostazione, cosa che varia da sistema a sistema (e da init a init). Con systemd (che, nel bene o nel male, ha portato una standardizzazione) dovrebbe esistere il file ‘/usr/lib/sysctl.d/50-default.conf’:

$ grep -1 'net.ipv4.conf.all.rp_filter' /usr/lib/sysctl.d/50-default.conf
# Source route verification
net.ipv4.conf.all.rp_filter = 1 

In attesa di soluzioni definitive, a noi non resta che verificare le impostazioni dei nostri sistemi. Voi, già fatto?

Marco Bonfiglio

Ho coltivato la mia passione per l’informatica fin da bambino, coi primi programmi BASIC. In età adulta mi sono avvicinato a Linux ed alla programmazione C, per poi interessarmi di reti. Infine, il mio hobby è diventato anche il mio lavoro.
Per me il modo migliore di imparare è fare, e per questo devo utilizzare le tecnologie che ritengo interessanti; a questo scopo, il mondo opensource offre gli strumenti perfetti.