Cloudbleed : le bug qui cache la forêt

Le mois dernier, un bug a été découvert par Tavis Omandy (un chercheur d’une équipe de Google) dans l’un des programmes utilisés par Cloudflare, une société américaine qui fournit différents services aux opérateurs de sites Web : performances (l’activité originelle de l’entreprise), protection contre les attaques en déni de service, sécurisation par HTTPS/TLS, firewall applicatif, etc. Nous ne reviendrons pas ici sur cette faille, « Cloudbleed », qui a d’ailleurs été documentée par l’entreprise dans un « post-mortem » d’excellente qualité, ainsi que vulgarisée avec plus ou moins de réussite dans les médias. Mais ce bug, corrigé depuis, cache une autre réalité.

Dénis de service

Les attaques en déni de service (DoS) visent, comme leur nom l’indique, à rendre indisponible un service. Elles consistent généralement à saturer la cible de l’attaque en monopolisant ses ressources, par exemple sa connexion au réseau ou la puissance de calcul dont elle dispose. Par définition, pour qu’un DoS réussisse il faut que l’attaquant dispose d’une capacité supérieure à celle de la cible. Compte-tenu des capacités actuelles des serveurs et des data centers, de leur connectivité, c’est rarement le cas. De plus, ces attaques étant déclenchées depuis des sources uniques, elles sont assez faciles à bloquer.

Pour contourner ce problème, les attaquants utilisent différentes techniques. Ils peuvent par exemple tirer parti de mécanismes « d’amplification » ou de « réflexion » qui permettent d’augmenter de manière importante le rapport entre le trafic utilisé à la source et celui reçu par la victime. Une autre possibilité est de multiplier les sources en utilisant un (très) grand nombre de machines que les attaquants peuvent contrôler ou qu’ils conduisent à participer à l’attaque. On parle alors de déni de service distribué, ou DDoS. De ce point de vue, la myriade d’appareils connectés à Internet constitue une aubaine. Pas ou peu sécurisés, ces équipements sont intégrés à des « botnets » qui servent pour des DDoS de très grande ampleur, comme ceux ayant touché OVH ou Dyn fin 2016.

Ces deux derniers événements d’une ampleur sans précédent — l’attaque contre OVH dépassait en pic le térabit par seconde (1 Tbps, soit 1000 Gbps) de trafic — ont été très médiatisées, en particulier l’attaque sur Dyn qui a perturbé pendant quelques heures le fonctionnement de certains sites populaires comme Twitter. Si les attaques massives augmentent en fréquence et en intensité — ce qui est préoccupant, elles restent encore relativement marginales. Selon un rapport d’Arbor Networks pour l’année 2016, sur le million d’événements observés par le système ATLAS de l’entreprise, seuls 553 auraient dépassé le seuil des 100 Gbps. Toujours d’après ce rapport, la moyenne se situerait à 931 Mbps et 70 % des attaques ne dépasseraient pas les 500 Mbps. Elles dureraient en moyenne 55 minutes et 84 % d’entre elles prendraient fin en moins d’une demi-heure. La tendance est donc à l’augmentation, mais il ne s’agit pas non plus du cataclysme « cyber » qu’on nous vend à longueur de temps.

Wordlwide Infrastructure Security Report – Arbor Networks

Mais comment fait le Père Noël ?

Le problème est que la plupart des opérateurs de services, en particulier de sites Web, ne disposent pas des moyens financiers, techniques et des ressources humaines nécessaires pour contrer une attaque, même relativement petite. Il leur faudrait acheter leurs propres serveurs, faire l’acquisition de coûteux équipements de défense contre les DDoS, louer de la bande passante, des emplacements dans un centre de colocation (un centre de données) et recruter quelques ingénieurs pour gérer tout ce bazar. Économiquement, c’est totalement inaccessible pour la plupart d’entre eux.

Ils doivent donc s’en remettre à des intermédiaires, comme leur hébergeur, pour détecter le trafic malveillant en amont et l’absorber. Certains de ces hébergeurs le font gratuitement, comme OVH ou Online.net, d’autres le facturent à leurs clients. Le populaire Amazon Web Services, par exemple, fournit un premier niveau de protection gratuit « AWS Shield Standard », mais pour accéder au niveau de protection « Advanced », il en coûtera à ses clients la modique somme de 3000 $ par mois, le trafic étant facturé en sus.

Parmi les autres solutions, on trouve des intermédiaires spécialisés dans la défense contre les DDoS comme Akamai, Incapsula, Verisign, Arbor Networks ou encore… Cloudflare. Cette dernière propose, à un tarif tout à fait abordable (200 $ par mois), une protection complète contre les DDoS.

L’entreprise revendique une capacité réseau de 10 Tbps ainsi qu’une centaine de datacenters éparpillés aux quatre coins du globe. Il n’y a guère que le Groënland, l’Antarctique ou le pôle Nord qui soient épargnés ; on se demande d’ailleurs comment font la Reine des Neiges et le Père Noël. Elle tire parti d’anycast, une technique d’adressage qui permet à des serveurs installés à différents endroits de la planète de partager les mêmes adresses IP. Le routage depuis l’utilisateur jusqu’au serveur est effectué « au plus proche » de l’emplacement géographique de l’utilisateur. Ensuite, les informations transitent entre le réseau de Cloudflare et le serveur de destination. Le routage étant fait « au plus proche » de la source, le trafic correspondant aux attaques DDoS est réparti plus ou moins uniformément sur l’ensemble des points de présence de Cloudflare dans le monde, ce qui permet de les absorber plus efficacement.

Réseau Anycast – Cloudflare

Pour le opérateurs de sites Web, la configuration est facile, les prérequis techniques sont bas, l’offre est abordable économiquement et la facture est stable à la fin de chaque mois. On comprend dès lors mieux le succès commercial de Cloudflare. Là où le bât blesse, c’est que Cloudflare va un peu plus loin que la simple protection contre les DDoS, ses serveurs jouant aussi le rôle de reverse proxies et gérant au passage HTTPS pour le compte des clients de l’entreprise.

Reverse proxies

Lorsque vous consultez un site Web depuis votre canapé, votre machine établit une connexion directe avec le serveur hébergeant le site. Si vous vous connectez depuis un réseau d’entreprise, il est possible (ou probable), que votre appareil se connecte à un serveur situé en périphérie de ce réseau. On parle alors de serveur mandataire, de « proxy », une machine intermédiaire qui se chargera à son tour d’établir la connexion avec le serveur de destination. Les entreprises utilisent souvent ce type d’architecture pour des raisons de sécurité, par exemple pour vérifier que vous n’êtes pas en train de télécharger malencontreusement un virus, ou de performances, notamment en mettant en cache certaines pages ou ressources Web (images, scripts, feuilles de style, etc.).

Ces serveurs mandataires sont utilisés par certaines organisations pour d’autres motifs plus ou moins légitimes et généralement liés à la censure au filtrage de certains contenus. Ainsi, selon le niveau de pudibonderie de votre directeur des systèmes d’information, il sera plus ou moins tenté de vous empêcher de visiter YouPorn depuis le bureau.

Lorsqu’un proxy est du côté du serveur de destination et non de celui de l’utilisateur, on parle de serveur mandataire inverse, de « reverse proxy ». C’est très exactement la nature des « edge nodes», les serveurs d’entrée du réseau de Cloudflare. Ces derniers servent d’intermédiaires entre les utilisateurs et les services Web des clients de la société.

Michel en marche

Illustrons cela par un cas concret. Après François Bayrou, c’est au tour d’une autre personnalité de premier plan de déclarer son soutien au candidat Emmanuel Macron : notre fidèle Michel©. Pour ce faire, il tapote avec délicatesse « en-marche.fr » dans son navigateur, et se rend sur le formulaire d’adhésion. Prudent, il vérifie la présence du cadenas vert dans la barre d’adresses, que le site utilise bien HTTPS, qu’il est sécurisé par TLS. Tout lui semble, à première vue, impeccable.

Ce que Michel ignore, c’est que la « forteresse digitale » de son candidat préféré a subi les puissants assauts des légendaires hackers russes ou, l’attribution d’attaques informatiques étant chose complexe toutes les spéculations sont possibles, de pirates à la solde de l’infâme et sournois Docteur Méluche.

L’équipe du sieur Macron a donc abrité son site de campagne derrière le réseau de serveurs de Cloudflare, qui le protège des hackers russes et du tribun subaquatique. Michel n’accède donc pas au serveur d’En Marche directement, mais par l’intermédiaire d’un reverse proxy de Cloudflare. La connexion HTTPS, sécurisée par le protocole TLS, n’est pas établie entre Michel et le site Web d’En Marche, mais entre Michel et un serveur de la société américaine. Cloudflare voit ainsi passer en clair toutes les requêtes HTTP à destination des serveurs ses clients, et toutes les réponses que ceux-ci renvoient, y compris un bon paquet de données personnelles ou confidentielles. La participation de Michel au Grand Mouvement Pour Faire Tomber la France En Marche ne fera pas exception.

Cloudflare revendique 6 millions de clients, dont beaucoup de très gros sites, et sert des centaines de milliards de pages Web tous les mois. D’après W3Techs, l’entreprise fournit 5,6% du million des plus gros sites Web référencés dans le classement Alexa. Ce sont autant de données qui transitent via le gigantesque réseau de l’entreprise.

Si nous étions d’humeur taquine, on se fendrait la fiole de retrouver le site de campagne d’un candidat qui prétend renégocier le Privacy Shield planqué derrière Cloudflare. Mais Reflets est un organe de presse tout ce qu’il y a de plus sérieux, nous nous contenterons donc de déplorer la tendance à la centralisation du Web, qui devient très préoccupante.

Vraiment.

Twitter Facebook Google Plus email

9 thoughts on “Cloudbleed : le bug qui cache la forêt”

  1. Excellent article. Et le coup du docteur Meluche est amusant

    Par contre, il y a une chose que je ne comprend/sais pas.
    Si vous faites du https, vous avez un certificat avec votre nom (ici reflet.info).
    Mais si je me connecte sur le site enmarche.fr via couldflare
    1) je devrai avoir un certificat couldflare.com et pas enmarche.fr-> pas de cadenas vert sur mon navigateur-> pas possible
    2) emarche.fr permet a cloudflare de decrypter ses communication en lui donnant ses cles prives -> je pense pas qu ils sont a ce point a la ramasse pour avoir fait ca
    3) il y a surement autre chose mais je sais pas quoi. Quelque un a une idee ?

    1. Solution 2: on fournit à cloudfare la clé privée (et on paie pour ça ^^’)

      https://support.cloudflare.com/hc/en-us/articles/200170466-How-do-I-upload-a-SSL-certificate-Business-or-Enterprise-only-

      Sinon c’est la solution 1:

      I have a certificate installed on my server, why am I seeing a Cloudflare certificate?

      When you use Cloudflare, we must decrypt the data at our edge in order to cache and filter any bad traffic. Depending on the SSL settings from above, we may re-encrypt or send it as plain text. (full vs flex) Since each certificate needs a dedicated IP address, we add your domain name and wildcard (*.domain.com) domain in the SAN (Subject Alt Name) to the certificate.

      https://support.cloudflare.com/hc/en-us/articles/204144518-SSL-FAQ

      1. vous voulez dire que cloudflare possede les cles prives de TOUS les sites qu ils protegent ?
        Eh ben, si j etait la NSA, j aurais cree cloudflare. Pourquoi s ingenier a espionner les gens s ils peuvent vous donner volontairement les clés …

    2. Alors, en entreprise (ou ailleurs), ça arrive (fréquement ?) de ne pas faire du https de bout en bout, en gros on arrête le https en bordure de DMZ ou autre. Concrètement, ça veut dire que oui, les clé privées ne sont pas sur le serveur qui publie réellement l’appli…
      Il y a de nombreuses raisons à ça, certaines pouvant se justifier (mais ça augmentera toujours le niveau de risque, il y a quelques cas assez spectaculaires lié à cette pratique…), d’autres étant totalement fumeuses !

      Après on peut très bien imaginer que cloudflare mette en pré requis de certains de ces services un chiffrement qui s’arrête à ses proxy… A votre avis que fait quelqu’un de « pas trop sensibilisé » à certaines thématiques qu’on connait bien ici ?

  2. Amusant comment la decentalisation technique du Web (par les reverse proxies entre autres) passe par sa centralisation commerciale (via CloudFlare et une poignee d’autres acteurs) et donc informationnelle (cette poignee d’acteurs voyant tout passer en clair, ce qui ne signifie pas necessairement qu’ils observent ces donnees).

    La seule maniere de decentraliser techniquement le Web sans passer par la centralisation economique serait de laisser les gerants de sites web effectuer la repartition du traffic eux-memes entre des proxies ou mirrors qu’ils gereraient eux-memes. La facture et/ou les requis en competence technique montant tres vite (comme vous le signalez dans l’article), c’est une solution encore lointaine.

  3. « nous nous contenterons donc de déplorer la tendance à la centralisation du Web, qui devient très préoccupante. »

    Bien d’accord.
    J’ai toujours pensé que cette omniprésence de cloudflare faisait plus de mal que de bien.
    Et quand en plus on utilise tbb, c’est infernal. Rien ne marche.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *