Analyse des virus furtifs
6.4.1 Donc qu’est ce qui est nouveau ?
Nous proposons un système d’analyse fiable, furtif et sécurisé [Jos06b,Jos07a] pour extraire automatiquement (ou interactivement lorsque c’est nécessaire) une information précise sur un rootkit. Nous récupérons une informa- tion précise relative avec ses interactions avec l’exécutif du système d’exploitation, plus particulièrement concernant la manière utilisée pour installer et maintenir des hooks dans le système cible.
Fig. 6.4 – Spectre d’auto-corrélation (VMware)
contrôlé, nous pouvons analyser la plupart des rootkit sans aucun risque pour le système réel.
Le processus d’analyse tout entier est conduit au sein d’un environnement virtuel (la matrice), qui peut être très difficile à distinguer d’un environnement réel, donc augmentant les compétences techniques requises chez un concepteur de rootkits pour pouvoir fabriquer un rootkit susceptible de s’évader ou de se propager.
Notre approche permet de prendre un instantané fiable et furtif des objets du noyau ou matériels qui sont habituel- lement modifiés par les infections informatiques implémentant la plupart des technologies rootkit. Cette fonction de surveillance est aussi furtive que possible car nous utilisons une CSIM complète et précise (incluant un CPU virtuel et les composants matériels les plus courants), sur laquelle s’exécute une version non modifiée du système d’exploitation.
Ces contrôles peuvent survenir à tout moment durant le cycle de vie du rootkit sous contrôle : au moment du démarrage de l’OS, du chargement de l’exécutable ou de son exécution. En effet, nous pouvons appliquer des contrôles à chaque cycle du CPU virtuel. Nous avons donc de nombreux degrés de liberté et une fine granularité.
En observant l’ensemble du système hôte corrompu depuis l’extérieur, nous offrons un nouveau point de vue qui permet l’étude des algorithmes de détection de rootkits actuels (à l’intérieur de la matrice) et de valider leur perti- nence dans ce nouveau contexte (à l’extérieur de la matrice).
En comparaison des solutions matérielles de détection des rootkits, et parce que la totalité de la machine peut être inspectée à tout instant durant le processus d’analyse, notre solution ne souffre pas des mêmes limitations et vulnérabilités (timing attacks, attaques sur le cache CPU, situations de concurrence).
En comparaison des outils de détection de rootkit actuels (à l’intérieur de la matrice), les même algorithmes de détection sont plus difficiles à contourner :
Fig. 6.5 – Spectre d’auto-corrélation (VMware) avec masquage des interruptions
– les fonctions de contrôle d’intégrité ne se heurtent pas aux contraintes et règles imposées par le système d’exploitation ou par le matériel. Des mesures furtives peuvent être pratiquées sans perturber le système d’exploitation et sans être repérables. Parce que les rootkits ne s’exécutent pas au même niveau que la fonction de détection, ils ne peuvent plus perturber son diagnostic.
– pour la même raison, les algorithmes de contrôle de modèle sont plus robustes et difficiles à déjouer. En outre, parce que nous pouvons échantillonner et effectuer des mesures avec un granularité plus fine et une fréquence plus élevée (à chaque cycle du CPU virtuel si nécessaire), il est possible d’obtenir des implémentations plus efficaces de ce type d’algorithme d’apprentissage.
Les algorithmes classiques s’appliquent mais sans les mêmes contraintes opérationnelles. En conséquence, il est plus facile d’appliquer la plupart d’entre eux conjointement et éventuellement d’augmenter la portée de l’analyse.
Durant le processus d’analyse, nous pouvons diriger des transformations complexes sur le programme cible, comme le dépacketage, et donc potentiellement analyser des rootkits blindés.
La plupart des rootkits actuels n’implémentent pas de protection logicielle comme le packetage. Notre moteur de dépacketage, qui est un plug-in de VxStripper, fournit une fonctionnalité de dépacketage générique qui pourrait être utile dans le futur lors de l’analyse de rootkits.
6.4.2
Limitations
La technologie rootkit évolue très rapidement et exploite volontiers la complexité structurelle croissante des systèmes d’exploitation et les nouvelles fonctionnalités des composants matériel. Dans ce contexte, spécifier un outil d’analyse fondé sur l’émulation logicielle de l’ensemble des composants matériel d’un PC relève du défi. L’émulateur QEMU, sur lequel se fonde VxStripper, ne propose pas encore de CPU logiciel correspondant aux spécifications des CPU AMD Pacifica ou Intel VT. Nous ne sommes donc pas en mesure de spécifier des méthodes de récupération d’in-
formation pour les rootkits exploitant les extensions de virtualisation proposées par le jeu d’instruction de ces CPUs.
Dans le contexte de l’analyse de rootkits, deux exigences de sécurité doivent être couvertes : l’isolation (confi- nement, capacité à endiguer la propagation) et la furtivité (si l’émulation est détecté, le rootkit cible ne fournira pas l’information escomptée ou pire, manipulera l’analyse). Nous avons vu au chapitre5 (section5.3.4) que plusieurs fonctions de sécurité sont obligatoires pour accroître la sécurité de notre solution. Pour être isolée et sécurisée, un émulateur doit implémenter une protection robuste des périphériques, du filtrage et des mécanismes de quarantaine réseau. Au minimum, un pare-feu doit être installé sur système hôte de façon à surveiller les interfaces de communi- cation réseau entre systèmes d’exploitation hôte et invité. Nous étudions actuellement la possibilité d’inhiber toute interface entre les systèmes hôte et invité, fournissant ainsi une VM hautement sécurisée.
Le problème de détection d’un environnement émulé par un rootkit est également crucial dans le contexte de la détection de rootkit par émulation. Nous avons vu à la section 5.3.4du chapitre 5 que les VMM souffrent de limitations structurelles qui peuvent être détectée. Les CSIM ne sont pas sensibles aux mêmes attaques, mais sont trop souvent détectables en raison de l’imperfection de l’émulation des composants matériels.
Nous avons présenté à la section 6.3.11 des méthodes de détection de VMM fondées sur le contrôle de modèle. Les CSIM ne sont a priori pas sensibles à ces attaques, dans la mesure où les timers et les caches du CPU logi- ciels sont entièrement émulés et ne sont pas partagés. Cependant, un algorithme de détection peut se fonder sur le contrôle de modèle en comparant l’empreinte du CPU logiciel constituée par le spectre d’autocorrélation avec l’empreinte du CPU réel correspondant, en terme de spécifications.
De manière à être aussi furtif que possible, les erreurs et limitations au coeur du moteur d’émulation doivent être corrigées. Il y a donc du travail à réaliser pour accroître le niveau de sécurité d’un détecteur de rootkits fondé sur un moteur d’émulation.
6.5
Conclusion
Nous avons présenté dans ce chapitre le module de VxStripper dédié à l’analyse des programmes furtifs. Il propose un système fiable pour récupérer automatiquement de l’information sur un rootkit et ses interactions avec le sys- tème. Cette information peut être utilisée pour définir un schéma de détection adapté.
Parmi les limites de l’outil VxStripper, nous avons identifié les imperfections relatives à l’émulation du CPU logiciel, susceptibles de trahir la présence d’un environnement d’analyse. Nous pouvons observer par ailleurs que l’émula- teur QEMU, sur lequel se fonde VxStipper, ne propose pas encore de CPU logiciel supportant les extensions de virtualisation. Il ne permet donc pas l’analyse de certains rootkits VMBR, comme Blue Pill ou Vitriol.
Nous avons étudié la transposition dans VxStripper de certains des algorithmes représentatifs de l’état de l’art dans ce domaine :
– les méthodes de contrôle d’intégrité des rouages internes du système d’exploitation, – les méthodes de contrôle de modèle.
Nous avons observé qu’il est possible de les appliquer conjointement de manière furtive et éventuellement d’aug- menter la portée de l’analyse.
D’autres méthodes de détection intéressantes, actuellement implémentées par des outils forensiques spécialisés, pourraient être transposées dans notre module d’analyse des rootkits :
– les méthodes de comparaison croisée pourraient être implémentées en injectant du code dans la machine virtuelle de manière à générer des appels systèmes de plus ou moins bas niveau ;
– les contrôles de cohérence pourraient être implémentés sur plusieurs structures du noyau pour fournir des bornes intrinsèques caractérisant un état sain ;
– les méthodes à base de signatures pourraient être implémentées en contrôlant plusieurs endroits du système (par exemple, le module noyau d’un rootkit, son dropper, la zone mémoire dans laquelle il se charge, etc.) à des étapes cruciales durant l’exécution du programme cible ou durant le cycle de vie du système virtuel tout
entier (au moment du démarrage, par exemple).
J’envisage comme tâche future l’implémentation de ces méthodes de récupération d’information d’interaction bas niveau avec l’OS. Je souhaite également étudier les possibilités d’extension des CPU logiciels supportés par VxS- tripper aux jeux d’instructions supportant la virtualisation, afin de pouvoir étudier les rootkits les utilisant.
Nous avons signalé dans le résumé de ce chapitre que notre outil d’analyse s’applique aux rootkits mais égale- ment à tout produit de sécurité qui interagit à bas niveau avec le système d’exploitation dans le but d’asseoir sa robustesse ou de cacher des informations en installant des hooks.
En effet, nous pouvons utiliser cet outil pour vérifier la robustesse des mécanismes de sécurité et recouvrer une information sur leurs procédures et fonctionnements internes : comme nous l’avons vu dans la section 6.4, nous sommes capables de collecter de nombreuses données qui révèlent des zones possibles de dissimulation.
Nous pourrions implémenter des modules de diagnostiques plus spécialisés de manière à évaluer la robustesse des fonctions de sécurité et mécanismes au travers d’une approche boîte noire ou boîte grise : la possibilité d’appliquer de la réécriture de code binaire au niveau des instructions ou des basic blocks durant l’exécution d’un produit de sécurité et de modifier n’importe quel endroit de la plate-forme toute entière est un composant critique de tout système d’extraction d’information ou d’injection de fautes.
Parmi les méthodes de détection des rootkits, les méthodes de contrôle de modèle, présentées à la section 6.3.11, sont sans doute les plus génériques. Elles s’appliquent en particulier à la détection des rootkits VMBR7. Nous avons observé que ces méthodes peuvent être formalisées en terme de tests statistique. Nous proposons dans le chapitre suivant une généralisation de cette approche aux autres méthodes de détection virale.
7Observons cependant que ces méthodes s’appliquent aujourd’hui plus à la détection de la présence d’un hyperviseur sous le système
d’exploitation qu’à détection d’un rootkit se fondant sur la virtualisation. C’est la raison pour laquelle il faut sans doute redéfinir les bons estimateurs [Fil07c].