Hier führen wir einen ARP-Scan durch, um aktive Hosts im Netzwerk zu entdecken. Das Ergebnis zeigt, dass die IP-Adresse 192.168.2.124 der MAC-Adresse 08:00:27:1a:04:cb zugeordnet ist, was auf ein Gerät von PCS Systemtechnik GmbH hinweist.
Wir fügen die IP-Adresse und den Hostnamen "bluesmoke.vln" zur /etc/hosts-Datei hinzu, um die Namensauflösung zu erleichtern.
Dieser Nmap-Scan zeigt, dass SSH (22) und HTTP (80) offen sind.
Dieser detailliertere Nmap-Scan liefert zusätzliche Informationen wie SSH-Hostkeys, den HTTP-Titel ("Filee Upload to Backup") und den Server-Header (Apache/2.4.38 (Debian)). Außerdem wird auf das fehlende HTTPonly-Flag für Cookies hingewiesen.
nikto identifiziert verschiedene potenzielle Schwachstellen, darunter fehlende Header für Clickjacking und Content-Type-ptions, das fehlende HTTPonly-Flag für Cookies und die mögliche Offenlegung von Inodes über ETags.
gobuster findet die Dateien index.php und backup.jpg sowie die Verzeichnisse /uploads und /javascript. upload.php leitet auf index.php um.
Nach der Reconnaissance versuchen wir, uns Zugriff auf das System zu verschaffen.
Wir haben einen offenen Webserver mit einer Upload-Funktion entdeckt, die wir näher untersuchen werden.
Wir erstellen zwei Dateien, die für einen "tar bomb"-Angriff benötigt werden. Diese Dateien werden verwendet, um beim Entpacken eines TAR-Archivs einen Befehl auszuführen.
Wir erstellen ein Reverse-Shell-Skript (rev.sh), das eine Verbindung zu unserem lokalen System auf Port 443 herstellt.
Wir machen das Reverse-Shell-Skript ausführbar.
Wir erstellen ein TAR-Archiv (tar_shell.tar), das die erstellten Dateien enthält.
Wir überprüfen den Inhalt des TAR-Archivs.
Die Webseite index.php bietet eine Upload-Funktion für TAR- und ZIP-Dateien.
Wir starten einen Netcat-Listener auf Port 443, um die Reverse Shell zu empfangen.
Nachdem wir eine Reverse Shell erhalten haben (durch Hochladen des TAR-Archivs mit dem "tar bomb"-Exploit) versuchen wir, unsere Privilegien zu erhöhen.
Wir erhalten eine Reverse Shell als Benutzer "backupper". Die Meldungen "cannot set terminal process group" und "no job control in this shell" deuten darauf hin, dass wir eine eingeschränkte Shell haben.
Wir suchen nach SUID-Binaries, um potenzielle Möglichkeiten zur Privilegieneskalation zu finden.
Die Ausgabe von find zeigt eine Liste von SUID-Binaries. Einige davon (wie z.B. /usr/bin/passwd oder /bin/su) könnten für eine Privilegieneskalation ausgenutzt werden.
Wir suchen nach Benutzern mit einer Bash-Shell.
Wir finden die Benutzer "root", "jaap", "backupper" und "remnie" mit einer Bash-Shell.
Wir überprüfen die aktuelle Benutzer-ID.
Wir sind als Benutzer "backupper" angemeldet.
Wir überprüfen die vorhandenen Home-Verzeichnisse.
Wir wechseln in das Home-Verzeichnis von "backupper".
Wir zeigen den Inhalt des Home-Verzeichnisses an. Wir finden eine Datei namens flag.txt.
Wir lesen den Inhalt der Datei flag.txt.
Wir wechseln in das .ssh-Verzeichnis und listen den Inhalt auf. Wir finden die Dateien id_rsa, id_rsa.pub und known_hosts.
Wir lesen den Inhalt der Datei id_rsa, die den privaten SSH-Schlüssel enthält.
Wir haben den verschlüsselten privaten SSH-Schlüssel von Benutzer "backupper" gefunden.
Wir konvertieren den SSH-Schlüssel mit ssh2john in ein John-the-Ripper-kompatibles Format.
Wir verwenden John the Ripper, um das Passwort des SSH-Schlüssels zu knacken. Das Passwort ist "samantha1".
Wir verbinden uns mit SSH als Benutzer "jaap" und verwenden den geknackten SSH-Schlüssel. Die Anmeldung ist erfolgreich!
Wir zeigen den Inhalt des Home-Verzeichnisses an. Wir finden eine Datei namens flag.txt.
Wir überprüfen unsere Benutzer-ID. Wir sind als Benutzer "jaap" angemeldet.
Wir überprüfen, ob der Benutzer "jaap" Sudo-Rechte hat.
Der Befehl sudo ist nicht verfügbar. Dies bedeutet, dass wir keine direkten Sudo-Rechte haben.
Wir lesen die Datei flag.txt. Sie enthält eine Base64-kodierte Zeichenkette.
Wir überprüfen die laufenden Dienste mit ss -altpn. Wir sehen SSH (22), einen Mailserver (25) und HTTP (80).
Wir verbinden uns mit Telnet zum Mailserver (Port 25) auf dem lokalen System.
Wir wechseln in das bin-Verzeichnis und listen den Inhalt auf. Wir finden die ausführbaren Dateien find und startserver.sh.
Wir zeigen den Inhalt des Skripts startserver.sh an. Es schreibt eine "1" in die Datei /tmp/start und beendet sich dann.
Wir überprüfen den Dateityp von find. Es ist ein SUID-Binary, was bedeutet, dass es mit den Rechten des Besitzers (in diesem Fall "jaap" und "remnie") ausgeführt wird.
Wir verwenden strings, um lesbare Zeichenketten in der ausführbaren Datei find zu finden. Die Ausgabe enthält interessante Begriffe wie "shell", "shell-escape" und "c-maybe", die auf eine mögliche Ausnutzung hindeuten könnten.
Wir nutzen die SUID-Berechtigung des find-Befehls, um mit erhöhten Rechten einen Befehl auszuführen. Wir verwenden die Option -exec, um /bin/sh -p auszuführen. Die Option -p sorgt dafür, dass die Shell ihre Privilegien behält.
Die Ausgabe des Befehls id zeigt, dass die effektive Gruppen-ID (egid) jetzt "remnie" ist.
Wir verwenden base64 -d, um die Base64-kodierte Zeichenkette zu dekodieren. Das Ergebnis ist ein Befehl zum Starten einer Reverse Shell.
find und Dekodierung von Base64Dieser Proof of Concept demonstriert, wie wir mit der SUID-Binary find und der anschließenden Dekodierung einer Base64-Zeichenkette eine Reverse Shell mit den Privilegien des Benutzers "remnie" erhalten.
In der Reconnaissance-Phase sammeln wir Informationen über das Zielsystem. Wir beginnen mit der Identifizierung von Hosts im Netzwerk und der Analyse offener Ports und Dienste.