Forensic – PearlArmor : analyse de journaux et d’une image disque
Sommaire
I. Présentation
Nous continuons notre suite d'articles sur le CTF du FIC 2021 proposé par l'école EPITA afin de découvrir certains outils et méthodes de forensic (investigation numérique). Dans cet article nous allons nous pencher sur l'analyse de journaux d'évènements d'un service web et d'une image disque.
Cette enquête est découpée en 5 articles, voici la liste des articles :
- Cas n°1 : PhishingBoat - analyse d'un fichier Mbox et d'un fichier PDF malveillant
- Cas n°2 : FloatingCredentials - analyse d’une capture WireShark
- Cas n°3 : EngineX - détection d'un scan nmap et analyse réseau d'un protocole propriétaire industriel
- Cas n°4 : SteerOnSomewhere - analyse de PDF et EXE malveillants
- Cas n°5 - PearlArmor : analyse de journaux et d'une image disque
II. Contexte : Panic on board - PearlArmor
Le contexte de l'incident sur lequel nous intervenons est le suivant : un bateau de croisière de la compagnie maritime ArMor a subi une panne et se retrouve bloqué en pleine mer.
Nous savons à présent qu'à la suite d'un phishing, l'attaquant est parvenu à dérober les identifiants VPN d'un utilisateur puis à mener une attaque sur les automates du bateau afin de les arrêter. Le cinquième et dernier contexte de cette analyse est le suivant :
Avant chaque appareillage, l’ordinateur de maintenance présent à bord met à jour sa documentation depuis le serveur de fichiers interne. Le PDF qui a infecté le SeaCastle a donc été téléchargé depuis ce serveur, pourtant situé dans les locaux d’ArMor ! Il ne reste plus qu’à trouver comment le fichier qui a infecté le SeaCastle a été uploadé sur le serveur de documentation !
Deux fichiers nous sont ici fournis :
- Droits Serveur Doc.pdf
- FIC-SERVEUR-DOC.ova.gz
- Utilisateurs Serveur Doc.pdf
Nous devons répondre aux questions suivantes pour compléter cette dernière étape de l'analyse :
- La date vraisemblable d'intrusion ;
- Le nom du fichier ayant exploité la faille Apache ;
- La commande ayant été exécutée en root.
N'oublions pas de vérifier l'intégrité des éléments récupérés (le hash BLAKE2 est fourni avec les fichiers sur le site du challenge) :
$ b2sum Droits Serveur Doc.pdf
6c768bfa48b48a576788b9466e0157f8fd6b2aeb653f6dee11aae31c95412c00fb1abef13d62b0d2a2b3925406fb045f889eadb19738c11c9e28eaaf5e9aef84 Droits Serveur Doc.pdf
$ b2sum FIC-SERVEUR-DOC.ova.gz
c513de9149a9eb85837a8fe9f939f3fa9a1d685514daec1d00a93d35ef2a43214d7f672a9cce58e3cb1840eb8d614e81e8f531fe72b5767e3688df7f294fb344 FIC-SERVEUR-DOC.ova.gz
$ b2sum Utilisateurs Serveur Doc.pdf
64b8a397f26b523a9b75fca277eb5ef0f27c4e1657f5c18e46c058982e989a92e2d3419a9e11b2a237e4d8d5ab471c8563eca5877c1b2004086c4d8df60a4fda Utilisateurs Serveur Doc.pdf
Vous trouverez le challenge en question et les fichiers utilisés dans cet article ici : Panic On Board - PearlArmor
Les deux documents PDF ne sont pas des preuves, mais des informations fournies à l'analyste. Dans un cas réel, ce genre d'information peut être obtenue par un échange direct avec les responsables du périmètre étudié. Ils nous informent sur les utilisateurs légitimes et la matrice de droit en place.
III. Gestion des preuves
L'un des principes importants lorsque l'on manipule les preuves (objets analysés) en forensic est de s'assurer de leur intégrité comme nous l'avons vu. En cela, il peut arriver que la simple lecture d'un fichier puisse altérer son contenu. Prenons par exemple le cas de notre image disque : nous pouvons tenter de monter cet OVA dans Vmware/VirtualBox puis de parcourir manuellement le contenu du serveur. Cependant, cette action entrainera de fait une modification du contenu de la preuve (écritures d'évènements de démarrage dans les journaux, de tentative d'authentification, etc.). Voire pire, l'attaquant a très bien pu installer un code de destruction qui s'activera au prochain démarrage.
Nous allons donc commencer par effectuer une copie de tous les éléments que nous comptons étudier, nous travaillerons alors sur cette copie et non sur le fichier récupéré.
IV. Analyse d'une image disque
Nous avons donc sous la main un fichier OVA.
Le format OVA (Open Virtual Machine Format) est un format d'archivage des données d'une machine virtuelle (disque & configuration) permettant de facilement les exporter et les importer d'un hyperviseur à un autre (changement de système ou de technologie). Plus simplement, il s'agit d'une archive .tar dont le contenu est défini par le format OVA.
$ file FIC-SERVEUR-DOC.ova
FIC-SERVEUR-DOC.ova: POSIX tar archive
$ tar -xvf FIC-SERVEUR-DOC.ova
FIC-SERVEUR-DOC.ovf
FIC-SERVEUR-DOC-disk001.vmdk
FIC-SERVEURit-DOC.mf
Le fichier OVF permet d'obtenir des informations sur la machine virtuelle, ce fichier est normalement lu par l'hyperviseur pour construire une VM avec les bonnes ressources (RAM, périphériques, etc.). Au passage, on remarque la présence d'une mauvaise pratique, probablement mise ici pour faciliter la résolution du challenge :
$ grep -i "description" FIC-SERVEUR-DOC.ovf
<Description>root = Root2021
Un autre fichier intéressant dans cette archive OVA est le fichier FIC-SERVEUR-DOC-disk001.vmdk.
VMDK (Virtual Machine Disk) est un format de fichier ouvert (à la base créé par VmWare) permettant de simuler un disque dur virtuel pour les machines virtuelles telles que VMware ou Virtualbox.
Le problème rencontré ici est que les outils d'analyse d'image disque ne sont pas tous accoutumés au format VMDK, nous devons donc convertir ce format VMDK en format raw (image disque brute). Cela à l'aide de la commande suivante :
$ qemu-img convert FIC-SERVEUR-DOC-disk001.vmdk -m 16 -O raw image.disk
À noter que dès lors, nous pouvons présumer que des preuves sont peut-être écrasées ou perdues par cette manipulation, d'où l'intérêt de travailler sur une copie de la preuve et non sur la preuve reçue directement. Cela nous permettra de revenir sur un fichier sain si nous pensons avoir supprimé quelque chose ou pour valider un constat par une autre technique. Nous nous retrouvons donc avec un fichier de 50Go, soit la taille du disque défini lorsque la machine a été créée :
$ ls -alh
-rwxrwxrwx 1 mdy mdy 2,6G déc. 12 2020 FIC-SERVEUR-DOC-disk001.vmdk
-rwxrwxrwx 1 mdy mdy 50G janv. 5 20:10 image.disk
Une fois cela fait, nous pouvons utiliser l'utilitaire fdisk pour déterminer les différentes partitions présentes dans notre disque :
$ fdisk -l image.disk
Disque image.disk : 50 GiB, 53687091200 octets, 104857600 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Type d'étiquette de disque : gpt
Identifiant de disque : 17D2441A-D62C-427F-BC1C-8B694294086E
Périphérique Début Fin Secteurs Taille Type
image.disk1 2048 4095 2048 1M Amorçage BIOS
image.disk2 4096 104855551 104851456 50G Système de fichiers Linux
Nous voyons ici que notre image disque comporte deux partitions, une partition d'amorçage BIOS, et une contenant un système de fichier Linux (très probablement ext4). Tentons à présent de monter cette partition pour pouvoir parcourir son contenu :
$ sudo mkdir /mnt/m
$ sudo mount -t ext4 -o loop,offset=2097152 image.disk /mnt/m
Étant donné que notre image disque contient deux partitions, nous sommes obligés ici d'indiquer l'offset de début de notre partition dans le fichier transmis à mount. Celui-ci est obtenu en multipliant l'offset de début indiqué par fdisk pour la partition ciblée (4096) à la taille d'un secteur sur le disque (512), ce qui donne 2 097 152 .
Puis nous pouvons parcourir librement le contenu de la partition montée :
$ cd /mnt/m
mdy@siftworkstation: /mnt/m
$ ls -al
total 4038784
drwxr-xr-x 24 root root 4096 déc. 11 2020 .
drwxr-xr-x 19 root root 4096 déc. 8 16:33 ..
drwxr-xr-x 2 root root 4096 déc. 5 2020 bin
drwxr-xr-x 3 root root 4096 déc. 11 2020 boot
drwxr-xr-x 2 root root 4096 déc. 5 2020 cdrom
drwxr-xr-x 4 root root 4096 févr. 3 2020 dev
Gardez cependant à l'esprit que le simple fait de lire un fichier modifiera des informations à propos de celui-ci, par exemple :
$ stat /etc./hosts
Fichier : hosts
Taille : 224 Blocs : 8 Blocs d'E/S : 4096 fichier
Périphérique : 713h/1811d Inœud : 1835722 Liens : 1
Accès : (0644/-rw-r--r--) UID : ( 0/ root) GID : ( 0/ root)
Accès : 2020-12-11 16:15:40.996000000 +0000
Modif. : 2020-12-05 08:36:46.450157258 +0000
Changt : 2020-12-05 08:36:46.450157258 +0000
Créé : -
$ cat /etc/hosts
127.0.0.1 localhost
[...]
$ stat /etc/hosts
Fichier : hosts
Taille : 224 Blocs : 8 Blocs d'E/S : 4096 fichier
Périphérique : 713h/1811d Inœud : 1835722 Liens : 1
Accès : (0644/-rw-r--r--) UID : ( 0/ root) GID : ( 0/ root)
Accès : 2022-01-05 20:22:21.025011907 +0000
Modif. : 2020-12-05 08:36:46.450157258 +0000
Changt : 2020-12-05 08:36:46.450157258 +0000
Créé : -
La date d'accès du fichier, qui fait partie des attributs des fichiers dans le système de fichier ext4, a été modifiée par notre accès en lecture. Nous ne pouvons ici plus savoir si ce fichier a été lu dans le cadre de l'attaque menée sur le système.
Pour palier à cela, nous pouvons monter le disque en lecture seule (read-only) :
$ sudo mount -t ext4 -o ro,loop,offset=2097152 "/media/mdy/Disque exte/image.disk" /mnt/
$ stat /etc./timezone
Fichier : timezone
Taille : 8 Blocs : 8 Blocs d'E/S : 4096 fichier
Périphérique : 713h/1811d Inœud : 1835770 Liens : 1
Accès : (0644/-rw-r--r--) UID : ( 0/ root) GID : ( 0/ root)
Accès : 2020-12-05 08:52:36.770945118 +0000
Modif. : 2020-12-05 08:52:36.774945114 +0000
Changt : 2020-12-05 08:52:36.774945114 +0000
Créé : -
$ cat /etc/timezone
Etc/UTC
$ stat /etc./timezone
Fichier : timezone
Taille : 8 Blocs : 8 Blocs d'E/S : 4096 fichier
Périphérique : 713h/1811d Inœud : 1835770 Liens : 1
Accès : (0644/-rw-r--r--) UID : ( 0/ root) GID : ( 0/ root)
Accès : 2020-12-05 08:52:36.770945118 +0000
Modif. : 2020-12-05 08:52:36.774945114 +0000
Changt : 2020-12-05 08:52:36.774945114 +0000
Créé :
Nous apprendrons plus loin dans cet article que l'attaque a eu lieu à une date ultérieure à la date d'accès du fichier /etc/timezone. Nous pouvons donc ici être relativement sûr que l'attaquant n'a pas consulté ce fichier. Cette information ne sert à rien ici, mais c'est un exemple pour montrer l'intérêt de conserver une trace dans son état d'origine autant que possible, et d'être conscient du fonctionnement de nos outils pour savoir quelles données risquent d'être modifiées par nos actions.
V. Étude des journaux d'évènements
Maintenant que nous avons un accès au disque dur, nous pouvons parcourir celui-ci et tenter de savoir ce qu'il s'est passé. Le fichier /etc./init.d/apache2.4.29 nous renseigne sur l'emplacement des configurations apache :
root@siftworkstation:/mnt/m/etc/init.d# cat apache2.4.29
[...]
HTTPD='/usr/local/apache2/bin/httpd'
#
# pick up any necessary environment variables
if test -f /usr/local/apache2/bin/envvars; then
. /usr/local/apache2/bin/envvars
fi
Les journaux du service web apache2 (/usr/local/apache2/logs/access.log) sont notamment intéressant :
On peut constater qu'il y a un trou au niveau des dates de journalisation. Cela peut être dû à une suppression intentionnelle de l'attaquant qui a souhaité effacer ses traces. Ce type d'action est référencé par la T1070.002 - Indicator Removal on Host: Clear Linux or Mac System Logs dans le framework MITRE ATT&CK.
Également, la configuration Apache nous apprend que le répertoire /home/ de l'utilisation deloin_c était exposé sur le service web :
root@siftworkstation:/mnt/m/usr/local/apache2/conf# grep "deloin_c" -A 5 httpd.conf
Alias "/log" "/home/deloin_c"
<Directory "/home/deloin_c">
Options Indexes FollowSymLinks
Require all granted
</Directory>
L'attaquant ayant compromis ce compte a donc pu s'en servir pour exposer des fichiers sur le service web, sans avoir besoin des droits du compte de service apache2. Intéressons nous maintenant à l'activité des comptes utilisateur, par exemple en regardant le contenu du fichier .bash_history des utilisateurs du système.
Sur les systèmes Linux, un fichier .bash_history est situé dans le /home/ de chaque utilisateur et contient l'historique des commandes saisies dans le terminal. Il n'a pas pour vocation première la journalisation dans un but d'investigation numérique puisqu'il peut être supprimé ou désactivé par l'utilisateur. Il est plus fréquemment utile lorsque l'on souhaite retrouver une commande saisie par le passé (Ctrl+R).
Le contenu du fichier /home/deloin_c/.bash_history est suspect :
root@siftworkstation:/mnt/m/home/deloin_c# cat .bash_history
[...]
echo hello >> test.txt
ls
cat test.txt
cp test.txt /usr/local/apache2/htdocs/Siemes/
vim /usr/local/var/log/carpediem.php
ls
ls -lha /usr/local/apache2/htdocs/Siemes/
ls -lh /usr/local/apache2/htdocs/Siemes/
ls -lh /usr/local/var/log/
chmod 777 /usr/local/var/log/carpediem.php
ls -lh /usr/local/var/log/
wget http://192.168.2.10/log
cat log
rm log
ls
ls -lh /usr/local/apache2/htdocs/Siemes/
ls -lh /usr/local/var/log/
ls
pwd
cp /home/deloin_c/test.txt /usr/local/apache2/htdocs/Siemes/
curl http://192.168.2.10/log/carpediem.php?cmd=cp+/home/deloin_c/test.txt+/usr/local/apache2/htdocs/Siemens
ls -lh /usr/local/apache2/htdocs/Siemes/
cat /proc/self/map
cat /proc/self/maps
cat /usr/local/apache2/logs/httpd.pid
cat /usr/local/apache2/logs/access_log
curl http://192.168.2.10/log/carpediem.php?cmd=/bin/bash
service apache2.4.29 graceful
logout
touch hello.txt
vim hello.txt
cat hello.txt
rm hello.txt
On remarque notamment différentes commandes visant à télécharger des fichiers (wget, curl) et à écrire ou modifier des fichiers dans le répertoire de travail d'apache2. Deux commandes nous interpellent plus particulièrement :
vim /usr/local/var/log/carpediem.php
curl http://192.168.2.10/log/carpediem.php?cmd=cp+/home/deloin_c/test.txt+/usr/local/apache2/htdocs/Siemens
On retrouve ici un élément caractéristique des webshells, l'utilisation d'un paramètre (cmd) contenant une commande système. Nous pouvons donc fortement supposer que le fichier PHP créé (carpediem.php) contienne du code PHP permettant d'exécuter des commandes système. Le nom du fichier carpediem.php est aussi peu commun, une rapide recherche sur internet nous oriente vers un exploit concernant une élévation de privilège locale sur Apache :
Si l'on regarde la date de dernière édition du fichier /home/deloin_c/.bash_history, on retrouve la date du 15/08/2020 :
root@siftworkstation:/mnt/m/home/deloin_c# ls -al
-rw------- 1 1012 1012 1284 août 15 2020 .bash_history
Ces différents constats nous permettent de répondre à la première question :
- La date vraisemblable d'intrusion : 15/08/2020
Un autre fichier intéressant est le fichier .viminfo :
root@siftworkstation:/mnt/m/home/deloin_c# cat .viminfo
# Marques dans le fichier :
'0 9 6 /usr/local/var/log/hello.html
|4,48,9,6,1607621460,"/usr/local/var/log/hello.html"
'1 52 0 /usr/local/var/log/carpediem.php
|4,49,52,0,1597511166,"/usr/local/var/log/carpediem.php"
'2 9 6 /usr/local/var/log/hello.html
|4,50,9,6,1607621460,"/usr/local/var/log/hello.html"
'3 536 25 /usr/local/apache2/conf/httpd.conf
|4,51,536,25,1597497150,"/usr/local/apache2/conf/httpd.conf"
'4 9 6 /usr/local/var/log/hello.html
|4,52,9,6,1607621460,"/usr/local/var/log/hello.html"
Le fichier .viminfo est créé automatiquement dans le /home/ de chaque utilisateur et permet d'historiser certains éléments comme les commandes saisies dans vim, les recherches faites dans les fichiers, les marques, etc.
Dans notre cas, on obtient le chemin absolu des fichiers modifiés par Mr Deloin (ou l'attaquant ayant compromis son compte) :
# Historique des marques dans les fichiers (les plus récentes en premier) :
/usr/local/var/log/hello.html
/usr/local/var/log/carpediem.php
/usr/local/apache2/conf/httpd.conf
~/index.php
/usr/local/var/log/index.php
~/hello.txt
L'attaquant semble avoir créé des fichiers dans /usr/local/var/log/ ainsi que dans le répertoire /home/ de l'utilisateur, or nous savons que le home de l'utilisateur était exposé sur le web, les fichiers PHP créés pouvaient donc y être interprétés par le service web. Avec les éléments recueillis, nous pouvons nous répondre à ces questions :
- Le nom du fichier ayant exploité la faille Apache : index.php
- Le dossier ayant servi de point d'entrée à l'attaquant : /home/deloin_c
Au passage, l'utilisation d'un exploit sur un système ou une application en vue d'élever ses privilèges est référencée par la T1068 - Exploitation for Privilege Escalation dans le framework MITRE ATT&CK.
VI. Récupération d'une preuve supprimée
Problème, lorsque l'on tente de lire ces fichiers, ils n'existent plus. Il semble donc que l'attaquant ayant utilisé ce compte utilisateur ait pris le soin de supprimer certaines informations. Nous allons tenter d'utiliser un outil de File Carving pour récupérer ces fichiers.
Le File Carving est le processus consistant à essayer de récupérer des fichiers en l'absence de leurs métadonnées (fichiers supprimés de la table de référence). Cela se fait en analysant les données brutes et en identifiant de quel format il peut s'agir (texte, exécutable, png, mp3, etc.). Cela peut être fait de différentes manières, mais la plus simple est de rechercher la signature de fichier ou les magic number qui marquent le début et/ou la fin d'un type de fichier particulier (lecture du contenu du disque en hexadécimal et marquage du début d'un fichier lorsque l'on rencontre un magic number). Nous avons déjà abordé les magics numbers dans l'article de cette même série : Forensic – SteerOnSomewhere : analyse de PDF et EXE malveillants
Nous utiliserons ici photorec :
Il nous faut ensuite sélectionner la partition à analyser dans l'image disque. Mais avant cela, nous allons faire un tour dans le paramètre File Opt (en bas) :
Ici nous allons pouvoir préciser à photorec quels sont les types de fichiers qui nous intéressent, nous sélectionnerons txt (qui comprend les extensions web) :
Pour faciliter le travail de photorec, nous lui précisons quel système de fichier est utilisé :
Et enfin, le dossier de sortie dans lequel positionner les fichiers retrouvés :
Après une vingtaine de minutes d'exécution, photorec a retrouvé plus de 60 000 fichiers, cela fait beaucoup trop pour une recherche manuelle. Mais l'on se souvient avoir observé cette commande :
curl http://192.168.2.10/log/carpediem.php?cmd=cp+/home/deloin_c/test.txt+/usr/local/apache2/htdocs/Siemens
Celle-ci nous a menés vers un exploit dont le code peut être trouvé ici. On sait donc que notre fichier contient au moins le mot CARPE par exemple. Utilisons à présent grep :
$ grep -ril "carpe" *
recup_dir.125/f92709184.php:o('CARPE (DIEM) ~ CVE-2019-0211');
recup_dir.125/f92709264.php:o('CARPE (DIEM) ~ CVE-2019-0211');
recup_dir.125/f92713296.php:o('CARPE (DIEM) ~ CVE-2019-0211');
recup_dir.14/f17105536.php:o('CARPE (DIEM) ~ CVE-2019-0211');
Nous avons identifié plusieurs fichiers parmi les 60 000 fichiers retrouvés par photorec. Une exploration de leur contenu nous en apprend plus sur ce qu'ils font et nous permet de répondre à notre dernière question :
$ grep "cmd" recup_dir.14/f17105536.php -C 5
$bucket = isset($_REQUEST['cmd']) ?
$_REQUEST['cmd'] :
"cp ./S7-300.pdf /usr/local/apache2/htdocs/Siemens/S7-300.pdf";
if(strlen($bucket) > $size_worker_score - 112)
{
o(
- La commande ayant été exécutée en root : cp ./S7-300.pdf /usr/local/apache2/htdocs/Siemens/S7-300.pdf
VII. Conclusion
Cette série d'articles sur le challenge Panic On Board proposé par le FIC/l'école EPITA est maintenant terminée. Comme dans toute analyse forensic, il est maintenant temps de résumer les différentes TTP (Tactics, techniques and procedures) utilisées par l'attaquant et identifiées dans notre analyse :
| Phase | ATT&CK | Nom |
|---|---|---|
| Initial Access | T1566.01 | Phishing : Spearphishing attachment |
| Execution | T1059.003 | Command and Scripting Interpreter: Windows Command Shell |
| Credential Access | T1552.001 | Unsecured Credentials: Credentials In Files |
| Persistence | T1078 | Valid Accounts |
| Impact | T0826 | Loss of Availability |
| Discovery | T1046 | Network Service Scanning |
| Execution | T1204.002 | User Execution: Malicious File |
| Defense Evasion | T1497.003 | Virtualization/Sandbox Evasion: Time Based Evasion |
| Defense Evasion | T1070.002 | Indicator Removal on Host: Clear Linux or Mac System Logs |
| Privilege Escalation | T1068 | Exploitation for Privilege Escalation |
Le résumé des TTP a plusieurs objectifs, il permet notamment de pouvoir rapidement corréler deux attaques en constatant que leur TTP sont similaires, ce qui peut être utile pour l'attribution d'une attaque ou simplement pour noter qu'il est probable que deux attaques aient été opérées par un même attaquant.
Dans les rapports d'analyse forensic, il est aussi courant de trouver un ensemble d'IOC (Indicator of Compromission) qui peuvent être des URL, domaines, IP, noms d'exécutable, de services, etc. La synthèse de ces IOC permet elle aussi de pouvoir faire une corrélation entre différentes attaques pour lesquelles on retrouverait les mêmes IOC. Ils permettent également de mettre à jour les systèmes de détection et de prévention (ex : mettre en blacklist une adresse IP, ajouter une alerte de détection pour un certains nom d'exécutable sur les solutions antivirales) ou d'effectuer des recherches ciblées sur les journaux d'évènements du SI (qui sont centralisés bien évidemment 🙂 ).
J'espère que cette suite d'articles vous a plu, il existe encore de nombreux challenges de ce type disponibles sur le site de l'EPITA et je ne peux que vous conseiller d'aller y jeter un œil :). C'est par ici : Challenges Forensic
