E 'possibile che un MITM SSH attaccha solo se la chiave non si trova in known_hosts?

4

Stavo cercando di connettere un server usando una porta diversa quando la rete sembrava troppo lenta. Fornisce una chiave ECDSA, mentre la chiave precedente in known_hosts è RSA. Mi sono rifiutato di continuare la connessione e ho provato più volte ad usare entrambe le porte, e non ho mai ricevuto un avvertimento. Alla fine mi sono connesso al server usando la porta originale e ho scoperto che il server non ha alcuna chiave ECDSA.

Potrebbe essere solo una sorta di errore DNS o di errore del gateway. Ma è possibile essere usato in un attacco? Alcuni nuovi utenti incuranti possono compromettere i server e altri utenti con la chiave già in known_hosts potrebbero non notare mai che l'attacco è avvenuto.

E se è usato in un attacco, sarebbe più sicuro usare l'autenticazione a chiave pubblica invece di una password?

Ecco la mia teoria per l'attacco:

L'utente malintenzionato esegue prima una scansione del server per assicurarsi che non abbia una chiave ECDSA. Se un client tenta di connettersi senza specificare l'algoritmo, dice che ha solo la chiave ECDSA. Se invece il client sceglie di utilizzare RSA, l'utente malintenzionato può reindirizzare la connessione al server reale senza essere notato.

Se il reindirizzamento è impossibile, l'attaccante può provare a rendere la rete apparentemente molto instabile e, infine, disconnettere prima di inviare la chiave. Poiché non ha mai inviato una chiave falsa, l'utente non riceve mai l'avviso che la chiave del server è stata modificata.

Potrebbero anche impostare una piccola probabilità per consentire all'utente di connettersi al server reale, quindi è improbabile che studi il problema. E possono aggiungere la chiave ECDSA al server reale se l'attacco ha successo, per fingere che l'attacco non sia mai accaduto.

Più in particolare, la parte di selezione dell'algoritmo è stata eseguita prima di verificare la chiave del server e funziona in un modo che potrebbe perdere lo stato di known_hosts senza un avviso?

Una teoria alternativa sarebbe un attaccante che sta solo intercettando il traffico su una porta specifica. Ma potrò confermare solo se il problema si ripresenta più tardi.

Modifica: si è rivelata una configurazione del server molto strana. (La macchina virtuale viene clonata da qualcuno con il privilegio, e uno di questi è aggiornato per avere una chiave ECDSA. È stato scambiato con un altro quando mi collego.)

    
posta user23013 06.07.2015 - 18:20
fonte

1 risposta

4

Prima di tutto, la risposta dipende dal tuo client SSH. Supponiamo che stiate usando l'ultimo client OpenSSH. Il protocollo SSH2 inizia così:

Client -> Server: Initiate connection, send client software version + SSH version
Server -> Client: Server software version and SSH version
Client -> Server: Client supported algorhitms
Server -> Client: Server supported algorhitms
Client -> Server: Diffie-Hellmann key exchange init
Server -> Client: Diffie-Hellmann parameters and server key!

Diciamo che known_hosts contiene la nota chiave RSA, ma il server ha inviato una chiave ECDSA. OpenSSH rileva una modifica della chiave!

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
78:16:03:b0:88:c3:9b:a7:7d:34:87:a5:8b:36:f1:4f.
Please contact your system administrator.
Add correct host key in /root/.ssh/known_hosts to get rid of this message.
Offending RSA key in /root/.ssh/known_hosts:1
ECDSA host key for 127.0.0.1 has changed and you have requested strict checking.
Host key verification failed.

Ora la domanda è: StrictHostKeyChecking è impostato su yes nella configurazione SSH?

E, ultimo ma non meno importante, se sei preoccupato di essere hackerato da un MiTM SSH, ti suggerisco di utilizzare le chiavi SSH per l'autenticazione anziché le password. È molto più sicuro e la tua password è sicura (a patto che tu non usi la password per sudo :) o qualcos'altro).

    
risposta data 17.08.2015 - 19:10
fonte

Leggi altre domande sui tag