Home Depot का GitHub टोकन 1 साल तक एक्सपोज़ रहा, जिससे इंटरनल सिस्टम्स तक पहुंच संभव थी

• एक security researcher ने पाया कि Home Depot के एक कर्मचारी ने गलती से एक GitHub access token ऑनलाइन पोस्ट कर दिया था, जिसके कारण 1 साल तक उसके इंटरनल सिस्टम्स बाहर से एक्सपोज़ रहे
• यह टोकन सैकड़ों private source code repositories तक पहुंच और उनमें बदलाव की अनुमति देता था, और cloud infrastructure, order processing, inventory management systems आदि तक भी पहुंच संभव थी
• शोधकर्ता ने Home Depot को कई बार email और LinkedIn messages भेजे, लेकिन कई हफ्तों तक कोई जवाब नहीं मिला
• Home Depot ने TechCrunch के संपर्क करने के बाद ही एक्सपोज़र को ठीक किया और टोकन की access वापस ली
• Home Depot के पास vulnerability reporting या bug bounty program नहीं है, जिससे यह घटना security response system की कमी को उजागर करती है

---

Home Depot इंटरनल सिस्टम एक्सेस एक्सपोज़र घटना का सार

• एक security researcher ने पाया कि Home Depot के एक कर्मचारी ने ऑनलाइन एक private access token पोस्ट कर दिया था
  • माना जा रहा है कि यह टोकन 2024 की शुरुआत से एक्सपोज़ था
  • शोधकर्ता ने पुष्टि की कि इसके जरिए Home Depot की सैकड़ों GitHub repositories तक पहुंच और उनमें बदलाव संभव था
• एक्सपोज़ हुई key से Home Depot के cloud infrastructure, order processing system, inventory management system, code development pipeline सहित कई इंटरनल सिस्टम्स तक पहुंच मिल रही थी
  • Home Depot 2015 से अपने अधिकांश development और engineering infrastructure को GitHub पर host कर रहा है

शोधकर्ता की चेतावनी और कंपनी की प्रतिक्रिया

• शोधकर्ता Ben Zimmermann ने Home Depot को कई बार email भेजे, लेकिन कई हफ्तों तक कोई जवाब नहीं मिला
  • उन्होंने Home Depot के chief information security officer (CISO) Chris Lanzilotta को LinkedIn message भी भेजा, लेकिन कोई जवाब नहीं मिला
• Zimmermann ने बताया कि पिछले कुछ महीनों में उन्होंने दूसरी कंपनियों में भी ऐसे ही एक्सपोज़र देखे, और ज्यादातर कंपनियों ने आभार जताया
  • उनके अनुसार, “सिर्फ Home Depot ने मुझे नज़रअंदाज़ किया”

TechCrunch के हस्तक्षेप के बाद की कार्रवाई

• Home Depot के पास vulnerability disclosure या bug bounty program मौजूद नहीं है
  • इसलिए Zimmermann ने समस्या के समाधान के लिए TechCrunch से संपर्क किया
• TechCrunch ने 5 दिसंबर को Home Depot के प्रवक्ता George Lane से संपर्क किया, जिन्होंने email मिलने की पुष्टि की, लेकिन बाद के अतिरिक्त सवालों का जवाब नहीं दिया
• इसके बाद एक्सपोज़ टोकन को ऑनलाइन से हटा दिया गया, और access permission भी TechCrunch के संपर्क के तुरंत बाद वापस ले ली गई

अतिरिक्त पुष्टि का अनुरोध और कोई जवाब नहीं

• TechCrunch ने पूछा कि क्या Home Depot logs जैसे technical means के जरिए यह पता कर सकता है कि उस टोकन का इस्तेमाल किसी और ने किया था या नहीं, लेकिन कोई जवाब नहीं मिला
• इसके कारण वास्तविक external access हुआ था या नहीं, और नुकसान कितना हुआ, यह अब भी स्पष्ट नहीं है

घटना का महत्व

• यह मामला दिखाता है कि बड़ी कंपनियों में भी basic access key management failure लंबे समय तक अनदेखी रह सकती है
• यह भी सामने आता है कि security vulnerability reporting system की कमी समस्या के समाधान में देरी कर सकती है
• TechCrunch के हस्तक्षेप के बाद ही कार्रवाई होने से external oversight के महत्व पर जोर पड़ता है

[GN⁺]

Hacker News की टिप्पणियाँ

• TechCrunch ने Home Depot से उजागर हुए access token के बारे में पूछा, लेकिन कंपनी ने मामला legal team को भेज दिया और फिर मानो चुप्पी साध ली
  शायद आगे आने वाला आधिकारिक बयान कानूनी भाषा से भरे, ज़िम्मेदारी से बचने वाले वाक्यों का होगा

  • इसलिए मैं भी ऐसे मामलों में सीधे डाक से legal team से संपर्क करता हूँ
    मामला सच में कानूनी हो सकता है, इसलिए वहाँ ऐसे लोग जवाब देते हैं जो पढ़कर कार्रवाई कर सकें
    पहले एक बार बैंक ने identity verification की समस्या के कारण मुझसे संपर्क तोड़ दिया था, तब भी एक चिट्ठी से मामला तुरंत सुलझ गया था
  • आज जैसे litigation risk वाले माहौल में Home Depot की प्रतिक्रिया व्यवहारिक रूप से सही लगती है
    बेशक हम internal analysis report देखना चाहेंगे, लेकिन shareholder-केंद्रित दुनिया में सावधानी बरतना लाज़िमी है

• पिछले हफ्ते मुझसे गलती से मेरे OpenAI, Anthropic, Gemini API keys उजागर हो गए
  Claude Code log में keys सीधे छप गए थे, और Anthropic ने तुरंत मेल भेजकर key disable कर दी
  जबकि OpenAI और Google की तरफ से कोई सूचना नहीं आई
  खासकर Google की Gemini key ढूँढने में ही 10~15 मिनट लग गए, और वह तब भी active दिख रही थी
  आजकल जितनी ज़्यादा vibe coding हो रही है, उतना ही issuer और user दोनों के लिए key hygiene महत्वपूर्ण हो गया है

  • इतनी बारीक key management बढ़ती जा रही है कि उल्टा security anxiety बढ़ती है, और समझ ही नहीं आता कि हम क्या कर रहे हैं
  • “vibe coding” शब्द सुनते ही रोंगटे खड़े हो जाते हैं
    पहले ही brogramming की वजह से बहुत security incidents होते हैं, और यह उसे 100 गुना बढ़ा सकता है
  • जिज्ञासा है कि key लीक कैसे हुई
    अगर बस Claude Code log में रह गई थी, तो Google ने उसे पहचान लिया, यह हैरान करने वाली बात है

• मैंने भी पहले अपना निजी GitHub PAT गलती से public repository में डाल दिया था
  हर बार GitHub ने तुरंत token disable किया और notification भेजी

  • GitHub का automatic token detection feature काफ़ी प्रभावशाली लगा
    मेरे मामले में बड़ा नुकसान नहीं हुआ, लेकिन system ने सही काम किया

• “Home Depot 2x4” वाले मज़ाक की तरह, अगर कोई एक साल तक मनमर्जी से सामान ले सकता, तो शायद कोई लकड़ी का गोला ही बना देता

  • लेकिन लकड़ी deep sea environment में कितना टिकेगी, यह पता नहीं

• secrets management कैसे करना चाहिए, इस पर सोच रहा हूँ
  अभी तो मैं manually SSH से login करके .env file edit करता हूँ

  • अगर single app है, तो .env file भी काफ़ी है
    वैसे भी app compromise हो जाए तो secret memory में रहेगा, इसलिए exposure पूरी तरह टाला नहीं जा सकता
    अगर संभव हो, तो IP-based access restriction लगाना सबसे मज़बूत बचाव है
  • SOPS इस्तेमाल करें तो management scope कम हो सकता है
    backend के रूप में Age इस्तेमाल करें तो server पर सिर्फ एक long-term private key रखनी पड़ती है
  • या फिर VM platform के native secret feature या 1Password API का इस्तेमाल भी एक तरीका है

• किसी ने पूछा, “उस जानकारी से आखिर क्या नुकसान किया जा सकता था?”

  • पूरा internal source code download करके vulnerabilities का विश्लेषण किया जा सकता था, या
    अगर deployment के लिए GitHub इस्तेमाल होता हो, तो production में malicious functionality डाली जा सकती थी
  • उदाहरण के लिए Atlas Lion नाम का hacking group बड़े retailers के internal systems को निशाना बनाकर
    gift card theft से कमाई कर रहा है
    हाल में Salesloft के GitHub के रास्ते AWS में घुसकर OAuth token चुराने और सैकड़ों Salesforce customer accounts तक पहुँचने का मामला भी सामने आया है

• किसी public string के सच में API key होने या सिर्फ किसी random value होने में फर्क करना मुश्किल होता है

  • इसलिए आजकल कई services key के आगे pat_, sk_ जैसे prefix लगाती हैं

• “Open Source Home Depot” वाक्यांश अजीब तरह से फिट बैठता है

• यह हैरानी की बात है कि GitHub या OpenAI खुद से token hash scanning automation नहीं देते
  customer safety के लिए इसे आसानी से implement किया जा सकता है
  platform-independent scanning service बनाने का सुझाव दिया गया

  • GitHub पहले से secret scanning program चला रहा है
    पहले Discord token उजागर होते ही वह तुरंत disable हो जाता था और system account DM भेजता था
  • GitHub की scanning काफ़ी sophisticated है
    official docs के अनुसार
    यह प्रमुख providers के pattern को automatically verify करती है और ज़रूरत पड़ने पर token revoke भी करती है
    हालाँकि GitHub के बाहर उजागर हुए tokens का पता लगाना कठिन है
  • फिर भी अब भी miss होने वाले cases बहुत हैं
    मैं bug bounty program के ज़रिए अक्सर leaked keys report करता हूँ
    अफ़सोस की बात है कि Home Depot का bug bounty नहीं है
  • जिज्ञासा है कि token public repository commit में मिला था या नहीं
    GitHub का free scanner भी इसे आसानी से detect कर सकता है
  • GitHub ने कई SaaS/PaaS कंपनियों के साथ automatic token verification and revocation partnership की हुई है

• किसी ने यह भी कहा कि इस internal system data से insider trading जैसी चीज़ें भी की जा सकती थीं