Élévation de Privilèges Linux : Guide des Techniques (2026)

Qu'est-ce que l'élévation de privilèges Linux ?

Qu'est-ce que l'élévation de privilèges Linux ? L'élévation de privilèges Linux est la technique consistant à obtenir sur un système Linux des permissions supérieures à celles de votre compte actuel, généralement en passant d'un utilisateur standard ou de service à root. Elle exploite des mauvaises configurations locales, et non la faille distante qui vous a donné le shell au départ.

L'accès initial vous place rarement en tant que root. Une application web vulnérable tourne sous www-data, un service de base de données compromis sous son propre utilisateur restreint, une clé SSH vous donne un compte de connexion normal. Aucun de ceux-là ne peut lire /etc/shadow, installer une porte dérobée persistante ou pivoter avec un contrôle total. Root le peut. L'élévation est le pont entre les deux, et MITRE ATT&CK la suit comme une tactique à part entière, TA0004, car presque toute intrusion sérieuse en dépend.

Bonne nouvelle pour l'apprenant : l'élévation sous Linux est très majoritairement une affaire de configuration, pas de corruption mémoire. Vous n'avez pas besoin d'écrire une seule ligne d'assembleur pour rooter la plupart des machines. Vous devez énumérer avec méthode et reconnaître une poignée de motifs. C'est une compétence qui se construit par la répétition, pas par le talent.

Étape 1 - Énumérer la machine

L'énumération est le point de départ de tout shell root. Avant d'essayer quoi que ce soit, vous construisez une image du système : qui vous êtes, ce que vous pouvez lancer, et où la machine fait confiance à quelque chose qu'elle ne devrait pas.

Commencez par les trois commandes qui ne coûtent rien et donnent souvent la réponse d'emblée :

id                    # your UID, GID, and group memberships
sudo -l               # what you can run as root, with or without a password
find / -perm -4000 -type f 2>/dev/null   # every SUID binary on the system

L'appartenance aux groupes sur cette première ligne compte plus que les débutants ne le pensent. Si id vous montre dans le groupe docker, lxd ou disk, vous disposez d'un chemin quasi immédiat vers root avant même de regarder autre chose, car chacun de ces groupes peut être abusé pour lire ou écrire au-delà de la limite de votre utilisateur.

Ensuite, élargissez le filet : vérifiez le noyau avec uname -a, listez les tâches planifiées dans /etc/crontab et /etc/cron.d/, cherchez les capabilities avec getcap -r / 2>/dev/null, et lisez les fichiers de configuration lisibles par tous dans les racines web et les répertoires personnels à la recherche d'identifiants stockés. En pratique, des mots de passe de base de données posés dans un config.php ou un fichier .env sont l'un des chemins réels les plus courants, et aucun outil automatisé ne les priorise pour vous.

Tout faire à la main prend du temps, donc la plupart des testeurs lancent un script d'énumération automatisé pour balayer la machine en une passe. Notre guide LinPEAS couvre son installation, son exécution sans écrire sur le disque et la lecture de sa sortie colorée : rouge sur jaune signale un chemin d'élévation à forte probabilité. Le script n'exploite rien. Il vous dit où regarder ; c'est à vous d'ouvrir la porte.

Binaires SUID et SGID

Le bit SUID (Set User ID) indique à Linux d'exécuter un binaire avec les permissions de son propriétaire, et non de l'utilisateur qui l'a lancé. Quand le propriétaire est root, tout utilisateur pouvant exécuter ce binaire fait tourner son code en tant que root le temps de l'exécution. C'est voulu pour des outils comme passwd, qui doit écrire dans /etc/shadow. Cela devient un chemin d'élévation quand le bit SUID se retrouve sur un binaire que l'on peut pousser à exécuter des commandes arbitraires.

Votre sortie find / -perm -4000 liste tous les candidats. La plupart des entrées sont des binaires système standard. Ce que vous cherchez, c'est tout ce qui est inhabituel : une copie de find, nmap, vim, python, ou un outil interne maison avec le bit positionné. Recoupez chaque entrée inconnue avec GTFOBins, un catalogue de binaires Unix et de la syntaxe exacte pour en abuser.

L'exemple classique : si find porte lui-même le bit SUID, cette seule commande vous donne un shell root, car find exécute le shell engendré avec ses propres privilèges élevés :

find . -exec /bin/sh -p \; -quit
# id
uid=0(root) gid=0(root) groups=0(root)

Le drapeau -p sur le shell est la partie que l'on oublie. Sans lui, bash et sh abandonnent les privilèges élevés au démarrage par sécurité, et vous vous retrouvez avec votre utilisateur d'origine en vous demandant pourquoi l'exploit a échoué.

Mauvaises configurations de sudo

Lancez sudo -l et lisez chaque ligne. Elle montre exactement quelles commandes votre utilisateur peut lancer en tant que root, et chacune est un candidat. Une règle comme (ALL) NOPASSWD: /usr/bin/vim se lit comme une commodité administrative anodine jusqu'à ce que vous vérifiiez GTFOBins pour vim :

sudo vim -c ':!/bin/sh'

Cela s'échappe vers un shell root, car vim tourne en tant que root sous la règle sudo et peut engendrer un processus fils. La même logique s'applique à awk, less, find, python, tar et des dizaines d'autres interpréteurs et utilitaires. Toute règle sudo pointant vers quelque chose qui peut exécuter du code, lire des fichiers arbitraires ou écrire des fichiers arbitraires mérite une vérification avant que vous ne la supposiez sûre.

Deux astuces basées sur l'environnement méritent d'être connues. Si le fichier sudoers contient env_keep+=LD_PRELOAD, vous pouvez compiler un petit objet partagé qui engendre un shell et le précharger dans n'importe quelle commande autorisée par sudo. Et les anciennes versions de sudo portent des vulnérabilités pures et simples : Baron Samedit (CVE-2021-3156) a permis à tout utilisateur local d'atteindre root quelle que soit son entrée sudoers, sur les versions de sudo antérieures à 1.9.5p2. Vérifiez toujours sudo --version face aux CVE connues.

Capabilities Linux

Les capabilities sont la cousine à grain fin du bit SUID. Au lieu d'accorder à un binaire toute la puissance de root, Linux peut lui accorder un privilège précis, et les administrateurs les positionnent parfois en pensant qu'elles sont l'option la plus sûre. Souvent, elles ne le sont pas.

Énumérez-les avec getcap -r / 2>/dev/null. Celle à surveiller est cap_setuid. Si un interpréteur Python la porte, par exemple, la sortie ressemble à ceci :

/usr/bin/python3.11 = cap_setuid+ep

Cette seule capability suffit à devenir root, car le binaire peut fixer son propre UID à 0 puis exécuter un shell :

/usr/bin/python3.11 -c 'import os; os.setuid(0); os.system("/bin/sh")'

Les capabilities passent inaperçues justement parce qu'elles semblent granulaires et maîtrisées. En pratique, une capability cap_setuid ou cap_dac_read_search sur un binaire scriptable est tout aussi dangereuse qu'un binaire SUID root nu, et elle échappe aux relecteurs qui ne cherchent jamais que le bit SUID.

Abus des tâches cron

Les tâches planifiées qui tournent en tant que root mais exécutent un fichier que vous pouvez modifier sont l'un des chemins d'élévation les plus propres sous Linux. Vérifiez /etc/crontab, le répertoire /etc/cron.d/ et /etc/cron.daily/ pour les tâches, puis examinez les permissions du script que chaque tâche appelle.

Si une tâche cron root lance /opt/scripts/backup.sh et que ce fichier, ou le répertoire qui le contient, est modifiable par votre utilisateur, vous possédez la prochaine exécution. Ajoutez une charge utile et attendez :

echo 'cp /bin/bash /tmp/rootbash && chmod +s /tmp/rootbash' >> /opt/scripts/backup.sh
# after the job runs on schedule:
/tmp/rootbash -p
# id -> uid=0(root)

Un joker dans une commande tar ou chown lancée par cron ouvre une attaque connexe appelée injection de joker, où des noms de fichiers fabriqués sont interprétés comme des drapeaux de ligne de commande. Le signal à guetter est toute automatisation appartenant à root qui touche un emplacement qu'un utilisateur non root peut modifier. Ce décalage est toute la vulnérabilité.

Abus du PATH et des fichiers modifiables

Quand un script appartenant à root appelle un binaire par son nom seul, tar au lieu de /bin/tar, le shell cherche dans les répertoires de $PATH dans l'ordre et lance la première correspondance. Si vous pouvez écrire dans un répertoire qui apparaît plus tôt dans cet ordre de recherche, ou influencer $PATH avant l'exécution du script, votre tar malveillant s'exécute avec les privilèges du script. Déposez un script de deux lignes portant le nom du binaire appelé dans un répertoire modifiable et plus prioritaire, et vous héritez de root.

Deux vérifications de permissions de fichiers appartiennent à la même catégorie. D'abord, un /etc/passwd modifiable, c'est fini : ajoutez une ligne avec un hash de mot de passe connu et un UID de 0, puis faites su vers ce compte. Ensuite, un /etc/shadow modifiable, ou lisible avec un hash root cassable, alimente directement le cassage de mots de passe hors ligne. Lancez toujours ls -l /etc/passwd /etc/shadow tôt, car une seule permission laxiste ici termine l'engagement.

Exploits du noyau

Quand les chemins basés sur la configuration ne donnent rien, la version du noyau elle-même devient la cible. C'est un dernier recours, pas un premier réflexe, car les exploits noyau peuvent faire paniquer la machine et mettre la cible hors ligne, ce qui est rarement acceptable sur un engagement réel sans accord explicite.

Les deux noms à connaître : PwnKit (CVE-2021-4034) a exploité le composant pkexec de Polkit et a donné root à tout utilisateur local sur les installations par défaut d'Ubuntu, Debian, Fedora et CentOS, après être resté non découvert pendant plus de douze ans. Dirty Pipe (CVE-2022-0847) a permis à un utilisateur non privilégié d'écraser des données dans des fichiers en lecture seule sur les noyaux à partir de 5.8, y compris /etc/passwd, rendant root trivial.

Recoupez la version du noyau issue de uname -r avec les CVE connues avant de sortir un exploit, et confirmez que la cible est un lab ou un engagement où l'instabilité est autorisée. Une machine de production plantée est un problème bien plus grave qu'un drapeau root manqué.

Aide-mémoire d'élévation de privilèges Linux

Gardez cet ordre d'énumération à côté de votre terminal. Il va des vérifications les plus susceptibles de payer vite à celles que vous sortez quand les chemins faciles sont taris.

Comment s'en défendre

Comment prévenir l'élévation de privilèges Linux ? Supprimez les mauvaises configurations précises dont dépendent les attaquants. Aucun contrôle unique ne l'arrête entièrement, mais chaque chemin ci-dessus se ferme avec un correctif concret et peu coûteux.

• Retirez les bits SUID inutiles. Auditez avec find / -perm -4000 et retirez le bit de tout ce qui n'en a pas réellement besoin. Rien de maison ne devrait le porter sans relecture.
• N'accordez jamais de sudo NOPASSWD aux interpréteurs. Une règle sudo pour vim, awk, python ou find est une porte ouverte vers un shell root. Restreignez les règles sudo à des actions précises et non scriptables.
• Passez en revue les capabilities des fichiers. Lancez getcap -r / pendant le durcissement et traitez cap_setuid sur tout binaire polyvalent comme l'équivalent d'un bit SUID root.
• Verrouillez les scripts cron. Les tâches planifiées appartenant à root doivent appeler des fichiers appartenant à root dans des répertoires appartenant à root, sans accès en écriture pour quiconque d'autre.
• Appliquez les correctifs à un rythme réel. PwnKit et Dirty Pipe ont tous deux été corrigés par une mise à jour. La plupart des élévations noyau réussies frappent des systèmes en retard de plusieurs mois.

Lors des tests sur de vraies machines, le moyen le plus rapide de trouver ces failles avant un attaquant est de lancer la même énumération qu'un attaquant, LinPEAS plus une revue manuelle des sudoers et des capabilities, de façon planifiée plutôt qu'une seule fois au déploiement.

Considérations légales et éthiques

Chaque commande de ce guide est ce qu'un vrai attaquant lance pour transformer un point d'appui en compromission totale. La seule chose qui sépare un testeur d'intrusion d'un criminel tapant la même syntaxe est l'autorisation, convenue par écrit avant le début de l'engagement.

Entraînez-vous légalement dans trois cadres : les programmes de bug bounty dans leur périmètre publié, les engagements rémunérés sous une lettre de mission signée, et les plateformes de labs cloisonnées conçues pour être cassées. Tout ce qui précède est écrit pour ces trois-là et rien d'autre.