As vulnerabilidades de segurança CVE-2021-44228 e CVE-2021-45046 foram divulgadas nas versões 2.0 a 2.15 da biblioteca 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 Cloud Armor e o controle de acesso do Identity-Aware Proxy, 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 Cloudpara nossa avaliação atual de produtos e serviços Google Cloud . É 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 de registros
Os resultados da consulta do Logging incluem apenas registros que já foram armazenados em buckets de registros 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 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 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 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 "Campos de registros", como mostrado na captura de tela a seguir:
Agora é possível ver os principais endereços IP remotos que enviam solicitações correspondentes no painel Campos de registro:
Isso mostra de onde vêm essas 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 aplicativos 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 pelo Web Security Scanner.
Pesquisar aplicativos segmentados e verificar técnicas de mitigação
Você também pode agregar nos aplicativos segmentados e identificar se as solicitações maliciosas realmente chegaram aos seus aplicativos. Se você ativou técnicas de mitigação usando políticas de segurança do Cloud Armor ou controle de acesso do Identity-Aware Proxy (IAP), também é 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 segmentado 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 registro".
Agora é possível ver os principais aplicativos ou serviços de back-end que estão sendo segmentados 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 encaminhada por proxy para o back-end ou bloqueada com sucesso por serviços como o IAP ou o Cloud Armor. Clique no valor do campo jsonPayload.statusDetails no resultado da entrada de registro e selecione Adicionar campo ao painel "Campos de registros".
Agora é possível conferir 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 você usar o Cloud Armor com a política de segurança correta anexada a um serviço de back-end, todas as solicitações bloqueadas pelo Cloud Armor terão statusDetails definido como denied_by_security_policy. Para saber como
aplicar a nova regra do WAF cve-canary pré-configurada às suas políticas de segurança do Cloud Armor, consulte
Regra do WAF do Google Cloud Armor para ajudar a mitigar 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 a IAP para esses serviços de back-end e aplicar
uma política de segurança do Cloud Armor com a regra cve-canary do WAF
pré-configurada para ajudar a bloquear essas tentativas de exploração.
Criar uma política de alertas baseada em registros
Depois de projetar uma consulta que encontre registros afetados no serviço, use essa consulta para criar uma política de alertas baseada em registro que notifique você quando novas entradas de registro corresponderem à consulta. Os incidentes criados pela política de alertas podem ser encaminhados 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 uma política de alertas com base em registros, consulte Criar uma política de alertas com base em registros (Análise de registros). Ao criar a política de alertas, use sua 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 doGoogle Cloud , consulte: