¿Es posible que un MITM de SSH ataque solo si la clave no está en el host conocido?

4

Estaba intentando conectar un servidor usando un puerto diferente cuando la red parecía demasiado lenta. Proporciona una clave ECDSA, mientras que la clave anterior en conocido_hosts es RSA. Me negué a continuar la conexión y probé más veces usando ambos puertos, y nunca recibí una advertencia. Finalmente, me conecté al servidor utilizando el puerto original y descubrí que el servidor no tiene ninguna clave ECDSA.

Puede ser solo un error de DNS o de puerta de enlace. ¿Pero es posible ser utilizado en un ataque? Algunos usuarios nuevos descuidados pueden comprometer sus servidores, y otros usuarios con la clave ya conocida en hosts conocidos nunca se darán cuenta de que ocurrió el ataque.

Y si se usa en un ataque, ¿sería más seguro usar autenticación de clave pública en lugar de una contraseña?

Aquí está mi teoría para el ataque:

El atacante primero explora el servidor para asegurarse de que no tenga una clave ECDSA. Si un cliente intenta conectarse sin especificar el algoritmo, dice que solo tiene la clave ECDSA. Si, en cambio, el cliente elige utilizar RSA, el atacante puede redirigir la conexión al servidor real sin que se note.

Si la redirección es imposible, el atacante puede intentar que la red parezca muy inestable y finalmente se desconecta antes de enviar la clave. Dado que nunca envió una clave falsa, el usuario nunca recibe la advertencia de que se cambió la clave del servidor.

También pueden establecer una pequeña probabilidad de simplemente permitir que el usuario se conecte al servidor real, por lo que es poco probable que investiguen este problema. Y pueden agregar la clave ECDSA al servidor real si el ataque tiene éxito, para fingir que el ataque nunca ocurrió.

Más específicamente, ¿se realiza la parte de selección de algoritmo antes de verificar la clave del servidor, y funciona de una manera que pueda filtrar el estado de known_hosts sin una advertencia?

Una teoría alternativa sería que un atacante solo está interceptando el tráfico en un puerto específico. Pero solo podré confirmar si este problema vuelve a aparecer más tarde.

Editar: Resultó ser una configuración de servidor muy extraña. (La máquina virtual es clonada por alguien con el privilegio, y uno de ellos se ha actualizado para tener una clave ECDSA. Se intercambió con otro cuando me conecté).

    
pregunta user23013 06.07.2015 - 18:20
fuente

1 respuesta

4

En primer lugar, la respuesta depende de su cliente SSH. Supongamos que está utilizando el último cliente OpenSSH. El protocolo SSH2 comienza así:

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!

Supongamos que known_hosts contiene la clave RSA válida conocida, pero el servidor envió una clave ECDSA. ¡OpenSSH detecta un cambio clave!

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

Ahora la pregunta es: ¿StrictHostKeyChecking está configurado en sí en su configuración de SSH?

Y por último, pero no menos importante, si está preocupado por ser pirateado por un SSH MiTM, sugiero usar claves SSH para la autenticación en lugar de las contraseñas. Es mucho más seguro y su contraseña es segura (siempre y cuando no use la contraseña para sudo :) o algo más).

    
respondido por el user2716262 17.08.2015 - 19:10
fuente

Lea otras preguntas en las etiquetas