Comment dois-je déboguer l'erreur «Impossible de saisir le clavier. Un client malveillant peut espionner votre session. »


14

J'exécute une installation d'Ubuntu 14.04 que j'ai installée plus de 6 mois. Il y a environ une semaine, j'ai commencé à recevoir un message d'erreur:

Could not grab keyboard. A malicious client may be eavesdropping on your session.

Je ne l'ai jamais vu en revenant à mon ordinateur après avoir été absent pendant un bon moment (généralement la nuit). Plusieurs fois, il a empêché l'écran de se verrouiller après le délai défini (j'ai commencé à le verrouiller activement avant de partir).

J'utilise un clavier USB (Kinesis Advantage) directement connecté à un port USB sur la carte mère. J'utilise une souris sans fil ELECOM .

Je vais essayer de déconnecter le dongle de la souris avant de partir. Sinon, comment pourrais-je identifier s'il y a un client malveillant qui suit mes frappes ou s'il s'agit d'un problème de connectivité?


1
NE PAS ÉMETTRE DE COMMANDES SUDO SI VOUS PENSEZ QUE VOS TOUCHES SONT ENREGISTRÉES !!! au lieu de cela, démarrez un support live propre et continuez à partir de là.
j0h

Réponses:


13

Voici comment résoudre votre mystère. L'objectif est davantage d'enseigner aux utilisateurs "comment pêcher" en utilisant les utilitaires standard d'Ubuntu pour fouiller dans les détails de tout processus sur leur système.

Étape # 1 (pour la curiosité principalement): identifiez le programme qui vous donne cette erreur:

# -- You may need to search under more dirs, YMMV
#    List files (incl. binaries) which contain the warning string

$ sudo grep -ral 'malicious client may be eavesdropping' /usr /bin /lib
/usr/lib/openssh/gnome-ssh-askpass

Dans mon env, le seul programme qui contient cette chaîne d'avertissement dans son binaire est gnome-ssh-askpass. Je pourrais rechercher s'il y a un bug déposé sur ce programme particulier, et même télécharger sa source apt-get source ssh-askpass-gnome(notez que le nom du package est différent du nom du programme) pour une inspection plus approfondie.

Cependant, je soupçonne que la cause profonde n'est pas un problème en gnome-ssh-askpass. Puisqu'il vous gnome-ssh-askpassdemande votre phrase secrète, ses développeurs ont simplement choisi de faire preuve de prudence lorsqu'ils ne saisissent pas le clavier, d'assumer le pire des cas et de faire en sorte que le message sonne de manière ultra-paranoïaque. Mais notez que taper votre mot de passe ou mot de passe dans une boîte de dialogue de site Web aléatoire par accident n'est probablement pas une bonne idée, donc en ce sens, les gnome-ssh-askpassdéveloppeurs ont fait le bon appel.

Récemment, de plus en plus de sites Web ont commencé à pratiquer l'affichage d'une fenêtre contextuelle, à effacer tout le reste en dehors de la boîte de dialogue contextuelle et à saisir activement le focus. Cela pourrait être la cause principale de l' gnome-ssh-askpasséchec de la saisie du clavier. Si votre navigateur est ouvert sur un tel site, fermer le navigateur ou s'éloigner du site Web agressif peut vous aider. Si cela est la cause, vous pourriez être intéressé par un paramètre de bureau empêchant les processus individuels de saisir le focus complet (bureau complet). Dans KDE par exemple, ce paramètre se trouve sous ( Paramètres système -> Comportement de la fenêtre -> Focus -> Prévention du vol de focus ). Si vous vous sentez vraiment paranoïaque, je recommanderais de le régler sur Highou Extreme. Bien sûr, cela peut également empêchergnome-ssh-askpasslui-même de saisir le clavier, ou plus précisément: saisir la Xmise au point.

Étape # 2: Identifiez les processus suspects:

Sachant que sous Unix, les périphériques apparaissent comme des fichiers uder /dev, la question suivante est de savoir quel périphérique représente "le clavier" dans la hiérarchie du système de fichiers. Nous pouvons utiliser l' lsofutilitaire (liste des fichiers ouverts) pour cela.

# look for processes holding devices open, filter out some common ones:
$ sudo lsof | grep /dev | grep -vE '/(null|urandom|zero)'

Notez que la plupart des processus qui maintiennent les périphériques ouverts dans un environnement de bureau typique maintiennent /dev/pts/<N>(un pseudo tty ) ouvert. Ce sont les "appareils" qui nous intéressent.

Quelques informations sur ce qui se passe ici:

Dans un bureau graphique Linux typique, les processus ne parlent pas directement au clavier. Au lieu de cela, le Xprogramme (Xorg) contrôle tous les événements du clavier via un périphérique /dev/input/event<N>. Xutilise un gestionnaire d'événements (evdev) qui, entre autres, gère les événements du clavier. Vous pouvez également le vérifier en consultant le Xjournal: /var/log/Xorg.0.logkeyboardest mentionné.

Les événements du clavier sont transmis du Xgestionnaire d'événements au processus sur lequel le pointeur de la souris se concentre à tout moment via l'entrée standard du processus qui est ouverte /dev/pts/<N>. Strictement parlant: un processus ne "saisit pas le clavier", le clavier est tenu par X, le processus n'a (ou n'attrape) que le "focus" ou l'attention, Xdonc Xpeut lui transmettre des événements de clavier via un descripteur de fichier stdin ouvert sur /dev/pts/<N>.

Diagramme des événements clavier multiplexés via X evdev

Étape # 3: quel processus le focus Xorg à un moment donné?

Comment comprendre quel processus a le focus à un moment donné? Voici une question askubuntu répondant à ceci:

découvrez l'application sous la souris

Le résumé de la réponse consiste à exécuter un script comme celui-ci dans un terminal tout en naviguant avec la souris:

#!/bin/bash
# Print the process tree of the window currently in focus.
# prereqs:
#   sudo apt-get install xdotool psmisc

while true; do
   pstree -spaul $(xdotool getwindowpid "$(xdotool getwindowfocus)")
   sleep 2
done

Étape # 4: approfondissez l'activité du processus

Une fois que vous avez identifié un processus suspect, la dernière étape consiste à enquêter sur ce processus individuel. Pour cela, vous pouvez vous tourner vers le système de /procfichiers Linux ( man 5 proc).

Presque tout ce que vous voudrez peut-être savoir sur un processus est disponible sous /proc. En fait, des programmes comme lsof(lister les fichiers ouverts), des débogueurs qui examinent l'état du processus et des utilitaires de listage de processus comme psou top, tous s'appuient sur /procce qui est rempli par le noyau, pour les données.

En utilisant, procvous pouvez trouver où le programme exécutable du processus se trouve sur le disque (par exemple, tout programme en dehors des répertoires système standard, en particulier s'il essaie de se cacher sous un nom "ne faites pas attention à moi" , peut être suspect) et en utilisant un débogueur ou un traceur d'appels système, vous pouvez examiner ce qu'ils font exactement au niveau des appels système (même si vous n'avez pas leur code source).

Les étapes 2 et 3 devraient vous donner tous les identifiants de processus PIDqui peuvent potentiellement lire votre clavier. Pour chacun de ces PIDS (notons chacun comme $pid), vous pouvez:

Mappez $ pid à sa ligne de commande complète:

cat /proc/$pid/cmdline

Mappez $ pid à son exécutable sur disque:

ls -l /proc/$pid/exe

Mappez $ pid à son répertoire de travail actuel:

ls -l /proc/$pid/cwd

Mapper $ pid à son environnement d'origine

cat /proc/$pid/environ | tr '\000' '\012'

Tracez $ pid (et ses enfants-procs) activité d'appel système en temps réel:

strace -f -p $pid

(Il y a plus: voir man 5 proc)

Si vous voyez un processus inconnu qui réagit à chaque pression de touche en le stockant dans un fichier (via write) ou en l'envoyant via le réseau à via sendto, vous avez peut-être trouvé un renifleur de clavier.

Vous pouvez également vérifier quels processus ont des points de terminaison réseau (tcp + udp) ouverts:

# See 'man netstat' for details on all options used below
$ sudo netstat -tunapee

Conclusion:

La cause la plus probable de l'erreur n'est pas un malware, mais plusieurs processus essayant d'obtenir le contrôle du clavier en même temps. L'un des deux est gnome-ssh-askpass(celui qui imprime l'erreur). L'autre peut être un navigateur ouvert sur un site avec une boîte de dialogue agressive d'acquisition de focus.

Même si vous avez en fait peu de logiciels malveillants installés à distance, la bonne nouvelle est que, puisque vous êtes sous Linux, tous les processus sont transparents pour vous de rechercher et d'inspecter. Il serait très difficile pour un malware de vraiment vous cacher ou de vous empêcher de le localiser facilement à l'aide des techniques ci-dessus, de tuer ses processus et de supprimer tous ses fichiers.


Au cours de l'étape 2, je ne vois pas beaucoup de processus se tenir /dev/pts/7(seulement 3 valeurs pid uniques). En parcourant les résultats, il semble que l'appareil le plus efficace soit /dev/pts/15bien que certains tiennent 1, 3, 12, 16, 17, 21, 22, 23, 24, 25, 25, 26, 27, 28, 29, 30, 31, 32, 34. Le clavier est-il toujours 7? Comment pourrais-je identifier lequel est mon clavier?
Steven C. Howell

Il peut s'agir de l'un des éléments ci-dessus. Le dispositif de clavier physique est en fait ouverte par Xorg ( /usr/bin/X) comme /dev/input/eventNoù vous pouvez trouver votre Nen regardant la chaîne evdevdans /var/log/Xorg.0.log. Xorg «transmet» ensuite chaque clic du clavier au processus individuel qui a le pointeur de la souris «concentré» à cet instant particulier. Quand je cours, ssh-askpassje vois qu'il est /dev/pts/3ouvert mais dans n'importe quel env, il peut s'agir de n'importe quel pseudo périphérique. Donc, chacun de vous /dev/pts/Npeut être pertinent ici.
arielf

@ stvn66 J'ai ajouté un petit script vous indiquant quel processus a "le focus" à plusieurs reprises (référence à une question connexe sur askubuntu). HTH.
arielf

après avoir exécuté le script pour identifier les processus qui tiennent la souris, comment identifier un suspect? Il semble que ce soit l'application que je sélectionne, par exemple, démarre lorsque le terminal dans {firefox}lequel j'ai exécuté le script, bascule lorsque je clique sur Firefox, bascule à nouveau {thunderbird}lorsque je sélectionne Thunderbird. Rien ne ressort comme inattendu. Peut-être que cela va à votre résultat : le problème ne vient pas de quelque chose qui saisit le clavier. J'aurais aimé être certain que cet avis est vide de sens ou pourrait l'éliminer.
Steven C. Howell

@ stvn66 Je vous entends :) vous ne pouvez pas remonter dans le temps et comprendre le processus qui avait le focus à l'origine. Ce processus a peut-être cessé depuis lors. Pour être vraiment sûr, vous devez pouvoir vous reproduire. Ma meilleure supposition est que c'était votre navigateur ( firefox) lors de la visite d'un site Web avec un pop-up de capture de focus. À moins que vous ne téléchargiez et installiez régulièrement des logiciels à partir de sources douteuses (non canoniques), je doute fortement que vous ayez accidentellement installé un renifleur de clavier sur Ubuntu. Il est bon d'être un peu paranoïaque, mais il n'est pas nécessaire de le transpirer.
arielf

1

Mon problème était dû à deux gnome-ssh-askpassfenêtres simultanées . J'ai eu deux tâches rsync sur le même serveur via SSH, et les deux ont essayé de demander le mot de passe du certificat SSH. Les regrouper (et les enchaîner) les a résolus pour moi!

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.