Volatilisons Linux : partie 2

1. Introduction

Avant d'entamer l'analyse, je vais revenir rapidement sur l'acquisition. Dans la partie 2.2 de l'article précédent, un teaser présentait la phrase suivante : « Sachez que certaines personnes travaillent actuellement sur une méthode de chargement d'un module pré-compilé et ce quelle que soit la version du noyau ». Ce travail a finalement abouti et a été présenté à Amsterdam à la première édition européenne du DFRWS. Le but de l'article n'est pas de présenter le fonctionnement complet du projet. Brièvement, la première étape repose sur la possibilité de parasiter un module déjà présent sur le système grâce au fait qu'un module noyau soit un objet ELF et puisse donc être lié à d'autres objets. Le lecteur intéressé pourra se délecter du papier intitulé « Robust Linux memory acquisition with minimal target impact », coécrit par Johannes Stüttgen et Michael Cohen ou bien regarder la présentation, les deux étant disponibles sur le site de la conférence [DFRWS14]. Pour les plus impatients, le code est accessible sur Google code [LMAP].

Petit bémol cependant, car Volatility ne supporte pas actuellement le format de fichier résultant de cette acquisition qui n'est autre qu'un fichier de type ELF64. Je ne doute pas que les développeurs de Volatility fourniront prochainement le module gérant cet addrspace mais en attendant, l'acquisition est exploitable au travers de rekall, le fork de Volatility. Le projet ressemble beaucoup à Volatility, mais il existe de subtiles différences internes.

Revenons à nos moutons : l'analyse d'une acquisition mémoire GNU/Linux avec Volatility. L'objectif est de présenter les différentes commandes implémentées dans le projet et permettant de mener à bien une analyse, que ce soit la récupération des différents processus, l'obtention des connexions réseaux créées ou, de la potentielle présence de rootkits. Afin de mettre en contexte les différentes commandes, l'article sera basé sur plusieurs codes permettant d'exploiter un système comme le ferait une personne malveillante.

2. Généralités

2.1 Les informations présentées

L'article précédent présentait les méthodes d'acquisition de la mémoire volatile d'un système GNU/Linux, la création d'un profil, son exploitation à l'aide de Volatility et la manière dont il était utilisé, pour présenter enfin le fonctionnement des Address Space. La suite de l'article va se concentrer sur les commandes utilisables sur une acquisition d'un système GNU/Linux en suivant la même catégorisation que la documentation en ligne sur le wiki du projet [VOLINUX] tout en expliquant sur quelles informations Volatility se base pour afficher ses résultats. Ainsi les informations suivantes seront présentées :

- les informations relatives au système ;

- l'analyse des processus ;

- les objets du noyau ;

- les informations relatives au réseau ;

- les détections de codes malicieux.

2.2 L'utilisation du profil et l'interprétation des données

La majorité des informations extraites par Volatility résulte de l'utilisation des symboles du noyau présents dans le fichier System.map. Si vous lisez le code source des différentes commandes, vous verrez que la majorité d'entre elles utilise la fonction get_symbol(), implémentée dans le fichier volatility/plugins/overlays/linux/linux.py, qui retourne l'adresse du symbole souhaité. Ce symbole est ensuite interprété par l'instanciation d'un objet Object utilisant la description de la structure au format dwarf comme présenté dans l'article précédent. Dans la suite de l'article, le symbole associé à une commande, et donc à l'information extraite, sera détaillé.

2.3 L'invocation des commandes

L'invocation des commandes relatives à l'analyse d'un système GNU/Linux est similaire à celle utilisée pour Windows. La seule différence est l'utilisation du préfixe linux. De manière générale, l'invocation d'une commande Volatility se fait comme suit lorsque l'on se trouve à la racine des sources du projet :

- --profile correspond au profil qui doit être utilisé par Volatility pour être en mesure d'interpréter les données. Il est possible de consulter la liste des profils en exécutant la commande python vol.py –info | less et de se rendre à la section Profiles.

- -f permet de fournir le chemin vers l'acquisition mémoire à analyser. Il peut être relatif ou absolu.

- commande correspond à la commande à utiliser. Il est possible de les lister en exécutant python vol.py --info | grep linux_

Des options supplémentaires peuvent être fournies pour, par exemple, activer le debug, utiliser un cache pour certaines informations récurrentes, paramétrer la timezone, etc. Le lecteur curieux se référera à la documentation générale [VOLUSAGE].

2.4 Practice yourself

Après ce rappel, il est temps de présenter les différentes commandes proposées. Pour vous exercer, de l'acquisition à l'analyse, une machine virtuelle, créée avec VirtualBox, est mise à votre disposition [VBOX]. Celle-ci est basée sur un système Debian Wheezy (7.5) en 64 bits. Le mot de passe du compte root est toor. À la racine du compte utilisateur misc (mot de passe misc), se trouvent les répertoires et fichiers suivants :

- suterusu : qui correspond au code open source d'un rootkit permettant de cacher des processus ou des connexions réseaux ainsi que de poser des hooks syscall ou de faire du keylogging. Au début de la rédaction de l'article, le code source accessible sur GitHub [SUTERUSU] a été modifié dans la machine virtuelle afin de présenter les mécanismes de détection de Volatility version 2.3.1. En effet, les techniques de hooks employées par ce rootkit n'étaient pas détectées par la version 2.3.1. Depuis la finalisation de l'article, la version 2.4 est disponible et détecte désormais les mécanismes utilisés par suterusu. Le lecteur est donc invité à compiler lui même la dernière version pour le constater.

- profile : contient le code permettant de générer le profil de manière automatisée. Il suffit d'exécuter la commande make dans ce répertoire.

- lime-forensics-1.1-r17 : contient le code du module noyau pour faire l'acquisition comme présentée dans l'article précédent.

Pour accéder simplement à l'acquisition, le script mount_sf.sh permet de monter un répertoire partagé avec le système hôte. Avant de lancer le script, il faut ajouter le répertoire en question à travers VirtualBox et associer au chemin en question le nom vbox comme sur la figure 1. Le point de montage dans la machine virtuelle se situe dans le répertoire share.

 

 

3. Informations du système

La première étape consiste à obtenir les informations de base sur le système. Cela permet de s'assurer que c'est la bonne machine qui est ciblée. La première commande à lancer affiche la version du système par le biais de la commande linux_banner qui récupère l'adresse du symbole éponyme et affiche la chaîne de caractères qui s'y trouve :

L'obtention des informations relatives au CPU résulte de l'exécution de la commande linux_cpuinfo. Cette commande récupère le symbole cpu_info, puis selon le type d'architecture (mono ou multi cpu) va récupérer différentes structures pour extraire les informations :

Avant de travailler sur les processus et les différentes zones mémoire, il peut être intéressant de regarder du côté des logs du noyau grâce à la commande linux_dmesg. Encore une fois, le symbole éponyme est utilisé. Cependant, il existe une différence depuis l'apparition des noyaux 3.0. En effet, ce n'est plus un tableau de type char, mais des structures consécutives de type log qui sont utilisées. L'exécution de cette commande permet, par exemple, d'obtenir les paramètres fournis au noyau ou encore de voir l'activité des points de montage physique en recherchant la chaîne sda dans le log grâce à grep comme dans le listing suivant :

4. Analyse des processus

La majorité des commandes relatives aux processus repose sur l'utilisation de la structure task_struct, définie dans include/linux/sched.h et présentée en figure 5. Elle est équivalente à la structure Eprocess pour Windows. Cette structure de données représente un processus dans le noyau Linux et contient des informations simples comme son nom, son état actuel, son uid, gid et des informations plus complexes telles que les allocations mémoires ou les descripteurs de fichiers ouverts.

Chaque structure task_struct contient un champ tasks de type list_head. Ce dernier type est au cœur du mécanisme officiel de gestion des listes chaînées dans le noyau Linux. Cette structure de listes chaînées contient les champs prev et next qui, dans le contexte d'une task_struct, pointeront respectivement sur la task_struct précédente et suivante. La gestion de ces listes chaînées est directement prise en compte par Volatility avec une possibilité d'itération par boucle for sur les structures contenant une list_head.

4.1 Lister les processus

Comment récupérer la liste des processus à partir d'une acquisition mémoire ? Pour comprendre le cheminement, un rappel sur l'initialisation d'un système GNU/Linux s'impose. Au cours de l'initialisation du noyau, l'ancêtre de tous les processus, le processus 0 ou idle process aussi appelé swapper process, est créé. Contrairement à tous les autres processus, ses structures sont allouées de manière statique. Parmi ces structures, celle qui nous intéresse est accessible à travers la variable init_task qui correspond, vous l'aurez deviné, à une task_struct.

Volatility récupère l'adresse du symbole init_task pour ensuite accéder à la liste des processus. C'est précisément le mécanisme implémenté par la commande linux_pslist. L'extrait de code suivant est implémenté dans la méthode calculate() du fichier volatility/plugins/linux/pslist.py.

Le résultat de cette commande est le suivant :

Vous noterez l'absence du processus swapper (processus 0) qui est un choix de l'équipe du projet. La première colonne correspond à l'adresse logique de l'objet task_struct, suivie du nom, du pid, uid et gid du processus par l'utilisation des membres comm, pid, uid et gid respectivement. La colonne DTB, pour Directory Table Base, correspond à l'adresse physique de la base de la table de répertoire des pages utilisée par le mécanisme de pagination pour traduire une adresse linéaire vers une adresse physique. La traduction d'adresse logique à linéaire repose sur le mécanisme de segmentation. C'est cette valeur qui est mise dans le registre de contrôle CR3 de la CPU lors d'un changement de contexte de processus. Cette adresse est associée au membre task_struct.mm.pgd. Cette structure sera détaillée dans une autre section de l'article ayant trait à l'accès des zones mémoire.

Dans l'exemple précédent, vous aurez remarqué que la colonne DTB pour le processus kthreadd est vide. Cela vient du fait que c'est un thread noyau qui utilise donc l'espace d'adressage du noyau. Ce qu'il se passe en réalité, c'est qu'un thread noyau se voit réattribuer l'espace d'adressage du dernier processus actif étant donné que l'espace d'adressage noyau est commun à tous les processus.

La dernière colonne fournit l'information temporelle de démarrage du processus grâce au membre start_time.

Il est possible d'enrichir les résultats de la commande précédente en affichant les arguments fournis au processus grâce à la commande linux_psaux qui reproduit le comportement de la commande ps aux. Les arguments fournis à un processus sont stockés dans un tampon accessible à l'adresse linéaire task_struct.mm.arg_start, d'une taille de task_struct.mm.arg_end.

Pour finir, il est possible de présenter la relation des processus sous forme d'arborescence. La méthode consiste à utiliser les membres children pour traverser les fils et sibling pour itérer sur les processus de même niveau grâce à la commande linux_pstree :

4.2 Espace d'adressage

Les sections suivantes présentent les commandes et structures utilisées pour récupérer l'espace mémoire d'un processus utilisateur. Le noyau représente celles-ci avec une structure appelée Memory Descriptor contenant toutes les informations relatives à l'espace d'adressage. Cette structure est représentée par mm_struct déclarée dans linux/sched.h. Elle est directement accessible depuis la task_struct par le membre mm. Le lecteur attentif aura remarqué que cette structure est aussi utilisée par la commande linux_psaux.

4.2.1 Répertoire des tables de page

À partir du membre mm, il est possible d'accéder à l'adresse physique pointant à la base de la page globale de répertoire par le biais du membre pgd présenté en section 4.1. L'article précédent expliquait que Volatility implémente les différents systèmes de translation d'adresse et notamment celui de la pagination, utilisé par la commande memmap, qui permet d'obtenir les pages physiques propres au processus. La sortie de la commande présentée ci-après affiche pour chaque processus les adresses virtuelles, physiques et la taille de chaque page allouée. Il est possible de filtrer un processus donné en renseignant l'argument -p suivi du PID en question.

Il est possible d'obtenir des informations plus précises concernant les différentes allocations mémoire d'un processus en utilisant le mécanisme d'allocation des ressources mémoire, lesVirtual Memory Area (VMA).

4.2.2 Virtual Memory Area

Une autre façon d'accéder aux différentes zones de l'espace d'adressage d'un processus consiste à utiliser le membre mmap qui pointe sur la tête de la liste chaînée d'une structure VMA et représentée par une structure vm_area_struct définie dans linux/mm_types.h. Celle-ci représente une zone de mémoire unique dans un espace d'adressage donné (un processus). Une VMA peut représenter différents types de zones mémoire tels qu'un fichier mappé en mémoire ou la pile d'un processus utilisateur. Une zone est définie par l'intervalle représenté par les membres vm_start (inclusif) et vm_end (exclusif). C'est à partir de cette structure qu'il est également possible de connaître le chemin vers les fichiers mappés en mémoire en utilisant le membre vm_file de type file. Si ce pointeur n'est pas nul, il est possible d'accéder aux informations du fichier par l'intermédiaire du champ f_path.

Cette structure est utilisée par la commande linux_proc_maps qui affiche les informations pour chaque VMA d'un processus. Le résultat de la commande affiche le PID, l'adresse linéaire de début et de fin de la VMA, les différents flags qui lui sont associés (lecture, écriture, exécution). Si la région correspond à un fichier mappé en mémoire, le champ vm_pgoff correspond à l'offset dans le fichier en question. Sont ensuite affichés le numéro de major et minor du pilote, le numéro d'inode associé au fichier et enfin son nom. Lorsque la zone fait partie du tas ou de la pile, le nom associé sera respectivement [heap] et [stack]. Il est possible d'afficher uniquement les VMA pour un processus donné en passant le PID à l'argument -p.

Si vous souhaitez accéder au contenu d'une VMA, il faut utiliser la commande linux_dump_map qui prend en paramètre le numéro de processus avec l'argument -p, l'adresse de la VMA à récupérer, préalablement fournie par linux_proc_map, avec l'argument -s et enfin le nom du répertoire où le fichier sera extrait avec -D. Le fichier créé a pour nomenclature task.<pid>.<vma_addr>.vma.

4.3 Lister les fichiers ouverts

La liste des fichiers ouverts par tous les processus s'obtient par la commande linux_lsof. Elle utilise le membre files de la structure task_struct, de type files_struct permettant de pointer sur un tableau de file descriptors (struct fdtable *fdt). Chaque entrée de ce tableau pointe sur une structure de type file. La boucle est bouclée, il est maintenant possible de savoir à quel fichier correspond un fd ouvert ! Pour travailler uniquement sur un processus donné, l'argument -p suivi du PID peut être utilisé.

5. Modules noyau

Un module noyau est représenté par la structure module définie dans le fichier linux/module.h. Les deux commandes suivantes utilisent des champs de cette structure pour extraire les informations voulues.

5.1 Lister les modules

La liste des modules actuellement chargés dans l'espace mémoire noyau s'obtient en exécutant la commande linux_lsmod. Celle-ci récupère l'adresse du symbole module, donnant accès au premier module puis parcourt la liste chaînée des modules représentée par le membre list de la structure module. Cette commande peut recevoir deux arguments optionnels :

- -S pour afficher les différentes sections du module par l'utilisation de la structure détaillant les attributs de chacune d'entre elles : module_sect_attrs définie dans kernel/module.c. Celle-ci contient un membre nsections représentant la taille d'un tableau de structures module_sect_attr nommé attrs.

- -P pour afficher les paramètres fournis au module.

En omettant les paramètres -P et -S, le chiffre après le nom du module représente l'addition des champs init_size et core_size. init_size représente la taille de la section .init qui contient le code d'initialisation. core_size représente quant à elle la taille de la section .text contenant le code du module à proprement parler.

5.2 Extraire les modules

Dans le cadre d'une étude d'un module noyau, il est possible d'extraire son code grâce à la commande linux_moddump. Celle-ci repose sur l'utilisation du membre module_core qui représente l'adresse de début du module et le membre core_size représentant la taille de la section core. Il est nécessaire de fournir l'argument -D à la commande pour spécifier le chemin où sera extrait le module. Enfin, il est possible d'extraire un seul module en fournissant une expression régulière avec l'argument -r.

6. Réseau

Dans le cas d'une analyse de système corrompu, il est plus que probable que des connexions réseaux illégitimes aient été effectuées vers l’extérieur. Dans la version simple, ces connexions ne sont pas cachées. Les connexions dissimulées seront présentées en section 7.

6.1 Connexions

La première commande utile va être de lister le cache ARP en utilisant linux_arp. Cette commande récupère le symbole neigh_tables de type neigh_table, défini dans le fichier net/neighbour.h, puis parcourt les éléments de la liste chaînée (membre next). Chaque élément de cette liste contient un tableau de type neighbour permettant de pointer sur les informations finales telles que l'adresse IP (v4 ou v6), le nom du périphérique réseau par lequel transiter et la MAC.

Pour obtenir les informations relatives aux interfaces réseau actives, l’équivalent de la commande ifconfig est implémenté par linux_ifconfig. Sur les noyaux récents, le symbole net_namespace_list est utilisé, sur les versions plus anciennes, ce sera le symbole dev_base. Pour les deux types, les informations de chaque carte sont accessibles en parcourant la liste chaînée des structures net_device. Cette dernière fournit l'adresse MAC du périphérique réseau et indique si la carte est en mode promiscious ou non. La liste des interfaces réseaux associées aux périphériques (gestion des alias) est obtenue en parcourant la liste ifa_list du membre ip_ptr.

Pour les versions du noyau antérieures à 3.6, il est possible d'obtenir les informations contenues dans le cache de la table de routage. Pour les versions plus récentes, ce cache n'existe plus car cela pouvait être une source de déni de service [ROUTECACHE]. Le symbole rt_hash_table est obtenu puis, pour chaque élément du tableau pointé, une nouvelle liste (chain) est parcourue pour fournir l'interface, la destination et la passerelle.

Pour terminer sur les connexions réseaux, l’équivalent de la sortie de la commande netstat peut être obtenu en exécutant linux_netstat. Cette commande récupère la liste des fichiers ouverts pour chaque processus en utilisant les résultats de la commande linux_lsof. Puis, pour chaque fichier, la commande va tester si le membre f_op pointe sur une structure socket_file_ops ou si le membre dentry.d_op pointe sur une structure sockfs_dentry_operations. Si tel est le cas, le membre dentry.d_inode est traduit en une structure socket permettant d’accéder au membre sk représentant la structure inet_sock. Cette dernière permet d’accéder aux informations telles que le protocole : TCP ou UDP, dans le cas de socket de type IPv4 ou IPv6 : les adresses, ports sources et destinations ainsi que l’état de la connexion (fermée, établie, en écoute). Dans le cas d'une socket locale, le chemin vers celle-ci sera affiché. Finalement, le nom et le PID du processus sont affichés.

6.2 Contenu des paquets

À partir d'une acquisition mémoire, il est possible d'obtenir dans certains cas le contenu des paquets réseaux.

La première technique repose sur la mise en queue des paquets, ce qui arrive dans deux cas de figure :

- lorsque le réseau n'est pas dimensionné pour tenir la cadence d'envoi d'une socket ;

- lorsque les paquets destinés à un processus utilisateur n'ont pas été traités.

La commande linux_pkt_queues extrait les paquets de cette queue avec la nomenclature suivante : [receive|send].pid.fd. Il est donc nécessaire de croiser les informations obtenues précédemment avec pslist et lsof.

La dernière commande relative à l'extraction des paquets réseaux, linux_sk_buff_cache, utilise le cache du noyau Linux, le SLAB, pour récupérer les structures sk_buff dans les caches skbuff_head_cache et skbuff_fclone_cache. Le système de cache du noyau sera décrit plus tard dans l'article. Les tampons utilisés par le noyau pour gérer les paquets réseaux sont représentés par cette structure sk_buff. Elle contient une multitude d'informations comme les périphériques utilisés, les informations des couches 1 à 3 du modèle OSI (membres h, nh et mac). Dans le cas présent, le membre len est utilisé pour connaître la taille du paquet contenant les données brutes pointées par le membre data.

Sachez que la structure sk_buff n'est pas pleinement exploitée par Volatility et qu'il pourrait être intéressant de faire un module tirant parti des différentes informations contenues dans celle-ci, notamment pour croiser les données...

7. Stratégie d'allocation mémoire

Afin d'optimiser les allocations et libérations de structure noyau (processus avec task_struct ou paquet réseau avec sk_buff), le noyau fournit un mécanisme de cache fourni par l’intermédiaire du mécanisme SLAB. Cela consiste à allouer au démarrage du noyau un pool de structures définies. Au moment d'une demande de création de structure donnée, le noyau a uniquement besoin de retourner le pointeur vers une entrée libre du pool, évitant ainsi le coût d'une allocation et la fragmentation de la mémoire physique.

Ces fonctionnalités sont proposées par le noyau au travers d'une API permettant d'accéder à des fonctions génériques d'allocation mémoire (kmalloc, kmalloc_node, …) ou à des caches spécifiques (kmem_cache_alloc, kmem_cache_alloc_node). Derrière ce mécanisme, il existe trois stratégies d'allocation différentes : le SLAB, le SLUB et le SLOB. Le SLAB est la première version développée et utilisée par le noyau, le SLUB étant sa version améliorée avec une gestion différente des allocations comme l'utilisation d'une liste au lieu d'un tableau et une meilleure gouvernance du cache. Le SLOB est principalement utilisé pour les systèmes embarqués disposant de peu de mémoire.

Il est possible d'obtenir le statut actuel du cache de l'alloueur SLAB sous GNU/Linux en exécutant la commande slabtop. C'est une commande équivalente à top en termes d'affichage et qui permet de connaître la taille de chaque cache et son taux d'occupation. L’équivalent sous Volatility est possible en exécutant la commande linux_slabinfo comme on peut le constater dans le listing suivant :

La majorité des commandes ayant comme suffixe _cache utilise les informations du cache grâce aux fonctions définies dans slab_info. Il est également nécessaire de préciser que Volatility ne gère pas l'alloueur d'objets de type SLUB.

8. Montrez ce que je ne saurais voir

Les sections précédentes ont présenté les commandes utiles pour travailler sur la partie visible d'un système. Cette section est consacrée aux commandes permettant de mettre en évidence ce qu'un attaquant souhaite dissimuler. De la même manière que les sections précédentes, l'envers du décor des commandes est présenté afin de comprendre les mécanismes de détection utilisés.

8.1 Historique des commandes exécutées

Lorsqu'une machine compromise est analysée, une des premières sources d'information est la liste des commandes exécutées par l'attaquant. Cependant, ce dernier prend généralement soin d'effacer le fichier .bash_history à la racine du compte utilisateur. Même si ce fichier a été effacé de manière sécurisée, tout n'est pas perdu. Il est en effet possible de récupérer l'historique des différentes commandes exécutées en analysant la mémoire allouée dynamiquement par le binaire bash. Ce dernier maintient une liste des commandes exécutées qu'il est possible de récupérer par l'utilisation du module linux_bash.

8.2 Hooking

Afin de rester sous le radar, la plupart des codes malveillants utilisent des techniques de dissimulation, dont celle du hooking. Elle consiste à intercepter les appels aux fonctions permettant par exemple de lister des fichiers, des processus, des connexions réseau, etc. L'objectif du code malveillant est de faire en sorte que ses fonctions soient appelées au lieu de celles du système. De manière simpliste, cela consiste à modifier l'adresse de la fonction interceptée en la remplaçant par l'adresse de la fonction de hook. Lors d'un appel à la fonction en question, celle du code malveillant sera donc exécutée. Si le résultat attendu de cet appel ne contient pas d'informations à dissimuler, la fonction originale est appelée sinon la fonction faisant office de hook retournera un résultat maquillé. Le principe de détection repose donc sur la validation des adresses des fonctions du système. Les sections suivantes présentent les hooks habituellement utilisés par du code malveillant et qui sont détectables par Volatility.

8.2.1 Modification des structures operations

Une technique couramment utilisée est d'intercepter les appels aux fonctions contenues dans une structure ayant pour suffixe _operations. Par exemple, celle relative aux fichiers se nomme file_operations et permet de lister le contenu d'un répertoire ou de lire le contenu d'un fichier. Cette structure est accessible par exemple depuis le membre f_op d'une structure de type file. Pourquoi modifier précisément ces informations ? Tout simplement parce que les outils habituels tels que ps ou top pour les processus ou netstat pour les connexions réseaux reposent sur l'utilisation du système de fichiers virtuel procfs.

Ce système de fichiers virtuel fournit les différentes informations relatives aux processus et au système de manière plus générale. Les répertoires nommés avec un nombre correspondent aux différents processus, le nombre représentant leur PID. Chaque répertoire contient les informations relatives au processus telles que ses arguments, ses fichiers mappés ou ses descripteurs de fichiers. Un code malveillant souhaitant dissimuler un processus à un utilisateur va donc hooker les routines de lecture du système de fichiers virtuel procfs.

La commande linux_check_fop permet de détecter aisément ce type d'usurpation en vérifiant que les pointeurs sur fonction pointent sur les adresses des symboles usuels définis dans System.map. La commande exécute cette vérification pour tous les fichiers ouverts fournis par la commande linux_lsof, sur les opérations associées à la structure proc_root accessible par l'obtention de l'adresse du symbole éponyme. Enfin le point de montage de procfs est également vérifié en récupérant le symbole proc_mnt représenté par la structure vfsmount (linux/mount.h).

Cette technique est également applicable pour dissimuler des connexions réseaux à une commande comme netstat. Ainsi, à l'instar de linux_check_fop, la commande linux_check_afinfo permet de rechercher ces modifications de pointeurs sur fonctions pour toutes les structures comportant des opérations d'entrées/sorties utilisées par les protocoles TCP et UDP. En plus de files_operations, cette commande effectue aussi la vérification sur la structure sequence_operations pour la fonction show par exemple.

8.2.2 Syscall

Une autre technique consiste à modifier la table des appels systèmes. Cette table contient les fonctions appelées par un processus demandant un service au noyau. Ainsi lorsqu'un programme ouvre un fichier et lit dans celui-ci, les appels systèmes open() et read() sont utilisés. Un rootkit comme Kbeast va ainsi durant son initialisation poser différents hooks d'appels système en remplaçant le pointeur de la fonction du système par la sienne. Afin de détecter ce comportement, la commande linux_check_syscall vérifie que chaque adresse contenue dans la table des appels système correspond à une adresse connue dans les symboles du profile. Si tel est le cas, le nom du symbole est affiché et HOOKED dans le cas contraire.

8.2.3 IDT

Une autre technique de hooking consiste à modifier l'Interrupt Descriptor Table. Cette table linéaire de 256 entrées contient un pointeur vers le gestionnaire d'interruptions. Brièvement, une interruption est un événement nécessitant une attention soudaine et qui va altérer la séquence d'instruction qui était en cours d'exécution par le processeur. Les sources d'une interruption peuvent provenir du matériel (Entrées/Sorties) ou peuvent être logicielles (par exemple avec l'instruction int3 utilisée par les debuggers pour poser un breakpoint). Le lecteur intéressé par les techniques de hooking IDT peut se reporter à l'article Handling Interrupt Descriptor Table for fun and profit paru dans Phrack [PHRACK].

La commande permettant de vérifier l’intégrité de l'IDT se nomme linux_check_idt et fonctionne sur le même principe de comparaison d'adresse que la commande linux_check_syscall.

8.3 Le jeu des différences

Une autre technique utilisée pour la détection d'anomalie repose sur la corrélation d'informations entre différentes sources. Selon les informations concernées, différents types de structures auront un accès à celles-ci. Si le code malveillant ne modifie pas tous ces pointeurs, il devient possible de détecter ce qui est dissimulé par ce biais. De plus, l'objectif d'un code malveillant, comme tout processus, est de se voir allouer du temps processeur. Même si son objectif est de rester le plus furtif possible, il aura toujours besoin d’être accessible d'une manière ou d'une autre.

8.3.1 Processus

Il est possible de dissimuler un processus en modifiant les pointeurs next et prev des task_struct précédentes et suivantes respectivement. Bien que le processus ne soit plus accessible depuis la liste doublement chaînée des task_struct, cela ne l'empêche pas d'obtenir du temps CPU pour continuer son exécution. En effet, afin de gérer l'exécution des processus, le noyau utilise un gestionnaire de tâches ou scheduler. Sa structure essentielle se nomme runqueue. Sur une architecture multiprocesseur, chaque CPU se voit attribuer une structure runqueue. Le champ le plus intéressant de cette structure est arrays qui est un tableau contenant la liste des processus actifs ou endormis. Ces deux éléments du tableau représentent une structure de type prio_array_t qui inclut 140 listes doublement chaînées représentant toutes les priorités existantes pouvant être attribuées à un processus. Le scheduler travaille directement à partir de ces listes pour gérer l'exécution des processus. Il faut savoir qu'au moment de la rédaction de l'article, il n'existait pas encore de module Volatility capable d'extraire les informations relatives aux runqueues.

Cependant d'autres structures du noyau permettent actuellement de mettre en avant des comportements potentiellement malicieux.

Comme vu précédemment, le noyau maintient un cache des objets alloués. Àpartir de celui-ci, il est donc possible d'obtenir des informations relatives aux allocations de la structure task_struct définissant un processus. C'est précisément la fonctionnalité fournie par la commande linux_pslist_cache qui va lister toutes les task_struct présentes dans le cache du mécanisme d'allocation SLAB. Par défaut, la commande va uniquement travailler sur les structures allouées, mais il est possible d'obtenir également une liste des éléments non alloués en fournissant l'argument -u à la commande. Il est ainsi possible de récupérer des informations relatives aux processus ayant pu être alloués précédemment.

Une autre technique possible repose sur l'analyse des tables de hash de PID obtenues au travers du symbole pid_hash. Il existe quatre tables de hash différentes dans le noyau Linux permettant de récupérer un descripteur de processus à partir de son PID. Un de ces mécanismes de traduction est par exemple utilisé lors de l'appel système kill. La commande linux_pidhashtable est en charge d'analyser ces informations.

Bien qu'il soit possible d'utiliser les deux commandes précédentes de manière séparée, il est plutôt recommandé de recourir à la commande linux_psxview qui croise les informations de linux_pslist, linux_pslist_cache et linux_pidhashtable et qui, comme présenté dans la figure suivante, affiche le nom de chaque processus et leur présence dans chacune des trois informations obtenues.

8.3.2 Modules noyau

De la même manière qu'un processus peut être caché en étant retiré de la liste task_struct, il est possible d'en faire autant avec la liste des modules noyaux chargés telle que présentée par la commande habituellement utilisée : lsmod. À titre informatif, le fichier /proc/modules est basé sur l'export de cette liste chaînée en question et c'est sur ce fichier que repose l'implémentation de la commande habituelle lsmod. Ce que fait Volatility pour détecter cette dissimulation est de procéder à une comparaison entre cette liste chaînée et le contenu du répertoire /sys/module qui représente chaque module par un répertoire portant son nom. Ce dernier contient à son tour les informations du module en question. Cette représentation « système de fichiers » repose en fait sur l'utilisation d'une nouvelle structure. Pour y accéder, il faut que le noyau ait été compilé avec le support de sysfs ce qui permet d'obtenir le symbole module_kset de type kset contenant un champ kobj. Ce champ donne ensuite accès à la liste chaînée de type kobject. La commande linux_check_modules fait par la suite une différence entre ces deux listes chaînées pour mettre en avant les modules suspicieux.

8.4 Keylogging

Comme mentionné sur le wiki du projet, Volatility permet de mettre en avant deux techniques utilisées pour keylogger et présentées dans le papier [KEYLOGGERS].

8.4.1 TTY

La première technique repose sur la pose d'un contournement de la fonction receive_buff du pilote tty. La commande Volatility en charge de détecter ce hook se nomme linux_check_tty. Elle va dans un premier temps récupérer et itérer sur la liste des pilotes tty obtenue par le symbole tty_drivers. À chaque pilote est associé un tableau contenant les périphériques tty et qui sont représentés par la structure tty_struct. Pour chacune d'entre elles, la commande accède ensuite au champ relatif à la structure définissant les opérations propres aux tty line discipline présentée dans le papier précédemment cité : ldisc.ops. Cet accès permet finalement de pointer sur la fonction receive_buf. L'adresse de cette fonction obtenue, il suffit de vérifier si celle-ci est associée à un symbole du noyau (get_symbol_by_address("kernel", recv_buf)). Si tel n'est pas le cas, la commande affichera HOOKED dans la colonne Symbol.

8.4.2 Keyboard notifier chains

Le côté intéressant de cette technique réside dans le fait qu'aucune modification de structure en mémoire n'est faite, mais qu'elle repose sur l'abus d'une API du noyau Linux existante depuis la version 1.1 : les notifiers chains. De manière simple, cette API permet d'associer à un événement système une liste chaînée de fonctions de rappel (callbacks). Lorsque l'événement en question se produit, la liste chaînée est parcourue et chaque fonction appelée. D'un point de vue programmation, ce mécanisme est équivalent au design pattern Observer. Vous l'aurez deviné, pour être informé d'un événement, il suffit d'ajouter sa callback à cette liste chaînée. Et depuis la version 2.6.24, il existe une chaîne de notification relative aux frappes clavier.

De la même manière que la commande linux_check_tty, la commande linux_keyboard_notifier va donc vérifier si les adresses de fonction de rappel enregistrées dans la liste chaînée keyboard_notifier_list correspondent à l'adresse d'un symbole du noyau ou non.

Conclusion

Cet article a présenté la majorité des différentes commandes utilisables par Volatility sur un système GNU/Linux. Résumer toutes les informations utilisées en un article n'est pas chose aisée notamment quand des livres sont dédiés à un seul sous-système du noyau. J'en profite pour attirer l'attention sur la sortie en juillet dernier d'une bible de 900 pages rédigée par l'équipe de développement de Volatility intitulé The Art of Memory Forensics traitant à la fois les systèmes Windows, Linux et Mac. Enfin, certaines informations ne sont pas encore utilisées et des pans entiers de structures n'ont pas été présentés, donnant la possibilité de développer de nouveaux modules à qui le veut.

Remerciements

Merci à Cédric et Jean-François pour leur relecture, Samir pour ses remarques et conseils pertinents ainsi qu'à Guillaume pour son extrême patience...

Bibliographie

[DFRWS14] http://www.dfrws.org/2014eu/program.shtml

[LMAP] https://code.google.com/p/rekall/source/browse/#git%2Ftools%2Flinux%2Flmap

[VOLINUX] http://code.google.com/p/volatility/wiki/LinuxCommandReference23

[VOLUSAGE] http://code.google.com/p/volatility/wiki/VolatilityUsage23

[VBOX] http://www.digital-forensic.org/media/vms/misc.zip

[SUTERUSU] https://github.com/mncoppola/suterusu

[ROUTECACHE] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=89aef8921bfbac22f00e04f8450f6e447db13e42

[PHRACK] http://www.phrack.org/issues/59/4.html#article

[KEYLOGGERS] http://www.ieee-security.org/TC/SPW2012/proceedings/4740a097.pdf