De manière générale, les keyloggers (ou enregistreur de frappes) sont de petits programmes informatiques capables d’enregistrer les touches appuyées sur un clavier d’ordinateur.
Ils peuvent être utilisés de façon bienveillante, dans le cas d’un système de contrôle parental par exemple, ou de façon malveillante, dans le cas des virus informatiques. Dans ce dernier cas, ils représentent une menace sérieuse, souvent négligée. La plupart du temps invisible, même aux yeux des antivirus et pare-feu, ils sont capables récupérer les informations les plus sensibles telles que mots de passe, numéros bancaires ou secrets industriels. Qu’une personne effectue une recherche Internet ou achète un objet en ligne, toutes les informations recueillies sont susceptibles revendus (publicité ciblée, numéros de carte, adresses, etc.).
par Paul Amicelli
Laboratoire (C+V)O , Axe Confiance Numérique et Sécurité/Laboratoire de cryptologie et virologie opérationnelles (ESIEA)
Il existe trois grandes familles d’enregistreurs de frappes :
- Résidents en mode utilisateur
- Résidents en mode noyau
- Physiques
Cet article traite des keyloggers sous Windows, et propose de détailler leur fonctionnement.
Fonctionnement du clavier sous Windows
Pour comprendre le fonctionnement des keyloggers, il est d’abord nécessaire de comprendre ce qu’il se passe lorsqu’une touche du clavier est appuyée.
a. Le clavier
Le clavier est constitué d’interrupteurs pour chacune des touches. Ces interrupteurs forment une matrice lue en permanence par un microcontrôleur interne au clavier. Chacune des touches est associée à une valeur, indépendante de celle écrite sur la touche : le scancode. Lorsqu’une touche est pressée, le microcontrôleur génère une interruption au niveau de la carte mère de l’ordinateur et lui fournit le scancode associé. Lorsqu’elle est relâchée, les mêmes actions s’opèrent.
Le microcontrôleur de la carte mère réceptionne alors le scancode, le transforme en valeur hexadécimale, et le met à disposition de drivers sur le port 60h. Il déclenche alors une interruption matérielle (IRQ1), qui va être traitée par les différentes composantes du système d’exploitation.
b. Le rôle de l’OS
Lorsque l’interruption matérielle est générée, le système d’exploitation lit l’IDT (Interrupt Descriptor Table), ou, table d’interruption, afin de trouver la fonction logicielle en charge du traitement des interruptions (appelées ISR – Interrupt Service Routine) pour le clavier. Sous Windows, il s’agit d’une des fonctions du driver i8042prt, ce dernier s’occupant de la gestion des événements clavier et souris bas-niveau.
L’ISR du driver i8042prt va alors lire le scancode sur le port 60h, vérifier sa conformité puis le placer dans une file afin qu’il puisse être traité par le driver de classe Kbdclass. Par la suite un IRP (I/0 Request Packet) contenant les informations (dont le scancode) liées à l’interruption est généré et le driver Kbdclass le fait remonter dans la pile des drivers clavier.
Une pile de drivers (drivers stack) est une succession de drivers qui, ensemble, forme une chaine de traitement pour un périphérique donné.
Ainsi, la pile des drivers clavier est constituée comme suit sur les dernières versions de Windows :
1. Drivers filtrants supérieurs
2. Kbdclass.sys
3. Drivers filtrants inférieurs
4. I8042prt.sys
Chaque élément à un rôle bien particulier, et, plus le driver est bas dans la liste, plus il est bas dans le système et proche du matériel. Tout driver de la pile peut intercepter et modifier le message qui circule dans la pile. Ainsi, si un driver filtrant inférieur modifie le scancode émis via IRP, le driver Kbdclass.sys recevra le scancode modifié et ne sera pas notifié du changement.
Les drivers i8042prt et Kbdclass sont natifs et fournis par Windows. Ils offrent la compatibilité nécessaire au fonctionnement de la plupart des claviers. Les fabricants ont toutefois la possibilité d’étendre le fonctionnement de leurs produits en ajoutant des drivers filtrants dans la pile.
Lors du démarrage, la partie utilisateur du système d’exploitation (ring 3) ouvre un accès unique et privilégié au driver Kbdclass afin de pouvoir dialoguer avec lui. C’est par cet intermédiaire que le processus crscc.exe de Windows crée et envoie les IRP dans la pile des drivers clavier. Un IRP traverse la pile de haut en bas, vide et est mis en attente au niveau du driver Kbdclass. Lorsqu’une interruption survient, l’ISR d’i8042prt extrait les données et les places dans une file qui est traitée en différé via une routine DPC (Deffered Process Routine). Cette routine appelle alors un callback de Kbdclass, qui complète l’IRP et le fait remonter le long de la pile jusqu’au processus crscc.exe qui en renvoie un autre. L’IRP est traité par le processus afin de créer les messages Windows associés à la touche appuyée et les place dans les files d’évènements des threads concernés.
Le procédé, simplifié, peut être schématisé comme suit :
3. Les keyloggers
a. Les keyloggers en mode utilisateur
Il s’agit des keyloggers les plus communs de par leurs simplicité de réalisation et de mise en œuvre. Ils sont pourtant d’une redoutable efficacité, bien que facilement détectables. Ils utilisent la plupart du temps des fonctions fournies par l’API Windows.
La fonction SetWindowsHookEx est l’une d’entre elles. Elle permet, entre autres, de hooker le clavier, c’est-à-dire d’intercepter les entrées dès leurs mises en file. La fonction de hook se situe dans une librairie qui est injectée dans tous les processus du système. Ce dernier va appeler cette fonction à chaque fois qu’un message clavier est extrait de la file, permettant à n’importe quel processus faisant appel à la fonction SetWindowsHookEx de récupérer les entrées claviers. Bien que cette technique soit très simple à implémenter et très efficace, son utilisation peut être aussi facilement détectée puisqu’elle implique une injection dans tous les processus courants.
Une seconde méthode est d’utiliser les fonctions GetAsyncKeyState et GetKeyState. Elles permettent de vérifier si une touche spécifique est appuyée ou non. Utilisées dans une boucle de manière périodique, elles offrent la possibilité d’intercepter les touches frappées. Dû au caractère cyclique, cette technique n’est pas aussi fiable que la précédente, et son utilisation peut aussi être facilement détectée.
Il est aussi possible de hooker les fonctions de l’API fourni par les librairies standard du type user32.dll. En modifiant l’IAT (Import Address Table), un attaquant peut intercepter les appels à des fonctions telles que GetMessage et ainsi récupérer les messages clavier. Plus compliquée à implémenter, cette technique est néanmoins efficace puisqu’elle couvre toutes les catégories de clavier (physiques, virtuels, etc.).
Beaucoup d’antivirus ne couvrent pas la détection de la totalité des keyloggers présentées ci-dessus du fait qu’ils reposent sur une analyse comportementale ou sur la signature de virus connus.
b. Les keyloggers en mode noyau
D’un point de vue technique les keyloggers en mode noyau sont plus difficiles à implémenter et détecter, puisqu’ils demandent une connaissance approfondie du système d’exploitation. Ils prennent ainsi la forme de drivers, et se nichent au sein du système d’exploitation, devenant de facto invisibles aux yeux des logiciels en mode utilisateur. Il existe plusieurs méthodes pour intercepter les frappes en mode noyau. Certaines d’entre elles utilisent les callbacks proposés par les drivers natifs i8042prt et kbdclass, tandis que d’autres utilisent des méthodes plus subtiles.
Comme vue précédemment, la pile des drivers clavier est constituée du driver kbclass auquel peut être ajouté un driver filtrant supérieur. Ce dernier a la possibilité de récupérer les requêtes provenant de kbdclass (IRP_MJ_READ) et contenant des informations sur la touche appuyée. Il a également la possibilité de modifier ces informations. Ainsi, un tel driver peut inhiber toutes les requêtes et donc rendre inutilisable le clavier, bien que cela ne soit pas son but premier. Un tel dispositif est extrêmement efficace puisqu’il permet d’intercepter la totalité des frappes claviers. Néanmoins, il n’est pas possible de « voir » les touches générées par un clavier virtuel, et le driver doit pouvoir être installé.
Un attaquant peut aussi utiliser le callback KeyboardClassServiceCallback fourni par kbdclass afin d’être notifié de toutes les entrées claviers. Le résultat est similaire à la technique précédente.
Une autre méthode est d’utiliser le callback PI8042_KEYBOARD_ISR fourni par i8042prt. Il est appelé par l’ISR du driver immédiatement après avoir lu les données sur le port 60h. Le keylogger est ainsi un des premiers à lire les touches frappées.
Toutes ces techniques sont précisées dans la documentation MSDN de Microsoft et sont donc légitimes. Il reste néanmoins certaines possibilités d’attaques, non documentées, mais tout aussi dangereuses.
La substitution des drivers dans la pile des drivers clavier peut être utilisée afin d’en détourner le fonctionnement. Quelques fuites du code source de Windows 2000 sur la toile peuvent permettre de reconstruire les drivers originaux afin de rendre invisible le subterfuge. Il est aussi possible de corrompre l’IDT (Interrupt Descriptor Table) afin de changer l’ISR native par une ISR corrompue qui va enregistrer les informations associées à l’interruption, puis appeler l’ISR originale afin de rester transparente.
Toutes ces méthodes impliquent la création d’un driver, et donc son installation et lancement en mode noyau. Sur les versions 64 bits de Windows, les drivers doivent posséder une signature valide afin de pouvoir être lancés. Ce mécanisme complique grandement la tâche des attaquants puisqu’ils doivent outrepasser la protection. De plus, le nouveau système PatchGuard assure que l’IDT et les composantes vitales du système d’exploitation ne sont pas corrompus, assurant ainsi une protection maximale.
c. Les keyloggers physiques
Les keyloggers physiques sont les plus dangereux d’un point de vue technique, puisqu’ils sont indétectables de manière logicielle. Ils se présentent la plupart du temps sous la forme de petits dongles s’ajoutant au niveau du branchement du clavier.
Certains dongles peuvent transmettre les données directement par voie aérienne (connexion à un accès Wifi), ou bien les stocker de manière interne. Leurs capacités peuvent dépasser une année d’utilisation (2 milliards de frappes environ) et ils ont l’indéniable avantage d’être indépendants du système d’exploitation.
Certains sont même insérables dans un clavier externe voire dans un PC portable.
Avec un tel dispositif, un antivirus est inefficace, et seule la vigilance permet de le détecter (sauf pour les keyloggers implantés directement dans une machine). Néanmoins, leurs installations nécessitent un accès physique à la machine, et, une fois qu’ils sont détectés, il suffit de les débrancher pour inhiber leurs actions. Ce type de dispositif jusque-là encore rare, commence à faire son apparition dans les entreprises, en particulier du fait de son très faible cout (de 20 à 150 euros).
Conclusion
Les keyloggers posent un réel problème de sécurité puisqu’ils ont la capacité d’intercepter toutes les données qui sont saisies sur un clavier. De telles données peuvent être extrêmement sensibles, et les conséquences peuvent s’avérer désastreuses, que ce soit pour les particuliers ou les entreprises. La mise en place d’antivirus est primordiale, mais bien souvent à portée restreinte contre ce type de virus en constante évolution. Si les techniques rétroactives et proactives des antivirus reposant sur les signatures ou les analyses comportementales ont un impact limité, il existe d’autres solutions novatrices qui semblent être des alternatives efficaces, telles que le chiffrement des touches. Nous présenterons une telle solution lors de la DEFCON 2015.
À l’inverse, il faut aussi noter que les keyloggers peuvent être utilisés dans un but légitime si leur présence est déclarée, pour de la protection parentale, dans des cybercafés et hôtels, ou bien en tant qu’instruments de sauvegarde par exemple.
Bibliographie
1. Grebennikov, Nikolay. Keyloggers: How they work and to detecte them (Part 1 & 2). SecureList. [Online] 03 27, 2007. https://securelist.com/analysis/publications/36138/keyloggers-how-they-work-and-how-to-detect-them-part-1/.
2. PILLOU, Jean-François. Keylogger. Comment-Ca-Marche. [Online] 06 2015. http://www.commentcamarche.net/contents/1226-keylogger.
3. Wilkipédia. Keystroke Logging. Wilkipédia. [Online] 03 9, 2008. https://en.wikipedia.org/wiki/Keystroke_logging.
4. Dimov, Ivan. Keyloggers – How they work and more. InfosecInstitute. [Online] 08 15, 2013. http://resources.infosecinstitute.com/keyloggers-how-they-work-and-more/.
5. MSDN. SetWindowsHookEx – MSDN. MSDN – Microsoft. [Online] 2015. https://msdn.microsoft.com/en-us/library/windows/desktop/ms644990%28v=vs.85%29.aspx.
6. REFOG. Keylogger. Refog. [Online] 04 28, 2015. http://www.refog.com/keylogger/.