RootkitRevealer

couche la plus basse, c’est-à-dire les données de registres et du système de fichiers bruts. RootkitRevealer signale toutes les différences constatées entre les divers balayages, de sorte que si une valeur de fichier ou de registre apparaît dans le balayage de bas niveau mais pas dans celui de haut niveau, RootkitRevealer le signale. RootkitRevealer ne balaiera pas la mémoire, par conséquent il ne saurait détecter les processus dissimulés par une manipulation directe de l’objet kernel. Au lieu de cela, la solution de Rootkit- Revealer cible les root kits qui veulent survivre à une réinitialisation (quand la mémoire est réinitialisée). La figure 6 montre la sortie de RootkitRevealer après balayage d’un système sur lequel Hacker Defender est actif.

Quand RootkitRevealer est exécuté sur votre système, il peut fort bien signaler des différences qui n’ont rien à voir avec les root kits. En effet, tout changement apporté au système de registres ou de fichiers, comme la création, la suppression ou la modification d’une valeur de fichier ou de registre, qui se produit après le balayage de haut niveau et avant le balayage de bas niveau, peut fort bien conduire RootkitRevealer à signaler une discordance. Le service Microsoft SQL Server, par exemple, met à jour périodiquement un tampon horodateur qu’il stocke dans le registre et qui peut conduire RootkitRevealer à signaler une divergence.

Une autre différence se manifeste couramment. Elle est provoquée par les clés de registres dont le nom contient un caractère de terminaison de chaîne (c’est-à-dire 0). De tels noms ne sont pas entièrement visibles par l’API Windows et, par conséquent, les clés ne sont pas accessibles à des outils du genre Regedit. Comme les noms de clés sont visibles par l’API native, certaines applications les utilisent pour cacher des informations sur les licences ou d’autres types de données sensibles. RootkitRevealer ne filtre pas les différences parce qu’un root kit peut dissimuler son malware dans le plus petit fragment de données.

Pour cacher le root kit et les processus malware aux regards de Rootkit- Revealer, il faut qu’un root kit dissimule les structures de données des registres et des systèmes de fichiers qui trahissent la présence des processus. Comme beaucoup de structures de données ne sont pas documentées, il est très délicat de les documenter de sorte que RootkitRevealer ne détecte pas les incohérences. A l’heure actuelle, aucun root kit n’a encore atteint ce niveau d’intelligence.

Les propos précédents ne signifient pas que les root kits ne peuvent pas attaquer RootkitRevealer. En fait, CSS a déjà vu une attaque dans des instances de Hacker Defender découvertes sur les systèmes d’au moins un client : un auteur de malware avait ajouté RootkitRevealer à la section root process du fichier de configuration de Hacker Defender. Hacker Defender ne cache pas les objets aux yeux de tels processus et donc le balayage de haut niveau du système effectué par RootkitRevealer correspondait à son balayage de bas niveau et il n’a signalé aucune différence associée à Hacker Defender. Dès qu’elle a appris l’existence de cette attaque, Sysinternals a diffusé une version actualisée de RootkitRevealer qui effectue des balayages à partir d’un processus dont le nom est généré aléatoirement.

Avant longtemps, les développeurs de root kits trouveront d’autres moyens de détecter le balayage de RootkitRevealer et de désactiver aussitôt la dissimulation, ce qui conduira Sysinternals à répliquer à son tour par des mises à jour qui déjoueront leur détection. Tous les détecteurs de root kits sont vulnérables aux mêmes genres d’attaques ciblées, et plus un détecteur se généralisera, plus les développeurs de root kits chercheront à exploiter ses faiblesses. Disons que les détecteurs de root kits feront évoluer les mécanismes de root kits pour les dissimuler de manière à ce que les root kits ne puissent pas les cibler : ironique, non ?