Tempête sur Debian : les clés SSH compromises

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 !).