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 de Jitterbit y explica cómo se mitigaron las vulnerabilidades.

Descubrimiento de vulnerabilidades

El 9 de diciembre de 2021, se divulgó una vulnerabilidad crítica de día cero por Apache que afecta a Apache Log4j2 (CVE-2021-44228). Una vulnerabilidad adicional relacionada fue divulgada por Apache 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 la conclusión del mantenimiento el 16 de diciembre de 2021 a las 5 p. m. PST (17 de diciembre de 2021 12 p. m. AEDT; 17 de diciembre de 2021 2 a. m. CET; 2021‑12‑17 01:00 UTC), debe realizar los siguientes pasos para que la actualización sea efectiva:

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 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 archivo 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 de inmediato para proteger a su organización de estas vulnerabilidades.

Una versión anterior de esta página instruyó a los usuarios a reiniciar solo los agentes privados. Reiniciar los 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 directorio Connectors para asegurarse de que está protegido de estas vulnerabilidades. Puede verificar que está protegido buscando log4j en cualquier nombre de archivo y comprobando 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ó una solución alternativa para abordar manualmente las vulnerabilidades en esta página antes del mantenimiento de emergencia. Esta solución alternativa ya no es necesaria para ninguna versión de agentes privados.

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 reiniciar los agentes para que reciban la actualización del 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 de JNDI de Apache Log 4j2?

Desde la Base de Datos Nacional de Vulnerabilidades del NIST CVE-2021-44228:

Las características de JNDI de Apache Log4j2 \<=2.14.1 utilizadas en la configuración, mensajes de registro y parámetros no protegen contra puntos finales relacionados con LDAP y otros JNDI controlados por atacantes. Un atacante que pueda controlar los mensajes de registro o los parámetros de los mensajes de registro puede ejecutar código arbitrario cargado desde servidores LDAP cuando la sustitución de búsqueda de mensajes está habilitada. Desde Log4j 2.15.0, este comportamiento ha sido deshabilitado por defecto.

Una vulnerabilidad relacionada es CVE-2021-45046, que describe una vulnerabilidad en la biblioteca Log4j 2.15.0. Ambas vulnerabilidades están cubiertas y abordadas aquí.

¿Qué productos de Jitterbit se vieron afectados por las vulnerabilidades?

Estas vulnerabilidades se limitaron a los conectores de Integration Studio creados con el SDK de Conectores de Integration Studio ("conectores del SDK de Conectores de Integration Studio").

Dado que los conectores no se consideran típicamente productos independientes de Jitterbit y deben ejecutarse en un agente de Jitterbit, es necesaria cierta explicación para detallar el impacto y los pasos de mitigación para abordar estas vulnerabilidades:

• ¿Qué es un conector del SDK de Conectores de Integration Studio?
  Los conectores del SDK de Conectores de Integration Studio son conectores construidos con el SDK de Conectores de Integration Studio. Actualmente incluyen ciertos conectores construidos por Jitterbit o por un tercero:
  • Jitterbit: La mayoría de los actuales conectores de aplicación de Integration Studio fueron creados utilizando el SDK de Conectores. Las excepciones incluyen los conectores de NetSuite, Salesforce, Salesforce Service Cloud, SAP y ServiceMax, que no fueron creados utilizando el SDK de Conectores y no están afectados. Consulte la lista completa a continuación de los conectores de Jitterbit afectados por estas vulnerabilidades. Los futuros conectores creados por Jitterbit utilizando el SDK de Conectores no estarán afectados.
  • De terceros: Dado que el SDK de Conectores está disponible públicamente para crear conectores de Integration Studio, su organización puede estar utilizando conectores adicionales creados con el SDK de Conectores por un socio o tercero y también pueden verse afectados por estas vulnerabilidades. Comuníquese con el proveedor de ese conector para determinar si han evaluado y, si es necesario, corregido su conector.
• ¿Cómo están relacionados estos conectores con los agentes?
  La última versión de un conector del SDK de Conectores de Integration Studio es descargada por un agente de Jitterbit según sea necesario desde Harmony cuando utiliza el conector.
• ¿Qué agentes se vieron afectados?
  Cualquier agente en la nube o privado que estuviera utilizando un conector del SDK de Conectores de Integration Studio se vio impactado por las vulnerabilidades, ya que la biblioteca Apache Log4j2 fue descargada y utilizada en el agente para escribir registros cuando se estaba utilizando el conector.
  • Agentes en la nube: En los agentes en la nube, Jitterbit abordó inmediatamente estas vulnerabilidades a través de controles de seguridad apropiados. No se requieren más acciones.
  • Agentes privados: En los agentes privados, antes del mantenimiento de emergencia del 16 de diciembre de 2021, se instruyó a los clientes a seguir la solución alternativa documentada anteriormente para abordar estas vulnerabilidades.

Estos productos de Jitterbit no se vieron afectados:

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

Conectores SDK de Jitterbit Integration Studio

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

Dado que el SDK de Conector está disponible públicamente para los desarrolladores, su organización puede estar utilizando un conector no listado aquí que fue creado por un socio o tercero utilizando el SDK de Conector de Integration Studio. Esos conectores también pueden estar afectados por las vulnerabilidades de Apache Log4j. Comuníquese con el proveedor de ese conector para averiguar si han 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 Integration Studio construidos con el SDK de Conectores para utilizar una versión disponible de la biblioteca Log4j que abordaba las dos vulnerabilidades de Apache Log4j.

Después de la conclusión del 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), debes realizar los siguientes pasos para que la actualización sea efectiva:

1. En cada agente privado, debes eliminar manualmente todos los archivos JAR de <JITTERBIT_HOME>/Connectors. (La excepción serían los archivos JAR de conectores que hayas instalado localmente.)
2. Cada agente privado debe ser reiniciado.
3. Ejecuta una operación donde se utilice el conector o prueba la conexión.

Si no has realizado todos los pasos anteriores en este orden después de completar el mantenimiento, hazlo inmediatamente para proteger a tu organización de estas vulnerabilidades.

Una versión anterior de esta página instruía a los usuarios solo a reiniciar los agentes privados. Reiniciar los 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 directorio Connectors para asegurarte de que estás protegido de estas vulnerabilidades. Puedes verificar que estás protegido buscando log4j en cualquier nombre de archivo y comprobando la versión de Log4j como se describe a continuación.

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

Una vez implementados los pasos de mitigación para los agentes privados, puedes confirmar que estás 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 versión 2, como log4j-api-2.11.1.jar, ya no debería estar presente. Cualquier nombre de archivo de la serie de versión 2 de Log4j debería haber sido reemplazado por un nombre que indique que la versión es al menos 2.16.0.

Para obtener más ayuda, contacta al 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 abordan con un reinicio del agente después del mantenimiento del 16 de diciembre de 2021. Si ya has realizado esta solución alternativa y reiniciado los agentes privados, no se necesita ninguna acción adicional.

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

Agente privado de Linux

Para los agentes privados de Linux, la solución alternativa manual es editar el script de inicio para el servidor Tomcat.

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

/opt/jitterbit/tomcat/bin/catalina.sh

1. Agrega la siguiente línea inmediatamente después de las líneas de comentario 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. Guarda el cambio en el archivo y sal de tu editor.

4. Reinicia el agente privado:

   > jitterbit stop
   > jitterbit start
   

Verificación del Cambio

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

Agente privado de Windows

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

Sigue estos pasos:

1. Detén el agente privado de Windows.

2. Usa la búsqueda de Windows para encontrar regedit y úsalo 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. Modifica sus Options y agrega lo siguiente antes de la línea -Xms:

   -Dlog4j2.formatMsgNoLookups=true
   

   Ejemplo:

   

5. Sal del Editor del Registro.

6. Reinicia el agente privado de Windows.

Verificación del Cambio

Para verificar los resultados de este cambio:

• Abre el Bloc de notas (o un editor similar).

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

  <JITTERBIT_HOME>\tomcat\logs\catalina.{date}.log
  

• Busca -Dlog4j2.formatMsgNoLookups=true para verificar que se esté utilizando el argumento de línea de comando.

Ejemplo de Salida de Verificación