Beginn der Aufklärungsphase zur Identifizierung des Ziels "Key" im Netzwerk.
Die IP-Adresse die zum scannen verwendet wird lautet: 192.168.2.129
**Analyse:** Die IP-Adresse des Zielsystems für diesen Test wird als `192.168.2.129` festgelegt.
**Bewertung:** Basisinformation für alle folgenden Operationen.
**Empfehlung (Pentester):** IP in Variable speichern (`export IP=192.168.2.129`).
**Empfehlung (Admin):** Keine Aktion erforderlich.
ARP-Scan
192.168.2.129
**Analyse:** Ein ARP-Scan bestätigt die Präsenz der IP `192.168.2.129` im Netzwerk. (Die MAC-Adresse fehlt hier im Log, wurde aber im Nmap-Scan später als `08:00:27:60:60:07` identifiziert).
**Bewertung:** Ziel erreichbar.
**Empfehlung (Pentester):** Weiter mit Port-Scanning.
**Empfehlung (Admin):** Keine Aktion.
/etc/hosts
127.0.0.1 localhost
192.168.2.129 key.nyx
**Analyse:** Die lokale `/etc/hosts`-Datei des Angreifers wird angepasst, um der IP `192.168.2.129` den Hostnamen `key.nyx` zuzuordnen.
**Bewertung:** Standardvorgehen zur Vereinfachung der Ansprache.
**Empfehlung (Pentester):** Hostnamen verwenden.
**Empfehlung (Admin):** DNS bevorzugen.
Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-09-16 13:58 CEST Nmap scan report for key.nyx (192.168.2.129) Host is up (0.00024s latency). Not shown: 65533 closed tcp ports (reset) PRT STATE SERVICE VERSIN 22/tcp open ssh penSSH 8.4p1 Debian 5+deb11u1 (protocol 2.0) | ssh-hostkey: | 3072 51:f9:f5:59:cd:45:4e:d1:2c:06:41:3b:a6:7a:91:19 (RSA) | 256 5c:9f:60:b7:c5:50:fc:01:fa:37:7c:dc:16:54:87:3b (ECDSA) |_ 256 04:da:68:25:69:d6:2a:25:e2:5b:e2:99:36:36:d7:48 (ED25519) 80/tcp open http Apache httpd 2.4.54 ((Debian)) |_http-title: Apache2 Test Debian Default Page: It works |_http-server-header: Apache/2.4.54 (Debian) MAC Address: 08:00:27:60:60:07 (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.24 ms key.nyx (192.168.2.129)
**Analyse:** Ein initialer Nmap TCP-Scan (`-sS -sC -sV -A -p-`) wird durchgeführt.
**Bewertung:** Findet nur zwei offene TCP-Ports: * **Port 22 (SSH):** OpenSSH 8.4p1 (Debian 11) - Relativ aktuell. * **Port 80 (HTTP):** Apache httpd 2.4.54 (Debian) - Relativ aktuell, zeigt Apache-Standardseite. Auf den ersten Blick scheint das Ziel sehr begrenzt zu sein. Der Scan hat **Port 6379 (Redis)** übersehen, der später per IPv6 gefunden wird. Dies deutet auf einen Fehler im ersten Scan-Befehl oder der Auswertung hin, oder darauf, dass der Redis-Dienst nur an die IPv6-Adresse gebunden war (was aber durch spätere Tests widerlegt wird).
**Empfehlung (Pentester):** Die Standardseite auf Port 80 untersuchen. Erneute, gründlichere Scans (insbesondere UDP und spezifische Ports wie 6379) oder IPv6-Scans in Betracht ziehen, falls Port 80 keine Angriffsfläche bietet.
**Empfehlung (Admin):** Sicherstellen, dass alle offenen Ports beabsichtigt und sicher sind.
Untersuchung des Apache-Webservers auf Port 80.
Allow: GET,PST,PTINS,HEAD
**Analyse:** Test der erlaubten HTTP-Methoden auf Port 80.
**Bewertung:** Erlaubt sind `GET`, `PST` (wahrscheinlich POST), `PTINS` und `HEAD`. Die ungewöhnlichen Methoden `PST` und `PTINS` könnten interessant sein, sind aber oft Fehlkonfigurationen ohne Auswirkung.
**Empfehlung (Pentester):** Testen der ungewöhnlichen Methoden, aber keine hohe Priorität.
**Empfehlung (Admin):** Unnötige Methoden deaktivieren.
WEB-Server Scan : * Trying 192.168.2.129:80... * Connected to 192.168.2.129 (192.168.2.129) port 80 > HEAD / HTTP/1.1 > Host: 192.168.2.129 > User-Agent: curl/8.8.0 > Accept: */* > * Request completely sent off < HTTP/1.1 200 K HTTP/1.1 200 K < Date: Mon, 16 Sep 2024 11:59:29 GMT Date: Mon, 16 Sep 2024 11:59:29 GMT < Server: Apache/2.4.54 (Debian) Server: Apache/2.4.54 (Debian) < Last-Modified: Tue, 19 Jul 2022 13:04:12 GMT Last-Modified: Tue, 19 Jul 2022 13:04:12 GMT < ETag: "29d1-5e4281ef033d9" ETag: "29d1-5e4281ef033d9" < Accept-Ranges: bytes Accept-Ranges: bytes < Content-Length: 10705 Content-Length: 10705 < Vary: Accept-Encoding Vary: Accept-Encoding < Content-Type: text/html Content-Type: text/html
**Analyse:** Abruf der HTTP-Header von Port 80.
**Bewertung:** Bestätigt Apache 2.4.54 und die Standard-Debian-Seite (`Content-Length: 10705`).
**Empfehlung (Pentester):** Standardseite, wahrscheinlich uninteressant.
**Empfehlung (Admin):** Keine Aktion.
Nikto v2.5.0 + Target IP: 192.168.2.129 + Target Hostname: 192.168.2.129 + Target Port: 80 + Start Time: 2024-09-16 13:59:30 (GMT2) + Server: Apache/2.4.54 (Debian) + /: The anti-clickjacking X-Frame-ptions header is not present. See: [Link: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-ptions | Ziel: 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: [Link: https://www.netsparker.com/web-vulnerability-scanner/vulnerabilities/missing-content-type-header/ | Ziel: 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) + /: Server may leak inodes via ETags, header found with file /, inode: 29d1, size: 5e4281ef033d9, mtime: gzip. See: [Link: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-1418 | Ziel: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-1418] + PTINS: Allowed HTTP Methods: GET, PST, PTINS, HEAD . + 8102 requests: 0 error(s) and 4 item(s) reported on remote host + End Time: 2024-09-16 13:59:46 (GMT2) (16 seconds) + 1 host(s) tested
**Analyse:** Nikto-Scan gegen Port 80.
**Bewertung:** Bestätigt Apache 2.4.54. Findet nur Standard-Konfigurationsmängel (fehlende Header, ETag-Leak) und die erlaubten Methoden. Keine kritischen Funde.
**Empfehlung (Pentester):** Port 80 scheint gehärtet oder uninteressant zu sein.
**Empfehlung (Admin):** Fehlende Header implementieren, ETag-Konfiguration prüfen.
http://key/index.html (Falscher Hostname im Log?) http://192.168.2.129/index.html (Status: 200) [Size: 10705]
**Analyse:** Gobuster-Scan auf Port 80.
**Bewertung:** Findet nur `index.html`. Keine weiteren Verzeichnisse oder Dateien.
**Empfehlung (Pentester):** Webserver auf Port 80 bietet keine Angriffsfläche. Erneute Überprüfung der Nmap-Scans oder anderer Methoden zur Diensterkennung ist ratsam.
**Empfehlung (Admin):** Keine Aktion.
Nachdem die Web-Enumeration auf Port 80 keine Ergebnisse brachte und der initiale Nmap-Scan möglicherweise unvollständig war, wird ein erneuter, gezielterer Scan durchgeführt, der den Redis-Dienst aufdeckt.
Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-09-16 15:45 CEST ... Initiating SYN Stealth Scan at 15:45 Scanning key (fe80a00:27ff:fe60:6007) [65535 ports] Discovered open port 80/tcp on fe80a00:27ff:fe60:6007 Discovered open port 22/tcp on fe80a00:27ff:fe60:6007 Discovered open port 6379/tcp on fe80a00:27ff:fe60:6007 Completed SYN Stealth Scan at 15:45, 2.35s elapsed (65535 total ports) ... Nmap scan report for key (fe80a00:27ff:fe60:6007) Host is up (0.00010s latency). Not shown: 65532 closed tcp ports (reset) PRT STATE SERVICE VERSIN 22/tcp open ssh penSSH 8.4p1 Debian 5+deb11u1 (protocol 2.0) 80/tcp open http Apache httpd 2.4.54 ((Debian)) 6379/tcp open redis Redis key-value store 6.0.16
Seltsamer Weise wird der Port hier angezeigt dort mit unserer eigentlichen
Technik jedoch immer noch nicht
Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-09-16 15:46 CEST Nmap scan report for key (fe80a00:27ff:fe60:6007) Host is up (0.00015s latency). Not shown: 998 closed tcp ports (reset) PRT STATE SERVICE 22/tcp open ssh 80/tcp open http MAC Address: 08:00:27:60:60:07 (racle VirtualBox virtual NIC)
Der Fehler war dass wir durch das nicht angeben von -p- nur die ersten hundert Ports gescant haben. Unserer der nicht gefunden wurde dadurch ausserhalb des Bereichs lag. Wird im Script sofort angepasst und getestet
**Analyse:** Ein erneuter, vollständiger Portscan (`-p-`) wird gegen die **IPv6**-Adresse durchgeführt. Dieser Scan entdeckt nun **Port 6379 (Redis)** als offen, zusätzlich zu den bekannten Ports 22 und 80. Der anschließende Scan ohne `-p-` bestätigt, dass der Standard-Nmap-Scan (Top 1000 Ports) den Port 6379 übersieht.
**Bewertung:** **Wichtiger Fund!** Der Redis-Dienst auf Port 6379 ist ein neuer Angriffsvektor. Der anfängliche IPv4-Scan hatte diesen Port ebenfalls übersehen, was die Bedeutung vollständiger Portscans (`-p-`) unterstreicht. Redis ist oft unsicher konfiguriert und ermöglicht unauthentifizierten Zugriff.
**Empfehlung (Pentester):** Untersuchen Sie den Redis-Dienst auf Port 6379. Versuchen Sie, sich ohne Passwort zu verbinden (`redis-cli`). Führen Sie Redis-spezifische Enumerations- und Exploit-Versuche durch (z.B. über Metasploit oder manuell).
**Empfehlung (Admin):** Stellen Sie sicher, dass Redis durch ein Passwort geschützt ist (`requirepass`). Binden Sie Redis nur an notwendige Schnittstellen (idealerweise nur localhost, wenn kein Fernzugriff benötigt wird).
Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-09-16 22:00 CEST Nmap scan report for key.nyx (192.168.2.129) Host is up (0.00018s latency). PRT STATE SERVICE 6379/tcp closed redis MAC Address: 08:00:27:60:60:07 (racle VirtualBox virtual NIC) Nmap done: 1 IP address (1 host up) scanned in 0.25 seconds
**Analyse:** Versuch, Redis-Passwörter über die **IPv4**-Adresse mit dem Nmap-Skript `redis-brute` zu knacken.
**Bewertung:** Der Scan meldet Port 6379 auf der IPv4-Adresse als `closed`. Dies bestätigt, dass der Redis-Dienst **nur an die IPv6-Adresse gebunden** ist.
**Empfehlung (Pentester):** Führen Sie alle Redis-Interaktionen über die IPv6-Adresse (`fe80a00:27ff:fe60:6007%eth0`) durch.
**Empfehlung (Admin):** Überprüfen Sie die `bind`-Konfiguration in der Redis-Konfigurationsdatei (`redis.conf`). Binden Sie den Dienst bewusst an die gewünschten Adressen.
Could not connect to Redis at 192.168.2.129:6379: Connection refused
not connected>
**Analyse:** Versuch, sich mit `redis-cli` über die IPv4-Adresse zu verbinden.
**Bewertung:** Scheitert mit "Connection refused", bestätigt erneut, dass Redis nicht an IPv4 lauscht.
**Empfehlung (Pentester):** IPv6-Adresse verwenden.
**Empfehlung (Admin):** Keine Aktion.
(Moduloptionen werden angezeigt)
COMMAND => INFO
RHOSTS => 192.168.2.129
RPORT => 6379
THREADS => 1
[*] 192.168.2.129:6379 - Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
RHOSTS => fe80a00:27ff:fe60:6007%eth0
[+] fe80a00:27ff:fe60:6007%eth0:6379 - Found redis with INFO command: $3628\x0d\x0a# Server\x0d\x0aredis_version:6.0.16\x0d\x0a... (sehr lange INFO-Ausgabe) ...
[*] fe80a00:27ff:fe60:6007%eth0:6379 - Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
**Analyse:** Das Metasploit-Modul `redis_server` wird verwendet, um Informationen vom Redis-Server abzufragen (`COMMAND INFO`). Zuerst wird die IPv4-Adresse getestet (scheitert), dann die IPv6-Adresse.
**Bewertung:** Der Scan gegen die IPv6-Adresse ist erfolgreich und liefert eine Fülle von Informationen aus dem `INFO`-Befehl, darunter Redis-Version (6.0.16), OS (Linux 5.10), Prozess-ID, Konfigurationsdetails, Speicherverbrauch etc. Entscheidend ist, dass die Verbindung **ohne Passwort** möglich war.
**Empfehlung (Pentester):** Der Redis-Server ist unauthentifiziert zugänglich. Dies ist eine kritische Schwachstelle. Verbinden Sie sich mit `redis-cli -h IPv6_ADRESSE` und prüfen Sie, welche Daten gespeichert sind und ob Sie Konfigurationsparameter ändern oder Befehle ausführen können.
**Empfehlung (Admin):** Aktivieren Sie dringend die Passwortauthentifizierung für Redis (`requirepass`).
... (Bereinigte Ausgabe des INFO-Befehls) ...
config_file:\
...
dbfilename
dump.rdb
...
dir
/home/dick
...
requirepass
...
**Analyse:** Die lange `INFO`-Ausgabe von Metasploit wird mit Textmanipulationswerkzeugen (`tr`, `sort`, `grep`) bereinigt und nach interessanten Schlüsselwörtern durchsucht.
**Bewertung:** Hebt wichtige Konfigurationsdetails hervor: * `config_file:` ist leer (Redis wurde ohne explizite Konfigurationsdatei gestartet). * `dbfilename`: `dump.rdb` (Standardname für Speicherabbilder). * `dir`: `/home/dick` (Das Arbeitsverzeichnis von Redis!). * `requirepass` ist leer (Kein Passwort gesetzt). Dass das Arbeitsverzeichnis `/home/dick` ist, ist **extrem kritisch**. Redis kann in dieses Verzeichnis schreiben, wenn Speicherabbilder erstellt werden (`SAVE` oder `BGSAVE`).
**Empfehlung (Pentester):** Dies eröffnet einen klassischen Redis-Exploit-Pfad: Schreiben Sie Ihren öffentlichen SSH-Schlüssel in die Redis-Datenbank, ändern Sie das Arbeitsverzeichnis auf `/home/dick/.ssh`, ändern Sie den `dbfilename` auf `authorized_keys` und erzwingen Sie ein `SAVE`. Dadurch wird Ihr Schlüssel in die `authorized_keys`-Datei des Benutzers `dick` geschrieben, was einen SSH-Login ermöglicht.
**Empfehlung (Admin):** Starten Sie Redis niemals mit einem Benutzerverzeichnis als Arbeitsverzeichnis! Konfigurieren Sie `dir` auf ein dediziertes Verzeichnis (z.B. `/var/lib/redis`). Passwortschutz aktivieren.
[fe80a00:27ff:fe60:6007%eth0]:6379> id (error) ERR unknown command `id`, with args beginning with: [fe80a00:27ff:fe60:6007%eth0]:6379> info # Server redis_version:6.0.16 ... (INFO Ausgabe) ... [fe80a00:27ff:fe60:6007%eth0]:6379> client list id=8 addr=[fe80a00:27ff:fe30:2eda]:54936 fd=8 name= age=221 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=26 qbuf-free=32742 argv-mem=10 obl=0 oll=0 omem=0 tot-mem=61466 events=r cmd=client user=default [fe80a00:27ff:fe60:6007%eth0]:6379> CONFIG GET * 1) "rdbchecksum" 2) "yes" ... 285) "dir" 286) "/home/dick" 287) "save" ... 299) "requirepass" 300) "" ... [fe80a00:27ff:fe60:6007%eth0]:6379> slowlog get 25 (empty array) [fe80a00:27ff:fe60:6007%eth0]:6379> INFO keyspace # Keyspace
**Analyse:** Erfolgreiche Verbindung mit `redis-cli` über IPv6 ohne Passwort. Verschiedene Redis-Befehle werden ausgeführt (`info`, `client list`, `config get *`, `slowlog`, `info keyspace`).
**Bewertung:** Bestätigt den unauthentifizierten Zugriff und die Konfigurationsdetails, insbesondere `dir "/home/dick"` und `requirepass ""`.
**Empfehlung (Pentester):** Fahren Sie mit dem SSH-Key-Injection-Exploit fort.
**Empfehlung (Admin):** Redis absichern (Passwort, Verzeichnis).
**Schritt: Redis SSH Key Injection Exploit**
K
K
**Analyse:** Die Redis-Konfiguration wird zur Laufzeit geändert: Das Arbeitsverzeichnis (`dir`) wird auf `/home/dick/.ssh` gesetzt und der Dateiname für Speicherabbilder (`dbfilename`) auf `authorized_keys`.
**Bewertung:** Vorbereitung des Angriffs. Der nächste `SAVE`-Befehl wird versuchen, den aktuellen Redis-Speicherinhalt in `/home/dick/.ssh/authorized_keys` zu schreiben.
**Empfehlung (Pentester):** Fügen Sie nun Ihren öffentlichen SSH-Schlüssel als Wert in die Redis-Datenbank ein.
**Empfehlung (Admin):** Verhindern Sie den Zugriff auf den `CONFIG`-Befehl für unauthentifizierte Benutzer oder benennen Sie ihn um (`rename-command CONFIG ""`).
K
K
**Analyse:** 1. Der öffentliche SSH-Schlüssel des Angreifers (`~/.ssh/id_rsa.pub`) wird mit zusätzlichen Leerzeilen davor und danach in eine lokale Datei `publickey.txt` geschrieben. (Die Leerzeilen sollen sicherstellen, dass der Schlüssel korrekt formatiert ist). 2. Der Inhalt von `publickey.txt` wird über eine Pipe an `redis-cli` übergeben, das den `SET`-Befehl ausführt (`-x set ssh_key`). Dies speichert den öffentlichen Schlüssel als Wert für den Redis-Schlüssel `ssh_key`. 3. Der `SAVE`-Befehl wird in Redis ausgeführt.
**Bewertung:** Der `SAVE`-Befehl schreibt den aktuellen Inhalt der Redis-Datenbank (der nun den öffentlichen Schlüssel enthält) in die Datei, die durch `dir` und `dbfilename` spezifiziert wurde: `/home/dick/.ssh/authorized_keys`. Damit wurde der öffentliche Schlüssel des Angreifers erfolgreich in die `authorized_keys`-Datei des Benutzers `dick` auf dem Zielsystem geschrieben.
**Empfehlung (Pentester):** Versuchen Sie nun, sich per SSH als Benutzer `dick` mit Ihrem privaten Schlüssel anzumelden.
**Empfehlung (Admin):** Redis absichern! Überprüfen Sie die `authorized_keys`-Dateien auf nicht autorisierte Einträge.
Nachdem der öffentliche SSH-Schlüssel des Angreifers über die Redis-Schwachstelle in die `authorized_keys`-Datei des Benutzers `dick` geschrieben wurde, wird nun der SSH-Login versucht.
Enter passphrase for key '.ssh/id_rsa': (Passphrase wird eingegeben) Linux key 5.10.0-16-amd64 #1 SMP Debian 5.10.127-1 (2022-06-30) x86_64 Last login: Sun May 21 19:09:56 2023 from 192.168.1.10 dick@key$
**Analyse:** SSH-Login als Benutzer `dick` unter Verwendung der IPv6-Adresse und des privaten Schlüssels des Angreifers (`.ssh/id_rsa`). Eine Passphrase für den Schlüssel wird eingegeben.
**Bewertung:** **Initial Access erfolgreich!** Der Exploit über Redis hat funktioniert, und wir haben eine Shell als Benutzer `dick`.
**Empfehlung (Pentester):** Beginnen Sie mit der Enumeration für Privilegienerweiterung als `dick`.
**Empfehlung (Admin):** Redis absichern, kompromittierten Benutzer `dick` untersuchen, nicht autorisierte SSH-Schlüssel entfernen.
**Kurzbeschreibung:** Der Redis-Dienst auf Port 6379 (nur IPv6) war ohne Authentifizierung zugänglich. Die Redis-Instanz lief mit `/home/dick` als Arbeitsverzeichnis (`dir`). Dies ermöglichte einem Angreifer, sich mit `redis-cli` zu verbinden, das Arbeitsverzeichnis auf `/home/dick/.ssh` und den Datenbank-Dateinamen auf `authorized_keys` zu ändern. Anschließend wurde der öffentliche SSH-Schlüssel des Angreifers in die Redis-Datenbank geschrieben und mittels `SAVE`-Befehl in die Datei `/home/dick/.ssh/authorized_keys` gespeichert. Dies erlaubte einen anschließenden passwortlosen (bzw. Key-basierten) SSH-Login als Benutzer `dick`.
**Voraussetzungen:**
**Schritte (Zusammenfassung):**
**Risikobewertung:** Kritisch. Ein ungesicherter Redis-Dienst mit einer unsicheren Verzeichniskonfiguration ermöglichte die vollständige Übernahme eines Benutzerkontos.
**Empfehlungen:**
Wir haben eine Shell als Benutzer `dick`. Nun suchen wir nach Wegen zu Root.
Matching Defaults entries for dick on key:
env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin
User dick may run the following commands on key:
(gary) NPASSWD: /usr/bin/perl
**Analyse:** Überprüfung der sudo-Rechte für `dick`.
**Bewertung:** `dick` darf `/usr/bin/perl` als Benutzer `gary` ohne Passwort ausführen. Perl ist ein Skriptinterpreter und kann leicht zur Ausführung von Shell-Befehlen missbraucht werden.
**Empfehlung (Pentester):** Nutzen Sie Perl, um eine Shell als `gary` zu erhalten: `sudo -u gary /usr/bin/perl -e 'exec "/bin/bash";'`.
**Empfehlung (Admin):** Entfernen Sie diese unsichere sudo-Regel. Erlauben Sie niemals die Ausführung von Interpretern wie Perl via sudo.
dick gary
user.txt
c58f5b2a916dc3287ec6901777ba7912
**Analyse:** Auflisten des übergeordneten Verzeichnisses (`/home`) zeigt den Benutzer `gary`. Die User-Flag wird im Home-Verzeichnis von `dick` gefunden und gelesen.
**Bewertung:** User-Flag gefunden. Bestätigt `gary` als Ziel für die horizontale Bewegung.
**Empfehlung (Pentester):** Flag notieren, PrivEsc zu `gary` durchführen.
**Empfehlung (Admin):** Keine Aktion.
**Analyse:** Der Perl-Befehl wird mit `sudo -u gary` ausgeführt, um eine Bash-Shell zu starten.
**Bewertung:** **Erfolg!** Wir haben nun eine Shell als Benutzer `gary`.
**Empfehlung (Pentester):** Überprüfen Sie die sudo-Rechte für `gary`.
**Empfehlung (Admin):** Sudo-Regel für `dick` entfernen.
Matching Defaults entries for gary on key:
env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin
User gary may run the following commands on key:
(root) NPASSWD: /usr/bin/runc
**Analyse:** Überprüfung der sudo-Rechte für `gary`.
**Bewertung:** **Entscheidender Fund!** `gary` darf `/usr/bin/runc` als `root` ohne Passwort ausführen. `runc` ist ein Low-Level-Container-Runtime-Tool. Fehlkonfigurationen oder die Möglichkeit, eigene Container-Spezifikationen zu laden, können zur Privilegienerweiterung missbraucht werden.
**Empfehlung (Pentester):** Recherchieren Sie Methoden zur Privilegienerweiterung mittels `sudo runc` (z.B. GTFOBins). Der typische Weg ist das Erstellen einer manipulierten `config.json`-Spezifikation, die das Host-Dateisystem mountet.
**Empfehlung (Admin):** Entfernen Sie diese gefährliche sudo-Regel. Gewähren Sie keine sudo-Rechte für Container-Runtimes an unprivilegierte Benutzer.
**Privilege Escalation per runc Config Manipulation**
config.json
...(Bearbeiten der config.json, Einfügen des bind-mounts für '/')
**Analyse:** 1. `sudo runc spec` wird ausgeführt, um eine Standard-Container-Spezifikationsdatei (`config.json`) zu erstellen. 2. Ein leeres Verzeichnis `rootfs` wird erstellt, das als Root-Dateisystem für den Container dienen soll. 3. Die `config.json` wird bearbeitet (`nano`).
**Bewertung:** Vorbereitung des Exploits. Der entscheidende Schritt ist das Hinzufügen eines speziellen Mount-Eintrags in `config.json`.
**Empfehlung (Pentester):** Fügen Sie den Bind-Mount für `/` in den `mounts`-Abschnitt der `config.json` ein.
**Empfehlung (Admin):** Sudo-Regel entfernen.
Configuration
Dieser Teil muss in die Config.json Datei eingebunden werden :
und zwar genau ab diesem Abschnitt in mounts reinhängen:
...
"hostname": "runc",
"mounts": [
...
Der Teil der eingebunden wird
{
"type": "bind",
"source": "/",
"destination": "/",
"options": [
"rbind",
"rw",
"rprivate"
]
},
...
Gesamte Configuration mit eingebundenen Teil
... (vollständige config.json mit eingefügtem Mount) ...
**Analyse:** Zeigt den genauen JSON-Block, der in den `mounts`-Abschnitt der `config.json` eingefügt werden muss. Dieser Block weist `runc` an, das Root-Verzeichnis des Hosts (`source: "/"`) rekursiv (`rbind`) mit Lese-/Schreibzugriff (`rw`) in das Root-Verzeichnis des Containers (`destination: "/"`) einzuhängen.
**Bewertung:** Dies ist der Kern des Exploits. Wenn ein Container mit dieser Konfiguration als Root gestartet wird, hat man innerhalb des Containers vollen Zugriff auf das Dateisystem des Hosts.
**Empfehlung (Pentester):** Stellen Sie sicher, dass die `config.json` korrekt modifiziert wurde.
**Empfehlung (Admin):** Sudo-Regel entfernen.
rm: ¿borrar el fichero regular 'config.json' protegido contra escritura? (s/n) s
<> es wird nicht zugelassen die Datei so abzuspeichern, deshalb löschen wir sie und erstellen eine neue , damit gehts <>
**Analyse:** Hier scheint es Probleme beim direkten Speichern der modifizierten `config.json` mit `nano` gegeben zu haben (möglicherweise Berechtigungsprobleme, obwohl `runc spec` die Datei erstellt hat). Als Workaround wird die ursprüngliche `config.json` gelöscht, neu erstellt, in eine temporäre Datei (`demo`) kopiert, das Original wieder gelöscht, der Inhalt aus der temporären Datei zurückkopiert und dann erneut mit `nano` bearbeitet.
**Bewertung:** Umständlicher Workaround, um die `config.json` mit dem notwendigen Mount-Eintrag zu versehen. Das Ziel bleibt dasselbe.
**Empfehlung (Pentester):** Sicherstellen, dass die finale `config.json` den korrekten Mount-Eintrag enthält.
**Empfehlung (Admin):** Keine Aktion.
# id uid=0(root) gid=0(root) groups=0(root) #
**Analyse:** Der Befehl `sudo runc run demo` wird ausgeführt. `runc run` startet einen neuen Container mit dem Namen (ID) `demo` basierend auf der `config.json` im aktuellen Verzeichnis. Da die `config.json` den Mount des Host-Root-Verzeichnisses enthält und der Prozess im Container als Root (uid=0, gid=0 laut `config.json`) startet, erhalten wir eine Shell mit Root-Rechten auf das gemountete Host-System.
**Bewertung:** **Privilege Escalation erfolgreich!** Der `id`-Befehl innerhalb des Containers bestätigt Root-Rechte.
**Empfehlung (Pentester):** Sie haben nun eine Root-Shell auf dem Host-System (innerhalb der Container-Umgebung, aber mit Zugriff auf das Host-Root `/`). Suchen Sie die Root-Flag.
**Empfehlung (Admin):** Sudo-Regel für `runc` entfernen!
**Kurzbeschreibung:** Der Benutzer `gary` hatte `sudo`-Rechte, um `/usr/bin/runc` als `root` auszuführen. Dies wurde ausgenutzt, indem eine Standard-Container-Spezifikation (`config.json`) mittels `runc spec` erstellt wurde. Diese Spezifikation wurde dann manuell bearbeitet, um einen `bind`-Mount hinzuzufügen, der das Root-Verzeichnis (`/`) des Host-Systems in das Root-Verzeichnis (`/`) des Containers mountet. Durch Starten eines Containers mit dieser modifizierten Konfiguration (`sudo runc run
**Voraussetzungen:**
**Erwartetes Ergebnis:** Erlangen einer Root-Shell auf dem Host-System.
**Schritte (Zusammenfassung):**
**Risikobewertung:** Kritisch. Das Erlauben der Ausführung von `runc` via `sudo` für unprivilegierte Benutzer ist extrem gefährlich und führt fast zwangsläufig zu einer vollständigen Systemkompromittierung.
**Empfehlungen:** Niemals `runc` oder ähnliche Container-Runtimes über `sudo` für nicht vertrauenswürdige Benutzer erlauben.
22c15f8a6b80b178f36f3fcf5053bd82
c58f5b2a916dc3287ec6901777ba7912
0210bf1feef973181bfff9a28e845f71
c4fe6806da41e3087eff3c01b1a98d5f
**Analyse:** Nachdem Root-Rechte über `runc` erlangt wurden, wird die Root-Flag aus `/root/root.txt` gelesen. Die User-Flag wurde bereits zuvor als Benutzer `dick` aus `/home/dick/user.txt` gelesen. (Die anderen User-Flags von 'Internal' und 'Jenk' scheinen hier versehentlich mitkopiert worden zu sein und gehören nicht zu 'Key').
**Bewertung:** User- und Root-Flags für die Maschine "Key" wurden erfolgreich gefunden und erfasst.
**Empfehlung (Pentester):** Bericht abschließen.
**Empfehlung (Admin):** Alle identifizierten Schwachstellen beheben (Redis-Fehlkonfiguration, unsichere sudo-Regeln für Perl und runc). Systemintegrität prüfen.