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, permite que um sistema que executa as versões 2.0 a 2.15 do Apache Log4j seja comprometido e permita que um invasor execute o 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 Proxy Aware-Aware, estão configuradas corretamente e funcionando como 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 da consulta do Cloud Logging incluem apenas registros que já foram armazenados em buckets de registro e que 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 incorretos
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 "Campos de registros", conforme mostrado na captura de tela a seguir:
Agora é possível conferir os principais endereços IP remotos que enviam solicitações correspondentes no painel Campos de registro:
Isso mostra de onde vêm as verificações de exploração de vulnerabilidade do Log4j 2. Algumas delas podem ser verificações legítimas de uma ferramenta de verificação de vulnerabilidades de aplicativo que você configurou, como o Web Security Scanner. Se você estiver usando o Web Security Scanner no Security Command Center, anote os intervalos de endereços IP estáticos usados por ele.
Pesquisar aplicativos segmentados e verificar técnicas de mitigação
Você também pode agregar os aplicativos de destino e identificar se solicitações maliciosas realmente chegaram aos seus aplicativos. Se você tiver ativado técnicas de mitigação usando políticas de segurança do Google Cloud Armor ou controle de acesso pelo Identity-Aware Proxy (IAP), também poderá verificar se elas funcionam conforme o 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 de 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 você pode conferir os principais aplicativos ou serviços de back-end que estão sendo direcionados por
verificações de exploração do 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 usada como proxy para o back-end ou se foi bloqueada por serviços como o IAP ou o Google Cloud Armor. Clique no valor do campo jsonPayload.statusDetails
do resultado da entrada de registro e selecione Adicionar campo ao painel "Campos de registro".
Agora você pode 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 o contexto de uso
antes de permitir o acesso. Essas solicitações bloqueadas pelo IAP têm statusDetails
definido como handled_by_identity_aware_proxy. Além disso, se você usar 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 pelo Google Cloud Armor terão statusDetails definido como denied_by_security_policy.
Para saber como aplicar a nova regra WAF cve-canary pré-configurada às suas políticas de segurança do Google Cloud Armor, consulte A regra do WAF do Google Cloud Armor para ajudar a mitigar a vulnerabilidade do Apache Log4j.
Para filtrar 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. Ative o IAP para esses serviços de back-end
e/ou aplique uma política de segurança do Google Cloud Armor com a regra WAF cve-canary pré-configurada 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 para a central de operações de segurança (SOC) da sua organização ou para a 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, use a Google Cloud CLI para criar uma métrica assim:
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: