Esta semana, Apache Software Foundation emitió un nuevo conjunto de parches con el fin de abordar las fallas de ejecución remota de código (RCE) en Log4j, las cuales podrían ser explotadas por actores de amenazas para comprometer los sistemas vulnerables. Identificada como CVE-2021-44832, esta falla recibió un puntaje de 6.6/10 en la escala del Common Vulnerability Scoring System (CVSS) y reside en todas las versiones de Log4j desde 2.0-alpha7.
Según el reporte, estas versiones son vulnerables a la ejecución remota de código cuando un atacante con permisos para modificar el archivo de configuración de registro puede construir una configuración empleando un Appender JDBC con una fuente de datos haciendo referencia a un UEI JNDI capaz de ejecutar código remoto.

Como se realiza el ataque log4shell
Top 20 de países con mayores intentos de ataques aprovechando la vulnerabilidad (Fuente ESET)

Aunque Apache no acreditó a nadie el reporte, el investigador Yaniv Nizry asegura haber presentado este informe: “Esta es una vulnerabilidad más compleja que la original CVE-2021-44228, pues requiere que los actores de amenazas tengan control sobre la configuración. A diferencia de Logback, en Log4j hay una función para cargar un archivo de configuración remota, por lo que se podría ejecutar código arbitrario mediante un ataque Man-in-The-Middle (MitM)“, señala el experto.
La publicación de estos parches significa la quinta ocasión en que se aborda un problema de seguridad en Log4j desde el hallazgo de la peligrosa vulnerabilidad Log4Shell. Las fallas corregidas hasta el momento son:

  • CVE-2021-44228: Error de ejecución remota de código que afecta a las versiones de Log4j de 2.0-beta9 a 2.14.1.
  • CVE-2021-45046: Vulnerabilidad de filtración de información y ejecución remota de código que afecta a las versiones
    de Log4j de 2.0-beta9 a 2.15.0.
  • CVE-2021-45105: Falla de denegación de servicio (DoS) que afecta a las versiones de Log4j de 2.0-beta9 a 2.16.0.
  • CVE-2021-4104: Error de deserialización no confiable que afecta a la versión 1.2 de Log4j.

Los problemas relacionados con Log4j no han hecho más que empeorar; hace un par de días, los gobiernos de Estados Unidos, Reino Unido, Australia y Canadá emitieron una alerta conjunta sobre la explotación masiva de las vulnerabilidades
detectadas en esta biblioteca, por lo que el panorama luce poco alentador para los administradores de sistemas.

Flujo para identificación de aplicaciones vulnerables (Fuente CISA)

Conclusión
Las vulnerabilidades de Log4j han generado un impacto global significativo, similar al de anteriores amenazas importantes, como Wannacry, Heartbleed y Shellshock. Debido a su amplio despliegue, se espera que las secuelas de esta vulnerabilidad duren un tiempo considerable, esto debido a que muchas aplicaciones empresariales y servicios en la nube requieren ser actualizados y estos procesos suelen ser de complejidad media a alta. Si bien el mundo aún no ha visto
ningún evento masivo de entrega de malware (ransomware, gusanos), troyanos, backdoors, etc.) que aprovechen las vulnerabilidades de Log4j, se debe estar muy atento a los comunicados publicados por parte del fabricante y una posible
actualización a una versión que pueda mitigar dichas vulnerabilidades.

Recomendaciones
Se recomienda validar junto con fabricantes que sistemas de los utilizados puedan estar siendo vulnerables y la forma de ejecutar los parches correspondientes, mantener al día las firmas de IPS y/o Anti-Malware para que ayuden a
detectar tráfico o comportamientos relacionados, otras recomendaciones incluyen los siguientes pasos:

  • Desactivar el software que utilice esta librería.
  • Bloquear las búsquedas JNDI.
  • Desconectar temporalmente las infraestructuras afectadas.
  • Crear una red aislada para separar las infraestructuras afectadas del resto de la red de la entidad.
  • Desplegar un WAF para proteger a las infraestructuras afectadas.

Los siguientes scripts pueden ser usados para identificar y detectar posibles intentos de explotación de las vulnerabilidades relacionadas.

Linux:

  • Script para detección del uso de Log4j: sudo grep -r –include “*.jar” JndiLookup.class /
  • Detección posible explotación: sudo egrep -I -i -r ‘\$(\{|%7B)jndi:(ldap[s]?|rmi|dns|nis|iiop|corba|nds|http):/[^\n]+’ /var/log
  • Detección posible explotación: sudo find /var/log -name \*.gz -print0 | xargs -0 zgrep -E -i ‘\$(\{|%7B)jndi:(ldap[s]?|rmi|dns|nis|iiop|corba|nds|http):/[^\n]+

Windows:

  • Script para detección del uso de Log4j: findstr /s /i /c:”JndiLookup.class” C:\*.jar

Para más información puede consultar las siguientes fuentes asociadas a la noticia: