सतत एकीकरण और सतत परिनियोजन (CI/CD) pipelineसॉफ्टवेयर विकास को सुव्यवस्थित बनाने में इनकी महत्वपूर्ण भूमिका होती है। फिर भी, जैसे-जैसे ये pipelineजैसे-जैसे इनकी अहमियत बढ़ती जा रही है, इन्हें कमजोरियों से बचाने की अनिवार्यता और भी स्पष्ट होती जा रही है। यह गहन जांच OWASP टॉप-10 में पहचाने गए एक प्रमुख जोखिम को संबोधित करने पर केंद्रित है। CI/CD सुरक्षा जोखिम: विषैला Pipeline निष्पादन (पीपीई)।
जहर क्या है? Pipeline निष्पादन (पीपीई)
OWASP टॉप-10 के अनुसार CI/CD सुरक्षा जोखिम, “जहर Pipeline निष्पादन (पीपीईजोखिम से तात्पर्य स्रोत नियंत्रण प्रणालियों तक पहुंच रखने वाले और बिल्ड वातावरण तक पहुंच न रखने वाले हमलावर की क्षमता से है। बिल्ड प्रक्रिया में दुर्भावनापूर्ण कोड/कमांड डालकर उसमें हेरफेर करना। pipeline विन्यास, अनिवार्य रूप से 'ज़हर' देना pipeline और निर्माण प्रक्रिया के हिस्से के रूप में दुर्भावनापूर्ण कोड चलाना।
संक्षेप में कहें तो, ज़हर Pipeline निष्पादन (पीपीई) तब उत्पन्न होता है जब हमलावर इसे संशोधित कर सकता है pipeline तर्क.
वहाँ दॊ है वेरिएंट:
- प्रत्यक्ष पीपीई (डी-पीपीई): डी-पीपीई परिदृश्य में, हमलावर CI कॉन्फ़िगरेशन फ़ाइल को संशोधित करता है वे उस रिपॉजिटरी में बदलाव कर सकते हैं जिस तक उनकी पहुंच है, या तो सीधे रिपॉजिटरी पर एक असुरक्षित रिमोट ब्रांच में बदलाव को पुश करके, या किसी ब्रांच या फोर्क से बदलाव के साथ एक पीआर सबमिट करके। चूंकि सीआई pipeline निष्पादन संशोधित CI कॉन्फ़िगरेशन फ़ाइल में दिए गए कमांड द्वारा परिभाषित होता है, हमलावर के दुर्भावनापूर्ण कमांड अंततः बिल्ड नोड में चलते हैं। pipeline शुरू हो रहा है।
- अप्रत्यक्ष पीपीई (आई-पीपीईकुछ मामलों में, डी-पीपीई की संभावना उस विरोधी के लिए उपलब्ध नहीं होती जिसके पास पहुंच होती है। SCM रिपॉजिटरी (उदाहरण के लिए यदि pipeline इसे इस तरह से कॉन्फ़िगर किया गया है कि यह CI कॉन्फ़िगरेशन फ़ाइल को उसी रिपॉज़िटरी में एक अलग, सुरक्षित शाखा से खींचे। ऐसे परिदृश्य में, जहर देने के बजाय pipeline हमलावर स्वयं ही उन फ़ाइलों में दुर्भावनापूर्ण कोड इंजेक्ट करता है जिनका संदर्भ दिया गया है। pipeline (उदाहरण के लिए: स्क्रिप्ट्स जिन्हें भीतर से संदर्भित किया गया है) pipeline कॉन्फ़िगरेशन फ़ाइल)
दोनों मामलों में, GitHub संशोधित संस्करण को निष्पादित करेगा। pipeline पूर्व समीक्षा या अनुमोदन की कोई आवश्यकता नहीं है.
पीपीई की शीघ्र पहचान
हम इस प्रकार की सुरक्षा खामी का पता कैसे लगा सकते हैं?
आइए इस उदाहरण को देखें pipeline :
और एक डमी शेल स्क्रिप्ट (runtests.sh) की सामग्री:
RSI pipeline यह काफी सरल है: इसका उद्देश्य समीक्षक को कुछ प्रारंभिक संकेत प्रदान करना है। Pull Request (पीआर) स्वीकृति प्रक्रिया:
- यह चालू हो जाएगा पुल अनुरोध (यानी जब भी कोई पीआर बनाया जाता है)
- यह पीआर कोड (यानी योगदानित कोड) की जाँच करता है।
- इससे निर्माण आसान हो जाएगा।
- यह योगदान किए गए कोड पर परीक्षण चलाएगा (उदाहरण के लिए, एक शेल स्क्रिप्ट को निष्पादित करके)।
यदि कोड कंपाइल नहीं होता है या टेस्ट में फेल हो जाता है, तो चरण #3 (बिल्ड बनाना) और #4 (टेस्ट चलाना) विफल हो जाएंगे। इसलिए, ये चरण पीआर को स्वीकार करने के लिए एक आवश्यक शर्त हैं, लेकिन पर्याप्त नहीं। सफल होने पर, रिपॉजिटरी एडमिन योगदान किए गए कोड की समीक्षा करेगा और उसके आधार पर, वह पीआर को स्वीकार/अस्वीकार करेगा/उस पर टिप्पणी करेगा।
ज़ाइगेनी स्कैनर
ज़ायजेनी एक CLI प्रदान करता है ( “ज़ाइगेनी स्कैनर”) जिसे इसमें एम्बेड किया जा सकता है pipeline या फिर कमांड लाइन में चलाएं। Xygeni स्कैनर इसे प्रोसेस करेगा। pipelineयह सुरक्षा खामियों की जांच करने के लिए है और यदि GitHub PAT प्रदान किया जाता है, तो यह संगठन/रिपॉजिटरी स्तर पर सुरक्षा खामियों का पता लगाने के लिए GitHub से कनेक्ट होगा।
ज़ाइगेनी सूची
जब हम इस रिपॉजिटरी पर Xygeni स्कैनर चलाते हैं, तो यह उपयोगी संपत्तियों का एक सेट खोजता है ( ज़ाइगेनी सूचीइस सूची में कई अलग-अलग प्रकार की वस्तुएं शामिल होंगी। CI/CD आस्तियों, जैसे:
- RSI SCM प्रणाली जहां रिपॉजिटरी संग्रहीत है
- RSI SCM प्लगइन्स स्थापित/उपयोग किया गया
- RSI कोड रिपोजिटरी खुद
- RSI SCM संगठन" जहां रिपॉजिटरी संबंधित है
- RSI CI/CD Pipelineऔर नौकरियाँ
- RSI CI/CD प्रणाली दौड़ रहा है pipelines
- IaC संसाधन रिपॉजिटरी में परिभाषित
- बाहरी निर्भरता
- आदि ..
हमारे उदाहरण में, हम किसी विशिष्ट परिसंपत्ति प्रकार के आधार पर इन्वेंट्री को फ़िल्टर कर सकते हैं (SCM- और सीआईसीडी-संबंधित संपत्तियां), इसलिए हम देख सकते हैं कि:
- SCM यह सिस्टम GitHub क्लाउड है।
- रिपॉजिटरी GitHub क्लाउड में संग्रहीत होती है और एक विशिष्ट GitHub संगठन से संबंधित होती है।
- वहाँ दॊ है pipelineयह GitHub द्वारा संचालित है (CI/CD प्रणाली)
- प्रत्येक pipeline इसमें एक विशिष्ट चरण शामिल है
ऊपर दिए गए विकल्प का चयन करके pipeline हमें कुछ कमजोरियां दिखाई दे सकती हैं:
- At pipeline इस स्तर पर, यह दोनों के प्रति संवेदनशील है प्रत्यक्ष और अप्रत्यक्ष पीपीई।
हम उन लोगों के बारे में जानकारी देख सकते हैं जिन्हें जहर दिया गया था। Pipeline निष्पादन संबंधी कमजोरियाँ
Xygeni को पता चलता है कि यह डी-पीपीई के प्रति संवेदनशील क्योंकि यह एक पर ट्रिगर होता है Pull Request इस इवेंट में कोई अतिरिक्त सुरक्षा नियंत्रण नहीं हैं, इसलिए कोई भी रेपो उपयोगकर्ता इसे संशोधित कर सकता है। pipeline और ये संशोधन बिना किसी समीक्षा या अनुमोदन के लागू किए जाएंगे।
इसी तरह, Xygeni भी यह पता लगाता है कि यह आई-पीपीई के प्रति संवेदनशील शेल स्क्रिप्ट को कॉल करने के कारण pipeline: कोई भी रिपॉजिटरी उपयोगकर्ता शेल स्क्रिप्ट को संशोधित कर सकता है और वे संशोधन बिना किसी समीक्षा या अनुमोदन के निष्पादित किए जाएंगे।
क्या आप और जानना चाहते हैं?
पीपीई का शोषण
पीपीई का लाभ उठाने के लिए, आइए एक ऐसे परिदृश्य पर विचार करें जहां दो प्रकार के रिपॉजिटरी उपयोगकर्ता:
- An आंतरिक उपयोगकर्ता (उस रिपॉजिटरी पर काम करने वाला एक आंतरिक डेवलपर), जिसके पास रिपॉजिटरी पर लिखने की अनुमति है।
- An बाह्य उपयोगकर्ता (एक आउटसोर्स डेवलपर उस रिपॉजिटरी पर काम कर रहा है लेकिन उसके पास रिपॉजिटरी पर केवल पढ़ने की अनुमति है), यानी उसे रिपॉजिटरी की ब्रांच बनाने की अनुमति नहीं है और उसे एक फोर्क पर काम करने के लिए मजबूर किया जाता है।
मान लीजिए कि दोनों दुर्भावनापूर्ण हमलावर हैं (या किसी दुर्भावनापूर्ण व्यक्ति द्वारा प्रतिरूपित हैं)। रिपॉजिटरी में कुछ गुप्त जानकारी है और दोनों उसे हासिल करना चाहते हैं। रिपॉजिटरी का गुप्त रहस्य चुराने के लिए और इसे हैकर-नियंत्रित सर्वर पर भेज देंगे। ऐसा करने के लिए, वे पॉइज़न्ड का फायदा उठाएंगे। Pipeline निष्पादन संबंधी कमजोरियाँ pipeline.
दोनों ही मामलों में (बाहरी और आंतरिक उपयोगकर्ता), वे एक फ़ाइल खोलते हैं। Pull Request उन्हीं संशोधनों के साथ:
- RSI pipeline और शेल स्क्रिप्ट को संशोधित किया गया है सेवा मेरे रहस्य पढ़ें पर्यावरण से और इसे हैकर-नियंत्रित सर्वर पर भेजें
संशोधन निम्न प्रकार के हो सकते हैं:
दोनों उपयोगकर्ता एक बनाएंगे Pull Request संशोधनों के साथपीआर बनने पर, GitHub दोनों संशोधनों को निष्पादित करेगा। (पूर्व समीक्षा या अनुमोदन की आवश्यकता के बिना)परिणामस्वरूप निम्नलिखित हुआ:
लिखने और पढ़ने वाले उपयोगकर्ताओं के लिए भी यही बात लागू होती है। दोनों ही मामलों में डी-पीपीई और आई-पीपीई लागू किए जाते हैं।अंतर यह है कि रीड यूजर सीक्रेट्स तक पहुंच नहीं सकता। (!!!!)
इसका कारण यह है कि, फोर्क से आने वाले पीआर के मामले में, गिटहब रेपो सीक्रेट्स तक पहुंच की अनुमति नहीं देता है। हालांकि रीड यूजर सीक्रेट्स को नहीं पढ़ सकता, फिर भी वह कोई भी अन्य प्रोग्राम चला सकता है। हमले का एक आम उदाहरण क्रिप्टो माइनर डाउनलोड करने वाले पीआर बनाना है, ताकि GitHub रनर किसी दूषित प्रोग्राम को चलाते समय क्रिप्टो माइनर को निष्पादित कर सके। pipeline.
यह बिल्कुल भी सुरक्षित वातावरण नहीं है!! इससे बचने के लिए रिपॉजिटरी एडमिन क्या कर सकता है?
कुछ गूगल सर्च करने के बाद, रिपॉजिटरी एडमिन ने इसमें बदलाव करने का फैसला किया। pipeline किसी पर सक्रिय होने के लिए पुल_अनुरोध_लक्ष्य घटना। क्यों? क्योंकि pipelinepull_request_target पर ट्रिगर होने वाले s निष्पादन की अनुमति नहीं देते हैं pipeline संशोधनोंयानी उपयोगकर्ता द्वारा किए गए किसी भी संशोधन के बावजूद "मूल" pipeline निष्पादित किया जाएगा।
हमारे उदाहरण का अनुसरण करते हुए, हमला पहले जैसा ही होगा। इसके बाद क्या होगा? pipeline संशोधन?
जैसा सोचा था, डी-पीपीई निष्पादित नहीं किया गया है लेकिन, चूंकि आई-पीपीई अभी भी मौजूद है, रीड यूजर अब रेपो सीक्रेट तक पहुंच सकता है!!!
अब रीड यूजर को सीक्रेट्स तक पहुंच क्यों मिल गई है? हालांकि pipeline इसे संशोधित नहीं किया जा सकता है, फिर भी शेल स्क्रिप्ट को संशोधित करना संभव है। जब pipeline यदि pull_request_target पर ट्रिगर होता है, तो इसे विशेषाधिकार प्राप्त मोड में निष्पादित किया जाएगा। so यह शेल स्क्रिप्ट भी होगीजिसके परिणामस्वरूप शेल स्क्रिप्ट को रिपॉजिटरी सीक्रेट्स तक पहुंच प्राप्त हो जाती है!!
निवारक उपाय
GitHub दुर्भावनापूर्ण PR से सुरक्षा के लिए कुछ उपाय प्रदान करता है।
शाखा सुरक्षा नियम
GitHub की मदद से आप चुनिंदा शाखाओं पर शाखा सुरक्षा नियम परिभाषित कर सकते हैं।
आप अपनी संरक्षित शाखाओं के लिए एक नीति निर्दिष्ट कर सकते हैं जो आवश्यकता है एक pull request विलय से पहले (साथ ही अतिरिक्त शर्तें जैसे कि आवश्यक संख्या में अनुमोदन, कोड मालिकों से समीक्षा आदि।)
कुछ ऐसी स्थितियाँ हैं जिन पर विशेष ध्यान देने की आवश्यकता है:
- "निर्दिष्ट अभिनेताओं को आवश्यक को बायपास करने की अनुमति दें pull requests".
- "उपरोक्त सेटिंग्स को दरकिनार करने की अनुमति न दें"
जबकि अधिकांश शर्तें नीति को और अधिक सख्त बनाती हैं, ये शर्तें नीति को शिथिल करती हैं और इससे दुर्भावनापूर्ण गतिविधियों के लिए एक खुला द्वार खुल सकता है, उदाहरण के लिए, यदि "विशेषाधिकार प्राप्त" व्यक्तियों द्वारा क्रेडेंशियल चुरा लिए जाते हैं।
GITHUB_TOKEN की अनुमतियों को प्रतिबंधित करें (न्यूनतम विशेषाधिकार)
GitHub टोकन की अनुमतियों को केवल आवश्यक तक ही सीमित रखें; इस तरह, हमलावर आपके सिस्टम को हैक करने में सफल भी हो जाएं तो भी आप सुरक्षित रहेंगे। pipelineवे ज्यादा कुछ नहीं कर पाएंगे।
स्ट्रिंग इंटरपोलेशन से बचने के लिए इसका उपयोग करें pipeline पर्यावरण चर
जब भी आप अपने कोड में कुछ इनपुट वेरिएबल का उपयोग करते हैं pipelineध्यान रखें कि इन्हें डिफ़ॉल्ट रूप से "अविश्वसनीय" डेटा माना जाना चाहिए (इनकी सामग्री अंतिम उपयोगकर्ता द्वारा नियंत्रित होती है)। देखें अविश्वसनीय क्रियाएँ और कार्यप्रवाह सुरक्षित और GitHub Actions के बारे में जानें।
स्क्रिप्ट के अंदर इनपुट वेरिएबल डालने के लिए स्ट्रिंग इंटरपोलेशन का उपयोग करने के बजाय हमेशा एनवायरनमेंट वेरिएबल का उपयोग करना चाहिए।
वर्कफ़्लो रन और अनुमोदन आवश्यकताएँ
के लिए सार्वजनिक GitHub में रिपॉज़ को निर्दिष्ट करने की अनुमति है। “बाहरी” पीआर के साथ कैसे काम करें.
GitHub संगठन की सेटिंग्स (“Org >> Settings >> Actions >> General”) में आप यह निर्दिष्ट कर सकते हैं कि बाहरी PR को कैसे प्रबंधित किया जाए:
डिफ़ॉल्ट रूप से, GitHub पहली बार योगदान करने वालों के लिए PR अनुमोदन अनिवार्य कर देता है, जिससे दुर्भावनापूर्ण अनुरोध हमलों को अंजाम देना और भी मुश्किल हो जाता है। फिर भी, हमलावर किसी तरह प्रोजेक्ट के रखवालों का भरोसा जीत सकता है, उदाहरण के लिए कुछ साधारण योगदान देकर। pull request असली हमले से पहले।
इस अर्थ में, तीसरा विकल्प (सभी बाहरी सहयोगियों के लिए अनुमोदन अनिवार्य करना) नियंत्रण का एक उच्च स्तर प्रदान करता है।
के लिए निजी GitHub, संगठन और रेपो दोनों स्तरों पर उपयोगी नियंत्रण प्रदान करता है।
"वर्कफ़्लो चलाएँ Pull Requests” (डिफ़ॉल्ट रूप से चेक नहीं किया गया) उपयोगकर्ताओं को फ़ॉर्क पीआर से वर्कफ़्लो चलाने की अनुमति देता है (केवल पढ़ने की अनुमतियों वाले और रहस्यों तक कोई पहुंच नहीं वाले GITHUB_TOKEN का उपयोग करके)। इस विकल्प को अंतिम विकल्प (“ के साथ चुनकरफोर्क पीआर वर्कफ़्लो के लिए अनुमोदन आवश्यक है”) , आप निजी रिपॉजिटरी के समान नीति पर पहुँच सकते हैं (जैसा कि ऊपर दिखाया गया है)।
जैसा कि हमने रीड यूजर द्वारा पीपीई एक्सप्लॉइट में देखा है, फोर्क से वर्कफ़्लो चलाने की अनुमति देना pull requests यह असुरक्षित है!!
शेष विकल्प (“फोर्क से वर्कफ़्लो में राइट टोकन भेजें pull requests" तथा "वर्कफ़्लो में गुप्त और चर भेजें pull requests") सुरक्षा स्तर को कम करें फोर्क पीआर पर लागू होता है।
आप इस फ़ोर्क नीति को संगठन स्तर या रेपो स्तर पर परिभाषित कर सकते हैं। यदि नीति संगठन स्तर पर अक्षम है, तो इसे रेपो स्तर पर सक्षम नहीं किया जा सकता है। लेकिन, यदि नीति संगठन स्तर पर सक्षम है, तो इसे रेपो स्तर पर अक्षम किया जा सकता है।
संक्षिप्त
हमें उम्मीद है कि आपने कुछ होने के निहितार्थों को समझ लिया होगा। pipeline जहर के प्रति संवेदनशील Pipeline क्रियान्वयन। यह बहुत आसान है। commit एक कमजोर pipelineऔर एक सुरक्षित कोड लिखना मुश्किल है।
इसलिए इस तरह की कमजोरियों से अवगत रहने के लिए Xygeni स्कैनर का उपयोग करना अत्यंत महत्वपूर्ण है।
जब तक आपको किसी खामी के अस्तित्व का पता नहीं होगा, तब तक आप उसे हल नहीं कर सकते!
लेकिन… अभी भी एक सवाल अनसुलझा है… आई-पीपीई से कैसे बचा जाए?
यह हमारे अगले पोस्ट का विषय होगा 🙂… अप्रत्यक्ष रूप से विषैला Pipeline निष्पादन (आई-पीपीई) !!
