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!

Muito longo; Para ler

Boost your HackerNoon story @ $159.99! 🚀

Pentests e Log4J: como explorar um sistema vulnerável

About Author

COMENTARIOS

Rótulos

ESTE ARTIGO FOI APRESENTADO EM

Related Stories

Valhalla de Floki se junta como patrocinador associado da viagem da Índia ao Sri Lanka

Modelo Bitcoin UTXO, alimentando um ecossistema único

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

Vazamento do prompt do sistema Claude Sonnet 3.5: uma análise forense

Valhalla de Floki se junta como patrocinador associado da viagem da Índia ao Sri Lanka

Modelo Bitcoin UTXO, alimentando um ecossistema único

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

Vazamento do prompt do sistema Claude Sonnet 3.5: uma análise forense

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps