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. 

Cloudflare have been leaking customer HTTPS sessions for months. Uber, 1Password, FitBit, OKCupid, etc. https://t.co/wjwE4M3Pbk

— Tavis Ormandy (@taviso) 23 février 2017

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

• Savoir si un site utilise Cloudflare

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.

• Choisir un bon mot de passe : les règles à connaître, les pièges à éviter
• Notre dossier sur les gestionnaires de mots de passe