ghrc.io पर दुर्भावनापूर्ण साइट होने का संदेह

 (bmitch.net)
1 पॉइंट द्वारा GN⁺ 2025-08-25 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • ghcr.io और ghrc.io के बीच साधारण टाइपो से हुआ भ्रम गंभीर सुरक्षा खतरा पैदा कर रहा है
  • ghrc.io पहली नज़र में सामान्य nginx सर्वर जैसा दिखता है, लेकिन अंदरूनी तौर पर OCI API की नकल करने वाली गतिविधि पकड़ी गई है
  • यह साइट www-authenticate हेडर के जरिए container clients को संवेदनशील authentication जानकारी भेजने के लिए उकसाती है
  • docker login आदि के दौरान गलती से credentials दर्ज कर देने या गलत registry का उपयोग करने पर credentials leak हो सकता है
  • अगर आपने गलत registry पर login किया है, तो पासवर्ड बदलना, PAT रद्द करना, और GitHub account में असामान्य गतिविधि की जांच करना ज़रूरी है

अवलोकन

सिर्फ एक साधारण टाइपो की वजह से अक्सर होने वाला ghcr.io और ghrc.io का भ्रम एक बेहद खतरनाक सुरक्षा समस्या पैदा कर सकता है। कई developers और teams द्वारा उपयोग किए जाने वाले GitHub Container Registry(ghcr.io) के typo version ghrc.io पर credentials चोरी करने की कोशिश पकड़ी गई है।

ghcr.io क्या है

  • ghcr.io container images और OCI artifacts के लिए एक OCI-compatible registry है
  • यह GitHub का हिस्सा है और अनगिनत open source projects में लोकप्रिय registry के रूप में इस्तेमाल होता है

ghrc.io: ऊपर से कैसा दिखता है

  • ghrc.io पर जाने पर एक साधारण nginx default page दिखाई देता है
  • सामान्य 404 error सहित बुनियादी व्यवहार एक सामान्य nginx server जैसा ही है

दुर्भावनापूर्ण गतिविधि की असली प्रकृति

  • मुख्य समस्या /v2/ prefix के तहत होने वाली OCI API calls में दिखाई देती है
  • इस path पर access करने पर, www-authenticate header और 401 response के साथ यह आधिकारिक container registry से बेहद मिलता-जुलता व्यवहार दिखाता है
  • www-authenticate: Bearer realm="https://ghrc.io/token"; header मौजूद है
  • इस header की वजह से Docker, containerd, podman, Kubernetes आदि के clients उपयोगकर्ता की authentication जानकारी को https://ghrc.io/token पर अपने-आप भेजने की कोशिश करते हैं
  • nginx की default configuration में यह header नहीं होता, इसलिए यह स्पष्ट रूप से जानबूझकर किया गया configuration है

जोखिम: credentials चोरी का परिदृश्य

  • यह पैटर्न typo-squatting आधारित credentials चोरी के हमले जैसा प्रतीत होता है
  • जोखिम केवल तब होता है जब user client ने ghrc.io के लिए credentials दर्ज किए हों या सहेजे हों
  • ऐसी परिस्थितियों के उदाहरण जिनमें वास्तविक credentials उजागर हो सकते हैं
    • docker login ghrc.io चलाने पर
    • GitHub Action में docker/login-action का उपयोग करते समय registry को ghrc.io सेट करने पर
    • Kubernetes secret में ghrc.io के लिए registry credentials सहेजकर image pull करने की कोशिश करने पर
  • सिर्फ ghrc.io पर image push/pull करने की कोशिश करने से authentication जानकारी उजागर नहीं होती (anonymous token की कोशिश के बाद error लौटता है)

प्रतिक्रिया के उपाय

  • अगर आपने गलती से ghrc.io पर login किया है, तो तुरंत पासवर्ड बदलें और इस्तेमाल किया गया PAT(Personal Access Token) रद्द करें
  • GitHub account में असामान्य login या दुर्भावनापूर्ण गतिविधि की जरूर जांच करें
  • हमलावर इसका उपयोग ghcr.io की repositories में दुर्भावनापूर्ण images जोड़ने या account access हासिल करने के लिए कर सकते हैं

निष्कर्ष

  • ghcr.io जैसे दिखने वाले पते का उपयोग करने वाली phishing sites से सावधान रहने की ज़रूरत है
  • credentials, tokens, passwords जैसी सुरक्षा जानकारी के प्रबंधन के लिए और अधिक सख्त नीति अपनानी चाहिए

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

2 टिप्पणियां

 
ndrgrd 2025-08-25

क्या इसे बस github.com के subdomain में बदल देना बेहतर नहीं होगा?
 
GN⁺ 2025-08-25
Hacker News राय

  • यह रेखांकित किया गया कि GitHub Container registry granular token की बजाय सिर्फ पुराने classic token को सपोर्ट करता है, जो गंभीर समस्या है
    संबंधित दस्तावेज़ और issue links भी जोड़े गए हैं
    आधिकारिक दस्तावेज़
    कम्युनिटी चर्चा
    रोडमैप issue

    • इस समस्या की वजह से classic PAT को पूरी तरह बंद नहीं किया जा सकता
      अतिरिक्त सुरक्षा उपाय के तौर पर session validity कम रखना और enterprise SSO से re-authentication अनिवार्य करना एक तरीका हो सकता है, लेकिन वास्तव में ज़रूरी एकमात्र classic PAT के लिए यह काफ़ी असुविधाजनक विकल्प है

    • अच्छा होगा अगर कोई सद्भावना से सारे typo domains खरीदकर Microsoft को सौंप दे
      उनका मानना है कि Microsoft को registry का नाम बदल देना चाहिए
      नाम इतना भ्रमित करने वाला है कि उन्होंने खुद भी कई बार typo किया है

  • domain issue को कई बार पढ़ने के बाद ही समस्या समझ में आई, यानी यह काफ़ी विश्वसनीय attack vector है

    • सिर्फ मैं ही नहीं, कई और लोग भी इसी तरह उलझे
      कई बार कोशिश करके असफल हुए, यहाँ तक कि कंप्यूटर restart करने के बाद भी वही समस्या रही
      संदर्भ के लिए stackoverflow उत्तर और Docker फ़ोरम चर्चा भी दी गई है

  • ghrc.io से जुड़े code search results का लिंक साझा किया गया

  • लेख में c और r के उलट होने की बात सीधे बताने तक उन्हें समस्या का पता ही नहीं चला

    • यह वैसी typo है जो वे दिन में लगभग 10 बार तक कर देते हैं

    • यहाँ असली समस्या यह है कि GitHub का domain name ही अव्यवस्थित है
      container registry का नाम सचमुच बहुत खराब है

  • पुरानी Hacker News चर्चा का लिंक साझा किया गया

  • whois से पुष्टि की जा सकती है कि यह domain dynadot पर registered है
    इसलिए abuse@dynadot.com पर रिपोर्ट करना उपयोगी हो सकता है

  • यह बताया गया कि कई open source projects इस domain का इस्तेमाल कर रहे हैं, और code search results फिर से साझा किए गए

    • GitHub के अंदर ऐसे tools की ज़रूरत है जो बड़े पैमाने पर auto-fix suggestions दे सकें और उन्हें deploy भी कर सकें

    • यह भी कहा गया कि GitHub code search results का पैमाना वास्तव में काफी बड़ा है

  • CI jobs में typo होने पर बड़ी समस्या खड़ी हो सकती है, ऐसी चिंता जताई गई

  • सलाह दी गई कि सुरक्षा के लिहाज़ से कम मूल्य वाले TLD का इस्तेमाल जहाँ तक हो सके टालना चाहिए
    प्यारा दिखने की कोशिश से ज़्यादा सुरक्षा अहम है
    उनका मानना है कि malicious domain takedown शायद .com जितनी तेजी से न हो, इसलिए US की Verisign द्वारा प्रबंधित .com ज़्यादा भरोसेमंद लगता है
    British Indian Ocean Territory, Colombia या Anguilla जैसे क्षेत्रों पर निर्भर रहना उचित नहीं है

    • यह भी जोड़ा गया कि .io TLD का प्रबंधन अमेरिकी कंपनी Afilias करती है

  • पूछा गया कि यहाँ असली सुरक्षा जोखिम token reuse का है क्या
    Bearer token सीधे password नहीं देता, और RFC व Mozilla दस्तावेज़ों का हवाला देते हुए यह सवाल उठाया गया कि असली समस्या authentication token खुद नहीं बल्कि authentication के लिए दोबारा token पाने की प्रक्रिया है क्या
    अगर domains के बीच OAuth token को reuse नहीं करता, तो क्या नकली domain को आख़िरकार token मिल ही नहीं पाएगा

    • ब्लॉग लेखक और OCI maintainer के रूप में जवाब दिया गया
      Bearer token पाने के अनुरोध में password या PAT को basic auth header में base64 encoding के साथ भेजा जाता है, लेकिन व्यवहार में यह लगभग plain text की तरह ही भेजा जाता है
      अनुरोध मिलने पर www-authenticate header आता है, फिर authentication token लेकर registry access सत्यापित किया जाता है, और उसके बाद token expire हो जाता है, लेकिन
      हमलावर असली token चुराने की कोशिश नहीं करता, बल्कि Bearer token पाने के लिए इस्तेमाल होने वाले credentials ही मंगवा लेता है