As vulnerabilidades de segurança CVE-2021-44228 e CVE-2021-45046 foram divulgadas nas versões 2.0 a 2.15 da biblioteca do Apache Log4j. O utilitário Apache Log4j é um componente usado com frequência para pedidos de registros. Essa vulnerabilidade, também chamada de Log4Shell, pode permitir que um sistema que executa as versões 2.0 a 2.15 do Apache Log4j seja comprometido e permitir que um invasor execute um código arbitrário.
Essa vulnerabilidade não afeta o Cloud Logging ou os agentes que ela fornece para coletar registros de aplicativos de terceiros, mas, se você usar o Log4j 2, seus serviços poderão ser afetados.
Use o Cloud Logging para identificar possíveis ataques. Este documento explica como fazer o seguinte:
- Consulte seus registros usando o Explorador de registros para identificar tentativas de explorar a vulnerabilidade do Log4j 2.
- Confirme se as técnicas de mitigação ativadas, como as políticas de segurança do Google Cloud Armor e o controle de acesso do Identity-Aware Proxy, estão configuradas corretamente e funcionando conforme o esperado, bloqueando essas tentativas de exploração do Log4j 2.
- Crie uma política de alertas para receber uma notificação quando uma mensagem de exploração possível é gravada nos seus registros.
Leia a Consultoria de segurança Log4j 2 do Google Cloud para nossa avaliação atual de produtos e serviços. É possível avaliar sua exposição lendo o relatório de vulnerabilidade do Instituto Nacional de Padrões e Tecnologia (NIST, na sigla em inglês) paraCVE-2021-44228 de dados.
Detecção do Cloud Logging
Os resultados das consultas do Cloud Logging incluem apenas registros que já foram armazenados em buckets de registros e também estão dentro dos limites de retenção especificados pelo usuário. Embora a maioria dos serviços do Google Cloud tenha registros ativados por padrão, os registros que foram desativados ou excluídos não são incluídos nas consultas. Recomendamos ativar os registros em seu ambiente para expandir sua visibilidade no ambiente.
Se você estiver usando um balanceador de carga HTTP(S), será necessário ativar a geração de registros para que os registros da solicitação estejam disponíveis no Cloud Logging. Da mesma forma, se você tiver servidores da Web, como Apache ou NGINX em execução em uma VM, mas não tiver instalado o agente de operações ou o agente do Logging, esses registros não poderão ser acessados no Cloud Logging.
Consultar os registros
Você pode usar o Explorador de registros para ajudar a detectar possíveis ataques
no serviço que exploram a vulnerabilidade Log4j 2. Se você estiver usando o Cloud Logging para registrar solicitações em seu serviço, poderá verificar os campos httpRequest com conteúdo gerado pelo usuário para possíveis explorações.
Os valores nos campos httpRequest podem ter tokens de string como ${jndi:ldap://, mas há muitas variações em como essa vulnerabilidade está sendo explorada.
Por exemplo, há muitas maneiras de usar escape ou Unicode para evitar detecção.
As seguintes strings mostram alguns exemplos comuns que indicam tentativas de exploração
no seu sistema. Mas isso não é um conjunto completo de variantes:
${jndi:
$%7Bjndi:
%24%7Bjndi:
${jNdI:ldAp
${jndi:${lower:l}${lower:d}${lower:a}${lower:p}:
${${lower:j}${lower:n}${lower:d}i:
${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}:
${${env:BARFOO:-j}ndi${env:BARFOO:-:}${env:BARFOO:-l}dap${env:BARFOO:-:}
É possível criar consultas no Explorador de registros que verificam algumas das possíveis strings de exploração. Por exemplo, a consulta a seguir tenta corresponder várias variações ofuscadas da string ${jndi: em campos httpRequest nos registros de solicitação do balanceador de carga HTTP(S). As expressões regulares usadas na consulta não detectam todas as variações e podem levar a falsos positivos:
resource.type="http_load_balancer"
httpRequest.requestUrl=~"(?i)(\$|\%24)(\{|\%7b).*j.*n.*d.*i.*(\:|\%3a)" OR
httpRequest.userAgent=~"(?i)(\$|\%24)(\{|\%7b).*j.*n.*d.*i.*(\:|\%3a)" OR
httpRequest.referer=~"(?i)(\$|\%24)(\{|\%7b).*j.*n.*d.*i.*(\:|\%3a)"
Use a consulta anterior para verificar registros de solicitação em outros serviços alterando o valor de resource.type.
A consulta anterior pode levar muito tempo para ser concluída quando você está verificando
um grande volume de registros. Para agilizar a execução das consultas, use campos indexados como resource.type, resource.labels ou logName para restringir a consulta a um conjunto. de serviços ou streams de registros específicos.
A detecção de entradas de registro correspondentes não significa que houve comprometimento na conclusão. Se algo for detectado, recomendamos que você siga o processo de resposta a incidentes da sua organização. Uma correspondência pode indicar que alguém está tentando explorar a vulnerabilidade dentro do seu projeto ou carga de trabalho. Ou pode ser um falso positivo, se seu aplicativo usa padrões como ${jndi: nos campos de solicitação HTTP. Verifique seus registros para garantir que esse padrão não faça parte do comportamento normal do aplicativo.
Refine a consulta para que faça sentido para seu ambiente.
pesquisar endereços IP ofensivos;
Se você encontrar resultados correspondentes e quiser agregar os endereços IP remotos que enviam essas solicitações, adicione o campo remoteIp ao painel Campos de registro no Explorador de registros. Para adicionar o campo remoteIp,
clique no valor do campo em uma entrada de registro correspondente e selecione Adicionar campo ao painel de campos de registros, conforme mostrado na captura de tela a seguir:
Agora é possível ver os principais endereços IP remotos enviando solicitações correspondentes no painel Campos de registro:
Isso fornece um detalhamento da origem das verificações de exploração de vulnerabilidade do Log4j 2. Algumas podem ser verificações legítimas de uma ferramenta de verificação de vulnerabilidades de aplicativos que você tenha configurado, como o Web Security Scanner. Se você estiver usando o Web Security Scanner do Security Command Center, anote os intervalos de endereços IP estáticos usados pelo Web Security Scanner.
Pesquise os aplicativos de destino e verifique as técnicas de mitigação
Convém também agregar os aplicativos de destino e identificar se as solicitações mal-intencionadas realmente chegaram aos seus aplicativos. Se você tiver ativado técnicas de mitigação usando políticas de segurança pelo Google Cloud Armor ou controle de acesso por Identity-Aware Proxy (IAP), também será possível verificar se elas funcionam como esperado com base nas informações registradas nos registros do balanceador de carga HTTP(S).
Primeiro, para adicionar o aplicativo de destino ao painel Campos de registro, escolha um dos
resultados da entrada de registro, expanda resource.labels, clique no valor do campo resource.labels.backend_service_name
e selecione Adicionar campo ao painel Campos de registros.
Agora é possível conferir seus principais aplicativos ou serviços de back-end sendo segmentados pelas
verificações de exploração Log4j 2. Para determinar se essas tentativas de exploração chegaram ao seu
serviço de back-end, use o campo jsonPayload.statusDetails preenchido pelo balanceador de carga HTTP(S) para
saber se a solicitação foi enviada por proxy para o back-end ou bloqueada por
serviços como IAP ou Google Cloud Armor. Clique no valor do campo jsonPayload.statusDetails no resultado da entrada de registro e selecione Adicionar campo ao painel de campos de registros.
Agora é possível conferir um detalhamento de como as solicitações foram processadas no painel Campos de registro:
Nesse exemplo, a maioria das solicitações foi bloqueada pelo IAP, que, quando ativado em um serviço de back-end, verifica a identidade do usuário e usa o contexto antes de permitir o acesso. Essas solicitações bloqueadas pelo IAP têm statusDetails definido como handled_by_identity_aware_proxy. Além disso, ou como alternativa, se
você estiver usando o Google Cloud Armor com a política de segurança correta anexada a um serviço de back-end,
todas as solicitações bloqueadas do Google Cloud Armor terão statusDetails definido como denied_by_security_policy.
Saiba como aplicar a nova regra pré-configurada cve-canary do WAF às políticas de segurança do
Google Cloud Armor em Regra do WAF do Google Cloud Armor para ajudar a reduzir a vulnerabilidade do Apache Log4j.
Para filtrar todas as solicitações permitidas que realmente chegam a um serviço de back-end, selecione response_sent_by_backend
em statusDetails no painel Campos de registro. Considere ativar o IAP para esses serviços de back-end
e/ou aplicar uma política de segurança do Google Cloud Armor com a regra pré-configurada cve-canary do WAF para ajudar a bloquear essas tentativas de exploração.
criar um alerta baseado em registros;
Depois de projetar uma consulta que encontre registros afetados no serviço, use essa consulta para criar um alerta baseado em registro que notificará você quando novas entradas de registro corresponderem à consulta. Esse alerta pode ser encaminhado ao centro de operações de segurança (SOC, na sigla em inglês) da sua organização ou à equipe apropriada de resposta a incidentes.
Para informações sobre como criar um alerta baseado em registro, consulte Criar um alerta baseado em registro (Explorador de registros). Ao criar um alerta, use a consulta para a string de exploração em vez da consulta especificada no exemplo.
Criar uma política de alertas para uma métrica com base em registros
Para monitorar quais endpoints ou serviços estão registrando possíveis tentativas de exploração, crie uma política de alertas em uma métrica baseada em registro:
Crie uma métrica com base em registros para contar as ocorrências de possíveis strings de exploração nos registros. Por exemplo, é possível usar a Google Cloud CLI para criar essa métrica:
gcloud logging metrics create log4j_exploits \ --description="Detect log4j exploits" \ --log-filter='httpRequest.requestUrl=~"(?i)(\$|\%24)(\{|\%7b).*j.*n.*d.*i.*(\:|\%3a)" OR httpRequest.userAgent=~"(?i)(\$|\%24)(\{|\%7b).*j.*n.*d.*i.*(\:|\%3a)" OR httpRequest.referer=~"(?i)(\$|\%24)(\{|\%7b).*j.*n.*d.*i.*(\:|\%3a)"'Para mais informações sobre como criar métricas com base em registros, consulte Configurar métricas de contador.
Crie uma política de alertas para receber uma notificação quando um número selecionado de ocorrências for atingido. Para mais informações sobre como configurar uma política de alertas, consulte Criar uma política de alertas em uma métrica de contador.
A seguir
Verifique este documento para ver atualizações quando novas informações forem disponibilizadas.
Para mais informações sobre a vulnerabilidade do Log4j 2 e os serviços do Google Cloud, consulte: