Numerose implementazioni del protocollo TLS permettono di estrarre le chiavi RSA

Un certo numero di implementazioni software di TLS contiene vulnerabilità che consentono agli hacker di ottenere le chiavi RSA con un impiego minimo di risorse di calcolo.

Florian Weimer, ricercatore presso Red Hat, ha pubblicato la settimana scorsa un report intitolato “Factoring RSA Keys With TLS Perfect Forward Secrecy“, il quale dimostra la presenza di vulnerabilità in una serie di dispositivi, incluso un popolare bilanciatore di carico di Citrix ed altre apparecchiature prodotte da Hillstone Networks, Nortel, Viprinet ed altri ancora.

L’implementazione del protocollo TLS in tali prodotti, secondo Weimer, evidenzia un livello di protezione insufficiente nei confronti dell’attacco Lenstra contro il “teorema cinese del resto”, ugualmente noto come RSA-CRT.

“Se si verifica un errore durante il calcolo di una firma (utilizzando l’ottimizzazione RSA-CRT), un attacker potrebbe essere in grado di recuperare la chiave privata dalla firma stessa (“fuga della chiave RSA-CRT”). All’epoca, l’utilizzo della crittografia in Internet era inconsueto; persino dieci anni dopo, la maggior parte delle connessioni TLS (o HTTPS) risultava immune nei confronti di tale problematica, visto che queste ultime non facevano ancora uso delle firme RSA, – scrive Weimer relativamente agli attacchi Lenstra. – La situazione è poi gradualmente cambiata, quando si è iniziato a raccomandare il forward secrecy riguardo al protocollo TLS, proprietà poi introdotta in molti siti web”.

Lenstra viene descritto come un attacco side-channel; Weimer afferma inoltre che, di per se stesso, l’algoritmo RSA risulta protetto nei confronti di questo genere di attacco, mentre la vulnerabilità si manifesta solo nel caso di alcune implementazioni non adeguatamente protette.

“Abbiamo osservato numerose fughe di chiavi RSA-CRT laddove questo non doveva avvenire – scrive l’autore del suddetto report, aggiungendo che, ad esempio, le implementazioni in OpenSSL e NSS risultano protette, e che Oracle, da parte sua, ha rilasciato una patch per OpenJDK relativamente alla CVE-2015-0478, dopo aver consultato lo stesso Weimer. – Tutti i certificati PKI dei browser riguardo ai quali sono state osservate delle fughe, sono stati sostituiti e revocati”.

Gli hacker possono avvalersi di questo tipo di attacco offline ad un costo relativamente inferiore rispetto ad altri attacchi crittografici. Il furto delle chiavi private di cifratura, tuttavia, si rivela estremamente pericoloso per i dati che il protocollo TLS deve proteggere. Un attaccante, sostiene Florian Weimer, deve in primo luogo penetrare all’interno della rete tramite un attacco di tipo “man-in-the-middle”, o mediante la compromissione del server, per poi condurre questo genere di attacco secondario e spacciarsi, in definitiva, per il server in questione.

“Tale fuga risulta visibile sia al client che effettua l’handshake TLS, sia all’osservatore passivo che intercetta il traffico di rete, – scrive Weimer. – La fuga delle chiavi consente inoltre la decodifica delle connessioni che non fanno uso di forward secrecy, senza che si riveli quindi necessario un attacco “man-in-the-middle”.

Gli attacchi, condotti offline, non possono essere facilmente identificati. Peraltro, un sistema di rilevamento delle intrusioni, afferma Weimer, è in grado di individuare una fuga di chiavi solo nel caso in cui esso sia stato appositamente configurato per eseguire il controllo di tutti gli handshake TLS.

“Per quel che riguarda le fughe di chiavi da noi osservate, riteniamo non possa esistere un modo – per gli attaccanti che operano da remoto – per realizzare tali fughe a proprio piacimento, visto che l’attacker non è in grado di manipolare il server, nell’ambito della rete, in maniera tale da far aumentare la probabilità di fughe di chiavi in relazione ad un determinato handshake TLS, – asserisce Weimer. – L’unica cosa che il malintenzionato può in realtà fare è catturare il maggior numero possibile di handshake, magari inizializzando una moltitudine di tali handshake”.

Il forward secrecy viene attualmente implementato in molti sistemi critici. Con l’utilizzo del forward secrecy, viene in pratica generata una nuova chiave crittografica per ogni sessione; ciò significa che, se un hacker è in grado di intercettare i dati relativi a varie sessioni, qualora sia in possesso di una sola chiave, egli non potrà ad ogni caso decodificare l’insieme dei dati carpiti, ma solo quelli relativi ad una singola sessione. Disattivare tale meccanismo di sicurezza, secondo il ricercatore, non è di sicuro una buona strategia.

“La disattivazione del forward secrecy consentirebbe ad un osservatore passivo, che ha in precedenza realizzato il furto delle chiavi, di decodificare le future sessioni TLS attraverso il traffico di rete passivamente intercettato, senza che risulti necessario reindirizzare le connessioni del client, – afferma Florian Weimer. – Questo significa che disattivare tale sistema, in genere, peggiora le cose. (La disattivazione del forward secrecy e la contemporanea sostituzione del certificato del server, invece, è una soluzione che funziona)”.

Fonte: Threatpost

Post correlati

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *