Investigadores de seguridad en Silverfort, proveedor de plataforma de autenticación sin agentes, identificó una vulnerabilidad grave que puede permitir a los piratas informáticos obtener control sobre Cisco Adaptive Security Appliance (ASA). Todas las versiones de ASA se ven afectadas. Después de revelar la vulnerabilidad a Cisco, Cisco reparó todas las versiones compatibles de ASA y publicó un aviso en eso. A la vulnerabilidad (CVE-2020-3125) se le asignó una puntuación de riesgo CVSS de 8.1 sobre 10, que se considera "alta". Esto se debe a que la vulnerabilidad puede permitir a un atacante eludir el Kerberos autenticación a Cisco ASA. Silverfort Los investigadores a los que se les atribuye el descubrimiento de la vulnerabilidad son: Yoav Iellin, Yaron Kassner, Dor Segal y Rotem Zach.

Cisco solucionó esta vulnerabilidad en todas las versiones de ASA. Recomendamos encarecidamente que las empresas actualicen a las últimas versiones de ASA para protegerse contra un exploit.

Este artículo describe la vulnerabilidad de suplantación de identidad de KDC y muestra cómo se puede utilizar para evitar la autenticación en Cisco ASA. Explicará cómo evitar estas vulnerabilidades tanto como desarrollador que implementa Kerberos como para empresas que ya han implementado estas soluciones en sus redes.

Explicando la vulnerabilidad

La vulnerabilidad radica en la implementación Kerberos de Cisco. 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.

Cisco utiliza el protocolo de autenticación Kerberos en muchas interfaces ASA, por ejemplo, VPN, apertura de sesiones de firewall y acceso administrativo, ya sea a través de la consola de administración web o mediante SSH. Por lo tanto, eludir la autenticación Kerberos permite a un atacante hacerse cargo del dispositivo Cisco, eludir su seguridad y obtener acceso a otras redes.

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

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 el año 2000, Dug Song informó de una vulnerabilidad que afectaba 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. 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í.

Cómo descubrimos la vulnerabilidad en Cisco ASA

Estábamos buscando una manera de agregar Autenticación multifactorial (MFA) para administradores que acceden a Cisco ASA y Anyconnect VPN. Después de configurar Cisco para usar Kerberos como protocolo de autenticación, examinamos los registros de autenticación en SilverfortLa consola. Silverfort proporciona visibilidad completa de todas las actividades de autenticación en la red. SilverfortLos registros mostraron que Cisco ASA estaba solicitando un TGT sin solicitar un ticket de servicio.

Volvimos a la guía de configuración. Cisco. 2007. PIX/ASA: Autenticación Kerberos y grupos de servidores de autorización LDAP para usuarios de clientes VPN a través del ejemplo de configuración ASDM/CLI. 30 de julio. ; y examinó los parámetros necesarios para configurar la autenticación Kerberos:

Como se vio arriba, no hay ningún lugar para ingresar la contraseña o la configuración de la tabla de claves para la autenticación Kerberos. La contraseña o la tabla de claves son necesarias para una implementación correcta, ya que crean el 'secreto' utilizado por Kerberos para autenticarse de forma confiable en el KDC. Sin el "secreto", no se puede confiar criptográficamente en la autenticación.

Seguimos adelante e intentamos lo mismo con otras interfaces de Cisco y vimos que existe la misma vulnerabilidad al abrir sesiones de firewall, autenticación administrativa e incluso cuando se usa SSH para acceder a la VM. Consulte a continuación la columna Kerberos en la tabla que resume el soporte de Cisco para diferentes protocolos de autenticación.

Explotación

Lo siguiente que queríamos ver es si esta vulnerabilidad se puede explotar. Para ello, secuestramos el tráfico Kerberos destinado al DC y lo desviamos a nuestro servidor. En lugar de desarrollar nuestra propia lógica KDC, simplemente instalamos AD Domain Services en nuestro servidor fraudulento, promocionando nuestro servidor como un controlador de dominio. Por supuesto, al no ser administrador del dominio original, creamos un nuevo dominio falso.

Como conocemos el nombre de usuario del administrador de Cisco en el primer dominio (Bob en este ejemplo), creamos un usuario llamado Bob en nuestro dominio falso. Configuramos la contraseña de ese usuario en nuestro dominio falso para que sea "1".

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 Cisco ASA a una versión fija y realice los cambios de configuración necesarios que se detallan en la Asesor de Cisco
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 Silverfort, 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 Política MFA 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 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, 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)