Una vulnerabilità intrinseca nel protocollo Secure Shell (SSH) presenta la possibilità di essere sfruttata da un avversario strategicamente posizionato, potenzialmente minando l’integrità delle connessioni SSH se determinate condizioni sono soddisfatte. Questo tipo di vulnerabilità può permettere a un attaccante, attraverso un’azione di man-in-the-middle (MITM) ben eseguita, di costringere i client SSH ad adottare metodi di autenticazione più vulnerabili e disattivare specifiche misure di sicurezza. La portata esatta di questa vulnerabilità è complessa da determinare a causa della varietà delle configurazioni client-server, delle diverse implementazioni del protocollo e di altre variabili contestuali. È importante notare che SSH è comunemente utilizzato per stabilire connessioni remote sicure e amministrare sistemi tramite un’interfaccia a riga di comando.
Un attacco, soprannominato “Terrapin Attack,” è stato dettagliatamente descritto in un documento tecnico di recente pubblicazione da Fabian Bäumer, Marcus Brinkmann e Jörg Schwenk, rispettati scienziati informatici affiliati all’Università della Ruhr a Bochum, in Germania. Questo attacco è stato portato alla luce in ottobre quando i ricercatori hanno discretamente informato gli sviluppatori di client e server SSH della vulnerabilità, promuovendo un processo di mitigazione che ora è diventato di dominio pubblico con la distribuzione di patch e informazioni correlate.
Il gruppo di ricerca ha anche reso disponibili script di accompagnamento e materiali aggiuntivi su GitHub per coloro che sono interessati ai dettagli tecnici più granulari. Un ulteriore strumento open source è stato sviluppato per verificare la suscettibilità di client e server SSH all’attacco Terrapin. In seguito a questa scoperta, si prevede che aggiornamenti software per SSH saranno distribuiti agli utenti, e nel frattempo, sono state proposte diverse strategie di mitigazione. Nonostante ciò, non c’è motivo di allarmarsi eccessivamente poiché l’attacco richiede una posizione MITM attiva sulla connessione vulnerabile piuttosto che un attacco diretto al server. Si tratta più di un attacco di declassamento piuttosto che di un problema legato a decrittazione o iniezione di comandi. Esistono, infatti, metodologie per proteggersi immediatamente dagli attacchi Terrapin.
È fondamentale essere consapevoli di tre CVE specifici: CVE-2023-48795, che riguarda la vulnerabilità generica a livello di protocollo SSH; e CVE-2023-46445 e CVE-2023-46446, che sono specifici per il client SSH Python AsyncSSH. AsyncSSH è particolarmente significativo, considerando i suoi circa 60.000 download giornalieri. Si è scoperto che questo client open source presentava errori nell’implementazione che potevano essere sfruttati in un attacco Terrapin per ingannare, ad esempio, una vittima a collegarsi a un account shell sotto il controllo dell’attaccante anziché al proprio. AsyncSSH ha affrontato queste vulnerabilità nelle versioni 2.14.1 e 2.14.2, rispettivamente.
Come funziona il Terrapin Attack su SSH ?
L’attacco Terrapin, in particolare il CVE-2023-48795, è un attacco di troncamento del prefisso che consente a un attaccante MITM di degradare la sicurezza di una connessione SSHv2 durante la fase di negoziazione dell’estensione. Questo attacco è analogo a un problema identificato nel 2015 in TLS 1.3 e successivamente risolto. Un attacco Terrapin riuscito può risultare nell’uso di algoritmi di autenticazione client meno robusti e nella disattivazione di specifiche contromisure contro gli attacchi basati sulla sequenza di tasti in OpenSSH 9.5. In circostanze particolarmente specifiche, potrebbe essere utilizzato per decifrare alcuni segreti, come la password di un utente o parti di essa durante l’accesso, anche se questo è un evento non banale e improbabile da realizzare in pratica.
Il meccanismo di attacco MITM di Terrapin implica l’inserimento di un messaggio di “ignora” in testo chiaro nella connessione pre-sicura durante l’handshake, causando l’incremento del contatore di sequenza per i messaggi ricevuti dal client, mentre il messaggio in sé viene ignorato. Una volta stabilito il canale sicuro, l’attaccante MITM impedisce al server di inviare messaggi al client relativi a difese aggiuntive. Nonostante il messaggio sia crittografato, l’aggressore si limita a impedirne l’arrivo, e il client non lo rileva né agisce di conseguenza. Questa manovra è fondamentale perché i conteggi corretti dei messaggi inviati e ricevuti sono successivamente utilizzati per verificare l’integrità dell’intero processo di handshake. Se i conteggi appaiono corretti, la connessione prosegue come se nulla fosse.
È importante notare che l’algoritmo di crittografia adottato per il canale sicuro è determinante per stabilire se una connessione SSH è suscettibile a un attacco riuscito. Alcuni algoritmi, come ChaCha20-Poly1305, sono stati identificati come “vulnerabili e perfettamente sfruttabili” a causa della modalità in cui i numeri di sequenza sono impiegati nella derivazione delle chiavi. Mentre non esiste un punto debole crittografico intrinseco in questi algoritmi, il modo in cui sono implementati per SSH può presentare vulnerabilità. Si è anche scoperto che il CBC-Encrypt-then-MAC (CBC-EtM) è probabilisticamente vulnerabile e sfruttabile, anche se, a seconda dell’implementazione specifica, l’attacco potrebbe non avere successo. L’algoritmo CTR-Encrypt-then-MAC è vulnerabile ma non praticamente sfruttabile.
Gli esperti hanno rilevato che oltre tre quarti dei server SSH esposti al pubblico supportano “almeno una modalità che può essere sfruttata nella pratica”, e il 57% di questi imposta un algoritmo sfruttabile come scelta preferita. Nonostante la gravità di questa scoperta, gli esperti hanno sottolineato che non è necessario disattivare gli strumenti SSH o considerarli una priorità immediata. L’attacco richiede un aggressore MITM attivo che possa intercettare e modificare il traffico della connessione a livello TCP/IP. Inoltre, per essere efficace, l’attacco richiede la negoziazione di ChaCha20-Poly1305 o di un qualsiasi cifrario CBC in combinazione con la modalità Encrypt-then-MAC come modalità di crittografia della connessione.
In termini di mitigazione, è consigliato tenere d’occhio le patch o gli aggiornamenti e installarli non appena possibile. Ad esempio, per gli utenti Linux, questi aggiornamenti dovrebbero essere disponibili tramite il solito metodo di aggiornamento della distribuzione. Recentemente, è stata rilasciata la versione 9.6 di OpenSSH, che tra le altre cose ha affrontato Terrapin con un protocollo di scambio di chiavi più rigoroso che, se supportato sia dal server che dal client, dovrebbe contrastare efficacemente questi attacchi. È importante notare che collegare un client vulnerabile a un server con patch, e viceversa, risulta comunque in una connessione vulnerabile. Questa settimana è stato anche rilasciato Putty 0.8 per affrontare Terrapin, insieme a libssh 0.10.6 e libssh 0.9.8.
Oltre agli aggiornamenti, gli amministratori possono mitigare gli attacchi disabilitando le modalità di crittografia vulnerabili nella configurazione dei propri server SSH e optando invece per algoritmi non vulnerabili come AES-GCM. Tuttavia, esiste il rischio che se il server è configurato in modo errato o il proprio client non supporta la configurazione, l’accesso al server potrebbe andare perso. È anche da notare che versioni precedenti di OpenSSH (6.2 e 6.3) sono vulnerabili a un buffer overflow quando si utilizza AES-GCM.
In conclusione, Terrapin non rappresenta un semplice bug del software che può essere risolto con un aggiornamento di un singolo componente. Piuttosto, richiede aggiornamenti sia dei client che dei server per proteggere le connessioni dagli attacchi di troncamento del prefisso. Questo sottolinea la necessità di aumentare la consapevolezza del problema in tutte le implementazioni client e server SSH, rappresentando così uno sforzo considerevole per la comunità informatica.
