Privilege Escalation
Analyse: Nachdem ich als Benutzer `lois` Zugriff auf das System erlangt habe, beginne ich mit der internen Enumeration. Ich finde die `user.txt` in Lois' Home-Verzeichnis und kann sie direkt lesen. Anschließend überprüfe ich die `sudo`-Berechtigungen mit `sudo -l`.
Bewertung: Die User-Flag ist schnell gesichert. Die `sudo -l`-Ausgabe enthüllt einen klaren Weg für die Privilegienerweiterung: Der Benutzer `lois` darf den Befehl `/usr/bin/cat /root/startup.log` mit `root`-Rechten und ohne Passwort ausführen. Dies bedeutet, ich kann den Inhalt dieser spezifischen Log-Datei im `root`-Verzeichnis lesen.
Empfehlung (Pentester): Der nächste logische Schritt ist, diese `sudo`-Regel auszunutzen und den Inhalt von `/root/startup.log` zu lesen. Ich erwarte, darin sensible Informationen wie Passwörter oder Hinweise auf weitere Schwachstellen zu finden.
Empfehlung (Admin): `sudo`-Regeln, die das Lesen von Dateien als `root` erlauben, müssen mit äußerster Vorsicht behandelt werden. Auch wenn es sich "nur" um eine Log-Datei handelt, können solche Dateien kritische Informationen enthalten. Der Zugriff sollte nur gewährt werden, wenn es absolut notwendig ist, und die Log-Dateien sollten regelmäßig auf sensible Einträge überprüft werden.
flag{user-f6b63474e7cc20b0893a82beb9e3b3fd}
Matching Defaults entries for lois on Griffin: env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin
User lois may run the following commands on Griffin:
(ALL) NOPASSWD: /usr/bin/cat /root/startup.log
Analyse: Bevor ich die Eskalation fortsetze, stabilisiere ich meinen Zugriff. Ich erstelle ein neues SSH-Schlüsselpaar und füge meinen öffentlichen Schlüssel zur `authorized_keys`-Datei im `.ssh`-Verzeichnis des `lois`-Benutzers hinzu. Dies ermöglicht mir einen direkten SSH-Login ohne auf die instabile Reverse-Shell angewiesen zu sein.
Bewertung: Der Wechsel zu einer vollwertigen SSH-Session ist ein entscheidender Schritt für die Effizienz und Stabilität der weiteren Arbeit. Es macht die Enumeration und die Ausführung von Befehlen wesentlich einfacher und zuverlässiger.
Empfehlung (Pentester): Etabliere immer eine stabile und persistente Zugriffsmethode, sobald es möglich ist. SSH-Zugriff ist einer Reverse Shell fast immer vorzuziehen.
Empfehlung (Admin): Überwachen Sie die `authorized_keys`-Dateien der Benutzer. Das plötzliche Hinzufügen neuer Schlüssel kann ein Indikator für eine Kompromittierung sein. File Integrity Monitoring (FIM)-Systeme können solche Änderungen erkennen und melden.
Enter passphrase for key '.ssh/id_rsa': Linux Griffin 4.19.0-27-amd64 #1 SMP Debian 4.19.316-1 (2024-06-25) x86_64 ... lois@Griffin:~$
Analyse: Mit meiner stabilen Shell als `lois` entdecke ich durch einen `ss`-Befehl einen internen Dienst, der auf Port 80 nur auf `localhost` (127.0.0.1) lauscht. Um diesen von meiner Angreifer-Maschine aus zu erreichen, nutze ich `socat` auf dem Zielsystem, um den internen Port 80 auf einen extern zugänglichen Port (8001) weiterzuleiten.
Bewertung: Das Port-Forwarding ist erfolgreich. Ich kann nun auf den versteckten Apache-Webserver zugreifen. Ein `feroxbuster`-Scan auf diesen neuen Endpunkt findet ein Verzeichnis `/family/` mit einer `index.php`, einer `captcha.php` und einer `admin.php`. Die `robots.txt` enthält einen auffälligen Hinweis auf die `rockyou`-Wortliste.
Empfehlung (Pentester): Der Hinweis in der `robots.txt` ist eine klare Aufforderung, einen Brute-Force-Angriff auf die gefundene Login-Seite im `/family`-Verzeichnis zu starten. Die `captcha.php` stellt dabei die größte Herausforderung dar, die es zu überwinden gilt.
Empfehlung (Admin): Versteckte oder interne Web-Panels müssen genauso robust abgesichert werden wie externe. Der Hinweis in der `robots.txt` ist ein unnötiges Informationsleck, das Angreifern direkt den nächsten Schritt vorgibt.
Analyse: Um das CAPTCHA-geschützte Login anzugreifen, klone ich ein Python-Skript von GitHub (`CAPTCHA-Login-bruteforce`), das speziell für solche Szenarien entwickelt wurde. Es verwendet die OCR-Bibliothek `ddddocr`, um die CAPTCHAs automatisch zu lesen. Während der Einrichtung stoße ich auf ein Problem mit einer veralteten Funktion in der `ddddocr`-Bibliothek. Ich muss die Datei `__init__.py` manuell bearbeiten und `Image.ANTIALIAS` durch das neuere `Image.LANCZOS` ersetzen, damit das Skript funktioniert.
Bewertung: Die Anpassungsfähigkeit ist hier der Schlüssel. Anstatt aufzugeben, habe ich das Problem im Code der Bibliothek identifiziert und behoben. Nach der Korrektur starte ich den Brute-Force-Angriff. Das Skript löst erfolgreich die CAPTCHAs und testet Passwörter aus der `rockyou.txt`-Liste. Es identifiziert `savannah` als korrektes Passwort, als die Webseite mit einem HTTP-Status 302 (Redirect) antwortet.
Empfehlung (Pentester): Mit dem gefundenen Passwort (`savannah`) und einem Benutzernamen, der zum Thema passt (in diesem Fall `brian`), kann ich mich manuell einloggen, um die Session zu analysieren und den nächsten Schritt zu planen.
Empfehlung (Admin): CAPTCHA-Systeme müssen robust genug sein, um modernen OCR-Tools standzuhalten. Dies kann durch komplexere Verzerrungen, Hintergründe oder interaktive CAPTCHAs (wie reCAPTCHA) erreicht werden. Die Abhängigkeit von einem einfachen Bild-CAPTCHA ist oft unzureichend.
... [00152] george | captcha=8K5N | status=200 [00153] savannah | captcha=WAUX | status=302 🎉 FOUND: savannah
Analyse: Nach dem erfolgreichen Login mit `brian:savannah` fange ich die Antwort des Servers mit Burp Suite ab. Die Antwort enthält ein `Set-Cookie`-Header für ein `auth_token`. Das Token `9xyr8Ay3ohk8o97mHD8X4aAZf9BTkQZWc` sieht kodiert aus. Ich verwende CyberChef, um es zu analysieren, und stelle fest, dass eine Base58-Dekodierung gefolgt von einer Base64-Dekodierung die Klartext-Anmeldeinformationen `meg:lovelyfamily` enthüllt.
Bewertung: Dies ist eine kritische Sicherheitslücke. Sensible Daten (Anmeldeinformationen) werden direkt im Cookie gespeichert, nur durch eine einfache Kodierung verschleiert. Ich habe nun einen neuen Satz von Credentials für den Benutzer `meg`. Ich melde mich sofort per SSH mit `meg:lovelyfamily` an.
Empfehlung (Pentester): Mit dem neuen Benutzerzugang als `meg` muss der Enumerationsprozess wiederholt werden: Überprüfe die `sudo`-Rechte, suche nach interessanten Dateien und plane den nächsten Schritt zur Root-Eskalation.
Empfehlung (Admin): Speichern Sie niemals Klartext-Credentials oder andere sensible Daten in Cookies, auch nicht kodiert. Kodierung ist keine Verschlüsselung. Session-Token sollten zufällig generierte, serverseitig validierte Werte sein, die keine Informationen über den Benutzer preisgeben.
auth_token=9xyr8Ay3ohk8o97mHD8X4aAZf9BTkQZWc;
--[CyberChef]-->
meg:lovelyfamily
Analyse: Als Benutzer `meg` überprüfe ich die `sudo`-Berechtigungen. `meg` darf das Python-Skript `/root/game.py` als `root` ohne Passwort ausführen. Ich starte das Skript und sehe, dass es ein Challenge-Response-Spiel auf Port 6666 startet. Ich habe ein separates Python-Skript entwickelt, um die mehrstufige Challenge (Mathe, Caesar-Chiffre, MD5) automatisch zu lösen. Dies gibt mir eine Flag, aber es ist nicht die Root-Flag.
Bewertung: Das `game.py`-Skript ist eine komplexe falsche Fährte ("Red Herring"). Obwohl es eine `sudo`-Regel und eine interaktive Herausforderung gibt, führt es nicht zum Ziel. Aus der `/root/startup.log`, die ich zuvor als `lois` lesen konnte, habe ich das Passwort für den Benutzer `peter` erfahren. Dies ist der eigentliche Weg. Ich wechsle mit `su peter` die Identität.
Empfehlung (Pentester): Lassen Sie sich nicht von aufwändigen falschen Fährten ablenken. Wenn ein Weg nicht zur Eskalation führt, kehren Sie zu den gesammelten Informationen zurück und bewerten Sie andere potenzielle Pfade neu. Die Information aus der Log-Datei ist hier der Schlüssel.
Empfehlung (Admin): Die `sudo`-Regel für `game.py` ist extrem gefährlich. Selbst wenn es als Spiel gedacht war, könnte ein Angreifer versuchen, Schwachstellen im Python-Skript selbst zu finden (z.B. durch Injektionen in die Eingaben), um `root`-Code auszuführen.
User meg may run the following commands on Griffin:
(ALL) NOPASSWD: /usr/bin/python3 /root/game.py
Proof of Concept
Analyse: Als Benutzer `peter` überprüfe ich erneut die `sudo`-Berechtigungen. Die Ausgabe von `sudo -l` zeigt, dass `peter` den minimalistischen Texteditor `mg` auf jede beliebige Datei als `root` ohne Passwort ausführen darf.
Bewertung: Dies ist der finale und entscheidende Angriffsvektor. Viele einfache Texteditoren, die über `sudo` ausgeführt werden, bieten eine Möglichkeit, zu einer Shell auszubrechen oder Befehle auszuführen. Ich kann diese Berechtigung nutzen, um die `/etc/sudoers`-Datei zu bearbeiten und mir selbst volle `root`-Rechte zu geben.
Empfehlung (Pentester): Der Plan ist, `sudo /usr/bin/mg /etc/sudoers` auszuführen, die Zeile `peter ALL=(ALL:ALL) ALL` hinzuzufügen, die Datei zu speichern und dann mit `sudo su` eine `root`-Shell zu erhalten.
Empfehlung (Admin): Geben Sie Benutzern niemals `sudo`-Rechte für Texteditoren, insbesondere nicht für unkritische Dateien wie `/etc/sudoers`. Verwenden Sie `visudo` für die Bearbeitung dieser Datei. Wenn ein Benutzer eine Datei mit erhöhten Rechten bearbeiten muss, ist `sudoedit` die sicherere Wahl, da es in einer temporären Datei arbeitet und die Berechtigungen des Benutzers beibehält.
Matching Defaults entries for peter on Griffin:
env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin
User peter may run the following commands on Griffin:
(ALL) NOPASSWD: /usr/bin/mg
Analyse: Ich führe `sudo mg /etc/sudoers` aus, füge die Zeile `peter ALL=(ALL:ALL) ALL` hinzu und speichere die Datei. Ein anschließender `sudo -l` bestätigt, dass ich nun volle `root`-Berechtigungen habe. Mit `sudo su` wechsle ich endgültig zum `root`-Benutzer.
Bewertung: Der Angriff war erfolgreich. Ich habe die vollständige Kontrolle über das System erlangt. Der Weg führte über eine Kette von Benutzerwechseln und der Ausnutzung von `sudo`-Fehlkonfigurationen. Ich kann nun die finale Root-Flag lesen.
Empfehlung (Pentester): Der Test ist abgeschlossen. Der Weg zur Kompromittierung ist vollständig dokumentiert und alle Flags sind als Beweis gesichert.
Empfehlung (Admin): Dies zeigt, wie eine einzige unsichere `sudo`-Regel die gesamte Sicherheit des Systems untergraben kann. Führen Sie regelmäßige Audits der `/etc/sudoers`-Datei durch und befolgen Sie das Prinzip der geringsten Rechte strikt.
root@Griffin:/home/lois# id
uid=0(root) gid=0(root) groups=0(root)
root@Griffin:/home/lois#