Mitigar a vulnerabilidade Apache Log4j2 JNDI no Jitterbit Harmony

Resumo

Esta página resume as vulnerabilidades do Apache Log4j2, descreve seu impacto nos produtos Jitterbit e explica como as vulnerabilidades foram mitigadas.

Descoberta de vulnerabilidades

Em 9 de dezembro de 2021, uma vulnerabilidade crítica de dia zero foi divulgada pela Apache que afeta o Apache Log4j2 (CVE-2021-44228). Uma vulnerabilidade relacionada adicional foi divulgada pela Apache em 14 de dezembro de 2021 (CVE-2021-45046).

Mitigação para agentes privados

Em 16 de dezembro de 2021, a Jitterbit realizou uma manutenção de emergência para resolver as vulnerabilidades do Apache Log4j2.

Após a conclusão da manutenção em 16 de dezembro de 2021 às 17h PST (17 de dezembro de 2021 12h AEDT; 17 de dezembro de 2021 2h CET; 2021‑12‑17 01:00 UTC), você deve executar as seguintes etapas para que a atualização entre em vigor:

Em cada agente privado, você deve excluir manualmente todos os arquivos JAR de <JITTERBIT_HOME>/Connectors. (A exceção seriam quaisquer arquivos JAR para conectores que você instalou localmente.)
Cada agente privado deve ser reiniciado.
Execute uma operação em que cada conector seja usado ou teste cada conexão para cada JAR do conector no agente.

Se você não tiver executado todas as etapas acima nesta ordem após a conclusão da manutenção, faça-o imediatamente para proteger sua organização dessas vulnerabilidades.

Uma versão anterior desta página instruía os usuários a reiniciar apenas os agentes privados. Reiniciar agentes privados é eficaz para a maioria dos conectores. No entanto, para alguns conectores, é necessário executar todas as etapas. Recomendamos excluir todos os arquivos JAR no Connectors diretório para garantir que você esteja protegido contra essas vulnerabilidades. Você pode verificar se está protegido pesquisando por log4j em quaisquer nomes de arquivo e verificando a versão do Log4j conforme descrito abaixo.

Solução alternativa anterior para agentes privados

Antes de 16 de dezembro de 2021, uma solução alternativa para abordar manualmente as vulnerabilidades foi publicada anteriormente nesta página antes da manutenção de emergência. Esta solução alternativa não é mais necessária para nenhuma versão de agente privado.

Se você já executou a solução alternativa, não precisa revertê-la. Se você não reiniciou os agentes privados desde que a manutenção de emergência foi concluída, você deve reiniciar os agentes para que eles recebam a atualização de manutenção de emergência. Nenhuma ação adicional além de reiniciar é recomendada com relação a essas vulnerabilidades.

Quais são as vulnerabilidades JNDI do Apache Log 4j2?

Do Banco de Dados Nacional de Vulnerabilidade do 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.

Uma vulnerabilidade relacionada é CVE-2021-45046, que descreve uma vulnerabilidade na biblioteca Log4j 2.15.0. Ambas as vulnerabilidades são cobertas e abordadas aqui.

Quais produtos Jitterbit foram afetados pelas vulnerabilidades?

Essas vulnerabilidades foram limitadas a Integration Studio conectores criados com o Integration Studio conector SDK ("Integration Studio conectores do SDK do conector").

Como os conectores não são normalmente considerados produtos Jitterbit autônomos e devem ser executados em um agente Jitterbit, algumas explicações são necessárias para explicar o impacto e as etapas de mitigação para abordar essas vulnerabilidades:

O que é an Integration Studio conector SDK Conector?
Integration Studio os conectores do Connector SDK são conectores construídos com o Integration Studio conector SDK. Eles atualmente incluem certos conectores construídos pela Jitterbit ou por terceiros:
- Jitterbit: A maioria dos conectores atuais Integration Studioconectores de aplicação foram criados usando o Connector SDK. As exceções incluem os conectores NetSuite, Salesforce, Salesforce Service Cloud, SAP e ServiceMax, que não foram criados usando o Connector SDK e não são afetados. Veja a lista completa abaixo dos conectores Jitterbit afetados por essas vulnerabilidades. Os conectores futuros criados pelo Jitterbit usando o Connector SDK não serão afetados.
- Terceiros: Como o Connector SDK está disponível publicamente para criação Integration Studio conectores, sua organização pode estar usando conectores adicionais criados com o Connector SDK por um parceiro ou terceiro e também pode ser afetada por essas vulnerabilidades. Entre em contato com o provedor desse conector para determinar se eles avaliaram e, se necessário, corrigiram seu conector.
Como esses conectores estão relacionados aos agentes?
A versão mais recente do an Integration Studio O conector do SDK do conector é baixado por um agente Jitterbit conforme necessário do Harmony quando você usa o conector.
Quais agentes foram afetados?
Qualquer agente de nuvem ou privado que estava usando an Integration Studio o conector do SDK do conector foi impactado pelas vulnerabilidades, pois a biblioteca Apache Log4j2 foi baixada e usada no agente para gravar logs quando o conector estava sendo usado.
- Agentes de nuvem: Em agentes de nuvem, a Jitterbit imediatamente abordou essas vulnerabilidades por meio de controles de segurança apropriados. Nenhuma ação adicional é necessária.
- Agentes privados: Em agentes privados, antes da manutenção de emergência em 16 de dezembro de 2021, os clientes foram instruídos a seguir a solução alternativa documentada anteriormente para abordar essas vulnerabilidades.

Esses produtos Jitterbit não foram afetados:

Agentes que nunca usaram an Integration Studio Conector SDK Conector: Não afetado.
Jitterbit Design Studio (e seus conectores): Não afetado.
Jitterbit Harmony Cloud: Não afetado.
Jitterbit eiCloud: Não afetado.

Jitterbit Integration Studio conectores do SDK do conector

A seguir está uma lista de todos Integration Studio conectores a partir de 16 de dezembro de 2021 que foram criados pela Jitterbit com o Integration Studio Connector SDK e são afetados pelas vulnerabilidades do Apache Log4j.

Como o Connector SDK está disponível publicamente para desenvolvedores, sua organização pode estar usando um conector não listado aqui que foi criado por um parceiro ou externo usando o Integration Studio Connector SDK. Esses conectores também podem ser afetados pelas vulnerabilidades do Apache Log4j. Entre em contato com o provedor desse conector para descobrir se eles avaliaram e, se necessário, corrigiram seu conector.

O que a manutenção de 16 de dezembro de 2021 fez?

Em 16 de dezembro de 2021, a Jitterbit realizou uma manutenção de emergência para abordar as vulnerabilidades do Apache Log4j2.

Como parte da manutenção, a Jitterbit atualizou o Integration Studio conectores criados com o Connector SDK para usar uma versão disponível da biblioteca Log4j que abordou as duas vulnerabilidades do Apache Log4j.

Após a conclusão da manutenção em 16 de dezembro de 2021 às 17h PST (17 de dezembro de 2021 12h AEDT; 17 de dezembro de 2021 2h CET; 2021‑12‑17 01:00 UTC), você deve executar as seguintes etapas para que a atualização entre em vigor:

Em cada agente privado, você deve excluir manualmente todos os arquivos JAR de <JITTERBIT_HOME>/Connectors. (A exceção seriam quaisquer arquivos JAR para conectores que você instalou localmente.)
Cada agente privado deve ser reiniciado.
Execute uma operação onde o conector é usado ou teste a conexão.

Se você não tiver executado todas as etapas acima nesta ordem após a conclusão da manutenção, faça-o imediatamente para proteger sua organização dessas vulnerabilidades.

Uma versão anterior desta página instruía os usuários a reiniciar apenas agentes privados. Reiniciar agentes privados é eficaz para a maioria dos conectores. No entanto, para alguns conectores, é necessário executar todas as etapas. Recomendamos excluir todos os arquivos JAR no Connectors diretório para garantir que você esteja protegido contra essas vulnerabilidades. Você pode verificar se está protegido pesquisando por log4j em quaisquer nomes de arquivo e verificando a versão do Log4j conforme descrito abaixo.

Como posso confirmar a proteção contra essas vulnerabilidades?

Depois de implementar as etapas de mitigação para agentes privados, você pode confirmar que está protegido pesquisando os subdiretórios de instalação do agente para nomes de arquivos que incluem log4j.

Quaisquer nomes de arquivo anteriores que incluam log4j e um número de série da versão 2, como log4j-api-2.11.1.jar, não deve mais estar presente. Todos os nomes de arquivo da série Log4j versão 2 agora devem ser substituídos por um nome que indique que a versão é pelo menos 2.16.0.

Para obter mais assistência, entre em contato com suporte Jitterbit.

Solução alternativa anterior para agentes privados

Esta solução alternativa foi publicada anteriormente antes da manutenção de emergência em 16 de dezembro de 2021. Esta solução alternativa não é mais necessária e as vulnerabilidades são abordadas com uma reinicialização do agente após a manutenção de 16 de dezembro de 2021. Se você já executou esta solução alternativa e reiniciou os agentes privados, nenhuma ação adicional é necessária.

Para clientes com agentes privados, as seguintes etapas foram recomendadas anteriormente para proteção contra as vulnerabilidades do Apache Log4j.

Cuidado

É uma prática recomendada ter agentes privados atrás de um firewall sem portas de entrada. Isso protege contra exploits de entrada.
Essas configurações serão substituídas ao atualizar ou melhorar.

Agente privado Linux

Para agentes privados do Linux, a solução manual é editar o script de inicialização do servidor Tomcat.

O arquivo a ser alterado é catalina.sh, localizado em <JITTERBIT_HOME>/tomcat/bin/catalina.sh. Em uma instalação típica, isso estará localizado neste local:

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

Adicione a seguinte linha imediatamente após as linhas de comentário no início do arquivo:
```
JAVA_OPTS="$JAVA_OPTS -Dlog4j2.formatMsgNoLookups=true"
```

Por exemplo:

. . .
# case the default is "true"
# -----------------------------------------------------------------------------
JAVA_OPTS="$JAVA_OPTS -Dlog4j2.formatMsgNoLookups=true"

# OS specific support. $var _must_ be set to either true or false.
. . .

Salve a alteração no arquivo e saia do seu editor.
Reinicie o agente privado:
```
> jitterbit stop
> jitterbit start
```

Verificação da Mudança

Para verificar os resultados desta mudança, execute o comando ps -ef | grep javae procure na saída por -Dlog4j2.formatMsgNoLookups=true.

Agente privado do Windows

Para agentes privados do Windows, você precisará editar o registro.

Cuidado

Alterar o registro do Windows incorretamente pode afetar o Sistema Operacional Windows. Tenha cuidado ao fazer essas alterações.

Siga estes passos:

Pare o agente privado do Windows.
Use a Pesquisa do Windows para encontrar regedit e use-o para abrir o Editor do Registro.
Navegue até Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Apache Software Foundation\Procrun 2.0\Jitterbit Tomcat Server\Parameters\Java.
Modifique suas Opções e adicione o seguinte antes de -Xms linha:
```
-Dlog4j2.formatMsgNoLookups=true
```
Exemplo:
Saia do Editor do Registro.
Reinicie o agente privado do Windows.

Verificação da Mudança

Para verificar os resultados desta alteração:

Abra o Bloco de Notas (ou editor similar).

Abra o arquivo de log mais recente, localizado em:

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

Pesquisar por -Dlog4j2.formatMsgNoLookups=true para verificar se o argumento da linha de comando está sendo usado.

Exemplo de saída de verificação

anexo