Ir para o conteúdo

Log4j: como é explorada e o que fazer para corrigir?

4 min. de leitura

Avatar de Segurança da Informação CWI

Segurança da Informação CWI Autor


Você provavelmente já deve ter visto todo mundo falando da vulnerabilidade no Log4j, que atingiu nota máxima entre as vulnerabilidades.

Vamos explicar rapidamente como ela é explorada e algumas ações que você deve fazer para corrigir/mitigar este problema! É só continuar a leitura ou assistir ao vídeo. 😉

O que é o Log4J?

Ele é uma biblioteca pra log. Você já deve estar de saco cheio de ver isso. Se você não cria log, nem deveria estar lendo este artigo — deveria estar vendo programação básica.

Você vai importar o pacote dele, criar um log e, depois, logar alguma coisa. Vai sair algo mais ou menos assim: a data, a hora, em qual componente de software foi gerado o log, o tipo de log, a aplicação e a mensagem de log que você colocou.

Até aqui, beleza. Nada demais, como qualquer outro logger, é assim que funciona.

O Log4J, no entanto, tem uma funcionalidade extra que permite gerar alguns dados no meio do log. Se você já viu algo sobre
template injection, já deve ter sentido o cheiro do problema.

Qual foi a ideia que o pessoal colocou? A galera decidiu, em um determinado momento da história, criar um carinha com JNDI pra consultar, por exemplo, informações de LDAP, trabalhar com LDAP… E aí você pode colocar o servidor do seu LDAP e algum recurso que você queira dele.

Isso é uma funcionalidade, correto? Qual foi o problema disso?

Tem uma tendência enorme, gigantesca, de a galera usar o Log4J para logar requisições que são feitas por sites. Se você hospeda um site que tem algum logger, no Log4J… Ou seja: o cara fez uma request e aí você loga essa request.

Bem, as informações que vão para dentro do log acabam sendo da pessoa que fez o request. E normalmente se loga o quê? A URL, os headers e, talvez (não é recomendado), o body daquela requisição.

E aí, o que pode acontecer? Um atacante pode fazer uma requisição para o seu site que tem um servidor vulnerável que usa o Log4J como logger pode passar, por exemplo, um parâmetro que não existe e ele pode colocar
essa informação aqui.

Ele pode colocar qualquer coisa que aceita naquelas variáveis do log. Por exemplo, colocar que o servidor do LDAP é o servidor dele, com um /virus — que já vamos ver como funciona.

No momento que for receber essa requisição, o que o servidor vai fazer? Vai guardar aquele request no log. E aí o log vai vir com a data, tudo certinho, mas a mensagem de erro (ou a mensagem do request, porque esse parâmetro foo não existe), por exemplo, vai ser “request para” e o que veio na URL do request.

Esse é um exemplo. Mas percebam que, na URL da request, o nosso atacante enviou um desses parâmetros que são dinâmicos.

Antes de cair no log, o que vai acontecer?

O servidor vai tentar resolver essa expressão. E resolver essa expressão significa “cara, vai cair no log isso aqui, o JNDI, para consumir algo do LDAP, executar alguma coisa com o LDAP, e o que tenho que fazer?”.

Tenho que ir no servidor do LDAP, que está para um servidor externo nesse caminho /virus. O que vai acabar acontecendo? O atacante vai receber uma conexão daquele servidor. E o que vai fazer? Como você pediu para o evil.com/virus, utilizando ferramentas como marshalsec, eu posso pegar uma classe Java que vai executar um código quando eu responder para o servidor.

Tentando ser um pouco mais claro: o servidor vai tentar resolver essa expressão antes de colocar no log. Vai ser feito um request, de dentro do seu servidor, para esse evil.com, que é o servidor do nosso atacante nesse path /virus.

Quando fizer esse request, o servidor malicioso, esse evil.com, pode responder a request com essa classe Java e devolver isso pro servidor.

Quando o servidor receber a resposta, ele vai fazer o quê? Vai executar um comando que permite que eu me conecte remotamente, do meu atacante, para o servidor. Aí eu posso ter comando como se estivesse no terminal.

Deu para entender um pouco? Se não, aí vai minha dica para você. O pessoal do Try Hack Me criou uma máquina, que é a Solar, com todos os passos para você explorar essa falha. Ele vai te ensinar o que é a falha, como descobrir a falha, como explorar essa falha, fazer bypass, persistência etc. Como explorar de cabo a rabo.

O que você pode fazer para resolver ou mitigar isso dentro dos seus projetos ou da sua empresa?

Primeiro, procure por projetos que usem essa dependência do Log4J, nas versão 2 a 2.15. Você pode acompanhar os releases na página da Apache do Log4j Security Vulnerabilities, que vai dizer quais ações você tem que tomar.

Você deve estar pensando “Ben-Hur, é óbvio que tenho que olhar
as dependências e atualizar”. Mas o mundo todo entrou em caos por causa disso. A maioria porque não tem gestão das bibliotecas.

O problema aconteceu porque deu a vulnerabilidade e ninguém sabe onde pode estar estourando. Então, o primeiro passo é começarmos a gerenciar as dependências e os softwares que utilizamos na nossa corporação como um todo.

Por exemplo, a VMWare também estava vulnerável. Nós usamos VMWare onde, como? Ter uma gestão de ativos, digamos assim, parece básico, mas a gente ainda tem que trabalhar muito nisso. Gerenciar as bibliotecas de software de um modo corporativo é o primeiro passo após a mitigação. Investir nesse tipo de coisa.

Outra dica é: se você colocar Log4j BlueTeam Gist, você vai cair em um compilado de várias ações que o time de BlueTeam pode colocar com questões de firewall, outras ferramentas de WAF etc. Para mitigar esse problema na borda.

Então, ficam aí as dicas. Apenas revisando:

  • Atualize para: Log4j 2.17.0 (Java 8), 2.12.3 (Java 7) e 2.3.1 (Java 6);
  • Acompanhe as vulnerabilidades ali na página;
  • Se você quer aprender a explorar, olhe a máquina Solar, do Try Hack Me, e acompanhe esse bagulhinho de BlueTeam. Passe para o seu BlueTeam para eles terem um ajuda ali.

É isso aí, espero que você tenha entendido, e boa sorte. Estamos todos juntos nessa!

Referências

Gostou?