Terrapin: 11 milioni di sistemi vulnerabili all'attacco che compromette SSH
Si tratta di un proof-of-concept sviluppato dai ricercatori dell'Università tedesca della Ruhr di Bochum e colpisce sia server, sia client
di Andrea Bai pubblicata il 04 Gennaio 2024, alle 10:11 nel canale SicurezzaCi sono quasi 11 milioni di sistemi esposti su Internet vulnerabili ad un attacco chiamato Terrapin, che minaccia l'integrità delle connessioni SSH manipolando i numeri di sequenza durante la fase iniziale di handshake.
L'attacco, sviluppato come proof-of-concpet da un gruppo di ricercatori dell'Università tedesca della Ruhr di Bochum, colpisce sia client che server SSH, compromettendo il canale crittografato quando vengono utilizzate specifiche modalità di crittografica come ChaCha20-Poly1305 o CBC con Encrypt-then-MAC. In questo modo, un malintenzionato potrebbe declassare gli algoritmi a chiave pubblica per l'autenticazione dell'utente e disabilitare le difese contro attacchi keystroke timing in OpenSSH 9.5.
L'attacco Terrapin richiede che l'aggressore si trovi in posizione Man-in-the-middle, intercettando e modificando lo scambio iniziale di informazioni. Si tratta di una situazione che gli hacker sanno molto bene come ricreare, sfruttando i meccanismi dell'ingegneria sociale. Si tratta di un attacco che sfrutta le vulnerabilità CVE-2023-48795, CVE-2023-46445 e CVE-2023-46446.
We are sharing SSH CVE-2023-48795 (Terrapin attack) vulnerable instances found in our IPv4/IPv6 scans in our Accessible SSH report: https://t.co/pLCz27PyMB
— Shadowserver (@Shadowserver) January 3, 2024
Nearly 11M instances (by unique IP) found vulnerable (~52%).
Background on the vulnerability: https://t.co/k5c3zLbEIe pic.twitter.com/7luSdHt0YF
Secondo il rapporto della piattaforma Shadowserver, i server SSH vulnerabili individuati sono circa 11 milioni, pari al 52% di quelli monitorati globalmente. La maggior parte dei sistemi vulnerabili sono stati identificati negli Stati Uniti (3,3 milioni), seguiti da Cina (1,3 milioni), Germania (1 milione), Russia (700.000), Singapore (390.000) e Giappone (380.000).
Si tratta di numeri che sottolineano come gli attacchi Terrapin potrebbero avere un impatto diffuso. Anche ipotizzando che non tutti gli 11 milioni di sistemi vulnerabili possano correre un rischio immediato, si tratta comunque di un bacino molto ampio da cui gli aggressori possono scegliere i loro bersagli.
Se si desidera verificare la suscettibilità a Terrapin di un client o server SSH, il team dell'Università della Ruhr a Bochum ha messo a disposizione uno scanner di vulnerabilità. E' inoltre disponibile anche un elenco, non esaustivo, di patch correttive che mitigano le vulnerabilità, ma come i ricercatori stessi osservano la diffusione e la varietà di implementazioni SSH rende il processo piuttosto difficoltoso.
5 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - infoSe il server supporta solo autenticazione mediante chiavi, non dovrebbero esserci problemi, o meglio il risultato dell'attacco dovrebbe ridursi ad un Denial of Service.
Ma ho letto rapidamente, potrei sbagliarmi.
Dici? Leggendo le FAQ sul sito ufficiale della vulnerabilità non sono riuscito a trovare una frase che "scagioni" i server con sola autenticazione mediante chiavi.
Semmai sono immuni quelli che non supportano l'algoritmo ChaCha20-Poly1305 e quelli in combinazione con Encrypt-then-MAC.
La cosa più spiacevole è che oltre alla patch del server tocca patchare anche il client, sennò non si risolve. Quindi come si farà? Si scollegheranno brutalmente i client per evitare che uno non patchato si connetta? Questo non l'ho capito...
Purtroppo no perché l'attacco consiste nello scartare una parte delle informazioni scambiate in chiaro prima dell'effettivo scambio di chiavi per la cifratura.
In particolare nell'handshake iniziale vengono scambiati gli algoritmi supportati da entrambi gli attori, client e server, per poter negoziare come procedere nell'autenticazione SSH.
Come potrai intuire, client e server devono supportare entrambi almeno 1 algoritmo, lo stesso, altrimenti non è possibile procedere.
Se io modifico i messaggi del client in maniera da far credere che non ne supporta nessuno, il server SSH può proporre al client di usare l'autenticazione via password.
In pratica fa un downgrade di sicurezza, passando da autenticazione via chiave ad autenticazione via password, con tutti i problemi che questa può comportare (attacchi a dizionario ad esempio).
Semmai sono immuni quelli che non supportano l'algoritmo ChaCha20-Poly1305 e quelli in combinazione con Encrypt-then-MAC.
La mia è una deduzione sulla base di quello che ho letto, prendila con le pinze, dovrei verificare con il tool fornito dai ricercatori, ma al momento ho già tutto aggiornato
Se non si ha controllo dei client, o si fa così oppure se si vuole evitare un Denial Of Service, configuri SSH per usare AES-GCM nel frattempo che tutti aggiornano.
Comunque già molte distribuzioni hanno rilasciato i pacchetti di aggiornamento.
Stessa cosa PuTTY, se reinstallo un server e mi ricollego allo stesso IP, il client se ne accorge che il server non è più lo stesso di prima anche se lo chiamo con lo stesso IP e mi avvisa (known host). Spererei che questo avvenga, altrimenti ci siamo basati per anni su un protocollo mica tanto sicuro se è così facile far credere al client di essere un certo server.
Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".