Perigo à vista: demonstração ao vivo de como funciona um exploit do Log4Shell

A vulnerabilidade Log4Shell pegou a comunidade Java de surpresa no fim de 2021, e muitas organizações ainda estão mitigando seus impactos. Para ajudar as equipes de desenvolvimento a acompanhar a situação, a Snyk criou e continua atualizando seu centro de recursos sobre a vulnerabilidade Log4j.

Durante uma recente demonstração ao vivo do Stranger Danger, Simon Maple, CTO de campo da Snyk, Eric Smalling, defensor sênior de desenvolvedores da Snyk, e Micah Silverman, diretor de aceleração de DevSecOps, conversaram sobre a vulnerabilidade Log4Shell e demonstraram como um exploit poderia funcionar.

Log4Shell: resumo rápido

Log4Shell é uma vulnerabilidade crítica, muito disseminada e fácil de explorar no framework de logging Log4j2 para Java. Ela afetou um grande número de aplicações Java, já que o Log4j2 é usado com frequência em muitas outras bibliotecas de código aberto.

“Como mostra o fato de que essa vulnerabilidade ficou adormecida aqui desde 2013, às vezes temos efeitos colaterais inesperados”, disse Micah. “Isso faz parte da natureza dos projetos de código aberto.”

Para corrigir essa vulnerabilidade, os desenvolvedores precisam identificar onde suas aplicações usam a biblioteca Log4j2 — como dependência direta ou indireta — e atualizá-la para a versão 2.17.1. Isso não só mitiga a vulnerabilidade Log4Shell, como também uma vulnerabilidade adicional de negação de serviço, divulgada pouco tempo depois.

Quer saber mais? Preparamos um guia completo de correção do Log4Shell.

Anatomia do Log4Shell

Em 2013, foi adicionada à biblioteca Log4j a possibilidade de usar referências à Java Naming Directory Interface (JNDI) por meio de strings interpoladas em mensagens de log. Strings interpoladas podem conter variáveis, chamadas de função ou outras expressões resolvíveis. O problema é que a JNDI pode buscar URLs nessas strings, disparando uma chamada de rede para um endpoint malicioso.

Além disso, um servidor LDAP não autorizado pode responder à solicitação JNDI com uma referência maliciosa a uma classe Java remota ou a outro código indesejado. Essa classe pode então ser desserializada, mesmo que não esteja no classpath da aplicação, resultando em um ataque de execução remota de código (RCE).

Demonstração de exploit do Log4Shell

Na demonstração ao vivo, usaremos um exemplo de exploit do Log4Shell (disponível no GitHub) que criamos em Java e executaremos em um servidor Tomcat. Quando inserimos uma senha incorreta na página de login, a aplicação informa que nossos dados serão registrados em log.

“É comum registrar em log as atividades nos frameworks Java e na sua aplicação quando ocorrem erros ou exceções, ou até mesmo durante uma transação normal”, explicou Simon. “Isso ajuda você a entender os diferentes fluxos e como as pessoas usam seu site.”

Ao analisar o código da aplicação, vemos que, quando um nome de usuário está incorreto, usamos o Log4j para registrar esse nome em log. Situações como essa, em que os usuários podem inserir dados que depois são registrados em log, são a forma mais comum de explorar a vulnerabilidade Log4Shell.

Por exemplo, podemos usar o campo de login para injetar uma string maliciosa e preparar um ataque de RCE. Mas, primeiro, vamos analisar nosso script de exploit em Python. O mais importante sobre esse script é que ele gera uma classe Java que cria um novo socket ao ser inicializada e, em seguida, se conecta ao nosso próprio servidor.

“Na prática, isso fará parte de um proxy remoto que vamos configurar”, explicou Simon. “A classe ficará em um loop contínuo, recebendo, executando e enviando comandos de volta para o serviço ao qual estamos conectados.”

Vamos criar e compilar o arquivo Java no nosso servidor malicioso e disponibilizá-lo por meio de um serviço HTTP. Depois, criaremos um servidor LDAP que enviará uma string para que a JNDI da aplicação-alvo busque nossa classe Java maliciosa.

Depois de configurar os servidores LDAP e HTTP, estaremos quase prontos para executar o exploit. Para executar a parte de “shell” do Log4Shell, também vamos configurar um servidor proxy reverso usando o netcat, um utilitário de rede. O proxy reverso permite executar comandos remotamente no servidor Tomcat, deixando a aplicação e o servidor vulneráveis a novos ataques.

Executamos o exploit inserindo nossa string maliciosa no campo de login da página da aplicação-alvo. Quando o Log4j registra essa string em log, a biblioteca também tenta resolvê-la. Isso faz com que a aplicação use o serviço JNDI para acessar o servidor LDAP, obter a referência à nossa classe Java maliciosa no servidor HTTP e executá-la localmente. Em seguida, essa classe Java se conecta ao netcat, criando nosso proxy reverso.

Como mitigar o Log4Shell com a Snyk

Como já mencionamos, a melhor forma de mitigar o Log4Shell é identificar e atualizar todas as instâncias do Log4j nas dependências diretas e indiretas. O Snyk Open Source pode verificar automaticamente suas dependências em busca de pacotes com vulnerabilidades como o Log4Shell.

A plataforma Snyk começa identificando e categorizando todos os artefatos do projeto para determinar como eles podem ser verificados. Por exemplo, a Snyk realiza análise de composição de software (SCA) em arquivos pom.xml e testes estáticos de segurança de aplicações (SAST) em arquivos Java. A Snyk também pode verificar configurações de infraestrutura como código (IaC) e arquivos Docker de aplicações conteinerizadas.

Depois de verificar a aplicação vulnerável acima, podemos abrir os resultados da análise do arquivo pom.xml, o arquivo de configuração do Maven que contém nossas dependências. Também podemos ver, na interface da Snyk, a árvore de dependências, que mostra que nossa aplicação usa o Log4j como dependência direta e indireta. Ao clicar na opção Corrigir esta vulnerabilidade, a Snyk pode abrir automaticamente uma solicitação de pull (PR) para atualizar todas as instâncias do Log4j para a versão 2.17.1. Se executarmos novamente o exploit anterior, veremos que ele não funciona mais.

Da mesma forma, os desenvolvedores podem usar o plugin da Snyk para IntelliJ (ou outro IDE) ou a CLI da Snyk para verificar problemas de segurança e corrigi-los diretamente durante o desenvolvimento. A Snyk se integra a todo o processo de desenvolvimento para simplificar o gerenciamento de vulnerabilidades nas aplicações.

Em algumas situações, as organizações não conseguem atualizar imediatamente os pacotes vulneráveis e precisam considerar outras opções para mitigar os riscos do Log4Shell. Os desenvolvedores podem remover a classe de consulta JNDI ou implementar outras correções rápidas, mas elas não são tão eficazes quanto o patch oficial disponível nas versões mais recentes da biblioteca.

Seja qual for a forma escolhida pelos desenvolvedores para mitigar a vulnerabilidade Log4Shell, a Snyk pode ajudar a identificar instâncias do Log4j e milhares de outras possíveis vulnerabilidades, analisando as dependências de código aberto ou os contêineres de um projeto. Assim, as organizações têm a visibilidade necessária para entender o perfil de risco de suas aplicações.