Uso de la VPN: Exploración de las técnicas posteriores a la explotación de la VPN
Resumen ejecutivo
En esta entrada del blog, los investigadores de Akamai describen la amenaza que se pasa por alto después de la explotación de la VPN, es decir, abordamos las técnicas que pueden utilizar los atacantes después de vulnerar un servidor VPN para escalar aún más su intrusión.
Nuestros resultados incluyen varias vulnerabilidades que afectaron a las VPN de Ivanti Connect Secure y FortiGate.
Además de las vulnerabilidades, detallamos un conjunto de técnicas de no corrección que pueden afectar a los productos Ivanti Connect Secure y FortiGate, así como a otros servidores VPN.
Nuestra investigación muestra que, en muchos casos, un servidor VPN vulnerado podría permitir a los atacantes obtener fácilmente el control sobre otros activos esenciales de la red.
Esta entrada del blog tiene como objetivo concienciar sobre estos riesgos y presenta las prácticas recomendadas que deben seguir los defensores para minimizar los riesgos que conllevan las técnicas posteriores a la explotación de la VPN.
Introducción
Todos hemos escuchado esta historia antes: se detecta una vulnerabilidad crítica en un servidor VPN. Se explota en el mundo real. Los administradores se apresuran a aplicar parches. El pánico se propaga por las redes sociales.
El año pasado fue bastante duro para la seguridad VPN: parece que un mes sí y otro no se aplica un parche a una vulnerabilidad crítica o se descubre una vulnerabilidad tras su explotación en el mundo real por parte de los atacantes. Aunque este tipo de actividad experimentó un aumento significativo en 2023, no es nuevo. Los atacantes llevan mucho tiempo intentando explotar los servidores VPN porque son accesibles desde Internet, exponen una superficie de ataque atractiva y a menudo carecen de seguridad y supervisión.
Históricamente, los servidores VPN se han explotado principalmente para lograr un único objetivo: el acceso inicial. Los atacantes vulneran el servidor VPN orientado a Internet y lo utilizan como entrada inicial a la red interna, lo que les permite llevar a cabo sus intrusiones.
Aunque este enfoque es muy eficaz, nos hemos preguntado lo siguiente: ¿el control sobre un servidor VPN debe considerarse únicamente como una puerta de enlace a la red?
Queríamos analizar qué más se podría hacer.
La siguiente entrada del blog explora las técnicas posteriores a la explotación de la VPN que pueden utilizar los atacantes que ya han vulnerado un servidor VPN por otros medios (vulnerabilidades, credenciales robadas, etc.) para lograr objetivos adicionales.
Uso de la VPN
El enfoque principal que utilizan los atacantes para llevar a cabo las técnicas posteriores a la explotación consiste en seleccionar el sistema operativo del dispositivo. Después de obtener la ejecución remota de código (RCE), un atacante puede descartar una implantación personalizada en el sistema operativo del dispositivo. A partir de este punto, el atacante puede controlar todos los aspectos de la VPN; por ejemplo, puede enlazar funciones para filtrar información confidencial, intentar evadir la detección mediante la manipulación de registros o modificar la configuración del sistema para mantener la persistencia en el dispositivo.
Aunque este enfoque tiene muchas ventajas, tiene un inconveniente principal: es caro. Dado que los dispositivos suelen ejecutarse en un sistema operativo reforzado personalizado, el esfuerzo que se necesita para desarrollar y mantener una implantación personalizada para un dispositivo VPN puede ser considerable. Esto significa que las técnicas posteriores a la explotación de la VPN normalmente solo las utilizaban los atacantes de Estados nación de primer nivel.
Exploración de un enfoque diferente
Decidimos explorar un enfoque diferente, una forma "más sencilla" de explotación posterior de la VPN. En lugar de depender de una implantación personalizada que se ejecuta en el sistema operativo, decidimos explotar la funcionalidad existente del dispositivo. Nos preguntamos lo siguiente: ¿qué puede lograr un atacante utilizando únicamente la interfaz de gestión de VPN?
Este enfoque, que denominamos el "uso de la VPN", tiene al menos dos ventajas.
Este tipo de acceso puede ser más fácil de obtener que la RCE completa: el acceso a la interfaz de gestión se puede obtener a través de una vulnerabilidad de omisión de autenticación, credenciales pocas seguras o el phishing.
Este enfoque puede resultar más rentable, ya que nos ahorramos el esfuerzo de desarrollar una carga útil personalizada.
Como sujetos de prueba, decidimos centrarnos en dos de los principales servidores VPN del mercado: Ivanti Connect Secure y FortiGate. Descubrimos 2 CVE y un conjunto de técnicas de no corrección que pueden utilizar los atacantes que controlan el servidor VPN para apropiarse de otros activos críticos de la red, lo que puede convertir potencialmente la vulneración de la VPN en una vulneración de toda la red.
Aunque nuestros resultados se centran en FortiGate e Ivanti, creemos que las variaciones de las técnicas que hemos detectado probablemente sean relevantes para servidores VPN y dispositivos del Edge adicionales.
Explotación de los servidores de autenticación remotos
Algunos de los activos más interesantes que gestiona un servidor VPN son las credenciales externas. Aunque los servidores VPN admiten el uso de usuarios locales para la autenticación, en muchos casos se utiliza un servidor de autenticación externo.
En lugar de mantener un conjunto independiente de credenciales por usuario, los administradores pueden optar por utilizar un proveedor de identidad existente para autenticar a sus usuarios. El usuario envía sus credenciales "normales" al servidor VPN, que se validan a través del servidor de autenticación remoto (Figura 1).
Fig. 1: Uso de un servidor de autenticación remoto para autenticar a los usuarios
Se pueden usar diferentes tipos de servidores de autenticación para esto, y las dos opciones principales son el protocolo LDAP y RADIUS.
Hemos identificado algunas técnicas que pueden permitir a los atacantes aprovechar este comportamiento para vulnerar estas credenciales externas, y que podrían proporcionar a los atacantes acceso a recursos adicionales de la red.
Interceptación de credenciales de LDAP
Una opción de servidor de autenticación muy popular para la VPN es el protocolo LDAP, que suele ser un controlador de dominio de Active Directory (AD). Con esta configuración, los usuarios pueden acceder a la VPN a través de sus credenciales de dominio, lo que la convierte en una opción muy cómoda.
Al configurar un servidor de autenticación de LDAP, se proporcionan las credenciales de una cuenta de servicio de AD para permitir que la VPN consulte la información del usuario. En la Figura 2 se puede ver un ejemplo de esta configuración en FortiGate.
Fig. 2: Configuración del servidor de autenticación de LDAP en la interfaz gráfica de usuario (GUI) de FortiGate
Cuando un usuario intenta autenticarse en FortiGate o Ivanti con sus credenciales de LDAP, la VPN verificará su identidad poniéndose en contacto con el servidor LDAP. La implementación exacta varía ligeramente entre los dos, así que vamos a examinar ambos.
Autenticación de LDAP de FortiGate
Para validar las credenciales, FortiGate intenta utilizarlas para autenticarse en el servidor remoto. Este proceso se lleva a cabo mediante una autenticación sencilla , lo que significa que FortiGate envía la contraseña al servidor en texto no cifrado (Figura 3).
Fig. 3: El enlace simple de LDAP expone la contraseña de usuario en texto no cifrado
Durante este proceso se transmiten dos conjuntos de credenciales: las credenciales de la cuenta de servicio LDAP configurada en FortiGate y las credenciales proporcionadas por el usuario que realiza la autenticación. Ambas se envían en texto no cifrado.
Aunque la configuración predeterminada es LDAP, FortiGate también admite LDAPS y TLS, lo que debería evitar la comunicación en texto no cifrado.
Autenticación de LDAP de Ivanti
La implementación de Ivanti para la autenticación de LDAP es ligeramente diferente y admite dos tipos de servidores de autenticación de LDAP: LDAP normal y Active Directory (Figura 4).
Fig. 4: Opciones de servidor de autenticación Ivanti, incluidos los servidores LDAP y Active Directory
Servidor de autenticación de LDAP
Con un servidor de autenticación de LDAP, el proceso es bastante similar al proceso de FortiGate; es decir, cuando se utiliza LDAP simple, se realiza un enlace simple y las credenciales de la cuenta de servicio de AD y las credenciales de autenticación del usuario se transmiten en texto no cifrado (Figura 5).
Fig. 5: Ivanti transmite credenciales de LDAP en texto no cifrado
Sin embargo, al configurar un servidor de autenticación de LDAP, la configuración predeterminada es TLS y también se admite LDAPS. Por lo tanto, es menos probable que las instancias de Ivanti utilicen LDAP simple.
Servidor de autenticación de AD
El segundo tipo de servidor de autenticación de LDAP que se puede configurar es un servidor de AD. Cuando se utiliza esta opción, la autenticación se realiza mediante Kerberos, lo que significa que no se transmiten contraseñas (Figura 6).
Fig. 6: Autenticación de LDAP segura mediante Kerberos
Captura de credenciales de LDAP en texto no cifrado
Tanto para FortiGate como para Ivanti, cuando se utiliza LDAP simple para autenticar un usuario, cualquier credencial enviada a la VPN puede vulnerarse. Esta vulneración la puede llevar a cabo un atacante que se encuentre entre la VPN y el servidor LDAP, o un atacante que controle el servidor VPN.
¿Cómo podemos capturar las credenciales sin colocar una implantación en el dispositivo? Afortunadamente, tanto FortiGate como Ivanti tienen una función de captura de paquetes integrada. Al utilizarla para capturar paquetes LDAP, un atacante puede interceptar todas las credenciales que pasan por la VPN (Figura 7).
Fig. 7: Uso de la función de captura de paquetes de FortiGate o Ivanti para capturar comunicaciones LDAP
En aquellos casos donde se emplea un protocolo seguro, no se transmiten credenciales en texto no cifrado desde el servidor. A pesar de ello, un atacante con control sobre la VPN puede capturarlos de forma trivial. Si controlamos la VPN, no hay nada que nos impida modificar la configuración y degradarla nuevamente a LDAP simple.
Para los servidores LDAP normales, simplemente podemos cambiar la configuración a LDAP simple. Para degradar el servidor de AD de Ivanti, podemos utilizar los detalles de conexión de AD para configurar un nuevo servidor LDAP normal en lugar del existente. En ambos casos, este cambio debería ser transparente para los usuarios y hará que la VPN envíe las contraseñas en texto no cifrado.
La conclusión es la siguiente: si se utiliza la autenticación de LDAP, independientemente de la configuración, un atacante que vulnere la VPN podrá obtener credenciales fácilmente y pasar al dominio.
Registro de un servidor de autenticación no autorizado
Como hemos mencionado, al autenticar un usuario remoto, la VPN se pondrá en contacto con el servidor de autenticación adecuado para validar las credenciales proporcionadas. Hemos identificado un método que explota este flujo de autenticación para vulnerar cualquier credencial proporcionada por un usuario a la VPN.
Esta técnica funciona registrando un servidor de autenticación no autorizado que la VPN utilizará al autenticar a los usuarios. Para ayudarle a comprender cómo se puede implementar esto, primero describiremos algunos detalles del proceso de autenticación en ambas VPN.
Grupos de usuarios de FortiGate
A los usuarios de FortiGate se les pueden otorgar diferentes permisos y se les pueden aplicar diferentes políticas. En lugar de gestionar cada usuario individualmente, los usuarios se pueden incluir en grupos de usuarios, es decir, conjuntos de usuarios a los que se les pueden aplicar políticas y permisos.
Al configurar un grupo de este tipo, podemos incluir usuarios de grupos remotos, es decir, grupos que están presentes en un servidor de autenticación remoto. Por ejemplo, podemos incluir usuarios de un grupo de AD específico (Figura 8).
Fig. 8: Configuración del grupo de usuarios de FortiGate
Observamos un comportamiento interesante que se produce cuando se utilizan grupos remotos. Supongamos que configuramos un grupo de usuarios que incluye dos entidades: un usuario FortiGate local y un grupo remoto presente en un servidor LDAP.
Con respecto a la autenticación, cabe esperar el siguiente comportamiento:
Cuando el miembro local del grupo se autentica en FortiGate, sus credenciales se verificarán mediante la base de datos de usuarios local de FortiGate.
Cuando un miembro del grupo remoto se autentica en FortiGate, sus credenciales se verificarán mediante el servidor LDAP del grupo remoto.
Sin embargo, resulta que no es así. Después de añadir un grupo remoto a un grupo de usuarios, siempre que cualquier miembro del grupo de usuarios se autentica, FortiGate intentará validar sus credenciales mediante la base de datos de usuarios local y el servidor de autenticación remoto. Además, si añadimos más de un servidor remoto a un grupo de usuarios, FortiGate intentará autenticar a los usuarios mediante todos los servidores de autenticación configurados.
Básicamente, FortiGate no asocia un usuario específico con su método de autenticación adecuado, sino que simplemente prueba con todos. Si alguno de ellos tiene éxito, el usuario se autentica.
Dominios de autenticación de Ivanti
Ivanti implementa una función similar para los grupos de usuarios denominados dominios de autenticación. A diferencia de los grupos de usuarios de FortiGate, cada dominio de autenticación de Ivanti está limitado a un único servidor de autenticación. Para gestionar usuarios desde distintos servidores, se deben utilizar dominios independientes.
A pesar de esta restricción (y oportunamente para nosotros), Ivanti nos permite configurar un "servidor de autenticación adicional" (Figura 9). Esta opción está diseñada para habilitar determinadas configuraciones de inicio de sesión único (SSO).
Fig. 9: Configuración de un servidor de autenticación adicional para un dominio de usuarios de Ivanti
Cuando se configura un servidor de autenticación adicional, Ivanti intentará validar las credenciales utilizando ambos servidores. La autenticación solo se realizará correctamente si ambos servidores la aprueban.
Creación de un servidor de autenticación no autorizado para filtrar las credenciales
Un atacante puede explotar estos comportamientos para filtrar las credenciales de cualquier usuario que se autentique en FortiGate o Ivanti con cualquier tipo de servidor de autenticación remoto. Al añadir un servidor de autenticación no autorizado a un grupo o dominio de usuarios, podemos hacer que el servidor VPN filtre las credenciales a un servidor controlado por un atacante (Figura 10).
Fig. 10: Adición de un servidor de autenticación no autorizado para vulnerar las credenciales del cliente
Estas credenciales pueden ser de clientes que se conectan a la VPN o de administradores que se conectan a la interfaz de gestión. Cualquier autenticación que se gestione mediante un grupo o dominio de usuarios podría secuestrarse mediante este método.
Para implementar esto en FortiGate, creamos un grupo remoto que utiliza nuestro servidor no autorizado y, a continuación, lo añadimos a nuestro grupo de usuarios de destino. Con Ivanti, simplemente añadimos nuestro servidor no autorizado como servidor de autenticación adicional para nuestro dominio de destino.
Ahora, cada vez que un miembro del grupo/dominio de usuarios de destino se autentique, la VPN intentará validar sus credenciales mediante nuestro servidor (Figura 11).
Fig. 11: Adición de un servidor de autenticación RADIUS no autorizado a un grupo de usuarios
Para capturar las credenciales, utilizaremos un servidor de autenticación RADIUS. La autenticación RADIUS es oportuna en este escenario por dos motivos:
Las credenciales se envían al servidor durante la solicitud inicial sin verificar primero si el usuario existe en el servidor.
Las credenciales se envían al servidor cifradas con una clave determinada por el atacante, lo que les permite recuperar las credenciales en texto no cifrado (Figura 12).
Fig. 12: Una contraseña cifrada en un mensaje de autenticación RADIUS
El siguiente script (basado en RFC 2865) puede descifrar contraseñas RADIUS:
import hashlib
# Authenticator value can be obtained from the PCAP
authenticator = bytearray.fromhex("98f245b6e3724f5873fa74e576323c67")
enc = bytearray.fromhex("15644ca055b817ce683083fecebc2902016f2890660d0dfcaee214a0dbaa1046")
# Pre-shared key configured by the attacker when setting up the rogue server
secret = bytes("verygoodpsk", "utf-8")
chunk_len = 16
enc_chunks = []
dec = ""
for i in range(0, len(enc), chunk_len):
enc_chunks.append(enc[i:i+chunk_len])
for chunk in enc_chunks:
dec_chunk = b""
chunk_key = hashlib.md5(secret + authenticator ).digest()
i = 0
for enc_byte in chunk:
dec_chunk += (enc_byte ^ chunk_key[i]).to_bytes(1,"big")
dec += chr(enc_byte ^ chunk_key[i])
i+=1
authenticator = chunk
print(dec)
Un apunte final: como hemos mencionado, cuando Ivanti utiliza un servidor de autenticación adicional, ambos servidores deben aprobar al usuario para que la autenticación se realice correctamente. Si nuestro servidor no aprueba las credenciales proporcionadas, los usuarios no podrán autenticarse en Ivanti. Para evitarlo, debemos asegurarnos de que nuestro servidor RADIUS aprueba todas las credenciales que se le proporcionan, lo cual se puede configurar fácilmente.
Extracción de los secretos del archivo de configuración
Es probable que nuestro hallazgo más preocupante esté relacionado con los archivos de configuración de la VPN.
Entre los diversos ajustes interesantes que podemos localizar en los archivos de configuración, hay uno que destaca entre ellos: los secretos. Las VPN almacenan muchos secretos en su configuración: contraseñas de usuario locales, claves SSH, certificados y, lo que es más interesante, credenciales de cuentas de servicios de terceros.
Un atacante puede obtener estos archivos confidenciales de dos formas principales:
Después de obtener el control de una VPN, un atacante puede exportar la configuración del dispositivo a través de la interfaz de gestión.
Un atacante puede localizar un archivo de configuración exportado previamente que se guardó en una ubicación pública, como una carpeta compartida.
Para protegerlos, los secretos se almacenan en el archivo de configuración de forma cifrada. La Figura 13 muestra un ejemplo de un secreto cifrado en un archivo de configuración de FortiGate.
Fig. 13: Una contraseña cifrada dentro de un archivo de configuración de FortiGate
A continuación vamos a descifrar algunos secretos.
Descifrado de secretos de un archivo de configuración de FortiGate
Se podría pensar que los secretos están protegidos mediante hash y, por lo tanto, no se pueden recuperar, pero puede que no sea realmente el caso. Tomemos como ejemplo las contraseñas de integración: dado que la contraseña en texto no cifrado es necesaria para conectarse a un tercero, se debe almacenar mediante cifrado reversible.
Esto se demostró en una entrada del blog de Bart Dopheide, quien investigó a fondo el proceso de cifrado de contraseñas de FortiGate. FortiGate utiliza AES para cifrar todos los secretos de la configuración. ¿Qué clave se utiliza para realizar este cifrado? Dopheide descubrió que se utiliza una sola clave integrada como parte del código en todos los dispositivos FortiGate. Esta clave no se podía cambiar. La entrada original del blog no la comparte, pero con una búsqueda rápida en Google descubrirá directamente cuál es.
Fortinet asignó la CVE 2019–6693 a este problema e implementó una corrección permitiendo a los usuarios cambiar la tecla integrada como parte del código por una personalizada.
Incluso después de esta corrección, el problema sigue siendo muy relevante hoy en día. La clave no se cambió, por lo tanto, de forma predeterminada, los dispositivos FortiGate siguen utilizando la misma clave. Esto significa que si un atacante obtiene un archivo de configuración de un dispositivo FortiGate con la configuración predeterminada, podrá descifrar todos los secretos almacenados en el dispositivo. Este código implementa el proceso de descifrado.
De acuerdo, pero ¿qué pasa si el administrador de FortiGate sigue la práctica recomendada y utiliza una clave personalizada en lugar de la predeterminada? Descubrimos que si controlamos la VPN, todavía podemos obtener fácilmente los secretos.
La configuración private-data-encryption se utiliza para controlar la clave de cifrado personalizada. Lo sorprendente es que los administradores pueden simplemente desactivar esta función. Esto no requiere saber cuál es la clave integrada como parte del código actualmente, y revertirá el cifrado de todos los secretos a la clave integrada como parte del código original.
Reversión del cifrado
Para revertir el cifrado, podemos utilizar los siguientes comandos de la interfaz de línea de comandos de FortiGate:
FGT # config system global
FGT (global) # set private-data-encryption disable
FGT (global) # end
En este punto, podemos descargar el archivo de configuración y descifrar los secretos utilizando la clave predeterminada conocida (exactamente como mostramos antes).
Con este método se pueden vulnerar muchos secretos interesantes. FortiGate admite integraciones con varias aplicaciones a través de la función de "conector externo". Estos conectores tienen diferentes propósitos, pero la mayoría de ellos comparten una característica importante: necesitan credenciales para la aplicación (Figura 14).
Fig. 14: Opciones de conector externo de FortiGate
Esto significa que FortiGate puede contener credenciales para servicios esenciales como proveedores de nube, SAP, Kubernetes, ESXi y muchos más.
En algunos casos, las credenciales requieren privilegios elevados para la aplicación correspondiente. Por ejemplo, la integración de "Poll Active Directory Server" requiere las credenciales de una cuenta con acceso administrativo a un controlador de dominio, posiblemente convirtiendo una filtración de FortiGate en una vulneración de todo el dominio inmediatamente.
Descifrado de secretos de un archivo de configuración de Ivanti
En el caso de Ivanti, la situación es bastante similar. De hecho, puede ser peor.
Ivanti también almacena secretos mediante cifrado reversible. Si extraemos el código del dispositivo y profundizamos en él, encontraremos rápidamente el valor secreto que se utiliza como clave de cifrado, que es (de nuevo) una cadena estática (Figura 15).
Fig. 15: Clave de cifrado estática de Ivanti
Hemos redactado la clave completa, pero al inspeccionar el principio de la misma, podemos suponer que probablemente no haya cambiado desde al menos 2015, cuando Juniper era propietario de Connect Secure.
Parece que Ivanti ha invertido un mayor esfuerzo en proteger los secretos almacenados con la implementación de un algoritmo de cifrado más complejo que FortiGate. A pesar de ello, este proceso obviamente sigue siendo reversible. Esto significa que los secretos de todas las instancias de Ivanti se cifran mediante una clave estática que no se puede cambiar. Los atacantes podrían utilizar este conocimiento para descifrar cualquier archivo de configuración de Ivanti.
Descifrado de las contraseñas por parte de Ivanti para nosotros
Nuestro enfoque inicial era aplicar ingeniería inversa al proceso de cifrado para crear un descifrado. Sin duda, esto es posible, pero después de varias horas examinando el código descompilado, decidimos adoptar un enfoque diferente como prueba de concepto. Dejamos el trabajo duro a Ivanti.
La idea principal es utilizar una instancia dedicada de Ivanti propiedad del atacante, "alimentarla" con la contraseña cifrada y que nos la descifre para nosotros (Figura 16).
Fig. 16: El proceso de descifrado de una contraseña de Ivanti en un entorno de laboratorio del atacante
Este descifrado se puede realizar mediante los siguientes pasos:
Obtener una contraseña cifrada de un archivo de configuración de Ivanti.
En un entorno de laboratorio, configurar una instancia de Ivanti y un servidor LDAP (por ejemplo, un servidor Windows que ejecute Active Directory).
En la instancia de Ivanti del laboratorio, configurar nuestro servidor LDAP como un servidor de autenticación que utilice autenticación simple.
Exportar la configuración de Ivanti del laboratorio a un archivo.
Sustituir la contraseña LDAP cifrada existente en el archivo de configuración por la contraseña cifrada que estamos intentando descifrar.
Volver a importar el archivo de configuración modificado a la instancia de Ivanti.
Ahora, cuando activamos un intento de autenticación en el servidor LDAP, Ivanti descifrará la contraseña de la configuración y la enviará en texto no cifrado al servidor LDAP. Al capturar los paquetes, podemos obtener la contraseña descifrada (Figura 17).
Fig. 17: Ivanti descifra nuestra contraseña suministrada y filtra el resultado a través de LDAP
Utilizamos la autenticación del servidor LDAP como una "interfaz" con el proceso de descifrado, pero es importante tener en cuenta que no estamos limitados a las contraseñas LDAP. Nuestras pruebas demostraron que esta técnica funcionará para todos los secretos almacenados en el archivo de configuración, incluidas, entre otras, las contraseñas de AD, las claves de RADIUS compartidas previamente y las claves de API.
Contraseñas de servidor de MDM en texto no cifrado
Ivanti es compatible con varios servidores de gestión de dispositivos móviles (MDM) populares como métodos de autenticación (Figura 18).
Fig. 18: Configuración del servidor de MDM de Ivanti
Al igual que otros servidores de autenticación, esta integración requiere credenciales para el servidor de MDM. Si inspeccionamos la configuración del servidor de MDM, encontraremos dos campos interesantes: "password-encrypted" y "password-cleartext". Y aunque los nombres puedan sugerir lo contrario, ambos campos están almacenados en texto no cifrado (Figura 19). ♂️
Fig. 19: Configuración de MDM de Ivanti que contiene contraseñas en texto no cifrado
Técnicas posteriores a la explotación de la VPN en el mundo real
Es probable que algunas de las técnicas que hemos mencionado en esta publicación ya se estén utilizando en el mundo real. En su informe Cutting Edge , los investigadores de Mandiant, que cubrían una serie de campañas de explotación contra dispositivos Ivanti, comentaron que los atacantes podían vulnerar la cuenta de servicio LDAP configurada en el dispositivo Ivanti (Figura 20).
Fig. 20: El informe de Mandiant menciona una cuenta LDAP vulnerada
Aunque el informe de Mandiant no entra en detalles sobre cómo los atacantes pudieron lograrlo, creemos que es muy probable que los atacantes hayan logrado obtener las credenciales utilizando alguno de los métodos que hemos mencionado en este blog, es decir, extrayéndolas del archivo de configuración o mediante de la captura de datos del tráfico de red.
Estos tipos de técnicas son muy fáciles de implementar y creemos que los atacantes de todos los niveles de sofisticación podrán utilizarlas.
Recomendaciones al utilizar un servidor VPN
Recomendamos cuatro principios que se deben seguir al utilizar un servidor VPN para minimizar los riesgos de las técnicas que acabamos de mencionar:
Utilizar el acceso de red Zero Trust
Limitar los permisos de la cuenta de servicio
Utilizar identidades dedicadas para la autenticación VPN
Supervisar los cambios de configuración
1. Utilizar el acceso de red Zero Trust
Uno de los principales problemas de las VPN tradicionales es su enfoque de "todo o nada" al conceder acceso a la red: los usuarios están "dentro" (y tienen acceso completo a la red) o están "fuera" (y no pueden acceder a nada).
Ambas opciones son problemáticas. Por un lado, debemos proporcionar a los usuarios acceso remoto a las aplicaciones internas. Por otro lado, no queremos que un atacante obtenga acceso completo a la red si vulnerara un servidor VPN.
El acceso de red Zero Trust (ZTNA) ofrece una solución. Al definir políticas de acceso a la red por entidades, podemos permitir que los usuarios realicen operaciones remotas aprobadas, a la vez que reducimos el impacto de una posible filtración.
Akamai Enterprise Application Access es una solución ZTNA que ofrece un acceso preciso, basado en la identidad y el contexto, a las aplicaciones privadas. Utiliza políticas basadas en identidades y datos en tiempo real, como la ubicación de los usuarios, la hora y la seguridad de los dispositivos, para garantizar que los usuarios solo tengan acceso a las aplicaciones que necesitan y eliminar el acceso a nivel de red. Funciona a la perfección con Akamai MFA para proporcionar una autenticación de usuario sólida.
2. Limitar los permisos de la cuenta de servicio
Como hemos ilustrado en esta publicación, es muy fácil recuperar las contraseñas en texto no cifrado de las cuentas de servicio almacenadas en servidores VPN. En realidad no hay forma de evitarlo, ya que las VPN requieren el uso de contraseñas en texto no cifrado en algunos casos.
Para reducir el impacto de una posible vulneración de la VPN, recomendamos el uso de cuentas de servicio con un conjunto limitado de permisos, preferiblemente de solo lectura. Los defensores deben tratar de comprender cómo un atacante podría aprovechar las credenciales almacenadas en la VPN y asegurarse de que una VPN vulnerada no ocasione la vulneración de otros activos críticos.
Algunas integraciones requieren una cuenta de servicio con permisos sólidos para su funcionamiento. Si es posible, deben evitarse.
3. Utilizar identidades dedicadas para la autenticación VPN
Ahora sabemos que es muy fácil para un atacante con control sobre la VPN vulnerar las credenciales de autenticación de usuarios de VPN. Aunque puede resultar tentador utilizar los servicios de autenticación existentes, como AD, para autenticar a los usuarios en la VPN, le recomendamos que evite hacerlo. Los atacantes con control sobre la VPN podrán obtener las credenciales y utilizarlas para pasar a los activos internos, convirtiendo la VPN en un único punto de fallo.
En su lugar, se recomienda utilizar una forma independiente y dedicada de autenticar a los usuarios en la VPN. Por ejemplo, realice una autenticación basada en certificados utilizando certificados emitidos específicamente para este fin.
4. Supervisar los cambios de configuración
Todas las técnicas que hemos mencionado se reflejarán en la configuración del dispositivo de una forma u otra. Dado que la configuración del dispositivo de red no tiende a cambiar con frecuencia, estos cambios pueden proporcionar una oportunidad de detección significativa.
Para identificar los cambios de configuración, recomendamos extraer periódicamente la configuración del dispositivo y compararla con una "imagen dorada". La mayoría de los dispositivos también incluyen capacidades de registro internas para eventos relacionados con el sistema y la seguridad. Le recomendamos que recopile y analice todos los registros disponibles, y los utilice para identificar cambios sospechosos en la configuración del dispositivo.
Estos cuatro principios se reducen a lo siguiente: no confíe ciegamente en su VPN.
Resumen
Los atacantes están deseando acceder a su VPN. Es un hecho. Los defensores deben asumir que es solo cuestión de tiempo que un atacante obtenga acceso a su VPN, y deben actuar en consecuencia ahora. Los defensores deben asegurarse de que una VPN vulnerada no pueda dar lugar a una red totalmente vulnerada.
Tiempo de divulgación
Ivanti
26.03.2024: Informe inicial al proveedor.
05.04.2024: Ivanti reconoce el informe y confirma que está trabajando en una solución.
03.06.2024: Notificación inicial a Ivanti para indicarles que planeamos publicar la investigación el 7 de agosto.
27.06.2024: Ivanti afirma que está trabajando en una solución, pero no puede confirmar que los problemas se solucionarán antes de la fecha de publicación.
08.07.2024: Ivanti asigna las CVE-2024-37374 y CVE-2024-37375 al problema de la clave integrada como parte del código, y las contraseñas en texto no cifrado de MDM, pero aún no ha publicado un parche.
15.07.2024: Aviso adicional a Ivanti sobre el programa de lanzamiento previsto.
07.08.2024: La investigación se publica.
Fortinet
22.03.2024: Informe inicial al proveedor.
17.04.2024: Respuesta inicial de Fortinet, en la que concluye que ninguno de los problemas descritos requiere una corrección.
21.04.2024: Notificación inicial a Fortinet para indicarles que planeamos publicar la investigación el 7 de agosto.
30.04.2024: Fortinet nos informa de que tienen la intención de corregir la omisión de la clave de cifrado personalizada que describimos.
15.07.2024: Aviso adicional a Fortinet sobre el programa de lanzamiento previsto.
23.07.2024: Fortinet indica que probablemente no podrán publicar el parche antes de la fecha de publicación.
02.08.2024: Fortinet nos informa de que, tras una consideración adicional, decidieron no corregir la omisión de la clave de cifrado personalizada, ya que "no cruza ningún límite de seguridad".
07.08.2024: La investigación se publica.