Une faiblesse dans la création des clés OpenSSH sur les serveurs Linux Debian expose de très nombreux serveurs aux pirates. Il leur suffit en effet de vingt minutes pour casser les clés SSH et prendre possession d’une machine aux sésames vulnérables. La vulnérabilité est, bien entendu, désormais largement exploitée sur Internet.

Administrateurs, si vous exploitez des serveurs Linux Debian accessibles par SSH, votre week-end risque d’être compromis. C’est ça, ou vos serveurs le seront probablement.

Les clés générées par la version Debian d’OpenSSL depuis ces deux dernières années doivent en effet être considérées comme compromises et être changées. Vous hésitez encore ? « Nous avons testé cette attaque. Le temps le plus long pour casser une clé RSA de 2048 bits sur un système vulnérable a été de vingt minutes », prévient Nicolas Collignon, consultant sécurité pour le cabinet d’audit HSC.

Et pour cause : fragilisées par une faiblesse du générateur de nombres aléatoires de l’OpenSSL Debian, les paires de clés RSA de 2048 bits présentent en réalité une robustesse équivalente à… 16 bits ! Et OpenSSL servant à la création de clés utilisées par de nombreux outils de sécurité, dont OpenSSH (mais aussi OpenVPN, Cyrus imap, Courier imap, Dovecot, etc…), la vulnérabilité affecte ainsi tous les sésames générés sur un serveur Debian et sur toute autre distribution qui s’en inspire (Ubuntu ou Xandros par exemple). Selon les premiers observateurs, il pourrait s’agir de la plus importante vulnérabilité qu’ait connu le projet Debian depuis sa création.

Il faut cependant insister sur le fait que seule la version Debian

d’OpenSSL (source ou package) est vulnérable. Les administrateurs qui

ont pris soin de compiler à partir des sources officielles ne sont pas concernés. En revanche, les clés générées sur Debian et utilisées sur d’autres systèmes seront faillibles.

Une vulnérabilité ancienne et silencieuse

L’importance de cette faille pour Debian se mesure à la liberté qu’elle offre aux pirates : elle permet de retrouver une clé privée à

partir de sa clé publique ou de l’empreinte (le fingerprint)

qu’annonce le serveur. Et pour ajouter au désespoir des administrateurs, son exploitation est silencieuse. « A moins

d’avoir activé le niveau de journalisation d’OpenSSH sur DEBUG, cette

attaque ne laisse aucune trace dans les journaux », prévient Nicolas

Collignon. 

Plus inquiétant encore, le trou est loin d’être récent. Il a été introduit en 2006, date à laquelle un responsable de package Debian a désactivé quelques lignes de code afin de s’éviter des avertissements lors de la compilation d’OpenSSL après avoir corrigé des alertes remontées par un outil automatique d’analyse du code. Mais sa modification, pourtant approuvée, ruinait l’efficacité du générateur de nombres aléatoires, avec les conséquences que l’on connaît.

Il est difficile de dire si cette vulnérabilité a été exploitée durant ses deux ans d’existence. Cependant, à l’occasion d’une série de détournements de serveurs britanniques en début d’année (qui se produisaient à nouveau même une fois les serveurs nettoyés et réinstallés), les experts avaient émis l’hypothèse du vol des clés SSH chez l’hébergeur des victimes. Il serait probablement intéressant de revenir aujourd’hui sur cette affaire afin de vérifier si les serveurs ne sont pas tous sous Linux Debian. Il s’agit, quoi qu’il en soit, de la vulnérabilité rêvée pour tout pirate, et si elle était connue elle devait se monnayer à prix d’or dans un cercle très restreint. Voire, être invendable.

Que faire ? Le guide de survie de l’administrateur Debian

Bien qu’un correctif soit disponible, patcher ne suffira pas : toutes les clés générées sur un système Debian vulnérable doivent l’être à nouveau. Le processus de remédiation conseillé est le suivant :

     Mettre à jour OpenSSL. Soit à partir du package Debian corrigé, soit à partir des sources officielles.

     Attention : une fois OpenSSL mis à jour via Debian (pas depuis

     les sources officielles), le serveur refusera la connexion aux clients munis de paires

     de clés vulnérables (postes de travail sous Ubuntu, autres serveurs Debian, etc..). Il est alors prudent de ne pas se déconnecter, au risque de rester coincé dehors !

     Re-générer la paire de clés du serveur (cela se fera automatiquement si vous utilisez la solution Debian).

     Une fois les clés du serveur mises à jour, il est nécessaire de mettre à jour le fichier « known_hosts » (à défaut les clients auront au mieux un avertissement à la connexion et au pire ils ne pourront se connecter, en fonction de la configuration de SSH).

     Vérifier les paires de clés des utilisateurs afin de déterminer si elles sont vulnérables (celles générées sur ce serveur le seront). Pour faciliter la vérification, Debian a publié un script ad-hoc, capable de contrôler les clés du serveur ou des utilisateurs.

     Re-générer les paires de clés des utilisateurs lorsqu’elles sont vulnérables.

Et pour les malheureux (inconscients) qui auraient déployés une PKI avec un certificat racine généré sous Linux Debian, il sera bien entendu nécessaire de révoquer tous les certificats. Heureusement, les gens sérieux utilisent des boîtiers de génération de clés dédiés pour ce genre de choses, dotés de générateurs de nombres aléatoires particulièrement performants (et onéreux…).

Cette procédure ne fera probablement pas plaisir aux nombreux responsables de serveurs Debian, surtout à la veille d’un week-end. Mais l’urgence est réelle. « Cette vulnérabilité est activement exploitée, et c’est une hécatombe », confirme Nicolas Collignon. Il semblerait que les pirates aient d’ailleurs pris un peu d’avance : peu avant que la faille ne soit rendue publique le SANS Institute s’inquiétait de la recrudescence des scans sur le port 22, alloué à SSH. Depuis, l’organisme a élevé son niveau d’alerte global.

Il est impossible d’estimer le nombre de serveurs compromis de la sorte à l’heure actuelle; mais le bilan sera nécessairement lourd et, surtout, il ne sera pas bouclé avant longtemps. Des vulnérabilités beaucoup moins contraignantes à corriger que celle-ci sont toujours exploitables, notamment sur les serveurs gérés par des « administrateurs du dimanche », dont la connaissance de Linux se limite à payer un serveur dédié d’entrée de gamme pour y héberger un forum ou un serveur privé de jeu en ligne. Espérons que dans leur méconnaissance de l’outil ils n’aient su configurer les connexions SSH par certificats et s’en soient tenus aux bons vieux mots de passe (et bien choisis de préférence !).