Heartbleed : Qu'est-ce que c'est et quelles sont les options pour l'atténuer ?

Premier Avant de paniquer, assurez-vous de bien comprendre si cette vulnérabilité vous concerne ou non. Si vous avez un serveur, mais que vous n'avez jamais eu d'applications utilisant TLS, ce n'est pas une priorité absolue pour vous. Si, au contraire, vous n'ont jamais eu Les applications compatibles avec TLS, alors vous allez vous régaler. Lire la suite :

Qu'est-ce que le CVE-2014-0160 alias "Heartbleed" ?

C'est un gros bordel, voilà ce que c'est. En résumé, une vulnérabilité exploitable à distance a été découverte dans les versions 1.0.1 à 1.0.1f d'OpenSSL, grâce à laquelle un attaquant peut lire certaines parties de la mémoire système. Ces parties sont celles qui contiennent des données sensibles telles que des clés privées, des clés pré-partagées, des mots de passe et des données d'entreprise de grande valeur, entre autres.

Le bogue a été découvert indépendamment par Neel Mehta de Google Security (21 mars 2014) et par la société finlandaise de tests de sécurité informatique Codenomicon (2 avril 2014).

Quelle en est la cause ?

Eh bien, un code errant dans OpenSSL. Ici est le commit qui a introduit la vulnérabilité, et aquí est le commit qui a corrigé la vulnérabilité. Le bug est apparu en décembre 2011 et a été corrigé aujourd'hui, le 7 avril 2014.

Le bug peut également être considéré comme le symptôme d'un problème plus vaste. Les deux problèmes liés sont (1) quel processus est en place pour s'assurer que du code errant n'est pas introduit dans une base de code, et (2) pourquoi les protocoles et extensions sont si complexes et difficiles à tester. Le point (1) est un problème de gouvernance et de processus avec OpenSSL et de nombreux autres projets. De nombreux développeurs résistent tout simplement aux pratiques telles que les revues de code, l'analyse et le balayage. Le point (2) est en cours de discussion au sein du groupe de travail TLS de l'IETF. Voir Heartbleed / complexité du protocole .

Le code errant a-t-il été inséré par malveillance ?

Je ne vais pas spéculer sur le fait de savoir s'il s'agit vraiment d'une erreur ou d'un bout de code glissé au nom d'un mauvais acteur. Cependant, la personne qui a développé le code d'OpenSSL affirme que c'était une inadvertance. Voir L'homme qui a introduit la grave faille de sécurité "Heartbleed" nie l'avoir insérée délibérément. .

Quels systèmes d'exploitation et quelles versions d'OpenSSL sont vulnérables ?

Comme mentionné ci-dessus, tout système d'exploitation qui utilise, ou toute application qui est liée à OpenSSL 1.0.1 à 1.0.1f.

Quels sont les symptômes, existe-t-il des méthodes pour détecter un exploit réussi ?

C'est la partie qui fait peur. Pour autant que nous le sachions, il n'existe aucun moyen connu de détecter si cette vulnérabilité a été exploitée ou non. Il est théoriquement possible que des signatures IDS soient publiées prochainement pour détecter cet exploit, mais à l'heure où nous écrivons ces lignes, elles ne sont pas disponibles.

Il existe des preuves que Heartbleed était activement exploité dans la nature dès novembre 2013. Voir l'article de l'EFF Wild at Heart : Les agences de renseignement utilisaient-elles Heartbleed en novembre 2013 ? Et Bloomberg rapporte que la NSA a utilisé l'exploit peu après l'introduction de la vulnérabilité. Voir La NSA exploiterait le bogue Heartbleed pour obtenir des renseignements depuis des années . Cependant, la communauté des services de renseignement américains dément les affirmations de Bloomberg. Voir IC ON THE RECORD .

Comment puis-je vérifier si mon système est affecté ?

Si vous maintenez OpenSSL sur votre système, alors vous pouvez simplement publier openssl version :

$ openssl version
OpenSSL 1.0.1g 7 Apr 2014

Si la distribution maintient OpenSSL, alors vous ne pouvez probablement pas déterminer la version d'OpenSSL en raison du dos Parcheando utilisant openssl ou les informations sur le paquet (par exemple, apt-get , dpkg , yum o rpm ). Le processus de retour Parcheando utilisé par la plupart (toutes ?) des distributions n'utilise que le numéro de version de base (par exemple, "1.0.1e") ; et ne no inclure un version efficace de la sécurité (par exemple, "1.0.1g").

Il y a une question ouverte sur Super User pour déterminer la version de sécurité effective pour OpenSSL et d'autres paquets lorsque les paquets sont rétablis. Malheureusement, il n'y a pas de réponse utile (autre que de vérifier le site web de la distro). Voir Déterminer la version de sécurité efficace face au backpatching ?.

En règle générale, si vous avez déjà installé l'une des versions concernées et si vous avez déjà exécuté des programmes ou des services qui utilisent OpenSSL pour la prise en charge du protocole TLS, vous êtes vulnérable.

Où puis-je trouver un programme pour tester cette vulnérabilité ?

Dans les heures qui ont suivi l'annonce de Heartbleed, plusieurs personnes sur Internet ont publié des applications Web accessibles au public, censées pouvoir être utilisées pour vérifier la présence de cette vulnérabilité sur un serveur. À l'heure où j'écris ces lignes, je n'ai examiné aucune de ces applications et je ne vais donc pas en faire la publicité. Elles peuvent être trouvées relativement facilement à l'aide de votre moteur de recherche préféré.

Comment cette vulnérabilité est-elle atténuée ?

Passez à une version non vulnérable et réinitialisez ou sécurisez à nouveau les données vulnérables. Comme indiqué sur le site Heartbleed site, les mesures d'intervention appropriées sont largement répandues :

1. Corrigez les systèmes vulnérables.
2. Régénérer de nouvelles clés privées.
3. Soumettez le nouveau CSR à votre CA.
4. Obtenir et installer le nouveau certificat signé.
5. Invalider les clés de session et les cookies
6. Réinitialiser les mots de passe et les secrets partagés
7. Révoquer les anciens certificats.

Pour une analyse et une réponse plus détaillées, voir Que doit faire un exploitant de site Web à propos de l'exploit OpenSSL Heartbleed ? sur le Security Stack Exchange.

Dois-je m'inquiéter du fait que mes clés ou d'autres données privées ont été compromises ? Quels sont les autres effets secondaires dont je dois m'inquiéter ?

Absolument. Les administrateurs de systèmes doivent supposez que leurs serveurs qui utilisaient des versions vulnérables d'OpenSSL sont effectivement compromis et répondent en conséquence.

Peu après la divulgation de la vulnérabilité, Cloudfare a proposé un défi pour voir si la clé privée d'un serveur pouvait être récupérée en pratique. Le défi a été remporté indépendamment par Fedor Indutny et Ilkka Mattila. Voir Le défi Heartbleed .

Où puis-je trouver plus d'informations ?

Lien dump, pour ceux qui cherchent plus de détails :

• OpenSSL SECADV 2014047
• CVE-2014-0160
• Heartbleed
• Annonce d'Ubuntu
• Annonce de RHEL
• Annonce officielle d'OpenSSL

Une chronologie assez détaillée des événements de divulgation peut être consultée à l'adresse suivante Chronologie de la divulgation de Heartbleed : qui savait quoi et quand ? .

Si vous êtes programmeur et que vous vous intéressez à diverses astuces de programmation, comme la détection d'une attaque Heartbleed par l'intermédiaire de l'interface OpenSSL msg_cb puis consultez le fichier d'appel de OpenSSL Avis de sécurité 2014047 .

Une explication simple du bug, par XKCD :

Ubuntu 12.04, 12.10 et 13.10

Ubuntu a publié USN-2165-1 qui indique que les paquets mis à jour sont maintenant disponibles dans les archives. Exécutez les deux commandes suivantes pour récupérer le correctif.

sudo apt-get update
sudo apt-get upgrade

Ubuntu 14.04

J'ai téléchargé un paquet Debian contenant la nouvelle version (1.0.1g) dans un PPA que j'ai mis en place à cet effet. Ces trois commandes vont ajouter mon PPA à votre système, mettre à jour la liste des paquets disponibles, et tout mettre à jour :

sudo add-apt-repository ppa:george-edison55/openssl-heartbleed-fix
sudo apt-get update
sudo apt-get upgrade

_{<em>Remarque : le PPA fournit également des paquets pour Ubuntu 12.04 et 13.10, au cas où vous préféreriez exécuter la nouvelle version (1.0.1g) plutôt que d'utiliser les versions corrigées dans les archives.</em>}

Ubuntu 10.04

Il s'agit d'une version LTS, la version serveur est toujours prise en charge et reçoit des mises à jour de sécurité. Mais la vulnérabilité heartbleed n'a pas affecté le paquet openssl d'une installation standard d'ubuntu 10.04, car la version est inférieure à 1.0.1.

La version de bureau a atteint sa fin de vie et doit être mise à niveau / réinstallée.

Ubuntu 13.04 et autres versions obsolètes

Ubuntu 13.04 a eu un cycle de support très court, ce à quoi vous ne vous attendiez peut-être pas. Elle a déjà atteint sa fin de vie et ne reçoit plus de mises à jour de sécurité. Elle aurait dû être mise à jour depuis longtemps. Si quelqu'un l'utilise encore, veuillez effectuer une mise à niveau maintenant, soit en partant de zéro, soit en effectuant une mise à niveau non destructive vers la version 13.10 en suivant cette procédure simple : http://www.tecmint.com/upgrade-ubuntu-13-04-raring-ringtail-to-ubuntu-13-10-saucy-salamander/ Après la mise à jour, le système reçoit le patch Heartbleed de la version 13.10.

Pour toutes les autres versions obsolètes d'ubuntu, cela signifie qu'une nouvelle installation est nécessaire.

Vérifier que le patch a été appliqué

Essentiellement, exécuter openssl version -a et assurez-vous que la date de construction est le 7 avril 2014 ou plus tard, mais voyez la suite. aquí .

Redémarrer

La meilleure façon de s'assurer que tous les services dépendant d'OpenSSL sont redémarrés est de redémarrer .

RedHat 6.5 et CentOS 6.5

Ceux-ci sont vulnérables. Erratum RHSA-2014-0376 de RedHat dit qu'il y a des bibliothèques corrigées disponibles, et que toute personne affectée devrait se mettre à jour dès que possible.

Au moment de la rédaction, CentOS n'avait pas encore de version corrigée, mais Publication de Karanbir Singh dans CentOS-announce dit qu'ils ont produit une version mise à jour d'openssl ( openssl-1.0.1e-16.el6_5.4.0.1 (notez les quatre derniers chiffres qui sont importants) dont la commande TLS exploitable est désactivée, et qui peut être appliquée en toute sécurité car elle sera remplacée par une version corrigée lorsqu'elle sera publiée.

La version temporairement corrigée ne semble pas encore avoir été placée sur tous les miroirs, mais se trouve dans le dépôt principal à l'adresse suivante http://mirror.centos.org/centos/6/updates/x86_64/Packages/ (et de même pour i686).

Editar Comme le dit Iain, il semble qu'il y ait maintenant une version entièrement corrigée pour C6.5, et il semble qu'elle ait été poussée autour des miroirs à la hâte. Une ligne droite yum update Je l'ai acheté pour mes serveurs ; c'est openssl-1.0.1e-16.el6_5.7 .

Versions de RH6 et C6 antérieures à 6.5

Ceux-ci ne sont pas vulnérables. D'après cet avis de Red Hat ,

Ce problème n'affectait pas les versions d'openssl livrées avec Red Hat Enterprise Linux 5 et Red Hat Enterprise Linux 6.4 et antérieures.

Publication de Karanbir Singh dans CentOS-announce est tout aussi clair en ce qui concerne le versioning :

Plus tôt dans la journée aujourd'hui, nous avons été informés d'une sérieuse problème dans openssl tel que livré dans CentOS-6.5.

Debian Wheezy

Debian a émis DSA-2896-1 et les bibliothèques corrigées sont disponible ici . Un Shell Shell est disponible ici .

1. Patch

Le dépôt Apt-get a été mis à jour, de sorte que les bibliothèques corrigées sont maintenant disponibles par l'intermédiaire de apt-get update && apt-get upgrade

apt-get upgrade libssl1.0.0 openssl

Alternativement (non recommandé), les paquets peuvent être mis à jour manuellement :

wget http://security.debian.org/pool/updates/main/o/openssl/libssl1.0.0-dbg_1.0.1e-2+deb7u5_amd64.deb
wget http://security.debian.org/pool/updates/main/o/openssl/openssl_1.0.1e-2+deb7u5_amd64.deb
wget http://security.debian.org/pool/updates/main/o/openssl/libssl1.0.0_1.0.1e-2+deb7u5_amd64.deb
wget http://security.debian.org/pool/updates/main/o/openssl/libssl-dev_1.0.1e-2+deb7u5_amd64.deb

dpkg -i openssl_1.0.1e-2+deb7u5_amd64.deb
dpkg -i libssl1.0.0_1.0.1e-2+deb7u5_amd64.deb
dpkg -i libssl1.0.0-dbg_1.0.1e-2+deb7u5_amd64.deb
dpkg -i libssl-dev_1.0.1e-2+deb7u5_amd64.deb

2. Redémarrez le serveur/services

Pour une meilleure protection, redémarrez le serveur entier ou, si le serveur ne peut pas être hors ligne, redémarrez les services nécessaires.

3. Vérifiez la version d'OpenSSL

love@server:~$ openssl version
OpenSSL 1.0.1e 11 Feb 2013
love@server:~$ dpkg -l libssl1.0.0
||/ Name                    Version          Architecture     Description
+++-=======================-================-================-====================================================
ii  libssl1.0.0                 1.0.1e-2+deb7u6  amd64            SSL shared libraries