CVE-2021-44228 (Log4Shell): comprobar y corregir

Qué está afectado

Solo está afectado log4j-core de Log4j 2, y solo desde 2.0-beta9 hasta la corrección. Log4j 1.x no está afectado por esta CVE, pero llegó al final de su vida útil en 2015 y tiene sus propias vulnerabilidades. Las aplicaciones Java basadas en Log4j 2 (servidores de aplicaciones, motores de búsqueda, aplicaciones a medida) llevan la biblioteca en sus propias carpetas, a menudo dentro de un .war o de un .jar fat, no como paquete del sistema.

La primera corrección, 2.15.0, era incompleta en algunas configuraciones (CVE-2021-45046), y después llegaron otros dos problemas (CVE-2021-45105 y CVE-2021-44832). Por eso el objetivo hoy es 2.17.1 o posterior en Java 8, 2.12.4 en Java 7 y 2.3.2 en Java 6.

Comprobar si un servidor lo tiene

Busca archivos log4j-core y después archivos comprimidos que lo incluyan. La versión está en el nombre del archivo:

sudo nice -n 19 ionice -c3 find / -xdev -type f -name 'log4j-core-*.jar' 2>/dev/null

sudo nice -n 19 ionice -c3 find / -xdev -type f \( -name '*.jar' -o -name '*.war' -o -name '*.ear' \) 2>/dev/null \
  | while read -r f; do
      unzip -l "$f" 2>/dev/null \
        | grep -qE 'log4j/core/lookup/JndiLookup\.class|log4j-core-[0-9][^/]*\.jar' && echo "$f"
    done

Para una aplicación que compilas tú, pregunta a la herramienta de build qué versión empaqueta realmente:

mvn dependency:tree -Dincludes=org.apache.logging.log4j:log4j-core

Para ver si alguien lo ha intentado, busca las búsquedas JNDI en los logs de acceso del servidor web (los atacantes también las ponen en cabeceras, que estos logs no registran):

sudo grep -rhiE '\$\{jndi|%24%7Bjndi|\$\{\$\{' --include='*access*' --exclude='*.gz' /var/log/apache2 /var/log/httpd 2>/dev/null | tail -20

Corregirlo

1. Software de un fabricante: instala la versión del fabricante que incluye Log4j 2.17.1 o posterior.
2. Tu propia aplicación: sube log4j-core (y log4j-api) a 2.17.1 o posterior, o 2.12.4 en Java 7 y 2.3.2 en Java 6, recompila y vuelve a desplegar. Comprueba con la herramienta de build que ninguna otra dependencia vuelva a traer una copia más antigua.
3. Reinicia la aplicación: una JVM en ejecución conserva las clases antiguas hasta entonces.
4. Repite la búsqueda de arriba: no debe quedar ningún log4j-core antiguo, tampoco en copias de seguridad de aplicaciones desplegadas que podrían volver a desplegarse.

<dependency>
  <groupId>org.apache.logging.log4j</groupId>
  <artifactId>log4j-core</artifactId>
  <version>2.17.1</version>
</dependency>

Fuentes

Los datos de esta página vienen de estas fuentes; consúltalas por si hay cambios.

• NVD: CVE-2021-44228
• Catálogo CISA Known Exploited Vulnerabilities: CVE-2021-44228
• Apache Logging Services: Log4j security vulnerabilities
• NVD: CVE-2021-44832