Que doit faire un opérateur de site Web à propos de l'exploit Heartbleed OpenSSL?

Question

CVE-2014-016

Ceci est censé être une question canonique sur le traitement de l'exploit Heartbeat.

J'exécute un serveur Web Apache avec OpenSSL, ainsi que quelques autres utilitaires reposant sur OpenSSL (en tant que client). Que dois-je faire pour atténuer les risques?

Le bug disséqué
Vérifiez si votre site est vulnérable (Duckduckgo.com l'est, par exemple!)

 I looked at some of the data dumps from vulnerable sites, and it was ... bad. I saw emails, passwords, password hints. SSL keys and session cookies. Important servers brimming with visitor IPs. Attack ships on fire off the shoulder of Orion, c-beams glittering in the dark near the Tannhäuser Gate. I should probably patch OpenSSL.

Crédit: XKCD .

scuzzy-delta · Accepted Answer

Il y a plus à considérer que de nouveaux certificats (ou plutôt de nouvelles paires de clés) pour chaque serveur affecté. Cela signifie également:

Patcher les systèmes affectés sur OpenSSL 1.0.1g
Révocation des anciennes paires de clés qui viennent d'être remplacées
Changer tous les mots de passe
Invalidation de toutes les clés de session et cookies
Évaluer le contenu réel géré par les serveurs vulnérables qui aurait pu être divulgué et réagir en conséquence.
Évaluer toute autre information qui aurait pu être révélée, comme les adresses mémoire et les mesures de sécurité

Neel Mehta (l'ingénieur de la sécurité Google qui a signalé pour la première fois le bogue) a tweeté :

Les modèles d'allocation de tas rendent l'exposition aux clés privées peu probable pour #heartbleed #dontpanic.

Tomas Rzepka (probablement de la société de sécurité suédoise Certezza ) répond avec ce qu'ils devaient faire pour récupérer les clés:

Nous pouvons extraire la clé privée avec succès sur FreeBSD après avoir redémarré Apache et effectué la première demande avec ssltest.py

Le vol de clé privée a également été démontré par CloudFlare Challenge .

Et l'utilisateur Twitter makomk a sonné avec :

Je l'ai récupéré d'Apache sur Gentoo en tant que facteur premier nu en binaire, mais votre démo est beaucoup plus claire ... Elle a un faible taux de réussite, plus d'essais sur la même connexion n'aident pas, se reconnecter en mai, redémarrer probablement gagné 't ... Quelqu'un avec des compétences décentes d'exploitation de tas pourrait probablement améliorer la fiabilité. Je n'essaie pas vraiment si fort.

J'ai résumé les points ci-dessus à partir de heartbleed.com (soulignement le mien):

Quel est le matériel de clé primaire qui a fui et comment le récupérer?

Ce sont les joyaux de la couronne, les clés de cryptage elles-mêmes . Des clés secrètes qui ont fui permettent à l'attaquant de décrypter tout trafic passé et futur vers les services protégés et d'usurper l'identité du service à volonté. Toute protection accordée par le chiffrement et les signatures dans les certificats X.509 peut être contournée. La récupération de cette fuite nécessite de corriger la vulnérabilité, de révoquer les clés compromises et de réémettre et redistribuer de nouvelles clés. Même en faisant tout cela, le trafic intercepté par l'attaquant dans le passé restera toujours vulnérable au déchiffrement. Tout cela doit être fait par les propriétaires des services.

Qu'est-ce que le matériel de clé secondaire qui a fui et comment le récupérer?

Ce sont par exemple les informations d'identification de l'utilisateur (noms d'utilisateur et mots de passe) utilisées dans les services vulnérables. La récupération de ces fuites nécessite d'abord que les propriétaires du service rétablissent la confiance dans le service conformément aux étapes décrites ci-dessus. Après cela, les utilisateurs peuvent commencer à changer leurs mots de passe et les clés de cryptage possibles selon les instructions des propriétaires des services qui ont été compromis. Toutes les clés de session et les cookies de session doivent être invalides et considérés comme compromis.

Qu'est-ce qu'un contenu protégé divulgué et comment le récupérer?

Il s'agit du contenu réel géré par les services vulnérables . Il peut s'agir de détails personnels ou financiers, de communications privées telles que des e-mails ou des messages instantanés, des documents ou tout autre élément qui mérite d'être protégé par cryptage. Seuls les propriétaires des services pourront estimer la probabilité de ce qui a été divulgué et ils doivent en informer leurs utilisateurs en conséquence. La chose la plus importante est de restaurer la confiance envers le matériel de clé primaire et secondaire comme décrit ci-dessus. Seulement cela permet une utilisation sûre des services compromis à l'avenir.

Qu'est-ce qu'une garantie fuite et comment récupérer?

Les garanties fuites sont d'autres détails qui ont été exposés à l'attaquant dans le contenu de la mémoire qui a fui. Ceux-ci peuvent contenir des détails techniques tels que des adresses mémoire et des mesures de sécurité telles que des canaris utilisés pour se protéger contre les attaques par débordement. Ceux-ci n'ont qu'une valeur contemporaine et perdront leur valeur pour l'attaquant lorsque OpenSSL aura été mis à niveau vers une version fixe.

hoa · Answer

Copié directement de site OpenSSL

Avis de sécurité OpenSSL [07 avr. 2014]

Dépassement de lecture de pulsation TLS (CVE-2014-0160)

Une vérification des limites manquantes dans la gestion de l'extension de pulsation TLS peut être utilisée pour révéler jusqu'à 64 Ko de mémoire à un client ou un serveur connecté.

Seules les versions 1.0.1 et 1.0.2-beta d'OpenSSL sont affectées, y compris 1.0.1f et 1.0.2-beta1.

Merci à Neel Mehta de Google Security d'avoir découvert ce bogue et à Adam Langley et Bodo Moeller d'avoir préparé le correctif.

Les utilisateurs concernés doivent passer à OpenSSL 1.0.1g. Les utilisateurs incapables de mettre à niveau immédiatement peuvent également recompiler OpenSSL avec -DOPENSSL_NO_HEARTBEATS.

1.0.2 sera corrigé dans 1.0.2-beta2.

Vérifiez si vous utilisez les versions mentionnées d'OpenSSL, si oui, mettez-le à 1.0.1g (en le compilant depuis source et en enveloppant le paquet avec par exemple FPM ).
(Ajout par atk) Ensuite, remplacez vos certificats exposés et révoquez-les.
(Ajout par dr.jimbob) Il convient de souligner que OpenSSH n'est pas affecté par le bogue OpenSSL. Alors qu'OpenSSH utilise openssl pour certaines fonctions de génération de clés , il n'utilise pas le protocole TLS (et en particulier l'extension TLS Heartbeat que Heartbleed attaque). Il n'est donc pas nécessaire de s'inquiéter de la compromission de SSH, bien que ce soit toujours une bonne idée de mettre à jour openssl à 1.0.1g ou 1.0.2-beta2 (mais vous n'avez pas à vous soucier de remplacer les paires de clés SSH).
- (OrangeDog): @drjimbob sauf si vos clés SSH sont dans la mémoire d'un processus qui utilise TLS d'OpenSSL. Peu probable mais possible.
(Ajout de Deer Hunter): à en juger par les tentatives actives signalées dans le DMZ , la meilleure chose maintenant est ARRÊT LE SERVEUR FRIKKIN DÈS QUE POSSIBLE . Des sessions sont détournées, des mots de passe divulgués et des données commerciales confidentielles révélées.
(Un peu plus avec la permission d'EFF.org ): "Pour parvenir à une conclusion plus ferme sur l'histoire de Heartbleed, il serait préférable que la communauté des réseaux essaie de reproduire les conclusions de Koeman. Tous les opérateurs de réseau qui ont un TLS étendu -les journaux de trafic des couches peuvent rechercher les battements de cœur malveillants, qui ont généralement une charge utile TCP TCP de 18 03 02 00 03 01 40 00 ou 18 03 01 00 03 01 40 00, Bien que le 0x4000 à la fin peut être remplacé par des nombres inférieurs, en particulier dans les implémentations qui essaient de lire plusieurs blocs de morceaux de malloc. "En résumé, si vous conservez des journaux TLS détaillés (peu probable pour la majorité des opérateurs), vérifiez les informations passées. tentatives d'exploitation (et partagez ce que vous avez).