Google OAuth लॉगिन, फेल हो चुके startup का डोमेन खरीद लेने पर सुरक्षित नहीं रहता

 (trufflesecurity.com)
6 पॉइंट द्वारा GN⁺ 2025-01-15 | 3 टिप्पणियां | WhatsApp पर शेयर करें
  • Google OAuth की एक सुरक्षा खामी के कारण "Sign in with Google" authentication प्रक्रिया में गंभीर vulnerability मौजूद है
    • किसी बंद हो चुके startup का domain खरीदने के बाद, उस domain के email accounts को फिर से बनाकर SaaS services में लॉगिन किया जा सकता है
    • संवेदनशील data वाले services तक पहुंच संभव:
      • Slack, ChatGPT, Notion, Zoom, HR systems (Social Security Number सहित)
    • Google ने शुरुआती रिपोर्ट के समय इसे "intended behavior" बताते हुए fix करने से इनकार किया
  • समस्या की जड़: Google OAuth domain ownership में बदलाव का पता नहीं लगा पाता
    • domain बदलने पर नया मालिक, पहले के कर्मचारियों के accounts में वही claims लेकर लॉगिन कर सकता है
  • इस्तेमाल होने वाली बुनियादी credentials जानकारी:
    • hd (hosted domain): domain जानकारी शामिल होती है (उदाहरण: example.com)
    • email: उपयोगकर्ता का email address शामिल होता है (उदाहरण: user@example.com)
  • अगर service providers इन दो जानकारियों पर निर्भर करते हैं, तो domain ownership बदलने पर उसी account की access मिल सकती है
  • समस्या का पैमाना
    • अमेरिका में 60 लाख लोग startups में काम कर रहे हैं
    • 90% startups विफल हो जाते हैं
    • विफल हुए startups में से 50% Google Workspaces का उपयोग करते हैं
  • लगभग 100,000 विफल startup domains खरीदने के लिए उपलब्ध हैं
  • औसतन हर domain पर 10 कर्मचारी और 10 SaaS services का उपयोग → 1 करोड़ से अधिक accounts में संवेदनशील data होने की संभावना

समाधान के प्रस्ताव और Google की प्रतिक्रिया

  • Google को सुझाए गए समाधान:
    1. यूज़र के लिए unique ID: ऐसा unique user identifier जो समय के साथ न बदले
    2. Workspace के लिए unique ID: domain से जुड़ा unique workspace identifier
  • Google की शुरुआती प्रतिक्रिया:
    • सितंबर 2024 में रिपोर्ट → "fix नहीं किया जा सकता" कहकर बंद
    • दिसंबर 2024 में Shmoocon conference में प्रस्तुति के बाद Google ने फिर से समस्या की समीक्षा की
    • $1,337 का bug bounty भुगतान किया गया और fix पर काम शुरू हुआ
  • फिलहाल Google के fix के बिना इस मूल समस्या का समाधान संभव नहीं है
  • कुछ services domain match होने पर सभी users की सूची लौटा देती हैं, जिससे vulnerability और बढ़ जाती है
  • Google लॉगिन की जगह password इस्तेमाल किया जाए, तब भी उसे reset किया जा सकता है
    • startups password authentication के बजाय SSO और 2FA को अनिवार्य करते हैं
    • service providers को password reset के समय अतिरिक्त authentication मांगना चाहिए (SMS code, credit card verification)

निष्कर्ष: Google OAuth सुरक्षा की बुनियादी समस्या

  • Google के OAuth implementation में खामी के कारण domain ownership बदलने पर account takeover संभव है
  • Google ने fix पर काम शुरू कर दिया है, लेकिन मूल समाधान अभी पूरा नहीं हुआ है
  • फिलहाल लाखों अमेरिकी लोगों के data और accounts जोखिम में हैं

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

3 टिप्पणियां

 
sixmen 2025-01-15

मुझे लगता है कि जब किसी डोमेन वाले ईमेल को authentication के साधन के रूप में इस्तेमाल किया गया हो, फिर डोमेन छोड़ दिया गया हो, और उससे जुड़े SaaS को ठीक से बंद न किया गया हो, तो यह यूज़र की गलती है। लेकिन क्या इसे भी security flaw माना जाना चाहिए?
 
kargnas 2025-01-16

मैं जिस service को बना रहा हूँ, उसमें मैंने इस issue को पहले से रोक रखा है, लेकिन फिर भी मैं इस राय से सहमत हूँ.
अगर यह समस्या है, तो फिर सामान्य email के जरिए login और signup भी पूरी तरह समस्या माने जाने चाहिए. सभी जगह email को unique ID की तरह इस्तेमाल किया जाता है, और password reset verification भी email के ownership check से ही होता है.

चरम स्थिति में, अगर यह मान लें कि gmail.com, hotmail.com जैसे प्रसिद्ध domain hack हो जाएँ और domain की DNS settings का control hacker के पास चला जाए, तो स्वाभाविक रूप से दुनिया भर के सभी SaaS accounts खतरे में पड़ जाएँगे.
 
GN⁺ 2025-01-15
Hacker News राय

  • DankStartup ने कारोबार बंद कर दिया और किसी दूसरे व्यक्ति ने डोमेन खरीद लिया, जिससे पुराने अकाउंट्स तक पहुंच संभव हो गई — यह DankStartup, Microsoft और OpenAI की जिम्मेदारी का मामला लगता है

    • इसे OAuth की भेद्यता बताना उचित नहीं है

  • Google के OpenID implementation में sub claim का उपयोग करके authentication करना सही तरीका है

    • sub claim बदलने की स्थिति के लिए एक flow होना चाहिए
    • प्रस्तावित 'बदलाव-रहित unique user ID' sub claim से अलग नहीं है

  • यह DNS पर निर्भर तरीके की मूलभूत समस्या है; डोमेन expire होने के बाद नया मालिक पिछले मालिक के अधिकार पा सकता है

    • यह ईमेल पते या DNS पर निर्भर authentication systems में होने वाली समस्या है

  • Google OAuth में कोई भेद्यता नहीं है; डोमेन खरीद लेने पर उस डोमेन के सभी ईमेल addresses भी आपके नियंत्रण में आ जाते हैं

    • Google OAuth का उपयोग न करने पर भी वही परिणाम हो सकता है

  • अतीत के thehunt.com मामले का अनुभव साझा किया गया, जहां डोमेन खरीदने के बाद सभी services तक पहुंच संभव थी

    • डोमेन की स्थिति monitor करके security threats रोकने वाले startup idea का सुझाव

  • समस्या उन services की है जो sub field का उपयोग नहीं करतीं; user identification के लिए sub field का उपयोग करना चाहिए

    • sub field का उपयोग न करने वाली services को vulnerability reports भेजकर कमाई की जा सकती है

  • Google के OpenID Connect में दो immutable identifiers लागू करने का प्रस्ताव

    • sub claim और डोमेन से जुड़ी unique workspace ID

  • Google OAuth में sub claim का बदलना दुर्लभ है, इसलिए यह service implementation की समस्या होने की संभावना अधिक है

  • डोमेन खरीदने के बाद ईमेल access मिलने का अनुभव साझा किया गया

    • Google के साथ internal connection के जरिए समस्या का समाधान हुआ

  • "लाखों अकाउंट्स" का दावा इस धारणा पर आधारित है कि असफल startup अपने SAAS accounts को deactivate नहीं करते