Question:
Que doit faire un opérateur de site Web à propos de l'exploit Heartbleed OpenSSL?
Deer Hunter
2014-04-08 08:10:31 UTC
view on stackexchange narkive permalink

CVE-2014-0160

http://heartbleed.com

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

Je lance 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?

Obligatory XKCD 

  J'ai regardé quelques des vidages de données de sites vulnérables, et c'était ... mauvais. J'ai vu des e-mails, des mots de passe, des indices de mot de passe. Clés SSL et cookies de session. Serveurs importants regorgeant d'adresses IP de visiteurs. Attaquez les navires en feu sur l'épaule d'Orion, des poutres en C scintillantes dans l'obscurité près de la porte de Tannhäuser. Je devrais probablement patcher OpenSSL.

Crédit: XKCD.

Il convient de noter qu'OpenSSH n'est pas affecté par le bogue OpenSSL. Bien 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 de battement de cœur TLS qui attaque les crises de saignement de cœur). Il n'y a donc pas lieu de s'inquiéter de la compromission de SSH, même si c'est toujours une bonne idée de mettre à jour openssl vers 1.0.1g ou 1.0.2-beta2 (mais vous n'avez pas à vous soucier de remplacer les paires de clés SSH).
@Adnan: sauf qu'il y a quelques autres choses à faire avec les certificats ... Si vous pensez que cela ne sert à rien, VTC.
@drjimbob sauf si vos clés SSH sont dans la mémoire d'un processus qui utilise le TLS d'OpenSSL. Peu probable mais possible.
À en juger par les tentatives actives signalées dans la [DMZ] (http://chat.stackexchange.com/rooms/151/the-dmz), la meilleure chose à faire est maintenant de ** ARRETER LE SERVEUR FRIKKIN dès que possible **. Des sessions sont détournées, des mots de passe divulgués, des données commerciales confidentielles révélées.
@OrangeDog - Bien que "possible", cela semble exiger un exploit complètement séparé. Il n'y a aucune raison (du moins sur mes systèmes) que tout processus ayant accès à une clé privée SSH utilise également TLS. Les clés privées SSH sont limitées à ssh, sshd et ssh-agent. Alors inquiétez-vous de changer vos certificats TLS utilisés pour HTTPS, FTPS, e-mail, etc. Souciez-vous de changer tous les mots de passe que vous avez déjà utilisés sur une connexion HTTPS ou TLS vers un site Web qui peut avoir utilisé OpenSSL au cours des trois dernières années que vous appréciez. Mais vraiment aucune raison légitime de s'inquiéter des clés SSH.
Apparemment, Gabriel Weinberg @ DuckDuckGo avait ses serveurs [patché] (https://twitter.com/yegg/status/453590663695966208). Qualys a intégré le chèque Heartbleed dans son [outil d'évaluation] (https://www.ssllabs.com/ssltest/analyze.html?d=duckduckgo.com&s=50.18.192.251).
Pour lier: [Que doivent faire les utilisateurs finaux à propos de Heartbleed?] (Http://security.stackexchange.com/questions/55083), [Comment fonctionne exactement l'exploit OpenSSL TLS Heartbeat (Heartbleed)] (http: // security. stackexchange.com/questions/55116)
Mise à jour de Node.JS: [indutny a commenté le 8 avril 2014: Non, ce n'est pas nous avons désactivé HEARTBEATS depuis le nœud v0.10.2.] (Https://github.com/joyent/node/issues/7424#issuecomment-39820298 )
[Un autre lien utile] (http://security.stackexchange.com/questions/7790/guidance-for-implementors-of-https-only-sites-server-side)
Pour faciliter la compréhension: http://security.stackexchange.com/questions/55343/how-to-explain-heartbleed-without-technical-terms. Pour les binaires statiques: http://security.stackexchange.com/questions/55107/heartbleed-how-to-find-out-applications-using-stately-compiled-version-of-ope
Pour encore plus de `` facilité de compréhension '': http://xkcd.com/1354/
Cinq réponses:
scuzzy-delta
2014-04-08 11:50:03 UTC
view on stackexchange narkive permalink

There is more to consider than just new certificates (or rather, new key pairs) for every affected server. It also means:

  • Patching affected systems to OpenSSL 1.0.1g
  • Revocation of the old keypairs that were just supersceded
  • Changing all passwords
  • Invalidating all session keys and cookies
  • Evaluating the actual content handled by the vulnerable servers that could have been leaked, and reacting accordingly.
  • Evaluating any other information that could have been revealed, like memory addresses and security measures

Neel Mehta (the Google Security engineer who first reported the bug) has tweeted:

Heap allocation patterns make private key exposure unlikely for #heartbleed #dontpanic.

Tomas Rzepka (probably from Swedish security firm Certezza) replied with what they had to do to recover keys:

We can extract the private key successfully on FreeBSD after restarting apache and making the first request with ssltest.py

Private key theft has been also demonstrated by CloudFlare Challenge.

And Twitter user makomk chimed in with:

I've recovered it from Apache on Gentoo as a bare prime factor in binary, but your demo's a lot clearer...It has a lowish success rate, more tries on the same connection don't help, reconnecting may, restarting probably won't...Someone with decent heap exploitation skills could probably improve the reliability. I'm not really trying that hard.

I summarized the bullet points above from heartbleed.com (emphasis mine):

What is leaked primary key material and how to recover?

These are the crown jewels, the encryption keys themselves. Leaked secret keys allows the attacker to decrypt any past and future traffic to the protected services and to impersonate the service at will. Any protection given by the encryption and the signatures in the X.509 certificates can be bypassed. Recovery from this leak requires patching the vulnerability, revocation of the compromised keys and reissuing and redistributing new keys. Even doing all this will still leave any traffic intercepted by the attacker in the past still vulnerable to decryption. All this has to be done by the owners of the services.

What is leaked secondary key material and how to recover?

These are for example the user credentials (user names and passwords) used in the vulnerable services. Recovery from this leaks requires owners of the service first to restore trust to the service according to steps described above. After this users can start changing their passwords and possible encryption keys according to the instructions from the owners of the services that have been compromised. All session keys and session cookies should be invalided and considered compromised.

What is leaked protected content and how to recover?

This is the actual content handled by the vulnerable services. It may be personal or financial details, private communication such as emails or instant messages, documents or anything seen worth protecting by encryption. Only owners of the services will be able to estimate the likelihood what has been leaked and they should notify their users accordingly. Most important thing is to restore trust to the primary and secondary key material as described above. Only this enables safe use of the compromised services in the future.

What is leaked collateral and how to recover?

Leaked collateral are other details that have been exposed to the attacker in the leaked memory content. These may contain technical details such as memory addresses and security measures such as canaries used to protect against overflow attacks. These have only contemporary value and will lose their value to the attacker when OpenSSL has been upgraded to a fixed version.

"Les clés secrètes fuites permettent à l'attaquant de décrypter tout trafic passé et futur vers les services protégés" - n'étions-nous pas censés avoir un secret de transmission parfait pour nous protéger de cela?
Citant de heartbleed.com: * "L'utilisation de Perfect Forward Secrecy (PFS), qui est malheureusement rare mais puissante, devrait protéger les communications passées du décryptage rétrospectif." / status / 453280081897467905) [clé de ticket] (http://en.wikipedia.org/wiki/Transport_Layer_Security#Session_tickets) compromettrait toutes les sessions signées.
Les clés SSL ne sont pas susceptibles de fuir via Heartbleed car elles ne sont probablement pas présentes dans ces régions de mémoire. En revanche, les cookies des utilisateurs, y compris les cookies de session, les mots de passe des utilisateurs et les données AJAX sont ** très susceptibles ** d'y être trouvés.
@kravietz Bon appel (voir edit / tweet de Neel Mehta)
@scuzzy-delta En fait, je fais des tests en ce moment et dans les vidages HB, je trouve pas mal de certificats X.509, donc je suis moins sûr de ne pas y trouver de clés privées. D'autre part, la présence des certificats peut être expliquée - le serveur SSL envoie un chemin de certificat à chaque nouveau client, afin qu'ils puissent être présents dans la mémoire opérationnelle. D'un autre côté, les clés privées sont ** également ** utilisées à chaque connexion, mais je ne sais pas si elles sont copiées en mémoire aussi souvent que les certificats.
Oh, et maintenant c'est officiel - nous devons régénérer les clés privées et réémettre les certificats ... https://www.cloudflarechallenge.com/heartbleed
hoa
2014-04-08 08:30:01 UTC
view on stackexchange narkive permalink

Directement copié à partir du site OpenSSL

Avis de sécurité OpenSSL [7 avril 2014]

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

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

Seulement 1.0.1 et 1.0.2-beta Les versions 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 pour la préparation du correctif.

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

La version 1.0.2 sera corrigée dans la version 1.0.2-beta2.

  • Vérifiez si vous utilisez les versions mentionnées d'OpenSSL, si oui le patch à 1.0.1g (en le compilant à partir de 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 qu'OpenSSH n'est pas affecté par le bogue OpenSSL. Bien 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 de battement de cœur TLS qui attaque). Il n'y a donc pas lieu de s'inquiéter de la compromission de SSH, bien que ce soit toujours une bonne idée de mettre à jour openssl vers 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 le TLS d'OpenSSL. Peu probable mais possible.

  • (Ajout de Deer Hunter): à en juger par les tentatives actives signalées dans la DMZ, la meilleure chose à faire est maintenant ARRÊTER LE SERVEUR FRIKKIN DÈS QUE POSSIBLE . Des sessions sont détournées, des mots de passe divulgués, des données commerciales confidentielles révélées.

  • (Un petit plus avec l'aimable autorisation de EFF.org): "Pour parvenir à une conclusion plus ferme sur l'histoire de Heartbleed, il serait préférable que la communauté de réseautage essaie de reproduire les conclusions de Koeman. Les opérateurs de réseau qui disposent de journaux de trafic étendus sur la couche TLS peuvent rechercher les battements de cœur malveillants, qui ont le plus souvent une charge utile 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 puisse être remplacé par des nombres inférieurs, en particulier dans les implémentations qui essaient de lire plusieurs chunk bins malloc. " En un mot, si vous conservez des journaux TLS détaillés (peu probable pour la majorité des opérateurs), vérifiez les tentatives d'exploitation passées (et partagez ce que vous avez).

Q&A associé à ServerFault:

https://serverfault.com/questions/587338/does-heartbleed-affect-aws-elastic-load-balancer

https://serverfault.com/questions/587329/heartbleed-what-is-it-and-what-are-options-to-mitigate-it

https://serverfault.com/questions/587348/best-method-to-update-ubuntu-13-10-to-path-the-heartbleed-bug

https://serverfault.com/questions/587324/heartbleed-how-to-reliably-and-portably-check-the-openssl-version

Un puits -Résumé écrit sur AskUbuntu: https://askubuntu.com/a/444905

Un Q&A complet chez Unix&Linux SE: https: //unix.stackexchange. com / questions / 123711 / comment-puis-je-récupérer-du-bug-in-openssl

Si par hasard vous exécutez un serveur sous Mac OS X: ht tps: //apple.stackexchange.com/questions/126916/what-versions-of-os-x-are-affected-by-heartbleed

Récupération de la clé SSL privée à l'aide de heart bleed: http://blog.cloudflare.com/answering-the-critical-question-can-you-get-private-ssl-keys-using-heartbleed Oui, c'est possible!

Remplacez ensuite vos certificats exposés et révoquez-les.
Luke Rehmann
2014-04-08 08:37:59 UTC
view on stackexchange narkive permalink

[edited

J'ai créé un outil pour vérifier l'état de votre SSL et voir si le battement de cœur est activé et vulnérable. Outil sur: http://rehmann.co/projects/heartbeat/

Il y en a un autre sur http://filippo.io/Heartbleed/

Si vous êtes vulnérable, veuillez mettre à jour vos packages OpenSSL. & renouveler vos certificats!

Mec, avez-vous une version hors ligne avec la source? Si mon site est vulnérable, je serais fou de le laisser sous tension.
@Deer Hunter Vous pouvez arrêter n'importe quel service utilisant TLS (apache, nginx, email?). SSH n'est ** PAS ** affecté par ce bogue.
Un autre vérificateur: http://filippo.io/Heartbleed/ (Filippo a mis sa source sur GitHub!)
Pourquoi devrions-nous faire confiance à votre outil pour ne pas exploiter la vulnérabilité?
@MichaelKjorling: étant donné la couverture massive du bogue, je suis sûr qu'il y a des dizaines de scanners tout autour.
@DeerHunter Sans aucun doute. Mais c'est l'échange de pile de sécurité de l'information, et je préfère ne pas pointer directement ces scanners vers mes serveurs. :)
-1 car il s'agit d'un outil en ligne qui n'est pas auditable, donc pas fiable.
@DeerHunter: Un outil en ligne, même avec du code source, est toujours un outil en ligne. Rien ne garantit que le code en cours d'exécution est le code annoncé. Le principal problème n'est pas que le site exploite directement le problème, mais plutôt qu'il enregistre l'image mémoire capturée et la conserve pour plus tard.
@dolmen: rien * ne garantit * que cet outil n'analysera pas votre site même si vous ne lui indiquez pas votre nom de domaine (en supposant que votre site puisse être connecté à, ofc). Il y a des gens qui scannent tous les sites qu'ils peuvent trouver pour le vuln. Certaines de ces personnes sont des chercheurs en sécurité.
Malheureusement, vérifier la version d'OpenSSL en utilisant `openssl version -a` n'est pas un moyen très fiable de voir si vous avez besoin d'un correctif. Certaines versions d'Ubuntu et Debian continuent d'afficher un numéro de version inférieur, même si tous les correctifs sont appliqués. Plus de détails sur http://serverfault.com/questions/587324/heartbleed-how-to-reliably-and-portably-check-the-openssl-version
dolmen
2014-04-08 19:13:59 UTC
view on stackexchange narkive permalink

Jspenguin a écrit un outil hors ligne pour vérifier si un serveur a la faille. Téléchargez-le, auditez-le et exécutez-le.

J'ai également écrit ssl-heartbleed-check.pl (également un outil hors ligne) pour vérifier si l'OpenSSL utilisé par votre pile Perl (qui sur * n * x est souvent l'openssl utilisé par l'ensemble du système) est affecté. Cela peut vous aider à déterminer si vous êtes affecté du côté client.

Nmap 6.45 inclut un script ssl-heartbleed . ssl-heartbleed.nse peut également être utilisé avec nmap ≥6.25.

L'outil hors ligne de Jspenguin est un fichier de zéro octet et le compartiment est un accès refusé.
En voici un autre (ou miroir) https://gist.github.com/takeshixx/10107280
Le site de Js Penguin est en panne, voici un miroir de son outil tel qu'il apparaissait le soir du 7 avril. http://rehmann.co/projects/heartbeat/ssltest.py
kravietz
2014-04-08 19:41:34 UTC
view on stackexchange narkive permalink

Notez que si vous utilisez un fournisseur basé sur le cloud ou un réseau de distribution de contenu, et qu'ils sont vulnérables, le contenu de votre site Web qui fuit sera mélangé au contenu de tous les autres sites Web utilisant ce fournisseur. Je viens de voir cela avec Incapsula, où le contenu d'un site Web bancaire a été divulgué le long du site Web de crypto-monnaie. Heureusement, ils sont corrigés.



ⓘ
Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...