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 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 solucionar las vulnerabilidades de Apache Log4j2.

Tras la finalización del mantenimiento el 16 de diciembre de 2021 a las 17:00 PST (17 de diciembre de 2021 a las 12:00 AEDT; 17 de diciembre de 2021 a las 02:00 CET; 17 de diciembre de 2021 a la 01:00 UTC), debe realizar los siguientes pasos para que la actualización sea efectiva:

En cada agente privado, debe eliminar manualmente todos los archivos JAR de <JITTERBIT_HOME>/Connectors. (La excepción serían cualquier archivo JAR para conectores que haya instalado localmente).
Cada agente privado debe reiniciarse.
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 reiniciaran 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 Connectors directorio para garantizar su protección contra estas vulnerabilidades. Puede verificar su protección 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 las versiones de agentes privados.

Si ya ha realizado la solución alternativa, no es necesario revertirla. Si no ha reiniciado los agentes privados desde que finalizó el mantenimiento de emergencia, debe reiniciarlos para que reciban la actualización. No se recomienda ninguna otra acción aparte 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 abordan 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 del conector de Integration Studio ("Conectores del SDK del conector de Integration Studio ").

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

¿Qué es un conector SDK del Integration Studio Connector?
Los conectores del SDK del conector de Integration Studio son conectores creados con el SDK del conector de Integration Studio. Actualmente incluyen ciertos conectores creados por Jitterbit o por un tercero:
- Jitterbit: La mayoría de los conectores de aplicación actuales de Integration Studio se crearon con el SDK del conector. Las excepciones incluyen los conectores de NetSuite, Salesforce, Salesforce Service Cloud, SAP y ServiceMax, que no se crearon con 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 futuros conectores creados por Jitterbit con el SDK del Conector no se verán afectados.
- De terceros: Dado que el SDK del conector está disponible públicamente para crear conectores de Integration Studio, es posible que su organización utilice conectores adicionales creados con el SDK del conector por un socio o un tercero y que también se vean afectados por estas vulnerabilidades. Póngase en contacto con el proveedor de dicho conector para determinar si lo ha evaluado y, de ser necesario, corregido.
¿Cómo se relacionan estos conectores con los agentes? La última versión de un conector SDK de Integration Studio Connector 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 usara un conector SDK de Integration Studio Connector se vio afectado por las vulnerabilidades, ya que se descargó y usó la biblioteca Apache Log4j2 en el agente para escribir registros cuando se usaba el conector.
- Agentes en la nube: En los agentes en la nube, Jitterbit solucionó de inmediato estas vulnerabilidades mediante los controles de seguridad adecuados. No es necesario tomar medidas adicionales.
- Agentes privados: En los agentes privados, antes del mantenimiento de emergencia del 16 de diciembre de 2021, se instruyó a los clientes que siguieran la solución alternativa previamente documentada para abordar estas vulnerabilidades.

Estos productos Jitterbit no se vieron afectados:

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

Conectores SDK del conector de Jitterbit Integration Studio

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

Dado que el SDK del Conector está disponible públicamente para los desarrolladores, es posible que su organización esté utilizando un conector no incluido aquí, creado por un socio o un externo mediante el SDK del Conector de Integration Studio. Estos conectores también podrían verse afectados por las vulnerabilidades de Apache Log4j. Póngase en contacto con el proveedor de dicho conector para comprobar si lo ha 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 abordar las vulnerabilidades de Apache Log4j2.

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

Tras la finalización del mantenimiento el 16 de diciembre de 2021 a las 17:00 PST (17 de diciembre de 2021 a las 12:00 AEDT; 17 de diciembre de 2021 a las 02:00 CET; 17 de diciembre de 2021 a la 01:00 UTC), deberá realizar los siguientes pasos para que la actualización entre en vigor:

En cada agente privado, debe eliminar manualmente todos los archivos JAR de <JITTERBIT_HOME>/Connectors. (La excepción serían cualquier archivo JAR para conectores que haya instalado localmente).
Cada agente privado debe reiniciarse.
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 reiniciaran 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 Connectors directorio para garantizar su protección contra estas vulnerabilidades. Puede verificar su protección 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 implementadas las medidas de mitigación para los agentes privados, puede confirmar su protección 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. Los nombres de archivo de la serie Log4j versión 2 deben reemplazarse por un nombre que indique que la versión es al menos la 2.16.0.

Para obtener más ayuda, contacte con soporte de Jitterbit.

Solución alternativa anterior para agentes privados

Esta solución alternativa se publicó antes del mantenimiento de emergencia del 16 de diciembre de 2021. Ya no es necesaria y las vulnerabilidades se solucionan reiniciando el 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 necesita hacer nada más.

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

Precaución

Se recomienda 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 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, se ubicará en esta ubicación:

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

Añada la siguiente línea inmediatamente después de las líneas de comentario al principio del archivo:
```
JAVA_OPTS="$JAVA_OPTS -Dlog4j2.formatMsgNoLookups=true"
```

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

Guarde los cambios en el archivo y salga del editor.
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.

Precaución

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

Siga estos pasos:

Detenga el agente privado de Windows.
Utilice la búsqueda de Windows para encontrar regedit y úselo para abrir el Editor del Registro.
Navegue hasta Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Apache Software Foundation\Procrun 2.0\Jitterbit Tomcat Server\Parameters\Java.
Modifique sus Opciones y agregue lo siguiente antes de -Xms Línea:
```
-Dlog4j2.formatMsgNoLookups=true
```
Ejemplo:
Salga del Editor del Registro.
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

attachment