Fin de semana movidito para los equipos de IT. El pasado viernes 10 de Diciembre saltaron todas las alarmas habidas y por haber en el mundo de la ciberseguridad: Apache Log4J, una de las librerías de logs más extendida y utilizada del mundo, presentaba una vulnerabilidad zero-day que permitía a un atacante ejecutar de forma remota código fuente malicioso en los sistemas que la utilizasen.

Esta vulnerabilidad, etiquetada por el CVE como CVE-2021-44228 (pero conocida comúnmente como Log4Shell), por su facilidad de explotación y la gravedad de la misma, ha sido catalogada con un 10 sobre 10, convirtiéndose en una de las más peligrosas de los últimos años.

Por suerte, solo poco más de 24 horas después ya se publicó una nueva versión de la librería (2.15.0) que solventa el problema. Ahora, solo basta con actualizar a la versión 2.15.0 2.16.02.17.0 2.17.1 para dejar de ser vulnerable.

Desde Soltel, llevamos días inmersos en el proceso de coordinarnos entre nuestros equipos y clientes para corregir el problema.

Log4Shell: En que consiste y cómo funciona

A grandes rasgos, la vulnerabilidad explota por un lado la capacidad de evaluar expresiones existente en Log4j junto a que no comprueba ciertos protocolos como ldap. Uniendo estos dos factores, un atacante puede, mediante la intermediación de un servidor ldap malicioso ser capaz de retornar código java como respuesta y conseguir que el servidor vulnerable ejecute lo que se haya dejado en el ldap para su maliciosa “evaluación” por parte de Log4J.

LOG4SHELL.drawio

¿Cómo puedo saber si estoy afectado?

Cualquier software que utilice las librerías log4j-core y log4j-api en su s versiones de la 2.0 a la 2.14.1 2.15.0 2.16.0 es vulnerable, por lo que hay que localizarlas. En proyectos mavenizados, por ejemplo, nos podemos precisamente apoyar en Maven para ello y su función de lista de dependencias:

  mvn dependency:list | grep log4j

 

Importante, no nos vayamos a creer que por usar una versión 1.x de Log4j vamos a estar a salvo. Log4j 1.x terminó su ciclo de vida en Agosto de 2015, por lo que deberíamos actualizar igualmente. Como prueba de ello se acaba de publicar precisamente la vulnerabilidad CVE-2021-4104, que por otros medios también permite la ejecución de código malicioso en nuestros entornos. Y no es la única vulnerabilidad existente, hay algunas mas reportadas en años anteriores.

 

Si estás acostumbrado al uso de herramientas de análisis estático de seguridad, es casi seguro que ya estén generando alertas al respecto.

Por ejemplo, el analizador de dependencias OWSAP Dependency Check (uno de los más populares) ya es capaz de ello:

owasplog4j

 

Pero ¡OJO!, cuidado con limitarse solo con el software propio. Es muy, muy posible que tu infraestructura esté utilizando esta librería a través de otros productos intermedios. La lista de sistemas afectados no para de crecer, pasando por Minecraft: Java Edition, Twitter, Cloudflare, Tencent, ElasticSearch, Redis, Elastic Logstash y otro largo etcétera, por lo que se debe estar atento.

 

Mitigando el error

Si tu software está afectado, hay actualmente tres vías de mitigación posibles: Actualizar tus librerías, desactivar la evaluación por Lookup y, en ultima instancia, eliminar o parchear en nuestro sistema la clase JndiLookup.

 

Contramedida 1: Subir de versión Log4j

Evidentemente la solución ideal es subir log4j a una versión que no evalúe por defecto estas expresiones. Esto ocurre a partir de la versión 2.15.0, 2.16.0, 2.17.0 2.17.1 ya disponible.

También se han publicado parches para los sistemas que funcionen bajo versiones anteriores de java: 2.12.4 (Java 7) y 2.3.2 (Java 6).

 

Contramedida  2: log4j2.formatMsgNoLookups = true (OBSOLETO)

Si no es sencillo el recambio inmediato la actualización de la librería,  se puede mitigar el efecto arrancando el servicio afectado con el parámetro log4j2.formatMsgNoLookups seteado a true. De esta forma forzamos a que el sistema no realice lookups cuando evalúe expresiones.

Esto es válido para las versiones 2.10 a 2.14.1. Versiones inferiores pueden probar la tercera vía.

Esta medida, es recomendable, aunque se aplique la actualización, aplicar este parámetro. Tened en cuenta que en sistemas dockerizables, se puede forzar desde su archivo de construcción de imagen DockerBuild.

  java -jar -Dlog4j2.formatMsgNoLookups=true mijar.jar
  export JAVA_OPTS=$JAVA_OPTS -Dlog4j2.formatMsgNoLookups=true

 

Actualización [2021-12-15]: Esta contramedida no sería aplicable para mitigar la nueva vulnerabilidad  CVE-2021-45046 reportada el dia 14/12/2021, por lo que actualmente se considera insuficiente.

Contramedida  3: Eliminar clase JndiLookup de tu pila técnica.

Como ultimo recurso, si tu versión log4j no se puede actualizar a la versión 2.17.1 (o a las versiones 2.12.4 (Java 7) / 2.3.2 (Java 6)), solo te queda localizar si en tu pila técnica o la de tu servidor de arranque está la clase org.apache.logging.log4j.core.lookup.JndiLookup y o bien eliminarla, o bien reemplazarla por una implementación vacía.

Ejemplo:

    zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Además, para evitar las posteriores vulnerabilidades publicadas, CVE-2021-45105 y CVE-2021-45106, Se recomienda en la configuración de logging, evitar referencias a contextos que pueden venir de entradas no controladas (cabeceras http, datos introducidos por el usuario, etc) como ${ctx:loginId} o $${ctx:loginId}. Alternativamente, también se pueden utilizar patrones del Thread Context Map (% X,% mdc o% MDC), evitando así la recursividad  no controlada que genera el problema.

Referencias:

 

Actualización [2021-12-15]: CVE Acaba de publicar una nueva vulnerabilidad sobre Log4j, que también afecta a la versión 2.15.0: CVE-2021-45046. Esta nueva vulnerabilidad, de menor gravedad, te permite efectuar ataques DDOS y se corrige o bien actualizando a la versión 2.16.0, o mediante la contramedida número 3.

 

Actualización [2021-12-19]: Al parecer la versión 2.16.0 no mitiga del todo las vulnerabilidades CVE-2021-45105 y CVE-2021-45106. Apache acaba de publicar nueva versión de Log4j (2.17.0) que «supuestamente» corrige el problema definitivamente.

 

Actualización [2021-12-30]: Se acaba de publicar una nueva vulnerabilidad: CVE-2021-44832. La versión libre de vulnerabilidades es ahora la 2.17.1 (o 2.12.4 para sistemas con java 7).

 

Articulo elaborado por Ramón Tur Vázquez, Solutions Architect en SOLTEL Group