(modifié le 24 février 2017 à 15:25)

Après HeartBleed c'est sa cousine CloudBleed qui fait surface, trouvée par Tavis Ormandy.

CloudFlare a communiqué le 23 février sur son blog mais Google est un peu plus précis. La faille était active le 13/02 puis découverte et corrigée le 18/02. L'équipe CloudFlare a attendu que les résultats en cache des différents moteurs de recherche contenant des fuites de données soit supprimées.

Le 13 février dernier 1 requête HTTP sur 3 300 300 aurait été interceptée, cela peut sembler anodin mais CloudFlare "protège" de nombreux sites sur le web.

D'après Numerama :

La compagnie explique que cette diffusion incontrôlée a été la conséquence d’un dépassement de tampon provoqué par une erreur dans le code qui été généré par l’analyseur syntaxique Ragel que la société utilisait auparavant pour le compiler. Selon Cloudflare,ce bug était présent dans le code produit par Ragel depuis des années mais n’a été découvert qu’au moment de passer à un autre analyseur syntaxique, cf-html, une décision qui « a changé subtilement le tampon » et entraîné la fuite, « même s’il n’y avait pas de problèmes dans cf-html lui-même ».

Relativisons tout de même car contrairement à Heartbleed il n'était pas possible d'exploiter la faille de façon automatisée, certaines conditions devant être réunies sur les services souscris auprès de CloudFlare : e-mail obfuscation, server-side excludes, et Automatic HTTPS Rewrites. Cela provoquait une fuite de données aléatoires dans certaines réponses HTTP. Aucune fuite des clés de sécurité n'est à déplorer.

Une liste non exhaustive des sites potentiellement impactés est disponible ici (merci @thesquashsh). On ne peut pas véritablement savoir quels sont les sites impactés, ceux qui étaient visibles des moteurs... alors il est difficile de parler de catastrophe. CloudFlare a directement informé les sites impactés, mais ceux-si ne vont pas le crier haut et fort.

Mais il faut juste qu'on m'explique un truc. Pourquoi tout ces gens utilisent CloudFlare ? Si on élimine ceux qui ne voulaient pas se payer un certificat SSL, que foutent les autres ? Je veux dire que tout le monde n'est pas visé par des attaques DDOS régulières, il faut être particulièrement important pour être ciblé régulièrement. Et si c'est le cas vous avez le budget pour vous protéger derrière du arbor et cie. Bon peut-être CloudFlare propose un panel de services intéressants, mais il y a une belle partie qui ne payent pas et se contentent de livrer leurs données.

La centralisation excessive continue donc, même chez ceux qui sont parfaitement conscient des risques. A quoi bon donner tout son traffic et les données personnelles qui circulent à l'intérieur chez CloudFlare ? C'est le même principe que la boite noire, sauf qu'elle est orange.

De mon côté je n'ai jamais confié BM à CF, premièrement parce que je veux garder la main sur ma zone DNS qui est au chaud chez web4all. Deuxièmement je n'ai pas envie que tout transite chez CF (y compris les mots de passe) et enfin je ne souhaite pas être victime d'indispo en cas d'attaque chez CloudFlare, combien de sites seraient concernés ?

Conclusion

Pourquoi ne pas saisir cette belle opportunité pour changer les mots de passes des services sensibles ? Cela fait bien longtemps que vous ne l'avez pas fait, alors c'est le bon moment 🙂

Auteur : Mr Xhark

Fondateur du blog et passionné par les nouvelles techno, suivez-moi sur twitter