Journal Oh, la belle prise (chez CloudFlare)

Posté par  . Licence CC By‑SA.
Étiquettes :
53
24
fév.
2017

Coucou nal (zut, ça marche pas)

Cette nuit, Google a révélé par son « Project Zero » une faille de sécurité chez CloudFlare, qui pourrait bien mériter le prix de faille de l’année.

Depuis le 22 septembre 2016, avec une aggravation depuis le 30 janvier, jusqu’au 18 février, certaines pages HTML mal formées permettaient, après traitement par CloudFlare, de participer à une magnifique loterie : lors d’un accès à la page, on obtenait la page et en cadeau Bonux un bout de mémoire vive du proxy de CloudFlare, contenant donc des données potentiellement sensibles de n’importe quel site passant par CloudFlare.
Les ingénieurs de Google ont trouvé ainsi des bouts de conversation sur des sites de rencontre ou de chat, du contenu pornographique, des mots de passe, etc., le tout dans le cache Google, sinon ce n’était pas drôle.

La réponse de CloudFlare est exemplaire en minimisation de l’impact de la faille : https://blog.cloudflare.com/incident-report-on-memory-leak-caused-by-cloudflare-parser-bug/.

Le message de Google étant plus précis sur l’impact donc : https://bugs.chromium.org/p/project-zero/issues/detail?id=1139.

J’adore l’Internet centralisé et les entreprises qui vendent du « man in the middle »…

  • # Et le cache des autres

    Posté par  . Évalué à 4.

    Il n'y a pas que le cache de Google, il y a tous les autres moteurs de recherche.

    Le plus embêtant, c'est que les utilisateurs n'ont pas beaucoup de moyen de savoir que leur site préféré utilise CloudFlare. Et qu'il leur faut donc changer leur mot de passe…

  • # Exemplarité

    Posté par  . Évalué à 10. Dernière modification le 24 février 2017 à 11:36.

    La réponse de CloudFlare est exemplaire en minimisation de l'impact de la faille

    Elle est très complète techniquement et elle ne minimise pas la gravité de la faille outre mesure.

    Ils disent clairement que c’est très grave, mais de courte durée (activation le 13/02, découverte et correction le 18/02) et sur des sites pour lesquels les administrateurs ont activé un certain set de fonctionnalités (donc une faible proportion de requêtes, même si potentiellement les données de n’importe lequel de leur client ont pu être accessible).

    Compare avec ce qui se fait ailleurs, notamment en France (il y a des exemples récents).

    • [^] # Re: Exemplarité

      Posté par  . Évalué à 9.

      Compare avec ce qui se fait ailleurs, notamment en France (il y a des exemples récents).

      Ho je sais qu'il est possible de faire bien pire que ce que fait CloudFlare, mais ils mettent tellement bien en forme que des collègues n'ont pas compris l'impact de la faille tout de suite.
      Accessoirement, la courte durée reste théorique, ils disent eux-même «The earliest date memory could have leaked is 2016-09-22.» (mais c'est dans les détails, dans le préambule ils s'abstiennent bien de faire peur).

      Leur réponse est parfaite techniquement, mais la section «External impact and cache clearing» devrait être la première section de l'article, et surtout elle ne précise pas assez clairement que chaque mot de passe d'un site utilisant cloudflare a pu potentiellement fuiter dans la loterie. Rien non plus sur l'impact pour des données privées telles que celles qu'a pu récupérer le chercheur de Google (extraits de conversations notamment).
      D'ailleurs, quand on donne «0.00003% of requests», je sais pas pour toi, mais je ne trouve pas sur internet le nombre de requêtes traitées par jour par CloudFlare, et donc ce chiffre est inexploitable…

      • [^] # Re: Exemplarité

        Posté par  . Évalué à 5.

        Quand tu vois le nombre de DC
        https://www.cloudflarestatus.com
        et :
        https://blog.cloudflare.com/the-porcupine-attack-investigating-millions-of-junk-requests/
        dans une partie du post
        "The spikes were large in scale - 500k to 1M HTTP requests per second. Something very strange was going on."

        Je pense que le nombre de request est monstrueux et du coup les 0.00003% peuvent devenir significatifs.

        • [^] # Re: Exemplarité

          Posté par  (site web personnel) . Évalué à -10.

          Je pense que le nombre de request est monstrueux et du coup les 0.00003% peuvent devenir significatifs.

          0.00003% sur 1 Milliard ou 0.00003% sur 1 Trillard reste 0.00003% non significatif.
          La valeur absolue n'a d’intérêt que pour ceux qui veulent trouver quelque chose de significatif en tordant la réalité.

          Juste pour relativiser : 0.00003%, c'est 1000x moins que, par exemple, le pourcentage de femmes qui meurent en accouchant, le truc bien naturel, en France (et vu le nombre d'accouchements, ça en fait des mortes dans l'année, on ne dit pas pour autant que c'est significatif en absolu car on s’intéresse toujours au pourcentage pour ça; perso je dirai juste que pour ce cas de mon exemple, 0.03% est significatif, je ne dirai pas "10 est significatif" car c'est le même problème de signification qu'on parle de la ville, le pays ou la planète)

          J'avoue ne pas comprendre pourquoi vous voulez parler de nombres absolus qui n’apportent rien pour savoir si c'est significatif dans le flux. Question idiote : à partir de quel nombre absolu ça serait significatif? Est-ce que votre choix de nombre serait différent si c'est comparé à 1 milliard, 1 trilliard, 1 trilliard de trilliard?

          • [^] # Re: Exemplarité

            Posté par  . Évalué à 10. Dernière modification le 25 février 2017 à 19:49.

            Je pense que le nombre de request est monstrueux et du coup les 0.00003% peuvent devenir significatifs.

            0.00003% sur 1 Milliard ou 0.00003% sur 1 Trillard reste 0.00003% non significatif.
            La valeur absolue n'a d’intérêt que pour ceux qui veulent trouver quelque chose de significatif en tordant la réalité.

            Juste pour relativiser : 0.00003%, c'est 1000x moins que, par exemple, le pourcentage de femmes qui meurent en accouchant

            Ce raisonnement est assez bête en fait, ce qui importe ce n'est ni le nombre total de requête affecté ni le ratio, ce qui compte c'est le nombre (ou le ratio) de personnes affecté. Comme très peu de françaises accouchent plus de 10 fois, la probabilité de mourir d'un accouchement dans sa vie est du même ordre de grandeur que la probabilité de mourir lors d'un accouchement en particulier.

            Dans le cas d'HTTP la situation est bien différente: si je vais sur https://korben.info, mon navigateur fait une centaine de requête vers ce domaine par page chargée, admettons que j'aille 1 fois par jour sur ce site et que j'ouvre en moyenne 2 page, ça fait 200 requêtes effectuée par jours sur ce domaine. En 5 mois d'existence de la faille, ça fait donc 30 000 requêtes effectuées vers ce domaine. Là, d'un coup la probabilité qu'une de mes requêtes se soit retrouvée dans la nature avec un cookie d’authentification valide s'approche de 1%.

            Bon OK pour Korben.info je m'en tape un peu. Si je regarde la liste des sites potentiellement affectés je vois des sites un peu moins anodins tels que transferwise.com, uber.com ou encore okcupid.com. OK les gens passent plus de temps à glander sur le net qu'à transférer de l'argent ou à commander des VTC, mais en 5 mois à raison de 2 courses en uber par semaine, ça fait encore plus d'une chance sur mille, et cela pour chacun des sites affectés : c'est clairement loin d'être négligeable.

            Il y a donc bien un problème et il vient du fait que le nombre de requête effectuées par chaque personne est monstrueux.

      • [^] # Re: Exemplarité

        Posté par  . Évalué à 4.

        Qu’on se comprenne bien, je ne défends pas CloudFlare en tant que tel, seulement leur communication sur cet incident et je trouve que tu n’es pas honnête en disant qu’elle est mauvaise.

        des collègues n'ont pas compris l'impact de la faille tout de suite.

        la section «External impact and cache clearing» devrait être la première section de l'article

        Dès le second paragraphe, ils précisent le type de faille et le type de données qui a pu fuiter :

        our edge servers were running past the end of a buffer and returning memory that contained private information such as HTTP cookies, authentication tokens, HTTP POST bodies, and other sensitive data. And some of that data had been cached by search engines.

        Le ciquième paragraphe commence par « c’est un problème d’une grande gravité » :

        Because of the seriousness of such a bug, a cross-functional team from software engineering, infosec and operations formed

        D'ailleurs, quand on donne «0.00003% of requests», je sais pas pour toi, mais je ne trouve pas sur internet le nombre de requêtes traitées par jour par CloudFlare, et donc ce chiffre est inexploitable…

        Sur ce point, je suis d’accord.

        • [^] # Re: Exemplarité

          Posté par  . Évalué à 5.

          our edge servers were running past the end of a buffer and returning memory that contained private information such as HTTP cookies, authentication tokens, HTTP POST bodies, and other sensitive data. And some of that data had been cached by search engines.

          Il manque dans ce paragraphe, tout comme dans l'intégralité de la première partie de leur article, un élément crucial qui est certes implicite quand on comprend leur fonctionnement technique, mais qui peut échapper à une personne légèrement moins intéressée : «other sensitive data from any website served previously on this edge server». Ils n'écrivent pas explicitement que le site pentagon.gov peut avoir fourni des données de petitchat.com… (ou l'inverse)

          Mais effectivement, mon journal est peut-être mal formulé sur ce point, c'est une minimisation par utilisation de l'implicite plutôt que l'explicite, et le fait de «noyer» dans la technique des points clés du problème. Peut-être qu'une annonce plus officielle, plus corporate, viendra régler cet aspect, mais ça m'étonnerait…

  • # le tweet du vendredi 16h00

    Posté par  . Évalué à 5.

    le genre de tweet dont tu te passerais bien. Après une journée a mouler sur slashdot :'D

    Could someone from cloudflare security urgently contact me.
    from : Vulnerability researcher at Google

    tentative de traduction : quelqu'un de l'equipe de sécurité cloudfare peut'il me contacter immédiatement.

    • [^] # Re: le tweet du vendredi 16h00

      Posté par  . Évalué à 10.

      Ouais il abuse le mec de Google, il aurait pu passer par le programme de rapport de failles de CloudFlare et gagner un TeeShirt…

  • # Petit sondage : pensez-vous que CloudFlare va de faire Dawinizer ?

    Posté par  . Évalué à -10. Dernière modification le 24 février 2017 à 13:45.

    • oui
    • non
    • heu

    ps : Dawinizer : néologisme signifiant qu'une entité va mourir, car elle n'était pas adaptée à son milieu.

  • # La réponse officielle de CF pour les clients, pour infos.

    Posté par  . Évalué à 3.

    Dear Cloudflare Customer:

    Thursday afternoon, we published a blog post describing a memory leak caused by a serious bug that impacted Cloudflare's systems. If you haven't yet, I encourage you to read that post on the bug:

    https://blog.cloudflare.com/incident-report-on-memory-leak-caused-by-cloudflare-parser-bug/

    While we resolved the bug within hours of it being reported to us, there was an ongoing risk that some of our customers' sensitive information could still be available through third party caches, such as the Google search cache.

    Over the last week, we've worked with these caches to discover what customers may have had sensitive information exposed and ensure that the caches are purged. We waited to disclose the bug publicly until after these caches could be cleared in order to mitigate the ability of malicious individuals to exploit any exposed data.

    In our review of these third party caches, we discovered data that had been exposed from approximately 150 of Cloudflare's customers across our Free, Pro, Business, and Enterprise plans. We have reached out to these customers directly to provide them with a copy of the data that was exposed, help them understand its impact, and help them mitigate that impact.

    Fortunately, your domain is not one of the domains where we have discovered exposed data in any third party caches. The bug has been patched so it is no longer leaking data. However, we continue to work with these caches to review their records and help them purge any exposed data we find. If we discover any data leaked about your domains during this search, we will reach out to you directly and provide you full details of what we have found.

    To date, we have yet to find any instance of the bug being exploited, but we recommend if you are concerned that you invalidate and reissue any persistent secrets, such as long lived session identifiers, tokens or keys. Due to the nature of the bug, customer SSL keys were not exposed and do not need to be rotated.

    Again, if we discover new information that impacts you, we will reach out to you directly. In the meantime, if you have any questions or concerns, please don’t hesitate to reach out.

    Matthew Prince
    Cloudflare, Inc.
    Co-founder and CEO

    • [^] # Re: La réponse officielle de CF pour les clients, pour infos.

      Posté par  . Évalué à 10.

      oh put*n j'ai cru un instant que le pdg de clouflare etait sur linuxfr !

    • [^] # Re: La réponse officielle de CF pour les clients, pour infos.

      Posté par  . Évalué à 4.

      Ouais, t'as de la chance, tu aurais pu recevoir « You are receiving this email because you are one of the customers where our team was able to identify data that was leaked due to the bug and stored in one of these third party caches.»
      Beaucoup moins fun…

    • [^] # Re: La réponse officielle de CF pour les clients, pour infos.

      Posté par  . Évalué à 10.

      Tu veux rire un peu ? Regarde ton mail en texte brut, ils ont fait une erreur à l'envoi (en tout cas sur celui que j'ai eu)

      Le même mail :
      - en texte brut : « You are receiving this email because you are one of the customers where our team was able to identify data that was leaked due to the bug and stored in one of these third party caches. »
      - en HTML : « Your domain is not one of the domains where we have discovered exposed data in any third party caches. »

      Donc les plus barbus avec mutt et cie (ou avec un lecteur de mail configuré pour le texte brut) vont paniquer, pour les autres c'est bon rien de grave…

  • # cloudfl..what?

    Posté par  (site web personnel) . Évalué à 6.

    J'ai jamais compris à quoi servait ce service …

    • [^] # Re: cloudfl..what?

      Posté par  (site web personnel) . Évalué à -3.

      Crée une boite avec un succès fulgurant qui génère des milliards de pages vues par jour sur toute la planète et qui n'a pas envie de se transformer en OVH parce que c'est pas son métier, et tu auras une meilleure idée.

      • [^] # Re: cloudfl..what?

        Posté par  (site web personnel) . Évalué à 9.

        Oh excusez moi, je ne savais pas que les questions sérieuses étaient interdites dans les commentaires

        • [^] # Re: cloudfl..what?

          Posté par  . Évalué à 10.

          www.cloudflare.com c'est essentiellement un frontal web (reverse proxy) pour un site web, il faut absolument confier les DNS à cloudflare. L'interface d'admin des DNS est superbe !

          Ensuite on a 2 possibilités soit on l'utilise gratuitement :
          - l'IP de son serveur est masquée par leurs IPs
          - on dispose d'un CDN, les pages de ton site qui peuvent être mises en cache le sont sur l'ensemble de leurs serveurs réparti géographiquement
          - un certificat SSL peut être activé entre les internautes et leurs serveurs CDN
          - une protection DDOS

          Pour les offres payantes, il y a des options que je n'ai pas mises en œuvre…

          https://www.cloudflare.com/fr/plans/

          l'offre gratuite permet d'améliorer leur détection des DDOS, on fait partie de l'ensemble de leur réseau et on augmente leur surface de détection. J'en suis conscient.

          www.cloudflare.com me semble assez facile à mettre en œuvre…

          J'ai un gros client (1er dans leur domaine en France et en au Royaume-Uni, avec une DSI au Royaume-Uni) qui a choisi https://www.incapsula.com un concurrent de https://www.cloudflare.com.

          Ensuite on peut citer ceux-ci, et ils me semblent plus difficiles à mettre en œuvre :
          https://www.akamai.com
          https://www.cachefly.com
          https://www.maxcdn.com.

          Plus d'infos ici :
          https://en.wikipedia.org/wiki/Content_delivery_network

          En fait, il serait difficile pour certains sites d'exister et être consultable dans de bonnes conditions, sans ces CDNs. Apple et Microsoft utilisent Akamai. Pour Apple, elle est entrain de ce construire son propre CDN et se détache d'Akamai. Elle à même fiancé les début d'Akamai et lâché l'affaire quand Microsoft est devenu cliente.

          • [^] # Re: cloudfl..what?

            Posté par  . Évalué à 3.

            Il existe aussi une petite société francaise spécialisée dans la revente de solutions CDNs avec des prix compétitifs http://www.atanar.net ils sont à fond open source.

      • [^] # Re: cloudfl..what?

        Posté par  . Évalué à 3.

        On est d'accord sur l'usage.
        Après, en terme d'exposition des données privées de ses clients, à leur insu, c'est presque intolérable.

        • [^] # Re: cloudfl..what?

          Posté par  . Évalué à 1.

          Niveau technologie, je sais que cachefly repose sur du TCP anycast, quelqu'un sait si les autres CDN sont sur le même type de techno ? C'est plutôt standardisé (via des RFC par exemple) ou chacun à sa solution custom ?

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.