Vous êtes ici : Accueil » Articles » Système
>>Les rootkits
Sommaire - Les rootkits Les rootkitsCet article traite des rootkits sous windows. Initialement créé sous les systèmes unix, leur conception s’en est vu simplifiée grâce au code source libre du noyau. Les rootkits sont dorénavant exportés sous windows et produisent de nombreux soucis. Qu’est-ce qu’un rootkit ?Un rootkit est un programme furtif qui se rend invisible. Il modifie en temps réel les informations de windows. Il peut se cacher lui-même, cacher d’autre processus, masquer des connexions réseaux, masquer des clés de la base de registre, conrompre les espaces disques. La finalité d’un rootkit est d’obtenir un accès à l’ordinateur (backdoor) en toute transparence vis à vis de l’utilisateur et de masquer l’existence d’autres outils. Il est important de noter que l’installation d’un rootkit nécessite les droits administrateurs afin de modifier le coeur du système Comment fonctionnent-t-ils ?Windows travaille avec deux modes. Le mode utilisateur (user mode) et le mode noyau (kernel mode). La plupart des applications travaillent en mode utilisateur : word, gestionnaire des tâches, outlook ... Le mode noyau est réservé pour les accès aux périphériques, à la mémoire (ram), d’une manière général : au materiel. Une autre partie du noyau est consacré à répondre aux appels des différents programmes du mode utilisateur. Il faut savoir que windows propose un éventail de fonction permettant aux applications de fonctionner. Cet éventail est nommé API. Un programme en mode utilisateur qui souhaite ouvrir un fichier vas utiliser une fonction (API) nommée OpenFile(). Cette fontion fera appel à la fonction plus primitive NtOpenFile() contenue dans ntdll.dll qui elle-même fera appel à une fonction en mode noyau nommé ZwOpenFile() qui sera exécuté par ntoskrnl.exe.
Il existe différent type de rootkit qui vont agir en mode utilisateur au niveau de NtOpenFile() et d’autre en mode kernel au niveau de ZwOpenFile(). Les rootkits peuvent être persistant en s’installant définitivement sur le système ou simplement résidant ce qui complique leur détection. Techniquement, ils placent des crochets d’interceptions (hook) soit sur les fonctions de ntdll.dll grâce à une dll, soit sur les fonctions noyaux, grâce à un driver, en modifiant une table en mémoire nommée SSDT (System Service Descriptor Table). Cette table contient les emplacements mémoires des fonctions du noyau windows. Ces techniques permettent de rediriger les adresses des fonctions vers l’espace mémoire des rootkits afin de modifier la réponse qui sera renvoyé au programme appellant. Un rootkit est donc communément composé :
Une autre méthode utilisée par les rootkits consiste à réaliser un détournement des fonctions du noyaux sans modifier cette fameuse SSDT. Ainsi aucune anomalie n’est visible dans cette table. Cette méthode consiste à modifier directement la fonction en mémoire en y ajoutant quelques segments de codes pour réaliser une redirection. On pourrait résumer cette manipulation par de l’injection de code en mémoire centrale. Actuellement, seul un logiciel permet de savoir si une fonction à été modifiée ou pas. C’est outil se nomme Gmer et sera succintement décrit dans cette page. Comment les détecter ?Quelques solutions existent et font leurs preuves. Des outils permettent de contrôler la validité de la SSDT (System Service Descriptor Table), d’afficher les processus cachés ou encore de lister les fichiers cachés. En théorie le composant qui doit pointer dans la SSDT se nomme ntoskrnl.exe. Donc si d’autre programme ou driver gère la fonction, cela peut indiquer un détournement mal attentionner. Maintenant il est important de noter que certain programme modifie cette SSDT afin de fonctionner correctement. Les anti-virus agissent comme cela, certain pare-feu ainsi que d’autre programme comme DeamonTools. Il faut donc faire la différence entre des drivers fournis par des logiciels seins et des drivers fournis par des rootkits. Une simple recherche par le nom du driver sur google doit donner des pistes de recherche en cas de doute. Seem, à partir de la version 4.0, est capable d’afficher les détournements de cette SSDT. Une recherche Internet sur le nom du driver peut être automatiquement lancée.
Une comparaison avec d’autres outils peut également être judicieux afin de s’assurer de la conformmité des informations.
Dans cet exemple qui est donnée par l’utilitaire Vice, le driver klif.sys correspond au logiciel kaspersky Anti-virus. Il est donc naturel que ce logiciel intercepte les requêtes pour réaliser son travail. Le driver d347bus.sys correspond quant à lui au logiciel DeamonTools. Un autre exemple avec l’utilitaire KProcCheck, qui vas afficher les hook de la SSDT :
Dans ce nouvel exemple, pas d’inconvénient le driver fwdrv.sys correspond à Kerio Personnal Firewall. Maintenant, voici un cas concret. Les rootkits hxdef et FuRootkit sont conjointement utilisés. FU vas masquer le processus iexplorer.
Pour le gestionnaire des tâches de windows, ces processus sont invibles. Les fichiers de hxdef sont également invisibles dans l’explorateur de windows. Seem pourra sans mal détecter le rootkit ’hxdef’. La possibilité de terminer le processus est également fonctionnelle.
Au travers d’autre module de Seem, la détection de ce rootkit peut se faire en analysant les drivers chargés. Ainsi le driver du rootkit ’hxdef’ apparait : ’hxdefdrv.sys’
IceSword : Cet outil permet, tout comme Seem, de lister ces informations.
Le service associé au driver du rootkit est également visible avec cet outil :
KProcCheck détecte les crochets d’interceptions (hook) placés dans la SSDT. Tout comme IceSword et Seem, il détecte également les processus cachés. Il possède une option encore expérimentale permettant de restaurer la table. Attention cette action rendra inactif les éventuels anti-virus présents.
RootKit Revealer, un autre outil plus connu que les précedents, créé par l’excellent Mark Russinovich, permet également d’afficher les fichiers cachés et les clés de la base de registre. Néanmoins il ne permet de terminer un procesus cacher ou encore de stopper un service caché :
Gmer est pourvue d’une option très intéressante permettant de savoir si une fonction noyau à été modifiée ou pas. Ce type de patch n’inclus pas la modification de la SSDT, il est donc difficilement décelable. Gmer propose d’afficher les fonctions patchées ainsi que l’adresse ou le nom du module ayant effectué cette opération.
Dans cet exemple, ces modifications sont effectuées conjointement par IceSword et le rootkit de démonstration BadRkDemo. Actuellement, aucune option ne permet de restaurer une telle manipulation. La seule possibilité reste de neutraliser le driver responsable en supprimant son service Windows et en supprimant le fichier. Comment se prémunir ?Il n’existe pas de solution miracle. Néanmoins l’utilisation conjointe d’un anti-virus et d’un pare-feu reste fortement conseillé. Malgré tout les types de protection possible, il existe des rootkits qui patche la SSDT neutralisant ainsi le bon fonctionnement des logiciels de protection pour s’installer impunément. Dans tout les cas, l’installation d’un rootkit fait souvent suite à une action humaine. Que cela soit l’exécution d’une pièce jointe d’un e-mail ou une réponse affirmative à l’exécution d’un script d’une page internet, une simple action annondine peut engendrer de lourde pertubation. Leur installation peut également se réaliser grâce à une faille de sécurité, il est donc nécessaire que le système soit à jour. Il existe aussi des logiciels permettant de contrôler les modifications de la table SSDT, de contrôler l’exécution des programmes. Je vous invite à vous rendre sur Open-Files pour avoir un descriptif de ces outils. Un peu de code ...Un simple programme en mode utilisateur permet de vérifier la liste des processus en mode noyau. la méthode consiste à accèder à la mémoire du kernel puis de la parser. L’inconvénient est de connaitre les emplacements mémoires des informations sachant que cela varie entre les versions de Windows. L’intégralité du code n’est pas décrite, c’est simplement pour donner un aperçu : [...] switch (BuildNumber) { case 2195: // Win2000 ListOffset = 0xa0; PIDOffset = 0x9c; NameOffset = 0x1fc; break; case 2600: // WinXP ListOffset = 0x88; PIDOffset = 0x84; NameOffset = 0x174; break; case 3790: // Win2003 ListOffset = 0x88; PIDOffset = 0x84; NameOffset = 0x154; break; default: return STATUS_NOT_IMPLEMENTED; } if (size<4) return STATUS_BUFFER_TOO_SMALL; size -= 4; if (NULL == buffer) return STATUS_INVALID_PARAMETER; *buffer = 0L; mypi = (PMY_PROCESS_INFO)(buffer + 1); ListHead = ListPtr = (PLIST_ENTRY)(*pPsInitialSystemProcess + ListOffset); while (ListPtr->Flink != ListHead) { if (size < sizeof(MY_PROCESS_INFO)) return STATUS_BUFFER_TOO_SMALL; mypi->KPEB = (ULONG)ListPtr - ListOffset; mypi->PID = *(ULONG*)(mypi->KPEB + PIDOffset); mypi->CR3 = *(ULONG*)(mypi->KPEB + 0x18); pfnMemcpy(mypi->Name, (PVOID)(mypi->KPEB + NameOffset), 16); (*buffer)++; mypi++; size -= sizeof(MY_PROCESS_INFO); ListPtr = ListPtr->Flink; } [...] Toujours avec les deux rootkits précédement chargés (hxdef.exe et FuRootkit qui masque IExplorer.exe), on constate qu’ils sont bien visible avec ce procédé :
Références |