Lab d’élévation de privilèges Linux : un binaire setuid, une règle sudo, une tâche cron

Chaque élève reçoit sa propre VM Ubuntu avec un second compte à faibles privilèges, intern, dont le nom et le mot de passe sont donnés dans le README. Root a laissé derrière lui trois erreurs ordinaires d’administrateur : un programme auxiliaire qui porte un bit qu’il ne devrait pas avoir, une règle sudo jamais resserrée, et un script que la tâche cron de root exécute et que n’importe qui peut modifier. La tâche consiste à utiliser l’une des trois pour devenir root et rédiger ce qu’ils ont utilisé.

La VM appartient à l’élève seul, sans accès à la machine d’aucun autre élève ni à Internet, à part l’archive de paquets d’Ubuntu, PyPI, npm et GitHub, si bien que la seule machine à attaquer est celle que le lab lui a donnée. La règle est dite en tête du lab, et elle est autant celle de la loi que la nôtre : attaquez votre VM uniquement, jamais une machine qui ne vous appartient pas, au titre du Computer Misuse Act 1990.

Ce que les élèves apprennent

Comment un petit raccourci d’administration ordinaire devient un chemin vers root : un programme auquel on a donné plus de privilèges que son travail n’en exige, une règle sudo écrite pour une seule commande et jamais revue, et une tâche planifiée qui fait confiance à un fichier que n’importe qui peut changer. Trouver chacune suppose de regarder une machine comme devrait le faire un administrateur avant de confier un compte à quelqu’un d’autre, et non de lancer un scanner. Convient à un premier cours de sécurité Linux, de durcissement système ou d’introduction aux tests d’intrusion.

Les failles

Un programme auxiliaire, copie d’un outil système ordinaire, avec le bit setuid positionné pour qu’il s’exécute toujours en root. Une ligne dans la configuration de sudo laissant le compte à faibles privilèges exécuter un programme ordinaire en root sans mot de passe. Un script que la tâche cron de root exécute chaque minute, laissé modifiable par n’importe qui sur la machine. Le README que le lab laisse dans le dossier personnel nomme le second compte et ne révèle aucune des trois.

Le lancer dans votre navigateur

Les labs VM se proposent comme une tâche de lab dans un module, et l’exemple se trouve sur la page du lab. La machine est petite : un processeur, 1 Go de mémoire et 6 Go de disque.

  1. Ajouter le lab. Dans un module que vous enseignez, ajoutez une tâche et choisissez la carte « Lab VM Ubuntu ». La page affiche une courte description de la machine au lieu d’un fichier compose.
  2. Partir de l’exemple. La page propose des labs prêts à l’emploi pour commencer. Choisissez Élévation de privilèges sous Linux. Utiliser un exemple remplace le texte, et « Annuler » rétablit le vôtre.
  3. Publier et démarrer votre propre copie. Publiez, puis « Démarrer ». Le script d’installation du lab crée le second compte, écrit le drapeau et sème les trois failles à partir de l’archive d’Ubuntu au premier démarrage de la VM, en une dizaine de secondes.
  4. Ouvrir le terminal. Ouvrez son terminal et lisez README.md dans le dossier personnel : il indique le nom et le mot de passe du second compte et ne donne aucune réponse.

Une leçon de base sur ce lab

Privilege Escalation Basics est une petite leçon qui se fait dans ce lab, qui est une VM Ubuntu : chaque étape est expliquée et accompagnée d’un bouton Exécuter qui tape sa commande dans le terminal de la machine et montre ce qu’elle a affiché. L’élève découvre le second compte, regarde ce qu’il a et n’a pas le droit d’exécuter, et lit les trois endroits où root a laissé quelque chose, sans s’en servir.

Elle se contente de regarder autour d’elle et laisse à l’élève la tâche propre du lab, devenir root, si bien qu’elle ne donne aucune réponse. Elle est volontairement petite : elle montre à un enseignant ce qu’est une leçon qui se fait dans un lab, et le lab fait le reste. Copiez-la dans un module à vous pour la modifier.

Comment il est rendu et lu

Ce lab n’a volontairement aucun script de notation. Un élève sur la machine a déjà ses propres droits d’administrateur : tout fichier qu’un script pourrait lire comme preuve, l’élève pourrait l’écrire en une ligne sans passer par les failles du lab. Une note facile à fabriquer est pire que pas de note, le travail est donc un compte rendu écrit que vous lisez. Le drapeau est l’objectif de l’élève et un appui pour ce compte rendu, pas une preuve. Corriger les failles ensuite n’est pas demandé ici, et vous pouvez le poser comme travail ultérieur.

  1. Le distribuer. Attribuez le lab comme n’importe quelle tâche, avec une échéance si vous le souhaitez. Chaque élève reçoit sa propre VM, conservée d’une session à l’autre. Dans les réglages de remise de la tâche, choisissez Documents pour que l’élève puisse rendre un compte rendu écrit.
  2. Lire le compte rendu. L’élève rend un court compte rendu : la faille utilisée, les commandes qui ont fonctionné et ce que disait le drapeau. Rien sur la machine ne le note, c’est donc vous qui le lisez.
  3. Noter. Notez-le comme n’importe quelle remise et renvoyez le travail avec un motif s’il demande un complément.

La définition sur GitHub

Le fichier est la définition complète du lab, le même texte que celui que la plateforme exécute : taille, script d’installation et README. Copiez-le et changez quel programme porte le bit setuid, quelle commande la règle sudo autorise, ou ce que fait le script modifiable, pour faire un lab à vous.

Questions fréquentes

Les élèves peuvent-ils s’en servir contre un vrai serveur ?
Non, et le lab le dit avant toute chose. La VM n’a accès à aucune autre machine, et le README comme cette page énoncent la règle : attaquez uniquement votre propre copie, ce que le Computer Misuse Act 1990 pose comme condition pour faire cela du tout.
Un élève peut-il tricher sans devenir root ?
Oui, et le lab ne prétend pas le contraire : un élève sur la machine a ses propres droits d’administrateur et pourrait lire le drapeau en une ligne. C’est pourquoi rien ne le note automatiquement. Vous lisez le compte rendu, avec les mots et les commandes de l’élève.
Les élèves doivent-ils corriger les failles ensuite ?
Non, pas dans ce lab. Les corriger reste un travail séparé, ultérieur, qu’un enseignant peut poser.