Évolution des rootkits

Cet article est le second d’une série consacrée à l’évolution des virus et des solutions antivirus. Cette évolution, telle que je me la représente, est un ensemble chronologique d’événements dans lequel il est possible de tirer un fil conducteur permettant de connecter logiquement une suite de changements. L’objectif étant bien sûr d’exposer chaque sujet de manière claire, à la fois logique et chronologique.

Introduction

Ma première rencontre avec un rootkit date de 2004, alors que j’en étais à mes débuts d’analyses antivirales. Je n’avais à ce stade qu’une vague idée des rootkits sous Unix. Un jour, je suis me suis heurtée à un exécutable pour Windows qui semblait ne rien faire une fois lancé. Cela m’a paru étrange aussi j’étudiais le phénomène de plus près et… j’ai alors découvert, en examinant la liste des modules chargés, un fichier qui n’était pourtant pas présent sur le disque. Évidemment, j’avais de la chance de l’apercevoir à l’œil nu – ce rootkit contenait des erreurs de code. Aujourd’hui, il me faudrait recourir à plusieurs outils spécialisés pour parvenir à ce résultat, effacer leur présence des listes de processus.

Le spécimen rencontré n’était pas, loin s’en faut, le premier rootkit sous Windows. Malgré tout, il s’agissait pour moi d’une première rencontre, et elle m’a permis d’accéder à un monde pour moi nouveau ; un monde où des programmes étaient capables de contourner les règles du système d’exploitation et, de façon quasiment miraculeuse, d’effacer leur présence des listes de processus et de fichiers. J’ai passé de longues heures à étudier des gestionnaires que le logiciel mettait en œuvre pour parvenir à se rendre invisible au système. Ce programme, Trojan-Dropper.Win32.SmallProxy, était conçu pour cibler un système particulier et pour se déployer dans des emplacements spécifiques – ce qui était une démarche relativement complexe et peu fréquente à l’époque.

Cet article se concentre principalement sur les rootkits sous Windows. Ils sont les plus nombreux, ils évoluent en permanence, ils supposent une menace sérieuse pour les utilisateurs et, parce que Windows est l’O.S. le plus répandu de nos jours, ils sont aussi les plus utilisés par les auteurs de virus. Nous pouvons définir un rootkit comme un programme mettant en œuvre des techniques furtives lui permettant d’échapper, ou de contourner les mécanismes standard du système dans le but masquer des objets système : fichiers, processus, gestionnaires, services, clés du registre, ports ouverts, connexions, etc.

Rootkits UNIX

Une présentation sur le thème des « rootkits » nécessite un rappel de l’étymologie de ce mot. Dans les systèmes Unix, le mot « root » désigne un administrateur avec tous les privilèges, tandis que le mot « kit » fait référence à un ensemble d’outils. Par conséquent, le terme « rootkit » désigne un ensemble d’outils pouvant être utilisé de façon malveillante pour avoir accès au système, à l’insu du véritable administrateur. Sous UNIX, de tels outils sont apparus pour la première fois au début des années 90. Ils existent toujours, mais leur évolution n’est plus significative.

Toutefois, il est important de retenir que si les « rootkits » sous Windows ont repris l’appellation employée dans l’univers UNIX, les logiciels malveillants de ce type sous Windows sont en fait des descendants directs des virus furtifs sous DOS, et non pas de véritables rootkits UNIX.

Virus furtifs

Les virus furtifs sous DOS sont apparus aux alentours de 1990 ; en même temps que les rootkits UNIX, ou un peu avant. À la différence d’un rootkit UNIX, conçu pour donner à son auteur un accès complet au système tout en dissimulant sa présence, un virus furtif sous DOS se contentait de rester invisible à l’utilisateur et aux applications antivirus. Or, c’est exactement ce que font les rootkits modernes sous Windows. Les techniques employées par les virus furtifs sous DOS ressemblent fortement à celles utilisées aujourd’hui par les rootkits sous Windows. Par exemple, les virus furtifs font appel à des techniques d’interception des appels au système ou bien masquent la présence de code malveillant en retournant des informations fausses sur l’état du disque ou de la mémoire. Comme eux, les rootkits sous Windows utilisent largement ce genre de techniques.

Les rootkits sous Windows ne sont apparus que 10 ans après, environ. Au lieu de reprendre l’appellation de virus furtifs, ou tout autre nom équivalent, le choix du terme rootkit pour baptiser ce nouveau type de programmes revient à un certain Greg Hoglund. Celui-ci a été l’un des premiers à mettre au point un outil destiné à masquer des données, en combinant plusieurs techniques permettant de contourner les fonctions d’autoprotection des systèmes Windows. Ses recherches furent publiées dans le magazine électronique PHRACK (http://phrack.org) où l’outil était désigné sous le nom de « NT Rootkit ». À partir de là, ses travaux furent récupérés par de nombreux logiciels malveillants ; de fait, NT Rootkit continue toujours d’intriguer et d’inspirer, aussi bien les chercheurs que les concepteurs de rootkit.

Des origines jusqu’à la popularisation

L’article de G. Hoglund date de 1999 et s’appuie sur les recherches menées l’année précédente sur le noyau de Windows et publiées sur Usenet par un programmeur du Sri-Lanka (pour plus de détails, visitez le site http://www.cmkrnl.com/arc-newint2e.html).

Auparavant en 1995, Jeffrey Richter, un gourou de la programmation sous Windows, dévoila plusieurs techniques de détournement des appels au système en mode utilisateur dans son célèbre ouvrage « Advanced Windows », quatrième édition, intitulé « Programming Applications for Microsoft Windows ». Ces techniques furent par la suite mises en œuvre par de nombreux rootkits, allant jusqu’à recopier directement le code source de l’ouvrage.

Puis ce fut le tour des techniques d’interception des appels au système en mode noyau, qui furent publiées dans deux autres manuels, désormais classiques : « Undocumented Windows 2000 Secrets » de Schreiber, en 2001, et « Undocumented Windows NT » de P. Dabak avec d’autres auteurs, en 1999.

Les premiers rootkits pour Windows

Les travaux de recherche sur la protection du système Windows se poursuivirent si bien que, aussitôt après la publication de NTRootkit, de nombreux autres outils firent leur apparition, tous conçus pour masquer les objets du système d’exploitation :

  • 2000 – he4hook, conçu par un programmeur russe. L’outil n’est pas malveillant, mais masque des fichiers. Il opère en mode noyau. Il est intéressant de noter que son auteur ne désigne pas son programme comme un rootkit.
  • 2002 – Hacker Defender (aussi connu sous le nom de HacDef). C’est également un outil, mais plus puissant : il permet de masquer des fichiers, des processus et des entrées du registre, en fonction des paramètres d’un dossier de configuration. Il opère également en mode noyau.
  • 2003 – Vanquish. Cet outil peut être utilisé pour masquer des fichiers, des répertoires et des entrées du registre. En outre, sa finalité est malveillante – il intercepte les mots de passe. Vanquish opère en mode utilisateur.

On observe déjà une évolution dans les raisons qui poussaient les chercheurs à travailler sur ce genre d’outils puisque, partant d’un intérêt neutre, certains commençaient à vouloir les exploiter, y compris de manière malveillante.

  • 2003 – Haxdoor (également connu comme A-311 Death et Nuclear Grabber, une variante modifiée du même programme). Il s’agit bien plus que d’un outil – c’est une « porte dérobée » qui met en œuvre les techniques des rootkits pour masquer sa présence dans le système. Il opère principalement en mode utilisateur
  • 2004 – FU – permettant de masquer des processus. Cet outil introduit une nouvelle technique qui modifie directement la structure même du système, au lieu d’intervenir seulement sur le mode d’accès au système. Il opère en mode noyau.

La liste précédente ne prétend pas être complète, mais elle comprend les principaux rootkits sous Windows, et plus particulièrement HacDef, Haxdoor et FU, afin de mieux comprendre leur évolution. Dans les milieux de culture virale, ces 3 rootkits travaillent généralement en tandem avec d’autres types de logiciels malveillants.

Les rootkits de 2000 à 2004 sont faciles à classer selon le système standard (maintenant obsolète) : ils peuvent opérer à la fois en mode utilisateur et en mode noyau, par modification du chemin d’exécution ou par manipulation directe d’objets du noyau. Cette classification a fait l’objet de discussions sans fin, et ceux qui s’y intéressent en apprendront davantage à partir d’ici : http://www.securityfocus.com/infocus/1850.

La production en masse de rootkits

Au cours de leur évolution, les rootkits ont également été intégrés dans des programmes malveillants. À cette époque, il était difficile de créer des technologies furtives de manière indépendante, en raison de l’absence de littérature sur le sujet. Par conséquent, il était possible de subdiviser le petit nombre de rootkits malveillants en trois catégories :

  1. Chevaux de Troie utilisant des outils ou des bibliothèques prêtes à l’emploi, pour se dissimuler eux-mêmes. L’écrasante majorité de ces chevaux de Troie utilisait le code Hacker Defender et FU.
  2. Rootkits malveillants prêts à l’emploi, disponibles au téléchargement ou à la vente, et modifiables par l’utilisateur. Haxdoor en est un exemple. Comme pour HacDef, Haxdoor était devenu très populaire à l’automne de 2005 ; Kaspersky Lab ajoutait quotidiennement environ dix nouvelles signatures permettant de se protéger contre de nouvelles variantes de Haxdoor.
  3. Rootkits personnalisés, conçus pour des attaques ciblées. Ce sont les clients des fabricants d’antivirus qui ont alerté de l’existence de ces rootkits, la plupart du temps dans de grandes organisations. Normalement, quand les administrateurs réseau ne parvenaient pas à identifier la cause du problème, les analystes antivirus venaient sur place mener leur enquête. Les rootkits de cette catégorie étaient en très petit nombre, mais les exemplaires rencontrés témoignaient d’un degré de sophistication technique élevé.

    Vers 2005, environ 80 % des rootkits existants étaient des variantes de HacDef et de Haxdoor. Rbot et SdBot ont été les premiers chevaux de Troie de type « porte dérobée » à fonctions multiples, qui intégrèrent des technologies appartenant aux rootkits. La motivation était claire ; toutes les technologies susceptibles d’améliorer les fonctionnalités générales d’un cheval de Troie se traduisaient directement par un profit économique supplémentaire pour son auteur ou pour celui qui avait le contrôle de l’outil. C’est ainsi que les réseaux robotisés furent les premiers qui mirent à profit les technologies furtives des rootkits.

    Vers 2006, nous avons vu des technologies propres aux rootkits intégrées dans des vers de messagerie tels que Bagle ; dans des logiciels espions (Trojan-Spy) comme Goldun ; et dans des robots de messagerie (« mailbot »), comme Rustock. Leur introduction a d’ailleurs posé un défi sérieux aux fabricants d’antivirus.

    Cependant, avant que l’intégration de ces techniques dans les chevaux de Troie ne devienne la norme, il existait un certain nombre d’outils antirootkit, indépendants ou intégrés dans un autre produit. L’équilibre des forces s’en trouvait rétabli.

    Le scandale des rootkits

    Vers 2005, l’emploi de techniques furtives dans les logiciels malveillants était si fréquent qu’elles finirent par attirer l’attention des médias et, naturellement, des professionnels de la sécurité. Les représentants de Microsoft portèrent l’affaire devant la RSA.

    Au cours de l’année 2006, de nombreux scandales liés à l’emploi des technologies propres au rootkits, dans plusieurs produits logiciels et matériels, démontrent à quel point les technologies furtives étaient devenues une affaire publique.

    1. Le système de protection DRM de Sony sur certains CD dissimule ses fichiers aux utilisateurs. Or, l’implémentation de cette technologie a pour effet de créer une vulnérabilité sérieuse : en nommant les fichiers d’une certaine façon, n’importe qui peut se servir de la technologie DRM de Sony pour les rendre invisibles.
    2. Les produits de Symantec employaient une caractéristique similaire: ils utilisaient un répertoire invisible pour les utilisateurs. Cet incident ne manque pas de sel ; car la « corbeille protégée » de Symantec était bien documentée et facile à désactiver. En pratique, l’idée de dissimuler des fichiers sous un dossier invisible n’a pas plus d’intérêt que celle visant à les dissimuler dans les profondeurs du système de fichiers, où aucun utilisateur ne va jamais regarder.
    3. Une autre victime des scandales liés aux rootkit a même été Kaspersky Anti-Virus ; il s’est avéré que ce produit enregistrait certaines données dans les flux de données du système de fichiers, c’est à dire un endroit qui reste effectivement caché aux yeux des utilisateurs. Même s’il n’était pas clair de dire en quoi cela représentait une menace, l’emploi du mot « rootkit » suffisait à effrayer beaucoup de monde.

    L’hystérie antirootkit

    Une autre dimension importante de l’évolution des rootkits était l’hystérie parallèle créée autour d’eux. Vers la moitié de 2006, il existait un consensus chez les principaux fabricants d’antivirus sur la nécessité de réagir aux menaces posées par les rootkits. Et chaque société a réagi à sa manière. Certains modifièrent leur produit pour inclure la recherche des objets masqués dans l’analyse antivirus normale. D’autres publièrent des outils anti-rootkit indépendants. D’autres enfin choisirent le compromis d’inclure une fonction spécialisée d’analyse anti-rootkit dans l’interface de leurs produits.

    En toute franchise, aucune de ces solutions n’était particulièrement réussie – il s’agissait surtout de refermer la porte de l’écurie après que le cheval s’en soit échappé.

    Dans ce contexte d’escalade, F-Secure, qui avait publié son propre outil anti-rootkit peu après le Rootkit Revealer de Sysinternals, fut l’un des premiers fabricants importants à prendre des mesures remarquées. L’outil de F-Secure se limitait à détecter des processus cachés, mais en utilisant des « preuves de concept » (POC, proof of concept).

    Anti-rootkits d’indépendants

    Des concepteurs indépendants avaient déjà publié des anti-rootkits bien avant, aux alentours de 2005. À la différence des solutions proposées par les fabricants d’antivirus, qui devaient faire la démonstration de leur efficacité devant les utilisateurs, les auteurs de ces outils gratuits ne cherchaient qu’à découvrir le maximum possible de données masquées. Pour cette raison, les outils de concepteurs indépendants étaient plus professionnels, performants et capables de réagir correctement dans un environnement changeant.

    Les premiers outils anti-rootkit étaient conçus pour révéler la présence d’un seul type d’objet, à savoir, des fichiers masqués. Au fur et à mesure, leurs fonctionnalités s’améliorèrent et ils commencèrent à utiliser une démarche sémantique. Aujourd’hui, les outils anti-rootkit d’usage général les plus utiles sont GMER (http://gmer.net) et Rootkit Unhooker (http://antirootkit.com) (ce dernier n’est plus pris en charge). Ces deux outils permettent d’effectuer une analyse rapide et superficielle des conditions du système sous différents angles. Ils peuvent également être utilisés, au besoin, pour des analyses approfondies plus spécialisées.

    Il existe aujourd’hui au moins 20 anti-rootkit gratuits (http://antirootkit.com), chacun mettant en œuvre plusieurs approches pour détecter les rootkits (voyez et http://www.securityfocus.com/infocus/1854 pour plus de détails). La bataille continue de faire rage, toutefois. L’une des tendances récentes dans l’évolution des rootkits est l’utilisation de la technologie Bluepill (de virtualisation matérielle) indétectable par des techniques actuelles. Il n’existe tout simplement pas d’outil anti-rootkit opérationnel capable de détecter les rootkits utilisant la technologie Bluepill. D’un autre côté, on ne connaît pas non plus de programme malveillant opérationnel exploitant cette technique, mais seulement le code servant pour preuve de concept.

    Néanmoins, des travaux de développement sont en cours afin de détecter ce type de menace hypothétique. Deux projets de recherche sont en cours sur ces rootkits : celui de North Security Labs en Russie (http://northsecuritylabs.com) et celui mené par Hypervista Technologies aux États-Unis (http://hypervisor.com). Jusqu’ici, Hypervista n’a publié que des informations théoriques, tandis que North Security Labs a mis une version bêta de leur outil Hypersight Rootkit Detector disponible au téléchargement. Bien que le projet en soit toujours à ses débuts, il reste néanmoins intéressant.

    Les preuves de concept des rootkits

    En 2006 la plupart des rootkits étaient détectés par des outils anti-rootkit et les efforts de recherche ont diminué. Naturellement, ceci a poussé les chercheurs, qu’ils soient du bon comme du mauvais côté, à mettre au point de nouvelles techniques indétectables.

    La plupart des chercheurs se sont concentrés sur la notion de virtualisation matérielle (intégrée dans les nouveaux processeurs Intel et AMD) afin de prendre le contrôle du système d’exploitation. Cette méthode permet de créer des rootkits indétectables par les outils anti-rootkit actuels.

    Pendant 2006, trois preuves de concept de ce type de rootkits ont fait l’objet d’une publication : SubVirt (http://www.eecs.umich.edu), BluePill (http://blackhat.com/presentations) et Vitriol (http://www.blackhat.com). Au moment où j’écris, ces lignes, la détection de ces rootkits est toujours un problème insoluble. Mais pour autant que nous sachions, ils ne sont pas encore actifs en milieu viral.

    Le second domaine de recherche est celui des rootkits qui opèrent sur le secteur d’amorçage, désignés aujourd’hui comme « bootkits ». Ce groupe de rootkits prend le contrôle complet du système au moment de l’amorçage. Cette technique renvoie à celle des virus d’amorçage qui régnaient à l’époque du DOS. La première preuve de concept de ces rootkits ayant pour cible le secteur d’amorçage a été eEye Bootroot (http://www.blackhat.com), apparu en 2005. Pour sa part, Vbootkit (http://www.blackhat.com) est une autre preuve de concept similaire, publiée en 2007 ; présentée comme un travail de recherche, elle portait sur le thème de sécurité de Vista.

    Dernières tendances

    Après une période relativement longue sans manifestation de nouveaux rootkits, l’année 2008 a amené son lot de nouveaux défis pour l’industrie antivirus. Un nouveau spécimen de code malveillant est apparu qui soi-disant infectait le secteur d’amorçage. Il est désigné par un certain nombre de noms : Sinowal, Mebroot et StealthMBR. La plupart des solutions antivirus ont des difficultés pour le détecter, et davantage encore pour le désinfecter.

    Ce rootkit, ou « bootkit », comme il est devenu fréquent de le nommer, parce qu’il s’exécute pendant la séquence de démarrage, utilise le code eEye Bootroot. Pour l’essentiel, cet outil n’est guère plus que du code malveillant permettant de masquer un cheval de Troie… ou plutôt, n’importe quel cheval de Troie. Il semble raisonnable de conclure que Sinowal est un outil partagé (probablement contre de l’argent) dans certains cercles, et que nous n’avons pas fini d’entendre parler de lui.

    Une autre technique récente, mais qui n’a pas attiré l’attention autant que les autres, est l’utilisation des fonctions CmRegisterCallback, créées par Microsoft pour aider les développeurs à masquer des objets dans le registre. Un certain nombre des programmes malveillants les plus sophistiqués, par exemple Bulknet, se servent de cette technique.

    Le mythe du rootkit

    À la fin de 2006, les forums de sécurité bouillonnaient de rumeurs à propos de Rustock.c, un nouveau Rootkit présumé indétectable. Ce nouveau rootkit se présentait comme le tout dernier développement de la famille des robots spammeurs Rustock. Un an et demi plus tard, des chercheurs de Dr. Web, une société russe d’antivirus, annoncèrent la découverte d’un échantillon de Rustock.c et l’analyse réussie de sa routine de propagation. Malheureusement, tous les détails ne sont pas encore disponibles et il est difficile d’évaluer le sérieux de cette menace. Les informations apportées par Dr. Web semblent indiquer que ce rootkit a réellement été créé en septembre 2007, et non fin 2006.

    Quoi qu’il en soit, il paraît clair que Rustock.c n’est pas impossible à détecter. Le programme n’utilise aucune technologie de pointe permettant de le rendre indétectable. Toutefois, il est capable d’éviter les méthodes de protection existantes, ce qui n’est guère difficile – un certain nombre de programmes moins célèbres sont également capables de contourner les dispositifs de sécurité.

    En somme, Rustock.c nous en a appris davantage sur la manière dont les informations circulent que sur des questions de technologie. Les rumeurs à la fin de 2006 n’étaient pas fondées, mais elles ont préparé le terrain à la venue des événements postérieurs. Quand un véritable échantillon fut annoncé, l’excitation était à son comble à l’idée d’avoir un aperçu de ce rootkit « indétectable » – même si en réalité, Rustock.c n’offrait aucun intérêt technique particulier. À mon avis, Rustock.c est davantage intéressant par la réaction qu’il a provoquée dans la communauté informatique, qu’en raison d’une avancée technologique sérieuse.

    Vous trouverez plus de détails sur l’histoire de Rustock.c à l’adresse : http://www.viruslist.com/fr/analysis?pubid=200676161.

    Rootkits en dehors de Windows

    De temps en temps, les laboratoires de virus voient arriver un échantillon de rootkit prenant pour cible des systèmes UNIX peu fréquents, comme c’est le cas de Solaris. Normalement, cela se produit quand l’organisation qui en est la victime n’a pas surveillé ses serveurs, configurés longtemps auparavant et restés intacts depuis lors. Il est facile de pirater un système de ce type et d’y implanter un rootkit qui ne sera détecté que des années plus tard, par hasard, et seulement après qu’une quantité importante de données propriétaires ou confidentielles aient été ratissées, avec les pertes financières que cela entraîne.

    De nombreux rootkits ont été écrits pour OS X (Macintosh) et il existe même un anti-rootkit pour ce système d’exploitation : OS X Rootkit Hunter. Par ailleurs, puisque OS X est un système Unix, certains rootkits UNIX peuvent être modifiés pour opérer aussi sur OS X. Mais en général, nous n’assistons pas à une évolution significative des rootkits pour Mac, non plus qu’à une menace sérieuse dans son domaine.

    Les systèmes d’exploitation pour mobiles, comme Windows Mobile, Symbian etc., n’ont pas encore subi d’attaques de rootkits pour autant que je sache. Cependant, il existe relativement peu de logiciels malveillants ciblant les systèmes d’exploitation de ces périphériques, et peu de personnes utilisent les solutions antivirus disponibles, ce qui rend inutiles les techniques furtives.

    Les quasi-rootkits

    Dans cet article, j’ai choisi de ne pas parler de certains logiciels malveillants identifiables par preuves de concept ; ils ne peuvent être classés parmi les rootkits et la plupart des chercheurs ne les appelleraient pas de cette manière. Si nous partons du fait qu’un rootkit est un programme permettant de contourner les mécanismes de sécurité du système d’exploitation et de dissimuler sa propre activité, les logiciels malveillants décrits ci-après sont certainement limitrophes.

    En premier lieu, il existe des logiciels malveillants qui se cachent dans le système d’exploitation, mais de façon « honnête » : ce type de logiciels ne cherche ni à modifier le système, ni à contourner la sécurité. Ce sont par exemple des programmes malveillants dont le noyau de code s’installe dans un répertoire ou dans les flux de fichiers. Ensuite, il existe des programmes qui exploitent des fonctions système qui sont documentées, et qui leur permettent de détourner les événements propres au système. Ces programmes ne sont pas considérés des rootkits, bien qu’ils agissent de manière invisible.

    En second lieu, il existe des programmes qui sont invisibles en raison de leur propre architecture interne, comme par exemple le ver CodeRed, qui ne crée ni fichier sur disque, ni processus en mémoire.

    Enfin, en troisième lieu, il existe des techniques sophistiquées permettant de duper le système d’exploitation. Celles-ci peuvent être employées par un programme malveillant, non pas tant pour dissimuler les traces de son activité, que pour pénétrer dans le système ou pour éluder les solutions antivirus.

    Réflexions finales sur les rootkits

    Les exemples limitrophes présentés plus haut nous conduisent à conclure qu’il n’existe pas à proprement parler de rootkit malveillant, mais plutôt un certain nombre de techniques furtives qui sont utilisées pour contourner la protection ou pour masquer la présence de programmes dans un système. Comme pour toutes les technologies avancées, il est possible de les utiliser pour le meilleur et pour le pire. Les anti-rootkits proactifs, par exemple, combattent habituellement le feu par le feu, en utilisant les mêmes procédés que les rootkits, en détournant des fonctions système, etc.

    Toutes ces techniques, ou une partie d’entre elles, peuvent être considérées des techniques furtives, à un degré plus ou moins grand. Au final, la quête de la définition précise d’un rootkit nous fait pencher tantôt du côté de la majorité – avec la définition généralement acceptée – tantôt du côté des experts, dont l’opinion minoritaire fait autorité.

    Mais pourquoi une définition précise est-elle nécessaire ? Parce que sans elle, nous risquons de passer de l’imprécision verbale à l’erreur de tir concernant des cas limitrophes, en détectant accidentellement de soi-disant rootkits dans des produits inoffensifs. Il est crucial d’analyser en détail le code et les techniques présentes dans chaque cas de figure, au lieu de se contenter d’identifier une certaine technique avec un rootkit, en risquant de provoquer des incidents qui effraient et font du bruit pour rien.

    Comme dans le cas, par exemple, du pseudo-rootkit (http://www.pcworld.com; http://www.kaspersky.com) identifié dans Kaspersky Anti-Virus. La technique suspecte utilisée par ce produit semblait placer des données douteuses à l’intérieur des flux du système de fichiers, c’est à dire, elle conservait des données dans des zones du système de fichiers qu’il est impossible de surveiller directement.

    S’agit-il pour autant d’une technique destinée à contourner le système d’exploitation ? Non – les flux de données sont des fonctions bien documentées du système d’exploitation. Peut-on considérer la dissimulation de données dans ces flux une activité malveillante ? Non plus, car dans ce cas, seule l’information du service est masquée. Peut-on considérer cette technique une vulnérabilité, c’est à dire, l’utiliser dans un but malveillant ? Non plus. Un utilisateur malveillant peut en effet utiliser les flux de données pour y dissimuler uniquement du code dangereux (technique déjà utilisée par bon nombre de programmes malveillants), mais cela correspond à une vulnérabilité du système, et non à une vulnérabilité de l’application elle-même. Alors… où se trouve le rootkit ? Pas dans Kaspersky Anti-Virus ou, pour rester dans notre sujet, pas dans un produit où c’est une vulnérabilité propre au système qui porte à croire que lui-même contient une vulnérabilité.

    L’incident lié au DRM de Sony est légèrement différent. Les techniques employées pour la protection contre la copie ont directement donné lieu à une vulnérabilité en ce sens qu’elles ont permis aux utilisateurs malveillants de renommer leurs programmes malveillants de façon à les rendre invisibles. Nous savons aujourd’hui que plusieurs programmes malveillants ont exploité cette vulnérabilité, bien que, pour rester équitables, c’est la révélation publique de cette vulnérabilité et le débat qui a suivi, qui ont donné lieu à l’apparition de ces programmes.


    Chronologie des évènements liés aux rootkits

    Conclusion

    De façon générale, l’évolution des rootkits reproduit celle des logiciels espions. Les rootkits ont d’abord été identifiés comme une catégorie distincte de logiciels malveillants. Ensuite, l’exagération de la part des medias a conduit au développement d’un grand nombre d’outils et de produits antirootkit, ainsi qu’à une réaction importante de l’industrie antivirus. Aujourd’hui, les rootkits et les logiciels espions ont été intégrés dans une même problématique et ne provoquent plus guère d’émotion. Il reste que l’idée de contourner les fonctionnalités du système pour lui cacher quelque action est toujours valable, et qu’il faut donc prévoir pour l’avenir l’apparition de nouvelles menaces mettant en œuvre ces procédés furtifs.

Posts similaires

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *