Rootkit

Pour les articles homonymes, voir Kit.

Vous lisez un « bon article » labellisé en 2011.

Un rootkit ^Écouter ou simplement « kit » (aussi appelé « outil de dissimulation d'activité »^[1], « maliciel furtif »^[2], « trousse administrateur pirate »^[3]), est un ensemble de techniques mises en œuvre par un ou plusieurs logiciels, dont le but est d'obtenir et de pérenniser un accès (généralement non autorisé) à un ordinateur le plus furtivement possible^{[4],[C 1],[L 1]}, à la différence d'autres logiciels malveillants. Le terme peut désigner la technique de dissimulation ou plus généralement un ensemble particulier d'objets informatiques mettant en œuvre cette technique.

Leur furtivité est assurée par plusieurs mécanismes de dissimulation (voir infra) : effacement de traces, masquage de l'activité et des communications, etc. Un rootkit peut s'installer dans un autre logiciel, une bibliothèque ou dans le noyau d'un système d'exploitation. Certains peuvent modifier l'hyperviseur fonctionnant en dessous des systèmes ou le micrologiciel intégré dans un matériel. La plupart des rootkits servent à installer des logiciels malveillants sur les machines où l'accès est obtenu. Certains fournisseurs de matériels informatiques, tel Sony, les utilisent pour s'assurer du respect des conditions d'utilisation de leurs produits par leurs clients. Certains kits ne jouent pas sur la discrétion mais sur le fait qu'enlever le kit serait une opération ardue^{[L 2]}.

Pour l'« attaquant », l'utilité d'un rootkit est soit de mettre à disposition des ressources système (temps processeur, connexions réseaux, etc.) sur une, voire plusieurs machines (voir infra), parfois en utilisant la « cible » comme intermédiaire pour une autre attaque ; soit d'espionner, d'accéder aux données stockées ou en transit sur la machine cible^{[L 2]}.

Ils sont généralement classés parmi les logiciels malveillants, mais pas toujours^{[L 1]} ; ils peuvent utiliser des « techniques virales » pour se transmettre (par exemple, en utilisant un virus ou un cheval de Troie)^[5]. Il existe des outils de détection et des méthodes de protection pour les contrer mais elles ne sont pas totalement efficaces.

En 1989 sont apparus des programmes manipulant les logs système (un log est un « journal des opérations », sorte de livre de bord où sont enregistrées les informations concernant l'état et l'activité d'un ordinateur) pour cacher leur présence. D'autres programmes permettaient de se dissimuler en manipulant les outils servant à vérifier les informations sur les utilisateurs, telles que les commandes who, w, ou last^[6], et ainsi être invisibles pour les administrateurs des machines.

Les premiers rootkits sont apparus en 1994 sur Linux et SunOS^{[6],[C 1]} ; en 1998, sous Windows, avec le célèbre Back Orifice (voir infra) ; et en 2004 apparaissait le premier rootkit sous Mac OS X, WeaponX^[7].

Les analyses et les recherches sur les rootkits ont commencé à partir de 1997, avec la publication par le webzine Phrack d'un cheval de Troie détournant une partie du noyau Linux (le LKM, qui permet d'ajouter des modules au noyau pendant son fonctionnement)^{[C 1]} et ouvrant la porte aux techniques des rootkits actuels. Depuis, de nombreuses recherches et analyses ont été conduites : Phrack et plusieurs autres sites Web^[8] publient régulièrement des travaux sur les rootkits. Certains projets se sont spécialisés dans ce domaine, comme chkrootkit débuté en 1997, dédié au développement d’un outil de détection de rootkits pour les plates-formes Linux, * BSD (FreeBSD, OpenBSD…), Solaris et HP-UX.

La mise au jour de rootkits passe par leur publication ou se fait grâce aux honeypots, des machines sciemment vulnérables utilisées par les professionnels de la sécurité pour analyser le mode opératoire d'un attaquant. Les résultats obtenus sont régulièrement évoqués lors de conférences sur la sécurité, comme la conférence Black Hat.

Certains rootkits peuvent être légitimes, pour permettre aux administrateurs de reprendre le contrôle d'une machine défaillante, pour suivre un ordinateur volé^[9], ou dans certains outils comme des émulateurs de disque (DAEMON Tools, Alcohol 120%)^[10]. Mais le terme a perdu ce sens historique et évoque essentiellement des outils à finalité malveillante.

La première phase d'action d'un rootkit sert généralement à trouver un hôte vulnérable par balayage d'un ensemble d'adresses IP ou grâce à une base de données d'IP vulnérables^{[C 2]}.

L'étape suivante consiste à chercher à obtenir un accès au système, sans forcément que celui-ci soit un accès privilégié (ou en mode administrateur). Il existe trois manières de contaminer un système, en suivant les techniques habituelles des programmes malveillants.

Il est possible de mettre en œuvre un exploit, c'est-à-dire profiter d'une vulnérabilité de sécurité connue ou non, à n'importe quel niveau du système (application, système d'exploitation, BIOS, etc.).

Cette mise en œuvre peut être le fait d'un virus, mais elle résulte aussi, souvent, de botnets qui réalisent des scans de machines afin d'identifier et d'exploiter les failles utiles à l'attaque.

Même s'il n'est pas un virus à proprement parler, un rootkit peut utiliser des techniques virales pour se transmettre, notamment via un cheval de Troie. Un virus peut avoir pour objet de répandre des rootkits sur les machines infectées. A contrario, un virus peut aussi utiliser les techniques utilisées par des rootkits pour parfaire sa dissimulation^[11].

Enfin, l’attaque par force brute permet d'accéder au système, en profitant de la faiblesse des mots de passe mis en œuvre par certains utilisateurs. À ces fins, il suffit de tester les mots de passe les plus courants.

Des outils, nommés « autorooters », réunissent ces opérations de scan et d'exploit en une seule opération, ce qui peut faciliter la tâche de script kiddies^{[C 3]} en laissant toutefois bon nombre de traces sur le réseau.

Une fois la contamination effectuée et l'accès obtenu, la phase suivante consiste à installer, au moyen de son script d'installation, les objets et outils nécessaires au rootkit^{[C 2]} ; c'est-à-dire les objets (programmes, bibliothèques) permettant la mise en place de la charge utile du rootkit, s'ils n'ont pas pu être installés durant la phase de contamination, ainsi que les outils et les modifications nécessaires à la dissimulation^{[L 3]}.

L'opération consiste en l'ouverture de portes dérobées, afin de permettre le contrôle des machines (pc, serveurs, etc.), et, d'y installer la charge utile. Le tout, afin de pérenniser l'accès au système^[4],[12], ceci constitue une technique très fréquemment utilisée.

Le rootkit cherche à dissimuler son activité pour minimiser le risque qu'on le découvre, afin de profiter le plus longtemps possible de l'accès frauduleux, mais aussi pour rendre sa désinstallation difficile^{[L 2]}. Il va notamment dissimuler ses propres fichiers, les autres fichiers utilisés par l'attaquant, les processus qu'il exécute et les connexions qu'il va ouvrir^{[C 4]}. Cette faculté de dissimulation le différencie des virus, qui cherchent principalement à se répandre, bien que ces deux fonctions soient parfois jumelées pour une efficacité supérieure. Plusieurs méthodes de dissimulation peuvent être combinées.

La dissimulation de processus informatiques ou de fichiers permet de cacher l'activité du rootkit. Sous Windows, cela peut être réalisé en modifiant certaines clés de la base de registre ; sous systèmes Unix l'attaquant peut remplacer la commande ls pour qu'elle n'affiche pas certains dossiers^{[C 5]}. Une fois en place, le rootkit peut supprimer ses propres fichiers d'installation pour éviter qu'il ne soit reconnu par une recherche de fichiers^{[C 2]}.

Certains objets exécutables ou certaines bibliothèques sont remplacés par des programmes malveillants contrôlables à distance (chevaux de Troie), tout en conservant leur horodatage^{[C 5]}. Il est également possible de détourner certains appels aux tables de travail utilisées par le système^{[L 4]} par hooking, de manière que des programmes d'apparence légitime exécutent les fonctions voulues par l'attaquant.

L'obtention des droits supérieurs par élévation des privilèges est également fréquemment rencontrée : cela permet notamment de désactiver les mécanismes de défense (comme un anti-virus) ou d'agir sur des objets de haut niveau de privilèges (pilotes de périphériques, noyau du système, etc.) Un rootkit va ainsi pouvoir écouter les transactions sur le réseau pour trouver des mots de passe non chiffrés (comme des connexions ftp) ou détourner une connexion ssh en interceptant l'appel système où le mot de passe n'est pas encore chiffré^{[C 6]}.

Le rootkit tente de ne pas apparaître dans les fichiers log^{[C 4]}. Pour cela, il efface certaines entrées des logs ou, de manière beaucoup plus sophistiquée, utilisera des techniques de type « Stealth by Design » (« furtif par conception »)^[13], à savoir implémenter à l'intérieur du rootkit des fonctions système afin de ne pas avoir à appeler les fonctions standards du système d'exploitation et ainsi éviter l'enregistrement d'événements système suspects^{[C 4]}. Il peut ainsi désactiver certains daemons et l'historique des shells^{[C 2]}.

Enfin, certains rootkits peuvent se charger intégralement en mémoire, ne laissant ainsi aucune trace sur les périphériques de stockage de la machine^{[L 5]}.

En revanche, certaines activités ne pourront pas facilement être camouflées, notamment ce qui concerne la charge utile qui engendre de la charge réseau ou processeur (voir infra) ; l'effort de dissimulation se portera alors sur les communications entre le rootkit et l'attaquant pour protéger et maintenir l'accès frauduleux.

Un rootkit doit pouvoir être manipulé à distance par un attaquant. Celui-ci cherche donc souvent à maintenir un shell (ou « interpréteur de commandes ») disponible idéalement à n'importe quel moment (ou au moins durant l'installation du rootkit), en remplaçant des commandes comme ping ou xterm. Généralement, l'attaquant installe plusieurs de ces portes dérobées au cas où l'une viendrait à être découverte et supprimée^{[C 7]}.

L'accès distant au kit peut se faire par l'intermédiaire d'une connexion TCP, comme telnet ou ssh (qui peut être renversée, c'est-à-dire que c'est la machine infectée qui va chercher à rentrer en contact avec l'attaquant), UDP ou ICMP. Il existe aussi des méthodes plus complexes mais plus discrètes : port knocking, faux paquet TCP contenant une commande cachée, se faire passer pour une autre machine^{[C 7]}, canaux cachés, etc. Au besoin, les scripts de démarrage seront modifiés pour que les services nécessaires au rootkit soient disponibles après chaque redémarrage de la machine^{[C 2]}.

Pour que l'accès à la machine ne soit pas détourné par un autre attaquant, celui-ci peut corriger les failles du système infecté : celles qui lui ont permis de rentrer, voire l'ensemble des failles connues.

La charge utile est la partie active du rootkit (et de tout programme malveillant en général), dont le rôle est d'accomplir la (ou les) tâche(s) assignée(s).

Cette charge utile permet d'avoir accès aux ressources de la machine infectée^{[L 2]}, et notamment le processeur, pour décrypter des mots de passe, pour effectuer des calculs distribués à des fins malveillantes ou pour mettre en œuvre (ou détourner l'usage légitime) des applications comme un serveur de messagerie afin d'envoyer des mails (pourriel ou spam) en quantité. Les ressources réseaux intéressent également les attaquants, la machine pouvant alors servir de base pour d'autres attaques (DDoS^[14], exploits) ou pour inspecter, sniffer l'activité réseau.

Le remplacement du procédé de connexion (comme /bin/login sous les Unix) peut aussi fournir soit un accès de type porte dérobée (voir infra), soit un moyen de récupérer les informations d'authentification des utilisateurs de la machine. La compromission de pilotes de périphériques permet également d'installer des enregistreurs de frappe ou keyloggers (entre autres), afin de récupérer, en complément de l'activité réseau, des traces et des informations personnelles ou confidentielles, comme le seraient des données bancaires ou de connexion.

La machine infectée peut aussi devenir le point de départ pour d'autres attaques, sur internet, ou sur l'intranet, comme un déni de service^{[C 6]}. La prise de contrôle de la machine offre la possibilité de constituer un réseau de type botnet (la machine infectée devenant alors une machine zombie, comme dans le cas du botnet Srizbi^[15]), ou d'accéder à d'autres machines, par rebond.

Bien que le terme ait souvent désigné des outils ayant la faculté d'obtenir un niveau de privilège de type administrateur (utilisateur root) sur les systèmes Unix, un rootkit ne cherche pas obligatoirement à obtenir un tel accès sur une machine et ne nécessite pas non plus d'accès administrateur pour s'installer, fonctionner et se dissimuler^[16]. Le programme malveillant « Haxdoor »^[17], même s'il employait des techniques de type noyau^[18] pour parfaire sa dissimulation, écoutait les communications sous Windows en mode utilisateur^[19] : en interceptant les API de haut niveau, il recueillait des données confidentielles avant leur chiffrement.

Cependant, l'élévation de privilège est souvent nécessaire pour que le camouflage soit efficace : le rootkit peut utiliser certains exploits afin de parfaire sa dissimulation en opérant à un niveau de privilège très élevé, pour atteindre des bibliothèques du système, des éléments du noyau, pour désactiver les défenses du système^{[L 4]}, etc.

Un rootkit peut intervenir à un ou plusieurs niveaux du système parmi les cinq suivants : micrologiciel, hyperviseur, noyau, bibliothèque ou applicatif^{[C 8]}.

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^[20] 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^[9], 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^[21] 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^[22], mais cette méthode reste à tester et à confirmer^[23].

En novembre 2010, un chercheur français, Guillaume Delugré, publie une méthode pour remplacer le firmware d'une carte réseau très répandue sur le marché^[24]. Le rootkit s'exécute ainsi directement sur la carte, et donc sans modifier l'OS. L'usage des canaux DMA permet alors de manipuler l'OS.

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)^[25]. 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 »^[26], un outil permettant de sécuriser BitVisor et Xen — mais portable sur les hyperviseurs de type 1 — contre entre autres Blue Pill^[27] : 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.

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 GNU/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'appelle rootkit », rendant les fichiers du rootkit invisibles pour l'utilisateur^{[C 9]}. Adore est un de ceux-là : il remplace entre autres les appels à fork(), open() et write()^[28].

A contrario, SucKIT, publié dans l'article 0x07 du Phrack n^o 58^[29], est un rootkit noyau ne nécessitant pas de LKM^[30] (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^[31], où des écrans bleus sont apparus en raison d'un conflit entre le fonctionnement du rootkit Alureon et la correction de cette vulnérabilité^[32].

À 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, (voir infra) –, 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 GNU/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 tout ce qui pourrait révéler la présence du kit, sans toucher aux exécutables systèmes (ps, ls, etc.)^{[C 10]}

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ée 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^{[C 5]}.

Cette méthode n'est pas efficace si ces programmes sont régulièrement recompilés à partir des sources^{[L 6]}.

À deux reprises, Sony a été confronté à la présence masquée de rootkits dans ses produits : dans ses clés usb biométriques et dans son composant de gestion numérique des droits (DRM)^[33],[34], nommé « XCP » (pour « Extended Copy Protection »), présent sur 52 CD audio (dont certains de Céline Dion et de Sarah McLachlan). L'entreprise cherchait à réduire le nombre de copies illégales de ses disques en limitant le droit de copie et en traçant la circulation des CD par internet.

Le kit XCP, présent sur quatre millions de CD produits en 2005^[35], est parfois instable et possède lui-même des failles qui peuvent être exploitées, permettant notamment de tricher sous World of Warcraft ou de créer un virus l'utilisant^[36]. En revanche, XCP peut être facilement déjoué en maquillant la deuxième piste du CD^[37] : la piste n'étant plus lisible, le rootkit ne peut pas s'activer. De plus, il ne fonctionne que sur les systèmes d'exploitation de type Windows^[38].

XCP se connecte régulièrement aux serveurs de Sony pour envoyer l'identifiant du disque audio que l'utilisateur écoute. Il empêche la lecture du CD par un autre logiciel que celui fourni par Sony, et limite le nombre de copies (gravure et rip) du disque^[39]. Une analyse du groupe Gartner montre que XCP se comporte comme un logiciel malveillant sur plusieurs points : téléchargements cachés, informations concernant son fonctionnement cachées dans la licence d'utilisation, absence d'utilitaire de désinstallation et envoi obligatoire d'un mail contenant des informations personnelles et sur le système pour en recevoir un, envoi de certaines informations à des serveurs de Sony sans information préalable à l'utilisateur^[40]. Gartner met en avant le cas XCP pour montrer que ce type de DRM n'est pas à envisager par une entreprise car il est inefficace, illégal sous certains aspects et dommageable pour le client^[37]. Il apparaît aussi que XCP se base sur des logiciels libres sans en respecter la licence, c'est-à-dire en redistribuant le code source produit^[39] : il utilise le code source de DVD Jon^[41].

Finalement, XCP était présent sur un nombre limité de CD et son impact sur la contrefaçon n'a pas été évalué. Ces affaires ont fait un tort important à Sony, qui a fini par abandonner ces logiciels, aussi bien pour sa respectabilité que financièrement. Dans plusieurs pays, Sony a été poursuivi en justice et obligé de reprendre les CD contenant un rootkit et de dédommager les clients. En 2007, aux États-Unis, Sony est condamné à rembourser jusqu'à 150 $ par acheteur pour un total de 5,75 millions de dollars^[35]. En 2009 en Allemagne, un travailleur indépendant a obtenu gain de cause en touchant 1 200 € de dommages et intérêts car le kit avait fait perdre du temps et des données à son entreprise^[41]. Pour ses rootkits, Sony a été nommé aux Big Brother Awards 2006^[39].

Le CERTA (Centre d'Expertise Gouvernemental de Réponse et de Traitement des Attaques informatiques de l'État français) a publié, dans une note d'information, l'analyse d'une attaque ayant permis d'installer un rootkit (non identifié, mais dont les caractéristiques semblent correspondre au rootkit « Rk »^{[C 11]}), n'utilisant à l'origine qu'une seule faille, laquelle concernait le module d'impression LPRng présents dans certains systèmes Linux (faille répertoriée CERTA-2000-AVI-087^[42]). Cette faille, qui aurait pu être corrigée soit par la mise à jour du système, soit par le blocage d'un port spécifique grâce à un pare-feu^[43], permettait l'exécution à distance de code arbitraire.

Cette attaque a été menée en moins de deux minutes. L'attaquant a identifié la vulnérabilité, puis envoyé une requête spécialement formée sur le port 515 (qui était le port exposé de cette vulnérabilité) pour permettre l'exécution d'un code arbitraire à distance. Ce code, nommé « SEClpd », a permis d'ouvrir un port en écoute (tcp/3879) sur lequel le pirate est venu se connecter pour déposer une archive (nommée rk.tgz, qui contenait un rootkit) avant de la décompresser et de lancer le script d'installation.

Ce script a fermé certains services, installé des chevaux de Troie, caché des processus, envoyé un fichier contenant les mots de passe du système par mail, et il est même allé jusqu'à corriger la faille qui a été exploitée, afin qu'un autre pirate ne vienne pas prendre le contrôle de la machine.

Back Orifice est un rootkit client-serveur développé à partir de 1998 par le Cult of the Dead Cow, un groupe de hackers. Il permet de prendre le contrôle des ordinateurs utilisant Windows 95/98, puis NT^[44]. Le CDC revendique plusieurs centaines de milliers de téléchargements de la version de base « BO » et de la version améliorée « BO2K » en quelques semaines^[45]. Back Orifice est certainement un des rootkits qui s'est le plus répandu, même si aujourd'hui ses cibles se sont raréfiées.

L'altération de la machine cible se fait en exécutant un programme qui va se charger à chaque démarrage de la machine. Cette altération est possible car les systèmes d'exploitation Windows 95/98 n'offrent pas de mécanismes de sécurité basiques tels que le chiffrement des mots de passe stockés (ils sont stockés en clair), ou le contrôle du droit d'exécution d'un programme (tout le monde peut exécuter n'importe quelle application, et même reconfigurer le système). Le client, utilisable sous Windows et Unix, est graphique et permet même à un non-initié de contrôler une machine infectée^[44].

La désinstallation du kit est simple : il suffit de supprimer l'exécutable résident et de retirer une clé de la base de registre. La plupart des antivirus le reconnaissent comme un virus.

TDL-4 est un trojan, qui installe un rootkit pour construire un botnet. Le rootkit s'installe sur le MBR du disque dur ce qui le rend difficile à détecter et à déloger. De plus, il utilise un système de cryptage complexe et un réseau pair-à-pair public (Kad) pour recevoir ses commandes. Il a la particularité de pouvoir désactiver les infections présentes sur la même machine pour ne pas être découvert par inadvertance, et d'installer ses propres outils de DDoS, de spamming… Selon Kaspersky Lab, il y aurait 4,5 millions de machines infectées (fin juin 2011)^[46].

La mise en œuvre d'une détection peut, selon le type de rootkit, demander un examen du système ou d'un périphérique suspect en mode « inactif » (démarrage à partir d'un système de secours ou d'un système réputé sain). Plusieurs méthodes existent.

La recherche d'objets cachés (tels que des processus informatiques, des clés de registre, des fichiers, etc.) est essentielle. Des outils comme unhide sous Linux peuvent révéler les processus cachés. Sous Windows, des outils comme RootkitRevealer recherchent les fichiers cachés en listant les fichiers via l'API normale de Windows puis en comparant cette liste à une lecture physique du disque ; les différences entre les deux sont alors repérées comme suspectes, à l'exception des fichiers légitimes connus de Windows, tels que les fichiers de métadonnées de NTFS comme $MFT ou $Secure^[47].

Le contrôle de l'intégrité des fichiers consiste à calculer, pour chaque fichier sensible (bibliothèque, commande système, etc.), une empreinte^[13]. Toute modification inattendue de cette empreinte indique une modification du fichier, et donc une contamination potentielle. Cependant, tout système subit des modifications légitimes lors des mises à jour ; idéalement, l'outil de contrôle a la possibilité d'accéder à une base de référence de ces sommes de contrôles, selon la version du système utilisée (rkhunter par exemple).

La détection de signatures spécifiques est le procédé classique d'analyse de signature, comme cela se fait pour les virus : on cherche à retrouver dans le système la trace d'une infection, soit directement (signature des objets du rootkit), soit par le vecteur d'infection (virus utilisé par le rootkit)^[13].

L’analyse des appels systèmes, des tables d'interruption^[48],[49], et de manière générale, des tables de travail utilisées par le système, au moyen d'outils spécifiques (des logiciels anti-espion comme HijackThis), permet de voir si ces appels ont été détournés ou non, par exemple en comparant ce qui est chargé en mémoire avec les données brutes de bas niveau (ce qui est écrit sur le disque).

On peut aussi s'intéresser à la charge du système. Du point de vue du processeur et de l'activité applicative, une surveillance continue peut mettre en évidence une surcharge, à partir du moment de la contamination. Il s'agit essentiellement d'une analyse de la charge habituelle de la machine, comme le nombre de mails sortants ou l'occupation du processeur. Toute modification (en surcharge) sans cause apparente est suspecte, mais elle nécessite une analyse complémentaire pour écarter les causes légitimes (mise à jour du système, installation de logiciels, etc.)

De la même manière, l’analyse des flux réseau^[50] permet de détecter une surcharge anormale. Mais il convient également de surveiller une utilisation de ports logiciels inhabituels grâce aux traces issues d'un pare-feu ou grâce à un outil spécialisé. Il est également possible de faire une recherche des ports ouverts et cachés, en comparant ce que connaît le système avec ce qui est effectivement ouvert, grâce à des outils d'investigation comme unhide-tcp. Toute différence peut être considérée comme anormale. Il existe cependant des moyens de dissimulation réseau, comme de la stéganographie ou l'utilisation de canaux cachés, qui rend la détection directe impossible, et nécessite une analyse statistique qui n'est pas forcément déterminante^[51].

L’analyse automatisée des logs système^[52] s'appuie sur le principe de corrélation, avec des outils de type HIDS qui disposent de règles paramétrables^[53] pour repérer les événements anormaux et mettre en relation des événements systèmes distincts, sans rapport apparent ou épars dans le temps.

Le site du Cert-IST propose régulièrement des informations sur les rootkits et les logiciels malicieux en général^[54].

Les moyens de détection peuvent également servir à la prévention, même si celle-ci sera toujours postérieure à la contamination. D'autres mesures en amont peuvent rendre difficile l'installation d'un rootkit^[55].

La correction des failles par mise à jour du système d'exploitation permet de réduire la surface d'exposition du système en limitant le temps pendant lequel une faille est présente sur le système^[56] et dans les applications^[52], afin de prévenir les exploits pouvant être utilisés pour la contamination.

L’utilisation d'un pare-feu, qui fait partie des bonnes pratiques dans le domaine de la sécurité informatique, se révèle efficace dans le cas des rootkits^{[49],[52],[56]} car cela empêche les communications inattendues (téléchargements de logiciel, dialogue avec un centre de contrôle et de commande d'un botnet, etc.) dont ont besoin les rootkits.

Il est possible de désactiver le système de chargement de modules en rendant le noyau statique, ce qui protège contre les rootkits qui s'installent en chargeant un module ; certains rootkits arrivent cependant à contourner cela en reconnaissant l'empreinte du module directement dans la mémoire^{[C 9]}.

De même, pour renforcer la robustesse des bibliothèques et empêcher le hooking, il est possible de compiler statiquement les bibliothèques^{[C 10]}.

Des systèmes de prévention d'intrusion^[52], sous forme de logiciel ou de matériel, répondent dès qu'une intrusion est détectée, en bloquant des ports ou en interdisant la communication avec une source (adresse IP) douteuse, ou toute autre action appropriée. La détection sera d'autant meilleure que l'outil utilisé sera externe au système examiné, puisque certains rootkits peuvent atteindre des parties de très bas niveau dans le système, jusqu'au BIOS. Un des avantages de ces outils est l'automatisation des tâches de surveillance^[13].

Des outils spécialisés de contrôle d'intégrité des fichiers peuvent produire des alertes lors de modifications inattendues. Cependant, ce contrôle à lui seul est insuffisant si d'autres mesures préventives ne sont pas mises en œuvre, si aucune réponse du système n'est déclenchée ou si ces différences ne sont pas analysées.

Le renforcement de la robustesse des mots de passe est une autre des bonnes pratiques de sécurité informatique qui élimine une des sources principales de contamination. Des éléments d'authentification triviaux sont des portes ouvertes pour tout type d'attaque informatique.

Le démarrage du système à partir d'une image saine, contrôlée et réputée valide du système d'exploitation, via un support fixe (comme un LiveCD, une clé USB) ou par réseau, permet de s'assurer que les éléments logiciels principaux du système ne sont pas compromis, puisqu'à chaque redémarrage de la machine concernée, une version valide de ces objets est chargée. Un système corrompu serait donc remis en état au redémarrage (sauf dans le cas de rootkit ayant infecté un plus bas niveau, comme le BIOS).

Les moyens de protection habituels sont également valables contre les rootkits : « Do everything so that attacker doesn’t get into your system »^[51]. Durcissement du système^[49], filtrages applicatifs (type modsecurity), utilisation de programmes antivirus^[49],[56] pour minimiser la surface d'attaque et surveiller en permanence les anomalies et tentatives de contamination, sont bien sûr à mettre en œuvre pour éviter la contamination du système et l'exposition aux exploits.

 : document utilisé comme source pour la rédaction de cet article.

• Greg Hoglund et James Butler (trad. Freenet Sofor ltd.), Rootkits : infiltrations du noyau Windows [« Rootkits: Subverting the Windows »], Paris, Campus Press, 2006 (1^re éd. 2005), 338 p. (ISBN 978-2-7440-2076-6, OCLC 145848531)
• (en) Larry Stevenson et Nancy Altholz, Rootkits for dummies, Indianapolis, Ind, Wiley Pub., coll. « For dummies », 2007, 380 p. (ISBN 978-0-471-91710-6, OCLC 85824660, lire en ligne)
• (en) Ric Vieler, Professional rootkits, Indianapolis, IN, Wiley/Wrox, coll. « Wrox professional guides », 2007, 334 p. (ISBN 978-0-470-10154-4, OCLC 77116927, présentation en ligne)
• (en) Bill Blunden, The rootkit arsenal : escape and evasion in the dark corners of the system, Plano, Tex, Wordware Pub., juin 2009, 908 p. (ISBN 978-1-59822-061-2, OCLC 297145864, lire en ligne)
• Joseph Kong (trad. de l'anglais), Rootkits BSD : Mieux les comprendre pour mieux s'en protéger, Paris, CampusPress, coll. « Sécurité Informatique », 14 novembre 2007, 148 p. (ISBN 978-2-7440-2220-3)
• (en) Anton Chuvakin, « An Overview of Unix Rootkits », iALERT White Paper, Chantilly, VA, iDefense Labs,‎ février 2003, p. 27 (lire en ligne [PDF])
• [PDF] E. Lacombe, F. Raynal, V. Nicomette, « De l’invisibilité des rootkits : application sous Linux », CNRS-LAAS/Sogeti ESEC, juin 2007 (consulté le 24 septembre 2014)

• Source Chuvakin :

• Source Lacombe :

• Autres sources

• Liste de logiciels de sécurité informatique
• Loadable Kernel Module
• Packet sniffer
• Vulnérabilité (informatique)
• Porte dérobée

• Notice dans un dictionnaire ou une encyclopédie généraliste :

  • Britannica
• Notices d'autorité :

  • LCCN
  • GND
  • Israël
• Vidéo sur le rootkit Trojan.Alureon/Trojan.TDSS

• Portail de la sécurité informatique