Segurança
Log4j: como é explorada e o que fazer para corrigir?
4 minutos de leitura
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
