Rootkit - Définition

Types

Un rootkit peut intervenir à un ou plusieurs niveaux du système parmi les cinq suivants : micrologiciel, hyperviseur, noyau, bibliothèque ou applicatif.

Niveau micrologiciel/matériel

Il est possible d'installer des rootkits directement au niveau du micrologiciel (ou firmware). De nombreux produits proposent désormais des mémoires flash qui peuvent être utilisées pour injecter durablement du code en détournant par exemple l'usage d'un module de persistance souvent implanté dans le BIOS de certains systèmes.

Un outil légitime utilise cette technique : LoJack, d'Absolute Software, qui permet de suivre un ordinateur à l'insu de l'utilisateur pour retrouver un ordinateur portable en cas de vol. Ce code reste en place après un formatage du disque dur, voire après un flashage du BIOS si le module de persistance est présent et actif. Tout périphérique disposant d'un tel type de mémoire est donc potentiellement vulnérable.

Une piste évoquée pour contrer ce genre de rootkit serait d'interdire l'écriture du BIOS, grâce à un cavalier sur la carte mère ou par l'emploi d'un mot de passe, ou d'utiliser des EFI à la place du BIOS, mais cette méthode reste à tester et à confirmer.

Niveau hyperviseur

Ce type de rootkit se comporte comme un hyperviseur natif, après s'être installé et avoir modifié la séquence de démarrage, pour être lancé en tant qu'hyperviseur à l'initialisation de la machine infectée. Le système d'exploitation original devient alors un hôte (invité) du rootkit, lequel peut intercepter tout appel au matériel. Il devient quasiment impossible à détecter depuis le système original.

Une étude conjointe de chercheurs de l'université du Michigan et de Microsoft a démontré la possibilité d'un tel type de rootkit, qu'ils ont baptisé « virtual-machine based rootkit » (VMBR). Ils ont pu l'installer sur un système Windows XP et sur un système Linux. Les parades proposées sont la sécurisation du boot, le démarrage à partir d'un média vérifié et contrôlé (réseau, CD-ROM, clé USB, etc.) ou l'emploi d'un moniteur de machine virtuelle sécurisé.

Blue Pill est un autre exemple de rootkit utilisant cette technique. En mai 2010, Zhi Wang et Xuxian Jiang, deux chercheurs de l'Université de Caroline du Nord, publient « HyperSafe », un outil permettant de sécuriser BitVisor et Xen — mais portable sur les hyperviseurs de type 1 — contre entre autres Blue Pill : le principe est d'empêcher l'injection et l'exécution arbitraire de code par overflow (non-bypassable memory lockdown) et de protéger les pointeurs de fonction pour empêcher les attaques par hooking.

Niveau noyau

Certains rootkits s'implantent dans les couches du noyau du système d'exploitation : soit dans le noyau lui-même, soit dans des objets exécutés avec un niveau de privilèges équivalent à celui du noyau.

Sous Linux, il s'agit souvent de modules pouvant être chargés par le noyau, et sous Windows de pilotes. Avec un tel niveau de privilèges, la détection et l'éradication du rootkit n'est souvent possible que de manière externe au système en redémarrant depuis un système sain, installé sur CD, sur une clé USB ou par réseau.

Le type le plus courant, depuis 1997, de rootkit noyau s'attaque au LKM des noyaux Unix. Le LKM a naturellement la possibilité de modifier certains appels système ; c'est ce qui rend le noyau modulaire. S'il est compromis par un kit, il peut remplacer la commande « ouvrir le fichier foo » – open() – par « ouvrir le fichier foo sauf s'il s'appel rootkit », rendant les fichiers du rootkit invisible pour l'utilisateur. Adore est un de ceux-là : il remplace entre autres les appels à fork(), open() et write().

A contrario, SucKIT, publié dans l'article 0x07 du Phrack n°58, est un rootkit noyau ne nécessitant pas de LKM (il passe par le périphérique /dev/kmem).

Les rootkits noyau sont dangereux à la fois parce qu'ils ont acquis des privilèges élevés (il est alors plus facile de leurrer tout logiciel de protection), mais aussi par les instabilités qu'ils peuvent causer sur le système infecté comme cela a été le cas lors de la correction de la vulnérabilité MS10-015, où des écrans bleus sont apparus en raison d'un conflit entre le fonctionnement du rootkit Alureon et la correction de cette vulnérabilité.

Niveau bibliothèque

À ce niveau, le rootkit détourne l'utilisation de bibliothèques légitimes du système d'exploitation.

Plusieurs techniques peuvent être utilisées. On peut patcher une bibliothèque, c'est-à-dire lui ajouter du code. On peut aussi détourner l'appel d'un objet – par hooking, () – , ce qui revient à appeler une « autre fonction » puis à revenir à la fonction initiale, pour que le détournement soit transparent du point de vue fonctionnel. Enfin, on peut remplacer des appels système par du code malveillant.

Ce type de rootkit est assez fréquent, mais il est aussi le plus facile à contrer, notamment par un contrôle d'intégrité des fichiers essentiels, en surveillant leur empreinte grâce à une fonction de hachage ; par une détection de signature du programme malveillant ; ou par exemple, par un examen des hooks au moyen d'outils comme unhide sous Linux ou HijackThis sous Windows.

Un exemple connu de ce type de kit est T0rn 8 : il charge sa propre bibliothèque (libproc.a) qui va remplacer la bibliothèque standard faisant l'intermédiaire entre les informations système – /proc – et l'espace utilisateur. Ainsi, le kit peut filtrer les informations qui transitent et retirer tous ce qui pourrait révéler la présence du kit, sans toucher aux exécutables système (ps, ls, etc.).

Niveau applicatif

Un rootkit applicatif implante des programmes malveillants de type cheval de Troie, au niveau utilisateur. Ces programmes prennent la place de programmes légitimes – usurpation d'identité – ou en modifient le comportement, afin de prendre le contrôle des ressources accessibles par ces programmes.

Par exemple, une application de traitement de texte peut être remplacé par une version malicieuse et donner accès aux fonctions permettant de lire et d'écrire un fichier dans une partie de l'arborescence. Plus grave, des applications comme ls, ps, grep peuvent être remplacées.

Cette méthode n'est pas efficace si ces programmes sont régulièrement recompilés à partir des sources.