Il y a quelques jours, le fournisseur de CDN CloudFlare a dû rapidement intervenir sur un bug, désigné par la suite sous le nom de CloudBleed. Celui-ci laissait apparaître les données privées d’internautes mises en cache par ses systèmes d’optimisation et de diffusion de contenus lors des requêtes effectuées sur Internet. Le problème a été découvert presque par hasard par l’un des experts en sécurité de Project Zero, l’équipe de Google qui traque les vulnérabilités les plus sérieuses dans les logiciels et sur le web. Tavis Ormandy s’est aperçu que le CDN de Cloudflare renvoyait quelquefois des pages web confuses qui pouvaient contenir des informations privées et secrètes des internautes (mots de passe, cookies de sessions, jetons d’authentification et, même, messages privés) au lieu des données de cache qu’il était supposé retourner. Les CDN accélèrent le web en permettant à des sites de pousser des pages et du contenu média vers les nœuds Internet se trouvant au plus près de l’utilisateur qui les demande.

Le réseau de Cloudflare fonctionne comme un proxy inversé pour des millions de sites web parmi lesquels ceux d’importants services Internet et de très grandes entreprises auxquels il fournit, en arrière-plan, des services de sécurité et d’optimisation de contenus. Dans ce cadre, il modifie les pages html lorsqu’elles transitent par ses serveurs pour réécrire les liens http et https, protéger certains contenus de l’inquisition des robots, brouiller les adresses email, mettre en œuvre le mode AMP (Accelerated Mobile Pages), etc. Le bug se trouvait dans un ancien analyseur de syntaxe que Cloudflare utilisait depuis de nombreuses années. Toutefois, cet outil n’avait pas été activé avant l'ajout d'un nouveau parseur l’an dernier. Ce dernier a modifié la façon dont les buffers des serveurs web internes étaient utilisés lorsque certaines fonctionnalités étaient actives. A partir de là, la mémoire interne contenant potentiellement des données sensibles était exposée lors du renvoi de certaines réponses vers les utilisateurs ou vers les robots d’indexation des moteurs de recherche. Les pages web contenant ces données étaient alors mises en cache et pouvaient être prises en compte par des moteurs de recherche tels que ceux de Google, Yahoo ou Bing.

Cloudflare alerté par Google le 18 février

Ces fuites ont été découvertes par le chercheur de Google alors qu’il travaillait sur un autre projet avec un collègue. Aussitôt après avoir compris de quoi il s’agissait et d’où cela venait, les deux experts ont alerté Cloudflare le 18 février. Le fournisseur de CDN a immédiatement constitué une équipe de prise en charge du problème qui a supprimé en quelques heures la fonctionnalité causant l’essentiel de la fuite. La résolution complète du problème de sécurité a été finalisée le 20 février. L’incident a été divulgué deux jours plus tard. Entre temps, Cloudflare a travaillé avec les moteurs de recherche pour purger les caches des données sensibles qui s’y trouvaient encore. « Avec l’aide de Google, Yahoo, Bing et des autres, nous avons trouvé 770 URI uniques qui avaient été mises en cache et contenaient des fuites de mémoire », a expliqué dans un billet John Graham-Cumming, le CTO de Cloudflare. « Ces 770 URI uniques couvraient 161 domaines uniques ». L'Uniform Resource Identifier est une chaîne de caractères qui identifie une ressource sur le web et qui est quelquefois utilisé de façon interchangeable avec le terme URL (Universal Resource Locator).

Selon Graham-Cumming, la fuite de données a certainement démarré le 22 septembre, mais c’est sans doute entre le 13 et le 18 février qu’elle a eu le plus d’impact, lorsque la fonction de masquage des adresses email a été migrée vers le nouvel analyseur de syntaxe (parseur). Cloudflare estime qu’environ 3,3 millions de requêtes http transitant par ses systèmes ont potentiellement subi des fuites de mémoire. Cela représente 0,00003% de toutes les requêtes.

1Password préservé des fuites de Cloudflare

Parmi les sites mentionnés par Tavis Ormandy (Project Zero) dans un tweet figure notamment 1Password.com d’AgileBits, dont l’app de gestion de mots de passe peut être synchronisée à travers Dropbox ou associée à des comptes payants sur 1Password.com pour que les entreprises et les particuliers puissent partager des documents et autres données. Mais selon AgileBits, ses serveurs n’ont pas été affectés par le bug de Cloudflare.

Dans un mail à nos confrères de Macworld, Jeffrey Goldberg, responsable de la sécurité de la société, explique que 1Password a été conçu dès le départ en tenant compte du fait qu’une connexion https pouvait être vulnérable et que TLS (transport layer security) pouvait rencontrer des problèmes. 1password.com ne recourt donc pas à une simple procédure de login dans laquelle un nom d’utilisateur et un mot de passe donnent accès aux informations stockées et transférées à travers une connexion web sécurisée. Ce n’est que l’une des 3 couches utilisées, ainsi que l’éditeur l’explique sur son blog.