¿La autenticación de clave pública en SSH evita la mayoría de los ataques MITM?

Question

¿La autenticación de clave pública en SSH evita la mayoría de los ataques MITM?

#1 de Edgar (2 votos)
#2 de theCowardlyFrench (1 votos)

4

Encontré este artículo que afirma que la firma criptográfica asimétrica de la clave obtenida con DH evita MITM:

Idea clave:

El valor de 'firma' es una firma del correspondiente privado clave sobre los siguientes datos, en el siguiente orden:
string    session identifier
byte      SSH_MSG_USERAUTH_REQUEST
Ahora el atacante tiene un problema, ya que el cliente y el servidor tienen diferentes ideas sobre qué identificador de sesión se supone que debe ser. Obviamente, el servidor rechazará la firma proporcionada por el cliente y la autenticación de clave pública fallará.

Me gustaría verificar si mi comprensión de esto es correcta:

Deje que Alice ( A ) sea cliente, MITM ( M ) un atacante y Bob ( B ) un servidor ssh.

Suposiciones:

M se encuentra en medio de la comunicación, interceptando todas las comunicaciones entre A y B
M de alguna manera engañó a A para que crea que es B y también engañó a B para que piense que es A (re huellas digitales, etc.).
Sin embargo, M no ha logrado penetrar la máquina de A ni la máquina de B , dejando la clave pública de A en la cuenta de A en B máquina intacta

Mientras se cumplan las condiciones anteriores de esta:

El identificador de sesión se calcula en función (entre otras cosas) del secreto compartido negociado por los compañeros que utilizan el algoritmo Diffie-Hellman.

= > mientras que M puede falsificar intercambios de DH con A y B , necesariamente tendrán que ser 2 secretos compartidos diferentes (falsos) (a menos que haya alguna forma para que M comprometa eso mediante la modificación de modificando intercambiaron números DH, no observándolos).

Cuando este secreto compartido se usa como componente de la creación de datos a firmar (parte o la totalidad del identificador de sesión), una cosa que M no puede falsificar y no sabe es la clave privada de A que se usará para firmar el ID de sesión basado en (1er) secreto compartido falso.

Por lo tanto, la firma digital del ID de sesión (+ otros datos de sesión según la descripción anterior) falla la verificación en B , o los ID de sesión no coincidirán, rompiendo la comunicación de manera efectiva.

Preguntas:

¿es correcto este razonamiento? Si no, ¿dónde están los errores?
¿la creación de ID de sesión es el "eslabón más débil" en esta cadena? Es decir, si M podría predecirlo (por ejemplo, si es un hash predecible que es susceptible de ataque estadístico, incluso si DH no lo es) y adivínelo de alguna manera (muy improbable, sí, pero es incluso teóricamente imposible) ?), entonces M tendría una ID de sesión "genuina" firmada por A y así B pensaría que la firma de autenticación es correcta?

Me doy cuenta de que esto es casi imposible en la práctica, pero ¿es completamente teórico imposible?

vulnerability man-in-the-middle ssh diffie-hellman asymmetric

pregunta wtfantastic 11.09.2014 - 20:00

fuente

2 respuestas

Lea otras preguntas en las etiquetas vulnerability man-in-the-middle ssh diffie-hellman asymmetric

Contraseña del sistema de Windows con hash: vea qué hash se usa ¿Dónde enviar el malware recolectado de mi honeypot?

score 2 · Answer 1

1.Sí es correcto. Hay 2 formas posibles:

A) Alice acepta ciegamente la nueva huella digital de la mallory atacante.   Alice y Mallory podrían conectarse y autenticarse mutuamente. Problema   Aquí para Mallory está, que no pudo firmar el ID de sesión, intercambiado   con bob Porque Mallory no posee la clave privada de Alice. Y   También Mallory no pudo redirigir el ID de sesión firmado de Alice a   Bob, porque el identificador de sesión sería, con alta probabilidad,   diferente.

B) Cuando Alice no acepta ciegamente la nueva huella digital, Mallory podría   Enviar la clave pública y, por tanto, la huella digital de Bob. Problema aqui   Sería que Mallory no podría autenticarse ante Alice, porque Mallory.   no era el propietario de la clave privada de Bob.

AVISO: En el caso A), cuando Alice también acepta una autenticación de contraseña, mallory configurará su servidor para autenticar al cliente con la autenticación de contraseña y así mallory obtendrá el nombre de usuario y la contraseña.

2.Sí, teóricamente sería posible. Consulte en A), ¿por qué Alice no debe aceptar la identificación firmada correcta de Bob? Ella aceptaría :) Y también Alice aceptaría la identificación firmada correcta de Bob. Mallory solo necesita mostrar a Alice la clave pública de Bob en la creación de la conexión.

score 1 · Answer 2

Aquí es donde esto falla. Usted asume:

M somehow tricked A into thinking that he's B and also tricked B into thinking he's A (re fingerprints etc).

Las huellas digitales son algo que no se pueden duplicar. Una huella dactilar (también conocida como HMAC) es un hash de la clave secreta. La clave secreta nunca se transmite, pero el cliente y el servidor la calculan de forma independiente mediante la clave maestra preshsared .

En PKI, la clave privada y pública son útiles porque a) la clave privada no puede derivarse de la clave pública yb) la clave pública se puede usar para cifrar datos que se pueden descifrar con la clave privada del servidor, y viceversa. versa

Por lo tanto, sin conocer la clave privada del servidor, nunca puede realizar un ataque MITM útil en una sesión SSH. Además, la mayoría de las veces, SSH simplemente reanudará una sesión en lugar de negociar una nueva. Esto implica enviar el ID de sesión en texto sin formato, pero reanudar el cifrado con el conjunto de cifrado predeterminado, que es desconocido para el atacante o [M], en este escenario.