Application de l’analyse de la mémoire vive

Application de l’analyse de la mémoire vive

Ce chapitre propose une technique d’analyse de la mémoire vive visant un équilibre entre une approche suﬃsamment spéciﬁque pour capturer des comportements malicieux particuliers à la plateforme Android, mais assez générique pour demeurer valide à travers les versions du SE. La méthode proposée utilise les greﬀons de Volatility ciblant l’extraction de structures internes du noyau Linux depuis une capture de la mémoire vive et les applique dans un contexte d’analyse de maliciels sur Android. Il est également proposé d’utiliser une technique proposée dans ce mémoire, l’analyse diﬀérentielle de la mémoire vive (ADMV), aﬁn de concentrer l’eﬀort d’analyse sur les structures aﬀectées par l’exécution de l’application. Ce chapitre présente en premier lieu le rationnel et le fonctionnement de l’ADMV. En second lieu, il présente une étude dans laquelle l’approche est appliquée aﬁn de capturer et d’extraire des artefacts de l’exécution d’un maliciel expérimental conçu à cette ﬁn et vise à démontrer la pertinence de l’ADMV sur une plateforme Android utilisant ART.

Analyse diﬀérentielle de la mémoire vive

L’analyse diﬀérentielle peut être déﬁnie comme l’utilisation de la diﬀérence entre les données recueillies à deux temps de mesure t espacés par Dt. La résultante permet d’isoler uniquement les éléments ayant été créés, supprimés ou modiﬁés entre ces temps de mesure. Ce substrat réduit la quantité de données à analyser et vise à réduire le temps et la complexité de d’analyse. Dans le cas de l’analyse de maliciels, il est possible d’obtenir un état initial qui se déﬁnit par l’état de la plateforme au moment qui précède le déploiement de l’échantillon à analyser. Pour l’ADMV, cela signiﬁe qu’il est possible d’obtenir une acquisition à un temps toù l’application à analyser n’a pas encore été déployée et que le système fonctionne normalement. Après l’acquisition de cette capture initiale, l’application est déployée. Aﬁn d’augmenter les chances qu’elle se révèle malicieuse si tel est le cas, elle peut être stimulée manuellement paroù les artefacts de l’exécution de l’application sont possiblement encore présents dans la mémoire vive.

Aﬁn d’eﬀectuer la comparaison entre les deux temps de mesure, il est proposé de comparer les informations extraites à l’aide des modules visant Linux de Volatility. Tel qu’il est décrit précédemment, Volatility permet d’extraire des informations sur les structures internes du SE à partir de la mémoire vive. La comparaison des résultats obtenus par l’outil permet d’établir clairement quelles composantes du SE sont d’intérêt pour l’analyse. Il est postulé que les nouvelles entrées sont des éléments ayant été créés pendant l’exécution de l’application. Les éléments présents avant et après le déploiement de cette dernière sont considérés pour l’analyse s’ils ont été modiﬁés dans l’intervalle d’acquisition. Finalement, les éléments présents au temps tL’ADMV a également été explorée par 504ensics Labs [2] en visant principalement les greﬀons Windows de Volatility. Leur approche est démontrée par l’outil Diﬀerential Analysis of Malware in Memory (DAMM) qui vise à automatiser la diﬀérenciation entre les captures de mémoire vive. Ce programme a été étudié dans les présents travaux et des eﬀorts ont été menés aﬁn de l’adapter aux greﬀons pour Linux de Volatility. Toutefois, le développement de l’outil a été abandonné par son créateur et les eﬀorts pour le maintenir ont été interrompus. Conséquemment, DAMM n’a pas été retenu dans les présents travaux bien qu’il en démontre l’intérêt de l’approche.

Étude de cas

L’approche de l’ADMV a reçu peu d’attention dans la littérature. Sur Android, il n’a pas été possible d’identiﬁer des travaux s’étant penchés sur sa pertinence et son utilisation en tant qu’outil d’analyse de maliciels. C’est pour cette raison que l’étude suivante s’est intéressée à démontrer l’applicabilité de l’ADMV dans l’identiﬁcation de comportements malicieux de même que sa résilience aux tactiques d’évasion de la détection comme l’obfuscation, lePlus spéciﬁquement, l’expérimentation décrite vise à répondre aux questions suivantes : est-ce possible d’utiliser l’ADMV pour identiﬁer, récupérer et analyser le contenu d’un ﬁchier de code malicieux déchiﬀré, chargé dynamiquement et supprimé dès la ﬁn de son chargement aﬁn d’empêcher sa récupération sur le stockage physique de l’appareil ? Également, est-il possible par cette même technique d’identiﬁer une élévation de privilèges et un cheval de Troie (ou porte dérobée) ?

L’appareil utilisé pour le déploiement de l’application est un téléphone Nexus 4 de LG avec la version 5.1 du système d’exploitation. Ce dernier a été recompilé pour supporter le chargement du module LiME selon la méthode présentée à la section 3.1.1. Le module est préchargé sur l’appareil avant le scénario. Également, pour le bien de la démonstration, le noyau a été modiﬁé aﬁn d’être vulnérable à l’élévation de privilèges utiliser dans l’exploit towelroot introduit par Hotz [63]. La révision du noyau utilisée correspond à une variante du noyau Linux, appelée Mako, et adaptée au Nexus 4. La version du code utilisée se situe sur la branche Git appelée origin/android-msm-mako-3.4-lollipop-mr1. La seule exception est le ﬁchier kernel/futex.c qui est à une version antérieure, soit à la révision identiﬁée par l’identiﬁant unique Git 7e9543a0ebde3c1df0108523a3e9e152e254f962. Cette dernière précède le correctif appliqué pourprotéger des exploits utilisant la même technique que towelroot. Cette modiﬁcation a pour eﬀet de retourner le noyau Linux à une version vulnérable tout en restant compatible avec la version 5.1 d’Android. Le fonctionnement de cet exploit est détaillé par Zatuchna sur Nativeﬂow [134–136]. La version utilisée dans le cadre de cette étude est celle de Timwr [120]. Finalement, l’utilisateur root est activé à l’aide du correctif SuperSU conçu par Chainﬁre [22] aﬁn de permettre l’acquisition par LiME. Toutefois, l’utilisation de ces privilèges n’est limitée qu’à l’invite de commande accessible par l’interface de déverminage ADB et utilisée pour lancer l’acquisition.