/ ndh2k17

Nuit du Hack XV - Qualifications - Bender Bending Rodriguez (FOR 75)

Énoncé

The new co-worker looks weird. He behaves like he is hiding something on his computer. We discreetly dumped the memory of his computer from SSH, in the hope to learn more. But we don't know much what to do with it. Can you help us?

The system is an Ubuntu 16.04, x64

Résolution

Nous avons pour ce challenge, un fichier dump.tar.gz. L'énoncé nous met sur la piste d'un dump mémoire, réalisé sur une machine Linux, à cause de la présence d'un serveur SSH.

Mais, en utilisant nos outils classiques d'analyse de dump tel que volatility avec une installation basique, on se rend compte qu'il manque le profil nécessaire pour l'analyse. Après quelques recherches, un GitHub est disponible avec des profils Linux/Mac déjà préparés.

L'ajout des profils est très simple, il suffit de placer le fichier compressé dans le dossier /usr/lib/python2.7/site-packages/volatility/plugins/overlays/linux, puis de vérifier la présence du profil avec la commande volatility --info et constater :

$ Profiles
--------
LinuxUbuntu16041x64   - A Profile for Linux Ubuntu16041 x64
LinuxUbuntu1604x64    - A Profile for Linux Ubuntu1604 x64

On installe les profils correspondants à Ubuntu 16.04. Mais en essayant de lancer une commande pour analyser le dump, rien ne se passe. En regardant plus en détails, on se rend compte que ces profils sont compatibles avec un kernel spécifique. Ceux disponibles sur GitHub ont très probablement été crééés avec le kernel par défaut sur une installation fraîche.

En faisant une rapide recherche des les chaînes de caractère dans le dump, on se rend compte que la version du kernel est elle bien différente de celle des profils :

$ strings dump.img| grep "Linux version" 
Linux version 4.4.0-57-generic

Il faut donc ici créer son propre profil Volatility afin de pouvoir analyser le dump, avec de nombreuses ressources en ligne disponible.

On installe donc une VM Ubuntu 16.04, en n'oubliant pas d'installer les packages suivants :

linux-image-4.4.0-57-generic
linux-headers-4.4.0-57-generic
volatility-tools

Après redémarrage, on vérifie la version du noyau utilisée avec la commande uname -r. Puis on créé le profil adapté à notre OS et noyau.

(/usr/src/volatility-tools/linux)$ make
make -C //lib/modules/4.4.0-57-generic/build CONFIG_DEBUG_INFO=y M="/usr/src/volatility-tools/linux" modules
make[1]: Entering directory '/usr/src/linux-headers-4.4.0-57-generic'
  CC [M]  /usr/src/volatility-tools/linux/module.o
  Building modules, stage 2.
  MODPOST 1 modules
  CC      /usr/src/volatility-tools/linux/module.mod.o
  LD [M]  /usr/src/volatility-tools/linux/module.ko
make[1]: Leaving directory '/usr/src/linux-headers-4.4.0-57-generic'
dwarfdump -di module.ko > module.dwarf
make -C //lib/modules/4.4.0-57-generic/build M="/usr/src/volatility-tools/linux" clean
make[1]: Entering directory '/usr/src/linux-headers-4.4.0-57-generic'
  CLEAN   /usr/src/volatility-tools/linux/.tmp_versions
  CLEAN   /usr/src/volatility-tools/linux/Module.symvers
make[1]: Leaving directory '/usr/src/linux-headers-4.4.0-57-generic'

Sans erreurs, on peut continuer en créant maintenant notre profil pour Volatility :

$ zip Ubuntu1604ndh.zip /usr/src/volatility-tools/linux/module.dwarf /boot/System.map-4.4.0-57-generic

Puis l'installer. Maintenant, l'analyse devrait pouvoir fonctionner :

$ volatility -f dump.img --profile=LinuxUbuntu1604ndhx64 linux_banner
Volatility Foundation Volatility Framework 2.6
Linux version 4.4.0-57-generic (buildd@lgw01-54) (gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) ) #78-Ubuntu SMP Fri Dec 9 23:50:32 UTC 2016 (Ubuntu 4.4.0-57.78-generic 4.4.35)

Bingo ! On peut maintenant analyser le dump mémoire comme d'habitude, en utilisant les commandes linux_pslist, linux_lsof, linux_psaux, ...

On peut identifier un programme python dans la liste des processus utilisateurs et on trouve un résultat intéressant dans la sortie de la commande linux_lsof.

$ volatility -f dump.img --profile=LinuxUbuntu1604ndhx64 linux_lsof
[...]
0xffff88007b496900 python      4203       29 /tmp/test.wav
[...]

On peut récupérer le fichier avec la commande linux_find_file :

$ volatility -f dump.img --profile=LinuxUbuntu1604ndhx64 linux_find_file -F "/tmp/test.wav"
Volatility Foundation Volatility Framework 2.6
Inode Number                  Inode File Path
---------------- ------------------ ---------
         1441801 0xffff88007c65de38 /tmp/test.wav

On tombe sur un fichier audio de mauvaise qualité mais nous disant "The Flag is...", nous sommes sur la bonne voie ! Puis en écoutant le fichier de manière attentive...

Flag : xaach1Xay8G