¿Cómo se ve afectada la seguridad de SSH en presencia de un MITM de monitoreo pasivo?

Question

¿Cómo se ve afectada la seguridad de SSH en presencia de un MITM de monitoreo pasivo?

#1 de Strigo (1 votos)
#2 de Jakuje (-1 votos)

10

En un mundo ideal, donde todos los enlaces son totalmente confiables desde el punto de vista de la integridad de los datos, con la configuración adecuada, se puede suponer que el SSH moderno es completamente seguro contra la interceptación del contenido de las comunicaciones, pero puede filtrarse. metadatos (por ejemplo, el hecho de que se está conectando a un host específico, y algunos sobre el patrón de uso y la cantidad de datos transferidos).

En un mundo un poco más realista, por mucho que no queramos que sea así, se debe esperar que los enlaces sean monitoreados . Sabemos que el tráfico cifrado puede ser retenido específicamente por los poderosos adversarios. Sin embargo, todavía hay una gran diferencia entre monitorizar pasivamente el tráfico por un lado y manipularlo activamente en vuelo por el otro.

Suponiendo que:

la clave de host SSH inicial se genera por medios desconocidos, posiblemente defectuosos;
el administrador no puede verificar directamente la corrección de la clave de host SSH presentada por el servidor en la primera conexión, más allá de poder saber si el intento de inicio de sesión fue exitoso o no, pero puede verificar la huella digital de la clave del host mediante comandos dentro de esa sesión una vez establecida;
el administrador reemplaza rápidamente la clave de host SSH con una generada de manera confiable y restablece una conexión una vez que se ha cargado la nueva clave de host;
el administrador confirma diligentemente las huellas dactilares de la clave de host SSH entre el cliente y el servidor;
el administrador no tiene acceso a un canal distinto al servidor para el mantenimiento de claves, por lo que los reemplazos de claves deben realizarse a través de la sesión SSH establecida con la clave de host que se encuentra en el servidor en ese momento;
el atacante no tiene acceso a la clave de host privado de SSH en el servidor, pero puede monitorear, almacenar y luego procesar todas las comunicaciones hacia y desde el servidor.

En tal escenario,

¿Qué garantías de seguridad puede ofrecer SSH-2 contra el espionaje del contenido de las comunicaciones (violación de la confidencialidad)?
¿Son estas garantías de seguridad diferentes en la conexión inicial (antes de que se reemplace la clave de host) y las conexiones posteriores?

man-in-the-middle ssh monitoring

pregunta a CVn 18.06.2017 - 16:29

fuente

2 respuestas

Lea otras preguntas en las etiquetas man-in-the-middle ssh monitoring

¿Por qué el HSTS no se aplica automáticamente a los subdominios para mejorar la seguridad? ¿Por qué razón alguien no querría HSTS en cada subdominio? Encabezados de almacenamiento en caché HTTP: privado vs no-cache

score 1 · Answer 1

No sé el protocolo interno de ssh, por lo que mi respuesta se basa en el conocimiento general de la criptografía y no se garantiza que sea correcta. Bueno, nada es.

Si la clave ssh inicial se generó de alguna manera "mala", entonces podría ser posible o imposible para el atacante descifrar su conexión inicial al servidor (depende de cómo se genere la clave de sesión en ssh-thing que no sé).

Si vuelve a generar la clave ssh en el servidor de manera correcta y se vuelve a conectar al servidor, creo que el intruso no podría descifrar nada dentro de su conexión ssh. Dado que la nueva clave es "buena" y el intruso no sabe que es una parte privada (no se transfirió a través de la red, solo lo fue la huella digital).

Eso debería estar bien si el atacante solo está escuchando a escondidas. Si él puede manipular activamente su tráfico, no tiene garantías de seguridad en ninguno de los dos casos:

la clave inicial se generó "mal"
el administrador no conoce la huella digital clave de una fuente confiable antes de conectarse por primera vez

score -1 · Answer 2

Dado su segundo punto,

el administrador no puede verificar directamente la corrección de la clave de host SSH presentada por el servidor en la primera conexión

el administrador puede estar ya conectado a un host diferente (falsificando el DNS o enrutando la conexión a un servidor diferente), el atacante puede presentarle su propia clave privada (no importa cuál, ya que el administrador no tiene forma de Averigüe cuál es el "correcto".

La autenticación se puede redirigir muy simplemente al host original para verificar la autenticación de clave pública o la contraseña se puede leer simplemente (se transfiere en texto sin formato dentro de la sesión SSH cifrada de extremo a extremo). Por ejemplo, utilizando este OpenSSH modificado .

Los otros comandos se pueden ejecutar en el servidor del atacante (en algunos entornos limitados) o de alguna manera se pueden reenviar al servidor real. Esto realmente depende de cómo el atacante conoce el flujo de trabajo de este administrador y quiere usarlo mal.

Pero a las preguntas:

1.

¿Qué garantías de seguridad puede ofrecer SSH-2 contra el espionaje del contenido de las comunicaciones (violación de la confidencialidad)?

En RFC 4251 , hay una sección completa dedicada a la "Confidentalidad" de la capa de transporte. Hay posibles ataques en los modos CBC y su mitigación utilizando

"inserción de paquetes que contienen SSH_MSG_IGNORE".

Este paquete adicional se envía solo si

"solo si el paquete se ha enviado a la red y no hay otros paquetes en espera de transmisión."

que hace que el tráfico visible en la red sea diferente de lo que realmente sucede en la sesión.

El RFC 4253 explica cómo se compone el paquete binario SSH. Puede observar que la longitud del mensaje no siempre tiene que estar relacionada con la longitud de los datos transferidos. Siempre hay un relleno de longitud aleatoria de datos aleatorios.

¿Estas garantías de seguridad son diferentes en la conexión inicial (antes de que se reemplace la clave de host) y en las conexiones posteriores?

No. La conexión inicial es la misma que otra. Pero una vez que escriba "sí" y no sepa que la huella dactilar es correcta, es posible que se conecte a un host diferente y que incluso no lo note después de la autenticación.