> Tech > A l’intérieur des root kits en mode kernel

A l’intérieur des root kits en mode kernel

Tech - Par Renaud ROSSET - Publié le 24 juin 2010
email

La plupart des root kits sophistiqués interceptent les API natives en mode kernel au moment où elles entrent dans l’OS, en utilisant system-call hooking. Les fonctions de Ntdll exécutent une instruction system-call pour faire la transition en mode kernel, mode dans lequel le dispatcher system-call de l’OS s’exécute. Les API

A l’intérieur des root kits en mode kernel

system-call sont identifiées en interne par le numéro, donc la fonction API native en mode utilisateur indique au dispatcher system-call le numéro de la fonction équivalente en mode kernel. Le dispatcher utilise ce numéro comme un index vers une table dans laquelle il stocke les pointeurs conduisant aux fonctions system-call. De la même manière que le DLL Import hooking, les root kits peuvent remplacer un pointeur dans la table par un pointeur vers la fonction du root kit, située dans un driver de périphérique, qui se comporte comme hook en mode utilisateur, en manipulant les données lors de leur renvoi à une application. NT Rootkit s’appuie sur un system-call hooking. La méthode de patching de fonction utilisée par Hacker Defender vaut aussi en mode kernel, bien qu’aucun des root kits publiés n’utilise le patching.

Il est une technologie root kit en mode kernel qui s’est répandue dans la communauté root kit : c’est la manipulation directe des objets kernel. Cette méthode attaque les structures de données du kernel elles-mêmes, plutôt que les API qui renvoient l’information sur les structures de données. Pour dissimuler un processus, par exemple, le root kit enlève le processus de la liste des processus actifs du kernel. Ensuite, NtQuerySystemInformation ne présentera pas le processus parce que NtQuerySystemInformation compte sur la liste des processus actifs pour son information, mais le kernel continuera à planifier les threads qui s’exécutent dans le processus. Ce genre de dissimulation a aussi été appliqué aux structures de drivers de périphériques, mais il est inapplicable aux clés de registres, aux valeurs de registres, aux fichiers ou aux répertoires, parce que ces objets ne sont pas maintenus avec de simples structures statiques. Le root kit FU pratique la dissimulation en utilisant la manipulation directe des objets kernel.

Une dernière approche adoptée par les root kits en mode kernel consiste à mettre en oeuvre la dissimulation dans un driver de filtres du système de fichiers. Les drivers de filtres du système de fichiers constituent une couche au-dessus des drivers du système de fichiers, comme NTFS, et audessous de la couche API appel système, de sorte qu’ils peuvent voir toute l’activité des systèmes de fichiers. Tous les scanners de virus « à l’accès » utilisent le filtrage des systèmes de fichiers pour intercepter les opérations d’ouverture de fichiers et pour scanner les fichiers et traquer les virus, avant de permettre la suite des opérations. NT Rooktkit utilise un driver de filtres de système de fichiers pour intercepter les requêtes de répertoires et enlever les références aux fichiers malware de la sortie renvoyée par le driver des systèmes de fichiers. Par conséquent, tout ce qui effectue une opération de listing de répertoires, que ce soit une application comme Windows Explorer en mode utilisateur, ou même un autre driver en mode kernel, est sujet à la dissimulation de NT Rootkit.

Téléchargez cette ressource

Guide de Sécurité IA et IoT

Guide de Sécurité IA et IoT

Compte tenu de l'ampleur des changements que l'IA est susceptible d'entraîner, les organisations doivent élaborer une stratégie pour se préparer à adopter et à sécuriser l'IA. Découvrez dans ce Livre blanc Kaspersky quatre stratégies efficaces pour sécuriser l'IA et l'IoT.

Tech - Par Renaud ROSSET - Publié le 24 juin 2010