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

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

• Laboratório Try Hack Me
• Sobre a vulnerabilidade
• Blue Team Gist