iHack 2013, volet forensique #3 & 4 - Vos yeux saignent et vous devez séparer quelque chose.

J'en ai parlé à un collègue joueur de CTF et il m'a dit qu'il demanderait à la ressource parfaite pour ça. Il m'est revenu avec des exemples de combinaisons de fichiers comme ZIP + ZIP, EXE + RAR ou EXE + ZIP. Tout dépend de la façon dont le fichier fonctionne : est-ce qu'il dépend de ses limites dans l'en-tête et le pied de page? Est-ce qu'il a de l'espace perdu? Bon, c'est intéressant, il faut expérimenter avec ça pour reproduire le comportement, et ça a marché.

Quelques mois plus tard, je devais monter des défis pour l'iHack 2013 et je voulais que les gens découvrent ça eux aussi et apprennent là-dessus. J'ai alors repensé à cette expérience, mais il fallait aussi que je trouve comment inverser tout le processus. Après avoir ragequitté mes tests avec un fichier ZIP exécutable autoextractible protégé par mot de passe/chiffré et un fichier RAR, parce que je n'arrivais pas à bâtir un fichier ZIP qui soit chiffré ET autoextractible (on m'a déjà dit que c'était à cause de la compatibilité MS-DOS..... on s'en fout-tu en 2013!?), je suis passé à autre chose et j'ai finalement opté pour un ZIP protégé par mot de passe et un fichier RAR, et ça a fonctionné à merveille avec un processus de carving assez simple, mentionné ici, basé sur l'identification des en-têtes pour vous indiquer où « couper » le fichier.

Il me fallait du contenu, ce n'est pas un gros défi. Puis j'ai eu un flash à propos d'un défi forensique que j'avais tenté aux qualifications de PHDays 2012 et de son writeup (voir ici, en allemand), qui pouvait se résoudre de 2 façons :

• stegsolve
• jouer avec la structure du fichier GIF, identifier la palette de couleurs et jouer avec

Il fallait absolument que j'inclue quelque chose de semblable... mais pas exactement pareil, parce que si quelqu'un trouvait ce writeup, ce serait trop facile. On ne peut pas cacher grand-chose en ligne sans que ça se trouve avec hexedit... et pas de descripteurs directs que je pourrais remplir et cacher facilement. Le deuxième facteur du défi devait être dans le fichier lui-même. Pourquoi ne pas le corrompre volontairement?

Voici les étapes :

• # file safe
  safe: Zip archive data, at least v2.0 to extract

  
  

• Dans Winzip/7zip, on a un fichier nommé flag5.txt... si facile que ça?

  
  

• Bah non... chiffré et protégé par mot de passe... bien sûr, vous pourriez le bruteforcer... mais c'est poche.

  
  

• Passons-le dans hexedit :

  • 000000D0   01 01 99 07  00 01 00 41  45 01 08 00  50 4B 05 06  00 00 00 00  01 00 01 00  66 00 00 00  76 00 00 00  00 00 52 61  72 21 1A 07  00 CF 90 73  00 00 0D 00  00 00 00 00  .......AE...PK..........f...v.....Rar!.....s........

    
    

  • 00000104   00 00 59 E3  7A 00 80 23  00 48 00 00  00 4A 00 00  00 02 71 98  0A 53 00 00  00 00 1D 33  03 00 01 00  00 00 43 4D  54 09 55 00  CB E4 CF F9  2B 05 98 24  70 C4 64 A6  ..Y.z..#.H...J....q..S.....3......CMT.U.....+..$p.d.

    
    

  • 00000138   40 88 22 C6  41 68 77 66  86 96 AE 1C  3F 8E 3E 1F  EE C9 BD 5F  AE F7 B0 F7  17 19 98 9D  92 2F 36 26  A5 91 D0 E0  81 91 52 86  03 C6 FF AF  27 4B EA AC  52 FE 6C 49  @.".Ahwf....?.>...._........./6&......R.....'K..R.lI

    
    

  • 0000016C   A7 BD CD 4F  10 C4 66 74  20 90 2F 00  E0 0A 00 00  E0 0A 00 00  02 E8 02 7A  21 04 01 AF  42 1D 30 0A  00 20 00 00  00 73 71 75  61 72 65 2E  67 69 66 00  B0 79 AE 3D  ...O..ft ./............z!...B.0.. ...square.gif..y.=

    
    

  • 000001A0   47 49 46 38  37 61 0A 00  00 A0 80 02  00 FF 30 00  FF 30 01 2C  00 00 00 00  80 02 80 02  00 02 FE 84  8F A9 CB ED  0F A3 9C B4  DA 8B B3 DE  BC FB 0F 86  E2 48 96 E6  GIF87a........0..0.,.............................H..

    
    
  
  
  
  

• Mais... ce n'était pas un fichier ZIP!? Hmmm... peut-être un cat file1 file2 > safe?

  
  

• Une recherche Google nous montre que « Rar! » est le début d'un en-tête de fichier RAR et, à partir d'ici, on sait comment gérer le reste.... du carving.

  
  

• Comme on l'a vu, ce fichier RAR contient un fichier GIF nommé square.gif et... un flag!

  
  

• Selon votre éditeur de GIF, vous pourrez le lire ou non. Il pourrait aussi être corrompu, surtout si vous le lisez sur Windows et que vous remarquez que le contenu du fichier ne correspond pas à la vignette de l'Explorateur Windows. On pourrait penser que des données ont été perdues, mais alors pourquoi ça fonctionnerait bien dans certains éditeurs? Allons voir les spécifications de l'en-tête du format GIF.

  
  

• Un indice à noter serait le nom du fichier GIF... peut-être que l'image doit être un carré? Vérifions les dimensions actuelles : sqtr(10x40960px) = 640

  • Ça veut dire qu'on peut former un carré de 640x640px avec le contenu actuel du fichier

    
    

  • Selon les spécifications de l'en-tête du fichier, on change les 7e+8e et 9e-10e octets pour 80 02 80 02

    
    
  
  
  
  

• Bon... c'est encore un gros carré rouge géant. Une des caractéristiques du GIF, c'est la palette de couleurs. Extrayez-la avec l'outil de votre choix et changez une des couleurs pour faire ressortir la chaîne « Unl0¢k it! »

  
  

• Ouvrez l'archive ZIP initiale avec cette chaîne comme mot de passe et récupérez le flag!