Ceux qui ont connu l'époque « classique » des virus du DOS, se souviennent des virus de boot, avec par exemple Stoned, Michelangelo, Junkie ou Tequila. Mais ce passé oublié pourrait revenir en force, preuve que les vieilles recettes ont encore de l'avenir. En effet  un récent rootkit exploite à nouveau cette ancienne technique délaissée depuis plusieurs années.

au sommaire

    Tout d'abord un petit résumé pour ceux qui ne sont pas familiers avec ces notions. Lorsqu'un ordinateur est mis sous tension, la première chose qui est exécutée est le BIOS, contenu dans une mémoire morte de la carte mère. La dernière instruction de cette séquence d'initialisation envoie la tête du disque dur (ou plus rarement de la disquette) lire le contenu du secteur d'amorce de ce support. C'est le Main Boot RecordMain Boot Record, ou MBR. Ce secteur contient les informations suivantes : le type de formatageformatage du disque, l'identification du système d'exploitationsystème d'exploitation présent, suivis d'une petite séquence de code exécutable qui indique à l'ordinateur où trouver le premier fichier à lire du système d'exploitation (obligatoire uniquement pour les disques ou disquettes bootablesbootables). Ce n'est qu'à partir de ce moment que le système d'exploitation lui-même se charge en mémoire.

    On voit donc tout le parti qu'on peut tirer de cette logique de démarrage. Il suffit de remplacer le code de démarrage contenu dans le MBR par un code infectieux, et ce dernier se chargera dans la mémoire avant le système d'exploitation et, bien entendu, avant tout antivirusantivirus. Il suffit enfin que le code du virus se termine, comme dans un MBR honnête, par l'appel du premier fichier de l'OS, et l'utilisateur n'y verra que du feufeu. Pire encore : à la grande époque des disquettes, il suffisait de placer une disquette infectée dans le lecteur pour que l'ordinateur soit contaminé puisque la première chose que fait l'ordinateur quand il reconnaît la présence d'une disquette, c'est de lire son secteur d'amorce.

    Bien sûr on ne peut pas loger beaucoup de code dans un seul secteur mais les virus d'antan faisaient un concours de minceur. Et puis, si le code était trop volumineux il suffisait de placer l'amorce du virus sur le MBR et cette amorce appelait le corps principal du virus soigneusement caché sur le reste du disque avant de lancer le chargement du système d'exploitation.

    Puis les choses ont évolué. Les prouesses techniques pour loger du code infectieux dans le MBR ont été abandonnées au profit de choses plus faciles : par exemple placer une macro virale dans un document Word ou Excel, puis plus tard utiliser des mails contenant une pièce jointe piégée, des pages web piégées et enfin exploiter la naïveté des internautes peu scrupuleux en plaçant des malwaresmalwares dans des réseaux de P2PP2P en les faisant passer pour les films, des morceaux de musique ou des programmes « crackés ».

    Le MBR à nouveau attaqué

    Mais actuellement les infections tendent à nouveau à se masquer au maximum par des mécanismes complexes pour devenir ce qu'on appelle des rootkitsrootkits. Il s'agit de programmes malicieux qui se dissimulent par diverses méthodes au sein même du système d'exploitation qu'ils détournent à un niveau élevé. On comprend que le MBR constitue une cible merveilleuse pour prendre le contrôle d'un ordinateur. Or, chose curieuse, cette vieille piste avait été totalement négligée par les auteurs de malwares récents. Il y avait juste eu deux études théoriques, l'une en 2005 et l'autre en 2007, montrant grâce à des programmes de démonstration non dangereux (proof of conceptproof of concept, ou PoC) la faisabilité d'un rootkit exploitant ce mécanisme.

    Or en décembre cette menace négligée est devenue réalité avec l'apparition du rootkit Trojan.Mebrot (selon la dénomination de Symantec qui l'a particulièrement étudié ainsi que iDefence, le département sécurité de Verisign). Certes la dissémination de ce malware est faible, mais son existence même ouvre la porteporte à toutes les inquiétudes, l'expérience montrant que dès qu'une voie s'ouvre, elle est largement exploitée par des variantes et de nouveaux malwares.

    Ironiquement les auteurs de ce rootkit se sont inspiré du code PoC de 2005 mais l'ont modifié pour lui faire implanterimplanter une backdoorbackdoor dans le kernelkernel (noyau) de Windows XPWindows XP, qui se comporte comme un cheval de Troiecheval de Troie permettant théoriquement de prendre le contrôle à distance de l'ordinateur infecté. Le code du cheval de Troie lui-même est constitué de 467 Ko stockés discrètement dans les derniers secteurs du disque (et qui ne sont donc jamais utilisés dans un usage normal).

    Le groupe à l'origine de ce rootkit est le même que celui qui a créé le cheval de Troie Torpig qui avait infecté à peu près 200.000 ordinateurs et leur avait dérobé des informations bancaires. Il s'agit donc clairement d'une manoeuvre criminelle. Il existe aussi des similarités techniques avec le cheval de Troie Anserin qui a été également hébergé sur le même site web que Mebrot.

    En effet l'infection ne se fait plus comme autrefois par l'intermédiaire de disquettes contaminées, car ce support n'est pratiquement plus utilisé. Elle résulte de la visite d'une page web piégée de diverses manières, dans le but qu'un des pièges au moins arrive à trouver une faille dans les défenses de l'ordinateur et du système d'exploitation. Certaines variantes ne sont probablement pas détectées encore par tous les antivirus.

    Mebrot utilise quelques autres vieilles recettes. Par exemple avant de remplacer le MBR il en recopie le contenu sur le secteur 62 du disque. Si on emploie un utilitaireutilitaire pour lire le contenu du MBR, le système d'exploitation contaminé redirige la lecture vers le secteur 62, de telle sorte qu'on a l'impression que le contenu du MBR n'a pas été modifié. Enfin si on essaie de corriger le MBR par la commande fixmbr qui récrit ce secteur, pour essayer d'éradiquer l'infection, le cheval de Troie s'y oppose.

    Se soigner, se protéger

    Par contre, bonne nouvelle, la commande fixmbr fonctionne si elle est exécutée dans la console de récupération lancée à partir du CDCD d'installation. Certes le code du cheval de Troie est toujours sur le disque, mais reste inoffensif puisqu'il ne peut pas être chargé en mémoire. Toutefois il est fortement conseillé, si on constate une infection, de soumettre son problème à un spécialiste (un "helper") comme ceux du groupe antimalware du forum de Futura-Sciences. En effet l'expérience montre qu'une infection en cache souvent une, ou plusieurs autres.

    Les versions de Windows sensibles à cette infection sont les diverses déclinaisonsdéclinaisons de Windows XP et probablement les Windows de la série 2000. VistaVista serait insensible à ce malware. La meilleure façon de se protéger est d'avoir un système d'exploitation et un navigateurnavigateur toujours à jour pour les derniers correctifs de sécurité puisque la contaminationcontamination doit exploiter une faille du navigateur et de Windows. Par contre c'est le moment de se souvenir que beaucoup de BIOS comportent une option qui bloque toute écriture sur le MBR, en souvenir d'une époque qu'on croyait révolue. C'est le moment de l'activer à nouveau.