Pour rappel :
Un driver est un programme qui permet l'intéraction entre le matériel et le système d'exploitation (et donc logiciel/utilisateur).
Un driver se doit de pouvoir être chargé bas dans le système afin de pouvoir exécuter les opérations dont il a besoin.
Nous verrons plus tard que Windows permet le chargement de driver en "kernel-mode" pour cela, certains rootkits tirent partie de ce mode pour pouvoir se dissimuler dans le système.
Drivers, Registre Windows et Services
Les drivers sont des fichiers, en général, avec l'extension .sys (mais ce n'est bien sûr pas obligatoire), ils se trouvent en général dans le dossier %windir%\system32\drivers (mais encore une fois, ce n'est pas une obligation).
Un driver se charge à partir d'un service (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services)
Par exemple, le driver du programme gmer (gmer.sys) se charge à partir du service gmer avec les informations du registre suivantes :
Le driver se nomme gmer.[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\gmer]
"Type"=dword:00000001
"ErrorControl"=dword:00000001
"Start"=dword:00000003
"ImagePath"=str(2):"System32\DRIVERS\gmer.sys"
"Group"=str(2):"Base"
Le chemin du driver est donné par la valeur ImagePath.
A noter que ces services ne sont pas listés dans la console (services.msc), se reporter à la page : Dossier sur les processus et les services Windows
Certains programmes permettent de lister les drivers chargés, c'est notamment le cas (en autre) de :
Gmer depuis l'onglet Modules :
ou IceSword
Il est aussi possible de créer un fichier bootlog qui liste les drivers se chargeant lors de la séquence de démarrage de Windows.
Ceci se fait à partir de msconfig (onglet SYSTEM.INI)
Après redémarrage, Le journal créé est C:\Windows\ntbtlog.txt.
La liste des drivers chargés par l'OS apparaît, on peux alors vérifier si des drivers non légitimes sont présents.
Un driver est donc un fichier qui se charge à partir d'un service.
Vous trouverez plus d'infos sur cette page MSDN : http://msdn.microsoft.com/en-us/library/aa906371.aspx
Drivers & rootkits kernel-mode
Les rootkits kernel-mode se chargent très bas dans le système afin de pouvoir effectuer les opérations necessaires pour se dissimuler dans le système (modifier les appels systèmes [syscalls], placer des hooks dans la table SDDT etc. - pour plus d'informations se reporter à la page Le danger et fonctionnement des rootkits).
Pour se charger au niveau du kernel, le rootkit installe un driver.
Voici un exemple de driver du rootkit Rustock (voir http://forum.malekal.com/viewtopic.php?f=33&t=982).
On voit que le service se nomme fak32 et le driver fak32.sys
Pour le système, le service est complètement invisible :
Enfin de même, si l'on tente de supprimer le driver (fak32.sys), le fichier est introuvable pour le système.
Il est alors impossible de supprimer le fichier directement.
Une autre version de Rustock lorsqu'on tenter de supprimer le driver rediriger systématiquement la demande de suppression vers un fichier légitime Windows.
Les rootkits une fois en place peuvent comrompre le service à leur guise.
Toute la puissance des rootkits est là, le premier installé (rootkit/logiciel de protection) a en général un avantage sur l'autre puisqu'il controle le système.
Quelques autres exemples de Drivers
A noter que des programmes légitimes peuvent aussi hooker la table SDDT, c'est notamment le cas de certains programmes de sécurité (pare-feu, HIPS[url], etc).
Voici une capture de hooks de la table SDDT par le driver safemon.sys qui appartient à l'IDS [url=https://www.malekal.com/tutorial_SystemSafetyMonitor.php]System Safety Monitor
De même le programme Daemon Tools installe le driver sptd.sys qui donne les lignes suivantes sur gmer très souvent rapporté en rootkit par certains scanneur rootkit.
---- Kernel code sections - GMER 1.0.13 ----
? C:\Windows\System32\Drivers\sptd.sys Le processus ne peut pas accéder au fichier car ce fichier est utilisé par un autre processus.
.text USBPORT.SYS!DllUnload 89E9BACF 5 Bytes JMP 866CE1C8
? System32\Drivers\aep4ro7h.SYS Le fichier spécifié est introuvable.
---- Kernel IAT/EAT - GMER 1.0.13 ----
IAT \SystemRoot\system32\drivers\atapi.sys[ataport.SYS!AtaPortWritePortUchar] [8071861E] \SystemRoot\System32\Drivers\sptd.sys
IAT \SystemRoot\system32\drivers\atapi.sys[ataport.SYS!AtaPortReadPortUchar] [80717AD4] \SystemRoot\System32\Drivers\sptd.sys
IAT \SystemRoot\system32\drivers\atapi.sys[ataport.SYS!AtaPortWritePortBufferUshort] [80718748] \SystemRoot\System32\Drivers\sptd.sys
IAT \SystemRoot\system32\drivers\atapi.sys[ataport.SYS!AtaPortReadPortUshort] [80717B9C] \SystemRoot\System32\Drivers\sptd.sys
IAT \SystemRoot\system32\drivers\atapi.sys[ataport.SYS!AtaPortReadPortBufferUshort] [80717C1A] \SystemRoot\System32\Drivers\sptd.sys
IAT \SystemRoot\system32\DRIVERS\i8042prt.sys[HAL.dll!READ_PORT_UCHAR] [8072D29A] \SystemRoot\System32\Drivers\sptd.sys
---- Devices - GMER 1.0.13 --
Device \Driver\aep4ro7h \Device\Scsi\aep4ro7h1 IRP_MJ_CREATE 865F7790
Device \Driver\aep4ro7h \Device\Scsi\aep4ro7h1 IRP_MJ_CLOSE 865F7790
Device \Driver\aep4ro7h \Device\Scsi\aep4ro7h1 IRP_MJ_DEVICE_CONTROL 865F7790
Device \Driver\aep4ro7h \Device\Scsi\aep4ro7h1 IRP_MJ_INTERNAL_DEVICE_CONTROL 865F7790
Device \Driver\aep4ro7h \Device\Scsi\aep4ro7h1 IRP_MJ_POWER 865F7790
Device \Driver\aep4ro7h \Device\Scsi\aep4ro7h1 IRP_MJ_SYSTEM_CONTROL 865F7790
Device \Driver\aep4ro7h \Device\Scsi\aep4ro7h1 IRP_MJ_PNP 865F7790
(Note : Le nom du Device est aléatoire).
Quelques liens relatifs aux drivers :
http://msdn.microsoft.com/en-us/library/aa906371.aspx
http://fr.wikipedia.org/wiki/RkU
http://www.securityfocus.com/infocus/1850
http://en.wikipedia.org/wiki/Ring_(computer_security)