XPAJ. Étude d’un bootkit sous Windows x64

Avant-propos

Le nombre de bootkits ne cesse d’augmenter. Il existe une grande diversité au niveau des bootkits, des plus simples aux plus complexes, poursuivant chacun des objectifs propres (il peut s’agir de rootkits ou de chevaux de Troie d’escroquerie). Les auteurs de virus n’hésitent pas à analyser le code malveillant de leurs concurrents.

De nos jours, rares sont les experts qui sont surpris par les nouveaux bootkits : l’infection des secteurs de démarrage est un phénomène bien connu et Internet permet d’obtenir assez d’informations sur le sujet.  Ceci étant dit, nous avons découvert un exemplaire intéressant : l’infecteur de fichiers Xpaj doté d’une fonction de bootkit tournant aussi bien sous Windows x86 que Windows x64. Ce qui le rend intéressant, c’est que sous Windows x64, avec le mécanisme de protection Patch Guard opérationnel, il  fonctionne avec des hooks dans le noyau pour protéger le secteur de démarrage infecté contre la lecture et la modification .

Dans le cadre de cet article, je me suis intéressé seulement au fonctionnement du rootkit sous Windows 7 x64. Il n’est pas nécessaire d’étudier le fonctionnement du rootkit sous Windows x86 car l’algorithme de fonctionnement du rootkit est plus au moins semblable dans les deux cas.

Charge d’essai ?

Sur la base des résultats de l’analyse de cette même modification de Xpaj réalisée par nos confrères de Symantec, nous pouvons avancer les points suivants :

  • L’infecteur de fichiers Xpaj n’infecte pas les modules exécutables 64 bits, dont les pilotes en mode noyau. Autrement dit, le virus infecte uniquement les fichiers exécutables 32 bits (.exe et .dll).
  • Les fichiers infectés ne contiennent pas de mécanisme d’autoreproduction.
  • Le code injecté depuis le mode noyau dans une application 64 bit se contente d’afficher un message de débogage et ne contient rien d’autre.

En fonction de ces éléments et des statistiques d’infection (cf. ci-après), nous pouvons affirmer que cet exemplaire du virus n’est qu’une version d’essai. Il est probable que la prochaine version du programme malveillant sera complète et peut-être que les auteurs du virus auront mis en œuvre un mécanisme d’infection des fichiers exécutables 64 bits, dont les pilotes en mode noyau (à l’exception bien sûr du mécanisme de vérification des signatures).

Chargement

Comme toujours, tout commence par un MBR infecté. La tâche principale du secteur de démarrage principal infecté consiste, comme dans la majorité des cas antérieurs, à lire des secteurs complémentaires et à les exécuter.

Ces secteurs complémentaires à la fin du disque contiennent les modules que le bootkit charge en fonction des besoins. Tous les modules, à l’exception du premier, sont compressés par APLib.

L’algorithme de fonctionnement du premier module est le suivant :

  • Lire le MBR d’origine avant l’infection et l’inscrire dans la mémoire à la place du MBR infecté.
  • Intercepter l’interruption 13h, responsable de la lecture et de l’écriture des secteurs du disque.
  • Transmettre le contrôle au secteur d’origine.

Après le transfert au MBR d’origine, l’initialisation du système d’exploitation se poursuit. Pendant l’initialisation du système d’exploitation, le fichier noyau et les composants nécessaires sont lus à partir du disque. Dans le hook de l’interruption, le bootkit attend la lecture du fichier noyau, calcule la somme de contrôle depuis le début du fichier et vérifie certains champs de l’en-tête.

Pour la poursuite de l’initialisation du bookit, la méthode sélectionnée ressemble à celle utilisée dans TDL-4, si ce n’est que cette fois-ci, la victime est le fichier du noyau et non pas KDCOM.DLL. Lors de la lecture  du le fichier du noyau le bootkit conserve les premiers 0x120 octets depuis le début du fichier et écrase les en-têtes avec son code.

PVOID MmMapIoSpace(
IN PHYSICAL_ADDRESS PhysicalAddress,
IN SIZE_T NumberOfBytes,
IN MEMORY_CACHING_TYPE CacheType
);

Cette fonction permet de charger une adresse physique dans la mémoire virtuelle. N’oubliez pas que le premier module du bootkit se trouve toujours dans la mémoire physique au moment du premier appel de cette fonction.

L’initialisation du bootkit se poursuit après l’appel de fonction interceptée.

Important : lors de l’appel de la fonction ZwLoadDrive détournée, un marqueur indique que la fonction a déjà été invoquée. Ce marqueur est installé avant la tentative d’ouverture du lien symbolique « ??physicaldrive0 ». En cas de nouvel appel du hook, la fonction d’origine est directement appellée. Le fait est que ce lien n’apparait uniquement à un moment donné de l’initialisation du système d’exploitation. Ainsi, en cas d’appel de la fonction ZwLoadDrive depuis un pilote aléatoire pendant le début du chargement du système d’exploitation, avant la création du lien, empêcherait le bootkit de s’initialiser correctement.

Ceci marque la fin du fonctionnement du premier module et l’exécution est transmise au troisième module qui termine l’initialisation du bootkit dans le système.

Fonction de rappel

Pendant l’initialisation, le bootkit active deux fonctions de rappel. 

La première fonction arrête les processus des logiciels antivirus. Lors de l’invocation de la fonction au moment de la création de n’importe quel processus dans le système, le bootkit calcule la somme de contrôle au nom du processus et la compare à sa liste interne de sommes de contrôle.


Illustration 12. Sommes de contrôles des noms des processus

Quand une somme de contrôle d’un nom de processus correspond à une somme de contrôle de la liste du bootkit, le bootkit insère l’instruction RET au point d’entrée et le processus est arrêté.

Et qu’en est-il de Patch Guard ?

J’ai déjà cité ce mécanisme de protection intégré au noyau du système d’exploitation 64 bits de Windows.  Patch Guard vise à empêcher la modification du noyau du système d’exploitation et de ses structures critiques telles que diverses tables de service (SSDT, IDT, GDT), les objets du noyau, etc. Le mécanisme de protection s’active à une étape antérieure de l’initialisation du noyau et après un certain temps, il recherche la présence éventuelle de modifications dans ces structures. S’il découvre des modifications, un arrêt contrôlé du système a lieu. Ce mécanisme a été développé avant tout pour offrir une protection contre les rootkits en mode noyau. Mais la médaille a un revers : de nombreux logiciels antivirus et de protection utilisaient les interceptions dans le noyau à diverses fins, notamment dans le cadre du module de défense proactive.

Les débats entre les éditeurs de logiciels antivirus et Microsoft à ce sujet font toujours rage. Certains estiment que le noyau ne doit contenir aucun détournement non documenté des éditeurs de logiciels antivirus et qu’il faut trouver d’autres moyens pour lutter contre l’intrusion de code malveillant dans le noyau. D’autres estiment que Microsoft ne garantit pas le niveau de protection requis et que les interceptions sont nécessaires pour améliorer la sécurité du système d’exploitation. Et il y a également des personnes qui pensent que si du code malveillant s’introduit dans le noyau, on ne peut pas faire confiance au système et qu’il est inutile de traiter de tels systèmes. Chaque partie détient une part de vérité et je ne souhaite pas attirer l’attention sur ceci.

N’importe quelle protection peut être déjouée d’une manière ou d’une autre. Patch Guard n’est pas une exception. Ce mécanisme a bien été étudié par des analystes tiers et par des individus malintentionnés, si bien que plusieurs méthodes pour le contourner ont été mises au point. Par exemple, TDL-4 utilise une méthode conceptuelle qui fait que le mécanisme de protection n’analyse pas l’emplacement de l’interception de ce rootkit. Il existe également des mécanismes connus qui reposent sur la modification du « loader » et du noyau du système d’exploitation, qui visent à désactiver l’initialisation de Patch Guard. Il y a également une méthode qui repose sur la modification du noyau déjà initialisé et qui désactive le lancement du mécanisme de vérification. De même, Patch Guard n’est pas initialisé en cas de connexion d’un débogueur en mode noyau au démarrage du système d’exploitation (ceci permet aux développeurs d’utiliser les points d’arrêt pour le débogage et les essais de leurs pilotes).

Ce qui est intéressant dans Xpaj, c’est qu’il utilise une autre méthode conceptuelle pour déjouer Patch Guard. Le fait est que l’initialisation de Patch Guard n’a pas lieu à l’étape la plus précoce du chargement du système d’exploitation. Vu que Xpaj est un bootkit, il peut contrôler n’importe quelle étape du chargement du système d’exploitation et modifier le noyau avant le début de l’initialisation du mécanisme de protection. Au moment de l’initialisation, le noyau contient déjà toutes les modifications et interceptions de Xpaj et au lieu de détecter ces modifications, Patch Guard les protège 

J’ai réalisé une petite expérience pour confirmer que Patch Guard protège bel et bien les interceptions ZwLoadDriver/NtReadFile/NtWriteFile. J’ai démarré le système infecté en mode débogage, j’ai attendu le chargement, j’ai connecté le débogueur de noyau et j’ai restauré les octets modifiés d’une des fonctions interceptées. Après quelques temps, le système s’est arrêté. Autrement dit, Patch Guard a détecté des modifications du noyau dans la mémoire et a invoqué BSOD.

Statistiques

Grâce à notre service dans le nuage KSN, j’ai pu récolter des statistiques sur les détections de secteurs de démarrage infectés par Xpaj et sur le nombre d’installateurs détectés de ce programme malveillant. Ce qui est particulièrement intéressant, c’est la répartition géographique du bootkit et, bien entendu, les versions des systèmes d’exploitation infectés.

Conclusion

En 2008, nous avons assisté à la renaissance d’une ancienne technologie : l’infection des MBR. Beaucoup d’eau à couler sous les ponts depuis. Aujourd’hui, les bootkits représentent la tendance moderne du développement de rootkit et ce mécanisme va demeurer dans l’arsenal des individus malintentionnés à court term

L’infection des secteurs de démarrage est une méthode très pratique pour initialiser un code malveillant le plus tôt possible et de plus, elle offre d’énormes possibilités au niveau du contrôle du chargement du système d’exploitation.

Les systèmes d’exploitation de la famille Windows x64 sont bien intégrés dans la vie des utilisateurs et, naturellement, les auteurs de virus tentent de créer des programmes malveillants universels pour pouvoir maintenir un nombre d’infections élevé.

Afin de lutter contre les rootkits, Microsoft a introduit une série de restrictions et de nouvelles technologies pour Windows x64, toutefois comme le montre la pratique, l’exigence de signatures valides pour les pilotes en mode noyau, ni la présence du mécanisme Patch Guard n’ont permis de corriger complètement la situation. Les rootkits pour les systèmes d’exploitation 64 bits ne vont pas disparaître et leur nombre va continuer à augmenter.

Posts similaires

Laisser un commentaire

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