Foram divulgadas as vulnerabilidades de segurança CVE-2021-44228 e CVE-2021-45046 nas versões 2.0 a 2.15 da biblioteca Apache Log4j. O utilitário Apache Log4j é um componente frequentemente utilizado para registar pedidos. Esta vulnerabilidade, também denominada Log4Shell, pode permitir que um sistema com as versões 2.0 a 2.15 do Apache Log4j seja comprometido e que um atacante execute código arbitrário.
Esta vulnerabilidade não afeta o Cloud Logging nem os agentes que fornece para recolher registos de aplicações de terceiros, mas se usar o Log4j 2, os seus serviços podem ser afetados.
Pode usar o registo para identificar possíveis ataques. Este documento descreve como:
- Consulte os seus registos através do Explorador de registos para ver tentativas existentes 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 controlo de acesso do Identity-Aware Proxy, estão configuradas corretamente e a funcionar como esperado, bloqueando estas tentativas de exploração do Log4j 2.
- Crie uma política de alertas para receber uma notificação quando uma possível mensagem de exploração for escrita nos seus registos.
Reveja o Google Cloudaviso de segurança do Log4j 2 da Review Google Cloud para a nossa avaliação atual de produtos e serviços. Pode avaliar a sua exposição lendo o relatório de vulnerabilidade do Instituto Nacional de Padrões e Tecnologia (NIST) para CVE-2021-44228.
Deteção de registo
Os resultados da consulta de registo incluem apenas registos que já foram armazenados em contentores de registos e que também estão dentro dos limites de retenção especificados pelo utilizador. Embora a maioria dos Google Cloud serviços tenha registos ativados por predefinição, os registos que foram desativados ou excluídos não são incluídos nas suas consultas. Recomendamos que ative os registos no seu ambiente para expandir a visibilidade do ambiente.
Se estiver a usar um balanceador de carga de HTTP(S), tem de ter o registo ativado para que os registos de pedidos estejam disponíveis no registo. Da mesma forma, se tiver servidores Web, como o Apache ou o NGINX, a serem executados numa VM, mas não tiver instalado o agente de operações ou o agente de registo, esses registos não estarão acessíveis no Logging.
Consultar os seus registos
Pode usar o Explorador de registos para ajudar a detetar potenciais ataques ao seu serviço que explorem a vulnerabilidade do Log4j 2. Se estiver a usar o registo para registar pedidos ao seu serviço, pode verificar os campos httpRequest com conteúdo gerado pelo utilizador para potenciais explorações.
Os valores nos campos httpRequest podem ter tokens de string, como ${jndi:ldap://, mas existem muitas variações na forma como esta vulnerabilidade está a ser explorada.
Por exemplo, existem muitas formas de usar a substituição de carateres ou o Unicode para evitar a deteção.
As seguintes strings mostram alguns exemplos comuns que indicam tentativas de exploração contra o seu sistema, mas não representam um conjunto exaustivo 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:-:}
Pode criar consultas no Explorador de registos que analisam algumas das possíveis strings de exploração. Por exemplo, a seguinte consulta tenta encontrar várias variações ocultadas da string ${jndi: em campos httpRequest nos registos de pedidos do balanceador de carga HTTP(S). Tenha em atenção que as expressões regulares usadas na consulta não detetam todas as variações e podem gerar 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)"
Pode usar a consulta anterior para analisar os registos de pedidos noutros serviços alterando o valor de resource.type.
A consulta anterior pode demorar muito tempo a ser concluída quando está a analisar um grande volume de registos. Para executar as suas consultas mais rapidamente, pode usar campos indexados, como resource.type, resource.labels ou logName, para restringir a consulta a um conjunto de serviços ou streams de registo específicos.
A deteção de entradas de registo correspondentes não significa que houve uma
comprometimento bem-sucedido. Se for detetado algo, recomendamos que siga o processo de resposta a incidentes da sua organização. Uma correspondência pode indicar que alguém está a sondar para explorar a vulnerabilidade no seu projeto ou carga de trabalho. Em alternativa, pode ser um falso positivo se a sua aplicação usar padrões como ${jndi: nos campos de pedidos HTTP. Consulte os registos para garantir que este padrão não faz parte do comportamento normal da aplicação.
Refine a consulta para que faça sentido para o seu ambiente.
Pesquise endereços IP ofensivos
Se encontrar resultados correspondentes e quiser agregar os endereços IP remotos que enviam esses pedidos, adicione o campo remoteIp ao painel Campos de registo no Explorador de registos. Para adicionar o campo remoteIp,
clique no valor do campo numa entrada de registo correspondente e selecione
Adicionar campo ao painel Campos de registos, conforme mostrado na captura de ecrã seguinte:
Agora, pode ver os principais endereços IP remotos que enviam pedidos com correspondência no painel Campos de registo:
Isto dá-lhe uma análise detalhada da origem destas análises de exploração de vulnerabilidades do Log4j 2. Algumas destas podem ser análises legítimas de uma ferramenta de análise de vulnerabilidades de aplicações que pode ter configurado, como o Web Security Scanner. Se estiver a usar o Web Security Scanner a partir do Security Command Center, tenha em atenção os intervalos de endereços IP estáticos usados pelo Web Security Scanner.
Pesquise aplicações segmentadas e valide técnicas de mitigação
Também pode querer agregar nas aplicações segmentadas e identificar se os pedidos maliciosos chegaram efetivamente às suas aplicações. Se tiver ativado técnicas de mitigação através de políticas de segurança do Cloud Armor ou controlos de acesso do Identity-Aware Proxy (IAP), também pode verificar se funcionam conforme esperado a partir das informações registadas nos registos do balanceador de carga de HTTP(S).
Primeiro, para adicionar a aplicação segmentada ao painel Campos de registo, escolha um dos resultados de entrada de registo, expanda resource.labels, clique no valor do campo resource.labels.backend_service_name e, de seguida, selecione Adicionar campo ao painel Campos de registos.
Agora, pode ver as suas principais aplicações ou serviços de back-end que estão a ser segmentados por análises de exploração de vulnerabilidades do Log4j 2. Para determinar se estas tentativas de exploração chegaram sequer ao seu serviço de back-end, use o campo jsonPayload.statusDetails preenchido pelo balanceador de carga HTTP(S) para saber se o pedido foi encaminhado para o back-end ou bloqueado com êxito por serviços como o IAP ou o Cloud Armor. Clique no valor do campo jsonPayload.statusDetails no resultado da entrada do registo e selecione Adicionar campo ao painel Campos de registos.
Agora, pode ver uma discriminação de como os pedidos foram processados no painel Campos de registo:
Neste exemplo, a maioria dos pedidos foi bloqueada pela IAP, que, quando ativada num serviço de back-end, valida a identidade do utilizador e o contexto de utilização antes de permitir o acesso. Esses pedidos bloqueados de IAP têm statusDetails definido como handled_by_identity_aware_proxy. Além disso (ou em alternativa), se usar o Cloud Armor com a política de segurança correta anexada a um serviço de back-end, todos os pedidos bloqueados pelo Cloud Armor têm statusDetails definido como denied_by_security_policy. Para ver detalhes sobre como
aplicar a nova regra de WAF pré-configurada às suas políticas de segurança do Cloud Armor, consulte o artigo
Regra de WAF do Google Cloud Armor para ajudar a mitigar a vulnerabilidade do Apache Log4j.cve-canary
Para filtrar quaisquer pedidos permitidos que cheguem efetivamente a um serviço de back-end, selecione
response_sent_by_backend em statusDetails no painel Campos de registo.
Considere ativar a IAP para estes serviços de back-end e aplicar uma política de segurança do Cloud Armor com a regra de WAF cve-canary pré-configurada para ajudar a bloquear estas tentativas de exploração.
Crie uma política de alertas baseada em registos
Depois de criar uma consulta que encontre registos afetados no seu serviço, pode usar essa consulta para criar uma política de alertas baseada em registos que lhe envia uma notificação quando novas entradas do registo correspondem à consulta. Os incidentes criados pela política de alertas podem ser encaminhados para o centro de operações de segurança (SOC) da sua organização ou para a equipa de resposta a incidentes adequada.
Para obter informações sobre como criar uma política de alertas baseada em registos, consulte o artigo Crie uma política de alertas baseada em registos (Explorador de registos). Quando criar a política de alertas, certifique-se de que usa a sua consulta para a string de exploração, em vez da consulta especificada no exemplo.
Crie uma política de alertas para uma métrica baseada em registos
Para monitorizar que serviços ou pontos finais estão a registar possíveis tentativas de exploração, crie uma política de alerta numa métrica baseada em registos:
Crie uma métrica baseada em registos para contabilizar ocorrências de possíveis strings de exploração nos seus registos. Por exemplo, pode usar a Google Cloud CLI para criar uma métrica deste tipo:
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 a criação de métricas baseadas em registos, consulte o artigo Configure métricas de contador.
Crie uma política de alertas para receber uma notificação quando for atingido um número selecionado de ocorrências. Para ver informações sobre a configuração de uma política de alertas, consulte o artigo Crie uma política de alertas numa métrica de contador.
O que se segue?
Consulte este documento para ver atualizações à medida que são disponibilizadas novas informações.
Para mais informações acerca da vulnerabilidade do Log4j 2 e dos seus Google Cloud serviços, consulte o seguinte: