Saltar al contenido

Mitigar la Vulnerabilidad JNDI de Apache Log4j2

Resumen

Esta página resume las vulnerabilidades de Apache Log4j2, describe su impacto en los productos Jitterbit y explica cómo se mitigaron las vulnerabilidades.

Descubrimiento de Vulnerabilidades

El 9 de diciembre de 2021, una vulnerabilidad crítica de día cero fue divulgada por Apache que afecta a Apache Log4j2 (CVE-2021-44228). Apache reveló una vulnerabilidad adicional relacionada el 14 de diciembre de 2021 (CVE-2021-45046).

Mitigación para Agentes Privados

El 16 de diciembre de 2021, Jitterbit realizó un mantenimiento de emergencia para abordar las vulnerabilidades de Apache Log4j2.

Después de finalizar el mantenimiento el 16 de diciembre de 2021 a las 5 p. m. PST (17 de diciembre de 2021 a las 12 p. m. AEDT; 17 de diciembre de 2021 a las 2 a. m. CET; 2021‑12‑17 01:00 UTC), debe realizar los siguientes pasos para que el actualizar para que entre en vigor:

  1. En cada Agente Privado, debe eliminar manualmente todos los archivos JAR de <JITTERBIT_HOME>/Connectors. (La excepción serían los archivos JAR de los conectores que haya instalado localmente).
  2. Se debe reiniciar cada Agente Privado .
  3. Ejecute una operación en la que se utilice cada conector o pruebe cada conexión para cada JAR de conector en el agente.

Si no ha realizado todos los pasos anteriores en este orden después de completar el mantenimiento, hágalo inmediatamente para proteger su organización de estas vulnerabilidades.

Una versión anterior de esta página indicaba a los usuarios que solo reiniciaran Agentes Privados. Reiniciar Agentes Privados es efectivo para la mayoría de los conectores. Sin embargo, para algunos conectores es necesario realizar todos los pasos. Recomendamos eliminar todos los archivos JAR en el Connectors directorio para asegurarse de que está protegido contra estas vulnerabilidades. Puede verificar que está protegido buscando log4j en cualquier nombre de archivo y verificando la versión de Log4j como se describe a continuación.

Solución Alternativa Anterior para Agentes Privados

Antes del 16 de diciembre de 2021, se publicó en esta página una solución alternativa para abordar manualmente las vulnerabilidades antes del mantenimiento de emergencia. Esta solución alternativa ya no es necesaria para ninguna versión de Agente Privado.

Si ya ha realizado la solución alternativa, no es necesario revertirla. Si no ha reiniciado Agentes Privados desde que se completó el mantenimiento de emergencia, debe reiniciar los agentes para que reciban la actualización del mantenimiento de emergencia. No se recomienda ninguna acción adicional más allá de reiniciar con respecto a estas vulnerabilidades.

¿cuáles Son las Vulnerabilidades de Apache Log 4j2 JNDI?

De la base de datos nacional de vulnerabilidades del NIST CVE-2021-44228:

Apache Log4j2 \<=2.14.1 JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From Log4j 2.15.0, this behavior has been disabled by default.

Una vulnerabilidad relacionada es CVE-2021-45046, que describe una vulnerabilidad en la biblioteca Log4j 2.15.0. Ambas vulnerabilidades se tratan y abordan aquí.

¿qué Productos Jitterbit Se Vieron Afectados por las Vulnerabilidades?

Estas vulnerabilidades se limitaron a los conectores Cloud Studio creados con el SDK de Harmony Connector ("conectores SDK de Cloud Studio Connector").

Como los conectores normalmente no se consideran productos Jitterbit independientes y deben ejecutarse en un Harmony Agente, es necesaria alguna explicación para explicar el impacto y los pasos de mitigación para abordar estas vulnerabilidades:

  • ¿Qué es un conector SDK de Cloud Studio Connector?
    Los conectores SDK de Cloud Studio Connector son conectores creados con Harmony Connector SDK. Actualmente incluyen ciertos conectores creados por Jitterbit o por un tercero:
    • Jitterbit: La mayoría de los conectores de aplicaciones actuales de Cloud Studio se crearon utilizando el SDK del conector. Las excepciones incluyen los conectores NetSuite, Salesforce, Salesforce Service Cloud, SAP y ServiceMax, que no se crearon utilizando el SDK del conector y no se ven afectados. Consulte la lista completa a continuación de los conectores Jitterbit afectados por estas vulnerabilidades. Los conectores futuros creados por Jitterbit utilizando el SDK de conector no se verán afectados.
    • Terceros: Dado que el SDK de Connector está disponible públicamente para crear conectores de Cloud Studio, su organización puede estar utilizando conectores adicionales creados con el SDK de Connector por un socio o un tercero y también puede verse afectada por estas vulnerabilidades. Comuníquese con el proveedor de ese conector para determinar si ha evaluado y, si es necesario, corregido su conector.
  • ¿Cómo se relacionan estos conectores con los agentes?
    Un Agente de Harmony descarga la última versión de un conector SDK de Cloud Studio Connector según sea necesario desde Harmony cuando utiliza el conector.
  • ¿Qué agentes fueron afectados?
    Cualquier Agente Privado o de nube que estuviera usando un conector SDK de Cloud Studio Connector se vio afectado por las vulnerabilidades, ya que la biblioteca Apache Log4j2 se descargó y se usó en el agente para escribir registros cuando se usaba el conector.
    • Agentes en Nube: En los Agentes en Nube, Jitterbit abordó de inmediato estas vulnerabilidades a través de controles de seguridad adecuados. No son necesarias más acciones.
    • Agentes Privados: En Agentes Privados, antes del mantenimiento de emergencia del 16 de diciembre de 2021, se indicó a los clientes que siguieran la solución alternativa previamente documentada para abordar estas vulnerabilidades.

Estos productos Jitterbit no se vieron afectados:

  • Agentes de Harmony que nunca han utilizado un conector SDK de Cloud Studio Connector: No afectado.
  • Harmony Design Studio (y sus conectores): No afectado.
  • Harmony Cloud: No afectado.
  • Jitterbit eiCloud: No afectado.

Conectores SDK de Harmony Cloud Studio Connector

La siguiente es una lista de todos los conectores de Cloud Studio al 16 de diciembre de 2021 que han sido creados por Jitterbit con el SDK de Harmony Connector y están afectados por las vulnerabilidades de Apache Log4j.

Dado que el SDK de Connector está disponible públicamente para los desarrolladores, es posible que su organización esté utilizando un conector que no figura aquí y que fue creado por un socio o un externo utilizando el SDK de Harmony Connector. Esos conectores también pueden verse afectados por las vulnerabilidades de Apache Log4j. Póngase en contacto con el proveedor de ese conector para saber si ha evaluado y, si es necesario, corregido su conector.

¿qué Hizo el Mantenimiento del 16 de Diciembre de 2021?

El 16 de diciembre de 2021, Jitterbit realizó un mantenimiento de emergencia para abordar las vulnerabilidades de Apache Log4j2.

Como parte del mantenimiento, Jitterbit actualizó los conectores de Cloud Studio creados con Connector SDK para usar una versión disponible de la biblioteca Log4j que abordaba las dos vulnerabilidades de Apache Log4j.

Después de finalizar el mantenimiento el 16 de diciembre de 2021 a las 5 p. m. PST (17 de diciembre de 2021 a las 12 p. m. AEDT; 17 de diciembre de 2021 a las 2 a. m. CET; 2021‑12‑17 01:00 UTC), debe realizar los siguientes pasos para que el actualizar para que entre en vigor:

  1. En cada Agente Privado, debe eliminar manualmente todos los archivos JAR de <JITTERBIT_HOME>/Connectors. (La excepción serían los archivos JAR de los conectores que haya instalado localmente).
  2. Se debe reiniciar cada Agente Privado .
  3. Ejecute una operación en la que se utilice el conector o pruebe la conexión.

Si no ha realizado todos los pasos anteriores en este orden después de completar el mantenimiento, hágalo inmediatamente para proteger su organización de estas vulnerabilidades.

Una versión anterior de esta página indicaba a los usuarios que solo reiniciaran Agentes Privados. Reiniciar Agentes Privados es efectivo para la mayoría de los conectores. Sin embargo, para algunos conectores es necesario realizar todos los pasos. Recomendamos eliminar todos los archivos JAR en el Connectors directorio para asegurarse de que está protegido contra estas vulnerabilidades. Puede verificar que está protegido buscando log4j en cualquier nombre de archivo y verificando la versión de Log4j como se describe a continuación.

¿Cómo puedo confirmar la protección contra estas vulnerabilidades?

Una vez que implemente los pasos de mitigación para los Agentes Privados, puede confirmar que está protegido buscando en los subdirectorios de instalación del agente nombres de archivos que incluyan log4j.

Cualquier nombre de archivo anterior que incluya log4j y un número de serie de la versión 2, como log4j-api-2.11.1.jar, ya no debería estar presente. Cualquier nombre de archivo de la serie Log4j versión 2 ahora debe reemplazarse con un nombre que indique que la versión es al menos 2.16.0.

Para obtener más ayuda, comuníquese con Soporte de Jitterbit.

Solución alternativa anterior para Agentes Privados

Esta solución alternativa se publicó anteriormente antes del mantenimiento de emergencia del 16 de diciembre de 2021. Esta solución alternativa ya no es necesaria y las vulnerabilidades se solucionan reiniciando el agente después del mantenimiento del 16 de diciembre de 2021. Si ya realizó esta solución y reinició Agentes Privados, no es necesario realizar ninguna otra acción.

Para los clientes con Agentes Privados, anteriormente se recomendaron los siguientes pasos para protegerse contra las vulnerabilidades de Apache Log4j.

Precaución

  • Lo mejor es tener Agentes Privados detrás de un firewall sin puertos de entrada. Esto protege contra exploits entrantes.
  • Estas configuraciones se sobrescribirán al actualizar o mejorar.

Agente Privado de Linux

Para los Agentes Privados de Linux, la solución manual es editar el secuencia de comandos de inicio del servidor Tomcat.

El archivo a cambiar es catalina.sh, situado en <JITTERBIT_HOME>/tomcat/bin/catalina.sh. En una instalación típica, estará ubicado en esta ubicación:

/opt/jitterbit/tomcat/bin/catalina.sh
  1. Agregue la siguiente línea inmediatamente después de las líneas de comentarios al principio del archivo:

    JAVA_OPTS="$JAVA_OPTS -Dlog4j2.formatMsgNoLookups=true"
    
  2. Por ejemplo:

    . . .
    # case the default is "true"
    # -----------------------------------------------------------------------------
    JAVA_OPTS="$JAVA_OPTS -Dlog4j2.formatMsgNoLookups=true"
    
    # OS specific support. $var _must_ be set to either true or false.
    . . .
    
  3. Guarde el cambio en el archivo y salga de su editor.

  4. Reinicie el Agente Privado:

    > jitterbit stop
    > jitterbit start
    

Verificación del cambio

Para verificar los resultados de este cambio, ejecute el comando ps -ef | grep java y busque en la salida -Dlog4j2.formatMsgNoLookups=true.

Agente Privado de Windows

Para los Agentes Privados de Windows, deberá editar el registro.

Precaución

Cambiar el registro de Windows incorrectamente puede afectar el sistema operativo Windows. Tenga cuidado al realizar estos cambios.

Sigue estos pasos:

  1. Detenga el Agente Privado de Windows.

  2. Utilice la búsqueda de Windows para encontrar regedit y utilícelo para abrir el Editor del Registro.

  3. Navega a Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Apache Software Foundation\Procrun 2.0\Jitterbit Tomcat Server\Parameters\Java.

  4. Modifique sus Opciones y agregue lo siguiente antes del -Xms línea:

    -Dlog4j2.formatMsgNoLookups=true
    

    Ejemplo:

    adjunto

  5. Salga del Editor del Registro.

  6. Reinicie el Agente Privado de Windows.

Verificación del cambio

Para verificar los resultados de este cambio:

  • Abra el Bloc de notas (o editor similar).

  • Abra el archivo de registro más reciente, ubicado en:

    <JITTERBIT_HOME>\tomcat\logs\catalina.{date}.log
    
  • Buscar -Dlog4j2.formatMsgNoLookups=true para verificar que se esté utilizando el argumento de la línea de comando.

Ejemplo de resultado de verificación

adjunto