Link alla notizia: https://www.hwupgrade.it/news/sicurezza-software/terrapin-11-milioni-di-sistemi-vulnerabili-all-attacco-che-compromette-ssh_123039.html

Si tratta di un proof-of-concept sviluppato dai ricercatori dell'Università tedesca della Ruhr di Bochum e colpisce sia server, sia client

Click sul link per visualizzare la notizia.

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.

Se il server supporta solo autenticazione mediante chiavi, non dovrebbero esserci problemi
Dici? Leggendo le FAQ sul sito ufficiale della vulnerabilità (https://terrapin-attack.com/) 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...

Ma tendenzialmente con qualcuno nel mezzo, il client non dovrebbe dirmi che la firma chiave del server è cambiata?

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

Dici? Leggendo le FAQ sul sito ufficiale della vulnerabilità (https://terrapin-attack.com/) 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 :read:


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.

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.