Comment récupérer du bogue Heartbleed dans OpenSSL?
CVE-2014-016 a.k.a. Heartbleed est une vulnérabilité d'OpenSSL. Ça fait peur.
Comment puis-je déterminer si je suis concerné?
Si je suis touché, que dois-je faire? Apparemment, la mise à niveau ne suffit pas.
Cette vulnérabilité a un impact potentiel élevé car si votre système a été attaqué, il restera vulnérable même après l'application de correctifs, et les attaques peuvent ne pas avoir laissé de traces dans les journaux. Il y a des chances que si vous patché rapidement et que vous n'êtes pas une cible de haut niveau, personne ne se sera mis à vous attaquer, mais il est difficile d'être sûr.
Suis-je vulnérable?
La version buggy d'OpenSSL
Le logiciel buggy est la bibliothèque OpenSSL 1.0.1 jusqu'à 1.0.1f , et OpenSSL 1.0.2 jusqu'à beta1. Les versions plus anciennes (0.9.x, 1.0.0) et les versions où le bogue a été corrigé (à partir de 1.0.1g, 1.0.2 beta 2) ne sont pas affectées. C'est un bug d'implémentation, pas une faille dans le protocole, donc seuls les programmes qui utilisent la bibliothèque OpenSSL sont affectés.
Vous pouvez utiliser l'outil de ligne de commande openssl version -a Pour afficher le numéro de version d'OpenSSL. Notez que certaines distributions portent le correctif de bogue sur des versions antérieures; si le journal des modifications de votre package mentionne le correctif de bogue Heartbleed, ça va, même si vous voyez une version comme 1.0.1f. Si openssl version -a Mentionne une date de construction (pas la date sur la première ligne) du 2014-04-07 vers la soirée UTC ou plus tard, ça devrait aller. Notez que le package OpenSSL peut avoir 1.0.0 Dans son nom même si le version est 1.0.1 (1.0.0 Fait 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 les connexions SSL . De nombreuses applications utilisent OpenSSL pour d'autres services cryptographiques, et c'est très bien: le bogue est dans l'implémentation d'une caractéristique particulière du protocole SSL, le "battement de cœur".
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 qui figure sur cette liste et écoute les connexions SSL , vous êtes probablement touché. Cela concerne les serveurs Web, les serveurs de messagerie, les serveurs VPN, etc. Vous saurez que vous avez activé SSL car vous avez dû générer un certificat, soit en soumettant une demande de signature de certificat à une autorité de certification, soit en créant votre propre auto-signature certificat. (Il est possible qu'une procédure d'installation ait généré un certificat auto-signé sans que vous vous en rendiez compte, mais cela se fait généralement 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 sauf si vos journaux ne montrent 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 n'a été exposé qu'en interne, la nécessité de modifier les clés dépendra des autres mesures de sécurité en place.
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 parcouru des sites Web aléatoires avec un navigateur vulnérable, vous pourriez avoir besoin s'inquiéter. Jusqu'à présent, il semble que la vulnérabilité n'ait pas été exploitée avant d'être découverte, vous n'avez donc à vous inquiéter que 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 ( tilise NSS )
- Firefox (utilise NSS) (au moins avec Firefox 27 sur Ubuntu 12.04, mais pas avec toutes les versions?
Quel est l'impact?
Le bogue permet à tout client qui peut se connecter à votre serveur SSL de récupérer environ 64 Ko de mémoire du serveur à la fois. Le client n'a pas besoin d'être authentifié en aucune façon. En répétant l'attaque, le client peut vider différentes parties de la mémoire dans des tentatives successives. Cela permet potentiellement à l'attaquant de récupérer toutes les données qui se trouvaient dans la mémoire du processus serveur, y compris les clés, les mots de passe, les cookies, etc.
L'un des éléments critiques des données que l'attaquant peut récupérer est la clé privée SSL du serveur. Avec ces données, l'attaquant peut usurper l'identité de votre serveur.
Le bogue permet également à n'importe quel serveur auquel votre client SSL s'est connecté de récupérer environ 64 Ko de mémoire du client à la fois. C'est un problème si vous avez utilisé un client vulnérable pour manipuler des données sensibles et que vous vous êtes ensuite connecté à un serveur non fiable avec le même client. Les scénarios d'attaque de ce côté sont donc nettement moins probables que du côté serveur.
Notez que pour les distributions typiques, il n'y a aucun impact sur la sécurité de la distribution des packages car l'intégrité des packages repose sur les signatures GPG, pas sur le transport SSL.
Comment corriger la vulnérabilité?
Remédiation des serveurs exposés
Mettez tous les serveurs concernés hors ligne. Tant qu'ils sont en cours d'exécution, ils peuvent potentiellement divulguer des données critiques.
Mettez à niveau le package de bibliothèque OpenSSL . Toutes les distributions devraient maintenant 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, mettez à niveau vers 1.0.1g ou supérieur. Assurez-vous que tous les serveurs concerné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/*/mapsGénérez de nouvelles clés . Cela est nécessaire car le bogue peut avoir 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.
- Dans tous les cas, déplacez les anciennes clés et certificats (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 desservant des connexions SSL peuvent potentiellement avoir été divulguées. Cela peut inclure les mots de passe des utilisateurs et d'autres données confidentielles. Vous devez évaluer quelles ont pu être ces données.
- Si vous exécutez un service qui permet l'authentification par mot de passe, les mots de passe des utilisateurs qui se sont connectés depuis un peu avant l'annonce de la vulnérabilité doivent être considérés comme compromis. Vérifiez vos journaux et modifiez les mots de passe de tout utilisateur concerné.
- Invalidez également tous les cookies de session, car ils peuvent avoir été compromis.
- Les certificats clients ne sont pas compromis.
- Toutes les données qui ont été échangées un peu avant la vulnérabilité peuvent être restées dans la mémoire du serveur et ont 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 désormais déchiffrer sa transcription. (À moins que PFS ait été assuré - si vous ne le savez pas, ce n'était pas le cas.)
Assainissement dans d'autres cas
Les serveurs qui n'écoutent que sur l'hôte local 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'y a que de rares scénarios où le bogue peut avoir été exploité: un exploit nécessiterait que vous utilisiez le même processus client pour
- manipuler des données confidentielles (par exemple mots de passe, certificats clients,…);
- puis, dans le même processus, connecté à un serveur malveillant via SSL.
Ainsi, par exemple, un client de messagerie que vous utilisez uniquement pour vous connecter à votre fournisseur de messagerie (pas complètement non fiable) n'est pas un problème (pas un serveur malveillant). Exécuter wget pour télécharger un fichier n'est pas un problème (pas de fuite de données confidentielles).
Si vous l'avez fait entre le 2014-04-07 soir UTC et la mise à niveau de votre bibliothèque OpenSSL, considérez que toutes les données qui étaient dans la mémoire du client sont compromises.
Références
- The Heartbleed Bug (par l'une des deux équipes qui ont indépendamment découvert le bug)
- Comment fonctionne exactement le battement de coeur OpenSSL TLS (Heartbleed)?
- Heartbleed signifie-t-il de nouveaux certificats pour chaque serveur SSL?
- Heartbleed: qu'est-ce que c'est et quelles sont les options pour l'atténuer?
Pour tester si vous êtes vulnérable, allez ici: http://filippo.io/Heartbleed/
Si vous constatez que vous êtes vulnérable, mettez à jour openssl et redémarrez votre serveur Web.
Il n'y a aucun moyen de se remettre de ce bogue. Sauvegardez tous les journaux, ils seront nécessaires dans le cas où quelqu'un se rendrait compte que la vulnérabilité existait réellement avant qu'elle ne soit annoncée