Murlock

Suite à mon petit utilitaire Yubikey, j’ai continué à approfondir l’interface proposée par Linux sur les périphériques entrée/sortie.

J’ai donc repris mon code pour capturer les événements d’un périphérique de type clavier. Comme on récupère ceux-ci directement du kernel, toute la phase de traduction côté userland n’est pas faite : les événements font référence à un clavier Américain. Le programme gère le support des touches spéciales ( Control, Alt, Shift, …) pour essayer de savoir si on a fait C ou Ctrl-C. Le code est disponible à l’adresse http://www.murlock.org/code/keylogger-0.1.tar.bz2

Bien sûr, je décline toute responsabilité pour toute utilisation frauduleuse de cet outil.

Pour lancer l’utilitaire (en tant que root), les logs sont disponible dans le fichier trace.log.

# keylogger path_to_dev_entry

Comment détecter l’outil ?

# lsof /dev/input/event1
 Output information may be incomplete.
COMMAND    PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
acpid     1615 root    4r   CHR  13,65      0t0 3043 /dev/input/event1
hald-addo 2290 root    4r   CHR  13,65      0t0 3043 /dev/input/event1
Xorg      2378 root   28u   CHR  13,65      0t0 3043 /dev/input/event1
keylogger 8338 root    3r   CHR  13,65      0t0 3043 /dev/input/event1

Exemple: avec changement d’onglet dans un Terminal et exemple de texte capturé

# ./keylogger /dev/input/event1 &
BusType : 17
Vendor  : 1
Product : 1
Version : 43841
Name : AT Translated Set 2 keyboard
Physical Location : isa0060/serio0/input0
# tail -f trace.log
Detected default keyboard layout :
XKBLAYOUT="fr"

<RIGHTCTRL=1><PAGEDOWN><RIGHTCTRL=0>ceci est un exe;ple de keylogger
<UP><HOME><DELETE><RIGHTSHIFT=1>c<RIGHTSHIFT=0>

Autre outil disponible : http://code.google.com/p/logkeys/

Pour ce premier post qui parle d’informatique, je vais vous presenter la YubiKey : c’est une cle d’authentification forte a base d’One-Time Password (ou mot de passe jetable), empechant les attaques par rejout. On peut utiliser cette cle avec une double authentification : le possesseur doit egalement saisir un autre mot de passe traditionnel, permettant une securite encore plus forte.

Malheureusement, il y a un defaut, cette cle est vu comme un peripherique de saisie standart ( HID ), ce qui ne cadrait pas avec mon utilisation de la cle : je voulais pouvoir modifier l’etat d’un service (le wifi ou surveillance video par exemple) sans avoir a ouvrir une session, ou dans le cas d’un routeur a base de firmware nihiliste extremiste libre, sans avoir a se connecter a une interface web).

Apres un peu de recherche, lors de l’insertion de la cle, grace a une regle udev, je lance mon programme :

ACTION=="add", SUBSYSTEM=="input", ATTRS{idVendor}=="1050", ATTRS{idProduct}=="0010", KERNEL=="event*", RUN+="/bin/yubico"

Je reclame ensuite le peripherique indique par la variable d’environnement DEVNAME:

fd = open( getenv("DEVNAME"), O_RDONLY );

A ce stade, j’obtiens copie de tout les evenenements claviers de la cle, mais cette derniere reste attache a l’entree standart du PC. Il faut alors reclamer le peripherique (un plongeon dans /usr/include/linux/input.h a ete necessaire).

ioctl( fd, EVIOCGRAB, 1 );

A ce stade, il suffit d’attendre une structure input_event (toujours le meme fichier input.h ainsi que Documentation/input/input.h). Une gestion de tampon et de timeout et me voila pret a verifier l’OTP.

A ce stade, j’ai joue la solution de facilite et j’attaque le WebService de Yubico pour verifier la cle OTP fourni par la cle. J’ai prevu trois hooks : en cas de succes, en cas d’echec et lorsque la cle est retire, le programme quitte automatiquement.

La suite du travail se passera sur une Alix PC-Engines avec OpenWRT pour verifier si tout marche correctement avec mdev, le remplacement d’udev fourni par BusyBox. Il reste aussi plusieurs bricoles comme indique dans l’archive.

Le progamme est telechargeable a http://www.murlock.org/utils/yubikey.tar.bz2. Ma machine, un Aspire One, tourne sur une Debian (mi testing / mi stable) avec le noyau 2.6.32.

PS: ce billet est entierement realise sur un clavier qwerty, donc pas d’accent dans un premier temps.

Dans certains cas (déplacement professionnel, réseau peu sûr/partiellement bloqué, ou tout simplement confidentialité pour la navigation), je désire protéger ma navigation.

Il est possible d’utiliser une connexion SSH pour se connecter une machine distante et de s’en servir comme relais via OpenVPN.

Préparons d’abord notre serveur (testé sur Debian) :

En premier, notre serveur VPN avec le fichier de configuration script d’init ( /etc/openvpn-server.conf par exemple )
remote localhost
dev tun
ping 30
ifconfig 192.168.5.1 192.168.5.2
proto tcp-server
port 6124
On lance le daemon avec sudo openvpn --conf /etc/openvpn-server.conf

Puis le proxy ( squid 3 dans mon cas)

Il faut juste ajouter dans les règles acl l’ip du client (192.168.5.2), rechercher la chaine acl localhost src 127.0.0.1/32 & insérer à la suite :
acl localhost src 192.168.5.2

Un petit /etc/init.d/squid3 restart pour prendre en compte les modifications.

Depuis notre portable / poste de travail, on se connecte à notre serveur  :

ssh -L 6124:localhost:6124 utilisateur@monserveur

(L’option -L 6124:localhost:6124 permet que le port 6124 en écoute qui se trouve sur le serveur sera également en écoute sur l’interface localhost:6124 sur la machine cliente)

Lançons maintenant la connexion VPN qui passera via le tunnel SSH

openvpn --config /etc/openvpn-client.conf

Contenu du fichier openvpn-client.conf
remote localhost
dev tun
ping 30
ifconfig 192.168.5.2 192.168.5.1
proto tcp-client
port 6124

Si tout va bien, on devrait voir pousser une nouvelle interface réseau (tun0 dans la plupart des cas).

Ensuite, dans notre navigateur, on paramètre le proxy sur HTTP / IP: 192.168.5.1 / port: 3128.

Dans la plupart des cas, je paramètre une nouvelle session de navigateur utilisant le proxy, me permettant de ‘choisir’ où va sortir le traffic.