Dark background with blue code overlay
Blog

Recomendações da Akamai para mitigação do Log4j

Akamai blue wave

Written by

Aparna Rayasam, SVP & GM Application Security, Akamai

December 16, 2021

log4j.png

Resumo executivo

Uma vulnerabilidade crítica de execução de código remota (CVE-2021-44228) foi divulgada publicamente no Log4j, um utilitário de registro de código-fonte aberto que é amplamente usado em aplicações, incluindo muitos de grandes organizações empresariais. 

A vulnerabilidade permite que os agentes de ameaça exfiltrem informações de sistemas que executam aplicações que utilizam a biblioteca manipulando mensagens de registro e executem códigos maliciosos neles. Já existem relatórios de servidores executando verificações em toda a internet em tentativas de localizar servidores vulneráveis, e nossas equipes de inteligência contra ameaças estão vendo tentativas de exploração dessa vulnerabilidade em volumes alarmantes. O Log4j está incorporado a muitas estruturas populares e diversas aplicações Java, fazendo com que o impacto seja generalizado.

O amplo pacote de segurança da Akamai, incluindo as soluções de segurança de aplicações e APIs, o Enterprise Threat Protector e Segmentação Guardicore, está bem posicionado para ajudar a resolver essa vulnerabilidade de diferentes maneiras. É altamente recomendável que as organizações atualizem o Log4j para a versão mais recente, 2.16.0. Devido à natureza de rápida expansão dessa vulnerabilidade, as equipes da Akamai continuarão a desenvolver e implantar medidas de mitigação para dar suporte aos nossos clientes. 

O que é a vulnerabilidade do Log4j?

Em 9 de dezembro de 2021, uma vulnerabilidade crítica envolvendo a execução de código remota e não autenticada e a exfiltração de dados (CVE-2021-44228) no Log4j foi relatada, causando preocupação devido à frequência com que a função de registro de código aberto é usada. Esse uso generalizado, combinado com a facilidade de exploração, torna seu impactos particularmente grandes. A vulnerabilidade está sendo explorada ativamente e as equipes de segurança em todo o mundo estão trabalhando nas pesquisas e mitigações.

Uma máquina comprometida permite que um agente de ameaça exfiltre dados e forneça remotamente softwares que o Log4j executa. Isso concede a um invasor a capacidade de executar comandos arbitrários dentro de um servidor, expondo informações e segredos e permitindo que esse servidor seja um propulsor de ataques adicionais, potencialmente contra máquinas protegidas dentro de uma rede sem acesso direto à Internet.

Os desenvolvedores do mundo Java usam o Log4j extensivamente para facilitar o registro de erros e informações de depuração. Como resultado, os fornecedores de produtos cujo software é baseado em Java podem estar vulneráveis. Mesmo que uma aplicação não utilize o Log4j diretamente, muitas ferramentas e estruturas comuns usam o Log4j internamente e, portanto, podem introduzir essa vulnerabilidade na pilha de aplicações.  

Qual é a gravidade da vulnerabilidade do Log4j?

Embora a Akamai tenha observado pela primeira vez as tentativas de exploração da vulnerabilidade do Log4j em 9 de dezembro, vemos cada vez mais evidências sugerindo que ela pode ter sido explorada por meses. Desde a publicação da vulnerabilidade, vimos diversas variantes da exploração a uma taxa constante de tráfego de ataque de cerca de 2 milhões de tentativas por hora. A velocidade com que as variantes estão evoluindo nunca foi vista antes. 

Mais da metade (aproximadamente 57%) dos ataques vistos até agora são de invasores anteriormente classificados como agentes mal-intencionados no banco de dados de inteligência contra ameaças da Akamai. Prevemos que devido ao grande volume de sistemas sem patches, continuaremos a ver tentativas de exploração nos próximos meses. As equipes de pesquisa de segurança e resposta a incidentes da Akamai continuam monitorando e protegendo nossa infraestrutura e nossos clientes, aproveitando nossa visibilidade e inteligência exclusivas.

Embora a ação mais importante a ser tomada durante qualquer vulnerabilidade seja corrigir sistemas infectados, os pesquisadores de segurança entendem que isso leva tempo. Em muitos casos, é possível que as organizações ainda não tenham sequer a visibilidade de quais sistemas estão vulneráveis. Dessa forma, mitigações adicionais devem ser implementadas para reduzir a superfície de ameaça o máximo possível.

Para ajudar nisso, a Akamai tem diversas recomendações. Neste momento, a maior quantidade de tráfego de ataque que estamos vendo associado ao Log4j é baseada em aplicações Web, portanto, a etapa mais impactante que as organizações podem tomar após a aplicação de patches é aproveitar as proteções de aplicações Web e API da Akamai. Continue lendo para saber como e o que fazer dentro de sua empresa à medida que os vetores de ataque evoluem. 

Mitigação do abuso do Log4j usando o Akamai App e o pacote de proteção de API

A Akamai continua a atualizar as regras do WAF (Web Application Firewall) para fornecer proteção contra essa exploração e suas diversas variantes. Isso inclui a atualização da regra 3000014 dentro do Kona Rule Set e Adaptive Security Engine da Akamai. Para os clientes que usam o Automated Attack Group, atualizamos o grupo de injeção de comando. Todos os clientes que, atualmente, têm essas regras ou os grupos de ataque ativadas no modo DENY receberão proteção automática em linha para as seguintes versões e os seguintes mecanismos de proteção:

  • Kona Rule Set – qualquer versão a partir de 29 de outubro de 2019

  • Automated Attack Group – qualquer versão

  • Adaptive Security Engine – qualquer versão

Muitos servidores, especialmente aqueles em ambientes de alto risco, como o acesso direto à Internet, podem já ter sido comprometidos. Para identificar os indicadores de comprometimento, o seguinte comando poderá mostrar as tentativas de exploração:

sudo egrep -i -r '\$\{jndi:(ldap[s]?|rmi|dns)://' /var/log

Para saber mais sobre as proteções de aplicações Web e APIs da Akamai, leia mais ou entre em contato conosco.

Embora as proteções WAF possam ser altamente eficazes para os servidores da Web nesse estágio, as organizações também devem considerar caminhos alternativos de ataque que possam ter levado a um comprometimento. Para isso, recomendamos o uso de microssegmentação para obter visibilidade da possível exposição e reduzir o risco e a disseminação. 

Detecção de abuso do Log4j usando o Enterprise Threat protetor

Os pesquisadores de ameaças da Akamai vêm analisando dados de DNS (Sistema de Nomes de Domínio), proxy e sinkhole de clientes em busca de comportamentos atípicos relacionados aos atores que tentam usar a vulnerabilidade do Log4j barbaramente. Nos dados de DNS, ficamos surpresos ao ver consultas de DNS para domínios que contêm a string "jndi:ldap". Essas são consultas de DNS inválidas, que contêm caracteres inválidos no nome do domínio e, portanto, não serão resolvidas. Além disso, vimos tráfego para domínios mal-intencionados conhecidos que foram redirecionados para servidores sinkhole; esses domínios hospedaram códigos Java mal-intencionados usados para abusar de servidores vulneráveis. Todas essas são indicações de possíveis abusos nas redes dos clientes. 

Mitigação do abuso do Log4j usando a segmentação Guardicore

Os clientes que usam a segmentação Akamai Guardicore podem aproveitar sua visibilidade no nível do processo para identificar aplicações vulneráveis e riscos de segurança no ambiente. Isso pode ser usado para obter controle preciso sobre o tráfego de rede para interromper ataques em sistemas vulneráveis, sem interrupções nas operações comerciais normais.

O que está sob ameaça: Identificação de processos Java vulneráveis e abuso do Log4j

Para ter proteção contra possíveis abusos do Log4j é necessário primeiro identificar processos potencialmente exploráveis. Isso requer uma visibilidade detalhada do tráfego de rede no nível do processo, que é fornecida pela Segmentação Akamai Guardicore. A visibilidade precisa das conexões de Internet e do tráfego nos permite ver claramente quais medidas de mitigação precisam ser tomadas sem interromper as operações de negócios. 

Interrupção do ataque: Bloqueie IoCs mal-intencionados e vetores de ataque

É necessário ser capaz de agir assim que as aplicações vulneráveis forem identificadas. Enquanto a implementação de patches está em andamento, a Segmentação Akamai Guardicore oferece uma variedade de opções para alertar, interromper e evitar ataques. Essencialmente, uma solução com controle detalhado e preciso sobre a comunicação e o tráfego da rede é necessária para bloquear ou isolar vetores de ataque cirurgicamente, com pouca ou nenhuma interrupção para as funções normais de negócios. Isso inclui:

  • Bloqueio automático do IoC com o Threat Intelligence Firewall (TIFW) e Segurança de DNS 

  • Colocar os servidores comprometidos em quarentena 

  • Bloquear o tráfego de entrada e saída para conteúdo vulnerável 

  • Bloquear o tráfego de saída de aplicações Java para a Internet

Além disso, clientes Guardicore Hunt têm seus ambientes monitorados e investigados continuamente por uma equipe dedicada de pesquisadores de segurança. Alertas sobre riscos de segurança e etapas de mitigação sugeridas são enviados imediatamente.  

Se deseja saber mais sobre a Segmentação Akamai Guardicore, leia mais ou entre em contato conosco.

Conclusão

A Akamai continuará a compartilhar seus insights conforme monitoramos e pesquisamos as explorações do Log4j de perto e fornecemos atualizações oportunas para nossas proteções e recursos.



Akamai blue wave

Written by

Aparna Rayasam, SVP & GM Application Security, Akamai

December 16, 2021