Une faille de divulgation des e-mails des utilisateurs YouTube rapporte 10 000 $ de prime

 (brutecat.com)
1 points par GN⁺ 2025-02-13 | 1 commentaires | Partager sur WhatsApp
  • L’identifiant interne de compte Google d’une chaîne YouTube, l’obfuscated Gaia ID, pouvait être exposé puis relié à une adresse e-mail via l’API de partage de Pixel Recorder, créant un problème de confidentialité des comptes Google
  • Une requête Innertube du menu de blocage du live chat renvoyait un paramètre moderateLiveChatEndpoint contenant le Gaia ID de la chaîne ciblée, même sans effectuer de blocage réel
  • En remplaçant l’ID de chaîne dans les paramètres de la requête, la portée s’étendait jusqu’aux Topic Channels sans messages de live chat, montrant que le problème ne concernait pas seulement certains participants
  • Le WriteShareList de Pixel Recorder acceptait l’obfuscated Gaia ID du destinataire du partage et incluait l’adresse e-mail dans la réponse ; un titre d’enregistrement de 2,5 millions de caractères permettait aussi d’empêcher l’envoi d’un e-mail de notification
  • Après un signalement reçu le 15 septembre 2024, Google a confirmé le correctif des deux failles le 9 février 2025 et a versé un total de 10 633 $ de récompense

Le Gaia ID révélé par la fonction de blocage de YouTube

  • Le document discovery de staging de l’API Internal People de Google montrait que l’objet BlockedTarget utilisait un obfuscated Gaia ID et fallbackName
    • profileId correspond à l’obfuscated Gaia ID de l’utilisateur bloqué
    • fallbackName correspond au nom affiché de l’utilisateur bloqué
  • Le centre d’aide des comptes Google indiquait qu’il était possible de bloquer des comptes depuis YouTube, et dans les faits, lorsqu’un utilisateur est bloqué dans un live YouTube, il apparaît dans myaccount.google.com/blocklist
  • Dans la liste de blocage, le nom de chaîne Mega Prime apparaissait comme fallbackName, et 107183641464576740691 comme profile ID
  • En partant du principe qu’une chaîne YouTube ne devrait pas exposer le compte Google sous-jacent, et sachant qu’il avait déjà existé des bugs permettant de convertir un Gaia ID en adresse e-mail, la recherche d’une autre voie a commencé

Extension à l’ensemble des chaînes via le menu du live chat

  • Le simple fait d’ouvrir le menu à trois points dans le live chat YouTube déclenchait une requête vers /youtubei/v1/live_chat/get_item_context_menu
  • La réponse contenait un moderateLiveChatEndpoint menant à /youtubei/v1/live_chat/moderate ainsi qu’une valeur params
  • Ces params étaient un protobuf encodé en base64, format fréquemment utilisé chez Google, et le décodage révélait le Gaia ID de l’utilisateur ciblé pour le blocage
    • L’exemple de réponse contenait 113907466537670370590 ainsi que des identifiants liés à la chaîne
    • Il était donc possible d’obtenir le Gaia ID de la cible sans effectuer de blocage réel
  • Le décodage des paramètres de la requête get_item_context_menu montrait qu’ils contenaient l’ID de chaîne à bloquer, l’ID de la vidéo du live et l’ID de l’auteur du live
  • En remplaçant l’ID de chaîne dans les paramètres de la requête, les tests ont montré qu’il était aussi possible d’obtenir le Gaia ID 103261974221829892167 d’une Topic Channel générée automatiquement par YouTube

Pixel Recorder servait de voie de conversion vers l’e-mail

  • En recherchant dans d’anciens produits Google des bugs ou défauts de logique capables de convertir un Gaia ID en e-mail, l’auteur a examiné Pixel Recorder avec nathan
  • Après avoir créé un enregistrement de test sur un téléphone Pixel et l’avoir synchronisé avec un compte Google, les endpoints web de recorder.google.com ont été utilisés
  • Lors du partage de l’enregistrement avec une adresse e-mail de test, la requête WriteShareList incluait l’obfuscated Gaia ID dans la liste des destinataires
  • La réponse de PlaybackService/WriteShareList sur pixelrecorder-pa.clients6.google.com renvoyait l’adresse e-mail du destinataire du partage
    • La réponse de test contenait vrptest2@gmail.com
    • En y injectant le Gaia ID 107183641464576740691 obtenu lors de l’expérience de blocage YouTube, la réponse renvoyait aussi redacted@gmail.com
  • Cela permettait donc une chaîne d’attaque où le Gaia ID obtenu via YouTube était injecté dans l’API de partage de Pixel Recorder pour découvrir l’adresse e-mail correspondante

Un titre d’enregistrement de 2,5 millions de caractères pour bloquer l’e-mail de notification

  • Lorsqu’un enregistrement Pixel Recorder était partagé avec une victime, celle-ci recevait un e-mail de notification, ce qui pouvait réduire l’impact de l’attaque
  • La fenêtre de partage ne proposait aucune option pour désactiver cette notification, et l’analyse du protobuf de la requête avec req2proto n’a révélé aucun champ permettant de la désactiver
  • La structure WriteShareListRequest contenait les champs suivants
    • recording_id
    • delete_obfuscated_gaia_ids
    • update_shared_users
    • sharing_message
  • Même en ajoutant et supprimant un utilisateur simultanément, l’e-mail continuait d’être envoyé
  • En constatant que l’objet de l’e-mail de notification incluait le titre de l’enregistrement, l’auteur a supposé qu’un titre extrêmement long pouvait provoquer l’échec de l’envoi
  • Un script Python a donc été écrit pour modifier le titre de l’enregistrement à 2,5 millions de caractères via l’endpoint UpdateRecordingTitle, et aucun contrôle de longueur côté serveur n’a été observé
  • Après avoir défini le titre à 2,5 millions de caractères puis partagé l’enregistrement avec un autre utilisateur de test, aucun e-mail de notification n’a été envoyé

PoC finale et calendrier de traitement

  • La chaîne d’attaque complète comportait trois étapes
    • Obtenir l’obfuscated Gaia ID de la chaîne ciblée depuis l’endpoint Innertube /get_item_context_menu de YouTube
    • Partager avec la cible un enregistrement Pixel Recorder au titre extrêmement long afin de convertir le Gaia ID en adresse e-mail
    • Retirer ensuite cet utilisateur des destinataires du partage de l’enregistrement Pixel Recorder pour effacer les traces
  • Une vidéo de PoC est fournie sur YouTube

Prime Google et calendrier du correctif

  • 2024-09-15 : envoi du signalement à l’éditeur
  • 2024-09-16 : l’éditeur a trié le rapport et a répondu Nice catch!
  • 2024-10-03 : le panel a marqué le dossier comme doublon d’un bug de suivi existant et a appliqué un correctif incomplet à l’exposition initiale de l’obfuscated Gaia ID sur YouTube
  • 2024-10-03 : nouvelle explication fournie à l’éditeur sur le fait que Pixel Recorder constituait aussi une vulnérabilité à part entière
    • l’obfuscated Gaia ID pouvait aussi être exposé chez les évaluateurs de Google Maps et Google Play
    • une méthode de contournement pour divulguer à nouveau l’obfuscated Gaia ID des chaînes YouTube a également été fournie
  • 2024-11-05 : le panel a accordé une prime de 3 133 $
    • justification : exploitabilité moyenne
    • classé comme méthodologie d’abus à fort impact
  • 2024-12-03 : l’équipe produit a renvoyé le rapport au panel pour examen d’une prime supplémentaire et a coordonné une date de divulgation au 2025-02-03
  • 2024-12-12 : le panel a accordé une prime complémentaire de 7 500 $
    • justification : exploitabilité élevée
    • classé comme méthodologie d’abus à fort impact
    • montant de base réduit d’un niveau en raison de la complexité de la chaîne d’attaque
  • 2025-01-29 : l’éditeur a demandé un report de la date de divulgation au 2025-02-02
  • 2025-02-09 : confirmation que les deux maillons de la chaîne d’attaque avaient été corrigés
    • soit 147 jours après le signalement initial
  • 2025-02-12 : publication du rapport

À lire aussi

1 commentaires

 
GN⁺ 2025-02-13
Avis de Hacker News

  • Le titre m’a embrouillé. Pour ceux qui n’ont pas lu jusqu’au bout : ce ne sont pas les e-mails divulgués qui ont coûté de l’argent ; cela a demandé du temps et de l’ingéniosité, et l’auteur a reçu une prime de bug bounty de 10 000 dollars

    • Au début, j’ai cru que cela voulait dire qu’ils proposaient un service permettant de divulguer les e-mails des utilisateurs pour 10 000 dollars par utilisateur
    • Moi aussi, j’ai cru que cela voulait dire qu’ils le proposaient comme un service à 10 000 dollars
    • Le titre est peut-être pensé pour faire cliquer
    • Au début, je pensais que ça parlerait du coût de calcul nécessaire pour bruteforcer un hash quelconque

  • Il y a beaucoup de bruit autour de la divulgation responsable, des motivations et de la récompense, mais on voit peu de gens dire que c’est un argument de plus contre une identité permanente centralisée
    Chaque fois qu’un service affirme fonctionner au mieux lorsqu’il est lié à une unique Real Identity™, j’ai l’impression que ces entreprises ne se soucient de protéger réellement les utilisateurs que de manière abstraite, et encore, seulement de temps en temps
    Imaginez que toute personne avec qui vous interagissez sur YouTube puisse immédiatement se rapprocher de trois ou quatre étapes d’un doxxing : c’est à peu près l’impact réel de ce bug, à mon avis. Tant mieux qu’il ait été corrigé, mais je ne pense pas que ce genre de bugs disparaisse bientôt. Que faudra-t-il pour que les fournisseurs et les grandes entreprises comprennent que cette conception est un champ de mines sur le point d’exploser ?

    • Sur le principe, je suis d’accord. Ces comptes devraient permettre un certain degré d’anonymat et de jetabilité. Après tout, ce ne sont jamais qu’une ligne dans une base de données quelque part
      Cela dit, beaucoup de gens effectuent de vraies transactions financières avec ces entreprises. Par exemple les abonnés YouTube Premium ou les créateurs de contenu. En pratique, un identifiant lié à l’identité réelle doit être stocké quelque part dans ce compte jetable. À cause du risque de fraude et des réalités bancaires, on finit par transmettre son identité et son adresse réelles à l’entreprise, qui les stocke aussi
      Je ne donne pas d’informations permettant de m’identifier à des applis ou sites web quelconques, mais les parties avec lesquelles je fais affaire savent forcément qui je suis dans la vraie vie, et deviennent en théorie un point par lequel ces données peuvent fuiter
    • Ils ne s’en soucient pas parce qu’il n’y a pas de conséquences juridiques
      Qu’un prestataire de santé divulgue des données médicales, et il se fera complètement démolir

  • « Voici un POC d’exploit fonctionnel : cette vidéo a été supprimée pour violation des conditions d’utilisation de YouTube », c’est drôle

    • L’auteur de l’article original a publié l’adresse e-mail d’un utilisateur réel pour sa preuve de concept. Dans la vidéo remise en ligne, l’adresse e-mail est floutée
    • Au début, c’est aussi ce que je voyais, mais en rouvrant l’article, la vidéo semble s’afficher. Je ne sais pas si elle vient tout juste d’être rétablie

  • Comme un commentaire sur trois dans ce fil dit que Google a trop peu payé pour ce bug, voici quelques bases sur la valorisation des vulnérabilités
    Les vulnérabilités côté serveur ont une faible valeur parce que les acheteurs ne se font pas concurrence. Il n’existe pratiquement pas de marché gris pour les vulnérabilités côté serveur. Il est difficile pour un tiers de mettre un prix sur un bug que Google peut tuer immédiatement, qui n’a quasiment aucune demi-vie dès sa découverte, et dont l’exploitation génère une télémétrie fiable chez la cible
    À l’inverse, si des bugs comme des chaînes complètes Android/Chrome se vendent des centaines de milliers de dollars, c’est parce que Google est en concurrence avec un marché gris bien établi. Un prestataire peut prendre ce bug et le vendre à plusieurs agences d’un pays européen, potentiellement six
    Cela dit, comparer les primes et le marché gris, c’est comparer des pommes et des oranges. Google n’a besoin que d’une preuve que l’exploit est possible, pas d’un exploit fiable, et n’a pas non plus de coûts de maintenance ; il paie donc bien moins que le marché gris. La valeur totale du reste du marché se répartit en plusieurs étapes et s’accompagne de conditions de risque, mais Google peut proposer un paiement forfaitaire attractif même avec une décote
    Les attaquants achètent des vulnérabilités qui s’intègrent à leurs processus métier existants. En général, ils n’imaginent pas de manière spéculative toutes les choses géniales qu’ils pourraient faire avec une nouvelle vulnérabilité ni comment la monétiser. Collecter des informations de paiement, obtenir des milliers de machines pour un botnet : ce sont des processus métier existants. Révéler le vrai nom lié à un compte Google peut-il devenir un business ? Peut-être. Est-ce que ça existe déjà ? Probablement pas
    Le montant des primes n’est généralement pas un référendum populaire sur l’ingéniosité ou l’intérêt d’un bug. Cela dit, ici, c’est un peu le cas aussi : 10 000 dollars pour un bug web côté serveur me semble exceptionnellement élevé
    Pour quelqu’un qui gagne sa vie en trouvant ce genre de bugs, la stratégie consiste à devenir très bon pour en trouver beaucoup. Ce n’est pas comme le développement d’exploits iOS, où l’on peut passer des mois sur un seul exploit fiable
    Les recherches de vulnérabilités que j’ai faites récemment dans ma carrière étaient plus proches de ça que de beaucoup d’autres travaux, donc je suis assez confiant. Mais il y a sur HN des gens qui font ce type de bug bounty à plein temps ; je serais heureux qu’ils me corrigent

    • Dans la plupart des autres domaines, on n’est pas rémunéré sur la base de la valeur au marché noir de ce qu’on a créé
      Si l’on appliquait cette analyse à autre chose, le prix plafond d’un nouvel autoradio ou d’un vélo serait d’environ 100 dollars, et le prix de tous les biens soumis au droit d’auteur serait limité au coût de leur transmission sur le réseau
      Je pense qu’il est plus utile de diviser le montant payé par Google par le temps consacré à ce travail, plus tout le temps passé sur des tentatives d’exploits ratées depuis la dernière prime
      La grande majorité des gens dans ce domaine gagnent probablement moins que le salaire minimum américain rapporté à l’effort fourni, tout en supportant un coût d’opportunité annuel à six chiffres
      Ce chiffre montre précisément la valeur que Google accorde à la sécurité des utilisateurs finaux et à la protection de leur vie privée. C’est bien moins que ce qu’ils paient, avec plusieurs ordres de grandeur de plus, d’autres ingénieurs pour voler les données personnelles des mêmes personnes
    • Je n’aime pas que ce fil HN parle surtout du montant de la prime, mais c’est aussi naturel. La plupart des gens qui commentent ici travaillent dans le logiciel et veulent normaliser des primes très élevées
      Pour eux, c’est une source de revenus supplémentaire. Tout comme les ingénieurs logiciel veulent que leur métier soit très bien payé, ils veulent aussi que les bug bounties augmentent. Il est naturel que les travailleurs réclament de meilleurs salaires pour leur métier, et aucune rationalisation ne changera cet instinct
    • « Les attaquants achètent des vulnérabilités qui s’intègrent à leurs processus métier existants », mais n’y a-t-il pas aussi un marché pour ce genre de chose ? Par exemple : « découvrons qui se cache derrière ce compte qui critique notre entreprise/gouvernement louche, afin de le neutraliser »
      Il existe aussi des incitations distinctes de la valeur sur le marché des attaquants. Une personne violente qui harcèle une personnalité en ligne n’est peut-être pas un client rentable sur ce marché des exploits zero-day, mais si une entreprise peut, par négligence, exposer l’identité de la cible à un harceleur violent, cette vulnérabilité reste une responsabilité et un risque éthique
      Personnellement, si l’on verse des sommes énormes à des artistes de performance LeetCode qui produisent des quantités colossales de code avec une attention imparfaite à la sécurité, je pense qu’il faut aussi bien payer les personnes qui aident à trouver et corriger leurs innombrables erreurs avant qu’un drame ne se produise
    • L’exploitation de bugs côté serveur par les forces de l’ordre est une zone beaucoup plus grise, voire réellement illégale. En revanche, les forces de l’ordre et les services de renseignement disposent déjà de procédures standard pour obtenir des ordonnances judiciaires leur permettant d’exploiter l’appareil d’une cible donnée, c’est-à-dire son téléphone ou son ordinateur portable

  • « Déclassement d’un niveau par rapport au montant de base en raison de la complexité de la chaîne d’attaque requise » : est-ce courant ?
    Je n’ai participé qu’à quelques programmes de vulnérabilités, mais la plupart payaient plutôt moins lorsqu’il s’agissait d’une faille absurdement simple mais grave, comme l’adresse e-mail de l’utilisateur exposée dans le source de la page

    • J’ai compris au contraire que la pénalité venait du fait que c’était relativement complexe pour une vulnérabilité web
    • Ça me semble à l’envers. En pratique, ils ont trouvé deux bugs, donc il faudrait augmenter le montant de base

  • « Il y a quelque temps, en cherchant une cible de recherche chez Google, je fouillais la documentation discovery de l’Internal People API (Staging) » : est-ce que c’est censé être simplement public ? https://staging-people-pa.sandbox.googleapis.com/$discovery/...

    • Ce n’est qu’un fichier de schéma généré automatiquement à partir de définitions .proto internes. Google ne s’appuie pas sur la sécurité par l’obscurité, mais sur de la vraie cryptographie
      De plus, les endpoints discovery sont documentés publiquement[0] et conçus pour les utilisateurs externes. En interne, les gens ne lisent pas les endpoints discovery : ils consultent directement les fichiers .proto via la recherche de code
      D’après mon expérience chez Google, exposer publiquement une API impliquait de se battre avec la bureaucratie pendant des semaines. Ce n’est pas comme un bucket AWS S3 rendu public par accident. L’équipe savait que c’était public, et elle a probablement franchi les obstacles bureaucratiques pour le rendre public
      [0]: https://developers.google.com/discovery/v1/getting_started

  • Si l’on regarde la chronologie de l’article, le signalement a été fait à l’entreprise le 15/09/2024, le 29/01/2025 l’entreprise a demandé une prolongation de la divulgation publique jusqu’au 12/02/2025, le 09/02/2025 il a été confirmé que les deux côtés de l’exploit avaient été corrigés, et la publication a eu lieu le 12/02/2025.
    Donc ce n’est pas resté non corrigé pendant 136 jours, et Google n’a-t-il pas demandé une prolongation ? Cela fait 147 jours jusqu’à la correction, 150 jours jusqu’à la publication.
    Si l’on compare avec le délai de divulgation avant correction que Google Project Zero impose aux autres entreprises, il est dit : « Ce bug est soumis à un délai de divulgation de 90 jours. Si un correctif est fourni aux utilisateurs avant l’échéance des 90 jours, ce rapport de bug sera publié 30 jours après la mise à disposition du correctif. Sinon, il sera publié à l’échéance. »
    « Si le correctif est prévu dans les 14 jours suivant l’expiration du délai, Project Zero peut accorder une prolongation… Cependant, comme la période de grâce de 14 jours chevauche la période de 30 jours d’application du patch, les vulnérabilités corrigées pendant cette période de grâce seront publiées au plus tard le 120e jour à compter du délai initial de 90 jours. »
    « Si nous estimons que le correctif ne sera pas prêt dans les 14 jours, nous utilisons le délai initial de 90 jours comme date de publication. Autrement dit, la prolongation de grâce de 14 jours n’est accordée que lorsque le développeur s’engage à déployer un correctif pendant cette période de grâce de 14 jours. »
    https://googleprojectzero.blogspot.com/p/vulnerability-discl...

    • Je ne pense pas que cette comparaison soit utile. Ici, c’est un bug Google dans un logiciel Google, alors que Project Zero trouve généralement des bugs dans des logiciels utilisés par beaucoup d’acteurs, ce qui rend la correction plus urgente à mon sens.

  • Dire que « ces params ne sont qu’un protobuf encodé en base64, un format d’encodage couramment utilisé dans tout Google », ça donne envie de payer un verre au développeur Google chargé de prendre un joli format de message binaire, de l’encoder en base64 et de le faire rentrer de force dans un blob JSON.
    Si vous voulez voir l’avenir, imaginez une botte portant l’inscription « worse is better » sur la semelle, piétinant éternellement le visage d’un ingénieur.

    • C’est partout et c’est le pire. Parfois, je me demande s’il n’y a pas plus d’octets protobuf représentés en base64 dans du JSON que de vrais octets protobuf circulant sur les lignes d’Internet, puis je me sers moi-même un verre.
    • En interne, ce doit être un protobuf en base64 dans un champ protobuf.
      La partie JSON est une conversion automatique.
    • Une chaîne JSON contenant un protocol buffer encodé en base64 : quelle que soit l’entreprise qui a fait ça, on sait très bien quelle entreprise l’a fait.

  • Le clou du spectacle, c’est d’avoir cassé le système d’e-mail au point que les mails ne soient pas envoyés. Dans une gigantesque entreprise comme Google, qui a créé d’innombrables produits, la sécurité semble presque factice.
    Si chaque ligne de code est une vulnérabilité potentielle, avec des millions de lignes, cela devient tout simplement inévitable. À part garder les choses simples, par exemple en supprimant le site recorder, je ne vois pas de solution, mais même ça n’est pas facile.

    • C’est peut-être une raison de plus pour laquelle Google tue beaucoup de produits qui ont réussi, mais pas assez pour qu’il vaille la peine de les maintenir en vie et sécurisés dans l’ensemble de son système.
    • Malheureusement, vu le nombre d’utilisateurs de Google, toute suppression provoquera des cris de douleur et des réactions du genre « je compte dessus pour chauffer mon ordinateur avec la barre d’espace ». Il suffit de voir https://killedbygoogle.com/.
    • J’aimerais qu’on me donne un exemple où la sécurité paraît « réelle », et en quoi cela aide.
      La plupart des produits logiciels reposent sur une pile logicielle très complexe, et si l’on fait confiance à 100 % à toutes les bibliothèques et à tous les systèmes d’exploitation utilisés, c’est à mon avis le mauvais état d’esprit. Même les processeurs ont eu des bugs comme Meltdown. La sécurité est un combat permanent : on ne sait jamais si l’on a gagné, on apprend seulement parfois quand on a perdu.
    • Au fond, tu proposes une sorte d’équation de Drake[1] qui calcule le nombre de vulnérabilités de sécurité à partir du nombre de lignes de code. Quels autres facteurs cette équation devrait-elle inclure ?
      [1] https://en.wikipedia.org/wiki/Drake_equation
    • Le point essentiel, c’est que la sécurité est factice. Aucune application n’est vraiment sûre. Même si l’on dépense des millions de dollars en sécurité applicative, une seule erreur d’un utilisateur humain peut suffire à tout compromettre.

  • Moi aussi, j’avais compris le titre comme quelque chose du genre 10 000 dollars de coûts de calcul GPU. Vu qu’il a choisi un vieux produit Google et y a trouvé une faille tout de suite, il doit y avoir encore des dizaines, voire des centaines, de bugs de ce genre.

    • Ça ne fonctionne pas vraiment comme « il a choisi un vieux produit Google et y a trouvé une faille tout de suite ». L’auteur a probablement fouillé plusieurs produits pendant des semaines ou des mois avant de trouver quelque chose de valeur.
    • Moi aussi, j’avais compris que ça voulait dire vendre des adresses e-mail de YouTubers pour 10 000 dollars.