Les
rootkits
Cet
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,
corrompre 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
matériel. 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 appelant.
Un
rootkit est donc communément composé :
d’un
driver : xxx.sys (mode kernel)
d’une
dll : xxx.dll (mode user)
d’un
programme : xxx.exe
d’un
fichier de configuration : xxx.ini
Une
autre méthode utilisée par les rootkits consiste à réaliser
un détournement des fonctions du noyau 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
succinctement décrit dans cette page.
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
judicieuse afin de s’assurer de la conformité 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 va 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 va masquer le processus iexplorer.
Pour
le gestionnaire des tâches de Windows, ces processus sont
invisibles. 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écédents,
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 processus
caché 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.
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 anodine
peut engendrer de lourde perturbation.
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
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édemment chargés (hxdef.exe et
FuRootkit qui masque IExplorer.exe), on constate qu’ils
sont bien visibles avec ce procédé :
security.org.sg
wikipedia.org
windowsitlibrary.com
osronline.com
ntkernel.com
cmkrnl.com
blackhat.com
book.itzero.com
rootkit.host.sk
