It looks like a naughty developer has been deploying a Docker image on a Santa production server a few days before Christmas. He was in a rush and was not able to properly pass all security checks on the built Docker image. Would be a shame if this image could give you an SSH access to the production server… http://46.30.204.47"
Etat des lieux
En allant sur l’IP donnée dans l’énoncé, on trouve une note nous donnait accès au docker en question.
Avec cette note, on sait que l’on cherche un accès SSH donc potentiellement:
- username ;
- password et / ou clé ;
- adresse IP de la machine de prod ;
- port ssh si non standard (22/TCP).
La première chose à faire est donc de récupérer ce docker:
|
|
Avant de commencer dans le vif du challenge, une petite recherche google a permis d’avoir des pistes à creuser:
Même si leur outil a l’air vraiment jolie, on va le faire à l’ancienne: avec du bash et du cervelet.
Différence entre docker save et export
Avant de faire un docker save de notre image, il est important de s’intéresser à la différence entre un docker save et un docker export. Les deux ont plus ou moins la même finalité: sauvegarder un container et le redéployer.
La différence majeure est qu’un docker export ne va pas garder les meta données, ni les layer d’un container. Quant à un docker save, il va tout récupérer et faire un beau tar avec.
Le tool de intrinsec se base sur les layer du container pour permettre à l’utilisateur de chercher à l’intérieur et ainsi récupérer des secrets.
Cet article en parle bien : https://tuhrig.de/difference-between-save-and-export-in-docker/
Sauver le soldat Santa
On peut voir sur l’image suivante, que l’archive tar générée par docker save
contient l’architecture suivante:
- hash.tar: un hash par layer;
- json: l’état du docker au moment du layer;
- layer.tar: l’ensemble des fichiers du layer;
- VERSION: la version du docker.
- hash.json: un “résumé” de tous les layers générés et les commandes associés;
- manifest.json: répertorie tous les hashs des différents layers;
- repositories (format json): contient le hash de la dernière version du docker.
Les données que l’on chercher doivent être dans un des “layer.tar”.
Localiser les fichiers utiles
La première chose à faire est de lister l’ensemble des fichiers dans les différents “layer.tar”, ça sera plus simple pour grepper dedans après:
|
|
Dans le fichier ddde36e2209357c424cca26ac5a0b46c2f864be797c053bed700422177ba7261.json
, le résumé de tous les layers, on peut voir que l’utilisateur supprime le .bash_history
et le .bashrc
:
|
|
Maintenant, il faut localiser un “layer.tar” contenant un .bash_history
:
|
|
Il semblerait que notre archive soit le layer: be3d4ffa7682700bcbc51a8655568428c4979c5464169a286208e9e03f7673a5
Extraction des premières informations
Il semblerait que la logique soit bonne:
|
|
Les fameux fichiers supprimés, mais aussi des archives de backup, ça sent bon. Avec un simple cat
sur ce fichier, on voit qu’il a fait beaucoup de commandes:
|
|
Mais on sait qu’on cherche de quoi se connecter en ssh:
|
|
Dans la liste des informations à trouver, on vient de récupérer:
- username: rudolf-the-reindeer ;
- adresse IP de la machine de prod: 46.30.204.47 ;
- port ssh si non standard (22/TCP): 5700.
Il nous manque donc un mot de passe ou une clé. Normalement, c’est à ce moment qu’on se demande “Mais que contiennent les backups ?”:
Ca tombe bien. Pour info, un unzip -l *
ne fonctionne pas, je ne me suis pas amusé à faire un for
pour le plaisir.
De toute façon, nous sommes face à une archive chiffrée:
Déchiffrement du zip
S’il a créé un zip chiffré, il a dû faire la commande zip
à un moment donné. Regardons dans le .bash_history
:
Une variable d’environnement pour le password, ça nous fait une belle jambe. Il n’y a plus qu’à espérer que cette variable ait été initialisée dans ce même bash:
On a encore eu de la chance. Le mot de passe du zip est donc 25362
. Lors de l’extraction d’un zip, quelque chose de rigolo se passe:
Après, il y a 9 zip, c’est peut être la clé de l’un d’entre eux. Pour celà, bash for the win:
|
|
Il semblerait qu’une archive puisse être déchiffrée:
dev_141219_backup.zip
Bonne nouvelle… Enfin presque:
Il semblerait que l’authentification SSH ait besoin d’une clé ET d’un mot de passe.
El famoso passwordo
Je dois avouer que j’ai passé un peu de temps à chercher ce mot de passe dans les autres layers, bruteforce sans succès les autres zip pour voir si la clé changeait, etc… Mais au final, je me suis rappelé qu’à la création de ce layer, l’utilisateur avait supprimé 2 fichiers:
.bash_history
.bashrc
Que contient le .bashrc
:
|
|
La fameux mot de passe:
HoHoHo2020!NorthPole
Il ne reste qu’à se connecter et collecter ce flag tant attendu:
Flag
SANTA{NeverTrustDockerImages7263}