A vulnerabilidade do Apache Log4J: questionário e dicas de VRM

O Apache Log4j 2, uma biblioteca de registro baseada em Java, foi afetado por uma vulnerabilidade de dia zero em 9 de dezembro de 2021. A vulnerabilidade, conhecida como Log4Shell e identificada pelo Instituto Nacional de Padrões e Tecnologia (NIST) como CVE-2021-44228, permite que os cibercriminosos assumam o controle de sistemas e servidores vulneráveis.

Muitos aplicativos da web, plataformas de nuvem de código aberto e provedores de serviços utilizam o Log4j. Esse uso generalizado pode expor a superfície de ataque interna da sua organização e o ecossistema de terceiros à vulnerabilidade do Log4Shell. Para proteger sistemas e dados críticos de forma eficaz, sua organização precisa avaliar o uso interno do Log4j e o uso da biblioteca de registro em log pelo fornecedor.

Continue lendo para descobrir 11 perguntas que sua equipe de gerenciamento de risco de fornecedores pode usar para determinar como os fornecedores usam o Log4j em sua cadeia de suprimentos de terceiros e como isso pode afetar a postura de segurança de sua organização.

Saiba mais sobre o UpGuard Vendor Risk: a solução de gerenciamento de risco de fornecedor #1 do mundo>

Resumo da vulnerabilidade do Log4Shell

Em dezembro de 2021, pesquisadores de segurança anunciaram uma falha crítica de segurança na estrutura Apache Log4j, permitindo que hackers mal-intencionados comprometessem sistemas vulneráveis por meio de uma única injeção de código.

Durante os primeiros dias de impacto, os pesquisadores de segurança identificaram aproximadamente 10 milhões de tentativas de exploração do Log4Shell a cada hora. Vários setores são vulneráveis ao Log4Shell porque muitos produtos e softwares digitais, incluindo aplicativos Microsoft e IOS, utilizam Java.

O setor de varejo foi o mais afetado pela vulnerabilidade Log4Shell, mas outros setores, incluindo tecnologia, serviços financeiros, manufatura e saúde, também foram afetados.

Corrigindo a vulnerabilidade do Log4J

A Apache começou a desenvolver um patch para o Log4Shell rapidamente depois de tomar conhecimento da vulnerabilidade em dezembro de 2021. No entanto, o Log4j ainda apresenta riscos de segurança significativos, devido ao seu uso generalizado.

Qualquer versão do Log4j 2 anterior à 2.17.1 é vulnerável à vulnerabilidade Log4Shell. Para se protegerem efetivamente contra essa vulnerabilidade, as organizações devem abordar qualquer versão vulnerável do Log4j 2 em uso em sua infraestrutura interna e ecossistemas de terceiros.

As equipes de segurança podem seguir o seguinte protocolo para resolver a vulnerabilidade:

Atualização para a versão mais recente do Log4j 2
Executar verificações de vulnerabilidade usando um scanner
Atualizar propriedades do sistema Java
Desativar JNDI
Enviar um questionário do Apache Log4j aos fornecedores
Empregue autenticação multifator

Leitura recomendada: Log4Shell: a vulnerabilidade do Log4J claramente explicada

Vulnerabilidades relacionadas ao Log4J

Enquanto o Apache trabalhava para resolver a vulnerabilidade do Log4Shell, pesquisadores e agentes de ameaças descobriram falhas adicionais em várias versões do Log4j. O NIST identificou essas falhas com os seguintes códigos:

CVE-2021-45046: permite que os cibercriminosos enviem pesquisas JNDI maliciosas, presentes no Log4j 2.15 e versões anteriores

CVE-2021-45105: permite que os cibercriminosos implantem ataques de negação de serviço por meio de mensagens maliciosas, presentes no Log4j 2.16 e versões anteriores

CVE-2021-44832: uma vulnerabilidade de execução remota de código (RCE) que permite que hackers explorem sistemas com código arbitrário se tiverem permissões elevadas, presente no Log4j 2.17 e versões anteriores

11 perguntas do Apache Log4J para fazer aos seus fornecedores

Os questionários de segurança são uma das maneiras mais eficazes de uma organização avaliar a postura de segurança de seus fornecedores terceirizados. Sua organização pode usar as 11 perguntas a seguir para criar um questionário de segurança para identificar versões desatualizadas do Log4j em todo o ecossistema de fornecedores.

Descubra a robusta biblioteca de questionários de segurança do UpGuard>

1. Sua organização executa alguma versão do Log4j 2?

Sim
Não
[Abra o campo de texto para comentários do fornecedor]

2. Sua organização atualizou para o Log4j 2.17.1 conforme recomendado pela Apache Software Foundation e pela CISA?

Sim, a organização atualizou para o Log4j 2.17.1
Não, a organização não pode atualizar para o Log4j 2.17.1 (explique abaixo)
A organização ainda não atualizou para o Log4j 2.17.1
[Abra o campo de texto para comentários do fornecedor]

3. Em caso negativo, qual versão do Log4j 2 sua organização executa atualmente?

A organização utiliza uma versão do Log4j 2 entre 2.7 e 2.14.1 (prossiga para a pergunta 3)
A organização utiliza uma versão do Log4j 2 entre 2.0-beta9 e 2.10.0 (prossiga para a pergunta 4)
A organização utiliza o Log4j 2.17.1

4. Se sua organização utiliza uma versão do Log4j2 entre 2.7 e 2.14.1, os seguintes esforços de mitigação foram implementados:

a) A propriedade do sistema, log4j2.formatMsgNoLookups, ou a variável de ambiente, LOG4J_FORMAT_MSG_NO_LOOKUPS, foram definidas como true

b) Todos os padrões PatternLayout foram modificados para %m{nolookups} em vez de apenas %m

A organização implementou precauções a)
A organização implementou precauções b)
A organização implementou as precauções a) e b)
[Abra o campo de texto para comentários do fornecedor]

5. Se sua organização utiliza uma versão do Log4j2 entre 2.0-beta9 e 2.10.0, os seguintes esforços de mitigação foram implementados:

a) A propriedade do sistema, log4j2.formatMsgNoLookups, ou a variável de ambiente, LOG4J_FORMAT_MSG_NO_LOOKUPS, foram definidas como true

b) A classe JndiLookup foi retirada do caminho: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.

A organização implementou precauções a)
A organização implementou precauções b)
A organização implementou as precauções a) e b)
[Abra o campo de texto para comentários do fornecedor]

6. Sua organização usou o repositório GitHub da CISA para identificar ativos vulneráveis ao Log4Shell?

Sim
Não
[Abra o campo de texto para comentários do fornecedor]

7. Sua organização identificou algum indicador de comprometimento (IOCs) resultante da vulnerabilidade Log4Shell?

Sim (por favor, liste abaixo)
Não
[Abra o campo de texto para comentários do fornecedor]

8. Como a vulnerabilidade do Log4Shell afetou sua organização?

A vulnerabilidade não afetou a organização e não fomos expostos a ataques cibernéticos ou problemas de segurança resultantes da vulnerabilidade
A vulnerabilidade afetou moderadamente a organização, mas nenhum sistema, infraestrutura, serviços ou dados críticos foram afetados (explique abaixo)
A vulnerabilidade afetou diretamente os sistemas, infraestrutura, serviços e/ou dados críticos da organização (explique abaixo)
[Abra o campo de texto para comentários do fornecedor]

9. Sua organização tem um plano de resposta a incidentes para responder a ameaças cibernéticas?

Sim, a organização tem um plano de resposta a incidentes em vigor
A organização está em processo de finalização de um plano de resposta a incidentes dedicado
Não, a organização não possui um plano de resposta a incidentes em vigor
[Abra o campo de texto para comentários do fornecedor]

10. Com que frequência sua organização implanta avaliações de risco detalhadas para avaliar vulnerabilidades de segurança interna?

Anualmente
A cada seis meses
Conforme necessário, ou não temos uma cadência programada para avaliações de risco
[Abra o campo de texto para comentários do fornecedor]

11. Quem é o ponto de contato da sua organização para responder a perguntas e consultas adicionais?

Nome:
Título:
Email:
Telefone:
[Abra o campo de texto para comentários do fornecedor]

Como corrigir os riscos do fornecedor

Se sua organização implantar um questionário de segurança do Apache Log4j e descobrir que um fornecedor está executando uma versão vulnerável do Log4j 2, você deverá corrigir o risco imediatamente. Sua organização deve priorizar os esforços de correção com base na criticidade do fornecedor se vários fornecedores forem expostos.

Dependendo do nível de conscientização de segurança do fornecedor, sua organização pode precisar trabalhar junto com a equipe de segurança do fornecedor para implantar as atualizações e os protocolos de correção necessários.

Sua equipe pode seguir o seguinte fluxo de trabalho de correção ao identificar um fornecedor exposto:

Comunique-se com o ponto de contato identificado e solicite a correção
Sugira procedimentos de mitigação, como remover pesquisas JNDI, atualizar para a versão mais recente do Log4j, usar o repositório GitHub da CISA para inventariar fornecedores e outros recomendados pelo Apache e CISA
Comunique expectativas, cronogramas e consequências consultivas para falha de correção
Envie um novo questionário de segurança para verificar se o risco foi corrigido

Leitura recomendada: Escolhendo o software automatizado de remediação de riscos do fornecedor em 2024

A UpGuard é uma empresa de segurança cibernética dedicada a ajudar as equipes de segurança a proteger suas superfícies de ataque internas e de terceiros. Os dois produtos da UpGuard, Vendor Risk e BreachSight, permitem que as organizações melhorem sua higiene cibernética, avaliem a postura de segurança de fornecedores individuais e implantem protocolos robustos de gerenciamento de risco de fornecedores e gerenciamento de risco cibernético.

Os recursos de verificação e avaliação de vulnerabilidades do UpGuard permitem que as organizações identifiquem várias vulnerabilidades que podem afetar sua postura de segurança e levar a ataques cibernéticos, como malware ou ransomware.

O UpGuard Vendor Risk e o BreachSight incluem os seguintes recursos:

Detecção de vazamento de dados: proteja a reputação, a propriedade intelectual e os dados do cliente da sua marca com a detecção oportuna de vazamentos de dados
Monitoramento contínuo: obtenha atualizações em tempo real e gerencie exposições em toda a sua superfície de ataque, incluindo domínios, IPs, aplicativos, endpoints, plug-ins e firewalls
Redução da superfície de ataque: reduza sua superfície de ataque descobrindo vulnerabilidades exploráveis e domínios em risco de typosquatting
Perfil de segurança compartilhado: crie um perfil compartilhado do UpGuard para eliminar o incômodo de responder a questionários de segurança
Fluxos de trabalho e isenções: simplifique os fluxos de trabalho de correção, elimine riscos rapidamente e responda a consultas de segurança
Relatórios e insights: acesse relatórios personalizados para diferentes partes interessadas e visualize informações sobre sua superfície de ataque externa
Questionários de segurança do fornecedor: automatize questionários de segurança para obter uma visão mais profunda de seus relacionamentos com fornecedores e postura de segurança de terceiros
Classificações de segurança: avalie a postura de segurança de fornecedores individuais usando nossas classificações de segurança orientadas por dados, objetivas e dinâmicas
Avaliações de risco: simplifique os fluxos de trabalho de avaliação de risco, reúna evidências e solicite correção rapidamente