Élévation de privilèges sous Linux : principes — Hacking éthique : méthodologie de test d'intrusion

Obtenir un premier accès sur une machine ne signifie presque jamais tout obtenir d'un coup. Le plus souvent, l'accès initial correspond à un compte aux droits limités. L'élévation de privilèges consiste à passer de ce compte restreint à un compte disposant de davantage de pouvoir sur le système, typiquement l'administrateur. Cette leçon en explique les grands principes sous Linux, dans la continuité du cours sur les systèmes que vous avez déjà suivi.

Rappel. Les principes de cette leçon s'appliquent et se vérifient uniquement sur les machines volontairement vulnérables de votre labo isolé, ou sur une plateforme d'entraînement légale. Aucune commande d'exploitation prête à l'emploi n'est fournie : l'objectif est de comprendre les familles de causes, utiles autant pour auditer que pour défendre un système.

Rappel : comptes, groupes et droits sous Linux

Vous avez vu, dans le cours sur les systèmes, que chaque fichier et chaque processus sous Linux appartient à un utilisateur et à un groupe, avec des droits de lecture, d'écriture et d'exécution. Le compte root dispose de tous les droits sur le système. Entre un compte standard et root, un mécanisme central permet d'effectuer ponctuellement certaines actions avec des privilèges élevés : la commande sudo, configurée pour autoriser certains utilisateurs à exécuter certaines commandes avec les droits d'un autre compte, le plus souvent root.

L'élévation de privilèges exploite presque toujours un écart entre ce qui devrait être permis et ce qui l'est réellement, à cause d'une configuration trop permissive, d'un logiciel vulnérable, ou d'une mauvaise habitude de gestion du système.

Les grandes familles de causes

Famille	Principe
Permissions `sudo` trop larges	Un utilisateur standard est autorisé à exécuter, avec les droits de `root`, une commande dont le fonctionnement permet en réalité d'obtenir bien plus que prévu (par exemple un éditeur de texte qui permet d'ouvrir n'importe quel fichier, ou un interpréteur qui exécute des instructions arbitraires).
Fichiers mal protégés appartenant à `root`	Un script exécuté automatiquement avec les privilèges `root` (par une tâche planifiée, par exemple) est modifiable par un utilisateur standard : celui-ci peut alors en changer le contenu pour qu'il exécute autre chose lors de sa prochaine exécution automatique.
Bit de privilège spécial mal utilisé	Un programme configuré pour s'exécuter avec les droits de son propriétaire (souvent `root`), même lorsqu'il est lancé par un autre utilisateur, peut être détourné si ce programme permet, par sa conception, d'effectuer des actions plus larges que prévu.
Logiciel ou noyau vulnérable	Une faille connue dans le système d'exploitation lui-même ou dans un logiciel installé permet de passer d'un compte standard aux privilèges élevés, de façon comparable aux vulnérabilités vues au chapitre 3.
Informations sensibles accessibles	Un mot de passe, une clé ou un jeton laissé en clair dans un fichier de configuration, un historique de commandes ou une sauvegarde accessible à tout utilisateur.

La démarche d'un testeur face à une machine déjà accédée

Une fois un premier accès limité obtenu (toujours en labo autorisé), la démarche ressemble à une nouvelle phase de reconnaissance, mais depuis l'intérieur de la machine plutôt que depuis le réseau :

Identifier le contexte : quel compte, quels groupes, quelles permissions sudo explicitement accordées ;
Inventorier les logiciels installés et leurs versions, pour comparer aux bases de vulnérabilités connues (chapitre 3) ;
Repérer les fichiers accessibles en écriture qui seraient exécutés avec des privilèges plus élevés ;
Chercher des informations sensibles laissées par erreur (fichiers de configuration, scripts, sauvegardes) ;
Documenter chaque piste, exactement comme pour l'exploitation initiale, avec hypothèse, vérification, preuve.

Des outils d'audit existent pour automatiser une partie de cet inventaire (ils listent les permissions inhabituelles, les fichiers mal protégés), mais ils ne remplacent pas la compréhension : un outil peut signaler une configuration comme suspecte sans que celle-ci soit réellement exploitable dans le contexte précis de la machine, et inversement.

Exemple générique, sans commande d'exploitation

Décrivons un scénario de labo de façon purement narrative, pour illustrer le raisonnement sans fournir de recette : sur une machine d'entraînement, un utilisateur standard découvre qu'il est autorisé, via sudo, à exécuter sans mot de passe un programme de visualisation de fichiers couramment utilisé pour consulter des journaux. Il se trouve que ce type de programme propose généralement une fonctionnalité permettant d'exécuter une commande externe depuis son interface. Si cette fonctionnalité n'a pas été désactivée dans la configuration sudo, l'utilisateur peut, depuis cette commande externe, obtenir un interpréteur de commandes avec les privilèges de root. La cause profonde n'est donc pas « ce programme est dangereux » en soi, mais l'autorisation sudo accordée sans tenir compte des fonctionnalités annexes du programme autorisé.

Ce type de raisonnement — comprendre ce qu'un programme autorisé peut faire au-delà de son usage apparent — est la compétence réellement transférable, bien plus qu'une liste de programmes à mémoriser, qui deviendrait vite obsolète ou incomplète.

Les défenses correspondantes

Accorder les permissions sudo au cas par cas, en vérifiant systématiquement si la commande autorisée permet, par une fonctionnalité annexe, d'obtenir davantage que prévu ;
Vérifier régulièrement les permissions de fichiers, en particulier ceux exécutés automatiquement avec des privilèges élevés ;
Maintenir le système et les logiciels à jour, pour fermer les failles connues du noyau et des programmes installés ;
Éviter de stocker des informations sensibles en clair dans des fichiers accessibles, des scripts ou l'historique de commandes ;
Utiliser des outils d'audit de configuration régulièrement, pour détecter les dérives avant qu'un attaquant ne les trouve ;
Journaliser l'usage de sudo et surveiller les usages inhabituels.

Le lien avec les chapitres précédents

Cette leçon prolonge directement des notions déjà vues : le principe du moindre privilège (premier cours du parcours, et chapitre précédent sur les identifiants), la défense en profondeur (chapitre sur le pivoting), et l'importance des mises à jour (deuxième cours du parcours). L'élévation de privilèges illustre concrètement pourquoi ces principes, qui peuvent sembler abstraits, ont un impact direct et mesurable sur la gravité d'un incident.

À vous de jouer : analyser une configuration fictive

Voici une description fictive de configuration, sans commande d'exploitation : un utilisateur standard sur une machine est autorisé par sudo à exécuter, sans mot de passe, un script de sauvegarde situé dans son propre répertoire personnel, qu'il peut lui-même modifier. Dans votre carnet, répondez : (1) où se situe exactement le problème ? (2) quelle est la cause profonde, parmi les familles vues dans la leçon ? (3) quelles corrections concrètes recommanderiez-vous ?

Voir une solution

(1) Le problème est que le script autorisé par sudo se trouve dans un emplacement que l'utilisateur contrôle entièrement : il peut donc en modifier le contenu avant de l'exécuter avec des privilèges élevés. (2) Il s'agit d'un fichier mal protégé exécuté avec des privilèges élevés, combiné à une permission sudo trop large qui ne tient pas compte du fait que l'emplacement du script est modifiable par l'utilisateur. (3) Corrections : déplacer le script vers un emplacement non modifiable par l'utilisateur standard (appartenant à root avec des permissions restrictives), ou revoir entièrement la nécessité de cette autorisation sudo, et auditer les autres autorisations similaires sur le système.

Astuce. Dans votre labo, prenez l'habitude, après avoir obtenu un premier accès sur une machine volontairement vulnérable, de toujours vous poser la question « que suis-je explicitement autorisé à faire avec des privilèges élevés, et que peut réellement faire ce qui m'est autorisé ? » avant de chercher une faille plus complexe ailleurs : c'est souvent la piste la plus rapide et la plus instructive.

À retenir

L'élévation de privilèges exploite un écart entre ce qui devrait être permis et ce qui l'est réellement.
Les grandes causes : permissions sudo trop larges, fichiers exécutés avec privilèges mais modifiables, bits de privilège mal utilisés, logiciels vulnérables, informations sensibles exposées.
La démarche reprend la logique de la reconnaissance, mais depuis l'intérieur de la machine déjà accédée.
Les défenses rejoignent le moindre privilège, la mise à jour régulière et l'audit de configuration.
Comprendre ce qu'un programme autorisé peut faire au-delà de son usage apparent est la compétence clé, plus utile qu'une liste figée de cas particuliers.

La leçon suivante aborde les mêmes principes du point de vue des systèmes Windows, souvent dominants dans les environnements d'entreprise.