Question Comment utiliser Internet pendant la correction de Heartbleed?


Il existe de nombreux sites Web qui ne sont pas actuellement vulnérables, mais je ne sais pas si étaient vulnérable il y a quelques jours.

Par exemple:

  • twitter.com: Pas vulnérable pour le moment, mais le certificat date du mer. mars 05 00:00:00 UTC 2014
  • google.com: Pas vulnérable en ce moment, mais le certificat date du mer. mars 12 09:53:40 UTC 2014
  • bankofamerica.com: Pas vulnérable en ce moment, mais le certificat date du jeudi 05 décembre 00:00:00 UTC 2013

Que fais-je? Ne les utilisez pas jusqu'à ce qu'ils soient réémis? Comment puis-je savoir qu'ils réémettent le certificat avec de nouvelles clés? Il semble que je ne devrais même pas me connecter à ces sites pour modifier mon mot de passe, car il est impossible de savoir qu’ils sont le véritable site Web.


119
2018-04-09 04:55


origine


Duplicata possible de Que devraient faire les utilisateurs finaux à propos de Heartbleed?sur security.stackexchange.com - Philipp


Réponses:


Mises à jour 2014-04-11

Cloudflare a mis au point un défi pour vérifier que l'extraction de clé privée était en fait possible. Cela a été fait avec environ 100 000 demandes, et cela vérifie les craintes. Ce n'est plus théorique, mais éprouvé. Tu peux y aller ici à lire à ce sujet.

Aussi, Bloomberg a rapporté que le NSA ont connu cet exploit pour au moins deux ans. Cela a du sens puisque la NSA a les ressources pour embaucher des analystes dont la seule tâche est de trouver des exploits dans des logiciels comme celui-ci. Maintenant que nous savons que le gouvernement des États-Unis l'utilise depuis si longtemps, la probabilité que d'autres États l'aient connue et exploitée est importante.


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

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

Cela semble vraiment mauvais. Comment ça marche dans la pratique

Vous avez raison, c'est un grave défaut, mais nous y reviendrons un peu plus tard. Maintenant, parlons de la raison pour laquelle l'exploit fonctionne. Sécurité de la couche transport (TLS) est utilisé pour sécuriser les informations par de nombreuses applications, y compris HTTP (HTTPS) ou pour sécuriser SMTP si activé par exemple. Dans la RFC 5246, qui définit les normes pour le protocole TLS, il existe une fonction appelée pulsation. Le client et le serveur envoient des données dans les deux sens pour que la connexion reste active, afin de pouvoir l'utiliser ultérieurement. Maintenant, en pratique, le client enverra des données et le serveur les renverra, et tout va bien. Cependant, dans les versions OpenSSL affectées, il n'y a pas de vérification pour voir si le client a effectivement envoyé la quantité de données qu'il a dite. Donc, si je lui envoie 1 octet et que je dis au serveur que je l’ai effectivement envoyé 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 octets de mémoire auxquels le processus a accès et que vous n'avez pas envoyé à l'origine, selon l'emplacement de votre octet. Ces octets supplémentaires de la mémoire sont le problème car ils peuvent contenir des informations précieuses telles que matériel de clé privée¹ et des informations que le serveur déchiffre pour les utiliser. Exemples: 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 cela est grave car la divulgation ne rend le cryptage plus qu'un simple obscurcissement. Cela signifie que même si les serveurs peuvent être mis à jour 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 qu’il ne soit publiquement connu ou qu’il n’y ait des correctifs, mais il n’existe actuellement aucune méthode prouvant qu’une attaque a eu lieu. Il est possible que les règles pour IDS peut devenir disponible, mais pour l'instant ce n'est pas le cas.  Les règles IDS ont été publiées. Celui-ci 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 à travers le réseau puisse être déchiffré par un tiers. La seule façon d'atténuer ce problème est de régénérer les clés et de réémettre de nouveaux certificats tout en révoquant les anciens. Malheureusement, cela prend du temps car le CAs sont sans doute inondés de ces demandes en ce moment. Encore cela laisse la possibilité pour un attaque homme-dans-le-milieu, ou d'autres possibilités de phishing.

Quand sera-t-il en sécurité? Savoir quand ce sera en sécurité est une question difficile. Certaines des choses que je suggérerais de surveiller sont les annonces publiques expliquant que le bogue a été corrigé dans leur environnement ou qu'elles n'ont jamais été vulnérables, car elles n'ont jamais utilisé les versions affectées. Quand ils ont annoncé qu'ils avaient mis à niveau vers une nouvelle version d'OpenSSL, je m'assurerais qu'ils utilisent un nouveau certificat signé après la date de publication de l'exploit qui était 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 ultérieurement.

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

Pour les prochains jours, 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 suggère de le faire. Si vous devez le faire, comprenez que votre session est potentiellement à risque et soyez prêt à en accepter les conséquences. Aussi, après que les organisations ont annoncé qu'elles ne sont plus vulnérables, vous devriez changez votre mot de passe; L'utilisation d'un gestionnaire de mots de passe peut vous aider. Vous devez également vous préparer à modifier ou à surveiller toute autre information que vous avez utilisée, par exemple les coordonnées bancaires ou les numéros de carte de crédit.

Avis spécial aux militants

N'importe quoi 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 d'OpenSSL il y a plus de deux ans, car ils disposeraient des ressources considérables nécessaires pour rechercher de tels exploits. 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 ultérieurement, sauf si sécurité avant parfaite (PFS) a été mis 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, l'extraction des clés a été réussie.  À ce stade, on ne sait pas quel côté est correct.


201
2018-04-09 07:17



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


Le risque posé par cette vulnérabilité est en train d’être exagéré. Je le dis car il existe des preuves ZERO que cette vulnérabilité était connue ou exploitée avant sa publication par les chercheurs il y a 2 jours.

Soyons clairs, il est urgent que les sites Web vulnérables, en particulier ceux qui traitent des données sensibles sur Internet, soient corrigés. Il est tout aussi urgent que les signatures pour l'attaque soient chargées dans les outils de protection IDS et de logiciels malveillants. Au sein de l'informatique, nous devrions répondre à cette vulnérabilité avec la plus haute priorité.

Cela dit, je ne pense pas que le niveau de risque associé à cette vulnérabilité de la presse publique soit 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 prouve que cette vulnérabilité a été exploitée, toute autre action est inutile et motivée par rien de plus que FUD. Vous êtes en désaccord? Considérez les nombreuses vulnérabilités publiées chaque mois ou trimestre permettre l'exécution de code arbitraire. Celles qui donnent à l’attaquant des privilèges root ou au niveau du système ou lorsque l’attaquant peut les gagner par l’escalade 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 du logiciel ou par les chercheurs qui en informent le fournisseur. Le fournisseur produit un correctif et le publie sur le marché sans publication des 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 exagérée des chercheurs qui ont annoncé cette vulnérabilité et dans la presse, qui ont amplifié le discours lâche des chercheurs. Ils pleurent le loup.

- El viejo


14
2018-04-09 22:35



Cette réponse devrait être votée plus IMO. Il y a beaucoup des vulnérabilités publiées chaque mois, qui permettraient aux utilisateurs de voler les clés privées des serveurs, sans trop de problèmes. Celui-là est plus grave que la moyenne en raison de l'omniprésence d'OpenSSL, mais il est toujours surestimé. - alastair
"Jusqu'à et à moins qu'il y ait des preuves que cette vulnérabilité a été exploitée" "S'il existe des preuves d'exploitation, nous devons réagir de manière appropriée." Vous parlez beaucoup de preuves d'exploitation. Pourtant, l'une des choses effrayantes à propos du bug Heartbleed est que une exploitation réussie est indétectable après le fait (à moins que vous ne stockiez intégralement le message de pulsation entrant à chaque fois, et même dans ce cas, il n'est pas garanti qu'une exploitation réussie entraîne une violation de la sécurité). Comment proposez-vous d’établir après coup la preuve de l’exploitation réussie du bogue? - Michael Kjörling
-1 car cet auteur ne comprend pas vraiment la nature des attaques que je ne pense pas. D'une part, les attaquants qui avaient ce type d'accès travailleraient très dur pour garder le secret et ne permettraient pas que des preuves de leur intrusion soient publiées. Un bug de ce type qui réduit la sécurité d’environ la moitié du trafic sécurisé sur Internet n’est pas du tout un cri de loup. C'est une question très grave, je pense. - Eliptical View
Je tiens Bruce Schneier en haute estime en matière de sécurité informatique. Citer son blog sur la vulnérabilité Heartbleed: "Catastrophic" est le mot juste. Sur l'échelle de 1 à 10, ceci est un 11. Cela suffit pour que je sois tout à fait en désaccord avec votre minimisation du problème. - abstrask
Ce poste devrait être déclassé. Le problème N'EST PAS résolu, il s'agit d'une défaillance catastrophique d'OpenSSL. En outre, même s'il n'a été utilisé que publiquement, les mauvais joueurs ont définitivement compromis les sites. Il est également très probable que la NSA le sache (mais cela ne peut pas être prouvé). Il y a des théories convaincantes indiquant que cela constitue un compromis délibéré, même si l'auteur le nie. - davidgo


Tous les sites Web n'utilisent pas les bibliothèques OpenSSL pour HTTPS (il y a aussi GnuTLS et PolarSSL par exemple), et toutes les versions d'OpenSSL ne sont pas vulnérables (les anciennes versions ne l'étaient pas). Cela signifie qu'il y a de bonnes chances que les sites Web que vous avez mentionnés n'aient pas changé de certificat, car ils n'en avaient pas besoin. Il suffit de regarder les dates auxquelles les certificats ont été émis ne vous en dit pas assez.

Un certain nombre d'outils et de 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à dit, cela ne vous dit pas s'ils l'étaient. J'ai peur que le problème principal ici soit la confiance: il n'y a aucun moyen objectif de vérifier quelles bibliothèques SSL ils utilisent et utilisent sans informations internes. Il faut espérer qu’ils ont fait ce qu’ils doivent faire (parce que c’est la bonne chose, ou même parce qu’ils ont peur de l’humiliation publique) et s’ils le font, on ne peut qu’espérer qu’ils sont ouverts à ce sujet.

Bien sûr, vous pourriez toujours demander à ces sites Web s’ils étaient affectés, j’ai vu un certain nombre de sites Web émettant des déclarations publiques à ce sujet. Le fait d’utiliser publiquement les médias sociaux comme 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 à quels sites Web vous faites confiance avec vos informations personnelles.


5
2018-04-09 05:36



attend l'inévitable bug PolarSSL (il est suivant dans la liste ...) - strugee


En ce qui concerne les clés privées exposées, il est utile d’ajouter que, même si une personne peut déchiffrer des données dans une session chiffrée, étant donné qu’elles ont maintenant la clé privée, elles devront toujours s’établir comme l'homme au milieu de la session. Non seulement n'importe qui sur Internet peut le faire.

Je crois comprendre qu’ils devront toujours intercepter le trafic en se trouvant sur votre réseau local et ARP usurper ou être capable de détourner / rediriger le trafic en annonçant de fausses routes vers des routeurs Internet. Ces attaques ont toujours été possibles même sans cette vulnérabilité.


1
2018-04-10 04:34



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 / sniffer le trafic pour exploiter cette vulnérabilité. Cependant, des logiciels malveillants devraient être installés sur le serveur ou le client et un accès correct à la mémoire vive serait également nécessaire. - ub3rst4r
Pas si. Cela pourrait également être compromis par une attaque de type Man-In-The-Middle. De plus, 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 mots de passe non cryptés des autres utilisateurs, en plus des clés privées facilitant le décodage du trafic [via l'attaque MITM] - davidgo
Je suppose 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 l'application du patch au serveur. - PeterJ


Vous pouvez entrer l'URL d'un site à l'adresse Checker LastPass Heartbleed et il vous dira si le site était ou est toujours vulnérable et quand son certificat a été mis à jour.

Il y a aussi une extension Chrome appelée Chromebleed cela vous avertira si vous visitez un site affecté par Heartbleed.

Mashable.com a une liste de sites connus, 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é.


0
2018-04-11 20:23





Je voudrais aussi visiter le site suivant:

https://www.ivpn.net/blog/heartbleed-passwords-change

Ils ont une liste de sites populaires qui ont été touchés et quand et où vous devriez changer vos mots de passe


0
2018-04-13 12:39





Globalement, je dirais que ne laissez pas la paranoïa vous arriver. En réalité, le simple 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 réellement fait.

Si tu utilises authentification à deux facteurs (et vous devriez) sur des sites tels que Twitter, Facebook, Gmail et vos services bancaires, vous ne devriez pas être trop inquiet, et même si vous ne le faites pas, vous êtes probablement en règle.

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


-1
2018-04-09 05:05



L'authentification à deux facteurs n'empêchera pas une partie malveillante 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 ne concerne pas vraiment quelqu'un qui pourrait tirer parti de cet exploit dans OpenSSL. - Ramhound
@ramhound J'ai mentionné dans les commentaires avant que les commentaires ne soient supprimés, deux facteurs, car une fois qu'un nouveau certificat a été émis, tous les mots de passe qu'un attaquant pourrait avoir ne sont plus utiles. Comme il est inutile de modifier un mot de passe avant qu'un nouveau certificat ne soit émis (et que les serveurs soient corrigés), vous gagnez une ré-sécurisation instantanée du compte contre les éventuelles fuites d'informations d'identification pouvant survenir lorsque l'attaquant possède la clé privée. En outre, Twitter et Facebook sont importants car ils peuvent être utilisés comme connexion unique 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 personnes qui utilisent une authentification à deux facteurs. Tant que l'attaquant est capable de transférer les données de la session, il peut effectuer une attaque MiTM contre vous. - Ramhound
Oui, mais la réutilisation des mots de passe est un échec distinct. Mon point était que deux facteurs contribuaient à atténuer la gravité et la longévité de l’après-coup, mais oui, cela n’aiderait pas à exploiter un bogue réel. - Sirex
@Sirex Autant que je sache, aucun site sur lequel je me connecte à l'aide d'une authentification à deux facteurs n'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 sur leurs propres requêtes. De plus, comme 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 est qu'il a été exploité. Je sais par exemple que chase.com était encore vulnérable dès mercredi matin. Peu probable que les attaquants aient manqué celui-là. - CrazyCasta