Palo Alto Networks publicó un aviso sobre una vulnerabilidad de suplantación de identidad de KDC en PAN-OS que fue descubierta y divulgada responsablemente a Palo Alto Networks por Silverfort investigadores Yoav Iellin, Yaron Kassner y Rotem Zach. La vulnerabilidad afectó a todas las versiones compatibles de PAN-OS y a todas las interfaces que utilizaban Kerberos. autenticación perfil. Después de revelar la vulnerabilidad, Palo Alto Networks reparó todas las versiones compatibles de PAN-OS y publicó un asesor al respecto. La vulnerabilidad puede permitir a un atacante eludir el Kerberos autenticación a PAN-OS y obtener acceso a las interfaces administrativas de PAN-OS, así como autenticación a sesiones de firewall a través del portal cautivo.

Esta vulnerabilidad es similar a una Vulnerabilidad de suplantación de identidad de KDC que nuestros investigadores descubrieron en Cisco ASA. Parece que la implementación del protocolo de autenticación Kerberos no siempre se completa correctamente, lo que deja los sistemas vulnerables a exploits.

Palo Alto Networks solucionó esta vulnerabilidad en todas las versiones de PAN-OS. Recomendamos encarecidamente implementar este parche para protegerse contra un exploit.

Este artículo describe la vulnerabilidad de suplantación de identidad de KDC en PAN-OS y muestra cómo se puede utilizar para omitir la autenticación sin conocer la contraseña. Explica cómo evitar estas vulnerabilidades como desarrollador que implementa Kerberos, así como como empresas que utilizan la autenticación Kerberos en sus sistemas.

Explicando la vulnerabilidad

La vulnerabilidad radica en la implementación Kerberos de Palo Alto Networks. Kerberos es el protocolo de autenticación más común para la autenticación local. Está ampliamente disponible en redes corporativas debido a la popularidad de Active Directoryy se prefiere a protocolos de autenticación más débiles como NTLM.

Palo Alto Networks utiliza el protocolo de autenticación Kerberos en muchas interfaces PAN-OS, por ejemplo, SSL VPN, portal cautivo o inicio de sesión de administrador. Por lo tanto, eludir la autenticación Kerberos permite a un atacante administrar Palo Alto Networks Strata, eludir su seguridad y obtener acceso a redes adicionales.

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 PAN-OS con cualquier contraseña, incluso una incorrecta.

Descubriendo la vulnerabilidad en PAN-OS

Descubrimos la vulnerabilidad cuando intentamos agregar SilverfortMFA a interfaces que dependen del protocolo Kerberos, incluidos SSL VPN, portal cautivo y inicio de sesión de administrador. Para configurar esto, configuramos Kerberos como método de autenticación y configuramos una política MFA coincidente en el Silverfort lado. Al final de este artículo se puede encontrar una explicación detallada sobre el protocolo Kerberos y la suplantación de identidad de KDC.
Como se ve a continuación, la captura de red incluye un AS-REQ y un AS-REP pero no un TGS-REQ:

La autenticación fue exitosa a pesar de que el protocolo requiere el TGS-REQ y no estaba en el proceso de autenticación. Como ya descubrimos un vulnerabilidad similar con Cisco ASA, queríamos verificar esto.

Regresamos y revisamos la guía de Palo Alto Networks para configurar la autenticación Kerberos; a continuación se muestra una captura de pantalla de la guía en ese momento:

Nos dimos cuenta de que no estábamos obligados a configurar una tabla de claves o una contraseña de servicio en ningún momento del proceso de configuración. PAN-OS ofrece una opción para configurar una tabla de claves, pero era opcional. Sin embargo, incluso si se configuró la tabla de claves, vimos que no se usaba para el proceso de autenticación en dichas interfaces. Sin una tabla de claves o una contraseña, PAN-OS no tiene las credenciales necesarias para validar la autenticidad del KDC. Esto significa que PAN-OS es susceptible a la suplantación de identidad de KDC.

Intentar explotar la vulnerabilidad

Ahora que sabíamos que PAN-OS es vulnerable, simulamos un ataque redirigiendo el tráfico entre PAN-OS y el KDC, en este caso el 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 nombre principal de usuario (UPN) que el administrador de PAN-OS en el dominio real. Para este ejemplo lo llamaremos 'Bob'. 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 de Bob, 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 de Bob 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. En primer lugar, actualice su PAN-OS a una versión fija y realice los cambios de configuración necesarios que se detallan en la Asesoramiento en redes de Palo Alto.
2. Supervise continuamente su autenticación Kerberos. Busque recursos que soliciten solo AS_REQ. Si no hay TGS_REQ, es una señal de alerta.
3. Uso SilverfortLa herramienta de código abierto. para buscar en los registros de autenticación servicios que no solicitan tickets de servicio.
4. Consulte las recomendaciones de desarrolladores para cualquier aplicación desarrollada internamente que implemente Kerberos y sistemas que usted mismo haya configurado.
5. Silverfort Los clientes que están aprovechando la capacidad de autenticación mejorada con Palo Alto Networks deben actualizar su Silverfort MFA política de una política TGT a una política de ticket de servicio después de actualizar su PAN-OS.

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 de 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 3^rd bibliotecas del partido correctamente – unos 3^rd Las 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-krb5 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)

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 los usuarios inician sesión, ingresan sus credenciales y se lleva a cabo 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, quien más tarde cofundó Duo Security, informó sobre un la técnica Se utiliza para omitir el protocolo Kerberos en algunas situaciones:

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. 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 a elección del atacante. Para la demostración, 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 Trucos 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í.