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 (   ), 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. https://nvd.nist.gov/vuln/detail/CVE-2021-44228  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   e está configurado para expor a porta 8080 para o servidor web vulnerável. https://github.com/cyberxml/log4j-poc  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   Raxis configura três sessões de terminal, chamadas Netcat Listener, Python Web Server e Exploit, conforme mostrado abaixo. https://github.com/kozmer/log4j-shell-poc,   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

Apache

Uncover hidden security gaps in your network

Este áudio é produzido no idioma original da história!

Pentests e Log4J: como explorar um sistema vulnerável

About Author

COMENTARIOS

Rótulos

ESTE ARTIGO FOI APRESENTADO EM

Related Stories

O guia completo para uma migração bem-sucedida para a nuvem: estratégias e práticas recomendadas

Criando produtos criptográficos centrados no usuário: a importância do feedback do cliente

Quer ganhar um concurso de redação do HackerNoon? Aqui está o que os vencedores do concurso #crypto-api recomendam

As camadas invisíveis: por que as entrevistas com usuários são um ativo insubstituível

O guia completo para uma migração bem-sucedida para a nuvem: estratégias e práticas recomendadas

Criando produtos criptográficos centrados no usuário: a importância do feedback do cliente

Quer ganhar um concurso de redação do HackerNoon? Aqui está o que os vencedores do concurso #crypto-api recomendam

As camadas invisíveis: por que as entrevistas com usuários são um ativo insubstituível

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps