Attaquer ssh avec ssh-agent.

Le post de blog précédent citait un commentaire de Ted Tso: Note that if your laptop allows incoming ssh connections, and you logged into master.kernel.org with ssh forwarding enabled, your laptop may not be safe. Ce post va expliquer ce risque de sécurité.

1/Rappels
ssh permet de se connecter à une machine distante en s'authantifiant de différentes manières, notamment via une paire de clés RSA. Ces clés peuvent être protégées (et c'est conseillé) par un mot de passe.
ssh-agent permet de conserver l'accès à ces clés une fois le mot de passe donné une première fois. ssh-agent permet aussi de faire suivre l'accès aux clés entre différentes machines. Ex: je me logge depuis 'host' sur A, puis sur B, le serveur sshd de B peut demander la clé sur host à l'aide de l'agent.

2/Usages
Généralement, on lance ssh-agent, puis on ajoute les clés nécessaires à l'aide de ssh-add. Une session s'affiche donc généralement:

iMac:~ test3$ ssh-agent
SSH_AUTH_SOCK=/tmp/ssh-xLT5wqNT0G/agent.720; export SSH_AUTH_SOCK;
SSH_AGENT_PID=721; export SSH_AGENT_PID;
echo Agent pid 721;
iMac:~ test3$ ssh-add
Identity added: /Users/test3/.ssh/id_rsa (/Users/test3/.ssh/id_rsa)
iMac:~ test3$

Puis la connexion est faite sur une machine distante, la connexion se fait sans mot de passe grâce à l'échange de clés RSA:

iMac:~ test3$ ssh -A kevin@192.168.1.99
Last login: Sat Oct  4 11:52:03 2011 from macos
Linux 2.6.37.6.
kevin@slackware:~$ env | grep SSH
SSH_CLIENT=192.168.1.5 50840 822
SSH_TTY=/dev/pts/3
SSH_AUTH_SOCK=/tmp/ssh-GOTNp27472/agent.27472
SSH_CONNECTION=192.168.1.5 50840 192.168.1.99 822
Et l'agent est accessible via une socket dans /tmp. Ce qui signifie que tout accès à cette socket donne accès à l'agent. Cette socket est protégée via des droits Unix:

kevin@slackware:~$ ls -la /tmp/ssh-GOTNp27472/
total 8
drwx------  2 kevin users 4096 oct.   4 14:27 ./
drwxrwxrwt 10 root  root  4096 oct.   4 14:27 ../
srwxr-xr-x  1 kevin users    0 oct.   4 14:27 agent.27472=
kevin@slackwall:~

3/ Conditions d'exploitation
Il est connu que root accède à tous les fichiers indépendamment des droits Unix, il a donc accès à la socket, et donc accès aux clés via l'agent:

root@slackware:~# export SSH_AUTH_SOCK=/tmp/ssh-sXrpwak27467/agent.27467
root@slackware:~# ssh-add -l
2048 a3:06:99:bc:e3:0d:7e:f4:e9:48:07:55:fd:ee:1b:be /Users/test3/.ssh/id_rsa (RSA)
root@slackwall:~#

Ceci devrait être bénin comme conséquence. La clé privée accessible sert à l'utilisateur test3 pour se connecter sur une machine distante. Mais, et c'est bien là ou se situe le noeud du problème, des utilisateurs choisissent expressément cette clé également comme clé de connexion personnelle! i.e. l'utilisateur test3 emploie la clé /Users/test3/.ssh/id_rsa.pub dans /Users/test3/.ssh/authorized_keys

Et là, c'est le drame, il devient dès lors possible pour root de se connecter sur la machine:

root@slackware:~# ssh -l test3 macos
Last login: Sat Oct  4 13:53:46 2011
iMac:~ test3$

Le client ssh se connecte sur macos, une demande d'échange de clé est faite; cette demande remonte à l'agent qui donne la liste de clés présente (id_rsa), qui correspond avec l'une du fichier authorized_keys : connexion établie. Et le root malveillant de la machine slackware a pu se connecter sur la machine macos via l'identité de test3.

4/ Remédiations
Le problème de ce setup provient de l'usage fait par cette clé. Elle sert aussi bien à se connecter sur une machine distante que sur la machine locale. Dit d'une autre manière, cela reviendrait à n'utiliser qu'un unique mot de passe entre une machine distante et une machine locale.
La solution consiste donc à utiliser plusieurs clés. La clé permettant de se connecter à slackware ne doit permettre de ne se connecter qu'à slackware. Une autre clé doit être générée via ssh-keygen pour se connecter sur macos. Ainsi, même si root accède à la socket de ssh, il n'aura pas l'autorisation pour se logger, l'agent n'ayant pas la bonne clé.
Il est également possible de ne pas utiliser l'agent (désactivé dans la configuration par défaut d'openssh) ou de ne pas utiliser de serveur sshd sur la machine locale comme proposé lors de la discussion sur la mainling-list.

J'en profite pour citer une autre partie de son message: "Yes, that's paranoia. With security, the question is always, "are you paranoid *enough*"?"