Openstuff Wiki : HowtoForensic

HomePage :: Categories :: PageIndex :: RecentChanges :: RecentlyCommented :: Login/Register

Détection d'une intrusion et réalisation d'un audit post-mortem


La collecte de trace ou autopsie (forensics) est une chose longue et fastidieuse. Nous verrons comment détecter les signes d'une machine compromise puis l'organisation de la collecte d'information. Pour finir, nous regarderons du côté des outils existants permettant de se simplifier la vie.

1. Détection et qualification d'un incident


1.1 Signe de compromission


Une machine infectée peut se manifester de nombreuses manières que ce soit par l'utilisation anormale de ressources (CPU, bande passante, disque, ...) ou par un comportement étrange (lenteur, nouveau service en écoute, ...). Il faut également bien avoir à l'esprit que si l'intrusion est avérée, nous ne pouvons pas faire confiance au système. En effet, il est possible qu'un rootkit ait été installé à notre insu, cachant toutes activités malveillantes. Voici néanmoins quelques pistes pour détecter une compromission:










1.2 Qualification


Ici l'objectif est de confirmer ou d'infirmer l'intrusion à partir des renseignements en notre possession. Ceci se fait en récupérant un ensemble d'information sur:

Une fois la qualification faite, en fonction de la gravité, il pourra nécessaire de recourir à une gestion de crise qui comprendra les phases suivantes:

Lors du traitement de la crise, il faudra veiller à isoler la ou les machines compromises. Attention à les isoler et non les éteindre ! Ceci entraînerait la perte d'information, exemple: filesystem complet en RAM (ramfs). Détaillons maintenant le processus de collecte de traces.

2. Collecte de traces post-mortem


En cas d'une intrusion avérée, l'audit d'une machine devrait suivre les étapes suivantes.

2.1 Mise en place d'une analyse réseau


Analyse du trafic réseau via des outils tels que wireshark, tcpdump ou autre. Ceci pourrait révéler de précieuses informations telles que la présence de C&C (command-and-control, canal permettant, l'envoie, d'instructions à distance sur un botnet), ou toutes autres activités malveillantes.

2.2 Récupération des données volatiles et analyse "live" du système


Le plus simple est de récupérer les informations via le réseau, par exemple avec la commande netcat:
 # nc -L -p161 >> victime.audit

 # commande || nc machine_audit 161

Toutes les commandes doivent provenir d'un toolkit intégrant les outils compilés statiquement.

Voyons maintenant les informations à récupérer.

2.2.1 Identification des machines


Windows
hostname & ver
date /T & time /T 
net statistics server
ipconfig /all


Linux
uname -a
date
uptime
ip a


2.2.2 Configuration


Sous linux:
rpm -qa <ou> dpkg -l
route -arn
cat /etc/passwd /etc/shadow, ...


Sous Windows:
systeminfo 

Différents outils de forensics existent pour Windows, voir: http://www.microsoft.com/technet/security/guidance/disasterrecovery/computer_investigation/a9a5c2a9-cce3-4edb-a92c-10983899240a.mspx

2.2.3 activité


Windows
netstat -an
arp -a


Linux
w
ps aux
netstat -tupawn
arp -a
lsof


2.2.4 historique


Sous linux:
lastlog
history
find (-ctime -atime -mtime)
fichier de log


2.2.5 autres


Sous linux, si un sniffer est utilisé, la socket doit apparaître dans la liste des descripteurs de fichier ouvert par le processus et aussi dans /proc/net/packet
 $ cat /proc/net/packet
 sk       RefCnt Type Proto  Iface R Rmem   User   Inode
 ffff810032a3e800 3      10   0003   2     1 0      101    16673 
 
 $ for fd in $(find /proc -name fd); do echo $fd; ls -al $fd | grep "socket:\[16673\]"; done;
 [...]
 /proc/5043/fd
 lrwx------ 1 root root 64 2007-06-01 11:21 7 -> socket:[16673]
 
 $ lsof -p 5043
 $ ps -p 5043   
   PID TTY          TIME CMD
  5043 ?        00:00:00 dhclient


Penser également à faire un dump de la RAM (/proc/kcore), des systèmes de fichier en ram ...

2.3 Copie et analyse "off-line"


Une fois l'analyse live du système, nous pouvons procéder à une analyse hors-ligne:


L'analyse à proprement parlé intégrera les étapes suivantes:

3 Exemples d'outils automatisés


Heureusement, des outils plus ou moins automatiques existent. Ils vont nous permettre de gagner un temps précieux. Nous allons voir en particulier deux outils, mais il en existe bien d'autres. Voir cette page par exemple. De nombreux live-cd intègre ces outils : http://www.darknet.org.uk/2006/03/10-best-security-live-cd-distros-pen-test-forensics-recovery/

3.1 The Coroner's Toolkit


3.1.1 Présentation

The Coroner's Toolkit (TCT) est une collection d'outils permettant l'analyse post-mortem de systèmes Unix après une compromission. Il est composé de quatre parties :

Une des limitations de TCT est qu'il ne gère pas le NTFS, le FAT ou l'EXT3.

3.1.2 grave-robber

grave-robber est la pièce maîtresse de TCT, c'est en fait un ensemble d'outils de récupération d'information. Toutes les informations sont capturées par ordre de "volatilité" puis sauvegardées avec un timestamp et un MD5. grave-robber peut être utilisé de deux façons. Premièrement pour produire des images du système à des instants donnés. Deuxièmement, après une intrusion, pour récupérer un maximum de trace. Cet outil est conçu pour éviter de lancer les commandes via un shell dans l'optique de minimiser les interactions avec le système. La date d'exécution des commandes ainsi que leurs résultats sont soigneusement enregistrés.

Voici un exemple d'utilisation de TCT:
$ sudo apt-get install tct
$ sudo grave-robber
$ tail -n3 coroner.log error.log
==> coroner.log <==
2007/07/11 13:24:59 +0200 PIPEFROM_CMD /usr/bin/md5sum /boot/grub/splash.xpm.gz
2007/07/11 13:24:59 +0200 PIPEFROM_CMD /usr/bin/md5sum /boot/grub/default
2007/07/11 13:24:59 +0200 PIPEFROM_CMD /usr/bin/md5sum /boot/grub/installed-version

==> error.log <==
/usr/bin/md5sum: /boot/grub: est un répertoire
/usr/bin/md5sum: /boot/grub/splashimages: est un répertoire
Can't open /var/cache/tct/conf/save_these_files (in process_files_to_save())
$ cd /var/cache/tct/data/
$ ls
chihiro/                           chihiro_2007_07_11_11:19:46_+0200/ 
$ sudo ls -al chihiro/
total 65836
drwx------  8 stan root     4096 2007-07-11 11:33 .
drwxr-xr-x  3 root root     4096 2007-07-11 11:19 ..
-rw-r--r--  1 root root 67269622 2007-07-11 13:24 body
-rw-r--r--  1 root root    27452 2007-07-11 13:23 body.S
drwx------  2 root root     4096 2007-07-11 11:34 command_out
drwx------ 14 root root     4096 2007-07-11 13:24 conf_vault
drwx------  2 root root     8192 2007-07-11 11:33 icat
drwx------  2 root root     8192 2007-07-11 11:33 proc
drwx------  2 root root     4096 2007-07-11 11:33 removed_but_running
drwx------  2 root root     4096 2007-07-11 11:19 trust


Ici nous avons donc installé TCT et lancé grave-robber. Attention l'exécution est longue, dans mon cas il aura mis 2 heures. Celui-ci à bien crée un fichier de log coroner.log contenant toutes les actions effectuées. Il y a également un fichier error.log qui contient l'ensemble des erreurs rencontrées. Le résultat de l'analyse se trouve dans le répertoire /var/cache/tct/data/. Le répertoire chihiro/ est un lien symbolique vers chihiro_2007_07_11_11:19:46_+0200/. Voici l'explication du résultat produit par grave-robber:


3.1.3 unrm & lazarus

Exemple d'utilisation : récupération des données sur /dev/hda3, puis analyse:
# unrm /dev/hda3 > unrm.out
# lazarus -D /var/cache/tct/blocks/ unrm.out


Chaque code affiché à l'écran représente un type de donnée particulier. Par exemple . représente un bloc de donnée non reconnu, t du texte non reconnu, l des fichiers de log, ...

3.1.4 mactime

mactime peut être lancé a la volé ou sur une base de données produite par grave-robber.

ici nous allons voir les fichiers accédés ou modifiés après le 24/05/2007 (attention a l'inversion des jours et des mois dans la commande)
$ mactime -d . 05/24/2007
Jul 11 07 15:25:31      118 .a. -rw------- stan     stan     ./.Xauthority
	               1099 .a. -rw-r--r-- stan     stan     ./.vimrc
Jul 11 07 15:25:34     9599 mac -rw-r--r-- stan     stan     ./out2.html
Jul 11 07 15:52:42        1 m.c -rw-r--r-- stan     stan     ./out.html


Nous avons au début de chaque ligne la date et l'heure, la taille du fichier, la "valeur mac", les droits puis le nom du fichier. La "valeur mac" indique les dernières dates de modification (mtime), d'accès (atime) ou de modification de statuts (ctime). Un point signifie qu'il n'y a pas eu de changement. Ici, Xauthority a été ouvert, out2.html a été créé et out.html a été modifié.

Pour faire la même chose sur ce qu'a capturé grave-robber:
$ mactime -b /var/cache/tct/data/chihiro/body 05/24/2007



3.2 The Sleuth Kit et Autopsy


Sleuth Kit, comme TCT, est un ensemble de commandes pour l'analyse post-mortem. TSK supporte les systèmes de fichiers suivant: FAT, Ext2/3, NTFS, UFS, et ISO 9660. Il analyse les images d'un système de fichier généré par dd. Sleuth Kit est écrit en C et en Perl et intègres différents outils:

Autopsy est une interface graphique similaire à un gestionnaire de fichier. Il se base sur les outils du Sleuth Kit qui sont en mode commande. Autopsy permet d'analyser différents types de système de fichier via une interface en HTML. Il suffit pour cela de se connecter au serveur Autopsy à partir d'un navigateur Web. Autopsy n'est pas comme Lazarus, aucune commande n'as besoin d'être lancé avant: tout peut être fait via l'interface qui générera les commandes Sleuth Kit adéquates.

4 Application: utilisation d'Autopsy sur un cas concret


Nous allons utiliser comme matière première le challenge proposé par le projet honeynet: The Forensic Challenge. Une archive d'un système compromis est disponible. Allez, c'est parti !

Récupération de l'archive, et extraction des partitions:
$ wget "http://www.honeynet.org/misc/files/challenge-images.tar"
$ tar xvf challenge-images.tar
./
./honeypot.hda1.dd.gz
./honeypot.hda5.dd.gz
./honeypot.hda6.dd.gz
./honeypot.hda7.dd.gz
./honeypot.hda8.dd.gz
./honeypot.hda9.dd.gz
./readme
$ for i in *.gz; do echo ">>> $i"; gunzip $i; done
>>> honeypot.hda1.dd.gz
>>> honeypot.hda5.dd.gz
>>> honeypot.hda6.dd.gz
>>> honeypot.hda7.dd.gz
>>> honeypot.hda8.dd.gz
>>> honeypot.hda9.dd.gz


Vérification des md5:
$ md5sum *.dd
a1dd64dea2ed889e61f19bab154673ab  honeypot.hda1.dd
c1e1b0dc502173ff5609244e3ce8646b  honeypot.hda5.dd
4a20a173a82eb76546a7806ebf8a78a6  honeypot.hda6.dd
1b672df23d3af577975809ad4f08c49d  honeypot.hda7.dd
8f244a87b8d38d06603396810a91c43b  honeypot.hda8.dd
b763a14d2c724e23ebb5354a27624f5f  honeypot.hda9.dd


Installation et lancement d'Autopsy:
$ sudo apt-get install autopsy
$ sudo autopsy


Maintenant, ouvrir un navigateur et aller sur: http://localhost:9999/autopsy
	   Location = /home/stan/forensic/honeypot.hda5.dd
	   Type = partition
	   Import Method = Symlink
	   Mount Point = /5_usr/
	   File System Type = ext


Ce qui donne:
	    Mountname       fs                      type
	    /1_boot/        honeypot.hda1.dd-0-0    ext
	    /5_usr/         honeypot.hda5.dd-0-0    ext
	    /6_home/        honeypot.hda6.dd-0-0    ext
	    /7_var/         honeypot.hda7.dd-0-0    ext
	    /1_/            honeypot.hda8.dd-0-0    ext
	    raw             honeypot.hda9.dd-0-0    raw



En parcourant le résultat nous pouvons trouver l'installation d'un root kit:
Wed Nov 08 2000 15:51:53         1187 .a. -/-rw------- 1010     100      109843   /5_usr/man/.Ci/scan/port/strobe/Makefile
	                          114 .a. -/-rwxr-xr-x 1010     100      109827   /5_usr/man/.Ci/scan/amd/a.sh
	                         4096 .a. d/drwxr-xr-x 1010     100      93894    /5_usr/man/.Ci/scan/statd
	                       132785 .a. -/-rwxr-xr-x 1010     100      109809   /5_usr/man/.Ci/qs
	                         4096 .a. d/drwxr-xr-x 1010     100      109831   /5_usr/man/.Ci/scan/x
	                        17969 .a. -/-rwxr-xr-x 1010     100      109832   /5_usr/man/.Ci/scan/x/x
	                          156 .a. -/-rwxr-xr-x 1010     100      109863   /5_usr/man/.Ci/needz
	                         4096 .a. d/drwxr-xr-x 1010     100      109840   /5_usr/man/.Ci/scan/port
	                         [...]


Juste avant, nous pouvons deviner qu'un utilisateur se logge à cause de l'accès aux fichiers hosts.allow, hosts.deny ainsi que message de login issue.net:
Wed Nov 08 2000 15:45:18          161 .a. -/-rw-r--r-- 0        0        26216    /1_/etc/hosts.allow
	                            0 .a. -/-rw-r--r-- 0        0        26217    /1_/etc/hosts.deny
Wed Nov 08 2000 15:45:19           63 .a. -/-rw-r--r-- 0        0        26573    /1_/etc/issue.net


Le reste de l'investigation est laissé en exercice au lecteur. La solution pourra être trouvée sur le site du projet Honeynet. Voir aussi: http://www.linux-magazine.com/issue/36/Autopsy.pdf
Valid XHTML 1.0 Transitional :: Valid CSS :: Powered by WikkaWiki
Page was generated in 0.0949 seconds