Techniques de détournement utilisées par les "Rootkits Windows"

Date : 28 Avril 2006

Nous avons déjà consacré plusieurs articles aux "rootkits" qui existent dans l'environnement Windows (voir en particulier l'article consacré à "RootkitRevealer", ainsi que celui consacré à "Haxdoor"). Nous revenons aujourd'hui sur ce sujet pour expliquer les techniques qui sont utilisées par ces "rootkits" de façon à altérer le comportement natif du système d'exploitation Windows.

Ces techniques de "rootkits" sont en effet aujourd'hui de plus en plus utilisées, par des programmes malveillants d'une part, mais aussi par des programmes beaucoup plus légitimes, comme par exemple :

  • Les gardes-barrières personnels. Ceux-ci utilisent des techniques de "rootkit" pour placer sous surveillance le trafic réseau et les applications lancées sur le poste.
  • Le produit "Norton SystemWorks" de Symantec. La fonctionnalité de "Protected Recycle Bin" utilise une technique de "rootkit" pour dissimuler des fichiers.
  • Le "rootkit Sony". Ce dernier utilisait des fonctions "rootkit" pour implanter un mécanisme de "DRM" ("Digital Rights Management").

 

Techniques les plus répandues

Nous ne faisons pas ici un inventaire complet de toutes les techniques possibles, mais nous nous intéressons à celles qui sont les plus répandues. Elles constituent aujourd'hui le "B.A.BA" des techniques d'attaque et de subversion du noyau Windows :

  • API "hooking"
  • SSDT "hooking"
  • "Inline hooking"

1 - API "hooking"

Cette technique d'API "hooking" permet de réaliser des "rootkits" de type "user-mode" : ce type de rootkit n'altère pas le noyau Windows, et s'exécute simplement au sein des applications infectées, dans le mode "user".

Les API ("Application Programming Interfaces") sont des fonctions que le système Windows met à disposition des programmeurs pour développer une application. Ces API sont implémentées au moyen de DLL ("Dynamic Link Library"). Par exemple, l'API "Win32" (qui est l'API majeure de Windows) est implémentée par des DLL comme  "Kernel32.dll", "User32.dll" ou "Gdi32.dll".

Quand une application veut appeler une fonction de l'API, elle n'appelle pas directement la DLL correspondante : elle utilise plutôt une table locale appelée l'IAT ("Import Address Table") qui liste les adresses des fonctions de toutes les DLL utilisées par l'application. L'IAT est donc une table d'indirections qui permet de "lier" l'application aux différentes DLL du système.

L'API "hooking" est une technique de détournement qui consiste à modifier à la volée ("patcher") l'IAT. Par exemple, si un pirate modifie l'entrée de l'IAT correspondant à la fonction "xxx" de l'API Windows, alors tout appel ultérieur à cette fonction sera détourné vers la fonction que le pirate aura lui-même défini (et dont il aura mis l'adresse dans l'IAT).

L'API "hooking" est une technique locale à une application (chaque application dispose de sa propre table IAT, dans son propre espace mémoire). Pour prendre le contrôle complet d'une machine, un pirate doit donc infecter une à une toutes les applications qui sont lancées, et "patcher" l'IAT de chacune d'elles. Il peut aussi choisir d'infecter uniquement certaines applications critiques, comme par exemple "Internet Explorer" (cas d'une attaque visant à voler des données lors de la visite de sites web bancaires). L'infection d'une application peut être réalisée de différentes manières, mais la plus simple reste de modifier la clé de la base de registre qui liste les DLL qui seront automatiquement associées (et exécutées) lorsqu'une application est lancée (le pirate ajoute sa propre DLL à cette liste).

 

2 - SSDT "hooking"

 

A certains moments au cours de son exécution, une application a besoin d'appeler le noyau Windows pour effectuer des opérations de bas niveau (ces appels bas niveau sont en fait provoqués par les fonctions de l'API Windows que l'application appelle, plutôt que directement par l'application elle-même). Le passage du mode "utilisateur" (on parle ici de "user-mode") au mode "noyau" (on parle ici de "kernel-mode") peut se faire (suivant les versions de Windows), soit en déclenchant une interruption, soit en utilisant des registres spéciaux du processeur (registres "MSR"). Quelque soit la méthode, une fois que le noyau prend la main pour exécuter le service qui lui a été demandé, il utilise une table d'indirection appelée la SSDT ("System Service Descriptor Table").

La SSDT est une table qui indique à quelle adresse se trouve chacune des fonctions implémentées par le noyau. Si un pirate modifie l'entrée de la SSDT correspondant à la fonction "xxx" du noyau Windows, alors tout appel ultérieur de cette fonction sera détourné vers la fonction que le pirate aura lui-même définie.

Cette fois, contrairement à ce que nous avons vu avec l'API "hooking", ce détournement s'appliquera instantanément à toutes les applications s'exécutant sur la plate-forme. Pour réaliser une telle attaque, un pirate doit réussir à l'introduire dans le noyau, par exemple via une faille dans un service du noyau, ou en installant des "drivers" malicieux.
 

3 - "Inline hooking"

Le "Inline hooking" est une variante des techniques vues précédemment. Cette fois, plutôt que de modifier une entrée dans une table d'indirection (IAT ou SSDT), cette technique consiste à écraser les premiers octets de la fonction pointée par la table d'indirection. Pour poser son "hook", le pirate :

  • regarde l'adresse légitime pointée par l'entrée de la table qu'il veut "hooker",
  • sauvegarde les premiers octets trouvés à l'adresse pointée,
  • écrase ces premiers octets par un code qui détourne l'exécution normale vers une fonction définie ailleurs par le pirate. Cette fonction pirate utilisera bien sûr les octets sauvegardés pour rétablir, si nécessaire, l'exécution normale.

L'intérêt de cette approche est qu'elle est plus difficile à détecter qu'une modification directe sur les tables IAT ou SSDT.

 

Détection

Il existe aujourd'hui quelques outils qui sont capables de détecter les "rootkits" sur une plate-forme Windows. Nous donnons ici les outils qui nous paraissent les plus significatifs. La plupart de ces outils s'adressent avant tout à des spécialistes, car ils sont réputés pour déclencher de fausses alarmes, et il faut donc inspecter soigneusement les résultats pour les interpréter correctement. "Backlight" de F-Secure est le seul produit (de notre liste) à avoir une vocation commerciale (il sera intégré à la suite "Internet Security 2006").

Cet outil est spécifiquement conçu pour détecter les techniques de "hooking" exposées dans cet article (IAT "hooking", SSDT "hooking", "inline hooking"). Il analyse les structures de données des exécutables et du noyau, de façon à détecter si elles ont été modifiées.
Cet outil tente d'identifier les "rootkits" en comparant la liste des fichiers obtenue en appelant l'API Windows (liste qui peut être altérée par un "rootkit") à celle obtenue en lisant directement la structure physique du disque dur (liste non altérable par un "rootkit").

L'approche de cet outil est la même que celle de "RootkitRevealer". Cet outil complète l'analyse de "RootkitRevealer" (qui se limite aux fichiers) en recherchant également si des processus sont cachés. Ici encore, c'est une analyse différentielle qui est faite : la liste des processus obtenue en utilisant l'API Windows est comparée avec une liste construite en analysant les structures internes du noyau.


Pour plus d'information

Précedent Précedent Suivant Suivant Imprimer Imprimer

© 2024 Cert-IST