🛡️ De l'Intrusion Ă l'Évasion : Compte-rendu d'un Pentest Docker
Aujourd'hui, j'ai plongé dans les entrailles de la sécurité des conteneurs à travers un exercice pratique de Docker Evasion. L'objectif ? Passer d'un simple accès utilisateur sur une application web à un contrôle total de la machine hôte.
Voici le récit technique de cette ascension, étape par étape.
1. La brèche initiale : Mouvement latéral
Tout commence dans un conteneur nommé webapp. Après une phase de reconnaissance réseau classique via Nmap, une cible potentielle est identifiée : privileged-service (11.10.10.38).
Le point d'entrée ? Une erreur humaine classique. En fouillant les fichiers de configuration (.bashrc), j'ai découvert des identifiants SSH laissés en clair par un précédent administrateur.
Leçon n°1 : Ne stockez jamais de secrets dans vos scripts ou historiques de commandes.
2. Le Pivot : L'accès Root
Grâce aux identifiants récupérés, j'ai pu effectuer un pivot (mouvement latéral) pour me connecter en SSH au second conteneur. Une fois à l'intérieur, la commande id confirme le Graal du hacker : je suis désormais root.
Cependant, être root dans un conteneur ne signifie pas être maître de la machine physique... sauf si le conteneur est mal configuré.
3. L'Évasion : Briser les murs de Docker
C'est ici que l'exercice devient critique. Le conteneur privileged-service portait bien son nom : il a été lancé avec le flag --privileged.
Ce paramètre désactive l'isolation du noyau et permet au conteneur de "voir" le matériel de l'hôte. En utilisant fdisk -l, j'ai pu identifier le disque dur principal de la machine physique (/dev/sdd).
La technique du montage direct :
Création d'un point de montage :
mkdir /mnt/host_rootMontage du disque hĂ´te :
mount /dev/sdd /mnt/host_rootAccès total : À cet instant, l'isolation Docker est réduite à néant. Je pouvais lire et modifier n'importe quel fichier sur l'ordinateur physique (WSL), incluant les données personnelles de l'utilisateur.
4. Preuve de Concept (PoC)
Pour valider l'évasion, j'ai créé un fichier texte directement dans le répertoire personnel de l'hôte depuis le conteneur. En quittant l'environnement virtuel, le fichier était bien présent sur ma machine réelle. L'évasion était confirmée.
📝 Ce qu'il faut retenir (Best Practices)
Ce lab est un rappel brutal que la sécurité d'un conteneur dépend entièrement de sa configuration :
Bannissez le flag
--privileged: Utilisez des capacités Linux spécifiques (cap-add) si nécessaire.Utilisez des utilisateurs non-root : Un processus limité n'aurait jamais pu monter le disque dur de l'hôte.
Nettoyage de post-exploitation : Toujours supprimer ses traces (fichiers de validation, historiques) pour ne pas créer de nouvelles failles.
Conclusion : Docker est un outil formidable, mais sans isolation rigoureuse, la "boîte" peut rapidement devenir une porte ouverte sur tout votre réseau.




Commentaires
Enregistrer un commentaire