Kerberos claramente evita que un atacante obtenga las credenciales de un usuario en un escenario de intermediario SSH (uno en el que el atacante ha conseguido que el usuario confíe en la clave pública de su servidor y redirige el tráfico a través de ese servidor). Sin embargo, ¿qué pasa si un atacante está de acuerdo con no obtener las credenciales del usuario porque podrá escuchar la sesión después de la autenticación y potencialmente obtener información valiosa, incluidas las credenciales ingresadas posteriormente?
Para ser claros, aquí está el escenario:
- El servidor SSH (Servidor1) y el cliente (Usuario1) están configurados para Kerberos. El servidor1 tiene un par de claves pública/privada estándar para autenticación, etc.
- El Usuario1 inicialmente intenta conectarse al Servidor1, pero un atacante redirige su conexión al Servidor2.
- El Usuario1 no mira de cerca la clave pública del Servidor2 que se presenta y la acepta como una clave de host conocida para el Servidor1 (configurando así el MITM).
- El Usuario1 pasa por la autenticación Kerberos con el Servidor1 hasta el Servidor2 (El Servidor2 configura dos sesiones SSH separadas y pasa información entre ellas). El atacante no obtiene ninguna información valiosa durante la autenticación debido a la forma en que funciona Kerberos.
- Sin embargo, una vez autenticado, el Usuario1 comienza a realizar operaciones en el Servidor1, incluido sudo. El atacante puede ver todo el contenido de la sesión a medida que pasa por el Servidor2.
¿Funcionaría esto? Obviamente, este escenario se frustraría utilizando la autenticación de clave pública durante el paso de autenticación. Pero, ¿hay algo en el protocolo Kerberos o SSH que pueda prevenir esta situación?
Respuesta1
Un poco ampliado de la discusión en los comentarios:
Su pregunta es: si desvía el tráfico SSH del cliente a un servidor SSH no autorizado, ¿se puede utilizar en un ataque de repetición capturando y reenviando el ticket Kerberos del cliente por parte del servidor SSH no autorizado al Servidor1 real?
Esto se basa en los mecanismos de seguridad SSH que evitan que los ataques MiTM fallen, es decir, el cliente aún no ha almacenado en caché la clave real del servidor del Servidor1 o, si lo ha hecho, StrictHostKeyCheckingse ha desactivado o ignorado.
Dado que SSH + Kerberos GSS-API se basa en SSH para el cifrado de datos, se supone que el servidor SSH fraudulento del intermediario puede, si la autenticación en el Servidor1 es exitosa, acceder a toda la información transmitida, ya que SSH no usa Kerberos. cifrado de datos basado en el cifrado SSH.
Sí, eso funcionaría en teoría, pero solo si su servidor SSH fraudulento, el Servidor2, logra hacerse pasar por el cliente del Servidor1.
Creo que el Servidor1 real rechazaría (o al menos debería) rechazar las credenciales reenviadas. Como parte de la autenticación Kerberos, el cliente envía dos mensajes, elTicket de servicio y autenticador. Aunque un ticket de servicio reenviado es válido, el autenticador que lo acompaña no lo sería.
RFC 4121la especificación Kerberos GSS-API que utiliza SSH tiene la información de enlace de canal como parte del mensaje del autenticador:
"Las etiquetas de enlace de canal están destinadas a identificar el canal de comunicaciones particular para el cual están destinados los tokens de establecimiento de contexto de seguridad GSS-API, limitando así el alcance dentro del cual un atacante puede reutilizar un token de establecimiento de contexto interceptado".
Es decir, el mensaje del Autenticador incluye la dirección IP del remitente y el puerto de origen, así como la dirección IP de destino y los números de puerto. Si no coinciden con los de la conexión real, el Servidor1 debería rechazar el intercambio de Kerberos.