Recouvrement des clefs

Dans le bulletin d'alerte Debian 1571, l'équipe en charge de la sécurité a révélé une faiblesse du générateur de nombres aléatoires utilisé par OpenSSL sur les systèmes Debian et les distributions dérivées. Suite à cette faiblesse, certaines clefs de chiffrement sont beaucoup moins aléatoires qu'elles ne devraient, permettant à un attaquant de deviner la clef avec une attaque par force brute à partir d'un minimum de connaissance sur le système. Cela concerne en particulier l'utilisation des clefs de chiffrement dans OpenSSH, OpenVPN et les certificats SSL.

Cette page explique comment effectuer les procédures de recouvrement des clefs pour les paquets dont les clefs sont victimes de la vulnérabilité d'OpenSSL.

D'autres logiciels utilisent des clefs cryptographiques, mais ne sont pas vulnérables car OpenSSL n'est pas utilisé pour créer ou échanger leurs clefs.

Pour les instructions de recouvrement des clefs concernant d'autres logiciels, veuillez vous référer aux renseignements fournis par les utilisateurs sur https://wiki.debian.org/SSLkeys.

OpenSSH

Un paquet mis à jour a été publié avec la DSA-1576, facilitant la transformation de clef.

1. Installer les mises à jour de sécurité de DSA-1576

Une fois la mise à jour appliquée, les clés d'utilisateur faibles seront automatiquement rejetées lorsque c'est possible (elles ne peuvent pas toujours être détectées). Si vous utilisez de telles clés pour l'authentification des utilisateurs, elles arrêteront immédiatement de fonctionner et devront être remplacées (voir étape 3).

Les clés d'hôtes OpenSSH peuvent être régénérées automatiquement lors de l'application de la mise à jour de sécurité d'OpenSSH. La mise à jour demandera une confirmation avant cette étape.

2. Mise à jour des fichiers known_hosts d'OpenSSH

La régénération des clés d'hôte entraînera l'affichage d'un avertissement lors de la connexion au système avec SSH jusqu'à ce que la clé d'hôte soit mise à jour dans le fichier known_hosts sur le client. L'avertissement ressemble à ceci : 

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.

Dans ce cas, la clé d'hôte a simplement été modifiée, et vous devriez mettre à jour le fichier known_hosts correspondant comme indiqué dans le message d'avertissement. Il est recommandé d'utiliser un canal sécurisé pour échanger la clé du serveur. Elle se trouve dans le fichier /etc/ssh/ssh_host_rsa_key.pub sur le serveur ; son empreinte peut être affichée avec la commande suivante :

ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub

En plus des fichiers known_hosts des utilisateurs, il peut y avoir un fichier d'hôtes connus au niveau du système /etc/ssh/ssh_known_hosts. Ce fichier est utilisé à la fois par le client ssh et par sshd pour la fonctionnalité hosts.equiv. Ce fichier doit également être mis à jour.

3. Vérification de toutes les clés OpenSSH des utilisateurs

L'action la plus sûre est de régénérer toutes les clés OpenSSH des utilisateurs, sauf s'il peut être établi à un degré suffisamment élevé de certitude que la clé a été générée sur un système non affecté.

Vérifiez si votre clé a été affectée en lançant l'outil ssh-vulnkey inclus dans la mise à jour de sécurité. Par défaut, ssh-vulnkey vérifie les emplacements standards des clés d'utilisateur (~/.ssh/id_rsa, ~/.ssh/id_dsa et ~/.ssh/identity), vos fichiers authorized_keys (~/.ssh/authorized_keys et ~/.ssh/authorized_keys2), et les clés d'hôte du système (/etc/ssh/ssh_host_dsa_key et /etc/ssh/ssh_host_rsa_key).

Pour vérifier toutes vos clés, en supposant qu'elles sont situées aux emplacements standards (~/.ssh/id_rsa, ~/.ssh/id_dsa, ou ~/.ssh/identity) utilisez :

ssh-vulnkey

Pour vérifier toutes les clés du système :

sudo ssh-vulnkey -a

Pour vérifier une clé à un emplacement non standard :

ssh-vulnkey /chemin/vers/la/clé

Si ssh-vulnkey répond Unknown (no blacklist information), alors il n'y a pas d'information sur la vulnérabilité de vos clés. En cas de doute, détruisez la clé et générez en une nouvelle.

4. Régénérer les clés des utilisateurs affectées

Les clés OpenSSH utilisées pour l'authentification des utilisateurs doivent être régénérées manuellement, y compris celles qui ont été transférées sur d'autres systèmes après avoir été créées.

De nouvelles clés peuvent être générées avec ssh-keygen, par exemple : 

   $ ssh-keygen
   Generating public/private rsa key pair.
   Enter file in which to save the key (/home/utilisateur/.ssh/id_rsa):
   Enter passphrase (empty for no passphrase):
   Enter same passphrase again:
   Your identification has been saved in /home/utilisateur/.ssh/id_rsa.
   Your public key has been saved in /home/utilisateur/.ssh/id_rsa.pub.
   The key fingerprint is:
   00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 utilisateur@hote

5. Mise à jour des fichiers authorized_keys (si nécessaire)

Une fois les clés d'utilisateur régénérées, les clés publiques correspondantes doivent être propagées dans tous les fichiers authorized_keys (et authorized_keys2, si nécessaire) sur les systèmes distants. Assurez-vous de bien supprimer les clés concernées.

OpenSSL : instructions de création de clef PEM générique

Ce n'est qu'un rappel pour ceux qui (re-)créent les certificats encodés PEM. Suivant l'endroit où vous êtes, d'autres pratiques probablement en place sont à respecter sur la façon de gérer les clefs. De plus, il vous faudra sans doute obtenir la signature du certificat par une autorité de certification (CA) tierce plutôt qu'utiliser un certificat auto-signé comme ci dessous : 

cd /etc/ssl/private
openssl genrsa 1024 > monsite.pem
cd /etc/ssl/certs
openssl req -new -key ../private/monsite.pem -x509 -days 9999 -out monsite.pem

Binc IMAP

Le paquet bincimap crée automatiquement un certificat auto-signé avec la commande openssl pour le service bincimap-ssl, et le place dans /etc/ssl/certs/imapd.pem. Pour le recréer lancer : 

rm -f /etc/ssl/certs/imapd.pem
dpkg-reconfigure bincimap

Box Backup

Box Backup n'est pas présent dans Debian stable, seulement dans testing : Lenny.

Une première analyse de l'impact des clefs crées sur les systèmes avec un générateur de nombres pseudo-aléatoires (PRNG) utilisant un aléa insuffisant à été publié en amont.

Si le PRNG d'OpenSSL ne possédait pas un aléa suffisant, vous devez :

cryptsetup

Cryptsetup n'utilise pas lui-même OpenSSL pour le chiffrement (c'est valable à la fois pour les périphériques utilisant LUKS et ceux utilisant dm-crypt).

Si cryptsetup a été configuré pour utiliser des fichiers de clef chiffrés par SSL (un réglage personnalisé explicitement configuré par l'utilisateur) et qu'une version cassée d'OpenSSL à été utilisée pour créer le fichier de clef, le chiffrement du fichier de clef peut être plus faible que prévu (car le sel n'est pas vraiment aléatoire).

La solution est soit de re-chiffrer le fichier de clef (si vous estimez avec une confiance suffisante que la clef chiffrée n'a pas été révélée à un tiers) ou d'effacer et réinstaller les partitions concernées avec une nouvelle clef.

Instructions pour for re-chiffrer un fichier de clef.

Effectuer les opérations suivantes pour chaque fichier de clef chiffré par SSL, en remplaçant <chemin_vers_la_clef_chiffré_par_ssl> par le vrai chemin vers la clef : 

tmpclef=$(tempfile)
openssl enc -aes-256-cbc -d -salt -in <chemin_vers_la_clef_chiffré_par_ssl> -out "$tmpclef"
shred -uz <chemin_vers_la_clef_chiffré_par_ssl>
openssl enc -aes-256-cbc -e -salt -in "$tmpclef" -out <chemin_vers_la_clef_chiffré_par_ssl>
shred -uz "$tmpclef"

Dropbear

Si des clefs /etc/ssh/*host* existent, effacez-les ou suivez d'abord les instructions OpenSSH avant de mettre à jour les clefs de Dropbear.

Le script de post-installation convertit les clefs OpenSSH existantes au format Dropbear, s'il ne peut pas trouver les clefs d'hôte de Dropbear. 

rm /etc/dropbear/*_host_key
dpkg-reconfigure dropbear

Remarquez que les clefs crées par Dropbear lui-même ne sont pas vulnérables (il utilise libtomcrypt plutôt qu'OpenSSL).

EKG

Les utilisateurs des programmes EKG ou EKG2 (le second n'est disponible que dans experimental) qui utilisent la fonctionnalité de chiffrement SIM, et qui ont créé une paire de clefs avec la commande /key [-g|--generate] (qui utilise libssl pour ce faire), devraient recréer leurs clefs, après avoir mis à niveau libssl et redémarré le programme.

Les développeurs amont ont publié une annonce sur leur site.

Pour obtenir de l'aide, veuillez vous adresser à ekg-users@lists.ziew.org ou ekg2-users@lists.ziew.org (en anglais ou en polonais).

ftpd-ssl

rm -f /etc/ftpd-ssl/ftpd.pem /etc/ssl/certs/ftpd.pem
dpkg-reconfigure ftpd-ssl

C'est suffisant pour la configuration par défaut. Si l'administrateur local a paramétré l'infrastructure SSL au-delà, ces clefs devront aussi être recrées.

GForge

Le paquet gforge-web-apache2 de Sid et Lenny configure le site web avec un certificat factice si aucun certificat existant n'est trouvé. Les utilisateurs sont alors encouragés à le remplacer par un vrai. Le certificat factice en question est le Snake Oil, il devrait donc être considéré faible (même sans le bogue SSL), mais certains utilisateurs risquent de l'avoir accepté les yeux fermés.

MIT Kerberos (krb5)

Aucune partie de MIT Kerberos de Debian 4.0 (Etch) n'utilise OpenSSL, aini Kerberos n'est pas concerné du tout dans Debian 4.0.

Dans Lenny, le paquet binaire krb5-pkinit utilise OpenSSL. MIT Kerberos ne crée pas lui même de paires de clefs durables quand le greffon PKINIT est utilisé, donc toutes les paires de clefs durables auront été crées en dehors du programme MIT Kerberos lui-même. Le greffon PKINIT ne fait référence qu'aux paires de clefs existantes, et n'est pas responsable de la gestion des clefs.

Les paires de clefs durables utilisé avec PKINIT risquent d'être concernées si elles ont étés créés sur un système Debian concerné, mais de telles créations sont extérieures à MIT Kerberos.

Cependant, les fonctions de clef aléatoires OpenSSL sont utilisées pour l'échange DH lorsque l'authentification PKINIT est utilisée, ce qui signifie qu'un attaquant pourrait accéder par force brute à la réponse du centre de distribution de clés (KDC) d'une authentification PKINIT et par conséquent accéder à n'importe quelle session créée avec les tickets de service de cette authentification.

Toute KDC utilisant le greffon PKINIT de Lenny devraient avoir leur paquet libssl0.9.8 immédiatement mis à niveau et le KDC de Kerberos redémarré avec : 

/etc/init.d/krb5-kdc restart

Tous les tickets du service d'émission de tickets (TGT) de Kerberos et les sessions résultants d'une authentification PKINIT utilisant un KDC de Kerberos avec la libssl affectée doivent être considérés suspects ; un attaquant ayant capturé des paquets pourrait compromettre ces clefs et ces sessions.

Nessus

Le script de post-installation du paquet nessusd (serveur Nessus ) crée quelques clefs SSL pour les échanges sécurisés entre un serveur et un client Nessus. Ce canal de de communication doit être considéré compromis puisqu'un utilisateur malintentionné a pu intercepter les renseignements échangés entre le serveur et le client (parmi lesquels des renseignements sur les vulnérabilités de l'hôte distant) et pourrait envoyer des commandes aux serveurs en se faisant passer pour l'utilisateur connecté.

De plus, si l'administrateur a créé la clef de CA de Nessus ou un certificat utilisateur (avec nessus-mkcert-client) pour les authentifications distantes sur un serveur utilisant une version d'OpenSSL concernée par le problème de sécurité, ces clef devraient être considérées comme compromises. Remarquez que les utilisateurs distants ayant accès au serveurs Nessus peuvent lancer des attaques sur les serveurs où ils sont autorisés pour attaquer et, si activé sur la configuration locale (ce n'est pas le réglage par défaut sur Debian), ajouter des greffons qui seront exécutés sur le serveur Nessus avec le privilèges du superutilisateur.

Les scripts de configuration du responsable recréeront les certificats OpenSSL lors de la configuration s'il ne sont pas trouvés. Vous devrez supprimer les certificats et en recréer de nouveaux avec : 

rm -f /var/lib/nessus/CA/cacert.pem
rm -f /var/lib/nessus/CA/servercert.pem
rm -f /var/lib/nessus/private/CA/cakey.pem
rm -f /var/lib/nessus/private/CA/serverkey.pem
dpkg-reconfigure nessusd

Ensuite, il faudra supprimer les anciennes clefs d'utilisateur en /var/lib/nessus/users/NOMDUTILISATEUR/auth et les recréer de nouveau avec nessus-mkcert-client. Les anciennes clés ne seront plus valable une fois que la clef de CA aura été supprimée.

Après avoir recréé la clef de CA, il faudra aussi distribuer le nouveau certificat de CA aux utilisateurs, et ils devront accepter le nouveau certificat du serveur Nessus quand ils se reconnecteront. Les configurations du certificat de l'ancien serveur devraient être retirées automatiquement mais vous pouvez les enlever vous-même en modifiant .nessusrc.cert (si le client Nessus est utilisé) ou .openvasrc.cert (si le client OpenVAS est utilisé).

OpenSWAN et StrongSWAN

rm /etc/ipsec.d/private/`nomdhote`Key.pem /etc/ipsec.d/certs/`nomdhote`Cert.pem
dpkg-reconfigure (open|strong)swan
/etc/init.d/ipsec restart

Attention : le redémarrage de services ipsec termine toutes les connexions IPSec actuellement ouvertes, elles risquent donc de devoir être redémarrées de l'autre côté.

OpenVPN

Sauvegarder les fichiers de clef secrète. Même si les noms de clef sont arbitraires, ils peuvent être trouver avec : 

grep secret /etc/openvpn/*.conf

Recréer les avec : 

openvpn --genkey --secret NOM_DE_FICHIER_SECRET

Ensuite, copier clefs secrètes partagées sur les hôtes distants et redémarrer le VPN sur chaque hôte avec : 

/etc/init.d/openvpn force-reload

ProFTPD

le paquet Debian ne s'occupe pas de la création de clefs, donc les étapes suivantes ne sont nécessaires sur si les clefs SSJ ont été créées par ailleurs.

Une mise à niveau de ProFTPD vers unstable contiendra un modèle de tls.conf avec les commentaires ci dessous.

Note that the self-signed certificate generation is bit different from that suggested on the general openssl section, in order to avoid using of an explicit password at daemon startup.

Vous pouvez recréer un un certificat auto-signé avec une commande du style : 

 openssl req -x509 -newkey rsa:1024 -keyout /etc/ssl/private/proftpd.key -out /etc/ssl/certs/proftpd.crt -nodes -days 365

Les deux fichiers ne doivent être accessibles en lecture que pour le superutilisateur. Les chemins de fichier peuvent être vérifiés et configurés en utilisant les directives de configuration suivantes : 

TLSRSACertificateFile                   /etc/ssl/certs/proftpd.crt
TLSRSACertificateKeyFile                /etc/ssl/private/proftpd.key
TLSCACertificateFile                    /etc/ssl/certs/CA.pem
TLSOptions                              NoCertRequest

Puppet

vous pouvez gérer les certificats de Puppet vous-même ou avec Capistrano.

Vous pouvez suivre lesinstructions pour recréer les certificats SSL de Puppet avec Capistrano.

Si vous préférez procéder par vous-même, suivez le détail des étapes.

  1. Supprimer puis recréer les renseignements de CA : 
    /etc/init.d/puppetmaster stop
rm -rf $vardir/ssl/*
/etc/init.d/puppetmaster start

    Cependant, si vous utilisez mongrel, plutôt que de démarrer puppetmaster depuis le script d'initialisation, vous devrez d'abord arrêter l'interface web à l'écoute (Apache, nginx, etc.) puis exécutez ceci : 

    puppetmasterd --daemonize ; sleep 30 ; pkill -f 'ruby /usr/sbin/puppetmasterd'

    Ce qui précède est nécessaire sinon, lors du fonctionnement avec mongrel, puppetmaster ne recréera pas ses CA.

  2. Supprimer tous les certificats clients : 
    /etc/init.d/puppet stop
rm $vardir/ssl/*
  3. Obliger tous les clients à demander un nouveau certificat : 
    puppetd --onetime --debug --ignorecache --no-daemonize
  4. Une fois toutes les requêtes arrivées, vous pouvez toutes les signer en une fois : 
    puppetca --sign --all
  5. Démarrer les clients puppet : 
    /etc/init.d/puppet start

Si ça vous convient, vous pouvez également activer temporairement l'autosignature.

sendmail

Sendmail (à la fois dans Etch et Lenny) crée de façon optionnelle des certificats OpenSSL par défaut lors de l'installation.

La procédure de recouvrement des clef est triviale : 

/usr/share/sendmail/update_tls new

Si vous avez personnalisé les modèles de /etc/mail/tls, ces valeurs seront réutilisées pour créer les nouveaux certificats.

ssl-cert

Le certificat Snake Oil /etc/ssl/certs/ssl-cert-snakeoil.pem peut être recréé avec : 

make-ssl-cert generate-default-snakeoil --force-overwrite

telnetd-ssl

rm -f /etc/telnetd-ssl/telnetd.pem /etc/ssl/certs/telnetd.pem
dpkg-reconfigure telnetd-ssl

C'est suffisant pour la configuration par défaut. Si l'administrateur local a configuré plus profondément l'infrastructure SSL, ces clefs devront être recrées également.

tinc

Supprimer tous les fichiers de clefs privées et publiques suspects :

  1. supprimer rsa_key.priv ;
  2. modifier tous les fichiers du répertoire hosts/ et supprimer les blocs de clefs publiques.

Créer une nouvelle paire de clefs public et privée : 

tincd -n <netname> -K

Échanger le fichier de configuration de l'hôte avec la nouvelle clef publique avec les autres membres du VPN. Ne pas oublier de redémarrer les autres démons tinc.

Tor

Tor n'est pas dans stable, mais concerné dans Lenny.

Les clients en version 0.1.2.x ne sont pas concernés. Les nœuds Tor ou les fournisseurs de services cachés de toute version, ainsi que tout le monde en version 0.2.0.x est concerné.

Veuillez lire l'annonce de vulnérabilité sur la liste de diffusion d'annonces Tor.

Mettre à niveau vers la version 0.1.2.19-3 (disponible dans testing, unstable, backports.org et l'habituel dépôt noreply.org) ou 0.2.0.26-rc-1 (disponible dans experimental et l'habituel dépôt noreply.org) est recommandé. Si vous exécutez un relais, ces versions obligeront à recréer de nouvelles clefs serveur (/var/lib/tor/keys/secret_*).

Si vous exécutez un nœud Tor sans utiliser l'infrastructure du paquet (utilisateur de debian-tor, DataDirectory configuré en /var/lib/tor, etc.), vous devez supprimer vous-même les mauvaises clefs. Voir l'annonce de vulnérabilité dont le lien est ci-dessus.

Si vous êtes un fournisseur de service caché, et avez créé la clef pendant la période concernée avec une mauvaise libssl, veuillez effacer la clef privée du service caché. Le nom d'hôte du service caché sera modifié et vos serveurs risquent de devoir être reconfigurés.

Si vous utilisez une version 0.2.0.x, une mise à niveau est sérieusement recommandée — la moitié des six serveurs d'autorité v3 ont des clefs compromises. Les anciennes versions 0.2.0.x ne fonctionneront plus d'ici une semaine ou deux.

xrdp

xrdp utilise des clefs crées. La plupart des client ne vérifient pas ces clefs par défaut, par conséquent les changer est sans grande conséquences. Il suffit de faire : 

rm /etc/xrdp/rsakeys.ini
/etc/init.d/xrdp restart

xrdp n'est pas dans stable.