In che modo viene influenzata la sicurezza di SSH in presenza di un MITM che monitora passivamente?

Question

In che modo viene influenzata la sicurezza di SSH in presenza di un MITM che monitora passivamente?

#1 da (1 voti)
#2 da (-1 voti)

10

In un mondo ideale, in cui tutti i collegamenti sono pienamente affidabili dal punto di vista dell'integrità dei dati, con impostazioni corrette, il SSH moderno può essere più o meno considerato completamente sicuro contro l'intercettazione sul contenuto delle comunicazioni, ma potrebbe perdere metadati (ad esempio il fatto che ci si sta connettendo a un host specifico e alcuni relativi al modello di utilizzo e alle quantità di dati trasferiti).

In un mondo un po 'più realistico, per quanto potremmo non volerlo, i link dovrebbero essere monitorati . Sappiamo che il traffico crittografato può essere mantenuto in modo specifico da potenti avversari. Tuttavia, c'è ancora una grande differenza tra il monitoraggio passivo del traffico da una parte e la manomissione attiva in volo dall'altra.

Supponendo che:

la chiave dell'host SSH iniziale è generata da mezzi sconosciuti, eventualmente imperfetti;
l'amministratore non può verificare direttamente la correttezza della chiave host SSH presentata dal server alla prima connessione, oltre a essere in grado di dire se il tentativo di accesso ha esito positivo o negativo, ma può verificare l'impronta digitale della chiave host tramite i comandi all'interno quella sessione una volta stabilita;
l'amministratore sostituisce rapidamente la chiave host SSH con una generata in maniera fidata e ristabilisce una connessione una volta caricata la nuova chiave host;
l'amministratore conferma diligentemente le impronte digitali delle chiavi dell'host SSH tra il client e il server;
l'amministratore non ha accesso a un canale distinto sul server per la manutenzione delle chiavi, pertanto le sostituzioni delle chiavi devono essere eseguite tramite la sessione SSH stabilita con la chiave host che si trova sul server in quel momento;
l'utente malintenzionato non ha accesso alla chiave dell'host privato SSH sul server, ma può monitorare, archiviare e successivamente elaborare tutte le comunicazioni da e verso il server.

In uno scenario simile,

quali garanzie di sicurezza può dare SSH-2 contro intercettazioni sul contenuto delle comunicazioni (violazione della riservatezza)?
queste garanzie di sicurezza sono diverse nella connessione iniziale (prima che la chiave host sia sostituita) e nelle connessioni successive?

monitoring ssh man-in-the-middle

posta a CVn 18.06.2017 - 16:29

fonte

2 risposte

Leggi altre domande sui tag monitoring ssh man-in-the-middle

PRTK con crittografia 7Zip AES-256 Utilizzo di HMAC per generare chiavi segrete

score 1 · Answer 1

Non conosco gli interni del protocollo ssh, quindi la mia risposta si basa sulla conoscenza generale della crittografia e non è garantito che abbia ragione. Bene, niente è.

Se la chiave ssh iniziale è stata generata in un modo "cattivo", potrebbe essere possibile o potrebbe essere impossibile per l'attaccante decrittografare la connessione iniziale al server (dipende da come viene generata la chiave di sessione in ssh-thing che non so)

Se rigenererai la chiave ssh sul server in modo corretto e ti ricolleghi al server, credo che l'intercettatore non sia in grado di decodificare nulla all'interno della tua connessione ssh. Poiché la nuova chiave è "buona" e l'intercettatore non sa che è una parte privata (non è stata trasferita sulla rete, era solo l'impronta digitale).

Questo dovrebbe essere giusto se l'attaccante sta solo ascoltando. Se riesce a manomettere attivamente il tuo traffico, non hai garanzie di sicurezza in nessuno dei due casi:

la chiave iniziale è stata generata "male"
admin non conosce l'impronta digitale chiave dalla fonte attendibile prima di connettersi per la prima volta

score -1 · Answer 2

Dato il tuo secondo punto elenco,

the administrator cannot directly verify the correctness of the SSH host key presented by the server on the first connection

l'amministratore può già connettersi a un altro host (spoofing DNS o instradare la connessione a server diversi), l'utente malintenzionato può presentargli la sua chiave privata (non importa quale, dal momento che l'amministratore non ha modo di scopri qual è il "corretto".

L'autenticazione può essere semplicemente reindirizzata all'host originale per verificare l'autenticazione della chiave pubblica o la password può essere semplicemente letta (viene trasferita in testo normale all'interno della sessione SSH crittografata end-to-end). Ad esempio, utilizzando questo OpenSSH modificato .

Gli altri comandi possono quindi essere eseguiti sul server degli attaccanti (in alcuni sandbox) o in qualche modo inoltrati in modo trasparente al server reale. Questo dipende molto da come l'hacker conosce il flusso di lavoro di questo amministratore e vuole utilizzarlo in modo errato.

Ma per le domande:

1.

what security guarantees can SSH-2 give against eavesdropping on the content of the communications (violation of confidentiality)?

In RFC 4251 , c'è un'intera sezione dedicata a "Confidenzialità" del livello di trasporto. Esistono potenziali attacchi alle modalità CBC e alla sua mitigazione usando

"insertion of packets containing SSH_MSG_IGNORE."

Questo pacchetto extra viene inviato solo se

"only if the packet has been sent out onto the network and there are no other packets waiting for transmission."

che rende il traffico visibile in rete diverso da quello che sta realmente accadendo nella sessione.

Il RFC 4253 sta spiegando come viene composto il pacchetto binario SSH. È possibile notare che la lunghezza del messaggio non deve sempre riguardare la lunghezza dei dati trasferiti. C'è sempre il riempimento di una lunghezza casuale di dati casuali.

are these security guarantees any different in the initial connection (before the host key is replaced) and later connections?

No. La connessione iniziale è la stessa di altre. Ma una volta che scrivi "sì" e non sai che l'impronta digitale è corretta, potresti connetterti a un altro host e potresti non accorgertene nemmeno dopo l'autenticazione.