Rootkit

Pronunciation of Rootkit in US English

Un rootkit (le nom « outil de dissimulation d'activité » est également utilisé^[1]), parfois simplement « kit », 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 de la manière la plus furtive possible^{[2],[C 1],[L 1]}, à la différence d'autres logiciels malveillants. Le terme peut désigner la technique de dissimulation ou, par métonymie, 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 au-dessus 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)^[3]. Il existe des outils de détection et des méthodes de protection pour les contrer mais elles ne sont pas totalement efficaces.

En 2008, un PC sur six contenait un rootkit^[4].

Historique

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^[5], et ainsi être invisibles pour les administrateurs des machines.

Les premiers rootkits sont apparus en 1994 sur Linux et SunOS^{[5],[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^[6].

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^[7] 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é^[8], ou dans certains outils comme des émulateur de disque (DAEMON Tools, Alcohol 120%)^[9]. Mais le terme a perdu ce sens historique et évoque essentiellement des outils à finalité malveillante.

Mode opératoire

Contamination

La première phase d'action d'un rootkit consiste 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 pour identifier et exploiter les failles qui sont 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 par 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^[10].

Enfin, l’attaque par force brute permet d'accéder au système en profitant de la faiblesse des mots de passe de certains utilisateurs : 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, ce qui peut faciliter la tâche de script kiddies^{[C 3]} en laissant toutefois beaucoup de traces sur le réseau.

Modification du système et dissimulation

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'ouverture de portes dérobées, afin de permettre le contrôle de la machine, d'installer la charge utile et de pérenniser l'accès au système^[2],[11] est une technique très fréquente.

Dissimulation

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 à ce 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 »)^[12], à 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.

Maintien de l'accès

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.

Mise en place de la charge utile

Un botnet permet d'avoir un accès sur des centaines de machines.

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^[13], 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^[14]), ou d'accéder à d'autres machines, par rebond.

Niveau de privilège

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^[15]. Le programme malveillant « Haxdoor »^[16], même s'il employait des techniques de type noyau^[17] pour parfaire sa dissimulation, écoutait les communications sous Windows en mode utilisateur^[18] : 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.

Types

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

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

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é^[23]. 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.

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

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

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

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é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]}.

Exemples

Rootkits Sony

À deux reprises, Sony a été confronté à la présence masquée de rootkits dans ses produits : dans ses clés usb biométriques^[32] 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 4 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 les code source de DVD Jon^[41].

Au final, 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^[42]. 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].

Exploitation de la vulnérabilité de LPRng

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^[43]). 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^[44], 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 a même été 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

Article détaillé : Back Orifice.

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^[45]. 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^[46]. 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^[45].

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

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, il y aurait 4.5 millions de machines infectées (fin juin 2011)^[47].

Prévention

Moyens de détection

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^[48].

Le calcul régulier des empreintes de fichiers sensibles permet de détecter une modification inattendue.

Le contrôle de l'intégrité des fichiers consiste à calculer, pour chaque fichier sensible (bibliothèque, commande système, etc.), une empreinte^[12]. 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)^[12].

L’analyse des appels systèmes, des tables d'interruption^[49],[50], 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).

Le hooking consiste à détourner un appel de fonction légitime par un autre qui contient du code malveillant.

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^[51] 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^[52].

L’analyse automatisée des logs système^[53] s'appuie sur le principe de corrélation, avec des outils de type HIDS qui disposent de règles paramétrables^[54] 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^[55].

Moyens de protection et de prévention

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^[56].

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^[57] et dans les applications^[53], 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^{[50],[53],[57]} 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]}.

La complexité d'un mot de passe est proportionnelle à sa taille et au nombre de caractères différents qu'il utilise. Un mot de passe complexe sera plus long à deviner dans une attaque par force brute.

Des systèmes de prévention d'intrusion^[53], 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^[12].

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, puisque à 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 »^[52]. Durcissement du système^[50], filtrages applicatifs (type modsecurity), utilisation de programmes antivirus^[50],[57] 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.

Outils et logiciels de détection

À part quelques cas particuliers, l'industrie de la sécurité informatique a tardé à prendre en compte les rootkits, les virus puis les chevaux de Troie accaparant l'attention des éditeurs. Il existe cependant quelques logiciels de détection et de prévention spécifiques à Windows, tels que Sophos Anti-Rootkit ou AVG Anti-Rootkit. Sous Linux, on peut citer rkhunter et chkrootkit ; plusieurs projets open-source existent sur Freshmeat et Sourceforge.net.

Aujourd'hui, il reste difficile de trouver des outils spécifiques de lutte contre les rootkits, mais leur détection et leur prévention sont de plus en plus intégrées dans les systèmes de prévention d'intrusion et même dans les antivirus classiques, lesquels sont de plus en plus obligés de se transformer en suites de sécurité pour faire face à la diversité des menaces ; ils proposent en effet de plus en plus souvent des protections contre les rootkits. C'est le cas d'Avast^[58] , AVG 8.0^[59] ou Microsoft Security Essentials^[60].

Bibliographie

 : Ouvrage 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 9782744020766) (OCLC 145848531) 
• (en) Larry Stevenson et Nancy Altholz, Rootkits for dummies, Indianapolis, Ind, Wiley Pub., coll. « For dummies », 2007, 380 p. (ISBN 9780471917106) (OCLC 85824660) [lire en ligne (page consultée le 19 avril 2010)] 
• (en) Ric Vieler, Professional rootkits, Indianapolis, IN, Wiley/Wrox, coll. « Wrox professional guides », 2007, 334 p. (ISBN 9780470101544) (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 9781598220612) (OCLC 297145864) 
• Joseph Kong, Rootkits BSD - Mieux les comprendre pour mieux s'en protéger, CampusPress, coll. « Sécurité Informatique », 14 novembre 2007, 148 p. (ISBN 978-2744022203) 
• (en) Anton Chuvakin, « An Overview of Unix Rootkits », dans iALERT White Paper, Chantilly, VA, iDefense Labs, février 2003, p. 27 [texte intégral [PDF] (page consultée le 30 mars 2010)] 
• [PDF] E. Lacombe, F. Raynal, V. Nicomette, « De l’invisibilité des rootkits : application sous Linux », CNRS-LAAS/Sogeti ESEC, juin 2007. Consulté le 24 avril 2010

Notes et références

• Source Chuvakin :

1. ↑ ^{a, b et c} Chuvakin (2003), p. 3 : Executive Summary
2. ↑ ^{a, b, c, d et e} Chuvakin (2003), p. 14 : Usage
3. ↑ Chuvakin (2003), p. 25 : End Notes
4. ↑ ^{a, b et c} Chuvakin (2003), p. 8-9 : Concealing Evidence
5. ↑ ^{a, b et c} Chuvakin (2003), p. 10-12 : Binary Rootkits
6. ↑ ^{a et b} Chuvakin (2003), p. 7-8 : Attack Other Systems
7. ↑ ^{a et b} Chuvakin (2003), p. 4-7 : Maintain Access
8. ↑ Chuvakin (2003), p. 10 : Types of Rootkits
9. ↑ ^{a et b} Chuvakin (2003), p. 12-13 : Kernel Rootkits
10. ↑ ^{a et b} Chuvakin (2003), p. 13-14 : Library Kits
11. ↑ Chuvakin (2003), p. 22 : Rk: Hidden but Not Enough

• Source Lacombe :

1. ↑ ^{a et b} Lacombe (2007), Définition d’un rootkit et comparaison avec les autres codes malicieux, p. 8
2. ↑ ^{a, b, c et d} Lacombe (2007), Vers l’évaluation d’un rootkit, p. 14
3. ↑ Lacombe (2007), L’architecture fonctionnelle d’un rootkit, p. 9
4. ↑ ^{a et b} Lacombe (2007)
5. ↑ Lacombe (2007), La communication avec le rootkit, p. 11
6. ↑ Lacombe (2007), Évolution des rootkits, p. 4

• Autres sources

1. ↑ Note d'information du CERTA, Objet : Terminologie d'usage au CERTA, Centre d'expertise gouvernemental de réponse et de traitement des attaques informatiques. Consulté le 8 mars 2010
2. ↑ ^{a et b} (en) What is rootkit?, WhatIs.com. Consulté le 16 mars 2010
3. ↑ Un rootkit falsifie le noyau du système d'exploitation, mais il n'est pas un vecteur de diffusion. Voir à ce sujet la section Mode opératoire.
4. ↑ Logiciels malveillants : un PC sur six renferme un rootkit
5. ↑ ^{a et b} (en) [PDF] Linux kernel rootkits: protecting the system's « Ring-Zero », SANS Institute, mars 2004, p. 10,11
6. ↑ (en) ghalen and wowie, « Developing Mac OSX kernel rootkits », Phrack Magazine, juin 2009
7. ↑ (en) Daniel B. Cid, « RootCheck » sur ossec.net, mars 2006. Mis en ligne le 7 mars 2006, consulté le 25 mars 2010
8. ↑ ^{a et b} [PDF] (en) FAQ LoJack for Laptops, AbsoluteSoftware
9. ↑ avg.com, foire aux questions, n°2346, AVG Technologies
10. ↑ Alisa Shevchenko, « Évolution des rootkits » sur viruslist.com, Kaspersky Lab, 29 août 2008. Consulté le 30 avril 2010
11. ↑ (en) Concept of rootkit
12. ↑ ^{a, b, c et d} [ppt] (en) J. Rutkowska, « Rootkits vs. Stealth by Design Malware », invisiblethings.org, 2 mars 2006
13. ↑ Le déni de service politique se banalise en Asie du Sud-Est, ZDNet.fr, 5 novembre 2010
14. ↑ (en) Botnet Spams 60 Billion Emails A Day, CyberInsecure.com, 9 mai 2008
15. ↑ (en) B. Cogswell, M. Russinovich, « RootkitRevealer », Microsoft (Windows Sysinternals), novembre 2006
16. ↑ (en) Haxdoor, F-Secure
17. ↑ (en) Rootkit Pharming, F-Secure, 24 février 2006
18. ↑ Les rootkits et la fraude bancaire, Cert-IST, 2006
19. ↑ (en) Anibal Sacco et Alfredo Ortega, « Persistent BIOS Infection », Phrack Magazine, juin 2009
20. ↑ (en) New BIOS Virus Withstands HDD Wipes, Tom's Hardware, 27 mars 2009
21. ↑ Ils ont inventé le virus de BIOS, presence-pc.com, mars 2009
22. ↑ (en) New Bios attack renders anti-virus useless, v3.co.uk, 26 mars 2009
23. ↑ (en) Guillaume Delugré, « Presentation at Hack.lu : Reversing the Broacom NetExtreme's firmware », Sogeti ESEC Lab, 21 novembre 2010
24. ↑ [PDF] (en) Samuel T. King, Peter M. Chen, Yi-Min Wang, Chad Verbowski, Helen J. Wang, Jacob R. Lorch, « SubVirt: Implementing malware with virtual machines », 2006
25. ↑ Zhi Wang, Xuxian Jiang, HyperSafe: A Lightweight Approach to Provide Lifetime Hypervisor Control-Flow Integrity, 31^e conférence IEEE Symposium on Security and Privacy, Oakland, CA, mai 2010
26. ↑ Joab Jackson, « Researchers to cure Blue Pill virtualization attacks », IDG News Service, 7 mai 2010. Consulté le 11 mai 2010
27. ↑ (en) Steve Terrell, « Discovery, Eradication and Analysis of an attack on an open system: Welcome to the Jungle », dans SANS Institute (InfoSec Reading Room), 17 juin 2003, p. 25 [texte intégral [PDF] (page consultée le 27 avril 2010)] 
28. ↑ (en) sd et devik, « Linux on-the-fly kernel patching without LKM », dans Phrack, n^o 58, 28 décembre 2001 [texte intégral (page consultée le 27 avril 2010)] 
29. ↑ Rainer Wichmann, « Linux Kernel Rootkits », 2006. Consulté le 27 avril 2010
30. ↑ Bulletin de sécurité MS10-015, Microsoft, février 2010
31. ↑ Microsoft : le rootkit Alureon responsable de BSOD sur XP, pcinpact.com, février 2010
32. ↑ Rootkit sur clé USB: l'incroyable 'erreur' de Sony, silicon.fr, 3 septembre 2007
33. ↑ Un rootkit dans les DRM de Sony, generation-nt.com (GNT Media), novembre 2005
34. ↑ Sony intègre puis retire un rootkit de ses CD audio protégés, secuobs.com, novembre 2005
35. ↑ ^{a et b} Cédric B, « Sony BMG poursuit son fournisseur de rootkits » sur generation-nt.com, 13 juillet 2007. Consulté le 21 avril 2010. « Le japonais [Sony] a utilisé celle-ci sur environ 4 millions de disques en 2005. »
36. ↑ David Civera, « Premier virus utilisant le rootkit Sony » sur presence-pc.com, 10 novembre 2005. Consulté le 20 avril 2010
37. ↑ ^{a et b} [PDF] (en) Martin Reynolds, Mike McGuire, « Sony BMG DRM a Public-Relations and Technology Failure », Gartner, 18 novembre 2005. Consulté le 20 avril 2010. « The user simply applies a fingernail-sized piece of opaque tape to the outer edge of the disc, rendering session 2 — which contains the self-loading DRM software — unreadable »
38. ↑ (en) Bill Thompson, « The rootkit of all evil? », BBC News, 4 novembre 2005. Mis en ligne le 4 novembre 2005, consulté le 23 avril 2010. « If you have got a Mac or a Linux box then you can play and even copy you disc happily ... »
39. ↑ ^{a, b et c} Sony-BMG et son "rootkit" espion sur bigbrotherawards.eu.org, 2006. Consulté le 20 avril 2010
40. ↑ [PDF] (en) Ray Wagner, Mike McGuire, Jay Heiser, Peter Firstbrook, « Sony's Approach to Content Protection Is Short-Sighted », Gartner, 9 novembre 2005. Consulté le 20 avril 2010. « It [XCP] was deliberately designed to be difficult to remove »
41. ↑ ^{a et b} Julien L, « Affaire rootkit de Sony : des utilisateurs obtiennent un dédommagement financier » sur numerama.com, 14 septembre 2009. Consulté le 30 avril 2010
42. ↑ Affaire rootkit : Sony BMG règle son conflit avec la FTC, ITespresso.fr, février 2007
43. ↑ Avis CERTA-2000-AVI-087, CERTA, 13 décembre 2000
44. ↑ Chronique d'un incident ordinaire, CERTA, 13 décembre 2000
45. ↑ ^{a et b} Jean-Claude Bellamy, « Tout ce que vous avez voulu savoir sur Back Orifice », 1998. Consulté le 19 avril 2010
46. ↑ (en) cDc, « BO2K Pressrelease » sur bo2k.com, 10 juillet 1999. Consulté le 19 avril 2010
47. ↑ (en) Gregg Keizer, « Massive botnet 'indestructible,' say researchers » sur computerworld, 29 juin 2011. Consulté le 30 juin 2011
48. ↑ RootkitRevealer : la riposte aux rootkits Windows, Cert-IST
49. ↑ (en) Rootkit detection, removal and prevention, 17 février 2006
50. ↑ ^{a, b, c et d} (en) Rootkit and malware detection and removal guide, ComputerWeekly, 3 juillet 2007
51. ↑ (en) Rooting out a rootkit: Stage one -- Diagnosis, techtarget.com, 10 août 2005
52. ↑ ^{a et b} [ppt] (en) J. Rutkowska, « Fighting Stealth Malware – Towards Verifiable OSes », invisiblethings.org, 28 décembre 2008
53. ↑ ^{a, b, c et d} (en) Linux RootKits For Beginners - From Prevention to Removal, SANS Institute, 23 janvier 2006, p. 5 et suivantes
54. ↑ [PDF] (en) D. Cid, « Log Analysis using OSSEC », ossec.net, 2007, p. 13 et suivantes
55. ↑ Le CERT dédié à la communauté Industrie, Services et Tertiaire française sur cert-ist.com. Consulté le 4 mai 2010
56. ↑ (en) Understanding Hidden Threats: Rootkits and Botnets, US-CERT, 2006
57. ↑ ^{a, b et c} (en) Rooting out a rootkit: Stage four -- Preventative measures, techtarget.com, 10 août 2005
58. ↑ Download avast! Free Antivirus 6 sur avast.com. Consulté le 9 mars 2011
59. ↑ (en) FAQ : How to deal with rootkits? sur avg.com. Consulté le 9 mars 2011
60. ↑ (en) Security Essentials fares well in AV-Test trial sur cnet.com. Consulté le 9 mars 2011

Voir aussi

Sur les autres projets Wikimedia :

• « Rootkit », sur Wikimedia Commons (ressources multimédia)
• « Rootkit », sur Wikiquote (recueil de citations)

Articles connexes

• Vulnérabilité, Porte dérobée
• Packet sniffer
• Liste de logiciels de sécurité informatique

Liens externes

• Le danger et fonctionnement des rootkits
• (en) antirootkit.com, site (ancien) listant de nombreux outils
• Vidéo sur le rootkit Trojan.Alureon/Trojan.TDSS

Cet article est reconnu comme « bon article » depuis sa version du 15 mars 2011 (comparer avec la version actuelle). Pour toute information complémentaire, consulter sa page de discussion et le vote l’ayant promu. La version du 15 mars 2011 de cet article a été reconnue comme « bon article », c'est-à-dire qu'elle répond à des critères de qualité concernant le style, la clarté, la pertinence, la citation des sources et l'illustration.