यही चूक हमलावर के लिए रास्ता खोलती है। अगर कोई हमलावर अपनी ब्रांच का नाम कुछ ऐसा रखता है जैसे --exec='ख़तरनाक कमांड'git rebase--exec फ्लैग को हर कमिट के रिप्ले होने के बाद एक शेल कमांड चलाने के लिए डिज़ाइन किया गया है। इसका नतीजा यह होता है कि हमलावर गॉग्स सर्वर प्रक्रिया के विशेषाधिकारों के साथ, ऑपरेटिंग सिस्टम पर पूरी तरह से मनमाने कमांड चला सकता है।
हमले का ब्यौरा एक नज़र में:
--exec फ्लैग और उसके बाद अपना मनचाहा शेल कमांड इंजेक्ट करता है। रैपिड7 लैब्स (Rapid7 Labs) के लिए इस खामी को खोजने वाले सुरक्षा शोधकर्ता जोनाह बर्गेस ने इसकी प्रक्रिया को साफ़ शब्दों में समझाया: "यह भेद्यता किसी भी प्रमाणित उपयोगकर्ता को एक ख़ास ब्रांच नाम के साथ पुल रिक्वेस्ट बनाकर सर्वर पर रिमोट कोड एक्ज़ीक्यूशन (RCE) हासिल करने की अनुमति देती है, जो git rebase--exec फ्लैग को इंजेक्ट करता है।"
जो लोग गॉग्स प्रोजेक्ट पर नज़र रखते रहे हैं, उनके लिए यह गंभीर अनपैच्ड ज़ीरो-डे कोई आश्चर्य की बात नहीं है। यह एक बहु-वर्षीय पैटर्न का सबसे ताज़ा और गंभीर उदाहरण है, जिसमें प्रोजेक्ट के प्राथमिक—और व्यवहार में, एकमात्र—मेंटेनर की ओर से सुरक्षा रिपोर्टों पर पूरी तरह से चुप्पी साध ली जाती है।
इस उपेक्षा की समय-रेखा कई स्वतंत्र अनुसंधान टीमों द्वारा अच्छी तरह से प्रलेखित है:
इस इतिहास ने रैपिड7 के इस ताज़ा खुलासे को एक सामान्य सुरक्षा एडवाइज़री से कहीं अधिक बना दिया है। जैसा कि एक उद्योग आउटलेट ने कहा, यह स्थिति "ओपन सोर्स प्रोजेक्ट्स की सीमाओं की याद दिलाती है" जब वे एक अकेले, अनुत्तरदायी मेंटेनर पर निर्भर हों । बिना किसी प्रभावी मल्टी-स्टेकहोल्डर गवर्नेंस के, व्यापक रूप से उपयोग किया जाने वाला एक महत्वपूर्ण बुनियादी ढांचा एक स्थायी जोखिम बन सकता है।
चूंकि कोई सॉफ़्टवेयर पैच उपलब्ध नहीं है, एडमिनिस्ट्रेटरों को अटैक वेक्टर को बेअसर करने के लिए कॉन्फ़िगरेशन बदलावों और नेटवर्क-स्तरीय नियंत्रणों पर निर्भर रहना होगा। निम्नलिखित कदम तत्काल ख़तरे को रोकते हैं और अटैक सरफ़ेस को कम करते हैं।
1. 'रिबेस बिफोर मर्जिंग' को तुरंत अक्षम करें
यह सबसे प्रभावी उपाय है। पूरी अटैक चेन इसी विशिष्ट मर्ज स्टाइल पर निर्भर करती है। रिपॉजिटरी या इंस्टेंस-वाइड सेटिंग्स को "मर्ज कमिट" (Merge commit) या "स्क्वॉश" (Squash) में बदलने से कमज़ोर कोड पाथ पूरी तरह से समाप्त हो जाता है ।
2. नेटवर्क की पहुंच को प्रतिबंधित करें
इस हमले के लिए पुल रिक्वेस्ट बनाने के लिए प्रमाणित HTTP पहुंच की आवश्यकता होती है। यदि आपके गॉग्स सर्वर को सार्वजनिक होने की आवश्यकता नहीं है, तो इसे किसी VPN या फ़ायरवॉल के पीछे ले जाएं जो केवल विश्वसनीय आंतरिक उपयोगकर्ताओं को ही अनुमति देता है। यह प्लैटफ़ॉर्म को बड़े पैमाने पर इंटरनेट स्कैनर्स और सामान्य हमलावरों से हटा देता है।
3. उपयोगकर्ता पंजीकरण और अनुमतियों को कड़ा करें
चूंकि कोई भी प्रमाणित उपयोगकर्ता इस खामी का फायदा उठा सकता है, सर्वर पर खातों की संख्या को न्यूनतम करना एक महत्वपूर्ण बचाव है। स्व-पंजीकरण अक्षम करें और नए उपयोगकर्ताओं को मैन्युअल रूप से स्वीकृति दें। अपनी उपयोगकर्ता सूची का तुरंत ऑडिट करें और किसी भी पुराने या अज्ञात खाते को निष्क्रिय करें ।
4. विसंगतियों के लिए पुल रिक्वेस्ट की निगरानी करें
पुल रिक्वेस्ट ब्रांच नामों के लिए आक्रामक निगरानी लागू करें जिनमें संदिग्ध अक्षर हों, जिनमें डबल डैश (--), सेमीकोलन, बैकटिक, या exec, curl, या wget जैसे स्पष्ट शेल कमांड टोकन शामिल हों। एक असामान्य ब्रांच नाम एक सक्रिय एक्सप्लॉइट प्रयास का एक मजबूत संकेतक है ।
5. गॉग्स से बाहर निकलने की दीर्घकालिक योजना बनाएं
अनपैच्ड गंभीर कमज़ोरियों के प्रलेखित पैटर्न को देखते हुए, गॉग्स पर निरंतर निर्भरता एक सामरिक जोखिम है। सबसे व्यवहार्य विकल्प गिटिया (Gitea) है, जो गॉग्स का एक समुदाय-संचालित फ़ोर्क है, जिसमें एक मजबूत, मल्टी-मेंटेनर डेवलपमेंट टीम और एक उत्तरदायी सुरक्षा प्रक्रिया है। कई अन्य प्रमुख गिट सर्विस प्लेटफ़ॉर्म मौजूद हैं, लेकिन उन टीमों के लिए जिन्होंने गॉग्स को विशेष रूप से इसकी हल्की, सेल्फ-होस्टेड प्रकृति के लिए चुना था, गिटिया एक नियर-ड्रॉप-इन रिप्लेसमेंट है जो एकल-मेंटेनर अड़चन को समाप्त करता है ।
6. एक पैच के लिए तैयार रहें (यदि कभी आता है)
गॉग्स सुरक्षा पृष्ठ और गिटहब रिलीज़ की सदस्यता लेते रहें। यदि अंततः कोई पैच प्रकाशित होता है, तो तुरंत अपग्रेड करें। हालाँकि, अपनी सुरक्षा स्थिति की योजना इस धारणा के तहत बनाएं कि यह पैटर्न दोहराएगा, और भविष्य में कोई गंभीर भेद्यता फिर से महीनों तक बिना सुधार के पड़ी रहेगी।
Comments
0 comments