Vulnerabilidades de segurança CVE-2021-44228 e CVE-2021-45046 foram divulgadas no Apache Log4j nas versões 2.0 a 2.15 da biblioteca. 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 em execução as versões 2.0 a 2.15 do Apache Log4j sejam comprometidas e o invasor executa 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 o Google Cloud Armor, as políticas de segurança e o controle de acesso do Identity-Aware Proxy estão configurados corretamente e operando conforme o esperado, bloqueando as tentativas de exploração do Log4j2.
- 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 os registros que já foram armazenados em buckets de registros e também estão dentro do intervalo e limites de retenção. 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 conferir os principais endereços IP remotos que enviam solicitações correspondentes no painel Campos de registro:
Isso fornece um detalhamento de onde essas verificações de exploração de vulnerabilidade do Log4j 2 estão vindo. Alguns deles podem ser verificações legítimas de um aplicativo ferramenta de verificação de vulnerabilidades que você possa ter 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.
Procurar aplicativos visados e verificar técnicas de mitigação
Também é possível agregar os aplicativos segmentados e identificar se solicitações maliciosas realmente alcançaram 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 uma das seguintes opções:
resultados da entrada de registro, expanda resource.labels, clique no botão resource.labels.backend_service_name
Valor do campo e, em seguida, selecione Adicionar campo ao painel de campos de registros.
Agora você pode ver seus principais aplicativos ou serviços de back-end sendo segmentados por
Verificações de exploração do Log4j2. 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 protegida por proxy para o back-end ou bloqueada por serviços como o IAP ou o Google Cloud Armor. Clique no jsonPayload.statusDetails
no resultado da entrada de registro e selecione Adicionar campo ao painel de campos de registros.
Agora é possível ver um detalhamento de como as solicitações foram processadas no painel Campos de registro:
Neste 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 (ou como alternativa), se
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 do Google Cloud Armor têm 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. Este alerta pode ser encaminhado para o o centro de operações de segurança (SOC) da organização equipe.
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 Configure 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: