Tercera vulnerabilidad de suplantación de identidad del KDC identificada por Silverfort Investigadores: esta vez en IBM QRadar [CVE-2019-4545]

*****Por Yoav Iellin, Yaron Kassner, Dor Segal y Rotem Zach, Silverfort*****

La suplantación de identidad de KDC nunca pasa de moda. Hemos revelado vulnerabilidades de suplantación de identidad de KDC en Cisco ASA y Palo Alto Networks PAN-OS en mayo de 2020. Ahora podemos compartir que IBM QRadar también es vulnerable debido a la forma Kerberos ha sido implementado.
La vulnerabilidad KDC Spoofing permite a un atacante eludir la autenticación Kerberos en QRadar y, como resultado, obtener acceso administrativo al sistema. Hemos estado trabajando estrechamente con los ingenieros de IBM para ayudar a solucionar este problema, lo que resultó en la publicación recientemente publicada. boletín de seguridad . Esta publicación de blog describe la vulnerabilidad, explica cómo evitarlas como desarrollador que implementa Kerberos y habla sobre la mitigación para organizaciones que usan QRadar y otros sistemas que usan Kerberos.

Explicando la vulnerabilidad

IBM QRadar Security Information and Event Management (SIEM) ayuda a los equipos de seguridad a detectar y priorizar amenazas en toda la empresa y proporciona información importante que permite a los equipos responder rápidamente para reducir el impacto de los incidentes.
La vulnerabilidad radica en la implementación del protocolo Kerberos por parte de IBM. 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.
IBM utiliza el protocolo de autenticación Kerberos para autenticar el acceso administrativo. Por lo tanto, eludir la autenticación Kerberos permite a un atacante obtener acceso administrativo a IBM QRadar, ver información confidencial y potencialmente alterar registros, 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 QRadar con cualquier contraseña, incluso una incorrecta.

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.

Cómo descubrimos la vulnerabilidad en QRadar

El acceso de administrador a QRadar debe protegerse con una autenticación sólida para evitar el acceso no autorizado y la manipulación del sistema. Usar la autenticación AD es una opción popular:
Cuando un administrador se autentica en QRadar, utiliza una serie de parámetros para autenticar al administrador (consulte a continuación una instantánea de la guía de implementación tomada de esta página). En primer lugar, QRadar solicita un TGT de AD. Después de recibir el TGT, QRadar solicita un ticket de servicio para la autenticación LDAP al controlador de dominio. Si tiene éxito, QRadar utiliza SASL para autenticarse con LDAP en el controlador de dominio. Utiliza el ticket de servicio para acreditar la identidad del usuario.

Falsificación de la autenticación Kerberos/SASL

Estos son los pasos que seguirá un atacante 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 QRadar 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 QRadar y utilizamos el usuario y contraseña que elegimos. QRadar 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 QRadar depende de la contraseña que elegimos, QRadar no debería rechazar la autenticación en este punto. Ahora que QRadar recibió el ticket de servicio, puede iniciar una solicitud LDAP al DC. También secuestraremos el tráfico LDAP. Tenemos dos opciones en este punto:
1. Se utiliza LDAP sin TLS. En este caso podemos secuestrar el tráfico LDAP. QRadar envía una solicitud de enlace al DC con un mensaje Kerberos AP_REQ, que contiene el ticket de servicio que tenemos. Podemos devolver un AP_REP basado en la clave de sesión de servicio que elegimos y QRadar lo aceptará.
2. Se ha configurado LDAPS. En este caso, no podemos devolver una respuesta en nombre del DC, porque se utiliza TLS para autenticar el DC, es decir, suponiendo que el certificado se haya configurado en el lado de QRadar.

Falsificación de la autenticación Kerberos/SASL/LDAPS para QRadar

Antes de abandonar la opción 2, notamos el siguiente comportamiento extraño. Si configuramos una dirección IP como URL del servidor, la autenticación aún funciona. En teoría, la autenticación con una dirección IP no debería funcionar, porque Kerberos no permite la autenticación de direcciones IP a menos que se haya configurado explícitamente un SPN.
Al enviar TGS_REQ, QRadar solicita un ticket a ldap/. Dado que el DC no tiene un nombre principal de servicio (SPN) con ese nombre, devuelve un error KRB_ERR_S_PRINCIPAL_UNKOWN. Según el protocolo Kerberos, se supone que QRadar deniega la autenticación en este punto. Sin embargo, una captura de red revela que se abre una solicitud LDAP incluso después del error y QRadar la restablece inmediatamente. Luego, el usuario puede iniciar sesión. Concluimos que QRadar considera que la autenticación fue exitosa incluso antes de completar el intercambio de aplicaciones Kerberos. Esto puede explotarse fácilmente. Como atacantes, podemos enviar un KRB_ERR_S_PRINCIPAL_UNKOWN justo después de falsificar el AS_REP y podemos hacer que QRadar acepte una autenticación con una contraseña de nuestra elección. El ataque se describe a continuación.

Un error adicional en QRadar hace que solicite autenticación de AD para un usuario que no necesariamente existe. QRadar tiene un usuario administrador local integrado. Resulta que al intentar la autenticación con el usuario administrador, QRadar primero intenta autenticarse en el DC con Kerberos. Este nombre de usuario no tiene que existir en AD. Esto facilita el ataque, porque el atacante conoce de antemano el nombre de usuario.

Además, este error podría considerarse una vulnerabilidad por sí solo. Independientemente de la suplantación de identidad de KDC, si un atacante puede obtener privilegios para crear usuarios en AD, por ejemplo, al hacerse cargo de una cuenta de la mesa de ayuda, el atacante puede crear un usuario llamado administrador en AD. Luego, el atacante puede utilizar ese usuario para autenticarse en QRadar.

Explotación

Ahora que sabíamos que QRadar es vulnerable, simulamos un ataque redirigiendo el tráfico entre QRadar y el KDC (en este caso un controlador de dominio) en el puerto 88 (el puerto Kerberos) a nuestro propio servidor Windows. 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 QRadar en el dominio real. Configuramos la contraseña de ese usuario para que sea "1" en el dominio falso.

Luego probamos las siguientes situaciones:
– Inicio de sesión normal (tráfico no desviado): logramos iniciar sesión con la contraseña original del administrador, 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ó.

La mitigación de IBM

El enfoque de IBM para mitigar esta vulnerabilidad es simple y seguro. Dado que se puede lograr exactamente la misma funcionalidad de autenticación en QRadar con LDAPS, la mitigación recomendada es simplemente cambiar de Kerberos a la autenticación LDAPS. Después de eso, debes instalar el parche de IBM. El parche verificará que la autenticación esté efectivamente configurada en LDAPS y fallará si aún no ha cambiado a la autenticación LDAPS. Esto es para asegurarse de que su sistema esté seguro después del parche.

Si has estado usando Silverfort Para proteger la autenticación en QRadar, también deberá actualizar el Silverfort política para QRadar para proteger la autenticación LDAPS en lugar de la solicitud Kerberos TGT.

Prevención y Mitigación

Pasos de mitigación para profesionales de la seguridad

1. Cambiar autenticaciónen su QRadar de Kerberos a LDAPS
2. Actualice su QRadar a una versión fija
3. Actualiza tu Silverfort política para QRadar 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. Utilizar 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 los desarrolladores para cualquier aplicación desarrollada internamente que implemente Kerberos y sistemas que usted mismo haya configurado.

Como desarrollador

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 Kerboros 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 Kerberos se envían durante la autenticación. Si no hay TGS_REQ, es una señal de alerta.
3. Si desea implementar un protocolo de autenticación usted mismo, debe seguir diligentemente los RFC 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?
Descubrimos otra vulnerabilidad de suplantación de identidad de KDC y esperamos escribir sobre ella pronto, pero no antes de que el proveedor publique un parche. Hasta entonces, estad atentos.

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 validar el AS_REQ, el KDC devuelve un AS_REP, que contiene una clave de sesión de inicio de sesión y un ticket de concesión de boletos (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 de 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. Cree un KDC falso.
2. Obtenga un nombre de usuario autorizado para acceder al servicio que desea atacar.
3. Cree un usuario en el KDC falso con una contraseña elegida por el atacante. Para demostración, llamemos a esta contraseña "1".
4. Autenticarse 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í.