La primer PoC (Prueba de concepto) de la vulnerabilidad ya está disponible en el momento de escribir este artículo: https://github.com/tangxiaofeng7/apache-log4j-poc
Detalles de la vulnerabilidad Log4j Zero-Day RCE (CVE-2021-44228)
Según RedHat (fuente: https://access.redhat.com/security/cve/cve-2021-44228) está clasificado como 9,8 CVSSv3, que es casi tan malo como parece. Si se explota con éxito en su infraestructura, los atacantes podrán realizar un ataque RCE (ejecución remota de código) y comprometer el servidor afectado. Dada la relativa simplicidad del exploit, es probable que su equipo de respuesta a incidentes deba ocuparse de un ataque.
Hay varios informes de que la vulnerabilidad se está explotando activamente en la naturaleza y debe ser parcheada de inmediato, ya hay una versión parcheada de Log4j disponible: https://logging.apache.org/log4j/2.x/security.html
Recomendaciones y detección
Para comprobar si es probable que su aplicación se vea afectada, debe verificar:
Versión de Log4j: todas las versiones 2.x anteriores a 2.15.0 (lanzadas hoy, viernes 10 de diciembre de 2021) se ven afectadas
Versión de JVM, si es inferior a:
Java 6 - 6u212
Java 7 - 7u202
Java 8 - 8u192
Java 11 - 11.0.2
Si ambos son verdaderos, su versión de Log4j es anterior a 2.15.0 y su nivel de parche de versión de Java es más antiguo que el mencionado anteriormente, es casi seguro que se verá afectado. En este momento, es probable que su infraestructura de acceso a Internet ya se haya visto comprometida ya que esta vulnerabilidad se está explotando activamente, según este informe: https://www.cert.govt.nz/it-specialists/advisories/log4j-rce-0-day-actively-exploited
Tenga en cuenta que incluso si su aplicación no usa log4j directamente, su infraestructura circundante, como el servidor de aplicaciones, el servidor de cola de mensajes, el servidor de base de datos, los dispositivos de red pueden estar usando esa combinación de Java y la versión de log4j que lo exponen a esta vulnerabilidad.
Descripción: Apache Log4j2 <= 2.14.1 Las funciones JNDI utilizadas en la configuración, los mensajes de registro y los parámetros no protegen contra LDAP controlado por atacantes y otros puntos finales relacionados con JNDI. Un atacante que puede controlar mensajes de registro o parámetros de mensajes de registro puede ejecutar código arbitrario cargado desde servidores LDAP cuando la sustitución de búsqueda de mensajes está habilitada. Desde log4j 2.15.0, este comportamiento se ha desactivado de forma predeterminada.
Mitigación
Cyberpeace recomienda la siguiente mitigación y detección:
Mitigación: en las versiones > = 2.10, este comportamiento se puede mitigar configurando la propiedad del sistema log4j2.formatMsgNoLookups o la variable de entorno LOG4J_FORMAT_MSG_NO_LOOKUPS en verdadero.
Para las versiones de 2.0-beta9 a 2.10.0, la mitigación es:
Eliminar la clase JndiLookup de la ruta de clases: zip -q -d log4j-core - *. Jar org / apache / logging / log4j / core / lookup / JndiLookup.class
¿Utilizas Java 1.8 o superior?
Descargue la última versión 2.15.0 mitigada de Log4j desde su página de descargas.
Si no puede actualizar inmediatamente y está utilizando Java 8u121 o posterior
Si la versión de Java es > = 8u121, es posible mitigar el problema configurando:
com.sun.jndi.rmi.object.trustURLCodebase to false y com.sun.jndi.cosnaming.object.trustURLCodebase to false
Sigue siendo preferible actualizar la versión de log4j para asegurar una lo antes
posible.
Usando la versión de Java Menor que 1.8
En versiones anteriores de log4j> = 2.10, es posible mitigar este problema al:
1. Establecer la propiedad del sistema
formatMsgNoLookups: true
2. Establecer el parámetro JVM
-Dlog4j2.formatMsgNoLookups=true
3. Eliminando la clase JndiLookup del classpath
example: zip -q -d log4j-core-*.jar
org/apache/logging/log4j/core/lookup/JndiLookup.class
Procedimientos de gestión de riesgos
Mientras los equipos de desarrollo trabajan para encontrar las aplicaciones afectadas y actualizar todas las dependencias relevantes, es recomendable actualizar los conjuntos de reglas de los sistemas de prevención de intrusiones (IPS) para ganar más tiempo para trabajar en la corrección.
Le recomendamos que se comunique directamente con su proveedor de IPS para asegurarse de que el software que utiliza su sistema IPS / IDS no se vea afectado por esta misma vulnerabilidad.
Aunque sus sistemas IDS (Sistema de detección de intrusiones) son útiles para mostrar los intentos de probar esta vulnerabilidad en sus aplicaciones, no pueden evitar que el ataque llegue a sus aplicaciones.
Importancia: Alta (10/10
Referencias y Créditos:
https://www.lunasec.io/docs/blog/log4j-zero-day/
https://nvd.nist.gov/vuln/detail/CVE-2021-44228
https://logging.apache.org/log4j/2.x/security.html
https://www.cert.govt.nz/it-specialists/advisories/log4j-rce-0-day-activelyexploited/
https://www.veracode.com/blog/research/exploiting-jndi-injections-java
https://github.com/veracode-research/rogue-jndi
Comments