Mitigar la vulnerabilidad JNDI de Apache Log4j2 en Jitterbit Harmony

Resumen

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

Descubrimiento de vulnerabilidades

El 9 de diciembre de 2021, Apache reveló una vulnerabilidad crítica de día cero que afecta a Apache Log4j2 (CVE-2021-44228). Apache reveló una vulnerabilidad relacionada adicional 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 solucionar las vulnerabilidades de Apache Log4j2.

Después de la conclusión del mantenimiento el 16 de diciembre de 2021 a las 5:00 p. m. PST (17 de diciembre de 2021 a las 12:00 p. m. AEDT; 17 de diciembre de 2021 a las 2:00 a. m. CET; 17 de diciembre de 2021 a la 01:00 UTC), debe realizar los siguientes pasos para que la actualización entre en vigencia:

1. En cada agente privado, debe eliminar manualmente todos los archivos JAR de <JITTERBIT_HOME>/Connectors. (La excepción sería cualquier archivo JAR para conectores que haya instalado localmente).
2. Cada agente privado debe reiniciarse.
3. Ejecute una operación donde 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 a su organización de estas vulnerabilidades.

Una versión anterior de esta página indicaba a los usuarios que solo debían reiniciar los agentes privados. Reiniciar los agentes privados es eficaz 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 los agentes privados desde que se completó el mantenimiento de emergencia, debe reiniciarlos para que reciban la actualización de mantenimiento de emergencia. No se recomienda ninguna acción adicional más allá del reinicio con respecto a estas vulnerabilidades.

¿cuáles son las vulnerabilidades JNDI de Apache Log 4j2?

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 limitaban a Integration Studio conectores creados con el Integration Studio sDK del conector ("Integration Studio conectores SDK").

Como los conectores no suelen considerarse productos Jitterbit independientes y deben ejecutarse en un agente Jitterbit, es necesario explicar el impacto y los pasos de mitigación para abordar estas vulnerabilidades:

• ¿Qué es an Integration Studio conector SDK ¿Conector?
  Integration Studio los conectores SDK de conector son conectores creados con el [Integration StudioSDK del conector. Actualmente incluyen ciertos conectores creados por Jitterbit o por un tercero:
  • Jitterbit: La mayoría de los conectores actuales Integration Studioconectores de aplicación 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 con el SDK del conector no se verán afectados.
  • Terceros: Como el SDK del conector está disponible públicamente para crear Integration Studio conectores, es posible que su organización esté usando conectores adicionales creados con el SDK de conectores por un socio o un tercero y que también se vean afectados por estas vulnerabilidades. Comuníquese con el proveedor de ese conector para determinar si lo han evaluado y, si es necesario, corregido.
• ¿Cómo se relacionan estos conectores con los agentes?
  La última versión de an Integration Studio El conector SDK del conector se descarga mediante un agente Jitterbit según sea necesario desde Harmony cuando se utiliza el conector.
• ¿Qué agentes se vieron afectados?
  Cualquier agente privado o en la nube que estuviera usando an Integration Studio el conector SDK del conector se vio afectado por las vulnerabilidades, ya que se descargó y usó la biblioteca Apache Log4j2 en el agente para escribir registros cuando se estaba usando el conector.
  • Agentes en la nube: En los agentes en la nube, Jitterbit abordó de inmediato estas vulnerabilidades a través de los controles de seguridad adecuados. No es necesario realizar más acciones.
  • Agentes privados: En los agentes privados, antes del mantenimiento de emergencia del 16 de diciembre de 2021, se les indicó a los clientes que siguieran la solución alternativa documentada previamente para abordar estas vulnerabilidades.

Estos productos Jitterbit no se vieron afectados:

• Agentes que nunca han usado an Integration Studio Conector SDK Conector: No afectado.
• Jitterbit Design Studio (y sus conectores): No afectado.
• Jitterbit Harmony Cloud: No afectado.
• Jitterbit eiCloud: No afectado.

Fluctuación de bits Integration Studio conectores SDK de conectores

La siguiente es una lista de todos Integration Studio conectores a partir del 16 de diciembre de 2021 que han sido creados por Jitterbit con el Integration Studio Connector SDK y se ven afectados por las vulnerabilidades de Apache Log4j.

Como el SDK del conector está disponible públicamente para los desarrolladores, su organización puede estar usando un conector que no figura aquí y que fue creado por un socio o un externo mediante el Integration Studio SDK del conector. Estos conectores también pueden verse afectados por las vulnerabilidades de Apache Log4j. Comuníquese con el proveedor de ese conector para averiguar si lo han evaluado y, si es necesario, corregido.

¿Qué hizo el mantenimiento del 16 de diciembre de 2021?

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

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

Después de la conclusión del mantenimiento el 16 de diciembre de 2021 a las 5:00 p. m. PST (17 de diciembre de 2021 a las 12:00 p. m. AEDT; 17 de diciembre de 2021 a las 2:00 a. m. CET; 17 de diciembre de 2021 a la 01:00 UTC), debe realizar los siguientes pasos para que la actualización entre en vigencia:

1. En cada agente privado, debe eliminar manualmente todos los archivos JAR de <JITTERBIT_HOME>/Connectors. (La excepción sería cualquier archivo JAR para conectores que haya instalado localmente).
2. Cada agente privado debe reiniciarse.
3. Ejecute una operación donde 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 a su organización de estas vulnerabilidades.

Una versión anterior de esta página indicaba a los usuarios que solo debían reiniciar los agentes privados. Reiniciar los agentes privados es eficaz 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 haya implementado 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 archivo 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. Todos los nombres de archivo de la serie Log4j versión 2 ahora deben 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ó previamente antes del mantenimiento de emergencia del 16 de diciembre de 2021. Esta solución alternativa ya no es necesaria y las vulnerabilidades se solucionan con un reinicio del agente después del mantenimiento del 16 de diciembre de 2021. Si ya ha realizado esta solución alternativa y reiniciado los agentes privados, no es necesario realizar ninguna otra acción.

Para los clientes con agentes privados, se recomendaban anteriormente los siguientes pasos para protegerse contra las vulnerabilidades de Apache Log4j.

Agente privado de Linux

Para los agentes privados de Linux, la solución manual consiste en editar el secuencia de comandos de inicio del servidor Tomcat.

El archivo a cambiar es catalina.sh, ubicado en <JITTERBIT_HOME>/tomcat/bin/catalina.sh En una instalación típica, este se ubicará 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 comienzo 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 del 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 javay busque en la salida -Dlog4j2.formatMsgNoLookups=true.

Agente privado de Windows

Para los agentes privados de Windows, deberá editar el registro.

Siga estos pasos:

1. Detenga el agente privado de Windows.

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

3. Navegue hasta 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 de la -Xms línea:

   -Dlog4j2.formatMsgNoLookups=true
   

   Ejemplo:

   

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 un 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 comandos.

Ejemplo de salida de verificación