Log4j2 es un marco de trabajo de logging open source incorporado en muchas aplicaciones basadas en Java tanto en servidores como sistemas de usuario final. A fines de noviembre de 2021, Chen Zhaojun de Alibaba identificó una vulnerabilidad de ejecución remota de código, que finalmente se reportó con el Id. de CVE: CVE-2021-44228, que se hizo público el 10 de diciembre de 2021. La explotación de la vulnerabilidad se realiza a través de la deserialización indebida de la entrada del usuario que se pasa al marco de trabajo. Permite la ejecución remota de código y puede permitir a un atacante filtrar datos confidenciales, como variables del entorno, o ejecutar software malicioso en el sistema objetivo.
La vulnerabilidad identificada afecta todas las versiones de Log4j2, desde la versión 2.0-beta9 hasta la versión 2.14.1. Los primeros métodos para aplicar un parche a este problema originaron varias candidatas a versiones, lo que culminó en la recomendación de actualizar el marco de trabajo a Log4j2 2.15.0-rc2 al momento de este blog.
Dada la complejidad trivial y la naturaleza de la explotación extendida observada, la mitigación debería considerarse crítica en cualquier entorno con software identificado que aproveche las versiones vulnerables de Log4j2.
Detectar la explotación de Log4Shell en Elastic Security
Los usuarios de Elastic Security pueden usar la regla de detección de correlación de eventos para identificar la explotación activa de la vulnerabilidad de log4j2. Según el formato de los datos de eventos basados en el host, es posible que debas modificar esta detección para que coincida con tus campos de datos.
Regla de detección si usas datos de Endpoint
sequence by host.id with maxspan=1m
[network where event.action == "connection_attempted" and
process.name : "java" and
/*
outbound connection attempt to
LDAP, RMI or DNS standard ports
by JAVA process
*/
destination.port in (1389, 389, 1099, 53, 5353)] by process.pid
[process where event.type == "start" and
/* Suspicious JAVA child process */
process.parent.name : "java" and
process.name : ("sh",
"bash",
"dash",
"ksh",
"tcsh",
"zsh",
"curl",
"perl*",
"python*",
"ruby*",
"php*",
"wget")] by process.parent.pid
Regla de detección si usas datos de Auditbeat
sequence by agent.id with maxspan=1m
[network where event.action == "connected-to" and
process.name : "java" and
/*
outbound connection attempt to
LDAP, RMI or DNS standard ports
by JAVA process
*/
destination.port in (1389, 389, 1099, 53, 5353)] by process.pid
[process where event.type == "start" and
/* Suspicious JAVA child process */
process.parent.name : "java" and
process.name : ("sh",
"bash",
"dash",
"ksh",
"tcsh",
"zsh",
"curl",
"perl*",
"python*",
"ruby*",
"php*",
"wget")] by process.parent.pid
Regla de detección si usas eventos transmitidos de Endgame
sequence by agent.id with maxspan=1m
[network where event.category == "network" and
process.name : "java" and
/*
outbound connection attempt to
LDAP, RMI or DNS standard ports
by JAVA process
*/
destination.port in (1389, 389, 1099, 53, 5353)] by process.pid
[process where event.type == "start" and
/* Suspicious JAVA child process */
process.parent.name : "java" and
process.name : ("sh",
"bash",
"dash",
"ksh",
"tcsh",
"zsh",
"curl",
"perl*",
"python*",
"ruby*",
"php*",
"wget")] by process.parent.pid
Esta regla de detección busca una secuencia de un intento de conexión saliente a puertos estándares para LDAP, RMI y DNS (que suelen ser el objetivo de los ataques por inyección de JAVA/JNDI observados recientemente) seguido por un proceso secundario de la misma instancia de proceso de Java.
Ahora, veamos cómo esta regla detecta la explotación de la vulnerabilidad de log42j:
En la captura de pantalla anterior se muestra a un atacante que está explotando la vulnerabilidad con una carga codificada en Base 64, cuyo objetivo es una aplicación vulnerable de ejemplo que creó Christophe Tafani-Dereeper.
En esta captura de pantalla se muestra la detección de la explotación activa de CVE-2021-44228 dentro de Elastic Security y se detallan tanto la vista de la alerta como de la línea de tiempo de la explotación.
En la captura de pantalla anterior se muestra que en la investigación de la alerta de detección Java ejecutó un script de shell para descargar y ejecutar un script de bash.
Detecciones de la comunidad
Varios miembros de la comunidad que debatieron sobre la explotación extendida de la vulnerabilidad proporcionaron información sobre diversos métodos de detección temprana que los analistas pueden aprovechar para identificar si los sistemas que usan fueron explotados o se encuentran en explotación activa:
-
El equipo de GreyNoise compartió una serie de cargas, incluidas aquellas con variantes codificadas y decodificadas para los analistas que buscan explorar los logs almacenados en sus sistemas. Esto se complementó con una lista de IP etiquetadas iniciales que intentaron la explotación de la vulnerabilidad.
-
Florian Roth de Nextron Systems proporcionó una serie de comprobaciones para la explotación local mediante grep/zgrep, junto con algunas firmas YARA iniciales en un Gist incluido en su cuenta de Github. Florian también compartió un método para generar Thinkst CanaryTokens con el objetivo de probar sistemas que puedes gestionar con relación a la explotabilidad.
-
Rob Fuller (Mubix) compartió una lista de hashes de archivos conocidos sobre versiones vulnerables del marco de trabajo, aquí.
Estrategias de mitigación adicionales
Fuera de la orientación que recomienda el equipo de Apache en cuanto al despliegue de las versiones con parches más recientes del marco de trabajo de Log4j2 para actualizar, se sugirieron varias mitigaciones para evitar la explotación:
-
Fastly sugirió comprobar si tu versión de Log4j soporta la ejecución de JVM con JAVA_OPTS=-Dlog4j2.formatMsgNoLookups=true para deshabilitar la funcionalidad de búsqueda en el servidor remoto. Esto debería aplicar a las versiones 2.10.0 a 2.15.0.
-
Para evitar el movimiento lateral desde un host vulnerable, o la explotación a través de la red, se recomienda limitar la conectividad de los sistemas potencialmente vulnerables a los recursos externos solamente a aplicaciones o servicios de confianza.
Gracias, de Elastic Security.
Queremos agradecerles a todos los equipos de seguridad del mundo por su labor incansable hoy y durante el fin de semana, en especial a aquellos nombrados en esta publicación. La apertura y la colaboración en la comunidad de seguridad para proteger a todos los usuarios es primordial al hacer frente a una vulnerabilidad tan seria y generalizada. Queremos que sepas que estamos aquí para acompañarte en cada paso del camino.
Elastic Security, en su versión existente, puede acceder a estas capacidades dentro del producto. Si eres nuevo en Elastic Security, echa un vistazo a nuestras guías de inicio rápido (videos de capacitación breves para que puedas dar los primeros pasos rápido) o nuestros cursos de capacitación gratuitos sobre conceptos básicos. Siempre puedes comenzar con una prueba gratuita de 14 días de Elastic Cloud. O descarga la versión autogestionada del Elastic Stack de forma gratuita.