Maker is dead
Contexte
Un maker est retrouvé mort dans un incendie, les pompiers déclarent que la cause de l'incendie provient d'une imprimante 3D. Dans l'incendie, ils récupèrent une clef usb et un raspberry pi à analyser.
Partie I
Lord of War 1/4
Piste de recherche : flag.txt
Pour commencer, nous avons deux images disques :
Raw1.dd qui correspond à la clé USB retrouvé
Raw2.dd qui correspond au raspberry
Les 4 premières étapes du challenge consiste à récupérer des informations dans le Raw1.dd
Je commence par lister le contenu de cette image :
Je découvre 3 partitions, dont une plus importante que les autres, la numéro "002" qui contient un système de fichier NTFS.
Je décide de regarder ce quelle contient :
Un fichier "Flag.txt" intéressant... ça semble être ce que l'on cherche vu notre piste de recherche ! J'extrait le fichier :
J'ai mon premier flag ! ECW{59b931696910632cd89986ccbf626e388055477e} + 50 points
Lord of War 2/4
Piste de recherche : WALLET
Cette fois ci, on recherche quelque chose en rapport avec "Wallet" :
Portefeuille
Cryptomonnaie
Bitcoin, Ethereum ?
Je commence par chercher le mot clé dans l'image disque, mais sans succès :
Je décide donc d'approndir ma recherche dans les autres fichiers trouvé précemment !
J'ai à ma disposition :
2 fichiers PDF
2 Vidéos
Un jeu d'échec
Après quelques recherches dans le fichier PDF et les vidéos, aucune information semble pertinente pour cette piste "Wallet", je décide d'éplucher le jeu d'échec.
Le fichier PgnChessBook/READ_ME_FIRST.txt nous apprend qu'il est possible à partir du programme PgnChessBook/Install_PgnChessBook.exe d'importer une partie d'échec si elle est au format .pgn, ça tombe bien nous avons le fichier PgnChessBook/my_best_game.pgn.
J'éxécute le programme et j'importe le fichier :
Après quelques tests de simulation de la partie, on se rend vite compte qu'elle n'a aucun sens car les deux joueurs placent leurs pions n'importe comment.
Les données contenue dans le fichier my_best_game.pgn semblent d'autant plus étrange :
Je décide d'effectuer quelques recherches sur ce format.
Je tombe sur le dépot github d'un certain "jes" https://github.com/jes/chess-steg qui a développé un outil pour encoder/décoder du texte au format pgn.
Il met en plus à disposition un outil en ligne : https://incoherency.co.uk/chess-steg/
Et cette fois ci, la piste de recherche prend tout son sens :
On découvre une conversation entre "Drewski" et "Yuri".
Drewski semble vouloir acheter quelques choses à Yuri à travers des cryptomonnaies, Drewski procède à un paiement, et Yuri lui envoie un fichier "stl". Mais quelque chose se passe mal... car Yuri veut dans ses derniers messages, tuer Drewski. Drewski serait-il le maker mort dans l'incendie ?
En attendant, j'ai mon 2ème flag : ECW{6d064b364f2a315c32fd25184256c1278b12ee73} + 50 points
Lord of War 3/4
Piste de recherche : 2eme flag.txt
Pour cette 3ème étape, nous recherchons un deuxième fichier flag.txt sur l'image disque de la clé usb.
Ce fichier est peut-être caché dans les 2 fichiers pdf restant, où dans les 2 vidéos.
Je remarque un détail important concernant les deux vidéos, elles font la même durée, mais la vidéo VOST à une taille pratiquement deux fois plus grandes que l'autre.
On pourrait penser que les sous-titres sont la cause de cette différence de taille... je décide de les analyser !
La vidéo est l'épisode 1 de la saison 1 de la série Mister Robot.
Un détail m'interpelle, certaines lettres dans les sous titres sont écrites en italiques :
J'extrait les sous-titres de la vidéo avec l'outil ffmpeg :
On retrouve les caractères en italiques encadré par les balises <i></i>. En les récupérant un à un, on obtient idontignoreyouboby.
Autre détail, je remarque dans les sous-titres la chaîne scC<=:7b:?rCJAE$Ac4b mais elle semble être chiffré.
L'un des PDF (Wiki.pdf) disponible sur la clé usb, on nous donne des informations sur le ROT13, une technique de chiffrement par décalage :
Vu l'alphabet utilisé pour cette chaîne chiffré, le ROT13 n'est pas adapté. En revanche le ROT47 oui, car il prend en charge les caractères spéciaux, j'obtiens une clé : D4rklif3inCryptSp4c3
Maintenant, j'ai deux clés potentiels, mais je ne sais pas quoi en faire !
Après quelques recherches par mots clés sur google, je trouve mon bonheur, un article de Korben qui semble intéressant :
Cacher un conteneur TrueCrypt dans une vidéo
Que dit l'article :
Martin Fiedler, un allemand portant le pseudo KeyJ a mis en ligne sur son blog, une méthode permettant d’intégrer dans une vidéo MP4, un conteneur TrueCrypt... Avant de commencer, il faut trouver un MP4 ou un MOV qui soit crédible pour le transport. C’est à dire un film qui soit suffisamment bien encodé et de bonne qualité, pour qu’une augmentation de sa taille n’éveille pas les soupçons. Une série de 500 Mo que vous ferez grimper à 700 Mo pourra faire l’affaire si la qualité est au rendez-vous.
Comment cela fonctionne ?
Et si nous avions un container chiffré dans notre vidéo ? Cela expliquerai sa taille importante et l'existance des clés pour le déchiffrer !
3ème mission réussie ! le flag est à nous : ECW{40474cc4ffb7874ebab39da9d1a16caaa9f06b07} + 100 points
Lord of War 4/4
Pour ce dernier challenge, il n'y a pas de piste de recherche.
Le container veracrypt contenait 3 autres fichiers :
Un fichier pdf
Un fichier gcode
Un fichier kdbx
Le fichier Brandalism.pdf n'est pas intéressant car il est identique à celui mis à disposition par l'entreprise Brandalism sur internet (sha256sum identique).
Le fichier Liberator.gcode semble intéressant, car le "gcode" est un langage pour donner des instructions à une imprimante 3D. Mais ce fichier ne cache aucun secret, à part le logo des organisateurs du CTF.
Le dernier fichier est un keepass, j'essaye de l'ouvrir avec la clé récupéré précédemment idontignoreyouboby :
Et ça marche, le flag de cette dernière étape de la première partie était caché ici !
ECW{9dc2896d55b56eb19f59d544383f832644381817} + 100 points
Partie II
Cette deuxième partie est constituée de 3 étapes et l'analyse se concentre sur l'image disque du rapsberry, c'est à dire le fichier Raw2.dd
Burn After Reading 1/3
On nous donne les informations suivantes :
Suite de l'enquête sur le maker décédé dans des conditions suspicieuses...
Une piste de recherche : Point d'entrée
Ici, on doit chercher une trace, qui montrerait le point d'entrée de l'attaquant. Et pour trouver une trace, on vise automatiquement les logs.
Malheuresement, cette image disque du raspberry est chiffré avec Luks ! mais heureusement, le maker a enregistré la clé de déchiffrement dans le fichier keepass :
Il suffit de monter la partition chiffrée avec la clé "3DPiting" :
On a désormais accès au raspberry.
Comme dit ci-dessus, nous recherchons une "trace", quoi de mieux que les logs pour trouver cela ?
Nous savons que le maker est mort dans un incendie, suite à l'attaque d'un pirate. Nous devons retrouver le point d'entrée du pirate... le fichier auth.log semble être l'un des plus pertinent pour lister les tentatives d'authentification.
Je découvre des traces qui semblent malveillante vers 13:50:59 :
L'utilisateur de "pihole", un outil pour bloquer les publicités, à supprimer et ajouter des noms de domaines aux listes de blocage de pihole.
Un nom de domaine est particulier : http://RUNXe2VkOTM3NWYzMGJkMjIwNzdjZmRkNDk3YWU3YzJhZWYxYmI0YjgzMmZ9Cg==
Il s'agit d'une chaine encodé en base64, et si on l'a décode :
Nous avons notre flag : ECW{ed9375f30bd22077cfdd497ae7c2aef1bb4b832f} + 50 points
Burn After Reading 2/3
Piste de recherche : Fichiers Ciblés
Rappelons nous, Yuri, le pirate avait envoyé un fichier "STL", ce fichier est utilisé par les imprimantes 3D. Je décide d'analyser les fichiers que l'imprimante du maker à utilisé.
La solution "octoprint" est installé sur le raspberry, cette solution permet de contrôler les opérations d'une imprimante 3D.
Les fichiers imprimés par l'imprimante sont stockés dans le répertoire uploads/
On découvre 6 fichiers, ouvrons les tous !
CE3PRO_Table_Hanger.gcode
CE3PRO_corona.gcode
CE3PRO_MIG-29_kit.gcode
CE3PRO_Naomi__Wu.gcode
CE3PRO_unbelievable.gcode
Cool, on a notre flag ! ECW{f79d8842c644881ddf017e0928e87710c0a15d84} + 50 points
Burn After Reading 3/3
Piste de recherche : Le virus
Pour cette dernière et ultime étape, nous devons retrouver le virus qui a tué le maker (non ce n'est pas le corona virus)
On imagine qu'il y a une action sur l'imprimante pour que celle-ci prennent feu, et tue Drewski...
Le meilleur moyen de retrouver ce "virus", est de tracer une timeline des événement, le dernier jour ou le raspberry a fonctionné.
Actuellement, le seul élement malveillant que nous avons, est le nom de domaine louche, ajouté par le pirate à travers pihole.
L'ensemble de l'attaque est maintenant tracée, un élément est particulièrement étrange... il s'agit du script basic-install.sh.
C'est le premier élément louche à être présent sur le raspberry, d'une part par son horaire de création sur le serveur et d'autre part par son contenu.
Voici un échantillon de ce qu'il contient :
Le script bash semble avoir été obfusqué avec Bashfuscator, malheuresement pour nous, il n'existe pas de désobfuscateur…
Après avoir sandboxer ce petit script, qui peut-être contient un virus, je l'éxécute pour voir ce qu'il me donne. Quelques secondes d'attente, et le code source d'une page web s'affiche, la page youtube d'un clip de Kenji Girac...
Cela ne nous avance pas beaucoup...
Analysons la structure du fichier :
Il contient énormément d'expression étrange comme
${@//\{twl}Au début du fichier, nous avons une redirection (<<<) :
${*^^} "${@}"ba"${@%4GJp}"s'h' ${*%%x\{&|q\]l} "${@/\(mL\`U./>l\"rs}" <<< "$( "${@//F\[sym/8%wS;k43}"
Ce fameux "<<<" permet en bash, d'afficher ou d'éxécuter une commande en input.
Que ce passe t'il si je remplace ${*^^} "${@}"ba"${@%4GJp}"s'h' ${*%%x\{&|q\]l} "${@/\(mL\`U./>l\"rs}" par un simple cat pour afficher la commande lancée...
La commande curl qui récupère la page youtube du clip de Kenji s'affiche, cool !
Le fichier cache peut être une aute occurence de cette fameuse redirection "<<<"
Je trouve une deuxième redirection identique ! Le fichier utilise un OU pour lancer deux commandes :
bash <<< printf $(...) || bash <<< printf $(...)
Je n'ai plus qu’à récupérer la deuxième commande... Même opération que toute à l'heure, j'ajoute cat devant le deuxième "<<<" :
Nous avons notre dernier flag ! ECW{7aaceb8d3e60402d94079707d2430c7394d916eb} + 100 points
Quel était l'objectif de ce virus ?
Trouver tous les fichiers gcode présent sur le raspberry
Pour chaque fichier trouvé :
Il injecte une commande invalide à la fin du fichier
Un grand nombre de commandes invalides a peut-être fait bruler l'imprimante !
Mis à jour
Ce contenu vous a-t-il été utile ?