Question:
Cloudbleed: est-il vraiment important de changer TOUS les mots de passe?
Andy Giesler
2017-02-26 02:56:47 UTC
view on stackexchange narkive permalink

En réponse aux révélations récentes de Google et Cloudflare sur la vulnérabilité Cloudbleed, certaines sources comme TNW recommandent aux gens de changer les mots de passe des sites et des services qui utilisent CloudFlare. Cela me semble une précaution raisonnable.

D'autres recommandent aux utilisateurs de changer tous les mots de passe, même pour les services qui n'utilisent pas Cloudflare . D'après ce que nous savons jusqu'à présent - certes au début de l'enquête - cela semble une réaction excessive.

Autant que je sache, la justification est la suivante:

  • Vous réutilisez probablement vos mots de passe, gros n00b. Une compromission de votre mot de passe affecté par Cloudbleed compromettra vos autres comptes.
  • Vous devriez quand même changer vos mots de passe de temps en temps. Arrêter de se plaindre. C'est bon pour vous.
  • La recherche dans une liste des sites concernés est vraiment difficile. Il est tellement plus facile de simplement changer tous vos mots de passe.

Je ne changerai pas tous mes mots de passe à la légère. Il y a plus de 400 sites dans mon gestionnaire de mots de passe et je ne réutilise pas les mots de passe. Rechercher quelques centaines de sites dans une liste, que ce soit sur Github ou Utilise-t-il Cloudflare, ne semble pas difficile comparé au temps fastidieux de les changer tous.

Jusqu'à présent, il semble que Cloudbleed ait occasionnellement causé la fuite des informations d'une page prise en charge par Cloudflare dans la sortie d'une autre page prise en charge par Cloudflare.

Est-ce que je manque quelque chose? Existe-t-il de bonnes raisons scientifiques de changer tous les mots de passe pour tous les sites et services, compte tenu de ce que nous savons jusqu'à présent (25 février 2017)? Ou est-ce une réponse de panique?

Quatre réponses:
Rápli András
2017-02-26 03:56:54 UTC
view on stackexchange narkive permalink

Alors que Miao convient au cas des mots de passe, cette vulnérabilité rend également les jetons oauth compromis. Si un site dépendant de Cloudflare utilise Oauth, vous devez effectuer une étape supplémentaire pour réinitialiser vos sessions dépendantes oauth sur le Web.

MiaoHatola
2017-02-26 03:45:26 UTC
view on stackexchange narkive permalink

Il n'y a aucune raison de modifier un autre mot de passe. Le seul scénario auquel je peux penser où cela peut être requis est le suivant:

Un attaquant apprend un mot de passe pour votre service de messagerie. Ensuite, il / elle utilise le service de messagerie compromis pour réinitialiser le mot de passe d'un service non CloudFlare.

Comme je n'ai pas trouvé de service de messagerie qui dépend de CloudFlare, ce scénario est donc peu probable, je Je suis certain que c'est une réponse de panique.

Alexander Block
2017-02-26 18:39:29 UTC
view on stackexchange narkive permalink

Honnêtement, je ne pense pas que les gens soient aussi gravement touchés que certains pourraient essayer de vous le faire croire. La probabilité que vos comptes soient affectés est proche de zéro.

Pour être concernés, plusieurs choses doivent s'être produites en même temps:

  1. Vous surfiez sur l'un des sites concernés.
  2. Un attaquant essayait en même temps de collecter des données privées en émettant autant de requêtes erronées que sa connexion et cloudflare le lui permettaient
  3. L'attaquant atterrit sur le même instances de proxy inverse par lesquelles vos requêtes étaient précédemment servies

Les trois choses doivent s'être déroulées à peu près au même moment. Au point 2., l'attaquant a peut-être collecté des données privées auprès de certains utilisateurs, mais la probabilité que vous soyez l'un d'entre eux est assez faible.

La raison pour laquelle cela a dû se produire en même temps est assez simple . Les instances proxy n'ont pas de mémoire illimitée et donc la mémoire est réutilisée très souvent. Ainsi, même si la mémoire proxy contenait des données sensibles de votre requête, l'une des requêtes suivantes des autres utilisateurs aurait écrasé ces données en raison de la réutilisation de la même mémoire.

Je suppose que l'instance proxy vous et l'attaquant utilisaient à ce moment-là dépendaient également de votre emplacement géographique et de celui des attaquants. Je n'ai jamais rien hébergé avec l'aide de cloudflare et n'ai jamais étudié le fonctionnement de leur équilibrage de charge, mais je suppose qu'ils essaient toujours de vous donner une instance de proxy qui donne les meilleures performances pour l'emplacement géographique particulier. Sur la base de cette hypothèse, je suppose que les attaquants étaient limités aux proxys au même endroit.

De plus, comme seules quelques demandes auraient contenu vos mots de passe (seules les demandes de connexion peut-être), la plupart ont fui les données sensibles n'auraient inclus que des jetons de session et des trucs comme ça. Ainsi, la probabilité que vos mots de passe soient divulgués diminue encore plus.

Point suivant: à partir de maintenant, il est supposé que le cloudbleed n'a pas été exploité avant la découverte et la fermeture du trou. On suppose que les données divulguées résident principalement dans les caches des moteurs de recherche (et probablement tout le reste sur Internet qui fait la mise en cache). Mais le nombre de requêtes avec des données divulguées par ces moteurs de recherche est assez faible par rapport aux requêtes nécessaires à un attaquant pour obtenir suffisamment de données sensibles et obtenir VOS données.

"L'attaquant a atterri sur les mêmes instances de proxy inverse par lesquelles vos demandes étaient précédemment servies" - ce point n'est pas valide, je crois.Cela équivaut à "même si l'attaquant a obtenu les informations de quelqu'un, ce n'est probablement pas vous".Eh bien, les données de _quelqu'un_ seront_ compromises, et il est impossible de dire si c'est vous ou non, nous devons donc nous protéger contre cette chance.De plus, l'attaquant n'est pas singulier et peut-être que chaque serveur a été gratté.
Si la demande des attaquants n'est pas servie par la même instance, comment pourrait-elle divulguer de la mémoire unifiée / libérée des demandes servies par d'autres instances?Il ne peut techniquement divulguer que des données de la même instance. Et bien sûr, les données de quelqu'un sont compromises, mais comme dit: la probabilité qu'il s'agisse de vos données est proche de zéro.C'est mauvais bien sûr, mais ce n'est pas aussi mauvais que cela puisse paraître.Il ne suffit pas de paniquer et de changer tous vos mots de passe, juste assez pour changer les plus sensibles.
Vous supposez qu'il y a un «attaquant» spécifique et une cible spécifique qui doivent entrer en collision sur un serveur pour que l'attaque puisse se produire.Ce n'est pas le cas ici.Il existe un nombre inconnu de bots qui ont consommé des données des serveurs Cloudflare, affectant des utilisateurs inconnus des sites clients Cloudflare.La probabilité qu'un attaquant spécifique soit servi par le même serveur que vous est sans importance car il peut y avoir eu des dizaines de robots différents sur chaque serveur.Vous devez supposer que * certains * bots ont définitivement des données du serveur sur lequel vous étiez.
En outre, la deuxième partie de votre argument est la suivante: "bien sûr, les données de quelqu'un sont compromises, mais la probabilité que ce soit vos données est proche de zéro."Ce n'est pas ainsi que fonctionne Infosec.S'il y a une fuite de mots de passe qui peuvent inclure le vôtre, la gravité de la perte de ces mots de passe peut être critique même si l'attaquant les rencontre avec une chance de 1/1000000.Vous évaluez donc pour vous l'importance des sites concernés, pas le risque de fuite.La seule partie où la probabilité entre en jeu ici est le nombre de demandes divulguées qui est en effet assez faible, ce qui est rassurant.
GAD3R
2017-02-27 01:23:03 UTC
view on stackexchange narkive permalink

Il y a quelques étapes à suivre:

  1. Effacez les données de votre navigateur et les cookies
  2. déconnectez-vous de tous les sites Web pour désactiver votre session
  3. Le Le site Web qui est affecté par la vulnérabilité cloud-bleed doit informer tous les utilisateurs de modifier leur mot de passe. Vous serez obligé de changer votre mot de passe.
  4. Configurez l'authentification à deux facteurs dès que possible


ⓘ
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...