Google को AI से hack करके 7 करोड़ रुपये कमाना

 (brutecat.com)
10 पॉइंट द्वारा GN⁺ 4 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • AI से Google की APIs को लगातार ऑटोमेटिक तरीके से probe करवाने के नतीजे में, 3 महीनों में 5 लाख डॉलर की bug bounty कमाने वाले एक security researcher का मामला
  • 60,000 से अधिक Android apps से इकट्ठी की गई API keys और Google के API specifications (discovery document) को जोड़कर, बाहरी दुनिया में कम ज्ञात APIs समेत 1,500 से अधिक APIs को टेस्ट टार्गेट के रूप में हासिल किया गया
  • Claude-आधारित AI को API testing tools से जोड़कर, इंसान की तरह requests भेजने और permission checks के बिना मौजूद access control vulnerabilities को अपने-आप ढूंढने के लिए सेटअप किया गया
  • Google Voice account takeover, YouTube private video leak, Widevine DRM key exposure, Nest device owner identity tracking जैसी कई गंभीर vulnerabilities मिलीं
  • इनमें से ज़्यादातर sophisticated attacks से नहीं, बल्कि permission checks की कमी, बिना authentication वाली APIs, और test environments में real data को जस का तस expose कर देना जैसी बार-बार दोहराई जाने वाली बुनियादी गलतियों से पैदा हुईं

रिसर्च की शुरुआत

  • 2025 के अक्टूबर में bugSWAT Mexico के निमंत्रण के बाद Google पर रिसर्च पर फिर से फोकस किया गया; Google source code का कुछ हिस्सा देख पाने की संभावना ने उत्सुकता बढ़ाई
  • पिछले 1 साल में Claude के साथ छोटे-छोटे projects बनाते हुए, यह आंका गया कि AI से Google APIs का बड़े पैमाने पर automated testing करने की काफी संभावना है
  • मुख्य entry point था discovery document — Google का Swagger-जैसा documentation, जो सभी endpoints, parameters और methods को machine-readable रूप में बताता है
    • YouTube Data API जैसी public APIs के लिए यह खुला है, लेकिन Internal People API जैसी internal APIs के लिए भी मौजूद है
    • कुछ तक सीधे पहुंचा जा सकता है, लेकिन ज़्यादातर के लिए valid API key चाहिए

API keys इकट्ठा करना

  • अक्सर एक service में मिली key उसी GCP project की कई दूसरी APIs पर भी enabled होती है, इसलिए जितनी ज़्यादा keys मिलें, उतनी बड़ी access surface मिलती है
  • दोस्त Michael के साथ मिलकर key collection किया गया
    • Google apps के सभी versions समेत 61,200 Android APKs डाउनलोड करके unzip किए गए और उनमें API keys खोजी गईं
    • Chrome Debugger API आधारित extension से traffic intercept करके, ज्ञात 2,800+ Google web domains पर जाते समय real-time requests से keys इकट्ठी की गईं
    • Google iOS apps (IPA) को decrypt करके और उपलब्ध Google binaries का analysis भी साथ में किया गया

  • सिर्फ Google keys अलग करना

    • VRP scope के भीतर रहने के लिए Cloud Marketplace API से key से जुड़े project की जानकारी निकालकर non-Google keys हटा दी गईं
    • जब किसी key को ऐसी API पर आज़माया जाता है जहां permission नहीं है, तो error response में project number दिख जाता है (उदाहरण: "...in project 244648151629...")
    • इस नंबर से query करने पर company field project owner domain बताता है, इसलिए google.com (और nest.com, fitbit.com, wing.com जैसी acquired companies) के अलावा बाकी keys फेंक दी गईं

live Google API domains ढूंढना

  • extension द्वारा logged domains, keyword-based brute generation, और certificate transparency logs को मिलाकर candidate domains निकाले गए
  • हर domain पर request भेजकर, अगर Server header ESF, GSE, या scaffolding on HTTPServer2 में से एक हो, तो उसे live valid Google API माना गया

छिपे हुए specifications तक scraping

  • 2025 के जुलाई में Google ने ज़्यादातर APIs से /$discovery/rest path हटा दिया, लेकिन कुछ में bypass अब भी संभव था

  • Visibility Label से छिपे endpoints

    • कुछ projects में visibility label enabled होता है, इसलिए labels parameter देने पर ही hidden endpoints दिखाई देते हैं
    • Service Management API specification बिना label के 253KB थी, लेकिन ?labels=GOOGLE_INTERNAL जोड़ने पर यह 329KB हो गई और काफी hidden docs सामने आ गए
    • एक बार में सिर्फ एक label लिया जा सकता था, इसलिए हर label, हर key और हर API के combination पर बड़े पैमाने पर requests चलानी पड़ीं
  • इस तरह 1,500 से अधिक API specifications जुटाई गईं, और पुराने research से जमा docs के साथ मिलाकर AI automated testing की तैयारी पूरी हुई

authentication की समस्या हल करना

  • API key से "permission" की समस्या तो कुछ हद तक हल हुई, लेकिन कई endpoints caller की पहचान पक्की करने के लिए अलग से authentication भी मांगते थे
  • Bearer tokens GCP project से बंधे होते हैं, इसलिए उन्हें API key के साथ मिलाने पर "different projects" error आता था; कोई ज्ञात bypass नहीं था

  • First Party Authentication (FPA)

    • कई APIs Google की proprietary auth scheme FPA को support करती हैं, जो API key के साथ काम करती है
    • web requests में session Cookie और उससे निकला Authorization value शामिल होता है, और ये *.clients6.google.com host पर भेजे जाते हैं
    • drivefrontend-pa जैसी कुछ APIs, email जैसी user identifiers को hash में शामिल करने वाला ज्यादा complete FPA v2 header मांगती हैं
    • Michael को एक sourcemap मिला जिसे Google ने कुछ समय के लिए गलती से expose कर दिया था, और उससे internal gapix library में FPA v2 header generation code मिल गया

  • token structure और Gaia ID

    • token format है <timestamp>_<hash>_<identifierkey> और SHA1 input है "email:gaiaId timestamp sessionCookie origin"
    • identifier key सिर्फ तीन हैं: e (email), u (obfuscated Gaia ID), a (Workspace domain); बाकी letters backend ignore कर देता है
    • Gaia का मतलब है "Google Accounts and ID Administration"; हर account के पास sequential unobfuscated Gaia ID (जैसे 131337133377) और एक लंबा obfuscated ID होता है

  • Origin whitelist और key restrictions

    • कई APIs allowed Origin list रखती हैं; disallowed origin देने पर SESSION_COOKIE_INVALID error मिलता है, जिससे cookie issue का भ्रम होता है
    • keys पर Server, Browser, Android, iOS — चार तरह की restrictions होती हैं; Browser में Referer, iOS में X-Ios-Bundle-Identifier, और Android में X-Android-Package के साथ certificate fingerprint match करना पड़ता है
    • key collection के दौरान इन values को भी साथ store किया गया, ताकि brute forcing उसी program में integrate हो सके
    • *.corp.google.com origin पर restrictions नहीं थीं, इसलिए ऐसी APIs के internal-only होने की संभावना ज़्यादा थी और bugs भी बहुत थे — एक case में access control vulnerability पर $9,000 मिले

request flow map और अपना testing tool

  • एक program बनाया गया जो classify करता था कि request किस stage पर reject हो रही है (method resolution → key validity → key restrictions → authentication → origin check → label आदि), ताकि कौन-सी key किस API पर काम करती है इसका mapping मिल सके
  • Google का API Explorer सिर्फ public APIs के लिए था और private नहीं, इसलिए FPA v2 तक support करने वाला अपना API Explorer लगभग एक हफ्ते में बनाया गया
    • specification को client-side parse करके valid request/response JSON auto-generate किया जाता था, और arbitrary payloads जल्दी आज़माने के लिए UI दिया गया
    • demo में दिखाया गया endpoint assignedTams (technical account managers) को leak करने वाली access control bug थी, जिस पर $6,000 मिले

AI automated testing setup

  • लक्ष्य था कि AI बुनियादी access control issues अपने-आप ढूंढे, और बाद में इंसान उन्हें और गंभीर vulnerabilities तक escalate करे
  • frontend के JSON parsing code को MCP tool के रूप में AI से जोड़ा गया, ताकि वह इंसान की तरह APIs टेस्ट कर सके

  • ज़्यादा thorough, ज़्यादा quiet

    • शुरुआत में AI कुछ probes के बाद जल्दी रुक जाती थी, इसलिए Ralph Wiggum loop लगाकर यह अनिवार्य किया गया कि वह खत्म होने से पहले हर endpoint को कम-से-कम 1 बार टेस्ट करे
    • endpoints को पहले logical groups में classify किया गया, फिर group-दर-group टेस्ट किया गया, और पहले groups की findings बाद वाले groups को दी गईं
    • probe_api input को endpoint, path, और body तक simplify किया गया; जटिल FPA auth backend संभालता था, जिससे AI सिर्फ payload लिखने पर ध्यान दे सके
    • हर key पर response अलग हो सकता था, इसलिए एक ही request को सभी keys से auto-send किया जाता था, और same responses को hash करके group किया जाता था
    • Method not found जैसे confusing errors को MISSING_REQUIRED_VISIBILITY_LABEL जैसे labels में translate किया गया, ताकि AI भ्रमित न हो

  • noise और validation समस्या हल करना

    • शुरू में असली bugs 90% noise में दब जाते थे, इसलिए validation की कठिनाई और बहुत ज़्यादा false positives दो मुख्य समस्याएं बन गईं
    • report में actual request को point करने वाला operation ID डाला गया, ताकि frontend में Play दबाकर reproduction हो सके और tamper-proof evidence मिले
    • एक महीने से ज़्यादा समय तक system prompt refine करके reporting criteria साफ़ किए गए — सिर्फ दूसरे users का data access या जहां 4xx आना चाहिए वहां 2xx आने जैसी चीज़ें report की गईं; साधारण existence enumeration को vulnerability नहीं माना गया
    • इसके बाद AI ने 50% से अधिक precision के साथ बड़े पैमाने पर bugs ढूंढने शुरू किए; एकमात्र सीमा उपलब्ध API keys की संख्या थी

मिली हुई प्रमुख vulnerabilities

  • 3 महीनों से कम समय में $500,000 के बराबर bugs मिले; नीचे fix हो चुकी कुछ प्रमुख मिसालें हैं

  • Google Voice account takeover

    • gfibervoice-pa में access control बिल्कुल नहीं था; बिना authentication की एक single curl line से सिर्फ victim का unobfuscated Gaia ID पता हो तो phone number, notification address समेत पूरी PII dump की जा सकती थी
    • response में victim का Google account recovery phone number भी दिख सकता था (सिर्फ कुछ conditions में; सटीक conditions Google ने public नहीं कीं)
    • ऐसे endpoints भी थे जो किसी भी account में Voice number force-assign कर सकते थे (500 error दिखने पर भी number सचमुच add हो जाता था), और SIM swap जैसी संभावना वाला endpoint भी मिला
    • इसे P0/S0 classify करके कुछ घंटों में patch किया गया, और $20,000 मिले
    • patch के तुरंत बाद /btz जैसे intranet-only zhandler exposure मिले; /flagz तक पहुंचने पर running service से API keys निकाली जा सकती थीं

  • AdExchange account takeover

    • एक single request से पूरी AdExchange account list dump करने वाला endpoint मिला
    • production में blocked account endpoint staging environment में बिना access control के चल रहा था, और वही staging असल production data की ओर point कर रही थी
    • किसी भी account में खुद को ADMIN जोड़ना भी संभव था; इन दो reports पर कुल $30,000 मिले

  • eldar.corp.google.com

    • internal privacy assessment management के लिए बना Googler-only site Eldar का API बाहरी दुनिया में expose था, जिससे non-Googlers internal log access requests जैसी sensitive जानकारी देख सकते थे
    • block होने के बाद भी दूसरे sandbox address से पहुंच संभव होने की अतिरिक्त सूचना दी गई; कुल $26,674 मिले

  • YouTube private video leak

    • video upload के समय बनने वाला asset name Auto generated asset - <video_id> format में था, इसलिए सिर्फ search करके private video IDs leak हो जाते थे और videos देखे जा सकते थे
    • हर 30 सेकंड में request भेजकर partner uploads के private videos का real-time feed पाया जा सकता था — कंपनियां product announcement videos पहले private upload करती हैं, इसलिए यह prediction markets में insider betting जैसी abuse संभावना पैदा करता था
    • $12,000 मिले (उत्कृष्ट report quality)

  • Widevine DRM key exposure

    • Disney, Netflix जैसी कंपनियों द्वारा इस्तेमाल किए जाने वाले दुनिया के सबसे बड़े DRM systems में से एक Widevine का partner portal API publicly accessible था
    • पूरी organization list dump की जा सकती थी, किसी खास organization की PGP और AES keys देखी और decrypt की जा सकती थीं, और खुद को arbitrary organization में जोड़कर device management तक संभव था
    • $16,004.40 मिले (उत्कृष्ट report quality)

  • plx.corp.google.com

    • employees-only internal analytics platform PLX की underlying DataHub API exposed थी, जिससे active employee info tables का metadata देखा जा सकता था
    • staging API में setIamPolicy के जरिए खुद को dataset admin जोड़कर confidential YouTube data dump करना संभव था (जिसमें 2.1PB तक की tables शामिल थीं)
    • 1 घंटे के भीतर P0/S0 माना गया; दोनों vulnerabilities पर $12,000-$12,000 मिले

Translation Hub में cross-tenant vulnerabilities

  • large-scale document translation management product Translation Hub में कई access control issues मिले
  • ListOperations OAuth token के बिना काम करता था, जिससे internal service account names, GCS bucket names, और internal table names leak हो रहे थे
  • किसी भी Google account के bearer token से translator emails, job confidential filenames जैसी दूसरे projects की जानकारी देखी जा सकती थी
  • UpdateProjectConfig से victim config को arbitrary GCS path में बदलने पर, shared service account permissions का दुरुपयोग करके private GCS objects को base64 में exfiltrate किया जा सकता था
  • इन तीन bugs पर कुल $36,500 मिले

YouTube TV CMS

  • किसी भी video को strike, claim, monetize कर सकने वाले YouTube CMS account APIs में campaign endpoint caller relationship की जांच ही नहीं करता था
  • GET /v1/campaigns बिना scoping के पूरे system के सभी campaigns global dump कर देता था, और modify, copy, delete भी सिर्फ ID के आधार पर संभव था
  • side effect के तौर पर sensitive CMS account emails भी leak हुए; $24,000 मिले (उत्कृष्ट report quality)

Vertex AI Search for Commerce

  • retail search और recommendation product के conversationalSearchCustomizationConfig में access control नहीं था, जिससे किसी भी project की settings पढ़ना और बदलना संभव था
  • read access के साथ customers के system prompts (model preambles) और internal policy notes वाले classification examples expose हो रहे थे
  • write access के साथ customer-facing search AI के system prompt में prompt injection payload डाला जा सकता था; $30,000 मिले

Cloud Console GraphQL

  • जो internal services इंटरनेट पर public नहीं थीं, वे भी proxy surface के जरिए indirectly reachable थीं, और Cloud Console (codename Pantheon) GraphQL के जरिए gRPC backends को proxy करता था

  • signature verification bypass

    • हर request में query signature (querySignature) verify किया जाता था, जिससे tampering कठिन था; लेकिन यह पता चला कि staging में unauthenticated queries पर signature verify ही नहीं होता
    • introspection से 3,448 schemas scrape करके GitHub पर archive किए गए, और "query path" concept लाकर मौजूदा AI fuzzing infra में GraphQL integrate किया गया

  • App Engine request logs

    • GetDashboardAppStats IAM verification के बिना (यहां तक कि authentication के बिना भी) किसी भी project के 24 घंटे के App Engine logs लौटा देता था
    • request URLs में password reset links, tokens वगैरह हो सकते थे; इस पर $18,000 मिले और CVE-2026-8934 assign हुआ

  • Vertex Assistant

    • 5GB frontend JS का analysis करके hidden experimental feature Vertex Assistant पहचाना गया, और DevTools से feature flag force-enable किया गया
    • इससे जुड़ी सभी queries बिना authentication सिर्फ userId से काम करती थीं, इसलिए target email जानना ही session list, पूरी conversation history देखने और बदलने के लिए काफी था; $30,000 मिले

  • Maps Platform billing credits

    • ListBillingAccountCredits permission checks के बिना काम करता था, और wildcard से कई customers की credit info लौटाता था
    • Google employees द्वारा approval के समय लिखी गई customer PII justification field में जस की तस दिख रही थी; $12,000 मिले

निष्कर्ष और सीख

  • 3 महीनों में इस setup से $500,000 से अधिक bounty मिली; प्रकाशित बातें इसका सिर्फ एक हिस्सा हैं
  • Google के ज़्यादातर bugs में sophisticated exploit नहीं, बल्कि धैर्य अहम था; वही टूटे हुए patterns बार-बार दिखे — IAM checks की कमी, unauthenticated GraphQL, production में debug endpoints, और real data की ओर point करते sandbox systems
  • AI की भूमिका novelty नहीं, बल्कि इतनी बड़ी surface पर स्पष्ट चीज़ों को बिना थके बार-बार verify करना है, जिसे इंसान अंत तक नहीं संभाल सकता
  • मुख्य सीख
    • operation_id reproduction system workflow को productive बनाने वाला निर्णायक तत्व था — one-click verification के बिना AI output बेकार noise है
    • अगर discovery docs, GraphQL SDL, और proto मिल जाएं, तो AI meaningful testing inputs समझ सकता है
    • Google की server-side surface बहुत standardized है, इसलिए infra-specific oddities को AI से abstract कर दिया जाए तो वह असली API testing पर बेहतर फोकस कर सकता है

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

1 टिप्पणियां

 
j2sus91 15 분 전

वाइब कोडिंग की वाकई एकदम नई तरह की कमाई है।