Vérifier rapidement la vulnérabilité de sa clef SSH Debian

Comme vous le savez sans doute une faille majeure a été trouvée dans l’implémentation SSL présente dans les distribution Debian et dérivée. Cette faille est présente dans les distributions depuis environ deux ans et concerne le générateur de nombres pseudo-aléatoire (PRNG), réduisant ainsi l’espace de clef de manière catastrophique.

Vous trouverez sur http://metasploit.com/users/hdm/tools/debian-openssl/ deux archives contenant tout l’espace de clef. Pour savoir si votre clef est dans le lot c’est très simple. Désarchivez l’une ou l’autre des archives (selon le type et la taille de clef). Les paires de clefs sont stockées dans des fichiers nommés en utilisant l’empreinte de la clef publique.

Vous pouvez donc récupérer l’empreinte de votre clef avec:
% ssh-keygen -l -f id_dsa | cut -d  »  » -f 2 | sed « s/://g »
f9040774bddfdfed7c2fccdfac60ad26
Regardez ensuite si un fichier est présent dans le répertoire contenant l’espace de clef avec un simple ls. Si c’est le cas, vous êtes mal. Un attaquant n’aura qu’à essayer tout l’espace de clef et finira par avoir un accès à un moment ou un autre (selon le nombre de tentatives infructueuses autorisées pour une adresse, directive MaxAuthTries dans sshd_config). Mais ce n’est qu’une question de temps.

OpenSSH 5.0 chrooté (façon gruik)

OpenSSH 5.0 vient d’être mis à disposition et intègre (mais ce n’est pas une nouveauté cette version) la directive ChrootDirectory permettant de chrooter dans un répertoire après la connexion. Cette fonctionnalité est principalement utilisée pour du SFTP mais on peu parfaitement configurer l’ensemble pour les logins SSH.

Méthode goret/vite’fait…

La version 5.0 n’existe pas dans les Debian à l’heure d’aujourd’hui. On récupère donc la version portable d’OpenSSH 5.0 :

ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-5.0p1.tar.gz

On désarchive et on récupère également les dernières sources Debian :
% cd /tmp
% mkdir SS
% cd SS
% apt-get source ssh
% cd ..
% wget ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-5.0p1.tar.gz
% tar xfzv openssh-5.0p1.tar.gz
£ cd openssh-5.0p1
% cp -r ../SS/openssh-4.7p1/debian .
Il ne faut pas oublier de récupérer les dépendances de compilation avec un petit apt-get build-dep ssh.

On copie ensuite le répertoire debian des sources 4.7 Debian dans les sources de la 5.0p1. Pour compiler, il faut supprimer les manpage du debian/rules. On tripote également le changelog puisque la version du paquet vient de là. On ajoute en haut du fichier :
openssh (1:5.0p1-0) unstable; urgency=low

* Major version

— Denis Bodor <lefinnois@lefinnois.net> Thu, 3 Apr 2008 21:21:05 +0200
Et puis on construit le paquet avec dpkg-buildpackage -b -rfakeroot.

Installation dans la KVM de test avec dpkg -i. Maintenant on peut s’amuser un peu. Et on commence par modifier le fichier de configuration du démon sshd (/etc/ssh/sshd_config) en ajoutant :
Match user lefinnois
ChrootDirectory /var/JAIL_%u
Pour l’utilisateur lefinnois on chroot dans /var/JAIL_lefinnois (%u est développé en lefinnois lors de la connexion).

Il nous faut construire l’environnement chrooté. Là, je vous préviens c’est très gruika…
# la base
% cd /var
% mkdir /var/JAIL_lefinnois
% cd JAIL_lefinnois
% mkdir -p bin usr/bin usr/lib usr/bin home/lefinnois dev etc
% chown -R lefinnois.lefinnois home/lefinnois

# les dev (pour scp par exemple)
% cd dev
% MAKEDEV std
% cd ..

# les libs
% cp -rv /lib .
% cp -rv /usr/lib usr
% cp /bin/ls /bin/mkdir /bin/mv /bin/pwd /bin/rm /bin/sh /bin/echo /bin/cp
/bin/cat /bin/ln /bin/chown /bin/chmod /bin/grep /bin/more /bin/tar
/bin/gzip /bin/true /bin/false /bin/ping /bin/egrep /bin/hostname
bin

# plus mieux pour les ls
% cp /etc/passwd /etc/group etc

# un peu de scp
% cp /usr/bin/scp usr/bin

# et surtout un shell (static pas obligé, on a les libs)
% aptitude install bash-static
% cp /bin//bin/bash-static bin/bash
Ouais, ça fait une tonne le libs (55Mo pour lib et 139 pour usr/lib). Faut faire le tri. Mais en tout ça fait que ~200Mo pour le chroot.

Résultat, depuis la machine hôte vers la KVM :
% ssh lefinnois@192.168.0.200
lefinnois@192.168.0.200’s password: XXXXXXXXXX
Linux VMdebian1 2.6.18-5-686 #1 SMP Wed Oct 3 00:12:50 UTC 2007 i686
Last login: Sat Apr 5 12:31:56 2008 from 192.168.0.1

[10:46:27] lefinnois@VMdebian1:~ % ls -la
total 16
drwxr-xr-x 2 lefinnois lefinnois 4096 2008-04-05 10:31 .
drwxr-xr-x 3 root root 4096 2008-04-05 10:15 ..
-rw——- 1 lefinnois lefinnois 279 2008-04-05 10:32 .bash_history
-rw-r–r– 1 lefinnois lefinnois 30 2008-04-05 10:24 .bash_profile

[10:46:29] lefinnois@VMdebian1:~ % ls -la /
total 32
drwxr-xr-x 8 root root 4096 2008-04-05 10:30 .
drwxr-xr-x 8 root root 4096 2008-04-05 10:30 ..
drwxr-xr-x 2 root root 4096 2008-04-05 10:20 bin
drwxr-xr-x 2 root root 4096 2008-04-05 10:31 dev
drwxr-xr-x 2 root root 4096 2008-04-05 10:21 etc
drwxr-xr-x 3 root root 4096 2008-04-05 10:15 home
drwxr-xr-x 12 root root 4096 2008-04-05 10:18 lib
drwxr-xr-x 4 root root 4096 2008-04-05 10:29 usr
Chrooted !!!!

Note : la construction de l’environnement chrooté est brouillon. Pour faire quelque chose de propre il faut se tourner vers des outils spécialisés ou développer son propre script Perl (dépendances des libs, etc). Pas le temps sur le coup…

Rendre disponible un tunnel SSH

Tout le monde connaiît OpenSSH (non ? Tant pis) et les possibilités de création de tunnel. Très pratique pour sécuriser (chiffrer) des protocoles trop bavards (HTTP; FTP, POP3, etc), il est possible de tunneliser presque n’importe quoi depuis le client SSH et le serveur (et inversement). Plus rarement utilisé, il est aussi possible de partager le tunnel du client sur le réseau.

L’idée de base est depuis la machine A d’accéder au serveur HTTP sur la machine B mais sans laisser circuler plein de HTTP en clair dans les tuyaux. On utilise donc sur la machine A :
% ssh -L 8000:localhost:80 machineb
Dès lors, sur la machine B on peut accéder au serveur HTTP de B avec l’adresse http://localhost:8000/. OpenSSH se charge comme un grand de chiffrer tout ça et de l’enfoncer joyeusement dans le tunnel.

Pour faire plus simple on peut ajouter dans son ~/.ssh/config :
Host montunnelhttp
Hostname machineb
Port 22
Compression yes
CompressionLevel 6
LocalForward 8000 127.0.0.1:80
et ensuite utiliser simplement
% ssh montunnelhttp
Seulement voilà. Le point d’entrée du tunnel est localhost:8000 sur A. Si l’on veut, par exemple, vérifier que son application Web ressemble vaguement à quelque chose avec un navigateur du mal sous un OS du mal, on se retrouve coincé. « Bin, je sors mon iptables de la mort et de forwa… » NON ! OpenSSH a ce qu’il faut (idem pour le « j’installe Putty et…« . Moins je touche aux OS sales, moins je m’ennerve, mieux je me porte) :
% ssh -L mon_ip_sur_eth0:8000:localhost:80 machineb
On bind gentillement sur l’adresse de l’interface ethernet de la machine cliente. Du coup, OpenSSH écoute le port 8000 de l’interface en question. Depuis notre OS du mal, on utilise http://mon_ip_sur_eth0:8000, et rulez…

Côté ~/.ssh/config, on utilisera ceci :
Host montunnelhttp
Hostname machineb
Port 22
Compression yes
CompressionLevel 6
GatewayPorts yes
LocalForward 8000 127.0.0.1:80