Pentests e Log4J: como explorar um sistema vulnerável

Neste artigo, testamos um sistema vulnerável e demonstramos como um shell remoto pode ser obtido usando uma exploração de código aberto Log4j que está disponível para qualquer pessoa.

Introdução

Essa vulnerabilidade crítica, denominada CVE-2021-44228, afeta um grande número de clientes, pois o componente Apache Log4j é amplamente usado em software comercial e de código aberto. Além disso, os invasores de ransomware estão armando o exploit Log4j para aumentar seu alcance para mais vítimas em todo o mundo.

Nossa demonstração é fornecida para fins educacionais para um público mais técnico com o objetivo de fornecer mais conhecimento sobre como esse exploit funciona.

A Raxis acredita que um melhor entendimento da composição dos exploits é a melhor forma de os usuários aprenderem como combater as crescentes ameaças na internet.

Log4j Explorar Storyboard

A vulnerabilidade do Apache Log4j, CVE-2021-44228 ( https://nvd.nist.gov/vuln/detail/CVE-2021-44228 ), afeta um grande número de sistemas e os invasores estão explorando atualmente essa vulnerabilidade para usuários conectados à Internet sistemas em todo o mundo.

Para demonstrar a anatomia de tal ataque, Raxis fornece uma demonstração passo a passo do exploit em ação. Em nossa demonstração, fazemos suposições sobre o ambiente de rede usado para o servidor vítima que permitiria que esse ataque ocorresse.

Certamente existem muitas maneiras de evitar que esse ataque seja bem-sucedido, como usar configurações de firewall mais seguras ou outros dispositivos avançados de segurança de rede; no entanto, selecionamos uma configuração de segurança "padrão" comum para fins de demonstração desse ataque.

servidor vítima

Primeiro, nosso servidor vítima é um servidor da Web Tomcat 8 que usa uma versão vulnerável do Apache Log4j e é configurado e instalado em um contêiner docker.

O contêiner docker nos permite demonstrar um ambiente separado para o servidor vítima que está isolado de nosso ambiente de teste. Nosso servidor Tomcat está hospedando um site de amostra obtido em https://github.com/cyberxml/log4j-poc e está configurado para expor a porta 8080 para o servidor web vulnerável.

Nenhuma outra porta de entrada para este contêiner docker está exposta além de 8080. O contêiner docker permite o tráfego de saída, semelhante à configuração padrão de muitas redes de servidor.

Observe que esse repositório específico do GitHub também apresentava uma versão integrada do código de ataque Log4j e da carga útil. Estamos usando apenas as partes do servidor da Web Tomcat 8, conforme mostrado na captura de tela abaixo.

Figura 1: Victim Tomcat 8 Demo Web Server executando código vulnerável ao log4j Exploit

Em seguida, precisamos configurar a estação de trabalho do invasor. Usando o código de exploração de https://github.com/kozmer/log4j-shell-poc, Raxis configura três sessões de terminal, chamadas Netcat Listener, Python Web Server e Exploit, conforme mostrado abaixo.

Ouvinte Netcat, porta 9001

A sessão Netcat Listener, indicada na Figura 2, é uma escuta Netcat em execução na porta 9001. Essa sessão é para capturar o shell que será passado para nós do servidor vítima por meio do exploit.

Figura 2: Ouvinte Netcat do invasor na porta 9001

Servidor da Web Python, porta 80

A sessão Python Web Server na Figura 3 é um servidor web Python executado na porta 80 para distribuir a carga útil para o servidor vítima.

Figura 3: Servidor da Web Python do invasor para distribuir carga útil

Código de exploração, porta 1389

A sessão Exploit, mostrada na Figura 4, é o código de exploração Log4j de prova de conceito operando na porta 1389, criando um servidor LDAP armado.

Este código redirecionará o servidor vítima para baixar e executar uma classe Java que é obtida de nosso Python Web Server rodando na porta 80 acima.

A classe Java está configurada para gerar um shell na porta 9001, que é nosso ouvinte Netcat na Figura 2.

Figura 4: Código de exploração Log4J do invasor

Execute o ataque

Agora que o código está preparado, é hora de executar nosso ataque. Vamos nos conectar ao servidor da vítima usando um navegador Chrome.

Nossa string de ataque, mostrada na Figura 5, explora o JNDI para fazer uma consulta LDAP à sessão de exploração do invasor em execução na porta 1389.

Figura 5: Site da vítima e sequência de ataque

A cadeia de ataque explora uma vulnerabilidade no Log4j e solicita que uma pesquisa seja realizada contra o servidor LDAP armado do invasor.

Para fazer isso, uma solicitação de saída é feita do servidor da vítima para o sistema do invasor na porta 1389. A sessão Exploit na Figura 6 indica o recebimento da conexão LDAP de entrada e o redirecionamento feito para o Python Web Server do invasor.

Figura 6: Sessão de exploração do invasor indicando conexão de entrada e redirecionamento

A sessão Exploit enviou um redirecionamento para o nosso Python Web Server, que está servindo uma classe Java armada que contém código para abrir um shell.

Essa classe Java foi realmente configurada em nossa sessão Exploit e está sendo atendida apenas na porta 80 pelo Python Web Server. O log de conexão é mostrado na Figura 7 abaixo.

Figura 7: servidor da Web Python do invasor enviando o shell Java

A última etapa do nosso ataque é onde Raxis obtém o shell com controle do servidor da vítima. A classe Java enviada à nossa vítima continha um código que abria um shell remoto para a sessão netcat do invasor, conforme mostrado na Figura 8.

O invasor agora tem controle total do servidor Tomcat 8, embora limitado à sessão docker que configuramos neste cenário de teste.

Figura 8: Acesso do invasor ao servidor da vítima que controla o shell

Conclusão

Como demonstramos, a vulnerabilidade Log4j é um processo de várias etapas que pode ser executado assim que você tiver as peças certas no lugar. A Raxis está vendo esse código implementado em bots de ataque de ransomware que estão pesquisando na Internet sistemas para explorar.

Este é certamente um problema crítico que precisa ser resolvido o mais rápido possível, pois é uma questão de tempo até que um invasor atinja um sistema exposto.

Também publicado aqui