Forum

Bonjour tout le monde,

Profitant du confinement pour "approfondir" le bash, je suis toujours surpris de tout ce qu'on peut faire avec ce langage de script et les utilitaires associés : c'est d'une puissance ! Pour exercice, j'ai "revisité" le keylogger ( y'en a plein sur internet, mais pas en bash ). Ça permet d'enregistrer toutes les touches pressées sur le clavier; et potentiellement "voler" les mots de passe des utilisateurs
c'est tellement simple sous Linux que ça en donne des frissons. Tout ça pour dire qu'il ne faut jamais saisir de mots de passe au clavier sur une autre machine que la sienne !

Manip (en root) :
- trouver le périphérique correspondant au clavier : dans /dev/input/by-id, on fait un cat sur chaque périphérique si on a un doute. Si ça sort des caractères à chaque appui de touche, alors, c'est le bon !
- Ensuite:
-- Pour démarrer le keylogger, dans un terminal, on fait par exemple :
output="/root/keylogger_"`date --iso-8601=seconds`".evt"
cat /dev/input/by-id/usb-046a_0023-event-kbd > $output
-- Pour l'arrêter, CTRL+C.

Tout ça peut être mis dans des scripts au démarrage du système, mais là ça n'est pas le but.

Ensuite, pour lire le fichier .evt créé, je propose le script suivant:
keylogger_analyse.txt

Il faut peut-être l'adapter à son clavier en modifiant le tableau de correspondance. Avec l'utilitaire showkey en root, c'est très facile d'optenir les codes des touches.



Voilà.
Même si ça ne sert pas à grand chose, je partage. Ça peut faire un bon exercice pour les apprentis linuxiens, avec une proposition de correction
Linux, quelle puissance !

merci pour le partage, et le rappel :

Salut Choucroot !
Merci, ça me fait découvrir des trucs !

En passant, c'est mon avis personnel, mais je pousse tout le monde à en faire autant :

Je déteste et milite contre la syntaxe `commande` pour 2 raisons :
1) ça complexifie et c'est difficilement lisible
2) difficile de faire une sous-sous-commande.

Essaie plutôt :


Sinon, j'aime aussi que les variables soit entouré par les accolades, ça permets aussi d'aller plus loin dans la syntaxe ! Je n'ai plus d'exemple en tête où les accolades... Ah si !

J'espère que cet exemple t'a convaincu de l'utilisation systématique des accolades.


Merci, beaux scripts !

Jybz is right !
Que d'erreurs de compréhension ou d'écriture évitées quand j'ai abandonné l'anti-quote "`". Et dans les commandes à rallonge ou les sources de awk...

Édité par magnux77 Le 24/04/2020 à 08h48

@Jybz : Ah oui, merci !
Je ne savais pas qu'on pouvait faire $(date --iso-8601=seconds) . carrément mieux que les ` ` !
Et ça résoud aussi les variables à l'intérieur, tout pareil ! comme : format_date="--iso-8601=seconds" ; echo $(date ${format_date})

Effectivement, les {}, ça rend plus lisible !

Du pur génie, ce bash !
Chouette. Merci !

Bonjour choucroot

Passionnante et instructive cette discussion, mais il y a un truc que je ne pige pas.
Quand j’exécute le script de lecture, je constate que toutes les touches sont répétés 2 fois.
exemple ci dessous :

Bonjour.

Oui, c'est du brut de fonderie, à savoir ça analyse les événements systèmes qui sont envoyés par le périphérique.

| k ¬ | k ↑ | ~ touche k enfoncée puis relevée ==> c'est un k (minuscule)

SHIFT_G ¬ | c ¬ | c ↑ | SHIFT_G ↑ | ~ shift gauche enfoncé, touche c enfoncée puis relevée, shift relevé => c'est un C (majuscule)

Effectivement, y'aurait moyen de peaufiner le script afin qu'il fournisse non pas la séquence de touche, mais la séquence de caractère !

Pas (encore) eu le temps mais ce serait un bon exercice.
Là dans l'état, on peut sans trop d'effort récupérer un mot de passe, ce qui est le but d'un keylogger

Merci pour l'explication C'est super clair.
Je ne sais pas à quoi, ça va me servir, mais je suis content d'avoir appris quelque chose et du coup, je me sens un petit peu pirate
Et puis je retiens l'abandon du ` et le {} pour les variables .

@+

Après, sans se fatiguer, y'a déjà un simili-keylogger qui donne en plus les touches ! C'est showkey
Mais c'est fourni par kdb; du coup par sûr que ça soit installé de base sur toute les distrib, et donc utilisable par un "pirate".
Et surtout on n'apprend rien à juste l'utiliser
localhost Bureau # rpm -qf $(which showkey)
kbd-2.0.4-2.mga7

(j'ai utilisé $() !! c'est vrai que c'est la classe ! )

Ca donne ça:

localhost ~ # showkey --ascii

Appuyer sur n'importe quelle touche. Ctrl-D mettra fin au programme

d 100 0144 0x64
s 115 0163 0x73
a 97 0141 0x61
Q 81 0121 0x51
...
...

Bonjour,

ça me fait penser à un truc, ce showkey : comment détecter un keylogger si je suis un utilisateur ?

Au départ, je pensais voir un process un plus à l'écoute du périphérique clavier. Mais non
En effet, si je lance showkey, alors je ne vois aucune différence lorsque je regarde qui est abonné au périphérique "clavier".
Avant ou pendant l'exécution, j'ai ça
localhost ~ # lsof /dev/input/by-id/usb-046a_0023-event-kbd
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
acpid 869 root 10r CHR 13,80 0t0 17308 /dev/input/by-id/../event16
systemd-l 885 root 20u CHR 13,80 0t0 17308 /dev/input/by-id/../event16
Xorg 1451 root 31u CHR 13,80 0t0 17308 /dev/input/by-id/../event16
localhost ~ #

Bref, showkey n'utilise pas le périphérique comme dans mon script. De toute façon la commande lsof n'est pas accessible en tant qu'utilisateur "normal" !

J'ai essayé de l'exécuter avec strace pour voir s'il y avait des ouverture d'un autre périphérique /dev, mais nada ! Ca doit surement passer par Xorg ?
Peut-on demander à Xorg qui est abonné au événement clavier ?

Bref, d'après vous, en tant qu'utilisateur, y a-t-il un moyen de savoir que le clavier est espionné ?

Édité par choucroot Le 27/04/2020 à 16h18

Non, je dirais qu'il n'y a aucun moyen.
Le premier programme démarré est Root avec l'init. Puis il se divise, et réduit les droits de ses processus détachés, jusqu'au processus utilisateur.
L'utilisateur peut encore se diviser et faire de nouveau processus, mais pas avec plus de droits qu'il n'en a lui même.

Xorg est lancé par root et as les droits root. C'est l'interface qui reçoit les "trucs" claviers (et autre) pour les transférer en cascade jusqu'à l'application.
L'application n'utilise que "scanf" de "stdin". Elle n'a pas moyen de savoir "d'où" l'information vient à priori.

Mais peut-être qu'il y a un moyen ! En tout cas, je ne le connais pas...
Modifier le système pour n'autoriser qu'une seule et unique application (Xorg?) à lire le fichier périphérique ?

Le truc qui me chiffonne est que les événements clavier sont reçus par showkey (ou idem par l'écoute du périphérique) même si la fenêtre 'terminal" n'a pas le focus. Si dans un terminal je fais un "read", alors ça ne fonctionne que si la fenêtre a le focus (même si je suis root).
Du coup, quelle est la différence entre "stdin" dont tu parles et l'entrée standard dans un terminal ?

Désolé, c'est compliqué et je ne comprends pas tout...

Regarde ça, ouvre deux terminaux,
dans l'un, tape :

ça te donne un code, tu le mémorises.
Puis tu tapes dans ce même terminal :

Tu ne valides pas la commande
Tu passes sur le second terminal, et tu tapes :

à savoir, 0 c'est "stdin".
Puis, tu reviens dans le premier terminal, et tu tapes :

et cette fois si, tu valides.

Dis moi à quel résultat tu t'attendais et quel résultat tu as eu.

Merci.

Résultat : Je constate que la commande "echo -n "test" >/proc/14825/fd/0 " dans le terminal B provoque l'apparition de la chaine "test" dans le terminal A. Or d'après la doc de bash, "$$" est le pid du terminal (ici 14825) . Donc, si je comprends bien ton exemple, n'importe qui peut envoyer des caractères sur l'entrée standard d'un processus au moment où il en connait l'id. Donc effectivement ça m'explique qu'il n'y a pas besoin d'avoir le "focus" pour recevoir des caractères sur l'entrée standard. Ca c'est top !

Mais je vois plus la chose comme un "abonnement". on a constaté que le keylogger (comme showkey) n'était pas directement branché au périphérique du clavier, mais que quelqu'un devait alors forcément lui envoyer les caractères sur son entrée standard (dont tu m'as prouvé avec brio le mécanisme ).
Mais qui est à l'origine de l'envoi ? Xorg ? Du coup, faut bien alors que showkey le lui demande !?
Et ça me fait penser, au démarrage, on a un avertissement:
localhost # showkey
le mode clavier était ?INCONNU?
[ si vous essayez cela sous X Window, cela peut ne pas fonctionner
étant donné que le serveur X utilise également /dev/console ]


A priori, y'aurait un /dev/console dans l'histoire ?


Pour info, si je fais un "cat /proc/14825/fd/1" dans le terminal B ( j'écoute l'entrée de A) et que je tape des caractères dans le terminal A, je devrais a priori voir les caractères dans le terminal B, non ? . Et bien le résultat, qui est hallucinant, c'est que ça se départage entre les 2 terminaux !! . Chacun m'en affiche un sur deux. C'est bizarre, non ?

http://hassansin.github.io/fun-with-unix-named-pipes

Oui, apparemment la lecture est "aléatoire". Lorsqu'il y a plusieurs processus qui lisent un fichier, on ne sait pas lequel des processus lira le caractère écrit dans le fichier.