Cette vulnérabilité a un impact potentiel élevé car, si votre système a été attaqué, il restera vulnérable même après avoir été corrigé et les attaques n'auront peut-être laissé aucune trace dans les journaux. Les chances que si vous corrigez rapidement et que vous ne soyez pas une cible de premier plan, personne n’aura réussi à vous attaquer, mais il est difficile d’en être sûr.
Suis-je vulnérable?
La version buggy d'OpenSSL
Le logiciel buggy est la bibliothèque OpenSSL 1.0.1 à 1.0.1f et OpenSSL 1.0.2 à beta1. Les versions plus anciennes (0.9.x, 1.0.0) et les versions où le bogue a été corrigé (versions 1.0.1g et 1.0.2 bêta 2 et ultérieures) ne sont pas affectées. Il s’agit d’un bogue d’implémentation et non d’une faille dans le protocole. Seuls les programmes utilisant la bibliothèque OpenSSL sont concernés.
Vous pouvez utiliser l'outil de ligne de commande openssl version -apour afficher le numéro de version d'OpenSSL. Notez que certaines distributions portent le correctif pour les versions précédentes; si le journal des modifications de votre paquet mentionne le correctif de bogue Heartbleed, c'est bien, même si vous voyez une version telle que 1.0.1f. Si vous openssl version -amentionnez une date de construction (et non la date sur la première ligne) du 2014-04-07 vers le soir UTC ou plus tard, tout devrait bien se passer. Notez que le paquet OpenSSL peut avoir 1.0.0son nom même si la version est 1.0.1 ( 1.0.0fait référence à la compatibilité binaire).
Applications concernées
L'exploitation est effectuée via une application qui utilise la bibliothèque OpenSSL pour implémenter des connexions SSL . De nombreuses applications utilisent OpenSSL pour d’autres services de chiffrement, et c’est bien: le bogue concerne l’implémentation d’une fonctionnalité particulière du protocole SSL, la «pulsation».
Vous voudrez peut-être vérifier quels programmes sont liés à la bibliothèque de votre système. Sur les systèmes qui utilisent dpkg et apt (Debian, Ubuntu, Mint,…), la commande suivante répertorie les packages installés autres que les bibliothèques qui utilisent libssl1.0.0(le package affecté):
apt-cache rdepends libssl1.0.0 | tail -n +3 |
xargs dpkg -l 2>/dev/null | grep '^ii' | grep -v '^ii lib'
Si vous exécutez un logiciel serveur figurant sur cette liste et qui écoute les connexions SSL, vous êtes probablement affecté. Cela concerne les serveurs Web, les serveurs de messagerie, les serveurs VPN, etc. Vous saurez que vous avez activé SSL parce que vous deviez générer un certificat, soit en soumettant une demande de signature de certificat à une autorité de certification, soit en créant votre propre convention auto-signée. Certificat. (Il est possible qu'une procédure d'installation ait généré un certificat auto-signé sans que vous le remarquiez, mais c'est généralement fait uniquement pour les serveurs internes, pas pour les serveurs exposés à Internet.) Si vous avez exécuté un serveur vulnérable exposé à Internet, considérez-le comme compromis. à moins que vos journaux n'indiquent aucune connexion depuis l'annonce du 2014-04-07. (Cela suppose que la vulnérabilité n'a pas été exploitée avant son annonce.) Si votre serveur a été exposé uniquement en interne,
Le logiciel client n'est affecté que si vous l'avez utilisé pour vous connecter à un serveur malveillant. Donc, si vous vous êtes connecté à votre fournisseur de messagerie à l'aide d'IMAPS, vous n'avez pas à vous inquiéter (sauf si le fournisseur a été attaqué - mais si c'est le cas, il devrait vous le faire savoir), mais si vous avez consulté des sites Web aléatoires avec un navigateur vulnérable, vous devrez peut-être s'inquiéter. Jusqu'à présent, il semble que la vulnérabilité n'ait pas été exploitée avant sa découverte. Vous n'avez donc qu'à vous inquiéter si vous vous êtes connecté à des serveurs malveillants depuis le 2014-04-08.
Les programmes suivants ne sont pas affectés car ils n'utilisent pas OpenSSL pour implémenter SSL:
- SSH (le protocole n'est pas SSL)
- Chrome / Chrome ( utilise NSS )
- Firefox (utilise NSS) (au moins avec Firefox 27 sur Ubuntu 12.04, mais pas avec toutes les versions?
Quel est l'impact?
Ce bogue permet à tout client pouvant se connecter à votre serveur SSL de récupérer environ 64 Ko de mémoire à la fois sur le serveur. Le client n'a pas besoin d'être authentifié de quelque manière que ce soit. En répétant l'attaque, le client peut vider différentes parties de la mémoire lors de tentatives successives. Cela permet potentiellement à l'attaquant de récupérer toutes les données qui se trouvaient dans la mémoire du processus du serveur, y compris les clés, les mots de passe, les cookies, etc.
L'une des données critiques que l'attaquant peut récupérer est la clé privée SSL du serveur. Avec ces données, l'attaquant peut emprunter l'identité de votre serveur.
Le bogue permet également à n'importe quel serveur auquel votre client SSL s'est connecté d'extraire environ 64 Ko de mémoire du client à la fois. Cela vous inquiète si vous avez utilisé un client vulnérable pour manipuler des données sensibles, puis que vous vous êtes connecté ultérieurement à un serveur non approuvé avec le même client. Les scénarios d'attaque de ce côté sont donc nettement moins probables que ceux du serveur.
Notez que pour les distributions types, la distribution des paquets n'a aucun impact sur la sécurité car l'intégrité des paquets repose sur les signatures GPG et non sur le transport SSL.
Comment corriger la vulnérabilité?
Remédiation des serveurs exposés
Mettez tous les serveurs affectés hors ligne. Tant qu'ils fonctionnent, ils risquent de laisser échapper des données critiques.
Mettez à niveau le package de bibliothèque OpenSSL . Toutes les distributions devraient déjà avoir un correctif (soit avec 1.0.1g, soit avec un correctif qui corrige le bogue sans changer le numéro de version). Si vous avez compilé à partir des sources, effectuez une mise à niveau vers la version 1.0.1g ou une version ultérieure. Assurez-vous que tous les serveurs affectés sont redémarrés.
Sous Linux, vous pouvez vérifier si les processus potentiellement affectés sont toujours en cours d'exécution avecgrep 'libssl.*(deleted)' /proc/*/maps
Générer de nouvelles clés . Cela est nécessaire car le bogue aurait peut-être permis à un attaquant d'obtenir l'ancienne clé privée. Suivez la même procédure que vous avez utilisée initialement.
- Si vous utilisez des certificats signés par une autorité de certification, soumettez vos nouvelles clés publiques à votre autorité de certification. Lorsque vous obtenez le nouveau certificat, installez-le sur votre serveur.
- Si vous utilisez des certificats auto-signés, installez-le sur votre serveur.
- Quoi qu'il en soit, déplacez les anciennes clés et certificats hors de portée (mais ne les supprimez pas, assurez-vous simplement qu'ils ne sont plus utilisés).
Maintenant que vous avez de nouvelles clés sans compromis, vous pouvez remettre votre serveur en ligne .
Révoquer les anciens certificats.
Évaluation des dommages : toutes les données qui ont été dans la mémoire d'un processus servant des connexions SSL peuvent potentiellement avoir été divulguées. Cela peut inclure des mots de passe utilisateur et d'autres données confidentielles. Vous devez évaluer ce que ces données peuvent avoir été.
- Si vous exécutez un service qui autorise l'authentification par mot de passe, les mots de passe des utilisateurs qui se sont connectés peu de temps avant l'annonce de la vulnérabilité devraient être considérés comme compromis. Consultez vos journaux et modifiez les mots de passe de tout utilisateur concerné.
- Invalide également tous les cookies de session, car ils peuvent avoir été compromis.
- Les certificats clients ne sont pas compromis.
- Toutes les données échangées un peu avant la vulnérabilité pourraient être restées dans la mémoire du serveur et auraient donc pu être divulguées à un attaquant.
- Si quelqu'un a enregistré une ancienne connexion SSL et récupéré les clés de votre serveur, il peut maintenant déchiffrer sa transcription. (Sauf si PFS était assuré - si vous ne le savez pas, ce n'était pas le cas.)
Remédiation dans d'autres cas
Les serveurs qui n'écoutent que sur localhost ou sur un intranet ne doivent être considérés comme exposés que si des utilisateurs non fiables peuvent s'y connecter.
Avec les clients, il n’ya que de rares scénarios dans lesquels le bogue peut avoir été exploité: un exploit nécessiterait que vous utilisiez le même processus client pour:
- manipuler des données confidentielles (p. ex. mots de passe, certificats clients,…);
- et ensuite, dans le même processus, connectés à un serveur malveillant via SSL.
Ainsi, par exemple, un client de messagerie que vous utilisez uniquement pour vous connecter à votre fournisseur de messagerie (non totalement non approuvé) ne constitue pas un problème (pas un serveur malveillant). Exécuter wget pour télécharger un fichier n’est pas une préoccupation (pas de données confidentielles à fuir).
Si vous avez fait cela entre la nuit 2014-04-07 UTC et la mise à niveau de votre bibliothèque OpenSSL, considérez que toutes les données contenues dans la mémoire du client sont compromises.
Références