La autenticación es la puerta de entrada a los sistemas de seguridad, por lo que si la evitas, puedes hacer prácticamente lo que quieras. Puedes entrar como administrador y cambiar configuraciones, acceder a recursos protegidos y obtener el control de los aparatos para robarles datos sensibles. Por estas razones, los protocolos de autenticación utilizados por los sistemas de seguridad deben ser impecables. Pero en seguridad, no existe un sistema impecable, y los errores de implementación pueden dar lugar a peligrosas vulnerabilidades de seguridad.
Y eso es exactamente lo que descubrimos al analizar cuatro sistemas de seguridad diferentes: Cisco ASA, F5 Big-IP, IBM QRadar y Palo Alto Networks PAN-OS. Todos eran vulnerables a los ataques de derivación debido a la forma en que implementaban los protocolos de autenticación Kerberos y LDAP.
Para entender estas vulnerabilidades, primero hay que comprender cómo funciona el protocolo de autenticación Kerberos. Consta de tres intercambios:
- En el intercambio del servicio de autenticación, un usuario se conecta a un cliente mediante un nombre de usuario y una contraseña para autenticarse en un servicio de autenticación, que reside en un centro de distribución de claves (KDC). A cambio, el servicio de autenticación proporciona un Ticket Granting Ticket (TGT), que se utiliza en el siguiente intercambio.
- A continuación, en el intercambio del Servicio de Concesión de Tickets, el cliente presenta el TGT a un Servicio de Concesión de Tickets (TGS), que también reside en el KDC, y solicita un ticket para acceder a un servicio concreto. El TGS devuelve un ticket de servicio.
- Por último, en el intercambio Cliente/Servidor, el cliente presenta el ticket de servicio al servidor, que lo verifica y permite al cliente acceder al servicio.
El protocolo Kerberos es sólido. Fue desarrollado en el MIT y proporciona Single Sign On (SSO) a muchas grandes empresas.
Una mala configuración puede provocar un ataque
Los cuatro sistemas de seguridad que hemos mencionado anteriormente pueden configurarse para utilizar Kerberos sin sus capacidades SSO. En su lugar, se pide al usuario un nombre de usuario y una contraseña al iniciar la sesión, y el sistema solicita el TGT. En otras palabras, el sistema de seguridad hace las veces de cliente y de servidor.
Uno podría pensar: si el cliente y el servidor son lo mismo, ¿por qué necesito el intercambio cliente/servidor? La contraseña se verifica durante el intercambio del Servicio de Autenticación, así que eso debería ser suficiente. Este proceso de pensamiento parece legítimo, sólo que han olvidado la primera regla del club de la lucha: No te desvíes de las especificaciones.
Ataques de falsificación de KDC
De hecho, esto no es legítimo en absoluto. Algunos dirían que es incluso ilegítimo. Descuidar el intercambio Cliente/Servidor puede dar lugar a una vulnerabilidad de suplantación del KDC. Veámoslo desde la perspectiva de un atacante:
Quiero autenticarme en el sistema, pero no conozco la contraseña. Así que intento autenticarme con una contraseña de mi elección – lo más probable es que sea una contraseña incorrecta, pero la idea es engañar al sistema para que piense que es la contraseña correcta.
El sistema, siendo el cliente de Kerberos, llegará al KDC para solicitar un TGT. Si este mensaje es realmente procesado y respondido por el KDC real, el ataque no funcionará, porque el KDC se dará cuenta de que la contraseña es incorrecta, y simplemente negará la autenticación. Pero si secuestramos la comunicación entre el sistema y el KDC, entonces podemos hacer cosas realmente malvadas.
¿Qué pasa si me hago pasar por el KDC, y en lugar de devolver un error, devuelvo un TGT falso?
Bien, en ese caso, durante el intercambio de TGS, el KDC rechazará mi TGT. Pero también puedo secuestrar la comunicación del intercambio TGS y devolver un ticket de servicio falso. Ah, pero entonces el intercambio Cliente/Servidor no funcionará, porque el servidor rechazará mi ticket de servicio falso.
Por otra parte, estos cuatro proveedores de seguridad no han implementado el intercambio Cliente/Servidor en absoluto. Así que puedo entrar con mi contraseña falsa en todos estos sistemas.
En realidad, descubrir estas vulnerabilidades fue un poco más complicado que eso, porque cada uno de los productos implementó el protocolo Kerberos de manera un poco diferente, y esto requirió cambios en el patrón de ataque original.
