Silverfort Los investigadores descubren una vulnerabilidad de suplantación de identidad de KDC en F5 Big-IP [CVE-2021-23008]

El año pasado informamos tres vulnerabilidades de suplantación de identidad en el Centro de distribución de claves (KDC) en Cisco ASA, Palo Alto Networks PAN-OS y IBM QRadar. Mencionamos que vendría otro, y ahora que F5 ha emitido una solución, publicamos la cuarta vulnerabilidad de suplantación de identidad de KDC que hemos identificado, esta vez en Big-IP. La vulnerabilidad KDC Spoofing permite a un atacante eludir la autenticación Kerberos en Big-IP Access Policy Manager, eludir las políticas de seguridad y obtener acceso ilimitado a cargas de trabajo confidenciales. En algunos casos, esto también se puede utilizar para omitir la autenticación en la consola de administración de Big-IP. Hemos estado trabajando estrechamente con los ingenieros de F5 para ayudar a solucionar este problema, lo que resultó en la aviso emitido recientemente. Esta publicación de blog describe la vulnerabilidad y explica cómo evitar estas fallas al implementar Kerberosy analiza los pasos de mitigación para los clientes que utilizan Big-IP y otros sistemas basados ​​en Kerberos.

Explicando la vulnerabilidad

F5 Big-IP Application Delivery Services es una solución que entrega aplicaciones de forma segura y escalable. Uno de sus componentes principales es Access Policy Manager (APM), que gestiona y aplica políticas para garantizar que el acceso esté autenticado y autorizado correctamente. En ocasiones, APM también se utiliza para proteger el acceso a la consola de administración de Big-IP.

La vulnerabilidad radica en la implementación del protocolo Kerberos por parte de F5. Kerberos es el protocolo de autenticación más común para la autenticación local. Es ampliamente utilizado en redes corporativas debido a la popularidad de Active Directoryy se prefiere a protocolos de autenticación más débiles como NTLM.

Kerberos se puede utilizar como protocolo de autenticación para la autenticación requerida por una política APM. Cuando un usuario accede a una aplicación a través de Big-IP, es posible que se le presente un portal cautivo y se le solicite que ingrese un nombre de usuario y contraseña. El nombre de usuario y la contraseña se verifican con AD con el protocolo Kerberos para garantizar que el usuario sea quien dice ser. Por lo tanto, eludir la autenticación Kerberos permite a un atacante obtener acceso a aplicaciones Big-IP sin tener credenciales legítimas.

Para que el protocolo Kerberos funcione, deben suceder tres cosas:

1. El usuario se autentica en el servidor.
2. El servidor se autentica ante el cliente.
3. El KDC se autentica en el servidor.

Aparentemente, a menudo se pasa por alto la autenticación KDC en el servidor. Quizás porque requerirlo complica los requisitos de configuración. Sin embargo, si el KDC no se autentica en el servidor, la seguridad del protocolo queda completamente comprometida, lo que permite que un atacante que haya secuestrado el tráfico de la red se autentique en Big-IP con cualquier contraseña, incluso una no válida.

Para conocer la terminología de Kerberos y los antecedentes sobre cómo funciona un ataque de suplantación de identidad de KDC, consulte el final de esta publicación de blog.

A continuación se muestra una captura de pantalla de las instrucciones para configurar la autenticación AD para una política de acceso, tomada del sitio web de F5.

Después de esta configuración, cuando un usuario intenta autenticarse en una aplicación ubicada detrás del proxy, se le pide al usuario que ingrese un nombre de usuario y contraseña. Cuando el usuario ingresa su contraseña, el producto utiliza Kerberos para autenticarse en el controlador de dominio (DC). Sin embargo, APM no solicita un ticket de servicio y otorga acceso según un AS_REP exitoso.
A diferencia de otros escenarios, F5 le permite configurar un nombre de usuario y una contraseña de administrador.

En teoría, esta contraseña podría usarse para autenticar el DC y prevenir la vulnerabilidad. Sin embargo, no se utiliza para estos fines, sino solo para recuperar grupos primarios o anidados, solicitar al usuario un cambio de contraseña o realizar una verificación de complejidad o un restablecimiento de contraseña.

Falsificar la autenticación Kerberos

Estos son los pasos que un atacante puede seguir para falsificar un controlador de dominio y evitar este tipo de autenticación. Supongamos que tenemos la capacidad de secuestrar la comunicación de red entre Big-IP y el DC. En este caso, podemos crear un DC falso con un nombre de usuario idéntico al del administrador y una contraseña de nuestra elección. Luego iniciamos una autenticación en Big-IP y usamos el usuario y contraseña que elegimos. Big-IP se autentica con Kerberos, secuestramos la comunicación de Kerberos y devolvemos un AS_REP que corresponde a la contraseña que elegimos; y un TGS_REP que consta de un ticket de servicio, cifrado con una clave de sesión de servicio de nuestra elección, y una clave de sesión de nuestra elección, cifrada con la contraseña que elegimos. Dado que en estas fases la única verificación que se realiza en el lado de Big-IP depende de la contraseña que elegimos, Big-IP permitirá la autenticación.

Explotación

Simulamos un ataque redirigiendo el tráfico entre Big-IP y el KDC (en este caso un controlador de dominio) en el puerto 88 (el puerto Kerberos) al nuestro. windows Server. Configuramos un dominio falso en el servidor de Windows y nos aseguramos de que haya un usuario con el mismo UPN que el administrador de Big-IP en el dominio real. Configuramos la contraseña de ese usuario para que sea "1" en el dominio falso.

Luego probamos los siguientes escenarios:

• Inicio de sesión normal (tráfico no desviado): logramos iniciar sesión con la contraseña original del usuario, como se esperaba. Al intentar la contraseña "1", el inicio de sesión falló.
• Iniciar sesión con el tráfico desviado a nuestro DC falso; iniciar sesión con la contraseña original del administrador falló, pero iniciar sesión con la contraseña “1” funcionó.

Prevención y Mitigación

Pasos de mitigación para profesionales de la seguridad

1. Actualice su Big-IP a una versión fija
2. Si no hay una versión fija disponible para la versión de Big-IP que está utilizando, asegúrese MFA está habilitado.
3. Actualice su Silverfort política para Big-IP en consecuencia
4. Supervise continuamente su autenticación Kerberos. Busque recursos que soliciten solo AS_REQ. Si no hay TGS_REQ, es una señal de alerta.
5. Uso SilverfortLa herramienta de código abierto. para buscar en los registros de autenticación servicios que no solicitan tickets de servicio.
6. Consulte las recomendaciones de desarrolladores para cualquier aplicación desarrollada internamente que implemente Kerberos y sistemas que usted mismo haya configurado.

Para desarrolladores

Recomendamos algunos pasos para asegurarse de que su solución no sea susceptible a la suplantación de identidad de KDC:

1. Validar que la implementación de Kerberos requiera una contraseña o tabla de claves: Para validar el DC es necesario utilizar algún tipo de secreto compartido. Si su solución no permite configurar un archivo keytab o un cuenta de servicio contraseña, la aplicación seguramente es susceptible a la suplantación de identidad de KDC.
2. Ejecute Wireshark: utilice Wireshark para ver qué solicitudes de Kerberos se envían durante la autenticación. Si no hay TGS_REQ, esto es una señal de alerta.
3. Si desea implementar un protocolo de autenticación usted mismo, debe seguir diligentemente la especificación del protocolo. Recomendamos tomar la ruta más fácil y utilizar una implementación existente de estos protocolos.
4. Utilice bibliotecas de terceros correctamente: algunas bibliotecas de terceros requieren una configuración específica para evitar la suplantación de identidad de KDC. Por ejemplo, una biblioteca común utilizada para Kerberos llamada pam-krb3 debe tener una tabla de claves configurada para funcionar correctamente. Aquí está el párrafo relevante de su documentación (https://github.com/rra/pam-krb5/blob/master/README.md)

¿Qué es lo siguiente?

Estoy seguro de que esta es la última vulnerabilidad de suplantación de identidad de KDC que encontraremos.

Antecedentes

Una descripción general del protocolo Kerberos

El protocolo de autenticación Kerberos fue desarrollado en la década de 1980 por Steve Miller y Clifford Neuman. Permite el inicio de sesión único (SSO) en una red administrada y su Active Directory (AD) lo ha convertido en el protocolo de autenticación principal para entornos empresariales locales.
El protocolo consta de tres intercambios para proporcionar autenticación mutua para el usuario y el servidor al que se accede. Cuando el usuario inicia sesión, ingresa sus credenciales y se realiza el intercambio del Servicio de autenticación (AS). El usuario obtiene un Boleto de Otorgamiento de Boletos (TGT), que luego se utiliza para obtener boletos para servicios específicos durante el Intercambio del Servicio de Otorgamiento de Boletos (TGS). Luego, el ticket se utiliza durante el intercambio cliente/servidor para completar la autenticación:

1. Intercambio del servicio de autenticación (AS)

Durante el intercambio de AS, el usuario se autentica en el Centro de distribución de claves (KDC). A cambio, el usuario obtiene el ticket y la clave necesarios para autenticarse en los servicios de la red sin tener que volver a introducir las credenciales. Cuando el usuario ingresa las credenciales por primera vez, el cliente envía un AS_REQ a la función del Servicio de autenticación (AS) del KDC. El AS_REQ es un mensaje firmado por la Master Key, que es función de la contraseña del usuario. El Servicio de Autenticación, que forma parte del KDC, verifica el AS_REQ según la clave maestra, que también está disponible para el KDC. Después de la validación de AS_REQ, el KDC devuelve un AS_REP, que contiene una clave de sesión de inicio de sesión y un Ticket-Granting Ticket (TGT), que está cifrado con la clave del KDC. El AS Exchange se describe a continuación. El TGT será utilizado por la bolsa TGS para obtener acceso a servicios específicos.

2.Intercambio del Servicio de Concesión de Billetes (TGS)

Cuando el usuario intenta acceder a un servicio en la red, envía un TGS_REQ a la función Ticket Granting Server (TGS) del KDC. Este mensaje se cifra con la clave de sesión de inicio de sesión, que se obtiene durante AS Exchange. El TGS_REQ es verificado por el TGS, que luego devuelve un TGS_REP. El TGS_REP contiene una clave de sesión de servicio y un ticket de servicio, que está cifrado con la clave maestra del servidor que aloja el servicio. La clave maestra del servidor en un sistema basado en Unix se configura en un archivo llamado archivo keytab. La clave maestra del servidor en un servidor miembro se deriva de la contraseña de la cuenta de la computadora. La Bolsa TGS se describe a continuación.

3.Intercambio cliente/servidor

Ahora el cliente tiene todo lo que necesita para autenticarse en el servicio. El cliente envía un AP_REQ al servicio, que está cifrado con la clave de sesión del servicio. El servicio descifra la clave de sesión del servicio para validar AP_REQ. Luego, el servidor devuelve un mensaje AP_REP y la autenticación se completa. El intercambio cliente-servidor se describe a continuación:

Protocolo a prueba de falsificaciones

Cuando el protocolo Kerberos se implementa correctamente, un atacante que intente hacerse pasar por el KDC no puede eludir la autenticación. Esto se debe a que incluso si un atacante crea con éxito un AS_REP válido en respuesta a un AS_REQ secuestrado, el atacante nunca podrá diseñar un ticket de servicio válido. Dado que el ticket de servicio está cifrado con la clave del servidor, una clave que el atacante no tiene, eso sería imposible.

¿Qué es la suplantación de identidad de KDC?

En 2000, Dug Song informó sobre un vulnerabilidad que afecta al protocolo Kerberos (Canción, Dug.2000. Vulnerabilidad de suplantación de identidad de Kerberos KDC. 28 agosto.).

Descubrió que ciertas implementaciones y configuraciones de clientes Kerberos no logran ejecutar el intercambio Cliente/Servidor y permiten la autenticación basada en el éxito de los intercambios anteriores. Desafortunadamente, este comportamiento no es seguro y un atacante puede aprovecharlo. Un atacante que pueda secuestrar la comunicación entre el cliente y el DC puede seguir los siguientes pasos:

1. Crea un KDC falso.
2. Obtener un nombre de usuario autorizado para acceder al servicio que quieren atacar.
3. Cree un usuario en el KDC falso con una contraseña a elección del atacante. Por ejemplo, llamemos a esta contraseña "1".
4. Autentíquese en el servicio con el nombre de usuario obtenido y la contraseña “1”.
5. Secuestra la comunicación del cliente al DC y desvíala al KDC falso.
6. Durante AS Exchange, devuelva un AS_REP que corresponda a la contraseña "1", la clave KDC falsa y una clave de sesión de inicio de sesión falsa.
7. Durante el intercambio TGS, devuelva cualquier TGS_REP.
8. El cliente aceptará la autenticación sin realizar un intercambio de aplicaciones.

Los ataques de suplantación de identidad del KDC suponen que el atacante puede secuestrar el tráfico hacia y desde el KDC y responder en nombre del KDC. Esto se puede hacer utilizando una variedad de técnicas. Por ejemplo, si el atacante se encuentra dentro del mismo segmento de red física que el cliente, puede realizar un ataque de suplantación de ARP como se describe en Hacks de seguridad de red (Lockhart 2007). Otro enfoque posible es hacerse cargo de un dispositivo de red, como un conmutador o enrutador, y controlar la comunicación desde allí.

Agradecimientos

La investigación y el descubrimiento de esta vulnerabilidad fue un esfuerzo conjunto con Thierry Van Steirteghem, quien trabajaba en Exclusive Networks en el momento del descubrimiento.