Falha em lookups JNDI no log4j2 permite que entrada controlada por atacante, quando registrada por uma aplicação Java vulnerável, acione carregamento remoto de objetos e contorne controles baseados apenas em filtragem de borda.
| Componente | Instâncias vulneráveis do log4j2 usadas por aplicações Java para registro de eventos, com suporte a lookups JNDI. |
| Vetor | Entrada controlada por atacante inserida em campos, pacotes ou outros dados processados pela aplicação e gravada em logs pelo log4j2 vulnerável. |
| Impacto | Execução remota de código na variante que carrega objetos Java por JNDI/LDAP; variantes com DNS podem causar requisições externas e divulgação não autorizada de informação. |
| Prioridade | Inventariar aplicações Java que usam log4j2, aplicar correções dos fornecedores, desabilitar JNDI quando suportado e tratar WAF/IPS como camada complementar, não como correção principal. |
| Versões | Ambientes Java 8 ou posteriores atualizados nos anos anteriores já continham mitigação contra a forma mais simples de carregamento remoto por LDAP, mas isso não eliminava variantes mais sutis nem a necessidade de corrigir o log4j2. |
| Mitigação | Quando a configuração de desativação de JNDI não existir em versões antigas do log4j2, a remoção cirúrgica da classe de lookup JNDI foi citada como alternativa de contenção, com risco de quebrar aplicações. |
Log4Shell é uma vulnerabilidade de execução remota de código associada ao log4j2, biblioteca de logging amplamente usada em aplicações Java. O ponto crítico não é apenas a presença da biblioteca, mas a combinação entre entrada controlada por usuário, registro dessa entrada em logs e suporte do log4j2 a uma linguagem própria de lookups. Quando uma aplicação vulnerável registra uma sequência de lookup JNDI fornecida por um atacante, o mecanismo de logging pode tentar resolver um recurso externo em tempo de execução. Na forma mais grave descrita, esse fluxo permite recuperar e executar uma classe Java por meio de JNDI usando LDAP, transformando uma operação aparentemente passiva de logging em caminho de execução de código.
A superfície é extensa porque a entrada que chega ao log pode vir de muitos lugares: nome de usuário, senha, número de telefone, cabeçalhos, campos de formulário, identificadores de dispositivo, pacotes TCP ou qualquer dado que a aplicação processe e registre. O problema, portanto, não depende de uma rota administrativa específica nem de um endpoint de exploração único. Ele depende de uma cadeia comum em sistemas corporativos: receber dados, registrar eventos para auditoria ou depuração e delegar a formatação desses eventos a uma dependência vulnerável. Essa característica explica por que a exploração em massa se tornou plausível logo após a divulgação pública.
JNDI é um recurso de Java usado para localizar e carregar objetos durante a execução. Entre os protocolos compatíveis está LDAP, protocolo de acesso a diretórios também associado a ambientes como Active Directory. O log4j2 incluiu suporte a lookups capazes de consultar recursos por JNDI. Em uma aplicação vulnerável, a sequência de eventos começa quando o atacante consegue fazer uma cadeia de lookup chegar a um ponto que será registrado. O log4j2 interpreta essa cadeia durante o processamento do log, aciona JNDI e tenta resolver o recurso indicado. Se a variante envolver carregamento remoto de objeto Java por LDAP e o ambiente permitir esse comportamento, o resultado pode ser execução remota de código no contexto da aplicação.
O contexto também descreve variantes menos diretas. Um lookup JNDI com DNS, por exemplo, pode forçar uma requisição para infraestrutura controlada pelo atacante. Mesmo sem carregar código externo, esse comportamento é útil para confirmar alcance de exploração e pode expor informação não autorizada por meio de consultas observáveis fora do ambiente. Para defesa, isso significa que a ausência de execução de código não encerra a investigação: consultas DNS inesperadas originadas de aplicações Java podem indicar tentativa de exploração, validação de alvo ou enumeração de sistemas vulneráveis.
A exploração é difícil de bloquear apenas com assinaturas porque a linguagem de lookups do log4j2 oferece margem para variações e ofuscações. Controles de borda como IPS e WAF conseguem reduzir tentativas triviais, especialmente cadeias copiadas diretamente de exemplos públicos, mas não avaliam necessariamente a linguagem de lookup da mesma forma que a aplicação alvo. Quando o produto de segurança apenas inspeciona texto de entrada e o serviço vulnerável interpreta esse texto com semântica própria, surge uma disputa assimétrica: o defensor tenta reconhecer padrões, enquanto o atacante altera a representação para preservar o efeito. Essa limitação torna a filtragem útil como contenção, mas insuficiente como remediação.
A exposição envolve aplicações Java que usam versões vulneráveis do log4j2 e registram dados controláveis por terceiros. A presença de Java no ambiente, isoladamente, não confirma vulnerabilidade; é necessário que a aplicação use o módulo vulnerável, que entradas externas sejam processadas e que essas entradas alcancem o logging. Ainda assim, a escala é grande porque Java é usado em servidores, aplicações corporativas, produtos embarcados e serviços internos, e porque dependências de logging frequentemente aparecem de forma transitiva dentro de pacotes maiores. A aplicação diretamente exposta à internet não é o único ponto de preocupação: serviços internos que registram dados repassados por proxies, filas, APIs ou integrações também podem interpretar entradas originadas fora do perímetro.
A correção também é operacionalmente complexa. Substituir uma dependência em software moderno depende de empacotamento, testes, compatibilidade e liberação pelo mantenedor de cada aplicação. Produtos abandonados ou mantidos com atraso podem permanecer vulneráveis por semanas ou meses. Forçar globalmente uma versão corrigida de uma biblioteca em todas as aplicações criaria risco de incompatibilidade e equivaleria a testar mudanças em produção. Por isso, o tratamento exige inventário real de dependências, identificação de cópias empacotadas em arquivos Java, validação por aplicação e acompanhamento de fornecedores.
- Aplicações Java que registram campos externos usando log4j2 vulnerável.
- Serviços que recebem dados por formulários, autenticação, cabeçalhos, APIs, pacotes ou integrações e depois registram esses valores.
- Ambientes com dependências transitivas, nos quais o log4j2 pode estar embutido sem aparecer como escolha direta da equipe de aplicação.
- Produtos de terceiros ou software sem manutenção ativa, nos quais o ciclo de correção depende do fornecedor ou de mitigação local controlada.
A investigação deve combinar telemetria de aplicação, rede, endpoint e resolução de nomes. Em logs HTTP, logs de autenticação e trilhas de aplicação, a defesa deve procurar cadeias compatíveis com lookups JNDI, inclusive variações ofuscadas e entradas em campos que normalmente não receberiam conteúdo técnico. O objetivo não é apenas encontrar uma string literal, mas identificar tentativas de fazer a aplicação interpretar dados como expressão de lookup. Campos de usuário, agente, senha, identificador de dispositivo, telefone, nome de host, cabeçalhos e parâmetros incomuns são bons pontos de inspeção porque o contexto mostra que atacantes e curiosos passaram a inserir esse tipo de expressão em praticamente qualquer entrada processável.
Na camada de rede, consultas LDAP e DNS inesperadas originadas de servidores Java merecem atenção. A variante LDAP está associada ao cenário mais severo de carregamento remoto de objeto Java, enquanto a variante DNS pode indicar validação de exploração ou vazamento de informação por resolução externa. A telemetria de egress é decisiva porque muitas aplicações vulneráveis podem não registrar claramente a avaliação do lookup, mas a resolução externa deixa sinais em proxy, firewall, DNS resolver ou sensores de rede. A investigação deve correlacionar o timestamp da entrada suspeita com conexões de saída iniciadas pelo processo Java ou pelo host que executa a aplicação.
No endpoint, a análise deve priorizar processos Java que iniciaram conexões incomuns, mudanças de comportamento após eventos de logging e carregamento de classes ou componentes fora do padrão esperado da aplicação. Quando houver suspeita de execução de código, a resposta precisa preservar logs e metadados antes de reiniciar serviços, pois a sequência de exploração pode estar distribuída entre log de aplicação, tráfego de saída e eventos do sistema operacional. Como a exploração pode ser acionada por dados benignos em aparência, entradas em sistemas de identidade, formulários públicos e integrações automatizadas devem ser tratadas como fontes relevantes de evidência.
- Entradas com padrões de lookup JNDI em logs de aplicação, autenticação, API, proxy e balanceador.
- Consultas LDAP ou DNS de saída feitas por servidores Java que normalmente não acessam esses destinos.
- Picos de sondagem em múltiplos campos de entrada, incluindo nomes de usuário, cabeçalhos, identificadores de dispositivo e parâmetros de formulário.
- Eventos de processo Java associados a conexões externas, carregamento inesperado de componentes ou comportamento anômalo após escrita de logs.
A resposta deve começar pelo inventário de aplicações e dependências. O foco é localizar onde o log4j2 vulnerável está presente, inclusive dentro de pacotes Java empacotados, produtos de terceiros e aplicações internas. Em seguida, as equipes devem aplicar correções fornecidas pelos mantenedores das aplicações ou atualizar a biblioteca conforme o caminho suportado pelo produto. Como a compatibilidade é parte do risco, a validação deve cobrir inicialização, fluxos críticos de negócio, logging e integrações que dependem da aplicação. A correção de biblioteca é a medida central porque remove a condição que transforma conteúdo de log em execução ou resolução externa.
Mitigações de configuração têm papel importante quando a atualização completa ainda não é viável. Desabilitar JNDI dentro do log4j2 é a opção mais limpa quando a versão em uso oferece essa configuração. Em versões mais antigas nas quais essa opção não existe, foi citada a remoção da classe responsável pelo lookup JNDI como alternativa de contenção, mas essa ação deve ser tratada como mudança invasiva: pode impedir exploração da funcionalidade vulnerável e, ao mesmo tempo, quebrar aplicações que esperavam a presença da classe. Quando aplicada, exige teste controlado, rastreabilidade e plano de reversão.
Atualizar a JVM também reduz risco em determinados cenários, especialmente para Java 8 ou posterior que já recebeu mitigação contra a forma mais simples de carregamento remoto por LDAP. Essa defesa, entretanto, não cobre todas as variantes. Ela não substitui a correção do log4j2 nem elimina a necessidade de monitorar DNS e outros usos de JNDI. WAF, IPS e regras de filtragem devem permanecer em uso para reduzir ruído de exploração e bloquear tentativas conhecidas, mas precisam ser acompanhados de correção, contenção de saída e investigação de possíveis acertos anteriores.
A validação pós-mitigação deve verificar três pontos: ausência de versões vulneráveis em aplicações e artefatos empacotados, bloqueio ou controle de tráfego de saída desnecessário a partir de servidores Java e inexistência de novas tentativas bem-sucedidas de resolução externa durante testes defensivos. Ambientes com fornecedores atrasados devem receber compensações temporárias, como restrição de egress, revisão de logs, isolamento de serviços expostos e priorização de produtos que recebem entrada direta da internet. A ordem correta é reduzir exposição imediatamente, corrigir a causa na dependência e manter hunting até que a superfície inventariada esteja limpa.
- Inventariar aplicações Java, dependências transitivas e produtos de terceiros que incluam log4j2 vulnerável.
- Aplicar correções dos mantenedores ou substituir o componente vulnerável pelo caminho suportado da aplicação.
- Desabilitar JNDI no log4j2 quando a versão permitir; em versões antigas, avaliar remoção da classe de lookup JNDI apenas com teste e plano de reversão.
- Restringir tráfego de saída LDAP e DNS desnecessário a partir de servidores de aplicação e monitorar exceções.
- Usar WAF e IPS como camada de redução de exploração, sem tratá-los como substitutos de patch ou mitigação local.
0 Comentários