Como comentó DuncG , la opción de deshabilitar las búsquedas para Log4j no es una opción de configuración sino una propiedad del sistema.

 log4j2.formatMsgNoLookups

Dependiendo de su entorno ( Spring , ejecutable independiente, aplicación web Tomcat ,...) la forma en que se establecen las propiedades del sistema puede variar. La posibilidad más sencilla de iniciar un proceso Java desde un archivo JAR sería agregar

 -Dlog4j2.formatMsgNoLookups=true

a su línea de comando:

 java -Dlog4j2.formatMsgNoLookups=true -jar myapp.jar

CVE-2021-44228 Vulnerabilidad Log4Shell

Si puede, actualice a las versiones Log4j2 + Java según lo recomendado por los detalles de seguridad en el sitio de registro de Apache . Este sitio ha cambiado desde mi publicación original; Siempre siga las pautas recomendadas del sitio web de Apache.

El sitio de Apache sugirió anteriormente algunas soluciones para la vulnerabilidad de búsqueda JNDI informada en versiones anteriores de Log4j2.

En mi opinión: esta es una vulnerabilidad tan grave que no debe contemplar estas soluciones alternativas y, para cuando lea esto, es posible que ya no le ayuden. Actualice los archivos JAR de Log4j y vea la nota a continuación sobre los lugares para verificar.

1. Establezca la propiedad del sistema log4j2.formatMsgNoLookups cuando inicie la VM, pasando como java -Dlog4j2.formatMsgNoLookups=true ... .
2. Establezca la variable de entorno LOG4J_FORMAT_MSG_NO_LOOKUPS en verdadero.
3. Para las versiones de 2.0-beta9 a 2.10.0, la mitigación consiste en eliminar org/apache/logging/log4j/core/lookup/JndiLookup.class de classpath; consulte log4j-core-*.jar .
4. reemplace el patrón de formato %m por %m{nolookups} para algunas versiones

No pude encontrar LOG4J_FORMAT_MSG_NO_LOOKUPS al ejecutar un grep en el código fuente de Java para 2.14.0 , por lo que no está claro si esto ayuda en absoluto.

Ciertas versiones de JDK mitigan los riesgos: JDK superiores a 6u211, 7u201, 8u191 y 11.0.1 no se ven afectados debido a los valores predeterminados aplicados a las búsquedas LDAP. Actualizar donde sea posible.

Algunos lugares para verificar el uso de Log4j

Compruebe qué versiones de Java utiliza son lo suficientemente recientes:

 java -version

Escanee las estructuras de lanzamiento de su aplicación, los servidores de aplicaciones y los entornos de desarrollo en busca de posibles versiones antiguas de Log4j:

 find yourReleaseDir -type f -name log4j\*jar

Si no está seguro de qué versión de Log4j tiene, abra el archivo JAR en una herramienta ZIP y vea META-INF\MANIFEST.MF ; puede haber una línea con los detalles de la versión:

 Log4jReleaseVersion: ABC

Vea los procesos en ejecución en cada máquina de lanzamiento para ver si hay algún identificador de archivo abierto para los archivos JAR de Log4j:

 lsof | grep log4j

También escanee las máquinas para verificar que la VM de Java sean las versiones que espera. Esto puede detectar más aplicaciones en las que trabajar:

 ps -ef | egrep "(java|jdk)" #OR: | grep -v grep

Escanee archivos EAR y WAR en servidores de aplicaciones para verificar que no haya ningún archivo JAR de Log4j incrustado dentro de un archivo contenedor. Puede hacer esto con los comandos de find y unzip , o pruebe la clase ShowClassVersions que escribí para detectar las versiones del compilador de Java en esta respuesta . Esto imprimiría los nombres de los archivos JAR dentro de los archivos WAR y EAR :

 java ShowClassVersions.java app_server_dir |grep log4j app_server_dir/somewebapp.war => WEB-INF/lib/log4j2-core.jar

Puede hacer esto: %m{nolookups} en el diseño.

{nolookups} es cómo establece la propiedad log4j2.formatMsgNoLookups=true dentro del contenido XML de configuración.

Citando de la fuente de Log4j:

FORMAT_MESSAGES_PATTERN_DISABLE_LOOKUPS = PropertiesUtil.getProperties().getBooleanProperty("log4j2.formatMsgNoLookups", false);

y su javadoc:

LOG4J2-2109 si es verdadero, MessagePatternConverter siempre funcionará como si

%m{nobúsquedas}

está configurado.

Ya que:

2.10

Agregue el delimitador -Dlog4j2.formatMsgNoLookups=true en export catalina_opts o export java_options .

Recuerde verificar siempre la información más reciente de los recursos que se enumeran a continuación.

CVE-2021-45105 ... ¡2.16.0 y 2.12.2 ya no son soluciones válidas! Las versiones de corrección actuales son 2.17.0 (Java 8) y 2.12.3 (Java 7). Todas las demás versiones de Java deben adoptar el enfoque de interrupción (eliminación/eliminación del archivo JndiLookup.class del archivo JAR log4j-core .

La opción de la variable de entorno ya no se considera una corrección o mitigación válida. Técnicamente, reducirá ligeramente la exposición de la vulnerabilidad, pero en realidad no solucionará nada. Describo la información de remediación a continuación.

• Más recursos
  • Log4j 0day siendo explotado
    • Este tiene toneladas de información útil, incluidos detectores, incluso más enlaces de recursos, pasos de remediación muy fáciles de entender y más
  • Guía de vulnerabilidades de Apache Log4j
  • CISA Log4j (CVE-2021-44228) Guía de vulnerabilidad
  • Vulnerabilidades de seguridad de Apache Log4j

Remediación:

CVE-2021-45046 ... CVE-2021-44228 ... CVE-2021-45105

• Siga la guía en esos recursos... puede cambiar, pero

A partir de 2021-12-18

es básicamente

• Elimine los archivos JAR log4j-core si es posible
  • De ambas máquinas en funcionamiento para una solución inmediata y
  • en su código fuente/archivos de administración de código fuente para evitar que futuras compilaciones/lanzamientos/implementaciones sobrescriban el cambio
• Si eso no es posible (debido a una dependencia), actualícelos
  • Si está ejecutando Java 8, puede actualizar a Log4j 2.17.0+
  • Si está ejecutando Java 7, puede actualizar a Log4j 2.12.3
  • Si está ejecutando una versión anterior de Java, debe actualizar a la versión más reciente de Java y luego usar la versión más reciente de Log4J.
  • Nuevamente, estos cambios tienen que ocurrir tanto en la máquina en ejecución como en el código.
• Si ninguno de los dos es posible por alguna razón... entonces existe la brecha de detención no correctiva de eliminar el archivo JndiLookup.class de los archivos JAR de log4j-core .
  • Hay una sola línea para la opción de interrupción en Linux usando el comando zip que viene empaquetado con la mayoría de las distribuciones de Linux de forma predeterminada.
    • zip -q -d "$LOG4J_JAR_PATH" org/apache/logging/log4j/core/lookup/JndiLookup.class
  • Al momento de escribir, la mayoría de las guías en línea para la opción de interrupción en Windows dicen que haga lo siguiente (nuevamente... suponiendo que no pueda eliminar una de las opciones JAR o actualizar anteriores):
    • Instala algo como 7-Zip
    • Localice todos sus archivos JAR log4j-core y para cada uno haga lo siguiente...
    • Cambie el nombre del JAR para cambiar la extensión a .zip
    • Use 7-Zip para descomprimir el archivo JAR (que ahora tiene una extensión .zip )
    • Localice y elimine el archivo JndiLookup.class de la carpeta descomprimida
      • La ruta es \\path\\to\\unzippedFolder\\org\\apache\\logging\\log4j\\core\\lookup\\JndiLookup.class
    • Elimine el archivo JAR anterior (que ahora tiene una extensión de .zip)
    • Use 7-Zip para volver a comprimir la carpeta
    • Cambie el nombre de la nueva carpeta .zip para cambiar la extensión a .jar
  • También hay algunas opciones para usar PowerShell
    • Hilo de Reddit: log4j_0day_ being_exploited
    • Ctrl + F para "PowerShell"

Esto está bien si solo tiene que manejar uno o dos archivos JAR y no le importa instalar 7-Zip o si tiene PowerShell disponible para hacerlo. Sin embargo, si tiene muchos archivos JAR o si no desea instalar 7-Zip y no tiene acceso a PowerShell, creé un script VBScript de código abierto (.vbs) que lo hará por usted sin necesidad de instalar ningún software adicional. Windowslog4jClassRemover

Lea el LÉAME y las notas de la versión - Lanzamiento: La luz es realmente fácil de leer y seguir ahora CrazyKidJack/Windowslog4jClassRemover

Hay mucha confusión con respecto a la variable a usar, log4j2.formatMsgNoLookups, log4j.formatMsgNoLookups, etc. Tenga en cuenta que como se indica en PropertySource.java ,

 / ** * Converts a property name string into a list of tokens. This will strip a prefix of {@code log4j}, * {@code log4j2}, {@code Log4j}, or {@code org.apache.logging.log4j}, along with separators of * dash {@code -}, dot {@code.}, underscore {@code _}, and slash {@code /}. Tokens can also be separated * by camel case conventions without needing a separator character in between. * * @param value property name * @return the property broken into lower case tokens * /

Puede usar diferentes valores para la variable, como puede verificar con este código de prueba (lamentablemente, debe indicar la propiedad del sistema en un bloque estático, por lo que para probar las diferentes opciones, debe comentar o descomentar las diferentes líneas del examen).

 package org.apache.logging.log4j.core.pattern; import org.apache.logging.log4j.core.util.Constants; import org.junit.Test; import static org.junit.Assert.assertTrue; / ** * * / public class Log4jParameterTest { static { // Test Ok. All working // System.setProperty ("log4j2.formatMsgNoLookups", "true"); // System.setProperty ("log4j.formatMsgNoLookups", "true"); // System.setProperty ("Log4j.formatMsgNoLookups", "true"); // System.setProperty ("org.apache.logging.log4j.formatMsgNoLookups", "true"); // System.setProperty ("log4j2-formatMsgNoLookups", "true"); // System.setProperty ("log4j2_formatMsgNoLookups", "true"); System.setProperty ("log4j2 / formatMsgNoLookups", "true"); // Test KO. All fail // System.setProperty ("log5j2.formatMsgNoLookups", "true"); // System.setProperty ("log5j2-formatMsgNoLookups", "true"); } @Test public void testLookupEnabledByDefault () { assertTrue ("Lookups deactivated", Constants.FORMAT_MESSAGES_PATTERN_DISABLE_LOOKUPS); } }

A quién usa log4j-xml-config-file :

1. Reemplace %m por %m{nolookups} en PatternLayout
2. Agregue la propiedad del sistema log4j.formatMsgNoLookups = true: System.setProperty("log4j2.formatMsgNoLookups", "true");