Comment utiliser Internet pendant la résolution de Heartbleed?

119

De nombreux sites Web ne sont pas vulnérables pour le moment, mais je ne sais pas s'ils étaient vulnérables il y a quelques jours.

Par exemple:

  • twitter.com: Non vulnérable pour le moment, mais le certificat est à partir du mercredi 05 mars 00:00:00 UTC 2014
  • google.com: Non vulnérable pour le moment, mais le certificat est daté du mer 12 mars à 09:53:40 UTC 2014
  • bankofamerica.com: Non vulnérable pour le moment, mais le certificat est à partir du jeu. 05 décembre 00:00:00 UTC 2013

Que fais-je? Ne pas utiliser ces derniers jusqu'à leur réémission? Comment savoir s'ils remettent le certificat avec de nouvelles clés? Il semble que je ne devrais même pas me connecter à ces sites pour changer mon mot de passe car il est impossible de savoir qu'ils sont le vrai site Web.

Cristian Ciupitu
la source
4
Double possible de Que devraient faire les utilisateurs finaux à propos de Heartbleed? sur security.stackexchange.com
Philipp

Réponses:

201

Mises à jour 2014-04-11

Cloudflare a lancé un défi pour vérifier que l'extraction de clé privée était réellement possible. Cela a été fait avec environ 100 000 demandes et cela vérifie les peurs. Ce n'est plus théorique, mais prouvé . Vous pouvez aller ici pour lire à ce sujet.

En outre, Bloomberg a indiqué que la NSA connaissait cet exploit depuis au moins deux ans . Cela a du sens, car la NSA dispose des ressources nécessaires pour recruter des analystes dont le seul travail est de trouver des exploits dans des logiciels tels que celui-ci. Maintenant que nous savons que le gouvernement américain l’exploite depuis si longtemps, la probabilité que d’autres États l’aient connue et exploitée est considérable.


TL; DR Surveillez les annonces des organisations concernant le statut de leurs systèmes, modifiez TOUS vos mots de passe et surveillez les fraudes / activités suspectes sur des comptes importants tels que les systèmes bancaires ou autres systèmes financiers.

Pour comprendre pourquoi la situation est si dangereuse, nous devons d’abord comprendre ce que cette attaque fait réellement. CVE-2014-0160, AKA Heartbleed, est un bogue de substitution de mémoire tampon qui permet à un attaquant d'obtenir jusqu'à 64 Ko de mémoire d'un serveur exécutant une version vulnérable d'OpenSSL.

Cela sonne vraiment mal. Comment ça marche en pratique

Vous avez raison, c'est un grave défaut, mais nous y reviendrons un peu plus tard. Parlons maintenant de la raison pour laquelle l'exploit fonctionne. Le protocole TLS ( Transport Layer Security ) est utilisé pour sécuriser les informations de nombreuses applications, notamment HTTP ( HTTPS ), ou pour sécuriser le protocole SMTP.si activé par exemple. Dans la RFC 5246, qui définit les normes pour TLS, il existe une fonction appelée pulsation. Le client et le serveur envoient des données dans les deux sens pour maintenir la connexion active afin qu'elle puisse être utilisée ultérieurement. Maintenant, dans la pratique, le client enverra des données et le serveur les renverra, et tout va bien. Cependant, dans les versions OpenSSL concernées, il n’ya aucune vérification pour savoir si le client a effectivement envoyé la quantité de données qu’il a indiquée. Donc, si je l’envoie 1 octet et que je dis au serveur que j’envoie réellement 64 ko, il me renverra heureusement 64 ko. D'où viennent ces autres octets? C'est la clé du problème ici. OpenSSL va vous renvoyer 64 Ko - 1 octet de mémoire auquel le processus a accès et que vous n'avez pas envoyé à l'origine, en fonction du lieu où votre octet est stocké.les clés privées et les informations que le serveur décrypte à utiliser. Des exemples de ce seraient: les mots de passe, informations de carte de crédit, et / ou PINs .

D'ACCORD. Qu'est-ce que cela signifie pour la sécurité de l'information? Si vous comprenez le fonctionnement de la cryptographie asymétrique, vous savez déjà que c'est grave, car sa divulgation rend le cryptage plus difficile que l'obscurcissement. Cela signifie que même si les serveurs peuvent être corrigés et ne perdent plus de mémoire, les sessions peuvent toujours être non sécurisées. Il est possible que cela ait été exploité avant sa publication ou la mise à jour du correctif, mais il n’existe actuellement aucune méthode prouvant qu’une attaque a eu lieu. Il est possible que les règles de IDSs peuvent être disponibles, mais à partir de maintenant qui n'est pas le cas. Les règles IDS ont été publiées . Cela en soi est extrêmement dangereux, car les opérateurs ne savent pas si leurs clés sont toujours sécurisées.

Nous sommes obligés de supposer que les clés ont été divulguées, ce qui signifie qu'il est possible que tout ce que vous envoyez sur le réseau puisse être déchiffré par un tiers. Le seul moyen de pallier ce problème consiste à régénérer les clés et à obtenir de nouveaux certificats et à révoquer les anciens. Malheureusement, cela prend du temps car les autorités de certification sont actuellement inondées de ces demandes. Cela laisse néanmoins la possibilité d’une attaque de type homme du milieu ou d’autres possibilités de phishing.

Quand sera-ce sécuritaire? Savoir quand ce sera sûr est une question difficile. Certaines des choses que je suggère de surveiller sont des annonces publiques expliquant que le bogue a été corrigé dans leurs environnements ou qu’ils n’ont jamais été vulnérables, car ils n’ont jamais utilisé les versions affectées. Une fois qu'ils ont annoncé qu'ils avaient mis à niveau leur nouvelle version d'OpenSSL, je m'assurais qu'ils utilisent un nouveau certificat signé après la date de publication de l'exploit, à savoir le 2014-04-07.

** Notez que le trafic précédemment enregistré peut être déchiffré si la clé privée a été divulguée par la suite.

Que puis-je faire en tant qu'utilisateur pour me protéger

Si vous pouvez éviter d’utiliser des sites critiques tels que les services bancaires en ligne ou l’accès aux dossiers médicaux en ligne, je vous conseillerais de le faire au cours des prochains jours. Si vous devez le faire, comprenez que votre session est potentiellement à risque et soyez prêt à en accepter les conséquences. En outre, après que les organisations ont annoncé qu'elles ne sont plus vulnérables, vous devez modifier votre mot de passe . en utilisant un gestionnaire de mot de passe peut aider. Vous devez également vous préparer à modifier ou à surveiller toute autre information utilisée, telle que les coordonnées bancaires ou le numéro de carte de crédit.

Avis spécial aux activistes

Tout ce qui utilise OpenSSL peut être affecté, y compris Tor . Il est possible que les gouvernements aient pu utiliser cette faille depuis son inclusion dans les versions OpenSSL d'il y a plus de deux ans, car ils disposeraient des vastes ressources nécessaires pour rechercher de tels exploits. Vous devez donc être prêt à utiliser ne plus être privé.

** Notez que le trafic précédemment enregistré peut être déchiffré si la clé privée a été divulguée par la suite, sauf si la sécurité PFS (Perfect Forward Security ) a été mise en œuvre.

¹- Il y a eu des affirmations selon lesquelles il est probable que les clés privées ne seraient pas en mémoire, mais en même temps, il y a eu des réclamations d'extraction réussie de clés. À ce stade, on ne sait pas quel côté est correct.

Jacob
la source
45
C’est de loin le texte le plus instructif que j’ai lu sur cette nouvelle attaque de Heartbleed, critique critique (tous les autres articles / blogs / articles de presse ne contenaient que des bribes d’informations). Bon travail :) .
Radu Murzea
4
Comment pouvons-nous savoir que les nouveaux certificats sont générés à l'aide d'une nouvelle clé?
3
Note that previously recorded traffic may be decrypted if the private key was later leaked. Pas si le serveur utilisait un chiffrement avec secret.
Wes
2
@Wes Vous avez raison de dire que PFS aurait probablement sécurisé le trafic. J'essayais d'expliquer la situation sans embarrasser les gens. Malheureusement, PFS n’a pas été largement déployé.
Jacob
6
Pour résumer what is heartbleed bug xkcd.com/1354
GoodSp33d
14

Le risque posé par cette vulnérabilité fait l’objet d’une surenchère. Je dis cela car il n’ya aucune preuve que cette vulnérabilité était connue ou exploitée avant sa publication par les chercheurs il ya 2 jours.

Soyons clairs: il est urgent que des correctifs soient apportés aux sites Web vulnérables, notamment ceux qui traitent des données sensibles sur Internet. Il est également urgent que les signatures de l'attaque soient chargées dans IDS et les outils de protection contre les logiciels malveillants. Dans l'informatique, nous devons répondre à cette vulnérabilité avec la plus haute priorité.

Cela dit, j'estime que le niveau de risque associé à cette vulnérabilité par la presse publique n'est pas justifié.

Que doivent faire les individus pour se protéger? N'utilisez pas de sites exécutant des versions vulnérables d'OpenSSL.

Tant que rien ne prouvera que cette vulnérabilité a été exploitée, toute action ultérieure est vaine et motivée par rien de plus que FUD. Vous n'êtes pas d'accord? Prenez en compte les nombreuses vulnérabilités publiées chaque mois ou chaque trimestre qui permettent l’exécution de code de manière arbitraire . Celles qui accordent à l'attaquant des privilèges au niveau de la racine ou du système ou pour lesquelles l'attaquant peut les obtenir ultérieurement par l'intermédiaire d'une élévation de privilèges présentent autant de risques pour la sécurité de toutes les données traitées par les systèmes vulnérables que cette vulnérabilité.

Dans de nombreux cas, ces vulnérabilités sont découvertes par le fournisseur de logiciel ou par des chercheurs qui en informent le fournisseur. Le fournisseur produit un correctif et le publie sur le marché sans publier les détails de la vulnérabilité. Dans certains cas, les détails sont publiés et les exploits sont publiés par la communauté de sécurité pour être utilisés dans des outils de test. Nous ne réagissons pas à ces nombreuses vulnérabilités en disant "Tous nos secrets PEUVENT avoir été exposés!"

S'il existe des preuves d'exploitation, nous devons réagir de manière appropriée. Je vois un grand risque dans la réaction excessive des chercheurs qui ont annoncé cette vulnérabilité et dans la presse qui ont amplifié le discours vague des chercheurs. Ils crient au loup.

- El viejo

el viejo
la source
9
Cette réponse devrait être votée plus IMO. De nombreuses vulnérabilités publiées chaque mois permettraient aux utilisateurs de voler les clés privées des serveurs, sans faire beaucoup de bruit. Celui-ci est plus grave que la moyenne en raison de l'omniprésence d'OpenSSL, mais il fait toujours l'objet d'une surenchère.
alastair
2
"Jusqu'à ce qu'il y ait des preuves que cette vulnérabilité a été exploitée" "S'il y a des preuves d'exploitation, nous devons réagir de manière appropriée." Vous parlez beaucoup de preuves d'exploitation. Pourtant, l’un des aspects effrayants du bogue Heartbleed est qu’une exploitation réussie est indétectable par la suite (à moins que vous stockiez le message de pulsation chaque jour dans son intégralité et à perpétuité, et même dans ces cas, il n’est pas garanti qu’une exploitation réussie entraîne une violation de Sécurité). Comment proposez-vous que nous établissions après coup les preuves d’une exploitation réussie du bogue?
un CVn
6
-1 parce que cet auteur ne comprend pas vraiment la nature des attaques, je ne pense pas. D'une part, les attaquants disposant de ce type d'accès travailleraient très dur pour le garder secret et pour ne pas laisser la preuve de leur intrusion se révéler. Un bogue de ce type qui entrave la sécurité d’environ la moitié du trafic sécurisé sur Internet ne crie pas du tout au loup. Je pense que c'est une question très grave.
Vue elliptique
19
Je tiens Bruce Schneier en haute estime en matière de sécurité informatique. Pour citer son billet de blog sur la vulnérabilité de Heartbleed : "Catastrophique" est le mot juste. Sur une échelle de 1 à 10, il s’agit d’un 11 . Cela seul suffit pour que je sois totalement en désaccord avec votre minimisation de la question.
abstrask
8
Ce poste devrait être déclassé. Le problème N'EST PAS en cours de traitement, c'est un échec catastrophique d'OpenSSL. De plus, même s'il n'a pas été utilisé jusqu'à ce qu'il soit annoncé publiquement, de mauvais joueurs ont définitivement compromis ses sites par la suite. Il est également fort probable que la NSA soit au courant (mais cela ne peut être prouvé). Il existe des théories convaincantes indiquant qu'il s'agit d'un compromis délibéré, même si l'auteur le nie.
davidgo
5

Tous les sites Web n'utilisent pas les bibliothèques OpenSSL pour HTTPS (GnuTLS et PolarSSL, par exemple) et toutes les versions d'OpenSSL n'étaient pas vulnérables (les versions antérieures ne l'étaient pas). Cela signifie qu'il est tout à fait probable que les sites Web que vous avez mentionnés ne modifient pas les certificats, car ils n'en ont pas besoin. Le simple fait de regarder les dates auxquelles les certificats ont été délivrés ne vous en dit pas assez.

Plusieurs outils et sites peuvent vous aider à vérifier si un site Web est vulnérable, par exemple: - http://filippo.io/Heartbleed - https://gist.github.com/mitsuhiko/10130454 - https: / /www.ssllabs.com/ssltest/

Malheureusement, comme vous l'avez déjà indiqué, cela ne vous dit pas si c'était le cas. Je crains que le principal problème en la matière ne concerne que la confiance: il n’ya aucun moyen objectif de vérifier quelles bibliothèques SSL ils utilisent et utilisent sans informations privilégiées. Vous devez espérer qu'ils ont fait ce qu'ils doivent faire (parce que c'est la bonne chose, ou même parce qu'ils craignent l'humiliation publique) et s'ils l'ont fait, vous ne pouvez qu'espérer qu'ils soient ouverts à ce sujet.

Bien sûr, vous pouvez toujours demander à ces sites Web s'ils ont été touchés. J'ai vu plusieurs sites Web publier des déclarations publiques à ce sujet. Demander publiquement à l'aide de médias sociaux tels que Twitter ou Facebook fonctionne souvent.

Le meilleur conseil que je puisse vous donner est donc un conseil général: faites attention à ce que vous laissez sur Internet et aux sites Web auxquels vous faites confiance avec vos informations personnelles.

Teun Vink
la source
3
attend que le bogue de PolarSSL inévitable apparaissent (il est à côté de la liste ...)
strugee
1

En ce qui concerne les clés privées exposées, il convient d’ajouter que, même si une personne peut déchiffrer des données dans une session chiffrée, comme elle dispose désormais de la clé privée, elle devra tout de même s’établir en tant qu’homme au milieu de la session. . Ce n'est pas n'importe qui sur Internet qui peut le faire.

D'après ce que j'ai compris, ils devront toujours intercepter le trafic en se plaçant sur votre réseau local (LAN) et en se faisant passer pour ARP, ou en étant en mesure de détourner / rediriger le trafic en annonçant de faux itinéraires vers des routeurs Internet. Ce type d'attaques a toujours été possible même sans cette vulnérabilité.

PeterJ
la source
2
Pas nécessairement vrai avec Heartbleed. Le bogue existe parce que les données (ce qui est censé être crypté) peuvent être exposées en accédant à la RAM. Par conséquent, ils n'ont pas besoin d'intercepter / renifler le trafic pour exploiter cette vulnérabilité. Cependant, certains logiciels malveillants doivent être installés sur le serveur ou le client et doivent également disposer d'un accès approprié pour accéder à la RAM.
ub3rst4r
Pas si. Il pourrait également être compromis par une attaque Man-In-The-Middle. En outre, le vidage de la mémoire n'affecte pas seulement cette session, il est possible (en fonction du contenu du bloc de mémoire) de voir les noms d'utilisateur et les mots de passe non chiffrés d'autres utilisateurs, en plus des clés privées pour faciliter le décodage de tout le trafic [via l'attaque de MITM]
davidgo
J'imagine que j'aurais dû être un peu plus clair sur le fait que je parlais principalement de l'utilisation des clés compromises après la correction du serveur.
PeterJ
0

Vous pouvez entrer l'URL d'un site sur LastPass Heartbleed Checker et celui-ci vous dira si le site était ou est toujours vulnérable et à quel moment son certificat a été mis à jour.

Il existe également une extension Chrome appelée Chromebleed qui vous avertira si vous visitez un site affecté par Heartbleed.

Mashable.com a une liste de sites bien connus, indiquant s'ils ont été affectés et si vous devez changer votre mot de passe. Fait intéressant, aucun des sites de la liste des banques et des courtiers n'a été touché.

Barmar
la source
-1

Globalement, je dirais que ne laissez pas la paranoïa vous toucher. En réalité, le fait de pouvoir décrypter le trafic et d’obtenir votre mot de passe n’est pas la même chose que de l’avoir fait.

Si vous utilisez une authentification à deux facteurs (et vous devriez) sur des sites tels que Twitter, Facebook, Gmail et votre banque, vous ne devriez pas être trop inquiet, et même si vous ne le faites pas, vous êtes probablement OK tel quel.

Si vous sentez le besoin de changer tous vos mots de passe, vous devrez aller de l'avant et le faire là où vous en ressentez le besoin. C'est tout ce qu'il y a à faire, vraiment.

Sirex
la source
1
L'authentification à deux facteurs n'empêchera pas un tiers malveillant de faire tout ce qui est possible autour de cet exploit. Je ne suis pas sûr de la raison pour laquelle vous en parlez. L'accès à vos comptes sociaux n'est pas vraiment la préoccupation de quelqu'un qui pourrait de toute façon tirer parti de cet exploit dans OpenSSL.
Ramhound le
1
@ramhound Je l'ai mentionné dans les commentaires avant que ceux-ci ne soient supprimés, deux facteurs sont utiles, car une fois qu'un nouveau certificat a été délivré sur le site, les mots de passe d'un attaquant peuvent ne plus être utiles. Parce qu'il est inutile de modifier un mot de passe après la délivrance d'un nouveau certificat (et la correction des serveurs), vous gagnez une nouvelle sécurisation instantanée du compte des fuites éventuelles d'informations d'identification alors que l'attaquant disposait de la clé privée. En outre, Twitter et Facebook sont importants car ils peuvent être utilisés comme identifiants uniques pour de nombreux autres sites Web (y compris celui-ci, je crois?)
Sirex
Le mot de passe est toujours utile car les utilisateurs utilisent le même mot de passe, même les utilisateurs qui utilisent une authentification à deux facteurs. Tant que l'attaquant est capable de vider les données de la session, il peut effectuer une attaque MiTM contre vous.
Ramhound le
Oui, mais la réutilisation des mots de passe est un véritable échec. Mon point de vue était que deux facteurs contribuent à atténuer la gravité et la longévité des séquelles, mais oui, cela n’aidera pas à l’exploitation du bug.
Sirex
@Sirex Pour autant que je sache, aucun site auquel je me connecte à l'aide d'une authentification à deux facteurs a invalidé les cookies de ma machine. C’est bien sûr un échec de leur part, mais ce que je veux dire c’est qu’à l’heure actuelle, l’authentification à deux facteurs n’est pas un sauveur. Un attaquant pourrait très facilement intercepter les cookies et les utiliser pour leurs propres demandes. De plus, puisqu'il n'y a aucun moyen de savoir si quelqu'un a exploité ce bogue (même pour les administrateurs système), la SEULE hypothèse de sécurité, c'est qu'il a été exploité. Je sais par exemple que chase.com était toujours vulnérable à partir de mercredi matin. Peu probable, les attaquants ont raté celui-là.
CrazyCasta