Brian Jackson - Fotolia
Quand Cloudflare laissait s’échapper des données sensibles
Le bogue qui affectait Cloudflare a été corrigé. Il a provoqué la fuite de données sensibles et plusieurs clients du réseau de distribution de contenus ont prévenu leurs utilisateurs finaux, leur recommandant de changer leurs mots de passe.
Les équipes du Projet Zéro de Google ont découvert un grave bug au sein de l’infrastructure de Cloudflare. Il exposait les données privées d’internautes utilisateurs des millions de sites hébergés sur le réseau de distribution de contenus (CDN).
Cette exposition était le résultat d'une fuite de mémoire causée par une interaction à l’implémentation malheureuse entre un ancien analyseur HTML et un autre que Cloudflare a commencé à utiliser en septembre dernier. Le CDN, qui a corrigé le bogue, a déclaré dans son rapport d'incident que seulement environ une sur 3.3 millions de requêtes de HTTPS serait susceptible d’avoir exposé des informations sensibles d’internautes, y compris des informations personnelles, des mots de passe, des cookies et des jetons de session.
Reste que le bogue, qui a été initialement découvert par le chercheur du projet zéro de Google Tavis Ormandy, a mis des informations sensibles à la disposition de quiconque opérant robot d’indexation Web sur les sites distribués par le CDN de Cloudflare… depuis septembre dernier. Dès lors, les données d’internautes ayant transité via le CDN entre le 22 septembre 2016 et le 17 février 2017 sont susceptibles d’avoir été exposées à des tiers. Mais il reste difficile de savoir combien d’internautes et de sites Web sont effectivement concernés.
« Cette situation était inhabituelle », a commenté Ormandy dans un rapport de suivi d’incident. « Des données personnelles ont été activement téléchargées par des robots d’indexation et des utilisateurs pendant une utilisation normale ; ils ne comprenaient tout simplement pas ce qu'ils voyaient ».
Ormandy a ainsi trouvé « des messages privés de grands sites de rencontres, des messages complets d'un service de chat bien connu, des données de gestionnaire de mots de passe, des images de sites vidéo adultes [et] des réservations d'hôtels, Les cookies, les mots de passe, les clés, les données, tout ».
Cloudflare a répondu en désactivant trois fonctionnalités de son CDN qui utilisaient le parseur HTML en question. Le bug, lié à un ancien composant logiciel contenant un problème de sécurité latent, « était grave parce que la mémoire affectée pouvait contenir des informations privées, mises en cache par les moteurs de recherche », explique John Graham-Cumming, un programmeur de Cloudflare. Et d’assurer toutefois que « nous n'avons pas découvert d’indication d'exploitations malveillantes du bug ». Il ajoute en outre que Cloudflare a travaillé avec Google et d'autres moteurs de recherche pour supprimer ces données en cache.
L'équipe du projet zéro de Google a partagé des captures d'écran de données personnelles d’utilisateurs d'Uber, d’OkCupid et de Fitbit. Le CDN de Cloudflare est utilisé par plus de 5 millions de sites Web dont chacun des utilisateurs pourrait être affecté. D’ailleurs, pour Sven Slootweg, chercheur indépendant en sécurité, il convient désormais de considérer que « toute donnée sensible jamais transmise à n’importe quel site sur Cloudflare est irrévocablement compromise ».
So in case this wasn't clear yet:
— Sven Slootweg (@joepie91) February 23, 2017
Consider ALL sensitive data EVER sent to ANY site on CloudFlare to be irrevocably compromised. Everything.
Avec d’autres, Ormandy a toutefois loué la réaction rapide de Cloudflare : « après que l’on a expliqué la situation, Cloudflare a rapidement reproduit le problème, mis en place une cellule de crise, et déployé une première correction en l’espace d’une heure ». Et Rob Graham, d'Errata Security, de souligner que « oui, [Cloudflare] a des bugs, mais il ne s’en cache pas » et c’est une bonne raison de lui faire confiance.
This is how you know you can trust CloudFlare: yes, they have bugs, but they don't run and hide from them. https://t.co/pJ1JsLolZh
— Rob, a nice guy (@ErrataRob) February 23, 2017
Graham-Cumming estime « la plus grande période d'impact » pour le bug était entre le 13 et le 18 février, lors de RSA Conference 2017 – l'une des périodes les plus chargées de l'année pour l'industrie de la sécurité.