Cloudbleed : importante fuite de données chez Cloudflare, changez vos mots de passe

Cloudbleed : importante fuite de données chez Cloudflare, changez vos mots de passe

Encore...

Avatar de l'auteur
Sébastien Gavois

Publié dans

Internet

24/02/2017 8 minutes
110

Cloudbleed : importante fuite de données chez Cloudflare, changez vos mots de passe

Victime d'un bug, Cloudflare a laissé fuiter des données personnelles, comprenant notamment des mots de passe. Tous les sites utilisant ce service peuvent être concernés et ils sont nombreux. Comme pour la faille Heartbleed, vous allez devoir changer vos mots de passe.

L'année 2017 débute sur les chapeaux de roues niveau faille de sécurité. En effet, Tavis Ormandy du Projet Zero de Google explique que Cloudflare a été victime d'une importante fuite de données, dont certaines ont été indexées par les moteurs de recherche, ce qui a été confirmé par le service.

Dans le lot, on retrouve des cookies, des jetons d'authentification, des requêtes HTTP et « d'autres données sensibles ». Un problème corrigé depuis quelques jours. Même si la probabilité que vous soyez concerné est faible, par sécurité vous allez devoir faire deux choses sur de nombreux sites et sur certaines applications :

  • Changer votre mot de passe
  • Vous déconnecter/reconnecter

Next INpact utilisant Cloudflare, il est préférable de le faire aussi sur notre site et dans nos applications. Si ce mot de passe était utilisé ailleurs, pensez à en changer. Nos lecteurs ont été avertis par email, et un billet de blog détaille la procédure à suivre.

Cloudflare, un point de centralisation d'Internet

Pour rappel, Cloudflare propose de nombreux services, dont un CDN (Content Delivery Network) qui est largement utilisé, notamment parce qu'il est accompagné de protections efficaces contre les attaques DDoS. Ses tarifs sont aussi plutôt raisonnables, avec une offre gratuite et une « Pro » dès 20 dollars par mois.

Cloudflare protège ainsi pas moins de 5,5 millions de domaines à travers le monde et devient un point de centralisation important. Il est d'ailleurs critiqué de manière récurrente pour cela, le problème du jour illlustrant parfaitement les craintes de ses détracteurs. Mais les solutions alternatives restent rares, et parfois assez spécifiques.

Google a par exemple mis à disposition des éditeurs de presse son propre CDN avec protection anti-DDoS : Shield. De quoi placer un peu plus le géant du web entre les médias et leurs lecteurs...

Que s'est-il passé ?

Parmi les outils proposés par Cloudflare, on retrouve un système d'analyse et de modification des pages HTML à la volée. Il est par exemple utilisé pour changer automatiquement des liens HTTP vers du HTTPS, ajouter des tags Google Analytics, masquer des adresses email, etc. Le cœur du problème se situe justement ici.

Pour modifier une page, Cloudflare a besoin de lire et d'analyser le code source de cette dernière. Pour cela, la société a développé un « parser » maison exploitant Ragel. Il y a un an, le fichier « .rl » contenant toutes les modifications à effectuer est devenu trop complexe, la société a donc développé un nouvel outil bien plus efficace, baptisé « cf-html ».

La migration s'est ensuite faite progressivement. Les deux sont implémentés comme des modules dans le serveur NGINX. Ils analysent chacun des blocs de mémoire à la recherche de morceaux de code HTML à modifier si besoin. 

À cause d'un dépassement de tampon (dû à une erreur de pointeur, les adeptes de C comprendront), le parser d'origine pouvait dans certaines circonstances accéder à des données se trouvant en mémoire vive alors qu'il n'aurait pas dû. Celles-ci se sont ensuite retrouvées dans le code HTML de la page et donc accessible à tout le monde sur Internet. Une histoire qui n'est pas sans rappeler le douloureux épisode Heartbleed, d'où le nom de « Cloudbleed » dans le cas présent.

Cloudflare indique que le bug était déjà présent depuis « des années » dans son module basé sur Ragel, mais qu'aucune fuite n'avait eu lieu en raison de la gestion des tampons internes de NGINX. Problème, l'arrivée de cf-hmtl a changé la donne, entrainant une fuite de données, même si cf-html n'est pas directement concerné.

Cloudflare précise qu'il s'agit bien d'une erreur de son côté, pas de Ragel. Tous les détails techniques sur les tenants et les aboutissants de cette histoire se trouvent par ici.

Quelles sont les informations qui ont pu être publiées ?

On y apprend notamment que des morceaux de requêtes HTTP de clients Cloudflare pouvaient se trouver dans la mémoire vive et qu'elles ont donc puis fuiter. Le détail de ce que l'on peut y trouver peut s'avérer assez compromettant (mais cela ne concerne pas les clefs privées SSL des clients) : 

  • Des morceaux de données POST, contenant éventuellement des mots de passe
  • Des réponses JSON d'une API
  • Des en-têtes HTTP
  • Des paramètres URI
  • Des cookies
  • Des clés API
  • Des jetons OAuth
  • Etc.

Les éditeurs de sites doivent aussi être relativement vigilants et mettre à jour leurs éléments de sécurité sans tarder. Comme le précise la société, tous les sites qui utilisent ses services sont potentiellement impactés. En effet, un site vulnérable « pourrait révéler des informations d'un autre site Cloudflare » puisque la brèche pioche des informations dans la mémoire vive du serveur, peu importe d'où elles proviennent.

Certains ont déjà commencé à communiquer sur le sujet, 1Password évoquant par exemple sa procédure de connexion pour indiquer ne pas être affecté par ce bug.

Cloudflare Cloudbleed
Crédits : Tavis Ormandy

Des conditions rares, une fuite sur 0,00003 % des requêtes

Mais il s'agit surtout de précautions, puisqu'il est difficile de savoir si l'on est concerné ou non. Pour qu'une fuite de donnée ait lieu, il faut réunir plusieurs éléments selon Cloudflare. Coté serveur, le dernier tampon de mémoire doit contenir un script ou une balise image mal formée, par exemple « <script type= », et il doit faire moins de 4 ko.

De son côté, le client doit avoir activé l'option d'obfuscation d'email (qui utilise à la fois le nouveau et l'ancien parser), ou bien Automatic HTTPS Rewrites/Server Side Excludes (qui utilise cf-html) en plus d'un service basé sur l'ancien parser.

D'après la société, ces conditions « expliquent pourquoi le dépassement de tampon résultant en une fuite de mémoire se produit si rarement » : environ une fois toutes les 3 300 000 requêtes HTTP, soit 0,00003 % du temps.

La première fuite pourrait remonter au 22 septembre de l'année dernière. Mais une montée en puissance a été constatée à partir du 13 février, car la réécriture de requêtes HTTP « n'est pas largement utilisée » et que Server-Side Excludes ne s'active que pour des IP jugées comme malveillantes :

  • 22 septembre 2016 : Automatic HTTP Rewrites en place
  • 30 janvier 2017 : Server-Side Excludes passe sur le nouveau parser 
  • 13 février 2017 : Email Obfuscation passe partiellement sur le nouveau parser
  • 18 février 2017 : Google informe Cloudflare qui met fin à la fuite des données

Nettoyage des moteurs de recherche et déroulement des événements

Si le faille a été corrigée il y a quelques jours, une partie des données s'est retrouvée dans la mémoire cache de moteurs de recherche comme Google. Cloudflare s'est donc assuré qu'elles avaient été supprimées avant de dévoiler publiquement cette fuite.

Au total, 770 URI de 161 domaines différents ont été purgées. Selon de premières investigations, aucune information n'a été mise en ligne sur des services comme Pastebin. Voici enfin le déroulement des principaux événements :

  • 18 février à 1h11 : Tweet de Tavis Ormandy
  • 18 février à 1h32 : Cloudflare reçoit les détails de Google
  • 18 février à 2h19 : Email Obfuscation est désactivé
  • 18 février à 5h24 : Automatic HTTPS Rewrites est désactivé
  • 20 février à 22h59 : Un correctif est déployé au niveau mondial
  • 21 février à 19h03 : Les fonctionnalités sont réactivées

On constate donc que la correction a été rapide. Si aucun service ne peut jamais prévenir toutes les attaques et autres fuites possible, c'est aussi sa réactivité qui peut faire la différence dans de pareils cas. Ici, Cloudflare a montré son sérieux, même si son image devrait souffrir de la situation.

Et maintenant, que faire ?

Au-delà de la fuite de données, la question est maintenant de savoir quelle attitude vous devez adopter en tant qu'internaute. Comme toujours en pareille situation, il est recommandé de changer a minima ses mots de passe pour l'ensemble des sites utilisant Cloudflare et de se déconnecter/reconnecter. Certains ont commencé à communiquer publiquement sur le sujet, mais attention, tout le monde ne sera pas forcément transparent.

Pour le reste, il faudra être prudent et surveiller ses différents comptes en ligne afin de détecter rapidement un éventuel problème. Pour rappel, vous pouvez utiliser un gestionnaire de mots de passe afin de les changer tous d'un coup, mais ces derniers utilisant parfois Cloudflare... pensez donc à changer aussi votre mot de passe maitre au passage.

De son côté, 1Password affirme qu'aucune donnée sensible n'a pu fuiter et qu'il n'est donc pas nécessaire de le changer. Le gestionnaire donnera plus de détails dans un second temps.

110

Écrit par Sébastien Gavois

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Cloudflare, un point de centralisation d'Internet

Que s'est-il passé ?

Quelles sont les informations qui ont pu être publiées ?

Des conditions rares, une fuite sur 0,00003 % des requêtes

Nettoyage des moteurs de recherche et déroulement des événements

Et maintenant, que faire ?

Commentaires (110)


Le site qui vérifie si un site passe par&nbsp; CloudFlare est-il fiable ?&nbsp; À l’instant il m’annonçait que NextInpact ne passait pas par CloudFlare http://www.doesitusecloudflare.com/?url=www.nextinpact.com ) :) (maintenant le site est tombé).


C’est la galère de savoir quel site utilise Cloudflare, j’espère que les sites impactés nous préviendront par mail :(


Je me faisais la même remarque…


Je me connecte par Google+, je dois faire quoi ?








tpeg5stan a écrit :



Je me connecte par Google+, je dois faire quoi ?





Je doute que l’API de GG+ donne accès aux identifiants aux sites tiers qui l’implémentent en guise d’identification. Ca doit être un token ou un cookie sans doute.





À cause d’un dépassement de tampon (dû à une erreur de pointeur, les adeptes de C comprendront)



Souvenirs souvenirs…&nbsp;<img data-src=" />








tpeg5stan a écrit :



Je me connecte par Google+, je dois faire quoi ?





Supprimer ton compte G+ <img data-src=" />



Déco/Reco pour changer la session, mais rien de plus pour le coup :) (au pire déconnecter/reconnecter Google+ mais je ne pense pas que ça fasse partie des infos potentiellement concernées)


Je me suis déconnecté et reconnecté.



C’est bon du coup ?



J’espère de tout cœur que personne n’est touché parmi vous en tout cas


Je la sentais venir…


Ca faisait longtemps… c’est pénible, franchement…


Le journal de bord tenu par le mec de Google qui a trouver cette faille est éloquent :https://bugs.chromium.org/p/project-zero/issues/detail?id=1139



Petit extrait qui m’a fait exploser de rire :

The examples we’re finding are so bad, I cancelled some weekend plans to go into the office on Sunday to help build some tools to cleanup. I’ve informed cloudflare what I’m working on. I’m finding private messages from major dating sites, full messages from a well-known chat service, online password manager data, frames from adult video sites, hotel bookings. We’re talking full https requests, client IP addresses, full responses, cookies, passwords, keys, data, everything.


C’est ça de faire appel à des presta extérieurs au lieu de tout faire soit même ^^


Humm

lié au compte google / g+ qui a redemandé une connexion ce matin ?





Sinon ,nextinpact a du mal à charger depuis 14h …








Papa Panda a écrit :



Humm

lié au compte google / g+ qui a redemandé une connexion ce matin ?





C’est très probable même si le mec de Google dit que non, pas à sa connaissance.









David_L a écrit :



Non





T’as des infos là dessus ? Car en toute logique, toute utilisation d’un compte google pour se connecter sur un site utilisant CloudFlare expose à la fuite d’un token valide. Après utiliser le token est pas forcément évident, mais ça reste une faille.



j’avais le même problème depuis 12h; c’est réglé depuis peu pour moi… et je n’ai pas compris d’où ça venait. Ca ne concernait que NXI.


Bin je ne crois pas au coïncidence …








Bejarid a écrit :



T’as des infos là dessus ? Car en toute logique, toute utilisation d’un compte google pour se connecter sur un site utilisant CloudFlare expose à la fuite d’un token valide. Après utiliser le token est pas forcément évident, mais ça reste une faille.





Le token en question n’est normalement pas ré-exploitable ailleurs.



En gros avec tous les sites qui utilisent cloudflare ça en fait dès mot de passe à changer pour certains.



😂


Bon ben ça tombe bien, j’avais des mots de passe à changer, on va faire mumuse avec LastPass… XD


tout dépend du site.

perso je vais pas changer mon pass ici.

aucun intérêt, il est unique.



si jamais vous voyez que je suis devenu fan d’Apple, ou que je défend la théorie de la terre plate, c’est que c’est pas moi. <img data-src=" />








matroska a écrit :



En gros avec tous les sites qui utilisent cloudflare ça en fait dès mot de passe à changer pour certains.





Et encore plus pour ceux qui font du multi-compte.



Tu as la liste sur github <img data-src=" />








ITWT a écrit :



Le token en question n’est normalement pas ré-exploitable ailleurs.





Tout à fait, mais quand une des deux couches de sécurité (protection du token lui-même) est tombé, on considère que la sécurité n’est plus fiable (c’est pour ça qu’un avion avec deux moteurs se pose dès qu’un des deux moteurs lâche : ce n’est pas un problème en soi, mais on a plus de filet de sécurité).



Et l’usurpation d’identité, c’est pas franchement si difficile vu le sérieux de certain fournisseur de certificat !



Un nslookup sur l’adresse IP du site te donnera la réponse :



&gt; nslookup nextinpact.com





  • 104.25.248.21

  • 104.25.249.21





    &gt; nslookup 104.25.248.21



  • primary name server = ns1.cloudflare.com







    Ou même encore plus simple, CLoudflare a eu la bonne idée de publier la liste des plages d’adresses IP qu’il gèrent :https://www.cloudflare.com/ips/

    Si l’adresse IP d’un site appartient à l’une de ces plages, c’est qu’il passe par Cloudflare.


Ce serait bien qu’un jour les composants de sécurité écrits en C soit vérifiés formellement. Ou plus écris en C. UN jour, peut être, s’il y a de l’argent.


J’ai eu l’info par un collègue dont le site qu’il gère utilise Cloudflare, et je viens de changer mon mot de passe NXI.&nbsp; Compte tenu de l’entreprise où je travaille, j’espère que l’on ne pourra pas me tracer à cause de ce genre de bug, bien que je ne poste que de chez moi, ou que d’un ordinateur personnel non relié à la connexion Internet de mon entreprise…









Ksass`Peuk a écrit :



Ce serait bien qu’un jour les composants de sécurité écrits en C soit vérifiés formellement. Ou plus écris en C. UN jour, peut être, s’il y a de l’argent.





Figures-toi que c’est la première chose que je vérifie dans le code des logiciels que je met en production pour mon entreprise.



Mais après, je ne peux pas tout voir, bien que cela m’ait évité pas mal de mauvaises surprises… et permis de remonter quelques bugs aux développeurs !









ActionFighter a écrit :



Et encore plus pour ceux qui font du multi-compte.







Là, je suis tranquille, je vais y passer l’après-midi pour tout changer !



<img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" />



Attention, utiliser les DNS CloudFlare n’implique pas forcément que le site utilise le CDN à ma connaissance <img data-src=" />


Excellent, merci <img data-src=" />








Commentaire_supprime a écrit :



Là, je suis tranquille, je vais y passer l’après-midi pour tout changer !



<img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" />





Oublie pas ton compte tmtisfree, ce serait con qu’il se mette à diffuser des propos collectivistes <img data-src=" />









ActionFighter a écrit :



Oublie pas ton compte tmtisfree, ce serait con qu’il se mette à diffuser des propos collectivistes <img data-src=" />







J’ai aussi le compte Masterdav à modifier en prio, surtout depuis que ledufakademy a été défacé par les modos. Manquerait plus qu’il trouve Mélenchon tout à fait potable, celui-là.



Je ne sais pas si on parle de la même chose quand j’écris “formellement vérifié”. Cela ne court définitivement pas les rues les systèmes de ce genre (malheureusement).








Commentaire_supprime a écrit :



J’ai aussi le compte Masterdav à modifier en prio, surtout depuis que ledufakademy a été défacé par les modos. Manquerait plus qu’il trouve Mélenchon tout à fait potable, celui-là.





hein ??









hellmut a écrit :



si jamais vous voyez que je suis devenu fan d’Apple, ou que je défend la théorie de la terre plate, c’est que c’est pas moi. <img data-src=" />



Et pourtant, des membres de la société de la Terre plate, il y en a sur tout le globe… <img data-src=" />









Ksass`Peuk a écrit :



Je ne sais pas si on parle de la même chose quand j’écris “formellement vérifié”. Cela ne court définitivement pas les rues les systèmes de ce genre (malheureusement).





Je vérifie a minima le fonctionnement du logiciel sur un serveur de test configuré comme deux de production en lui faisant subir toutes les avanies possibles, et je vois comment il réagit.



&nbsp;C’est déjà suffisant pour voir les plus gros problèmes. Après, j’audite le code dans la limite de mes capacités pour écrémer ce que j’ai pu rater. C’est pas miraculeux mais c’est toujours une bonne précaution à prendre.

&nbsp;

&nbsp;









darkbeast a écrit :



hein ??







J’ai aussi Dackiller, macmc et keskildi comme multi-compte.



elpetio, je me le suis fait sucrer par les modos, dommage…









Torre Torinese a écrit :



Mais après, je ne peux pas tout voir, bien que cela m’ait évité pas mal de mauvaises surprises… et permis de remonter quelques bugs aux développeurs !





Je crains que tu n’es pas saisi la signification du “formellement”.



Ici, ça veut dire que c’est vérifié via un logiciel, qui prouve mathématiquement l’exactitude de l’algo écrit.



Le fait même d’utiliser un être humain pour vérifier quelque chose inclue une part d’erreur.



Quand je parle de vérification formelle de composants de sécurité, je pense plutôt à des trucs comme ça :





Ils disent que le https n’est pas impacté.








John Shaft a écrit :



Tu as la liste sur github <img data-src=" />





nextinpact n’y est pas =&gt; FAKENEWS!!

<img data-src=" />



Il ne sont pas dans la liste montrée sur la page Github. Ce qu’il faut regarder c’est le contenu du fichier, qui est LARGEMENT plus conséquent.








John Shaft a écrit :



Tu as la liste sur github <img data-src=" />





J’ai retranscris en bash leur méthodologie avec les url d’une archive keepass, si ça peut servir:

&nbsphttps://wiki.xanatos.net/doku.php?id=dev:scripts:cloudbleed_check



oui je m’en doute, jsuis au taf jpeux pas choper le fichier. ^^








Bejarid a écrit :



Je crains que tu n’es pas saisi la signification du “formellement”.



Ici, ça veut dire que c’est vérifié via un logiciel, qui prouve mathématiquement l’exactitude de l’algo écrit.



Le fait même d’utiliser un être humain pour vérifier quelque chose inclue une part d’erreur.









Ksass`Peuk a écrit :



Quand je parle de vérification formelle de composants de sécurité, je pense plutôt à des trucs comme ça :

https://eprint.iacr.org/2016/846.pdfhttps://people.csail.mit.edu/nickolai/papers/chong-nsf-sfm.pdfBref, quelque chose de très amont, qui donne des garanties très fortes en terme de sûreté et de sécurité, mais qui demande une débauche de temps et de moyens assez conséquente.





Dans ce sens-là, oui, je ne fais pas une vérification formelle, je suis d’accord avec vous deux.



Outre que cela dépasse mes capacités, parce que ce n’est pas mon métier, il va de soi que je ne peux pas mobiliser les moyens nécessaires pour faire une vérifiaction aussi poussée.



Disons plutôt que je fais une vérification de fonctionnement en conditions réelles avant mise en production.



Si le serveur DNS contacté pour résoudre l’adresse IP du site appartient à Cloudflare, si.








Obidoub a écrit :



Ils disent que le https n’est pas impacté.





Je sais pas qui c’est “ils”, mais ce que je sais c’est que pour le chercheur chez Google qui a passé son WE dernier à travailler sur cette faille, les informations fournis pour CloudFlare c’est du pure bullshit.







  • Non, la faille ne concerne pas que quelques rares clients, car CF fait du multi-tenant, donc mêmes les sites qui n’ont pas activé les fonctions bugué peuvent-être être touchés

  • Non, la faille n’est pas active que depuis quelques jours (le 13 février pour CF), de nombreux exemples de cache de google datant de l’année dernière contenaient le bug (donc le 22 septembre est plus probable, soit 5 MOIS !)

  • Non, la faille ne touche probablement pas que 0,000003% des requetes, de fait CF a sorti ce chiffre de son chapeau via une règle de 3 basé sur des chiffres absolument pas fiable.





    Pour le coup l’article de NXi aurait pu faire plus que reprendre le communiqué de presse de CloudFlare.



Changer son mot de passe comme précaution élémentaire.



Il ne me reste plus qu’à trouver un dialogue de Hentaï que je peux retenir sans trop de difficultés…



<img data-src=" />








Torre Torinese a écrit :



Dans ce sens-là, oui, je ne fais pas une vérification formelle, je suis d’accord avec vous deux.



Outre que cela dépasse mes capacités, parce que ce n’est pas mon métier, il va de soi que je ne peux pas mobiliser les moyens nécessaires pour faire une vérifiaction aussi poussée.



Disons plutôt que je fais une vérification de fonctionnement en conditions réelles avant mise en production.





Ouais, tu fais de la QA quoi. Rien qui n’empêchera de nouveau bug de sécurité obligeant tout le monde à renouveler l’ensemble de ses mots de passes <img data-src=" />



J’ai envoyé ce lien à un collègue qui m’avait conseillé 1password comme solution pratique pour mes X mots de passe sur le web…



J’ai bien fait de ne pas suivre son conseil à ce que je vois.








Bejarid a écrit :



Je sais pas qui c’est “ils”, mais ce que je sais c’est que pour le chercheur chez Google qui a passé son WE dernier à travailler sur cette faille, les informations fournis pour CloudFlare c’est du pure bullshit.



Non, la faille ne concerne pas que quelques rares clients, car CF fait du multi-tenant, donc mêmes les sites qui n’ont pas activé les fonctions bugué peuvent-être être touchés&gt;&gt;&gt; On le dit



&nbsp;Non, la faille n’est pas active que depuis quelques jours (le 13 février pour CF), de nombreux exemples de cache de google datant de l’année dernière contenaient le bug (donc le 22 septembre est plus probable, soit 5 MOIS !)&gt;&gt;&gt; On le dit



&nbsp;Non, la faille ne touche probablement pas que 0,000003% des requetes, de fait CF a sorti ce chiffre de son chapeau via une règle de 3 basé sur des chiffres absolument pas fiable. &gt;&gt;&gt; Tu as un élément concret pour avancer ça ?

&nbsp;

Pour le coup l’article de NXi aurait pu faire plus que reprendre le communiqué de presse de CloudFlare.





Pour le coup, lire les actus ça aide <img data-src=" />



1Password indique ne pas être concerné du fait de sa procédure de connexion, comme évoqué dans l’article <img data-src=" />








Railblue a écrit :



J’ai envoyé ce lien à un collègue qui m’avait conseillé 1password comme solution pratique pour mes X mots de passe sur le web…



J’ai bien fait de ne pas suivre son conseil lire l’article à ce que je vois.



<img data-src=" />



Dans l’article il est bien&nbsp;précisé que la faille pourrait être active depuis le 22 septembre (en fait elle l’est bien)



Tout est expliqué dans le lien&nbsp;du tweet de Tavis Ormandy, lui aussi intégré dans l’article.



EDIT : bon ben grilled.


Un pirate propose toutes les infos piratées pour: 29.99€ … sik

&nbsp;


Pour le coup, votre “Etc.” n’est pas assez alarmant.

La page du Projet Zero montre que tout type de contenu sort.

La panique n’est pas cool mais l’inaction encore moins.


Va falloir que je change mon mot de passe sur t411.li nextinpact.com. Bon aller ce soir on va faire chauffer keepass et changer tous les password ! Au lieu de regarder TF1 … <img data-src=" />


De toute façon, le HTTPS c’est chiffré non?&nbsp;

Donc aucun risque.&nbsp;


SI car Cloudflare déchiffre la connexion pour pouvoir la traiter puis la rechiffre.








synclinal a écrit :



Un pirate propose toutes les infos piratées pour: 29.99€ … sik

&nbsp;





Tu t’es trompé d’onglet non?&nbsp;<img data-src=" />



Un “txt” de 68 Mo!!!








David_L a écrit :



Pour le coup, lire les actus ça aide <img data-src=" />






Je parlais du fait que vous ayez repris certaines parties sans nuance (comme le %) alors que d'autres étaient manifestement très édulcoré (ils ne présentent pas la date de 13 février comme une monté en puissance mais comme la seule date où la faille a réellement pu se produire, alors que non, y a v'la les pages entière de mémoire qu'on fuité avant).     





Désolé si c’était pas clair, mais cet article reste trop basé sur les infos de CF, alors qu’ils n’ont pas joué franc jeu et minimisent les conséquences (ce n’est pas moi qui le dit, c’est celui que vous citez qui le dit).









hellmut a écrit :



nextinpact n’y est pas =&gt; FAKENEWS!!

<img data-src=" />





La liste ne contient que les sites importants <img data-src=" />



Blague à part NextInpact est placé à la 12,453ème place donc il loupe la liste des 10k&nbsp;http://siterank.top/siteinfo/nextinpact.com

Peut être pour la prochaine fois…









Bejarid a écrit :



Je parlais du fait que vous ayez repris certaines parties sans nuance (comme le %) alors que d’autres étaient manifestement très édulcoré (ils ne présentent pas la date de 13 février comme une monté en puissance mais comme la seule date où la faille a réellement pu se produire, alors que non, y a v’la les pages entière de mémoire qu’on fuité avant).&nbsp;



Désolé si c’était pas clair, mais cet article reste trop basé sur les infos de CF, alors qu’ils n’ont pas joué franc jeu et minimisent les conséquences (ce n’est pas moi qui le dit, c’est celui que vous citez qui le dit).





Faux, ils disent bien que ça date d’avant. Reprenons leur phrase au sujet du 13 février :



&nbsp;      

"The greatest period of impact was from February 13 and February 18 with around 1 in every 3,300,000 HTTP requests through Cloudflare potentially resulting in memory leakage (that’s about 0.00003% of requests)."






Si tu as bien lu, tu auras vu le mot "greatest" qui signifie "le plus gros". On peut donc traduire par "La période où l'on a eu le plus de cas fut celle allant du 13 au 18 février", ce qui implique donc que ça a commencé avant. Donc non, ils ne disent pas que ça a commencé là. Plus loin, on peut aussi lire :      

&nbsp;

"The three features implicated were rolled out as follows. The earliest date memory could have leaked is 2016-09-22."

&nbsp;

Donc ils savent que ça date au maximum de là. (avec 5 lignes + loin le retour &nbsp;du "greatest impact" du 13 février).






Maintenant, que dit l'article de NXi ?      

&nbsp;

"La première fuite pourrait remonter au 22 septembre de l'année dernière. Mais une montée en puissance a été constatée à partir du 13 février"






Le tout est suivi des 4 lancements comme dans l'article de CloudFlare.      






En résumé, lis avant de parler la prochaine fois&nbsp;<img data-src=">


J’ai pas encore fini ma migration sur 1password tellement c’est chiant (heureusement qu’il n’est pas INpacté). Ça devient vraiment agaçant à la longue. Va falloir trouver autre chose pour le futur parce que ça part vraiment n’importe comment.


Marant, moi aussi j’ai du me reconnecter ce matin sur mon compte google (android).. Idem, j’aurais aimé avoir la raison.


J’ai bien commencé par lire le communiqué de CF (avant que NXi n’ait publié son article) et leur présentation, qui ne donne qu’un chiffre à la seconde période, et aucun à la première est clairement trompeur. Pour le coup, NXi ne s’est pas permis de faire la même manipulation. Notons également que le communiqué utilise un superlatif, ce que ne fait pas NXi.




 Donc oui, j'ai bien lu les deux, et oui, les chiffres et les mots employés ont un poids. Surtout les chiffres, dénoncé par Tavis. Désolé si ta lecture ne sait aller au delà de la rhétorique, et à varier ses sources pour boucher les trous dans l'analyse de la situation.

Il est joli ton edit, sauf que j’ai vu le message initial. Donc si monsieur est meilleur que moi, je vais le laisser se pavaner seul.<img data-src=" />



Bon, grâce à LastPass, j’ai changé pas mal de MDP, il m’en reste sur des sites…pas conseillés au boulot&nbsp;<img data-src=" />








_Quentin_ a écrit :



Marant, moi aussi j’ai du me reconnecter ce matin sur mon compte google (android).. Idem, j’aurais aimé avoir la raison.







Ca m’est arrivé pour 2 de mes 5 comptes avant-hier

Rien pour les 3 autres

Ca devait être aléatoire et non lié à cette histoire





Nos lecteurs ont été avertis par email





Tous ? Moi j’ai rien reçu. Vous ne m’aimez pas <img data-src=" />








Ricard a écrit :



Souvenirs souvenirs… <img data-src=" />





Comme il est souvent dit : un dépassement de tampon, c’est quelque chose de mauvais, c’est souvent du à la mauvaise utilisation de string.



Pour savoir si un site utilise cloudflare tapez le nom de domaine suivi de&nbsp; /cdn-cgi/trace



exemple:http://www.nextinpact.com/cdn-cgi/trace








jackjack2 a écrit :



Ca m’est arrivé pour 2 de mes 5 comptes avant-hier

Rien pour les 3 autres

Ca devait être aléatoire et non lié à cette histoire









Google ont leur propre data center… et assez pour ne pas avoir besoin d’une société de presta. Les CDN comme cloudflare ou akamai c’est bien pour les “petits”, quand tu t’appelles google ou microsoft ou amazon et que tu as des data centers partout sur la planète, l’intérêt est assez limité….









jphilip a écrit :



Pour savoir si un site utilise cloudflare tapez le nom de domaine suivi de  /cdn-cgi/trace



exemple:http://www.nextinpact.com/cdn-cgi/trace









Tous les sites utilisant cloudflare ne sont pas touchés, bien heureusement !



Seuls les sites ayant fait le choix de faire transiter les données sensibles par cloudflare le sont, ceux qui utilisent uniquement la fonction primaire de cloudflare (à savoir du CDN) ne le sont pas.



Pour le savoir, il suffit de récupérer les URLs de login et de faire un ping sur l’host. Si la réponse est quelquechose.cloudapp alors il faut changer…



J’ai reçu des alertes de la part de plateformes de trading de crypto-monnaies. Rien de la part des autres.








Fuinril a écrit :



Google ont leur propre data center… et assez pour ne pas avoir besoin d’une société de presta. Les CDN comme cloudflare ou akamai c’est bien pour les “petits”, quand tu t’appelles google ou microsoft ou amazon et que tu as des data centers partout sur la planète, l’intérêt est assez limité….







Azure cloud utilise (entre autres) Akamai CDN.

De mémoire, il me semble qu’Apple et FB sont aussi clients, pour la partie web.









ITWT a écrit :



Azure cloud utilise (entre autres) Akamai CDN.

De mémoire, il me semble qu’Apple et FB sont aussi clients, pour la partie web.







Non non non, il ne faut pas tout confondre !



Azure et akamai ont un partenariat qui permet aux client d’intégrer facilement un CDN (Azur CDN) à leurs solutions. Microsoft eux même n’utilisent pas akamai !



Facebook n’utilise pas de CDN externe (du moins pas en frontal).



Apple aucune idée mais j’ai quelques doutes…



Ah oui tout à fait. Moi je mets 123456 partout. Non je déconne.



<img data-src=" />


MDR !



Et si tu deviens socialiste ? Ou pire Mélanchon ! On demandera ton exécution sur la place publique.



<img data-src=" />&nbsp;<img data-src=" />&nbsp;<img data-src=" />&nbsp;<img data-src=" />








Fuinril a écrit :



Non non non, il ne faut pas tout confondre !



&nbsphttps://www.akamai.com/us/en/our-customers.jsp



MSN (donc Microsoft) utilise Akamai à minima pour les flux vidéo.



Apple et Adobe utilisent Akamai pour la diffusion des programmes applicatifs, vidéo…



http://www.doesitusecloudflare.com









jackjack2 a écrit :



Ca m’est arrivé pour 2 de mes 5 comptes avant-hier&nbsp;

Rien pour les 3 autres&nbsp;

Ca devait être aléatoire et non lié à cette histoire



&nbsp;

ça arrive que pour les gens qui utilisent le même mot de passe sur plusieurs services google. Si vous avez des mails c’est que votre sécurité laisse a désirer.



1 mot de passe différent pour chaque ou il y a des informations sensibles.

&nbsp;

&nbsp;

Sinon un T-Shirt et 1an de Cloudflare Pro pour trouver des bugs et failles, LOOOOOOOOOOL.



C’est bien triste. (je suppose que) Vous sécurisez correctement les mots de passe des utilisateurs, et c’est finalement un service tiers qui en fait fuiter une partie. C’est biensûr sa faute, mais vous êtes aussi responsables de l’utiliser et par extension de fragiliser la sécurité de nos données.

Moralité : comptez-vous continuer avec Cloudfare (ou n’importe quel autre service de cache tiers) ? Car au final ce sont les utilisateurs qui trinquent.








Ricard a écrit :



Souvenirs souvenirs…&nbsp;<img data-src=" />





<img data-src=" />



Il y a vraiment des gens pour utiliser 1password &co ?

Tout ses mot de passe au même endroit et en ligne ???????????????????????????? &nbsp;ça va pas la tête ??????????



Sinon ça devient fatiguant de changer tous les 3-4 mois ses passwords à cause de l’incompétence de ces gens (Sony, CloudFlare, etc…) qui ont systématiquement des leaks/hacks. Le pire c’est que certains c’est leur métier premier la sécurité…








bilbonsacquet a écrit :



&#160https://www.akamai.com/us/en/our-customers.jsp



MSN (donc Microsoft) utilise Akamai à minima pour les flux vidéo.



Apple et Adobe utilisent Akamai pour la diffusion des programmes applicatifs, vidéo…







Ca reste très restreint comme usage à l’échelle des services des sociétés en question, mais effectivement.









k4ne a écrit :



Il y a vraiment des gens pour utiliser 1password &co ?

Tout ses mot de passe au même endroit et en ligne ????????????????????????????  ça va pas la tête ??????????



Sinon ça devient fatiguant de changer tous les 3-4 mois ses passwords à cause de l’incompétence de ces gens (Sony, CloudFlare, etc…) qui ont systématiquement des leaks/hacks. Le pire c’est que certains c’est leur métier premier la sécurité…







La sécurité absolue n’existe pas. Bienvenue dans l’informatique.



D’où l’intérêt de ne rien centraliser….









grosbidule a écrit :



C’est bien triste. (je suppose que) Vous sécurisez correctement les mots de passe des utilisateurs, et c’est finalement un service tiers qui en fait fuiter une partie. C’est biensûr sa faute, mais vous êtes aussi responsables de l’utiliser et par extension de fragiliser la sécurité de nos données.

Moralité : comptez-vous continuer avec Cloudfare (ou n’importe quel autre service de cache tiers) ? Car au final ce sont les utilisateurs qui trinquent.







C’est un bug extrêmement mineur de cloudflare. Il n’y a aucun intérêt à utiliser ce genre de service (reverse proxy, pas le CDN qui lui en a) pour un site comme nxi, c’est de la faute de nxi et de tous les autres qui l’utilisent !



D’ailleurs j’ai regardé il y a quelques mois et la partie login / mot de passe de nxi était directement pluguée sur Azur quand le contenu était servi par cloudflare. Pourquoi ils ont changé ça me dépasse…



Vous devriez abandonner CloudFlare s’ils ont des problèmes de sécurité surtout que CloudFlare est un service assez inefficace ! Quand j’ai le message qui indique que le site est impossible l’option qui permet de voir quand même le contenu grâce à CloudFlare ne marche quasiment jamais.








tazvld a écrit :



Comme il est souvent dit : un dépassement de tampon, c’est quelque chose de mauvais, c’est souvent du à la mauvaise utilisation de string.





<img data-src=" />









Fuinril a écrit :



Non non non, il ne faut pas tout confondre !



Azure et akamai ont un partenariat qui permet aux client d’intégrer facilement un CDN (Azur CDN) à leurs solutions. Microsoft eux même n’utilisent pas akamai !



Facebook n’utilise pas de CDN externe (du moins pas en frontal).



Apple aucune idée mais j’ai quelques doutes…





Facebook, jusqu’en 2015, on trouve des articles montrant qu’akamai est utilisé. Ils ont sans doute migré sur des solutions maison suite à la polémique de 2014.



Apple :http://appleinsider.com/articles/16/02/10/apples-in-house-cdn-efforts-spell-trou…



CloudFlare c’est juste un MITM&nbsp;<img data-src=" />








Fuinril a écrit :



La sécurité absolue n’existe pas. Bienvenue dans l’informatique.



D’où l’intérêt de ne rien centraliser….





Et n’existera jamais&nbsp;<img data-src=" />



Je pense que beaucoup de gens/webmaster l’utilise parce que tu te fais un HTTPS gratos sans aucune config (pas comme let’s encrypt). Bon c’est : internaute-&gt;CF en HTTPS après… c’est plus nébuleux…



Et ils pensent à tort ou à raison je ne sais pas, que ça “protège” leur site contre des attaques ou autre. C’est tellement simple à utiliser et configurer que je peux comprendre le choix d’utiliser cloudflare.



Perso je ne l’utilise pas pour mes clients, et certainement pas pour du reverse proxy. Après pour la partie CDN, je ne sais pas, jamais eu à gérer un tel cas je testerait celui de OVH, quelqu’un sait si ça vaut le coup/coût ?


env. 4 300 000 lignes, forcément. Pis comparé à certains fichiers de logs que peuvent cracher des serveurs <img data-src=" />


Heureusement que le TES est hautement sécurisé








Also_Spracht_Wapdoowap a écrit :



Changer son mot de passe comme précaution élémentaire.



Il ne me reste plus qu’à trouver un dialogue de Hentaï que je peux retenir sans trop de difficultés…



<img data-src=" />







“Yamete_onii-san”



fait chier bordel <img data-src=" />


Okay pour NextInpact mais après vérifier tous les autres sites… Teeeeellleeeement la flemme, c’est pas envisageable ça tant pis pour moi !


Pour le moment je suis “à l’ancienne” avec mes mots de passe dans un fichier txt dans un zip protégé par un gros mot de passe. J’ai également le fichier sur mobile comme ça je me peut aussi me connecter à n’importe quel site et si je doit changer tout mes passes je vais en avoir pour des heures :/ D’ailleurs merci au mobiles de ne pas proposer une “croix de direction” ce qui m’oblige à chosir des passes “simple”. :(



ps : Pour avoir exploité la faille heartbleed, il faut avoir vraiment beaucoup de temps pour arriver à extraire des informations “intéressantes”, la majorité du temps c’est des bout de html et css qui sortaient.


Hier Paypal m’a expressément demander de changer mon mot de passe suite à une tentative d’accès jugée suspecte. J’utilise le même depuis des années mais maintenant il fallait vraiment le changer.


N’empêche qu’un débordement de tampon c’est dégoûtant. Rien que le nom déjà…



Personne l’a faite ?



<img data-src=" />


Ça devient lourd tout ça.

J’attends la news TESbleed avec INpatience…


J’avais même pas vu et c’est hideux ! Bravo !



<img data-src=" />&nbsp;<img data-src=" />&nbsp;<img data-src=" />








Fuinril a écrit :



Google ont leur propre data center… et assez pour ne pas avoir besoin d’une société de presta. Les CDN comme cloudflare ou akamai c’est bien pour les “petits”, quand tu t’appelles google ou microsoft ou amazon et que tu as des data centers partout sur la planète, l’intérêt est assez limité….





Oui mais quand ton compte Google est utilisé pour t’identifier sur des sites comme NextInpact suivant comment c’est géré côté site tiers peut-être que quelque chose a pu fuiter

Par exemple les 2 que j’ai du reconnecter sont les 2 seuls que j’ai lié à d’autres sites

Après j’en sais rien, tu as l’air bien mieux renseigné que moi…









nick_t a écrit :



Ça devient lourd tout ça.&nbsp;

&nbsp;J’attends la news TESbleed avec INpatience…



Moi aussi, et avant que j’ai à refaire ma carte d’identité de préférence…









k4ne a écrit :



&nbsp; &nbsp;

ça arrive que pour les gens qui utilisent le même mot de passe sur plusieurs services google. Si vous avez des mails c’est que votre sécurité laisse a désirer.

&nbsp;&nbsp;





&nbsp;

Qu’est ce que tu racontes ??????

Il me semble que c’est le principe, Google te fournit un “SSO” pour accéder à tous ses services.



Bon de mieux en mieux après le compte paypal, i l y a eu hier une tentative de récupération de mon compte apple que je n’utilise plus depuis des années.