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