Sélectionner le fichier
image dans File browsing.
Dans le menu
Integrity Check, générer une somme de contrôle MD5, cela permet de vérifier que le fichier n'est pas altérer
par la suite.
Trois fichiers se trouvent dans la racine de la disquette
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.
Chaque mois, le Scan of the Month challenge propose
l'analyse de trames réseaux suspectes. Le SOTM 24 rompt avec la tradition.
Le Digital Forensic Research WorkShop (DFRW) a proposé de travailler sur
l'analyse d'une disquette.
Pour le challenge, le DFRW ont concocté une histoire de trafic de drogue dans un lycée. Dans ce scénario, une disquette a été saisie par la police lors d'une perquisition chez Joe Jacobs qui a été pris en flagrant délit de revente de stupéfiant aux abords de la Smith Hill High School. Le but est de découvrir le fournisseur/producteur de marijuana et de trouver si possible des éléments prouvant qu'il est lié à l'augmentation du trafic dans d'autres écoles.
Après avoir récupérer l'image de la disquette et le rapport de la police, vérifier que l'image n'a pas été altérée.
md5sum image.zip b676147f63923e1f428131d59b1d6a72 image.zip
L'empreinte MD5 correspond. On peut dezipper le fichier: unzip image.zip
Pour accéder aux données, on peut regénérer une disquette à partir
de son image dd if=image of=/dev/fd0 ou bien utiliser
l'interface de loopback en tant qu'utilisateur root.
# mount -o loop,ro image /mnt/tmp
De cette façon, le système de fichier de la disquette est disponible
dans le répertoire /mnt/tmp.
$ cd /mnt/tmp $ ls -al total 25 drwxr-xr-x 2 root root 7168 jan 1 1970 . drwxr-xr-x 9 root root 1024 oct 22 16:36 .. -rwxr-xr-x 1 root root 15585 sep 11 08:30 cover page.jpgc -rwxr-xr-x 1 root root 1000 mai 24 08:20 schedu~1.exe $ file * cover page.jpgc : PC formatted floppy with no filesystem schedu~1.exe: Zip archive data, at least v2.0 to extract
Des deux fichiers listés sur la disquette, cover page.jpgc a une
extension bizarre et le fichier pointe sur des données non formatées, d'autre part,
schedu~1.exe correspondrait plutôt à un fichier zip.
unzip schedu~1.exe
Archive: schedu~1.exe
End-of-central-directory signature not found. Either this file is not
a zipfile, or it constitutes one disk of a multi-part archive. In the
latter case the central directory and zipfile comment will be found on
the last disk(s) of this archive.
note: schedu~1.exe may be a plain executable, not an archive
unzip: cannot find zipfile directory in one of schedu~1.exe or
schedu~1.exe.zip, and cannot find schedu~1.exe.ZIP, period.
Mais ce n'est pas un fichier zip valide. On a donc deux fichiers
inexploitables pour le moment. Il semble que le système de fichier
soit endommagé. Utilisons dosfsck pour vérifier cette hypothèse.
[kmaster@christophe sotm24]$ dosfsck -v image
dosfsck 2.8 (28 Feb 2001)
dosfsck 2.8, 28 Feb 2001, FAT32, LFN
Boot sector contents:
System ID "MSDOS5.0"
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
Wrong checksum for long file name "Scheduled Visits.exe ".
(Short name SCHEDU~1.EXE may have changed without updating the long name)
1: Delete LFN
2: Leave it as it is.
3: Fix checksum (attaches to short name SCHEDU~1.EXE)
? 2
/cover page.jpgc
Contains a free cluster (420). Assuming EOF.
/cover page.jpgc
File size is 15585 bytes, cluster chain length is 0 bytes.
Truncating file to 0 bytes.
/SCHEDU~1.EXE
File size is 1000 bytes, cluster chain length is > 1024 bytes.
Truncating file to 1000 bytes.
Checking for unused clusters.
Reclaimed 31 unused clusters (15872 bytes).
Leaving file system unchanged.
image: 2 files, 2/2847 clusters
En effet, le système de fichier a du être altéré pour empêcher la récupération des informations. Il est temps de sortir les grands moyens.
L'analyse sera effectué avec le produit OpenSource
The @stake Sleuth Kit (TASK)
et son interface web Autopsy.
Ce logiciel a déjà été évoqué dans le dossier Dissimulation, exhumation et autopsie de
données sous Linux paru dans LinuxMag 42. Cette fois-ci, il sera utilisé sur un système
de fichier FAT et non plus EXT2.
L'installation des logiciel est assez simple:
tar xzf task-1.52.tar.gz cd task-1.52/ make cd ..
tar xzf autopsy-1.62.tar.gz make Autopsy Forensic Browser Installation perl found: /usr/bin/perl strings found: /usr/bin/strings Testing decimal offset flag of strings: PASS Testing non-object file arguments: PASS grep found: /bin/grep Enter TASK Directory: /home/kmaster/tools/filesystem/task-1.52 TASK bin directory was found Enter Morgue Directory: /home/kmaster/tools/filesystem/morgue WARNING: /home/kmaster/tools/filesystem/morgue does not exist Enter Default Investigator Name (for the Autopsy Reports) [unknown]: Christophe GRENIER Settings saved to conf.pl
Le répertoire de la morgue /home/kmaster/tools/filesystem/morgue
contiendra les systèmes de fichiers à analyser. Il suffit de le créer.
Pour commencer l'analyse, on copie l'image de la disquette dans la morgue de TASK,
puis le fichier fsmorgue est renseigné pour indiquer l'existence
de cette image de disquette.
cd morgue cp ~/image . echo "image fat12 A:\ EST5EDT" >> fsmorgue
Il n'y a plus qu'à exécuter la partie serveur.
[kmaster@christophe autopsy-1.62]$ ./autopsy 8888 localhost
============================================================================
Autopsy Forensic Browser
ver 1.62
============================================================================
Morgue: /home/kmaster/tools/filesystem/morgue
Start Time: Wed Nov 20 19:02:32 2002
Investigator: Christophe GRENIER
Paste this as your browser URL on localhost:
http://localhost:8888/14823541513871875968/autopsy
Keep this process running and use <ctrl-c> to exit
Sélectionner le fichier image dans File browsing.
Dans le menu Integrity Check, générer une somme de contrôle MD5, cela permet de vérifier que le fichier n'est pas altérer
par la suite.
Trois fichiers se trouvent dans la racine de la disquette
| Secteur | |
|---|---|
| 0 | Boot FAT12 |
| 1-9 | FAT 1 |
| 10-18 | FAT 2 |
| 19-32 | Répertoire racine |
| 33-2878 | Données |
L'extension jpgc est étrange, elle ne correspond à rien
si ce n'est qu'elle s'approche de jpg, l'extension des fichiers
images JPEG.
Sélectionner le fichier cover page.jpgc indique
que le type de fichier est PC formatted floppy with no filesystem,
c'est à dire qu'il pointe vers un espace formaté sans donné ce qui ne correspond
pas à une image JPEG.
La taille indiquée pour ce fichier est de 15585 octets. En regardant
les informations rattachées à cette entrée, l'inode 8, seul
le secteur 451 est utilisé. Comme chaque secteur fait 512 octets,
le fichier devrait occuper 31 secteurs. ((15585 + 512 - 1 ) / 512 = 31 secteurs)
L'entré et l'extension du fichier semblent avoir été trafiquées. En attendant, passons au fichier suivant.
Le fichier Jimmy Jungle.doc a été effacé, il commençait au secteur 33
et avait une taille de 20480 octets,
soit 40 secteurs ((20480+512-1)/512=40 secteurs).
Il est de type Microsoft Office Document.
Ce serait donc bien un document Word mais la fonction Export
ne permet de récupérer que les 512 premiers octets!
Recherchons la cause du problème au niveau du File System.
Dans un système de fichier FAT, l'espace disque est divisé
sous forme de cluster de taille fixe. Dans le cas d'une disquette,
chaque cluster ne compte qu'un secteur.
La FAT, File Allocation Tables, est constitué de listes chaînées de clusters.
Au niveau des entrées de répertoires appelées inode par Autopsy,
il est indiqué quel est le premier cluster
utilisé par chaque fichier, ainsi on accède à la suite du fichier en parcourant
les clusters indiqués dans la FAT.
Dans notre cas, deux chaînes sont présentes:
L'inode du fichier Jimmy Jungle.doc indique que le premier
cluster était le numéro 33. Aucune chaîne dans la FAT ne commence à
ce secteur, ce qui est cohérent avec l'effacement du fichier.
Dans Data browsing puis Allocation List,
on voit que les secteurs 33 à 72 sont libres, soit 40 secteurs
exactement. Lorsqu'un système FAT n'est pas fragmenté, les
clusters sont consécutifs et il semble que cela soit le cas, Ouf!
Copions les 40 secteurs commençant au secteur 33 et exportons le.
Sauvegardons ce fichier sous le nom Jimmy Jungle.doc.
Le document Word est parfaitement lisible avec AbiWord, on a
réussi!
Ce fichier permet d'apprendre l'adresse du fournisseur de Joe:
Jimmy Jungle 626 Jungle Ave Apt 2 Jungle, NY 11111Ce courrier indique aussi la présence du planning de Joe protégé par mot de passe, mot de passe identique à celui que Jimmy lui aurait communiqué précédemment.
Le fichier Scheduled Visits.exe est de type
Zip archive data, at least v2.0 to extract contrairement
à ce que son extension laisserait croire. Les informations
liées à son inode révèlent que le fichier fait 1000 octets et occupent
les secteurs 104 et 105, or on a vu que les secteurs 104 à 108 formaient
une chaîne. C'est donc cette chaîne que l'on va sauvegarder via le menu
File System sous le nom Scheduled Visits.zip
[kmaster@christophe sotm24]$ unzip Scheduled\ Visits.zip Archive: Scheduled Visits.zip [Scheduled Visits.zip] Scheduled Visits.xls password: skipping: Scheduled Visits.xls incorrect password [kmaster@christophe sotm24]$Malheureusement, le fichier zip nécessite un mot de passe dont l'existence était évoquée dans le précédent document Word.
Jusqu'à présent, on a découvert que les secteurs
33-72 (40) étaient occupés par JIMMY JUNGLE.DOC et
les secteurs 104-108 (5) par SCHEDULED VISITS.EXE.
Il reste la chaîne de 31 secteurs 73-103 que l'on n'a pas encore vu.
Or justement le fichier COVER PAGE.JPGC faisant
15585 octets, il occupe le même nombre de secteurs.
Dans le menu File System, sélectionnons la chaîne
73-103, elle est de type JPEG! Sauvegardons là dans le fichier COVER PAGE.JPG.
Cette image est la couverture de la revue POT SMOKERS MONTHLY
et cite Jimmy Jungle comme producteur et fournisseur.
Les trois fichiers ont été récupérés mais le fichier zip est protégé
par mot de passe. Il va falloir approfondir les recherches. Pour cela,
demandons un Strings display, c'est à dire l'affichage des
chaînes de texte pour chacun des fichiers. Le document Word a été écrit avec
la version 10 soit XP. Rien d'intéressant pour le fichier zip. Bingo,
à la fin de l'image JPEG se trouve le texte pw=goodtimes.
Ce texte commence à l'octet 15648 (Utiliser la visualisation hexa), alors
que le fichier ne fait que 15585 octets. Il est donc plus juste de dire
qu'il se trouve dans l'espace inutilisé du dernier secteur du fichier.
Le mot de passe goodtimes permet de décompresser le fichier ZIP.
Le fichier Excel s'ouvre très bien avec Gnumeric. Il recense le planning des écoles où seront vendu la drogue.
Les secteurs 32 à 108 ont été examinés, il contenait les données
des trois fichiers. Qu'est ce qui se trouve dans les secteurs suivants ?
Les secteurs 109 et suivants ne contiennent que les caractères hexadécimales
F6, cela correspond à des secteurs formatés mais jamais utilisés.
Pour vérifier que le reste de la disquette ne contient pas d'autres
données, utilisons une petite astuce:
dd if=image bs=512 skip=109 2> /dev/null | hexdump 0000000 f6f6 f6f6 f6f6 f6f6 f6f6 f6f6 f6f6 f6f6 * 015a400 0000 0000 0000 0000 0000 0000 0000 0000 * 015a600
Il n'y a aucune autre information. Pour récapituler, voici la structure de la disquette:
| Secteur | |
| 0 | Boot FAT12 |
| 1-9 | FAT 1 |
| 10-18 | FAT 2 |
| 19-32 | Répertoire racine |
| 33-72 | Jimmy Jungle.doc |
| 73-103 | Cover Page.jpgc |
| 104-108 | Scheduled Visit.exe |
| 109-2878 | Secteurs formatés initialisés à F6 |
J'espère que cet article vous aura inspiré et que vous serez à même de récupérer un fichier effacé si le problème se présentait. Je tiens à remercier Erik Cabetas pour sa solution dont je me suis inspiré pour cet article.
Christophe GRENIER grenier@cgsecurity.org
Security Consultant chez Global Secure