Depuis plus de deux ans, le projet Honeynet propose régulièrement d'étudier des outils, des tactiques utilisées par des pirates lors d'intrusion pour démontrer la réalité de ces attaques, pour apprendre comment un pirate agit pour s'en protéger et plus généralement pour améliorer les technologies et méthodes de collecte d'information. Le Scan of the Month 26 consiste à analyser le contenu d'une disquette dans la suite du SOTM24.

Pour ce challenge, le DFRW ont concocté une histoire de trafic de drogue dans un lycée. Dans cette seconde partie du scénario, une disquette a été saisie par la police lors d'une perquisition chez Jimmy Jungle, le fournisseur de Joe Jacobs qui a été pris en flagrant délit de revente de stupéfiant aux abords de la Smith Hill High School.

Analyse

Vérification des données

Pour commencer, téléchargeons le rapport de police et l'image de la disquette. 

md5sum scan26.zip
c8e2454b970538de26a0fa887017109b  scan26.zip

L'image n'a pas été altérée lors du téléchargement, dezipons l'archive et vérifions le système de fichier. 

[kmaster@christophe sotm26]$ unzip scan26.zip
Archive:  scan26.zip
  inflating: scan26
[kmaster@christophe sotm26]$ fsck.msdos -v scan26
dosfsck 2.8 (28 Feb 2001)
dosfsck 2.8, 28 Feb 2001, FAT32, LFN
Boot sector contents:
System ID ""RVRbIHC"
Media byte 0xf0 (5.25" or 3.5" HD floppy)
       512 bytes per logical sector
       512 bytes per cluster
         1 reserved sector
First FAT starts at byte 512 (sector 1)
         2 FATs, 12 bit entries
      4608 bytes per FAT (= 9 sectors)
Root directory starts at byte 9728 (sector 19)
       224 root directory entries
Data area starts at byte 16896 (sector 33)
      2847 data clusters (1457664 bytes)
18 sectors/track, 2 heads
         0 hidden sectors
      2880 sectors total
Checking for unused clusters.
scan26: 0 files, 0/2847 clusters

Le système de fichier est valide mais aucun fichier ne s'y trouve!

Analyse

L'analyse de la disquette sera effectué avec le produit OpenSource The @stake Sleuth Kit (TASK) et son interface web Autopsy, les mêmes logiciels que pour le SOTM24.

Création d'un cas

[kmaster@christophe autopsy-1.70]$ ./autopsy 8888 localhost
============================================================================

                       Autopsy Forensic Browser
                             ver 1.70

============================================================================

Evidence Locker: /home/kmaster/tools/filesystem/evidence/
Start Time: Mon Feb 10 11:25:23 2003

Paste this as your browser URL on localhost:
        http://localhost:8888/17620511601522052610/autopsy

Keep this process running and use  to exit


Créons un nouveau cas SOTM26.

Ajoutons une nouvelle machine jimmy_jungle avec comme fuseau horaire EST5EDT qui correspond à New York, lieu des événements.

Suivons les instructions et copions l'image de la disquette dans le sous-répertoire des evidence (preuves): cp ~/scan26 /home/kmaster/tools/filesystem/evidence//SOTM26/jimmy_jungle/images.

Ajoutons l'image somt26 en tant quefat12. Validons le checksum avec Autopsy.

Analyse des données

A l'aide du programme gettypes et d'une petite modification pour afficher le numéro des secteurs, récupérons le type de données des différents secteurs: 

~/tools/filesystem/gettypes scan26
/usr/share/magic/magic.mime file not found, using defaults
attempting to find data types in scan26...

Possible data types found in scan26 with offsets:

  sector        hex         dec     type
--------------------------------------------------
        33  0x00004200       16896  image/jpeg
        97  0x0000c200       49664  image/bmp
      2171  0x0010f600     1111552  video/unknown
      2179  0x00110600     1115648  application/octet-stream
      2375  0x00128e00     1216000  audio/mpeg
      2739  0x00156600     1402368  text/plain

La disquette a du subir un formatage rapide car le répertoire racine et les FATS sont vierges.

Dans le menu Data Unit, sélectionnons le secteur n°33 et une taille de 64 secteurs (96-33+1=64), sauvegardons le fichier sous le nom images-scan26-Sector33.jpg.
Le marqueur de fin d'une image JPEG est 0xffd9, on en déduit que la taille du fichier est de 32602 octets. 

dd if=images-scan26-Sector33.jpg of=image-33.jpg count=1 bs=32602
Toujours dans le menu Data Unit, sauvegardons cette fois-ci le fichier images-scan26-Sector97.bmp commençant au secteur 97 avec une taille de 2279 (2375-97+1=2279) secteurs.
En parcourant la disquette ou en utilisant la fonction strings, on remarque deux textes:

Secteur 2397pw=help
Secteur 2739John Smith's Address: 1212 Main Street, Jones, FL 00001

Il s'agit à priori d'un mot de passe et d'une adresse.

Analyse des images

Les images sont deux plans de la même zone. On y apprend deux adresses:

image-33.jpg

Comme aucun fichier texte n'a été trouvé, je me demandé si aucune information n'avait été dissimulé dans les images. A l'aide de stegdetect, recherchons si de la stéganographie a été utilisé. 

[kmaster@christophe sotm26]$ ~/tools/stegano/stegdetect/stegdetect image-33.jpg
image-33.jpg : invisible[7771](***)

Bingo, des données ont été cachées avec Invisible Secrets. Si on y regarde de plus près, elles se trouvent sous forme cryptée dans la partie commentaire de l'image JPEG. 

[kmaster@christophe sotm26]$ identify -verbose image-33.jpg
Image: image-33.jpg
  Format: JPEG (Joint Photographic Experts Group JFIF format)
  Geometry: 720x540
  Class: DirectClass
  Type: true color
  Depth: 8 bits-per-pixel component
  Colors: 807
  ...
  Resolution: 72x72 pixels/inch
  Filesize: 32602b
  Interlace: None
  Background Color: white
  Border Color: #dfdfdf
  Matte Color: grey74
  Iterations: 0
  Compression: JPEG
  comment: SnUG³-D5Ò#fk½v
  signature: a2de2523105e9517ba584bf0c6a6ce0e0aed84b9bd77b2657a8a99bb43fed91d
  Tainted: False
  User Time: 0.0u
  Elapsed Time: 0:01

Toutes les tentatives de décryptage avec Invisible Secrets ont été infructueuses en prenant comme mot de passe help quelque soit l'algorithme utilisé.

image-97.bmp

Stegdetect ne fonctionne que pour les images JPEG. Regardons "à la main" si cette image elle-aussi dissimule un contenu secret. Avec Gimp, ajustons le contraste au maximum (menu Filtre/Amélioration/Augmenter les contrastes).

On distingue parfaitement des pixels colorés dans la partie supérieure de l'image alors que la partie inférieure est nette. Des données ont donc été dissimulées au début de l'image JPEG dans les bits de poids faibles (LSB) ce qui est une caractéristique de Invisible Secrets: Analyzing a steganography software: Invisible Secrets 2002. Le décodage avec le mot de passe help échoue lui aussi!

L'information négligée

Lorsque j'ai réalisé ce challenge, je me suis retrouvé bloqué à cette étape. J'avais négligé une information cruciale se trouvant dans le rapport: dfrws.org était inscrit sur la disquette. Il s'agit du site web des concepteurs de ce challenge! Des commentaires HTML se trouvent dans le code source de la page http://www.dfrws.org/dfrws-overview.html: 

Invisible Secrets
http://www.invisiblesecrets.com
PW=lefty
Algorythm= twofish
PW=right

Décodage des fichiers

Sous Invisible Secrets, avec le mot de passe lefty et l'algorithme de cryptage twofish, on peut extraire le fichier John.doc du fichier JPEG et avec le mot de passe right un fichier WAV. Le fichier son indique: This is Jimmy, meet me at the pier tomorrow. I drive a blue 1978 Mustang with Ontario license plates. Jimmy donne rendez-vous au Pier aujourd'hui, il conduira une Mustang bleu de 1978 avec des plaques de l'Ontario.

Le document Word est protégé par le mot de passe help. On y apprend que Jimmy Jungle n'a pas pu prendre possession de la dernière cargaison au Danny's faute d'argent, son principale dealer Joe Jacobs ayant été arrêté.

Toutes les informations ont été trouvées, le travail de police peut continuer.

Conclusion

Pour ce challenge, seuls 14 personnes ou équipes ont envoyées leurs résultats, résultats souvent partielles car peu ont utilisé l'information se trouvant sur le site web. Ce challenge figure parmi les plus difficiles sans doute non pas par la présence de stéganographie mais par la "difficulté" à retrouver les mots de passe. 

Christophe GRENIER, grenier@cgsecurity.org
Consultant Sécurité chez Global Secure