Tout d’abord , avant de paniquer, assurez-vous de bien comprendre si cette vulnérabilité s’applique ou non à vous. Si vous avez un serveur, mais que vous n’avez jamais eu d’applications utilisant TLS, il ne s’agit donc pas d’une tâche hautement prioritaire à réparer. Si, par contre, vous avez déjà eu des applications compatibles TLS, alors vous êtes prêt à vous régaler. Continuer à lire:
Qu'est-ce que CVE-2014-0160, autrement dit "Heartbleed"?
C'est un gros bazar, c'est ce que c'est. En résumé, une vulnérabilité exploitable à distance a été découverte dans les versions OpenSSL 1.0.1 à 1.0.1f par lesquelles un attaquant peut lire certaines parties de la mémoire système. Ces éléments sont ceux 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 de manière indépendante par Neel Mehta de Google Security (21 mars 2014) et la société finlandaise de tests de sécurité informatique Codenomicon (2 avril 2014).
Quelle est la cause?
Eh bien, code errant dans OpenSSL. Voici le commit qui a introduit la vulnérabilité, et voici le commit qui a corrigé la vulnérabilité. Le bogue est apparu en décembre 2011 et a été corrigé aujourd'hui, le 7 avril 2014.
Le bogue peut également être considéré comme un symptôme d'un problème plus vaste. Les deux problèmes liés sont (1) quel processus est en place pour garantir que le code errant n'est pas introduit dans une base de code, et (2) pourquoi les protocoles et les extensions sont-ils si complexes et difficiles à tester. L'élément (1) est un problème de gouvernance et de processus avec OpenSSL et de nombreux autres projets. De nombreux développeurs résistent simplement à des pratiques telles que la révision de code, l'analyse et le scan. Le point (2) est en discussion sur le groupe de travail TLS de l'IETF. Voir Heartbleed / complexité du protocole .
Le code errant a-t-il été malicieusement inséré?
Je ne spéculerai pas sur le point de savoir s'il s'agissait vraiment d'une erreur ou éventuellement d'un peu de code inséré de la part d'un mauvais acteur. Cependant, la personne qui a développé le code pour OpenSSL a déclaré que c'était par inadvertance. See Man qui a introduit une grave faille de sécurité 'Heartbleed' nie l’avoir insérée délibérément .
Quels systèmes d'exploitation et versions d'OpenSSL sont vulnérables?
Comme mentionné ci-dessus, tout système d'exploitation utilisant ou toute application 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 effrayante. À notre connaissance, 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 détectées prochainement pour détecter cet exploit, mais à ce jour, elles ne sont pas disponibles.
Il a été prouvé que Heartbleed était activement exploité dans la nature dès novembre 2013. Voir Wild at Heart de l'EFF : les agences de renseignement ont-elles utilisé Heartbleed en novembre 2013? Et Bloomberg rapporte que la NSA avait armé l'exploit peu de temps après l'introduction de la vulnérabilité. Voir NSA dit avoir exploité Heartbleed Bug pour l'intelligence pendant des années . Cependant, les services de renseignement américains nient 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, vous pouvez simplement émettre openssl version:
$ openssl version
OpenSSL 1.0.1g 7 Apr 2014
Si la distribution maintient OpenSSL, vous pouvez probablement pas déterminer la version d'OpenSSL en raison de revenir rapiéçage en utilisant la opensslcommande ou les informations de package (par exemple, apt-get, dpkg, yumou rpm). Le processus de correction en arrière utilisé par la plupart des distributions (toutes?) Utilise uniquement le numéro de version de base (par exemple, "1.0.1e"); et n'inclut pas une version de sécurité effective (par exemple, "1.0.1g").
Une question ouverte sur le super utilisateur consiste à déterminer la version de sécurité effective pour OpenSSL et les autres packages lorsque les packages sont renvoyés en arrière. Malheureusement, il n'y a pas de réponses utiles (autres que consulter le site Web de la distribution). Voir Détermination de la version de sécurité effective en cas de backpatching ?.
En règle générale, si vous avez déjà installé l'une des versions concernées et avez exécuté des programmes ou des services liés à OpenSSL pour la prise en charge de TLS, vous êtes vulnérable.
Où puis-je trouver un programme pour tester la vulnérabilité?
Quelques heures après l’annonce de Heartbleed, plusieurs utilisateurs d’Internet avaient annoncé des applications Web accessibles au public, censées permettre de vérifier la présence de cette vulnérabilité sur un serveur. Au moment de la rédaction de cet article, je n’en ai examiné aucune, je ne publierai donc plus leurs applications. Ils peuvent être trouvés relativement facilement à l'aide de votre moteur de recherche préféré.
Comment cette vulnérabilité est-elle atténuée?
Mettez à niveau vers une version non vulnérable et réinitialisez ou sécurisez de nouveau les données vulnérables. Comme indiqué sur le site Heartbleed , les étapes de réponse appropriées sont généralement les suivantes:
- Corrigez les systèmes vulnérables.
- Régénérez de nouvelles clés privées.
- Soumettez un nouveau CSR à votre autorité de certification.
- Obtenez et installez le nouveau certificat signé.
- Invalider les clés de session et les cookies
- Réinitialiser les mots de passe et les secrets partagés
- Révoquer les anciens certificats.
Pour une analyse plus détaillée et une réponse, voir Que devrait faire un exploitant de site Web à propos de l’exploit Heartbleed OpenSSL? 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 autres effets secondaires devrais-je m'inquiéter?
Absolument. Les administrateurs système doivent supposer que leurs serveurs utilisant des versions vulnérables d'OpenSSL sont effectivement compromis et réagissent en conséquence.
Peu de temps après la divulgation de la vulnérabilité, Cloudfare a lancé un défi pour savoir si la clé privée d'un serveur pouvait être récupérée dans la 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 de vidage, pour ceux qui recherchent plus de détails:
Une chronologie assez détaillée des événements de divulgation peut être trouvée dans Chronologie de divulgation de Heartbleed: qui savait quoi et quand .
Si vous êtes programmeur et êtes intéressé par diverses astuces de programmation telles que la détection d'une attaque Heartbleed via le msg_cbrappel OpenSSL , consultez l' Avis de sécurité 2014047 d'OpenSSL .
