muhammad-ali007/log4j_cve-2021-44228Exercício prático de laboratório para explorar o Log4Shell (CVE-2021-44228) com injeção JNDI, servidores de referência LDAP e payloads de shell reverso. Inclui detecção, técnicas de bypass e orientação pós-exploração.
A vulnerabilidade Log4j, também conhecida como "Log4Shell" ou "CVE-2021-44228", é uma falha crítica de segurança na biblioteca Apache Log4j. Log4j é um framework de logging amplamente utilizado baseado em Java que permite aos desenvolvedores registrar mensagens de aplicações em vários destinos, como arquivos, bancos de dados e saídas de console.
A vulnerabilidade foi descoberta em dezembro de 2021 e ganhou atenção significativa devido à sua gravidade e potencial de exploração. Ela afeta as versões 2.x do Log4j e, em alguns casos, até versões anteriores. A vulnerabilidade Log4j é uma vulnerabilidade de Execução Remota de Código (RCE), o que significa que um atacante pode executar código arbitrário em um sistema alvo explorando a falha. A vulnerabilidade é causada por uma falha de design na biblioteca Log4j relacionada ao processamento de mensagens de log que contêm dados especialmente criados.
A exploração da vulnerabilidade depende da capacidade de injetar código malicioso na mensagem de log. Isso pode ser alcançado por meio de vários vetores, como campos de entrada controlados pelo usuário, cabeçalhos de requisição HTTP ou outros dados fornecidos pelo usuário que são passados para a instrução de log.
Quando uma aplicação vulnerável processa uma mensagem de log contendo os dados especialmente criados, o Log4j interpreta os dados como uma consulta de Java Naming and Directory Interface (JNDI). Ao explorar esse comportamento, um atacante pode criar um payload que dispara uma consulta JNDI para um servidor malicioso controlado pelo atacante. Esse servidor pode então responder com um payload que é executado no sistema alvo, permitindo que o atacante alcance execução remota de código.
O impacto da vulnerabilidade Log4j é severo porque o Log4j é amplamente utilizado em várias aplicações baseadas em Java, incluindo servidores web, aplicações e serviços em nuvem. A vulnerabilidade permite que atacantes obtenham acesso não autorizado a sistemas afetados, potencialmente levando a violações de dados, comprometimento do sistema e exploração adicional do ambiente comprometido.
Hoje, a versão 2.16.0 do log4j está disponível e corrige essa vulnerabilidade (JNDI está totalmente desabilitado, o suporte para Message Lookups foi removido e a nova vulnerabilidade de DoS CVE-2021-45046 não está presente). (https://github.com/apache/logging-log4j2/releases/tag/rel%2F2.16.0)
No entanto, o perigo absoluto dessa vulnerabilidade se deve à ubiquidade do pacote de logging. Milhões de aplicações, bem como provedores de software, usam esse pacote como dependência em seu próprio código. Embora você possa corrigir seu próprio código base que usa log4j, outros fornecedores e fabricantes ainda precisarão enviar suas próprias atualizações de segurança downstream. Muitos pesquisadores de segurança compararam essa vulnerabilidade à do Shellshock pela natureza de sua enorme superfície de ataque. Veremos essa vulnerabilidade por anos.
Para uma lista crescente de softwares e serviços vulneráveis ao CVE-2021-44228, mantida pela comunidade, confira este repositório GitHub (https://github.com/YfryTchsGD/Log4jAttackSurface)
Embora existam vários outros artigos, blogs, recursos e materiais de aprendizado sobre o CVE-2021-44228, eu (o autor deste exercício) sou particularmente parcial a estes:
O pacote log4j adiciona lógica extra aos logs ao "parsear" as entradas, em última análise para enriquecer os dados — mas também pode tomar ações e até avaliar código com base nos dados da entrada. Esta é a essência do CVE-2021-44228. Outras sintaxes podem de fato ser executadas exatamente como são inseridas nos arquivos de log. Alguns exemplos dessa sintaxe são:
Você já deve conhecer o payload geral para abusar dessa vulnerabilidade log4j. O formato da sintaxe usual que tira proveito disso é assim:
Essa 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 é utilizado como arma neste ataque.
Observe o esquema "ldap://". Isso indica que o alvo entrará em contato com um endpoint (um local controlado pelo atacante, no caso deste ataque) via protocolo LDAP. Para fins de brevidade, não precisaremos cobrir todos os detalhes do LDAP aqui, mas saiba que isso é algo com que precisaremos trabalhar ao refinar nosso ataque. Por enquanto, saiba que o alvo de fato fará uma conexão com um local externo. Isso é indicado pelo placeholder ATTACKERCONTROLLEDHOST na sintaxe acima. Você, atuando como o atacante neste cenário, pode hospedar um simples listener para visualizar essa conexão.
A próxima pergunta é: onde poderíamos inserir essa sintaxe? Em qualquer lugar onde os dados sejam registrados pela aplicação.
Este é o cerne dessa vulnerabilidade. Infelizmente, é muito difícil determinar onde está a superfície de ataque para diferentes aplicações e, portanto, quais aplicações são realmente vulneráveis. Simplesmente ver a presença de arquivos log4j não revela o número exato da versão, nem mesmo onde ou como a aplicação pode usar o pacote.
Outros locais onde você pode fornecer essa sintaxe JNDI:
Se você quiser mais informações sobre esse vetor de ataque JNDI, reveja esta apresentação da Black Hat USA de 2016. https://www.blackhat.com/docs/us-16/materials/us-16-Munoz-A-Journey-From-JNDI-LDAP-Manipulation-To-RCE.pdf
POC
Exploitation Neste ponto, você verificou que o alvo é realmente vulnerável ao ver essa conexão capturada em seu listener netcat. No entanto, ele fez uma requisição LDAP... então tudo que seu listener netcat pode ter visto foram caracteres não imprimíveis (bytes estranhos). Agora podemos construir sobre essa base para responder com um manipulador LDAP real.
