Il succo di quanto accaduto
Nel maggio 2020 è stato scoperto un gruppo di nodi di uscita che interferivano con le connessioni in uscita. In particolare, lasciavano intatte quasi tutte le connessioni, ma intercettavano quelle relative a un piccolo numero di exchange di criptovaluta. Se gli utenti visitavano la versione HTTP del sito (cioè non crittografata e non autenticata), i nodi malevoli impedivano il reindirizzamento alla versione HTTPS (cioè crittografata e autenticata). Se l'utente non notava la sostituzione (ad esempio, l'assenza dell'icona a lucchetto nel browser) e iniziava a inviare informazioni sensibili, tali informazioni potevano essere intercettate dall'attaccante.
Il progetto Tor ha escluso questi nodi dalla rete nel maggio 2020. Nel luglio 2020 è stato scoperto un ulteriore gruppo di relay che conduceva un attacco simile, dopo di che anche loro sono stati esclusi. Finora non è chiaro se alcuni utenti siano stati attaccati con successo, ma considerando l'entità dell'attacco e il fatto che l'attaccante ha tentato di nuovo (il primo caso ha coinvolto il 23% della capacità totale dei nodi di uscita, il secondo circa il 19%), è ragionevole supporre che l'aggressore abbia ritenuto i costi dell'attacco giustificati.
Questo incidente è un buon promemoria che le richieste HTTP sono non crittografate e non autenticate e, pertanto, continuano a essere vulnerabili. Tor Browser include l'estensione HTTPS Everywhere, appositamente progettata per prevenire attacchi di questo tipo, ma la sua efficacia è limitata dall'elenco che non copre tutti i siti web del mondo. Gli utenti, quando visitano le versioni HTTP dei siti, saranno sempre a rischio.
Prevenire attacchi simili in futuro
I metodi per prevenire attacchi si dividono in due parti: la prima comprende misure che possono adottare utenti e amministratori dei siti per rafforzare la propria sicurezza, mentre la seconda riguarda l'identificazione e la rilevazione tempestiva di nodi malevoli nella rete.
Azioni raccomandate da parte dei siti:
1. Abilitazione di HTTPS (certificati gratuiti forniti da Let’s Encrypt)
2. Aggiunta di regole di reindirizzamento nella lista HTTPS-Everywhere, affinché gli utenti possano stabilire proattivamente una connessione sicura, piuttosto che fare affidamento su un reindirizzamento dopo aver stabilito una connessione non sicura. Inoltre, se l'amministrazione dei servizi web desidera evitare completamente l'interazione con i nodi di uscita, può fornire una versione onion del sito.
Al momento, il progetto Tor sta considerando la possibilità di disabilitare completamente HTTP non sicuro nel Tor Browser. Qualche anno fa, una misura simile era impensabile (troppi risorse utilizzavano solo HTTP non sicuro), ma sia HTTPS-Everywhere che la prossima versione di Firefox hanno la possibilità sperimentale di utilizzare HTTPS come impostazione predefinita per la prima connessione, con la possibilità di tornare a HTTP se necessario. È ancora poco chiaro come un approccio del genere influenzerà gli utenti del Tor Browser, quindi verrà provato prima ai livelli più alti di sicurezza del browser (icona del scudo).
Dalla parte della rete Tor ci sono volontari che monitorano il comportamento dei relay e segnalano incidenti, il che consente di escludere i nodi dannosi dai server di catalogo radice. Anche se tali rapporti vengono solitamente esaminati rapidamente e i nodi dannosi disconnessi subito dopo la scoperta, non ci sono risorse sufficienti per il monitoraggio continuo della rete. Se riesci a scoprire un relay dannoso, puoi segnalarlo al progetto, le istruzioni sono disponibili a questo link.
L'approccio attuale presenta due problemi fondamentali:
1. Nel valutare un relay sconosciuto, è difficile dimostrarne la malevolenza. Se non ci sono stati attacchi da parte sua, dovremmo lasciarlo lì? Gli attacchi di massa che colpiscono molti utenti sono più facili da riconoscere, ma se gli attacchi colpiscono solo un numero limitato di siti e utenti, l'attaccante può agire d'anticipo. La rete Tor stessa è composta da migliaia di relay distribuiti in tutto il mondo, e questa varietà (e la decentralizzazione che ne deriva) è uno dei suoi punti di forza.
2. Nel valutare un gruppo di relay sconosciuti, è difficile dimostrarne l'interconnessione (ovvero, se stanno condurre un attacco Sybil). Molti operatori volontari di retransmissione scelgono le stesse reti economiche per l'hosting, come Hetzner, OVH, Online, Frantech, Leaseweb, ecc., e se verranno scoperti diversi nuovi retransmittenti, sarà difficile supporre inequivocabilmente se siano comparsi diversi nuovi operatori o solo uno che gestisce tutti i nuovi retransmittenti.
Fonte: linux.org.ru
