YouTube यूज़र ईमेल लीक कमजोरी पर $10,000 का इनाम मिला

 (brutecat.com)
1 पॉइंट द्वारा GN⁺ 2025-02-13 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • YouTube चैनल के आंतरिक Google account identifier obfuscated Gaia ID के उजागर होने और उसे Pixel Recorder sharing API के जरिए ईमेल पते से जोड़े जा सकने के कारण यह Google account privacy की समस्या बन गई
  • लाइव चैट के block menu का Innertube request, असल में block किए बिना भी target channel के Gaia ID वाला moderateLiveChatEndpoint parameter लौटाता था
  • request parameters में channel ID बदलने पर scope उन Topic Channel तक बढ़ गया जिनमें live chat messages नहीं होते, इसलिए यह समस्या केवल किसी खास participant तक सीमित नहीं थी
  • Pixel Recorder का WriteShareList share target के obfuscated Gaia ID को input के रूप में लेकर response में ईमेल पता शामिल करता था, और 25 लाख अक्षरों वाले recording title से notification email भेजे जाने को भी रोका जा सकता था
  • Google ने 15 सितंबर 2024 को report मिलने के बाद 9 फरवरी 2025 को दोनों vulnerabilities के fix की पुष्टि की, और कुल $10,633 reward दिया

YouTube block feature में सामने आया Gaia ID

  • Google के Internal People API staging discovery document में यह पुष्टि हुई कि BlockedTarget object obfuscated Gaia ID और fallbackName का उपयोग करता है
    • profileId block किए जाने वाले user का obfuscated Gaia ID है
    • fallbackName block किए जा रहे user का display name है
  • Google account help में बताया गया था कि YouTube पर accounts को block किया जा सकता है, और वास्तव में YouTube live stream में user को block करने पर वह user myaccount.google.com/blocklist में दिखाई देता है
  • block list में channel name Mega Prime fallbackName के रूप में, और 107183641464576740691 profile ID के रूप में दिखा
  • इस धारणा के आधार पर कि YouTube channel को underlying Google account expose नहीं करना चाहिए, और क्योंकि पहले भी Gaia ID को ईमेल address में convert करने वाले bugs थे, अतिरिक्त रास्ते खोजने शुरू किए गए

live chat menu से पूरे channels तक विस्तार

  • YouTube live chat में 3-dot menu खोलते ही /youtubei/v1/live_chat/get_item_context_menu request trigger होता है
  • response में /youtubei/v1/live_chat/moderate की ओर जाने वाला moderateLiveChatEndpoint और params value शामिल होती है
  • यह params Google में आम तौर पर इस्तेमाल होने वाला base64 encoded protobuf था, और decode करने पर इसमें block target user का Gaia ID था
    • example response में 113907466537670370590 और channel-related identifiers शामिल थे
    • actual block किए बिना भी target का Gaia ID पाया जा सकता था
  • get_item_context_menu request parameters को decode करने पर block किए जाने वाले channel का channel ID, livestream video ID, और livestream author ID शामिल थे
  • request parameters के अंदर channel ID को किसी दूसरी value से बदलकर test करने पर, YouTube द्वारा automatically generated Topic Channel का Gaia ID 103261974221829892167 भी पाया जा सका

Pixel Recorder ईमेल conversion path बना

  • पुराने Google products में Gaia ID को email में बदल सकने वाले bug या logic flaw की तलाश के दौरान, nathan के साथ Pixel Recorder की जांच की गई
  • Pixel phone पर test recording बनाकर उसे Google account से sync करने के बाद, web के recorder.google.com endpoints इस्तेमाल किए गए
  • recording को test email पर share करते समय WriteShareList request ने share target list में obfuscated Gaia ID शामिल किया
  • pixelrecorder-pa.clients6.google.com के PlaybackService/WriteShareList response ने उस share target का email address लौटाया
    • test response में vrptest2@gmail.com शामिल था
    • YouTube block experiment से मिले 107183641464576740691 Gaia ID को डालने पर भी redacted@gmail.com लौटा
  • इससे YouTube से मिले Gaia ID को Pixel Recorder sharing API में डालकर email address पता करने वाली attack chain संभव हो गई

notification email रोकने वाला 25 लाख अक्षरों का recording title

  • Pixel Recorder में recording को victim के साथ share करने पर victim को email notification भेजा जाता था, जिससे attack impact कम हो सकता था
  • sharing popup में notifications बंद करने का विकल्प नहीं था, और req2proto से request protobuf analyze करने पर भी notification disable करने वाली कोई field नहीं थी
  • WriteShareListRequest structure में ये fields थीं
    • recording_id
    • delete_obfuscated_gaia_ids
    • update_shared_users
    • sharing_message
  • user को एक साथ add और remove करने पर भी email भेजा जाता रहा
  • यह देखते हुए कि notification email subject में recording title शामिल होता है, माना गया कि recording title को बहुत लंबा बनाने पर email भेजना fail हो सकता है
  • UpdateRecordingTitle endpoint के जरिए recording title को 25 लाख characters में बदलने वाली Python script लिखकर test किया गया, और server side पर title length limit नहीं थी
  • title को 25 लाख characters पर set करने के बाद जब दूसरी test user के साथ share किया गया, तो notification email नहीं भेजा गया

final PoC और handling timeline

  • तैयार attack chain तीन steps से बनी थी
    • YouTube Innertube /get_item_context_menu endpoint से target channel का obfuscated Gaia ID प्राप्त करना
    • बहुत लंबे title वाली Pixel Recorder recording target के साथ share कर Gaia ID को email address में convert करना
    • Pixel Recorder recording के share targets से उस user को remove कर cleanup करना
  • PoC video YouTube video के रूप में दी गई

Google reward और fix timeline

  • 2024-09-15: vendor को report भेजी गई
  • 2024-09-16: vendor ने report triage की और Nice catch! response मिला
  • 2024-10-03: panel ने इसे मौजूदा tracking bug का duplicate mark किया, और initial YouTube obfuscated Gaia ID exposure के लिए incomplete patch किया
  • 2024-10-03: vendor को फिर समझाया गया कि Pixel Recorder खुद भी vulnerability है
    • obfuscated Gaia ID Google Maps और Google Play reviewers में भी expose हो सकता था
    • YouTube channel obfuscated Gaia ID को फिर leak करने वाला bypass method भी दिया गया
  • 2024-11-05: panel ने $3,133 reward दिया
    • आधार था medium exploitability
    • high-impact abuse-related methodology के रूप में classify किया गया
  • 2024-12-03: product team ने अतिरिक्त reward review के लिए report को panel के पास वापस भेजा, और 2025-02-03 disclosure schedule coordinate किया
  • 2024-12-12: panel ने $7,500 additional reward दिया
    • आधार था high exploitability
    • high-impact abuse-related methodology के रूप में classify किया गया
    • attack chain complexity के कारण base amount से 1 level down लागू किया गया
  • 2025-01-29: vendor ने disclosure schedule को 2025-02-02 तक extend करने का अनुरोध किया
  • 2025-02-09: पुष्टि हुई कि attack chain के दोनों हिस्से fix हो गए हैं
    • initial report के 147 दिन बाद
  • 2025-02-12: report public हुई

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-02-13
Hacker News की राय

  • शीर्षक उलझाने वाला था। जिन्होंने लेख अंत तक नहीं पढ़ा, उनके लिए: लीक हुए ईमेल की वजह से कोई खर्च नहीं हुआ था, बल्कि समय और सूझ-बूझ लगाई गई और $10,000 का bug bounty मिला था

    • शुरुआत में मुझे लगा था कि इसका मतलब है कि वे user email लीक करने वाली service प्रति user $10,000 में दे रहे हैं
    • मुझे भी लगा था कि इसे $10,000 वाली service के रूप में पेश किया जा रहा है
    • शायद शीर्षक clickbait के लिए रखा गया हो
    • शुरुआत में मुझे लगा था कि यह किसी hash को brute force करने की compute cost जैसी बात होगी

  • responsible disclosure, motive और reward को लेकर बहुत शोर है, लेकिन यह बात कम दिख रही है कि यह centralized permanent identity के खिलाफ एक और दलील है
    जब भी कोई service दावा करती है कि वह तभी सबसे अच्छा काम करती है जब वह एक Real Identity™ से जुड़ी हो, तो लगता है कि कंपनियों को users को सचमुच protect करने में सिर्फ सैद्धांतिक दिलचस्पी है, और वह भी कभी-कभार ही
    कल्पना कीजिए कि YouTube पर जिसके साथ भी आप interact करते हैं, वह तुरंत आपकी doxxing के तीन-चार कदम और करीब पहुंच सकता है; इस bug का वास्तविक असर मेरे हिसाब से यही था। अच्छा है कि इसे fix कर दिया गया, लेकिन इस तरह के bugs जल्द गायब होंगे, ऐसा नहीं लगता। कंपनियों और बड़ी enterprises को यह समझाने के लिए क्या चाहिए कि ऐसा design फटने को तैयार minefield है

    • सिद्धांत रूप में सहमत हूं। ऐसे accounts में कुछ हद तक anonymity और disposability की अनुमति होनी चाहिए। आखिरकार वह कहीं किसी database की एक row ही है
      हालांकि बहुत से लोग इन कंपनियों से असली पैसे में लेन-देन करते हैं। जैसे YouTube Premium subscribers या content creators। व्यवहार में, उस disposable account में कहीं न कहीं real-world identity identifier stored होना ही पड़ता है। fraud risk और banking की वास्तविकताओं के कारण, आप अपनी असली identity और address company को दे देते हैं और company भी उसे store करती है
      मैं random apps या websites को पहचान बताने वाली जानकारी नहीं देता, लेकिन जिसके साथ मैं transaction करता हूं, वह अनिवार्य रूप से real दुनिया वाले मुझे जानता है और सिद्धांततः वही data leak होने की जगह बन सकता है
    • कानूनी नतीजे नहीं हैं, इसलिए वे परवाह नहीं करते
      कोई healthcare provider अगर medical data leak करे तो उसकी हालत पूरी तरह खराब हो जाएगी

  • “working exploit POC है: यह video YouTube Terms of Service के उल्लंघन के कारण हटा दिया गया है” — यह मजेदार है

    • original post के लेखक ने proof of concept के लिए एक वास्तविक user का email address public कर दिया था। दोबारा upload किए गए video में email address blur किया गया है
    • शुरुआत में मुझे भी ऐसा ही दिखा था, लेकिन फिर post खोलकर देखा तो लगता है video दिख रहा है। पता नहीं अभी-अभी restore हुआ है या नहीं

  • इस thread में हर तीसरे comment में यही बात है कि Google ने इस bug के लिए बहुत कम दिया, इसलिए vulnerability valuation पर बुनियादी तौर पर बात करें तो यह कुछ इस तरह है
    Server-side vulnerabilities की value कम होती है क्योंकि vendors उनके लिए compete नहीं करते। Server-side vulnerabilities का लगभग कोई grey market नहीं होता। ऐसे bug पर किसी third party के लिए price लगाना मुश्किल है जिसे Google तुरंत खत्म कर सकता है, जिसके discover होते ही उसकी half-life लगभग खत्म हो जाती है, और exploit करने पर target पर भरोसेमंद remote telemetry पैदा होती है
    इसके उलट Android/Chrome full chain जैसे bugs लाखों dollars में इसलिए बिकते हैं क्योंकि Google एक अच्छी तरह बने grey market से compete कर रहा होता है। कोई vendor वह bug लेकर यूरोप के किसी देश की कई agencies, संभवतः 6 जगहों तक, बेच सकता है
    फिर भी bounty और grey market की तुलना apples और oranges जैसी है। Google को high-reliability exploit नहीं चाहिए, बस यह proof चाहिए कि exploit लिखा जा सकता है, और maintenance cost भी नहीं चाहिए, इसलिए वह grey market से काफी कम देता है। बाकी market का total amount कई stages में बंटा होता है और risk conditions जुड़ी होती हैं, लेकिन Google discount के बावजूद एक attractive lump sum offer कर सकता है
    Attackers वे vulnerabilities खरीदते हैं जो उनके existing business processes में fit बैठती हैं। आम तौर पर वे यह speculative तरीके से नहीं सोचते कि किसी नई vulnerability से क्या cool चीजें की जा सकती हैं और पैसे कैसे कमाए जा सकते हैं। Payment information collect करना, botnet के लिए हजारों machines हासिल करना — ये existing business processes हैं। Google account का असली नाम expose करना क्या business बन सकता है? हो सकता है। क्या पहले से है? शायद नहीं
    Bounty payouts आम तौर पर इस बात पर referendum नहीं होते कि bug कितना clever या interesting है। हालांकि यहां थोड़ा वैसा भी है, क्योंकि server-side web bug के लिए 10,000 dollars असामान्य रूप से ज्यादा लगता है
    जो लोग ऐसे bugs ढूंढकर जीविका कमाते हैं, उनके लिए business strategy यह है कि बहुत सारे bugs ढूंढने में skilled बनें। यह iOS exploit development जैसा नहीं है, जहां एक reliable exploit पर महीनों लगाए जाते हैं
    हाल के career में जो vulnerability research मैंने की है, वह कई दूसरे कामों की तुलना में इस तरफ ज्यादा रही है, इसलिए इस बारे में मुझे काफी confidence है। फिर भी HN पर ऐसे लोग हैं जो यह bounty work full-time करते हैं, इसलिए अगर कोई ऐसा व्यक्ति सुधार करे तो खुशी होगी

    • दूसरे ज्यादातर क्षेत्रों में लोगों को उनके बनाए सामान की black market value के आधार पर reward नहीं मिलता
      इस analysis को दूसरी चीजों पर लागू करें तो नए car audio या bicycle की upper price लगभग 100 dollars हो जाएगी, और copyrighted हर goods की कीमत network पर transmit करने की cost तक सीमित हो जाएगी
      मुझे लगता है कि Google ने जो amount दिया, उसे इस काम में लगे समय और पिछली bounty के बाद failed exploit attempts में लगे कुल समय से divide करना ज्यादा useful होगा
      इस field में ज्यादातर लोग effort के मुकाबले US minimum wage से कम कमाते होंगे, और सालाना six-figure opportunity cost चुका रहे होंगे
      वह number ठीक-ठीक दिखाता है कि Google end-user security और privacy को कितनी value देता है। यह उसी लोगों की personal information चुराने के लिए दूसरे engineers को दिए जाने वाले कई orders of magnitude ज्यादा पैसे से बहुत कम number है
    • मुझे पसंद नहीं कि यह HN thread ज्यादातर bounty amount के बारे में है, लेकिन यह natural भी है। यहां comment करने वाले ज्यादातर लोग software industry में काम करते हैं और बहुत high bounties को normal बनाना चाहते हैं
      क्योंकि उनके लिए यह extra income source है। जैसे software engineers चाहते हैं कि उनका profession high-paying हो, वैसे ही वे bug bounties भी ऊंची होना चाहते हैं। Workers का अपने profession की wage बढ़ाने की मांग करना natural है, और कोई भी rationalization उस instinct को नहीं बदलता
    • “Attackers वे vulnerabilities खरीदते हैं जो existing business processes में fit बैठती हैं”, लेकिन क्या ऐसी चीजों का भी market नहीं है? जैसे, “हमारी संदिग्ध company/government की आलोचना करने वाले इस account के पीछे कौन व्यक्ति है, यह पता लगाकर उसे neutralize करें”
      Attacker market value से अलग incentives भी होते हैं। Online celebrities को stalk करने वाला कोई violent व्यक्ति zero-day exploit market में profitable customer न हो सकता है, लेकिन अगर company लापरवाही से target की identity किसी violent stalker के सामने expose कर सकती है, तो वह vulnerability फिर भी liability और ethical risk है
      निजी तौर पर, अगर सुरक्षा पर अधूरा ध्यान देते हुए भारी मात्रा में code उगलने वाले LeetCode performance artists को बहुत पैसे दिए जा रहे हैं, तो बुरी घटना होने से पहले उनकी ढेरों गलतियां ढूंढकर ठीक करने में मदद करने वालों को भी अच्छा payment मिलना चाहिए
    • Law enforcement द्वारा server-side bugs exploit करना कहीं ज्यादा grey area है, या वास्तव में illegal भी हो सकता है। दूसरी ओर, किसी specific target के device, यानी phone या laptop, को exploit करने के लिए court order लेने की standard process law enforcement और intelligence agencies के पास पहले से मौजूद है

  • “Required attack chain की complexity की वजह से base amount से 1 level downgrade लागू किया गया” — क्या यह common है?
    मैंने कुछ ही vulnerability programs में participate किया है, लेकिन उनमें से ज्यादातर में अगर page source में user email दिखने जैसी हद से ज्यादा simple लेकिन serious flaw हो, तो उल्टा कम reward दिया जाता था

    • मैंने इसे ऐसे समझा कि web vulnerability के हिसाब से यह relatively complex थी, इसलिए points कटे
    • यह तो उल्टा लगता है। दरअसल 2 bugs मिल गए, इसलिए base amount से ऊपर देना चाहिए

  • “कुछ समय पहले Google में research target खोजते हुए मैं Internal People API (Staging) discovery docs खंगाल रहा था” — क्या इसका simply public होना ठीक है: https://staging-people-pa.sandbox.googleapis.com/$discovery/...

    • यह सिर्फ schema file है जो internal .proto definitions से automatically convert हुई है। Google security by obscurity पर नहीं, बल्कि वास्तविक cryptography पर rely करता है
      इसके अलावा discovery endpoint publicly documented है[0] और external users के लिए बनाया गया है। Internal लोग discovery endpoint नहीं पढ़ेंगे, बल्कि code search से सीधे .proto file देखेंगे
      Google में काम करने के अनुभव से कहूं तो किसी API को public expose करने के लिए bureaucracy से कई हफ्ते लड़ना पड़ता था। यह गलती से public हो गई AWS S3 bucket जैसी चीज नहीं है। Team को पता रहा होगा कि यह public है, और इसे public करने के लिए उन्होंने bureaucracy पार की होगी
      [0]: https://developers.google.com/discovery/v1/getting_started

  • लेख की टाइमलाइन देखें तो 2024-09-15 को कंपनी को रिपोर्ट किया गया, 2025-01-29 को कंपनी ने सार्वजनिक disclosure को 2025-02-12 तक बढ़ाने का अनुरोध किया, 2025-02-09 को पुष्टि हुई कि exploit के दोनों पहलू ठीक कर दिए गए हैं, और 2025-02-12 को इसे सार्वजनिक किया गया।
    तो क्या यह 136 दिनों तक ठीक नहीं हुआ और Google ने extension मांगा? ठीक होने तक 147 दिन, और disclosure तक 150 दिन लगे।
    Google Project Zero दूसरी कंपनियों को fix से पहले public disclosure के लिए जो deadline देता है, उससे तुलना करें तो वह कहता है, “इस bug पर 90-दिन की disclosure deadline लागू होती है। अगर 90-दिन की deadline से पहले users के लिए fix उपलब्ध करा दिया जाता है, तो यह bug report fix उपलब्ध होने के 30 दिन बाद प्रकाशित की जाएगी। नहीं तो deadline पर प्रकाशित होगी।”
    “अगर patch deadline खत्म होने के 14 दिनों के भीतर आने की उम्मीद हो, तो Project Zero extension दे सकता है… हालांकि 14-दिन का grace period 30-दिन के patch adoption period के साथ overlap करता है, इसलिए grace period के भीतर fix की गई vulnerabilities भी मूल 90-दिन की deadline से अधिकतम 120वें दिन तक प्रकाशित कर दी जाती हैं।”
    “अगर यह माना जाए कि fix 14 दिनों के भीतर तैयार नहीं होगा, तो मूल 90-दिन की deadline को ही disclosure time के रूप में इस्तेमाल किया जाता है। यानी 14-दिन का grace extension तभी दिया जाता है जब developer 14-दिन के grace period के भीतर fix deploy करने का वादा करे।”
    https://googleprojectzero.blogspot.com/p/vulnerability-discl...

    • मुझे नहीं लगता यह तुलना बहुत उपयोगी है। यह Google software में Google का bug है, और Project Zero आम तौर पर ऐसे software में bugs ढूंढता है जिसे बहुत से लोग इस्तेमाल करते हैं, इसलिए मेरी समझ में fix की urgency वहां ज्यादा होती है।

  • “वे params बस base64-encoded protobuf हैं, और यह Google भर में आम तौर पर इस्तेमाल होने वाला encoding format है” — शानदार binary message format को base64 encode करके JSON के ढेर में ठूंसने वाले Google developer के नाम एक जाम तो बनता है।
    अगर भविष्य देखना हो, तो कल्पना करें कि तले पर “worse is better” लिखा एक boot किसी engineer के चेहरे को हमेशा के लिए कुचल रहा है।

    • यह हर जगह है और सबसे खराब है। कभी-कभी मैं सोचता हूं कि internet wires पर गुजरने वाले असली protobuf bytes से ज्यादा मात्रा में शायद JSON के अंदर base64 में दर्शाए गए protobuf bytes ही चलते होंगे, और फिर मैं अपने लिए एक जाम डाल लेता हूं।
    • अंदरूनी तौर पर शायद यह protobuf field के अंदर base64 protobuf होगा।
      JSON वाला हिस्सा automatic conversion है।
    • base64-encoded protocol buffer की JSON string—किस कंपनी ने किया है पता न हो, फिर भी पता चल जाता है कि किस कंपनी ने किया होगा।

  • email system को खराब करके mail भेजे ही न जा सकें, यही तो icing on the cake है। Google जैसी अनगिनत products बनाने वाली विशाल कंपनी में security नकली जैसी लगती है।
    अगर code की हर line एक संभावित vulnerability है, तो लाखों lines में यह बस अपरिहार्य है। इसे simple रखने—जैसे recorder site को बंद कर देने—के अलावा कोई रास्ता नहीं दिखता, लेकिन वह भी आसान नहीं है।

    • यह एक और वजह हो सकती है कि Google ऐसे बहुत से products को खत्म कर देता है जो सफल तो हुए, लेकिन Google के पूरे system में उन्हें जिंदा और सुरक्षित बनाए रखने जितने सफल नहीं हुए।
    • दुर्भाग्य से Google के users की संख्या देखते हुए, कोई भी shutdown दर्द भरी चीखों और “मैं computer को spacebar से गर्म करने पर निर्भर हूं” जैसी प्रतिक्रियाओं को जन्म देगा। https://killedbygoogle.com/ देखें।
    • मैं पूछना चाहूंगा कि security “सचमुच” जैसी महसूस होने का कोई उदाहरण दें, और वह कैसे मदद करती है।
      ज्यादातर software products बेहद जटिल software stack पर निर्भर होते हैं, और अगर आप इस्तेमाल की जाने वाली हर library और operating system पर 100% भरोसा करते हैं तो मेरे हिसाब से यह गलत mindset है। processors में भी Meltdown जैसे bugs रहे हैं। security एक लगातार चलने वाली लड़ाई है; आपने जीता है या नहीं, यह कभी निश्चित नहीं होता, और हारे हैं यह बस कभी-कभी पता चलता है।
    • मूल रूप से आप code lines की संख्या के आधार पर security vulnerabilities की संख्या निकालने वाली Drake equation[1] जैसी कोई चीज प्रस्तावित कर रहे हैं। इस equation में और कौन-कौन से factors आएंगे?
      [1] https://en.wikipedia.org/wiki/Drake_equation
    • असली बात यह है कि security नकली है। कोई भी app सच में सुरक्षित नहीं है। app security पर लाखों dollars खर्च करने के बाद भी, किसी एक human user की एक गलती से सब टूट सकता है।

  • मैंने भी title को GPU compute cost 10,000 dollars जैसा कुछ समझ लिया था। जिस तरह एक पुराना Google product चुनकर तुरंत छेद मिल गया, लगता है ऐसे bugs दर्जनों या सैकड़ों और होंगे।

    • यह ऐसे काम नहीं करता कि “एक पुराना Google product चुना और तुरंत छेद ढूंढ लिया।” बहुत संभव है कि लेखक ने कुछ valuable मिलने से पहले कई products को हफ्तों या महीनों तक खंगाला हो।
    • मैंने भी इसे YouTuber email addresses को 10,000 dollars में बेचने के मतलब में गलत समझा था।