Terrapin: 11 milioni di sistemi vulnerabili all'attacco che compromette SSH

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 pubblicata il , alle 10:11 nel canale Sicurezza
 

Ci 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.

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 - info
WarDuck04 Gennaio 2024, 10:20 #1
Da quello che ho letto, è un attacco che dovrebbe consentire il downgrade dell'autenticazione dall'uso di chiavi all'uso di password, se il server SSH supporta *entrambi* i tipi di autenticazione.

Se 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.
virtualdj04 Gennaio 2024, 11:23 #2
Originariamente inviato da: WarDuck
Se il server supporta solo autenticazione mediante chiavi, non dovrebbero esserci problemi

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...
destroyer8504 Gennaio 2024, 13:51 #3
Ma tendenzialmente con qualcuno nel mezzo, il client non dovrebbe dirmi che la firma chiave del server è cambiata?
WarDuck04 Gennaio 2024, 16:53 #4
Originariamente inviato da: destroyer85
Ma tendenzialmente con qualcuno nel mezzo, il client non dovrebbe dirmi che la firma chiave del server è cambiata?


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).

Originariamente inviato da: virtualdj
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 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

Originariamente inviato da: virtualdj
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...


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.
destroyer8505 Gennaio 2024, 09:54 #5
Intendevo ancora prima. Come quando c'è un man in the middle https, se il certificato non è valido (e a meno che sia corrotto il vault dei certificati non lo può essere mai) il browser mi avvisa, guarda che il certificato ha qualcosa che non va.
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".

La discussione è consultabile anche qui, sul forum.
 
^