Élévation de privilèges sous Linux : vecteurs et durcissement pour les défenseurs

L'élévation de privilèges est le moment où un accès limité sur un hôte Linux se transforme en contrôle total. Pour une équipe bleue, c'est l'une des phases les plus lourdes de conséquences d'une intrusion : un attaquant qui atterrit comme compte de service non privilégié puis devient root peut désactiver la journalisation, installer de la persistance et se déplacer latéralement dans tout le parc. Cet article adopte une approche comprendre pour défendre. Nous décrivons le fonctionnement de l'élévation au niveau conceptuel, cartographions les surfaces que les attaquants sondent, puis consacrons l'essentiel du temps à ce qui compte pour les défenseurs : la télémétrie qui révèle les tentatives d'élévation et le durcissement qui supprime l'opportunité à la racine.

Ce que signifie réellement l'élévation de privilèges

Sous Linux, l'autorité s'exprime par l'identité utilisateur et groupe, l'UID/GID effectif avec lequel un processus s'exécute et un ensemble de capacités noyau à grain fin. Un processus hérite généralement des privilèges du compte qui l'a lancé. L'élévation de privilèges est toute technique permettant à du code de s'exécuter avec plus d'autorité qu'il ne lui en a été accordée. Il existe deux grandes familles. L'élévation verticale passe d'un utilisateur peu privilégié à un utilisateur supérieur, généralement root. L'élévation horizontale se déplace latéralement vers un autre utilisateur du même niveau de privilège pour atteindre des données ou des sessions. Les deux comptent, mais l'élévation verticale vers root est celle que les défenseurs redoutent le plus, car root peut réécrire les règles du système, y compris les contrôles censés le détecter.

Le modèle mental clé pour un défenseur est que l'élévation est rarement un unique exploit magique. C'est presque toujours l'abus d'un mécanisme légitime configuré de façon trop laxiste : un binaire auxiliaire doté de trop de pouvoir, une tâche planifiée s'exécutant en tant qu'utilisateur privilégié, un compte de service capable de modifier sa propre configuration. Qui comprend le mécanisme peut à la fois détecter son abus et supprimer la configuration laxiste.

Comment l'élévation fonctionne à haut niveau

Un attaquant qui a atterri sur un hôte effectue une reconnaissance locale pour énumérer ce que l'identité actuelle peut atteindre. Il cherche des fichiers qu'il peut écrire et que des processus privilégiés liront ou exécuteront ensuite, des programmes s'exécutant avec une autorité élevée mais acceptant des entrées influencées par l'attaquant, et des logiciels obsolètes présentant des failles connues. L'élévation elle-même est le moment où une entrée contrôlée par l'attaquant franchit une frontière de confiance vers un contexte privilégié. Conceptuellement, chaque vecteur est une variation d'un même thème : une entrée peu privilégiée qui atteint un chemin d'exécution hautement privilégié. Votre tâche défensive consiste à trouver ces ponts et à les supprimer ou à les surveiller de près.

Vecteurs courants et surface d'attaque

Un sudo mal configuré est le constat le plus fréquent dans les environnements réels. Lorsqu'un compte est autorisé à exécuter des commandes spécifiques en tant que root, et que l'une de ces commandes peut lancer un shell, lire des fichiers arbitraires ou écrire dans des chemins sensibles, la frontière s'effondre. Les jokers dans les règles sudoers et les entrées NOPASSWD élargissent encore la surface.

Les binaires SUID et SGID s'exécutent avec les privilèges du propriétaire du fichier, quel que soit celui qui les lance. Un programme SUID-root légitime qui peut être amené à exécuter une autre commande, ou à lire et écrire des fichiers en tant que root, devient un levier. L'inquiétude grandit lorsque des binaires internes ou tiers portent inutilement le bit SUID.

Les capacités Linux excessives sont un cousin plus subtil. Un binaire doté de cap_setuid, cap_dac_override ou cap_sys_admin détient une part du pouvoir de root sans le bit SUID, et elles sont faciles à négliger dans un audit qui ne vérifie que les modes de fichier.

Les tâches planifiées comme les tâches cron, les minuteries systemd et les scripts d'init s'exécutent souvent en tant qu'utilisateurs privilégiés. Si un script qu'elles exécutent, ou un répertoire sur le chemin vers ce script, est modifiable par un utilisateur moindre, celui-ci peut influencer ce que root exécute. Des permissions faibles sur les fichiers et services généralisent cela : une unité de service modifiable par tous, un fichier de configuration lu par un service au démarrage ou un répertoire de bibliothèques sur le chemin de recherche d'un binaire privilégié sont autant de ponts du bas vers le haut.

La manipulation de PATH et de l'environnement exploite les scripts privilégiés qui appellent des programmes auxiliaires par nom plutôt que par chemin absolu ; si un attaquant peut influencer le chemin de recherche, l'auxiliaire se résout vers son propre binaire. Enfin, les vulnérabilités du noyau et des services dans un logiciel non corrigé donnent une élévation directe, et les mauvaises configurations de conteneurs et d'espaces de noms, comme un conteneur s'exécutant en root avec le système de fichiers de l'hôte ou le socket Docker monté, permettent de s'évader vers l'hôte.

Détection : la télémétrie qui révèle l'élévation

La source la plus précieuse est le cadre d'audit Linux, auditd. Les règles qui surveillent execve, les modifications de /etc/sudoers et /etc/sudoers.d/, les écritures sous /etc/cron.* et /etc/systemd/, ainsi que l'usage des appels setuid, setreuid et capset transforment une élévation silencieuse en événements enregistrés. Étiquetez ces règles avec des clés pour que votre SIEM puisse alerter dessus. Une soudaine rafale d'énumération — de nombreux événements execve pour id, sudo -l, find / -perm et des lectures de /etc/passwd en quelques secondes — est un fort signal comportemental avant même l'élévation.

Le noyau émet un enregistrement d'audit lorsque setuid élève le privilège. Corrélez cette transition vers root à une base de référence des services qui le font légitimement ; un processus inattendu qui fait le saut mérite une enquête immédiate. sudo écrit dans le journal d'authentification, alertez donc sur les échecs, sur l'usage du chemin NOPASSWD par des comptes qui ne devraient pas l'avoir, et sur toute commande exécutée en root qui lance ensuite un interpréteur de shell. Côté EDR, cherchez des chaînes parent-enfant suspectes, par exemple un processus de serveur web ou de base de données qui lance bash, sh, python ou nc, et un compte de service non interactif qui obtient soudain un TTY interactif.

La surveillance de l'intégrité des fichiers boucle la boucle. Alertez dès que le bit SUID ou SGID apparaît sur un binaire, dès que les capacités de fichier changent et dès que des fichiers cron, des unités systemd ou des bibliothèques partagées sont modifiés hors d'une fenêtre de changement. Expédiez tout cela de façon centralisée afin qu'un attaquant de niveau root qui efface les journaux locaux ne puisse pas effacer les preuves déjà générées.

Atténuation et durcissement : d'abord le moindre privilège

Chaque décision de durcissement découle du moindre privilège. Auditez sudoers et supprimez les droits généraux : accordez des commandes spécifiques à des utilisateurs spécifiques, évitez NOPASSWD sauf si une automatisation étroitement délimitée l'exige, et n'autorisez jamais des commandes pouvant ouvrir un shell ou lire des fichiers arbitraires à moins que ce ne soit l'intention délibérée. Préférez sudo avec des restrictions d'arguments à l'octroi d'un shell root interactif. Révisez ces règles de façon planifiée, car elles s'accumulent au fil du temps comme des exceptions ponctuelles jamais retirées.

Exécutez les services sous des comptes dédiés et non privilégiés, un par service, afin que la compromission d'une application web ne remette pas à l'attaquant un shell auquel un autre service fait confiance. Utilisez les directives de sandboxing de systemd — NoNewPrivileges=yes, ProtectSystem=strict, PrivateTmp=yes et un CapabilityBoundingSet restrictif — pour réduire ce qu'un service compromis peut faire avant même d'envisager l'élévation.

Durcissement du système de fichiers, du SUID et des capacités

Inventoriez chaque binaire SUID et SGID de votre parc et justifiez chacun. Retirez le bit de tout ce qui n'en a pas besoin, et traitez un binaire SUID inattendu comme un incident. Montez les systèmes de fichiers contenant des données modifiables par l'utilisateur ou temporaires — /tmp, /var/tmp, /dev/shm et les partitions home — avec nosuid, nodev et, quand c'est possible, noexec, afin qu'un fichier SUID déposé ne porte tout simplement pas son privilège. Auditez les capacités de fichier avec un outil qui les liste dans toute l'arborescence, et préférez les capacités au SUID uniquement lorsque vous pouvez les délimiter étroitement.

Verrouillez les permissions de tout ce qu'un processus privilégié consomme : les répertoires cron, les fichiers d'unité systemd, la configuration des services et les répertoires du chemin de recherche de bibliothèques et d'exécutables de tout binaire privilégié ne doivent pas être modifiables par des utilisateurs moindres. Dans les scripts privilégiés, appelez toujours les auxiliaires par chemin absolu et réinitialisez l'environnement, afin que la manipulation de PATH n'ait rien à saisir.

Noyau, correctifs et contrôle d'accès obligatoire

L'application rapide des correctifs supprime les vulnérabilités du noyau et des services qui donnent une élévation directe ; suivez votre exposition face à un flux de vulnérabilités et priorisez tout ce qui présente une faille publique d'élévation locale de privilèges. Au-delà des correctifs, superposez un contrôle d'accès obligatoire. SELinux en mode enforcing ou un profil AppArmor bien réglé confine un processus à ce que son rôle exige, de sorte que même une élévation réussie vers root au sein d'un domaine confiné ne puisse pas réécrire librement le système. Combinez cela avec un durcissement du noyau comme kernel.yama.ptrace_scope, un accès restreint à dmesg et des modules noyau inutilisés désactivés pour supprimer des classes entières de technique.

Pièges courants que les défenseurs doivent éviter

Le premier piège est de traiter le durcissement comme un projet ponctuel. Les règles sudo, les inventaires SUID et les tâches cron dérivent à mesure que les systèmes évoluent ; sans réaudit périodique, la surface repousse en silence. Le deuxième est de ne surveiller que les signatures d'exploit connues en ignorant le comportement — l'élévation par mauvaise configuration ne produit aucune signature d'exploit, seulement une filiation de processus anormale et des transitions de privilège. Le troisième est de ne conserver les journaux qu'en local, qu'un attaquant de niveau root efface ; centralisez la télémétrie pour qu'elle survive à la compromission de l'hôte. Le quatrième est d'oublier les conteneurs : un conteneur qui s'exécute en root, reçoit --privileged ou monte le socket Docker accorde de fait root sur l'hôte, appliquez donc la même discipline de moindre privilège à l'intérieur des images.

Liste de contrôle pratique de durcissement

Utilisez ceci comme revue récurrente. Moindre privilège : auditez sudoers, supprimez les règles générales et NOPASSWD, exécutez chaque service sous son propre compte non privilégié. Système de fichiers : inventoriez et minimisez SUID/SGID, montez les partitions modifiables avec nosuid,nodev,noexec, renforcez les permissions sur les chemins cron, systemd et de configuration. Capacités : auditez les capacités de fichier et retirez les inutiles. Noyau : appliquez les correctifs à un rythme régulier, activez SELinux ou AppArmor en mode enforcing, appliquez des sysctls de durcissement du noyau. Détection : déployez des règles auditd pour setuid, sudoers, cron et capset ; surveillez la filiation des processus dans l'EDR ; activez la surveillance de l'intégrité des fichiers sur les chemins privilégiés ; expédiez tous les journaux vers un stockage central que l'hôte n'atteint pas. Conteneurs : exécutez en non-root, retirez les capacités, ne montez jamais le socket Docker dans des charges non fiables.

Foire aux questions

Est-il sûr de supprimer les binaires SUID ? Certains binaires système ont réellement besoin du bit, comme passwd. L'approche sûre consiste à inventorier chaque fichier SUID, à le rattacher à un besoin justifié, à retirer le bit de tout ce qui est injustifié et à tester d'abord dans un environnement de préproduction. Un binaire SUID inexpliqué a bien plus de chances d'avoir été déposé par un attaquant que d'être légitime.

Si j'exécute tout dans des conteneurs, suis-je à l'abri de l'élévation de privilèges ? Non. Les conteneurs sont une frontière, pas une garantie. Un conteneur s'exécutant en root avec des capacités excessives ou un socket hôte monté est souvent un chemin direct vers root sur l'hôte. Traitez la configuration des conteneurs avec la même rigueur de moindre privilège que vous appliquez aux hôtes, et surveillez aussi l'élévation à l'intérieur des conteneurs.

Conclusion

L'élévation de privilèges sous Linux n'est généralement pas une affaire d'exploits exotiques ; c'est la conséquence prévisible d'une configuration laxiste accumulée — une règle sudo trop large, un bit SUID égaré, un chemin cron modifiable, un noyau non corrigé. C'est une bonne nouvelle pour les défenseurs, car cela signifie que la surface est énumérable et que les correctifs sont concrets. Combinez un moindre privilège discipliné, le durcissement du système de fichiers et des capacités, l'application rapide des correctifs et le contrôle d'accès obligatoire pour supprimer l'opportunité, puis superposez auditd, la surveillance de la filiation des processus par l'EDR et la surveillance centralisée de l'intégrité des fichiers pour attraper le reste. Révisée à un rythme régulier plutôt que traitée comme ponctuelle, cette posture défensive transforme l'élévation d'une inévitabilité silencieuse en un événement bruyant et détectable.