Privileged Groups
L'appartenance à certains groupes système peut accorder des privilèges importants, parfois équivalents à l'accès root, si elle est mal configurée. Voici des groupes à connaître et des techniques courantes d'escalade associées.
🐳 LXC / LXD
LXD est le gestionnaire de conteneurs d'Ubuntu (similaire à Docker). Lors de l'installation, les utilisateurs autorisés sont souvent ajoutés au groupe lxd. La membership à ce groupe peut être utilisée pour escalader des privilèges en créant un conteneur privilégié et en montant le système de fichiers hôte.
Processus général d'exploitation (pattern)
Vérifier l'appartenance au groupe :
idPréparer une image (ex: Alpine) et l'importer dans LXD :
unzip alpine.zip
lxc image import alpine.tar.gz alpine.tar.gz.root --alias alpineInitialiser LXD si nécessaire :
lxd initCréer un conteneur privileged (sans mapping d'UID) :
lxc init alpine r00t -c security.privileged=trueAjouter un device pour monter le système de fichiers hôte dans le conteneur :
lxc config device add r00t mydev disk source=/ path=/mnt/root recursive=trueDémarrer le conteneur et obtenir un shell :
lxc start r00t
lxc exec r00t /bin/shDans ce contexte, le root du conteneur correspond au root de l'hôte pour les chemins montés, permettant de lire ou modifier /etc/shadow, récupérer des clés SSH, ou ajouter un compte privilégié.
🐋 Docker
Ajouter un utilisateur au groupe docker équivaut pratiquement à donner un accès root au système : les membres peuvent lancer des conteneurs avec des volumes montés depuis l'hôte.
Exemple d'abus : monter /root dans un conteneur et y accéder :
Une fois dans le conteneur, il est possible de lire les clés SSH, modifier des fichiers sensibles ou créer des accès persistants.
💽 Groupe disk
diskLes utilisateurs du groupe disk ont accès direct aux périphériques sous /dev (ex: /dev/sda1). Cela permet d'utiliser des outils de bas niveau (debugfs, fdisk, mount -o loop) pour accéder au contenu des partitions et extraire des fichiers (ssh keys, /etc/shadow, etc.).
📄 Groupe adm
admLes membres du groupe adm peuvent lire la plupart des logs système sous /var/log. Cela ne donne pas directement les privilèges root, mais peut fournir des informations sensibles :
mots de passe en clair accidentels,
tâches cron,
commandes exécutées par d'autres utilisateurs.
Vérifier l'appartenance au groupe :
🛠️ Recommandations pour l'audit
Lister les groupes et leurs membres dès l'accès initial :
getent group,id,groups username.Prioriser les comptes membres des groupes
lxd,docker,disk,admet d'autres groupes sensibles sur la machine.Tester les techniques d'escalade dans un environnement isolé avant toute action sur la cible.
Évaluer les risques liés à chaque groupe : par exemple,
lxdetdockerpermettent facilement le montage de volumes hôte depuis des conteneurs.
🛡️ Mesures d'atténuation pour les administrateurs
Restreindre l'appartenance aux groupes sensibles : n'ajouter que les utilisateurs qui en ont strictement besoin.
Surveiller et alerter les ajouts aux groupes à privilèges (logs d'audit, alertes SIEM).
Appliquer le principe du moindre privilège et revoir périodiquement les memberships de groupe.
Durcir les outils d'orchestration de conteneurs (désactiver les conteneurs privilégiés, utiliser des profils AppArmor/SELinux, limiter l'accès aux sockets de lxd/docker).
Isoler les services sensibles sur des hôtes dédiés si possible.
📚 Ressources utiles
SSH to 10.129.40.22 (ACADEMY-LPE-NIX02) with user "secaudit" and password "Academy_LLPE!"
Use the privileged group rights of the secaudit user to locate a flag.
Dans un premier temps, nous nous connectons à notre cible en ssh :
Une fois la connexion effective, nous observons les groupes auxquels on appartient :
Nous observons que l'utilisateur secaudit fait partie du groupe adm, groupe connu pour avoir accès à certains fichier du répertoire /var/log.
Nouc nous rendons donc dans le répertoire /var/log afin d'utiliser la commande grap pour trouver le flag :
Nous pouvons donc relever le flag présent dans les logs de la machine attaquante :
Last updated