Toutes les Menaces

Virus

Hackers

Spams

Whole site    Viruses
  
Encyclopédie Virus
Alertes
Analyses
Actualité
Glossaire

 
Calendrier

<< 2014  
Jan Feb Mar
Apr May Jun
Jul Aug Sep
Oct    
Les Analyses les plus Populaires



Rapport de Kaspersky Lab sur les cybermenaces mobiles : les attaques visant Android sous stéroïdes



Courrier indésirable en août 2014



Enquête sur un incident : vol dans une banque électronique



PAC et la problématique de la configuration automatique



10 astuces simples pour renforcer la sécurité de votre Mac
 
 

  Page d'accueil / Analyses

Bootkits – le malware 2.0

18.12.2008   |   comment

Sergueï Golovanov
Alexander Gostev
Alexey Monastyrsky
  • Des redémarrages inexpliqués
  • Liens remplacés
  • Code d'exploitation "personnel"
  • Neosploit ressuscité
  • Bootkit
  • Centre d'administration nomade
  • Module d'espionnage
  • Réseau malveillant
  • Ampleur de l'infection
  • Méthodes de protection
  • Conclusion

    L'expression Malware 2.0, souvent utilisée dans nos articles, désigne un modèle moderne de fonctionnement d'ensembles de programmes malveillants qui est apparu vers la fin de l'année 2006. Les vers Bagle, Warezov et Zhelatin sont les précurseurs de cette catégorie et demeurent, à ce jour, les exemples les plus frappants de celle-ci.

    Les principales caractéristiques de ce modèle sont les suivantes :

    • Absence d'un centre unique d'administration du réseau d'ordinateurs infectés ;
    • Résistance active face aux tentatives d'analyse du code malveillant ou de saisie du contrôle du réseau de zombies par des tiers ;
    • Diffusion massive du code malveillant sur une courte période ;
    • Application efficace des astuces d'ingénierie sociale ;
    • Utilisation de divers moyens de diffusion des programmes malveillants et abandon progressif des moyens les plus courants (courrier électronique) ;
    • Utilisation de différents modèles (et non pas d'un seul modèle universel) pour la réalisation de diverses fonctions malveillantes.

    Le développement de Malware 2.0 entraîne toute une série de problèmes pour le secteur de la lutte contre les virus. Selon nous, l'incapacité des solutions antivirus traditionnelles, basées exclusivement sur l'analyse heuristique ou l'utilisation de signatures, à lutter efficacement contre les attaques de virus, sans parler des problèmes liés au traitement des systèmes infectés, est le problème le plus important.

    Certains événements survenus en 2008 révèlent le danger que représente Malware 2.0. Rappelons-nous la fameuse histoire du rootkit (outil de dissimulation d’activité) Rustock. (Rustock a fait l'objet d'un article détaillé publié sous le titre " Rootkit, Rustock et tout le reste"). Rustock exploitait quelques-unes des nouvelles technologies, astuces et méthodes qui vont peut-être exercer une forte influence sur le développement ultérieur de Malware 2.0.

    Un autre événement que nous souhaitons aborder dans cet article illustre clairement les nouvelles armes déployées dans la lutte entre les auteurs de virus et les éditeurs de logiciels antivirus, et souligne le rôle clé des nouvelles technologies de protection.

    Des redémarrages inexpliqués

    Vers le milieu du mois d'août, des messages sont apparus sur plusieurs forums pour signaler le redémarrage de l'ordinateur après la visite de certains sites. Les causes de ces redémarrages n'étaient pas claires. Rien ne permettait d'indiquer que le matériel utilisé ou les logiciels installés pouvaient être responsables de ce comportement. Il ne restait qu’une seule option : ces redémarrages inexpliqués étaient provoqués par la visite de certains sites web.

    L'examen initial du contenu des pages des sites suspects ne donna aucun résultat : les sites avaient l'air inoffensif. D’ordinaire, les individus mal intentionnés compromettent un site légitime en y plaçant des liens vers des ressources truffées de codes d'exploitation. Cette technique porte le nom de "drive-by-download" et elle permet d'installer des programmes malveillants à l'insu de l'utilisateur lors de la visite d'un site infecté. Dans le cas présent, aucun iframe ou script suspect n'avait été détecté.

    Les problèmes rencontrés par les utilisateurs auraient pu être imputés au redémarrage automatique de Windows après une mise à jour, d'autant plus qu'à l'époque des faits Microsoft avait publié un nouveau correctif. Toutefois, la situation était bien plus sérieuse.

    Dans la seconde étape de notre enquête, nous avons visité les sites suspects à partir de machines virtuelles. Nous ne nous sommes pas contentés d'ouvrir les sites mais nous avons activement navigué sur les sites en question (accès à différentes rubriques, activation de liens). Et peu de temps après, l'ordinateur du test redémarra !

    L'analyse du système mit en évidence une modification du secteur de démarrage du disque. Ces modifications pouvaient trahir la présence d'un rootkit dans le système. Le rapport sur le premier trimestre 2008 (viruslist.com) traitait des outils de dissimulation d'activité (rootkits) et des problèmes liés à cette technologie. Toutefois, depuis mars 2008 nous n'avions recensé aucune nouvelle version d'outils de dissimulation d'activité. Etait-il de retour ?

    Liens remplacés

    Après avoir identifié les sites et les liens qui entraînaient le redémarrage de l'ordinateur, nous avons pu aborder l’analyse de manière plus approndie.

    Les individus mal intentionnés utilisaient une méthode assez originale même si pas tout à fait récente pour intégrer les liens. Ils n'ajoutaient aucun iframe ou script particulier au code des pages des sites compromis car de telles modifications auraient été découvertes facilement. Ils remplaçaient les liens "propres" du site par des liens "malveillants".

    Voici à quoi ressemble un lien "propre" : <a href="http://atm.n****.com"><B>atm.n****.com</B></a>

    Une fois que le site a été compromis, le lien est remplacé par : <a href="http://***.com/cgi-bin/index.cgi?dx"><B> atm.n****.com</B></a>

    Pour que l'infection ait lieu, le PC de l’utilisateur doit non seulement ouvrir une page du site compromis mais également cliquer sur le lien remplacé. Ce procédé réduit le nombre de victimes potentielles de l'infection mais selon nos estimations, cette réduction n'est pas substantielle, surtout si le remplacement des liens est effectué manuellement et que les liens remplacés sont soigneusement choisis par l'individu mal intentionné.

    Des sites avec des adresses du type ***.com/cgi-bin/index.cgi?dx apparaissent sur Internet depuis le début du mois de juin 2008 dans les messages d'auteurs ou de visiteurs de sites légitimes qui se plaignent de l'apparition de liens étranges sur des ressources fiables. Il semblerait qu'il existe de nombreux "centres d'infection" de ce type sur Internet. Toutefois, malgré un nombre élevé de noms de domaine, ils sont tous hébergés sur des serveurs communs.

    Voici une petite partie des sites que nous avons découverts :

     

     
    Exemples de distribution des serveurs infectant les utilisateurs à l’aide d’un rootkit (de gauche à droite : nom de domaine, adresse IP du serveur, sous-réseau où se trouve le serveur ; système autonome du réseau Internet)

    Code d'exploitation "personnel"

    Que se passe-t-il une fois que l'utilisateur clique sur le lien remplacé ? Le serveur traite la requête entrante et obtient les informations sur le site en provenance duquel le visiteur est arrivé, son adresse IP, le navigateur utilisé et les modules externes du navigateur installés. A partir de ces informations, le serveur attribue à l'utilisateur un identifiant unique qui sera enregistré sur le serveur.

    Exemple d'identifiant attribué par le serveur à un des visiteurs du site compromis: index.cgi@ac6d4ac70100f060011e964552060000000002e4f11c2e000300190000000006

    Dans cet exemple, les derniers chiffres de l'identifiant indiquent que l'utilisateur a installé la version 6 d'Acrobat Reader.

    Ensuite, un code d'exploitation propre à cet utilisateur est créé. Si l'utilisateur possède une version d'Acrobat avec une vulnérabilité, c'est un code d'exploitation d'une vulnérabilité des fichiers PDF qui sera téléchargé, s'il utilise une version vulnérable de Real Player, ce sera un code d'exploitation pour cette application, etc. Sur la base de l'identifiant de l'utilisateur, le serveur génère une clé d'obfuscation qui chiffre le code d'exploitation requis.

     
    Exemple d'obfuscation du code d'exploitation

    Le plus souvent, ce sont des codes d'exploitation pour le traitement de fichiers PDF, SWF et QuickTime qui sont téléchargés. La liste des vulnérabilités utilisées par les individus mal intentionnés est longue et ne cesse de s’allonger. Voici quelques-unes des vulnérabilités les plus répandues :

    • CVE-2007-5659
    • CVE-2006-0003
    • CVE-2006-5820
    • CVE-2007-5779
    • CVE-2008-1472
    • CVE-2007-0018
    • CVE-2006-4777
    • CVE-2006-3730
    • CVE-2007-5779
    • CVE-2008-0624
    • CVE-2007-2222
    • CVE-2006-0005
    • CVE-2007-0015

    Une fois que le code d'exploitation pour un visiteur particulier a été créé, il est exécuté sur la machine de la victime via l’application vulnérable. Pendant qu'il fonctionne sur l'ordinateur, il télécharge un cheval de Troie de type "dropper" créé sur le serveur à l'aide de la clé unique du serveur et de l'identifiant de l'utilisateur enregistrés dans la base du serveur.

    Vu de l'extérieur, tout semble inoffensif et rien ne pousse à la suspicion : une fois que le code d'exploitation a été exécuté, le serveur rend à l'utilisateur la véritable adresse de la page qu'il voulait visiter en cliquant sur le lien remplacé. La victime arrive sur la ressource voulue sans se douter que l'ordinateur a déjà été connecté à un autre serveur et qu'il a été infecté.

    De plus, si ce même utilisateur clique une nouvelle fois sur le lien modifié, le code d'exploitation ne sera pas activé et il n'y aura pas de tentative d'infection. Au contraire, l'utilisateur sera directement envoyé vers la page légitime. Le serveur malveillant tient une base de données de toutes les visites et il n'accepte pas une deuxième utilisation du même identifiant.

    Neosploit ressuscité

    Quel est le logiciel utilisé pour générer les codes d'exploitation "personnels" pour les utilisateurs ? Quelle ne fut pas notre surprise de nous retrouver face à un "revenant" : le toolkit Neosploit.

    L'ensemble de codes d'exploitation Neosploit est connu depuis le milieu de l'année 2007. Il se vendait au marché noir pour quelques milliers de dollars (entre 1 000 et 3 000 dollars américains) et faisait office de concurrent sérieux aux kits de programmes malveillants alternatifs tels que MPack et IcePack.

    A la fin du mois de juillet 2008, des messages (ddanchev.blogspot.com; blogs.zdnet.com) indiquant qu'un célèbre groupe de cybercriminels responsables de la création, de la diffusion et du soutien de Neosploit cessait ses activités firent leur apparition.

    Le message diffusé par des représentants du groupe indiquait :

    “Unfortunately, supporting our product is no longer possible. We apologize for any inconvenience, but business is business since the amount of time spent on this project does not justify itself. We tried hard to satisfy our clients’ needs during the last few months, but the support had to end at some point. We were 1.5 years with you and hope that this was a good time for your business.”

    Ce genre de "cessation d'activités" soudaine s'explique, généralement, par le fait que les forces de l'ordre sont sur les traces du groupe ou signale que les criminels préparent un grand coup et qu'ils doivent se fabriquer un "alibi".

    La dernière version de Neosploit avant l'arrêt de la création et de la vente du programme était la version 2.0.17. Sur le serveur responsable de la création des codes d'exploitation, nous avons vu la version 2.0.23 du panneau d'administration Neosploit !

     
    Fenêtre principale du panneau d'administration

    L'interface du panneau d'administration de Neosploit, malgré son aspect modeste, est très fonctionnelle.


    Fenêtre d'ajout d'un nouvel utilisateur au système

    Le toolkit Neosploit, utilisé pour la création de codes d'exploitation, la tenue de la base de données des utilisateurs infectés, etc. est un fichier exécutable programmé en langage C++ et compilé dans les systèmes d'exploitation Linux et FreeBSD.

     
    Vue du toolkit Neosploit de l'intérieur

     
    Code désassemblé du serveur responsable de l'obfuscation des codes d’exploitation

    Neosploit est prévu pour être installé sur des sites d'hébergement et son installation et exécution peuvent être très rapides. Toutefois, son utilisation pose un sérieux problème. Ce problème est lié au caractère "commercial" du logiciel. Neosploit, une fois acheté, ne peut être utilisé que dans un nombre limité de connexions. Ce système évoque les sharewares qui peuvent être utilisés jusqu'à une certaine limite.

    A chaque tentative d'infection de l'utilisateur et de création d'un code d'exploitation, le serveur Neosploit établit une connexion avec un serveur qui, vraisemblablement, réalise l'inventaire des connexions (au moment de la rédaction de cet article, ce serveur se trouvait en Ukraine). Sur la base du nombre d'utilisateurs infectés, les auteurs de Neosploit peuvent contrôler l'exploitation de leur "création" et/ou le paiement des services. Si la connexion avec ce serveur n'est pas possible statistiquement, le code d'exploitation n'est pas créé et l'infection de l'utilisateur n'a pas lieu.

    Bootkit

    Une fois qu'il a été téléchargé dans le système, le cheval de Troie de type "dropper" s'exécute grâce à une application vulnérable, extrait le programme d'installation du bootkit et lui transmet l'identifiant unique de l'utilisateur.

    Ensuite, le programme d'installation modifie le secteur de démarrage du disque et place le corps principal du programme malveillant dans les secteurs du disque dur.

    Exemple d'enregistrement dans le secteur de démarrage du disque

    CreateFileA("\\\\.\\RealHardDisk0", GENERIC_WRITE | GENERIC_READ, FILE_SHARE_READ | FILE_SHARE_WRITE, NULL, OPEN_EXISTING, 0x0, 0x0)

     
    Exemple de MBR infecté

    Si toutes ces actions sont exécutées sans erreur, le dropper donne à l'ordinateur l'ordre de redémarrer. C'est précisément ce redémarrage inattendu du système pendant l'utilisation normale d'Internet qui a éveillé les soupçons des utilisateurs et qui les a amenés à écrire dans les forums pour tenter de comprendre ce qui se passait.

    Après le redémarrage, le bootkit s'empare de diverses fonctions système et commence à fonctionner pleinement dans le système : il dissimule sa présence et fonctionne en tant que bot dans le réseau de zombies.


    Schéma d'infection d'un utilisateur

    Centre d’administration (CC) nomade

    Les technologies découvertes lors de l'analyse du mécanisme d'introduction du programme malveillant dans l'ordinateur des victimes étaient toutes dignes d’intérêt, voire originales (remplacement des liens, obfuscation des codes d'exploitation "au vol" sous un système particulier), mais pas vraiment uniques. Ces technologies ne sont pas nouvelles mais avant août 2008, elles n'avaient jamais été utilisées au cours d'une attaque.

    L’analyse du fonctionnement du bot nous réserva une véritable surprise : le centre d'administration (CC) du réseau de zombies changeait en permanence de domaine !

    Ainsi, nous avons été témoin de 2 à 3 déplacements du CC au cours d'une même journée. Le matin, le centre d'administration se trouvait sur aykjfgves.com, à midi, sur dmiafgves et le soir sur gfdpves.com. Chaque fois qu'un ordinateur faisant partie du réseau de zombies était connecté, il fallait rechercher le centre d'administration actif.

    Ce type de réseaux de zombies est très difficile à trouver et une fois qu'ils ont été identifiés, il est difficile de les mettre hors de service. Les individus mal intentionnés peuvent à tout moment déplacer le CC sur n'importe lequel des dizaines ou des centaines de domaines préparés et les experts anti-virus ne peuvent rien y faire. Même si le centre d'administration est découvert, il est déplacé vers un autre domaine dans les deux heures qui suivent. Il sera possible de le retrouver uniquement en analysant les paquets de réseaux des ordinateurs qui doivent, eux aussi, trouver leur "nouvelle demeure".

    Il est évident que cette méthodologie est très utile dans la lutte contre les concurrents qui pourraient tenter de "voler" le réseau de zombies et dans la lutte contre les éditeurs de logiciels antivirus et les autorités judiciaires.

     
    Exemple d'emplacement de serveurs d'administration d'un réseau de zombies. (de gauche à droite : nom de domaine, adresse IP du serveur, sous-réseau où se trouve le serveur ; système autonome du réseau Internet)

    La génération de noms de domaines selon un algorithme spécial et l'enregistrement des domaines correspondant permet aux individus mal intentionnés de déplacer autant qu'ils le souhaitent le centre d'administration du réseau de zombies. Les domaines sont enregistrés auprès de différentes sociétés d'enregistrement américaines, africaines, asiatiques ou européennes. Les données d'enregistrement des propriétaires ont des sonorités russes indéniables mais les données sont plus que probablement fausses.

    S'agissant de l'hébergement, les centres d'administration utilisent diverses ressources disséminées dans le monde entier. Le CC du réseau de zombies est capable de se déplacer vers un nouvel hébergeur en quelques minutes, ce qui lui permet d'éviter les fermetures et de conserver ainsi toutes ses capacités.

     
    Exemple d'emplacement d'un serveur déterminant la correspondance du nom de domaine et de l'adresse IP du CC du réseau de zombie. (de gauche à droite : domaine, adresse IP du serveur, sous-réseau où se trouve le serveur ; système autonome du réseau Internet)

    Cette méthode ressemble à la technologie Fast-Flux qui est beaucoup utilisée par les vers de la famille Zhelatin (ver de la tempête). La différence est que Fast-Flux permet de changer en permanence l'adresse IP des domaines malveillants tandis que la technologie exploitée par le bootkit change les domaines et les adresses IP.

    Le centre d'administration du réseau de zombies contient une base des noms de domaines enregistrés qui peuvent être utilisés pour héberger le centre d'administration.

    Exemple de domaines enregistrés

    ccuuuag.biz 67.228.229.122 registered : 2008-08-07
    ewwxbhdh.com 74.50.107.78 registered : 2008-08-07
    paiuuag.com208.73.210.32 registered : 2008-08-06
    paiuuag.net 208.73.210.32 registered : 2008-08-06

    Lors de l'infection initiale de l'ordinateur, un bootkit visant à travailler avec le centre d'administration du réseau de zombies actif au moment de l'infection est chargé lors de l'exécution du code d'exploitation sur l'ordinateur de la victime. Après le redémarrage du système et le début du fonctionnement complet du bootkit, le bot tente de se connecter à ce centre d'administration. Le programme malveillant crée un paquet de données de réseau spécial à partir de l'identifiant de l'ordinateur infecté et tente de l'envoyer au serveur du centre d'administration qui possède déjà des informations concernant les ordinateurs infectés.

     
    Exemple de paquet envoyé

    Si la connexion au centre d'administration du réseau de zombies échoue, le bot commence à générer des noms de domaines dans les zones .com, .net et .biz selon un algorithme spécial. L'ordre des noms de domaines générés dépend de la date du jour et de l'heure. Sur chacun de ces domaines, la porte dérobée tente d'établir une connexion et de transmettre le paquet préparé en tant que clé d'autorisation.

     
    Exemple de sélection de domaines

    Quand un des domaines est accepté (il accepte le paquet et répond en envoyant son propre paquet). Le bot s'y connecte en tant que client du réseau de zombies et commence à chiffrer la communication avec le centre d'administration du réseau de zombies. Le résultat de cette communication, en règle générale, est le chargement sur la machine infectée d'un module complémentaire (DLL).


    Schéma incomplet du fonctionnement du bot

    Module d'espionnage

    Depuis le début de l'année 2008, le bootkit a été étudié par de nombreux spécialistes. Tous ont limité leurs travaux à l'analyse du rootkit et au mode d'introduction du corps du programme malveillant dans les secteurs du disque dur. Certains des experts ont tenté d'analyser le mode de fonctionnement du réseau de zombies et des instructions d'administration.

    Toutefois, toutes ces études dont nous connaissons les résultats n'ont pas permis de répondre à une importante question à nos yeux : "Pourquoi ?" Ou, en d'autres termes : "Où est l'argent ?"

    Notre tâche principale consistait dès lors à tirer au clair l'histoire du bootkit. Et pour ce faire, il fallait absolument découvrir ce qui permettait de cacher si bien le bootkit dans le système ?

    Après la première connexion au centre d'administration du réseau de zombies, la machine infectée reçoit un paquet de données chiffré (d'environ 200 Ko). Le bootkit reçoit le paquet et le décrypte. Il renferme une bibliothèque système (DLL) qui est chargée par le bootkit dans la mémoire de l'ordinateur et qui n'existe pas sous la forme de fichier sur le disque !

    Ainsi, le bootkit est totalement invisible grâce à la DLL aussi bien durant l'analyse de l'état du système par les méthodes traditionnelles que lors de l'analyse par la majorité des logiciels antivirus. Souvenez-vous de ce que faisait Rustock ? Il téléchargeait également la DLL en mémoire mais elle figurait sur le disque de l'ordinateur. Le bootkit agit de manière plus rusée.

    Bien entendu, l'insertion du code uniquement dans la mémoire de l'ordinateur implique sa disparition au redémarrage du système, il cesse d'exister et le système est assaini (à l'exception de la présence du bootkit). Mais cet "inconvénient" a des côtés positifs : les logiciels antivirus qui analysent la mémoire de l'ordinateur au démarrage du système d'exploitation n'y découvrent rien d'anormal tout simplement parce que tel est le cas. Mais dès que l'ordinateur se connecte à Internet, le bootkit établit une connexion avec le centre d'administration et charge à nouveau la DLL.

    Quel est le rôle de la DLL ?

    Revenons un instant sur l'histoire du nom "Sinowal" (c'est ainsi que nous avons classé le bootkit). Quand le bootkit est apparu à la fin de l'année 2007, ce nom existait déjà : Trojan-Spy.Win32.Sinowal regroupait de nombreux chevaux de Troie espion qui volaient les données des utilisateurs et plus particulièrement les données d'accès aux services bancaires en ligne.

    L'analyse du bootkit nous permit de découvrir que l'algorithme d'obfuscation du corps du bootkit était identique à l'algorithme d'obfuscation utilisé par Trojan-Spy.Win32.Sinowal et nous en avons conclu que les auteurs du bootkit et du cheval de Troie espion étaient les mêmes. Sans une analyse détaillée de la DLL, la ressemblance entre les algorithmes d'obfuscation utilisés était le seul élément pouvant confirmer l'origine commune des deux programmes malveillants.

    Après avoir extrait la DLL cachée dans la mémoire de l'ordinateur et analysé ses principes de fonctionnement, nous avons établi un verdict définitif : la DLL est identique au Trojan-Spy.Win32.Sinowal et exécute les mêmes fonctions que l'espion.

    Ainsi, après l'autorisation du bot dans le réseau, la DLL est chargée sur la machine infectée. Il s'agit d'un module pour le vol de mots de passe et l'interception du trafic de réseau du PC.

    Sinowal est en quelque sorte un "voleur universel". Une fois entré dans le système, il se lance sans attendre à la recherche de tous les mots de passe et comptes d’utilisateurs disponibles d'une multitude d'applications.

     
    Code démonté du module de vole de mots de passe

    Liste des applications attaquées

    Total Commander Thunderbird FlashFXP SecureFX
    Windows The Bat Trellian FTP LeechFTP
    Commander Internet Explorer Crystal FTP e-Safekey
    AK-Mail Mozilla FireFox Folder Flash Player
    Inetcomm LeechFTP FAR Manager PuTTY
    Outlook FTPS FTP Voyager WinSCP
    MSO FireFtp CuteFTP SecureCRT

    La majorité des applications ciblées par le module de vol de données confidentielles intervient dans l'administration de sites Web. Pour les individus mal intentionnés, il s'agit de données critiques car ces sites peuvent être utilisés pour agrandir le réseau de zombies ou l'administrer ou pour installer des codes d'exploitation.

    Toutefois ce sont les comptes de services bancaires en ligne qui sont les plus appréciés des criminels.

     
    Partie de la liste des sites de services bancaires en ligne dont les mots de passe sont dérobés par le module. La liste compte près de 3 000 sites.

    En interceptant toutes les connexions de réseau de l'ordinateur infecté, la DLL cherche dans le trafic les requêtes envoyées vers des sites de services bancaires en ligne. Toutes les données que l'utilisateur saisit sur ces sites sont envoyées immédiatement vers le serveur des individus mal intentionnés.

    En utilisant le bootkit comme plateforme disposant d’un accès total aux ressources du système d'exploitation, le module d'espionnage peut organiser des attaques de l'homme du milieu (HDM) (http://fr.wikipedia.org/wiki/Attaque_de_l%27homme_du_milieu) en interceptant, par exemple, des données confidentielles depuis le navigateur.

    Le module est capable d'exécuter la quasi-majorité des fonctions des logiciels espions, depuis la simple interception de données via le clavier jusqu'à la substitution des connexions SSL protégées. Lorsqu'il contacte des sites via le protocole HTTPS, le logiciel espion peut ouvrir des fenêtres complémentaires dans le navigateur pour l'autorisation et l'utilisateur peut y saisir par erreur ses données en pensant qu'il se trouve sur le site de la banque.

    Le logiciel espion peut réorienter les requêtes de l'utilisateur vers des sites de phishing.

    Toutes les informations récoltées sont chiffrées et envoyées vers un serveur spécial.

     
    Exemple de serveur compatible avec les connexions SSL utilisé pour réorienter les utilisateurs vers une page de phishing (de gauche à droite : nom de domaine, adresse IP du serveur, sous-réseau où se trouve le serveur ; système autonome du réseau Internet)

     
    Exemple de serveur vers lequel sont envoyés les mots de passe volés des applications (de gauche à droite : nom de domaine, adresse IP du serveur, sous-réseau où se trouve le serveur ; système autonome du réseau Internet)

    Réseau malveillant

    Lorsqu'on analyse l'attaque dans son ensemble, il ne faut pas perdre de vue le fait que tous les composants du réseau du bootkit sont en perpétuel mouvement. Grâce au contrôle des serveurs de domaines (Names servers), les individus mal intentionnés peuvent changer rapidement et facilement l'emplacement des codes d'exploitation, du panneau d'administration du centre d'administration, l'emplacement de téléchargement du module et la collecte des données confidentielles. Ceci confère une énorme fiabilité au système car la reconfiguration des composants du réseau peut être réalisée sans configuration complémentaire du bootkit en lui-même et de ses modules.


    Schéma de fonctionnement du bootkit avec les serveurs

    Ampleur de l'infection

    La diffusion du premier bootkit, apparu vers la fin de l'année dernière, et du rootkit Rustock a eu lieu à l'aide de ressources du groupe IframeBiz. L'émergence actuelle du bootkit se déroule selon un tout autre scénario : elle est bien plus technologique et repose en grande partie sur le bilan des épidémies antérieures de Rustock et de Sinowal.

    Bien évidemment, les plaintes des utilisateurs sur le redémarrage de l'ordinateur ne peuvent servir d'indice d'une épidémie. La réponse univoque pourrait provenir des statistiques du réseau de zombies, obtenues depuis le centre d'administration. Toutefois, nous n'avions pas un accès complet au panneau d'administration. Il est toutefois possible d'avancer quelques chiffres.

    Au moment de l'analyse de l'incident, nous avons découvert cinq serveurs principaux impliqués dans le téléchargement de codes d'exploitation. Le nombre total de visites uniques depuis les Etats-Unis avoisinait les 200 000 personnes par jour.


    Nombre de visites uniques depuis les Etats-Unis sur deux sites contenant des codes d'exploitation

    Comme nous l'avons dit plus haut, le panneau d'administration du réseau de zombies change de place en permanence selon un algorithme déterminé et tous les bots sont loin de se connecter lors du "déplacement".

    Les graphiques ci-après montrent les étapes de la migration de certains centres, la "file" de connexions de bots au centre et les données sur le nombre de systèmes infectés. Comme on le voit, la taille totale d'un réseau de zombies était de près de 100 000 bots, ce qui est assez important. Pour rappel, dans ce cas, nous comptons uniquement les utilisateurs américains.


    Nombre de visites uniques depuis le territoire des Etats-Unis du panneau d'administration qui se déplace vers un autre domaine


    Nombre de visites uniques depuis le territoire des Etats-Unis du panneau d'administration qui reste sur les anciens domaines

    Méthodes de protection

    Les auteurs du bootkit ont déployé beaucoup d'efforts afin de créer un ensemble bien protégé, extrêmement mobile et invulnérable en réfléchissant à toutes les étapes de son fonctionnement, depuis l'infection des utilisateurs jusqu'à l'organisation de l'administration du réseau de zombies et sans laisser la place à la moindre erreur, même dans les détails (comme l'introduction d'un iframe dans le code des pages).

    Malgré les ruses employées par les auteurs du bootkit, les logiciels antivirus modernes doivent pouvoir empêcher l'introduction du code malveillant dans l'ordinateur.

    Qu'est-ce qui peut résister aux cybercriminels à chaque étape de l'infection ?

    Les astuces déployées par les individus mal intentionnés pour attirer les utilisateurs sur les sites malveillants et la génération de codes d'exploitation uniques visent non seulement à infecter un nombre maximum de victimes mais à lutter contre toute une série de logiciels antivirus existants.

    Ainsi, le remplacement de liens au lieu de l'ajout d'iframe vise à lutter contre les méthodes traditionnelles d'analyse du trafic Internet dans le cadre desquelles les iframes suspects sont analysés plus en détails avant d'être complètement bloqués.

    Si l'on tient compte des dizaines, voire des centaines de milliers de cas de sites légitimes compromis et de l'insertion sur ceux-ci de pages au contenu malveillant, la méthode la plus efficace pour se propager contre ces menaces consiste à bloquer les sites malveillants connus.

     
    Interdiction de l'ouverture d'une page d'un site infecté dans KIS 2009

    Les codes d'exploitation sont générés automatiquement pour chaque nouvel utilisateur. Le code d'exploitation change, mais le mécanisme d'obfuscation reste le même. Autrement dit, le logiciel antivirus peut détecter le script d'obfuscation à l'aide de la signature ou à partir d'une analyse heuristique.


    Exemple de détection d'obfuscation de codes d'exploitation

    Si le code d'exploitation est malgré tout chargé sur l'ordinateur, il ne fonctionnera pas si l'utilisateur applique les "correctifs" pour le système d'exploitation et le logiciel installé. Un scanneur de vulnérabilité peut mettre en évidence les applications vulnérables.

     
    Détection d'un composant d'un lecteur Flash avec une vulnérabilité ouverte

     
    Description de la vulnérabilité sur le site Viruslist.com

    Supposons que l'utilisateur possède une application vulnérable et que le code d'exploitation a fonctionné. Dans ce cas, le dropper du bootkit est téléchargé sur l'ordinateur. Il s'agit d'un fichier exécutable qui est formé sur le serveur pour un utilisateur en particulier, ce qui complique la détection sur la base de signatures.

    A ce stade, le moyen le plus efficace de lutter contre les virus est la défense proactive capable d'analyser un nouveau fichier inconnu, de définir ses fonctions et de réaliser une analyse heuristique du code et du comportement du programme malveillant.

     
    Au lancement du fichier exécutable, KIS 2009 l'analyse...

     
    ... et bloque l'exécution si l'analyse a mis en évidence un danger potentiel


    L'application présente un indice de danger élevé vu que l'analyse heuristique a déclenché Heur.Backdoor.Generic

    Si, au moment de l'infection, l'ordinateur de l'utilisateur n'était pas protégé par un programme antivirus puissant, le bootkit qui s'est introduit dans le système commence à fonctionner avant le lancement du système d'exploitation et du logiciel antivirus, ce qui lui permet de contrôler d'importantes fonctions système et de dissimuler sa présence dans le système.

    La découverte et la neutralisation du code malveillant peuvent être réalisées à l'aide d'un programme antivirus doté d'un puissant dispositif de lutte contre les outils de dissimulation d'activité, tout d'abord dans la mémoire du système...

     
    Détection de l'outil de dissimulation d'activité dans la mémoire d'un ordinateur infecté

    ...puis dans le secteur de démarrage du disque.

     
    Réparation MBR

    Le système se débarrasse complètement du bootkit.

     
    Rapport sur la réparation complète du système à l'aide de KIS 2009

    Conclusion

    La technologie du bootkit a marqué une révolution dans la création des virus. Elle exploite de puissants outils de diffusion et de fonctionnement au sein du réseau de zombies.

    Les technologies exploitées dans le rootkit Rustock offraient au programme malveillant un large éventail de possibilités pour échapper au radar des éditeurs de logiciels antivirus et compliquaient son analyse. Le bootkit exploite différentes méthodes pour éviter la découverte du programme malveillant au début de l'infection et tente d'infecter un maximum d'utilisateurs et d'éviter la mise hors service du réseau de zombies.

    L'ampleur de l'organisation du travail et des solutions technologiques employées par les individus malveillants est impressionnante : la programmation de bas niveau, l'exploitation de vulnérabilités dans des dizaines de logiciels tiers, le passage du mode de chargement du système d'exploitation au mode nul, le troisième cercle, la création d'application en C++ pour les systèmes exploitation nix, les protocoles de cryptographies, les protocoles d'autorisation des bots dans le système, etc.

    Il ne fait aucun doute qu'il aura fallu plusieurs mois pour développer un tel système et son fonctionnement requiert un débogage permanent et des dépenses pour acheter ou créer de nouveaux codes d'exploitation, de nouveaux domaines, de nouveaux centres d'hébergement, etc.

    La création, la planification, la réalisation et le soutien de toute cette structure n'ont pas pu être le fruit des efforts d'une seule personne. Nous sommes ici en présence du travail non pas d'un groupe de cybercriminels mais de plusieurs qui collaborent étroitement et sont chacun responsable de leur segment.

    L'histoire du bootkit illustre tout le spectre des principales menaces informatiques pour l'utilisateur moyen. Toutes les méthodes et technologies que nous avons étudiées sont employées activement par les individus mal intentionnés dans la grande majorité des programmes malveillants.

    L'infection via le navigateur, la technologie des outils de dissimulation d'activité, les réseaux de zombies, le vol des données de l'utilisateur, la cryptographie, l'obfuscation, la lutte contre les logiciels antivirus sont des phénomènes que nous avons rencontrés tout au long du troisième trimestre 2008 séparément ou regroupés dans le cas du bootkit.

    Une lutte efficace contre ces menaces complexes est possible uniquement en appliquant un large éventail de technologies de protection : logiciel antivirus avec filtrage du trafic, analyseurs de comportement, "bac à sable", système d'analyse du trafic de réseau et pare-feu. Un logiciel antivirus moderne doit pouvoir lutter non seulement contre les rootkits mais être capable également de neutraliser des phénomènes tels que les bootkits.

    Source:
    Kaspersky Lab
 

Copyright © 1996 - 2014
Kaspersky Lab
Industry-leading Antivirus Software
All rights reserved
 

Email: webmaster@viruslist.com