halpomeranz/lmgScript d'automatisation de la capture et de l'analyse de la mémoire Linux
Linux Memory Grabber Un script pour extraire la mémoire Linux et créer des profils Volatility(TM). Hal Pomeranz ([email protected]), 2020-02-01
« Si j’ai vu plus loin, c’est en me tenant sur les épaules de géants. » ~ Isaac Newton
De nombreuses personnes méritent des remerciements pour avoir rendu ce petit outil possible :
-- Les braves gens de Microsoft pour avoir rendu AVML disponible
-- Joe Sylve pour son travail sur LiME
-- Toute l’équipe de développement de Volatility(TM) pour son travail continu. Je tiens à remercier particulièrement Andrew Case qui a répondu à plusieurs questions épineuses que je lui ai posées lors du développement de mon outil.
-- David Anderson pour son soutien continu à libdwarf et dwarfdump
-- Matt Suiche de MoonSols. Lorsque je concoctais mon outil, mon objectif de conception était « le rendre aussi facile à utiliser que DumpIt » (si vous devez capturer la mémoire Windows, je ne connais pas d’outil plus facile à utiliser). Merci donc pour l’inspiration, Matt !
-- Les personnes qui ont fourni des idées et du code pour améliorer l’outil :
Julien – Répertoires de sortie/construction alternatifs et étiquettes d’identifiant de cas,
abandon si non exécuté en tant que root
Jonathon Poling – Idées similaires à celles de Julien
Jeff Bryner – Création de fichiers volatilityrc pour chaque capture
La communauté est meilleure grâce à tous ces efforts. J’ai choisi de rendre mon outil disponible sous la licence Creative Commons « Attribution » (CC BY), afin de le rendre aussi largement disponible que possible.
Pour analyser la mémoire Linux, vous devez d’abord être capable de capturer la mémoire Linux. AVML fonctionne très bien, mais si votre système ne possède pas /proc/kcore ou /dev/crash, vous aurez besoin du Linux Memory Extractor (LiME) de Joe Sylve. Mais vous devez disposer d’un module LiME compilé pour le noyau du système où vous souhaitez extraire la RAM.
Volatility(TM) est excellent pour analyser les images mémoire Linux. Mais il a besoin d’un profil correspondant au système sur lequel la mémoire a été capturée. Construire un profil signifie compiler un programme C sur le système approprié et utiliser dwarfdump pour obtenir les adresses des structures de données importantes du noyau. Vous avez également besoin d’une copie du fichier System.map du répertoire /boot.
Maintenant, si vous avez la chance d’avoir un duplicate de votre système cible, vous pouvez construire le profil Volatility(TM) sur le clone et, si nécessaire, construire LiME pour capturer et analyser la mémoire de votre cible. Mais il existe de nombreuses situations où un duplicate de votre système cible n’est pas disponible. Vous pouvez donc être amené à construire votre profil Volatility(TM) et LiME sur votre machine cible.
Et ce n’est pas pour les âmes sensibles. Plusieurs étapes sont nécessaires, et certaines commandes Linux assez basiques sont impliquées. Mon objectif était de créer un package pouvant être installé (par un expert) sur une clé USB et distribué à des agents sur le terrain. L’utilisateur de la clé USB devrait pouvoir brancher la clé, exécuter une seule commande, et réussir à acquérir une image mémoire de la machine cible ainsi qu’un profil Volatility(TM) fonctionnel. Le résultat est mon script lmg (Linux Memory Grabber).
Si vous êtes un puriste de la forensique, cet outil n’est probablement pas fait pour vous. Examinons quelques-unes des façons dont mon outil interagit avec le système cible :
Support amovible – L’outil est conçu pour être exécuté depuis un périphérique USB portable tel qu’une clé USB. Vous allez brancher un périphérique accessible en écriture sur votre système cible, où il pourrait potentiellement être ciblé par des utilisateurs malveillants ou des logiciels malveillants présents sur le système. Le fait de brancher le périphérique sur le système va modifier l’état de la machine (par exemple, créer des entrées de journal, des entrées mtab, etc.). Si le périphérique n’est pas monté automatiquement par le système d’exploitation, l’utilisateur doit monter manuellement le périphérique via un shell root.
Compilation – La création d’un profil Volatility(TM) implique de compiler du code sur la machine cible. Il en va de même pour la construction de LiME lorsque AVML ne fonctionne pas. Donc gcc sera exécuté, des fichiers d’en-tête lus, des bibliothèques liées, etc. lmg tente de minimiser l’impact sur le système de fichiers de la machine cible en définissant TMPDIR sur un répertoire du périphérique USB à partir duquel lmg s’exécute. Cela signifie que les fichiers intermédiaires créés par le compilateur seront écrits sur la clé USB plutôt que sur le système de fichiers local de la machine cible.
Dépendances – Pour compiler du code noyau sous Linux, la machine cible a besoin d’un environnement de développement fonctionnel avec gcc, make, etc. et tous les fichiers d’en-tête et bibliothèques partagées appropriés. En particulier, les fichiers d’en-tête du noyau doivent être présents sur la machine locale. Ces dépendances peuvent ne pas exister sur la cible. Dans ce cas, l’utilisateur est confronté au choix d’installer les dépendances appropriées (si possible) ou de ne pas pouvoir construire le profil Volatility(TM) pour le système.
Logiciels malveillants – lmg utilise /bin/bash, gcc, zip et une multitude d’autres programmes de la machine cible. Si le système a été compromis, les applications utilisées par lmg peuvent ne pas être fiables. Une solution plus complète consisterait à créer un environnement d’exécution sécurisé pour lmg sur le périphérique USB portable, mais cela dépassait le cadre de cette preuve de concept initiale.
Mémoire – Toutes les commandes exécutées modifieront la mémoire du système cible. Le fait de capturer la RAM créera toujours des artefacts, mais dans ce cas, une compilation extensive, un accès au système de fichiers, etc. s’ajoutent à l’exécution d’un extracteur de RAM.
Cela étant dit, lmg est un outil très pratique pour permettre à des agents moins expérimentés de capturer des données d’analyse mémoire utiles à partir de systèmes cibles.
Notez que si AVML échoue, lmg cherchera un module LiME déjà existant sur le périphérique USB qui correspond à la version du noyau et à l’architecture processeur de la machine cible. S’il est trouvé, lmg ne prendra pas la peine de recompiler. De même, vous pouvez choisir de ne pas faire créer le profil Volatility(TM) pour la cible afin de minimiser l’impact sur le système cible.
lmg utilise des chemins relatifs lors de l’invocation de programmes comme gcc et zip. Donc, si vous souhaitez exécuter ces programmes depuis un support alternatif, mettez simplement à jour $PATH de manière appropriée avant d’exécuter lmg.
Tout d’abord, préparez une clé USB selon les instructions du document INSTALL fourni avec lmg.
Lorsque vous souhaitez acquérir de la RAM, branchez la clé USB sur votre système cible. Sur la plupart des systèmes Linux, les nouveaux périphériques USB seront montés automatiquement sous /media. Supposons que le vôtre se retrouve sous /media/LMG.
Maintenant, en tant que root, exécutez « /media/LMG/lmg ». C’est le mode interactif et l’utilisateur sera invité à confirmer avant que lmg ne construise un module LiME pour le système et/ou crée un profil Volatility(TM). Si vous ne voulez pas de confirmation, utilisez « /media/LMG/lmg -y ».
Tout le reste est automatisé. Après l’exécution du script, vous aurez un nouveau répertoire sur la clé USB nommé
« .../capture/<nom_hôte>-AAAA-MM-JJ_hh.mm.ss »
lmg prend en charge une option -c pour spécifier un nom de répertoire d’identifiant de cas à utiliser à la place du répertoire par défaut « <nom_hôte>-AAAA-MM-JJ_hh.mm.ss ».
Quel que soit le nom de répertoire utilisé, ce répertoire contiendra :
<nom_hôte>-AAAA-MM-JJ_hh.mm.ss-memory.lime – la capture RAM <nom_hôte>-AAAA-MM-JJ_hh.mm.ss-profile.zip – profil Volatility(TM) <nom_hôte>-AAAA-MM-JJ_hh.mm.ss-bash – copie du /bin/bash cible volatilityrc – fichier de configuration Volatility prototype
Le fichier volatilityrc définit les emplacements appropriés pour la mémoire capturée et le plugin. Voir l’EXEMPLE D’UTILISATION ci-dessous pour savoir comment utiliser ce fichier.
La copie de /bin/bash est utile pour déterminer l’adresse de la structure de données de l’historique du shell dans la mémoire des processus bash dans la capture mémoire. Voir https://github.com/volatilityfoundation/volatility/wiki/Linux-Command-Reference#linux_bash pour plus de détails sur l’utilisation de cet exécutable (ou référez-vous à l’EXEMPLE D’UTILISATION ci-dessous).
Notez qu’il peut y avoir des moments où vous ne souhaitez pas écrire de données sur le support à partir duquel vous exécutez lmg – par exemple si les outils lmg se trouvent sur un support en lecture seule comme un DVD-ROM. lmg prend en charge une option -d pour spécifier un répertoire de sortie différent. Par défaut, toute la compilation se fera dans le répertoire cible, mais l’utilisateur peut spécifier un répertoire de compilation alternatif avec -B.
Voici un exemple d’utilisation de l’outil lmg, qui inclut l’utilisation de Volatility(TM) directement depuis la clé USB pour analyser l’image capturée. Sur ma machine de test, la clé USB était sur /dev/sdb et n’était pas montée automatiquement par mon système d’exploitation. J’ai donc tout fait manuellement.
[root@localhost ~]$ sudo -s [sudo] password for lab: [root@localhost lab]# mkdir -p /mnt/usb [root@localhost lab]# mount /dev/sdb1 /mnt/usb
[root@localhost lab]# /mnt/usb/lmg -y AVML is /mnt/usb/avml/avml-x86_64 Dumping memory in "lime" format to /mnt/usb/capture/localhost.localdomain-2020-02-01_08.16.55 This could take a while...Done! Grabbing a copy of /bin/bash...Done! Writing volatilityrc to /mnt/usb/capture/localhost.localdomain-2020-02-01_08.16.55...Done! make -C //lib/modules/4.18.0-147.3.1.el8_1.x86_64/build M="/mnt/usb/volatility-master/tools/linux" clean make[1]: Entering directory '/usr/src/kernels/4.18.0-147.3.1.el8_1.x86_64' make[1]: Leaving directory '/usr/src/kernels/4.18.0-147.3.1.el8_1.x86_64' rm -f module.dwarf make -C //lib/modules/4.18.0-147.3.1.el8_1.x86_64/build CONFIG_DEBUG_INFO=y M="/mnt/usb/volatility-master/tools/linux" modules make[1]: Entering directory '/usr/src/kernels/4.18.0-147.3.1.el8_1.x86_64' CC [M] /mnt/usb/volatility-master/tools/linux/module.o Building modules, stage 2. MODPOST 1 modules WARNING: modpost: missing MODULE_LICENSE() in /mnt/usb/volatility-master/tools/linux/module.o see include/linux/module.h for more information CC /mnt/usb/volatility-master/tools/linux/module.mod.o LD [M] /mnt/usb/volatility-master/tools/linux/module.ko make[1]: Leaving directory '/usr/src/kernels/4.18.0-147.3.1.el8_1.x86_64' dwarfdump -di module.ko > module.dwarf make -C //lib/modules/4.18.0-147.3.1.el8_1.x86_64/build M="/mnt/usb/volatility-master/tools/linux" clean make[1]: Entering directory '/usr/src/kernels/4.18.0-147.3.1.el8_1.x86_64' CLEAN /mnt/usb/volatility-master/tools/linux/.tmp_versions CLEAN /mnt/usb/volatility-master/tools/linux/Module.symvers make[1]: Leaving directory '/usr/src/kernels/4.18.0-147.3.1.el8_1.x86_64' adding: module.dwarf (deflated 90%) adding: boot/System.map-4.18.0-147.3.1.el8_1.x86_64 (deflated 79%)
[root@localhost lab]# cd /mnt/usb/capture/localhost.localdomain-2020-02-01_08.16.55 [root@localhost localhost.localdomain-2020-02-01_08.16.55]# ls localhost.localdomain-2020-02-01_08.16.55-bash localhost.localdomain-2020-02-01_08.16.55-memory.lime localhost.localdomain-2020-02-01_08.16.55-profile.zip volatilityrc [root@localhost localhost.localdomain-2020-02-01_08.16.55]# ../../volatility-master/vol.py --conf-file=volatilityrc linux_banner Volatility Foundation Volatility Framework 2.6.1 Linux version 4.18.0-147.3.1.el8_1.x86_64 ([email protected]) (gcc version 8.3.1 20190507 (Red Hat 8.3.1-4) (GCC)) #1 SMP Fri Jan 3 23:55:26 UTC 2020
[root@localhost localhost.localdomain-2020-02-01_08.16.55]# gdb localhost.localdomain-2020-02-01_08.16.55-bash GNU gdb (GDB) Red Hat Enterprise Linux 8.2-6.el8_0 Copyright (C) 2018 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/. Find the GDB manual and other documentation resources online at: http://www.gnu.org/software/gdb/documentation/.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from localhost.localdomain-2020-02-01_08.16.55-bash...Missing separate debuginfo for /mnt/usb/capture/localhost.localdomain-2020-02-01_08.16.55/localhost.localdomain-2020-02-01_08.16.55-bash
Try: dnf --enablerepo='debug' install /usr/lib/debug/.build-id/b6/858d77c486b7b596f22956149bbc9f8058d98d.debug
Reading symbols from .gnu_debugdata for /mnt/usb/capture/localhost.localdomain-2020-02-01_08.16.55/localhost.localdomain-2020-02-01_08.16.55-bash...(no debugging symbols found)...done.
(no debugging symbols found)...done.
(gdb) disass history_list
Dump of assembler code for function history_list:
0x00000000000ccea0 <+0>: endbr64
0x00000000000ccea4 <+4>: mov 0x24b09d(%rip),%rax # 0x317f48
0x00000000000cceab <+11>: retq
End of assembler dump.
(gdb) quit
[root@localhost localhost.localdomain-2020-02-01_08.16.55]# ../../volatility-master/vol.py --conf-file=volatilityrc linux_bash -H 0x317f48
Volatility Foundation Volatility Framework 2.6.1
Pid Name Command Time Command
13822 bash 2020-01-30 20:25:39 UTC+0000 uname -a 13822 bash 2020-01-30 20:25:39 UTC+0000 ls 13822 bash 2020-01-30 20:25:39 UTC+0000 sudo -s 13822 bash 2020-01-30 20:25:39 UTC+0000 fg [... more output not shown ...]