निरन्तर एकीकरण र निरन्तर तैनाती (CI/CD) pipelineसुव्यवस्थित सफ्टवेयर विकासलाई सहज बनाउनमा हरूले महत्त्वपूर्ण भूमिका खेल्छन्। तैपनि, यी pipelineजोखिमहरू बढ्दो रूपमा महत्त्वपूर्ण हुँदै गइरहेका छन्, तिनीहरूलाई जोखिमहरूबाट जोगाउनु पर्ने आवश्यकता अझ स्पष्ट हुँदै गइरहेको छ। यो गहन अनुसन्धान OWASP शीर्ष-१० मा पहिचान गरिएको प्रमुख जोखिमलाई सम्बोधन गर्नमा केन्द्रित छ। CI/CD सुरक्षा जोखिम: विषाक्त Pipeline कार्यान्वयन (पीपीई)।
विषाक्त के हो? Pipeline कार्यान्वयन (पीपीई)
OWASP शीर्ष-१० अनुसार CI/CD सुरक्षा जोखिम, "विषाक्त Pipeline कार्यान्वयन (PPE) जोखिम भन्नाले स्रोत नियन्त्रण प्रणालीहरूमा पहुँच भएको र निर्माण वातावरणमा पहुँच बिनाको आक्रमणकारीको क्षमतालाई जनाउँछ - बिल्डमा मालिसियस कोड/कमाण्डहरू इन्जेक्ट गरेर बिल्ड प्रक्रियालाई हेरफेर गर्न pipeline कन्फिगरेसनअनिवार्य रूपमा 'विषाक्त' पार्ने pipeline र निर्माण प्रक्रियाको भागको रूपमा मालिसियस कोड चलाउने"
केही शब्दमा, विषाक्त Pipeline कार्यान्वयन (PPE) तब उत्पादन हुन्छ जब आक्रमणकारीले परिमार्जन गर्न सक्छ pipeline तर्क.
त्यहाँ दुई छन् भिन्नताहरू:
- प्रत्यक्ष PPE (डी-पीपीई): D-PPE परिदृश्यमा, आक्रमणकारीले CI कन्फिग फाइल परिमार्जन गर्दछ रिपोमा रहेको असुरक्षित रिमोट शाखामा सिधै परिवर्तन पुश गरेर, वा शाखा वा फोर्कबाट परिवर्तनको साथ PR पेश गरेर तिनीहरूले पहुँच गर्न सक्ने भण्डारमा। CI देखि pipeline परिमार्जित CI कन्फिगरेसन फाइलमा रहेका आदेशहरूद्वारा कार्यान्वयन परिभाषित गरिन्छ, आक्रमणकारीका दुर्भावनापूर्ण आदेशहरू अन्ततः निर्माण समाप्त भएपछि बिल्ड नोडमा चल्छन्। pipeline ट्रिगर गरिएको छ।
- अप्रत्यक्ष पीपीई (आई-पीपीई): केहि अवस्थामा, D-PPE को सम्भावना पहुँच भएको विपक्षीलाई उपलब्ध हुँदैन SCM भण्डार (जस्तै यदि pipeline एउटै भण्डारमा रहेको छुट्टै, सुरक्षित शाखाबाट CI कन्फिगरेसन फाइल तान्न कन्फिगर गरिएको छ)। यस्तो अवस्थामा, विष हाल्नुको सट्टा pipeline आफैंमा, आक्रमणकारीले द्वारा सन्दर्भित फाइलहरूमा दुर्भावनापूर्ण कोड इन्जेक्ट गर्दछ pipeline (उदाहरणका लागि: भित्रबाट सन्दर्भ गरिएका लिपिहरू pipeline कन्फिगरेसन फाइल)
दुबै केसमा, GitHub ले परिमार्जित कार्यान्वयन गर्नेछ pipeline पूर्व समीक्षा वा अनुमोदनको आवश्यकता बिना.
PPE को प्रारम्भिक पहिचान
हामी यस प्रकारको जोखिम कसरी पत्ता लगाउन सक्छौं?
यो उदाहरण हेरौं pipeline :
र डमी शेल स्क्रिप्टको सामग्री (runtests.sh):
यो pipeline यो एकदम सरल छ: यसको उद्देश्य समीक्षकलाई केही प्रारम्भिक संकेतहरू प्रदान गर्नु हो Pull Request (PR) स्वीकृति प्रक्रिया:
- यो 'मा ट्रिगर हुनेछ अनुरोध_पुल्नुहोस् (अर्थात् जब पनि PR सिर्जना गरिन्छ)
- यसले PR कोड (अर्थात् योगदान गरिएको कोड) जाँच गर्छ।
- यसले निर्माण गर्नेछ
- यसले योगदान गरिएको कोडमा परीक्षणहरू चलाउनेछ (जस्तै शेल स्क्रिप्ट कार्यान्वयन गरेर)
यदि कोड कम्पाइल भएन वा परीक्षणहरू पास गर्न असफल भएमा चरण #३ (निर्माण गर्नुहोस्) र #४ (परीक्षण चलाउनुहोस्) असफल हुनेछन्। त्यसैले, यी चरणहरूले PR स्वीकार गर्न आवश्यक, तर पर्याप्त नभएको अवस्थाको रूपमा काम गर्छन्। सफल भएमा, रिपो प्रशासकले योगदान गरिएको कोड समीक्षा गर्न अगाडि बढ्नेछ र त्यसको आधारमा, उसले PR स्वीकार/अस्वीकार/टिप्पणी गर्नेछ।
Xygeni स्क्यानर
जाइगेनी CLI प्रदान गर्दछ ("Xygeni स्क्यानर") जुन a मा सम्मिलित गर्न सकिन्छ pipeline वा कमाण्ड-लाइनमा चलाउनुहोस्। Xygeni स्क्यानरले प्रशोधन गर्नेछ pipelineकमजोरीहरू जाँच गर्न र, यदि GitHub PAT प्रदान गरिएको छ भने, यो org/repo स्तरमा कमजोरीहरू पत्ता लगाउन GitHub मा जडान हुनेछ।
Xygeni इन्भेन्टरी
जब हामी यो रिपोमा Xygeni स्क्यानर कार्यान्वयन गर्छौं, यसले सम्पत्तिहरूको उपयोगी सेट पत्ता लगाउँछ ( Xygeni इन्भेन्टरी)। सूची धेरै फरक प्रकारकाले भरिनेछ CI/CD सम्पत्तिहरू, जस्तै:
- यो SCM सिस्टम जहाँ रिपो भण्डारण गरिन्छ
- यो SCM प्लगिन्स स्थापित/प्रयोग गरिएको
- यो कोड रिपोजिटरी आफ्नै
- यो SCM संगठन रिपो कहाँको हो
- यो CI/CD Pipelines र जागिरहरू
- यो CI/CD सिस्टम चलिरहेको छ pipelines
- IaC स्रोतहरू रिपोमा परिभाषित
- बाह्य निर्भरता
- आदि
हाम्रो उदाहरणमा, हामी केही विशिष्ट सम्पत्ति प्रकार (SCM- र CICD-सम्बन्धित सम्पत्तिहरू), त्यसैले हामी देख्न सक्छौं कि:
- SCM प्रणाली GitHub क्लाउड हो
- रेपो GitHub क्लाउडमा भण्डारण गरिएको छ र एक विशिष्ट GitHub संगठनसँग सम्बन्धित छ।
- त्यहाँ दुई छन् pipelineGitHub द्वारा संचालित (CI/CD प्रणाली)
- हरेक pipeline एउटा विशिष्ट चरण समावेश गर्दछ
माथिको छनौट गरेर pipeline हामी केही कमजोरीहरू देख्न सक्छौं:
- At pipeline स्तरमा, यो दुवैको लागि जोखिमपूर्ण छ प्रत्यक्ष र अप्रत्यक्ष PPE।
हामी विषाक्त भएकाहरूको विवरण हेर्न सक्छौं Pipeline कार्यान्वयन जोखिमहरू
Xygeni ले पत्ता लगाउँछ कि यो D-PPE को जोखिममा किनभने यो a मा ट्रिगर गरिएको छ Pull Request घटना र त्यहाँ कुनै अतिरिक्त सुरक्षा नियन्त्रणहरू छैनन्, त्यसैले कुनै पनि रिपो प्रयोगकर्ताले परिमार्जन गर्न सक्छ pipeline र ती परिमार्जनहरू कुनै समीक्षा वा स्वीकृति बिना नै कार्यान्वयन गरिनेछ।
त्यसै अर्थमा, Xygeni ले पनि पत्ता लगाउँछ कि यो I-PPE को जोखिममा बाट शेल स्क्रिप्टमा कल भएको कारणले गर्दा pipeline: कुनै पनि रिपो प्रयोगकर्ताले शेल स्क्रिप्ट परिमार्जन गर्न सक्छ र ती परिमार्जनहरू कुनै समीक्षा वा स्वीकृति बिना नै कार्यान्वयन गरिनेछ।
के तपाई अझ बढी जान्न चाहानुहुन्छ?
पीपीईको प्रयोग
PPE को उपयोग गर्नको लागि एउटा परिदृश्यलाई विचार गरौं जहाँ छन् दुई प्रकारका रिपो प्रयोगकर्ताहरू:
- An आन्तरिक प्रयोगकर्ता (त्यो रिपोमा काम गर्ने आन्तरिक विकासकर्ता), रिपोमा लेख्ने अनुमति सहित
- An बाह्य प्रयोगकर्ता (त्यो रिपोमा काम गर्ने तर रिपोमा पढ्ने अनुमति भएको आउटसोर्स गरिएको विकासकर्ता), अर्थात् रिपोलाई शाखा बनाउन अनुमति छैन र फोर्कमा काम गर्न बाध्य पारिएको छ।
कल्पना गरौं कि दुबै दुर्भावनापूर्ण आक्रमणकारीहरू हुन् (वा दुर्भावनापूर्ण अभिनेता द्वारा प्रतिरूपण गरिएको)। रिपोमा केही गोप्य कुराहरू छन् र दुबै चाहन्छन् रिपो गोप्य चोरी गर्न र यसलाई ह्याकर-नियन्त्रित सर्भरमा पठाउनुहोस्। यो गर्न, तिनीहरूले विषाक्तताको फाइदा उठाउनेछन् Pipeline कार्यान्वयन जोखिमहरू pipeline.
दुबै अवस्थामा (बाह्य र आन्तरिक प्रयोगकर्ता), तिनीहरूले a खोल्छन् Pull Request उही परिमार्जनहरू सहित:
- यो pipeline र शेल स्क्रिप्ट परिमार्जन गरिएको छ लाई रहस्य पढ्नुहोस् वातावरणबाट र ह्याकर-नियन्त्रित सर्भरमा पठाउनुहोस्
परिमार्जनहरू निम्नानुसार हुन सक्छन्:
दुबै प्रयोगकर्ताहरूले एउटा सिर्जना गर्नेछन् Pull Request परिमार्जनहरू सहित। जनसम्पर्क समितिको सिर्जना भएपछि, GitHub ले दुवै परिमार्जनहरू कार्यान्वयन गर्नेछ। (पहिले समीक्षा वा स्वीकृतिको आवश्यकता बिना), जसको परिणामस्वरूप निम्न हुन्छ:
लेख्ने र पढ्ने प्रयोगकर्ताहरूको लागि पनि उस्तै, दुबै अवस्थामा D-PPE र I-PPE कार्यान्वयन गरिन्छ, फरक यति छ कि पढ्ने प्रयोगकर्ताले गोप्य कुराहरू पहुँच गर्न सक्दैन। (!!!!)
यो कारण यो हो कि, फोर्कबाट आउने PR को मामलामा, GitHub ले रेपो गोप्यहरूमा पहुँच अनुमति दिँदैन। पढ्ने प्रयोगकर्ताले गोप्य कुराहरू पढ्न नसके पनि, उसले अझै पनि कुनै पनि अन्य कार्यक्रम चलाउन सक्छ। एउटा विशिष्ट आक्रमणको उदाहरण भनेको क्रिप्टो माइनर डाउनलोड गर्ने PR हरू सिर्जना गर्नु हो, त्यसैले GitHub रनरले विषाक्तता कार्यान्वयन गर्दा क्रिप्टो माइनरलाई कार्यान्वयन गर्नेछ। pipeline.
अवश्य पनि, यो सुरक्षित वातावरण होइन !! यसबाट बच्न रेपो प्रशासकले के गर्न सक्छ?
केही गुगलिङ पछि, रिपो एडमिनले परिमार्जन गर्ने निर्णय गर्छ pipeline a मा ट्रिगर हुन अनुरोध_लक्ष्य_तान्नुहोस् घटना। किन? किनभने pipelinepull_request_target मा ट्रिगर गरिएका s ले कार्यान्वयन गर्न अनुमति दिँदैनन् pipeline संशोधनहरू, अर्थात् कुनै पनि प्रयोगकर्ता परिमार्जनको बावजुद "मूल" pipeline कार्यान्वयन गरिनेछ।
हाम्रो उदाहरण पछ्याउँदै, आक्रमण पहिले जस्तै हुनेछ। यस पछि के हुनेछ? pipeline परिमार्जन?
अपेक्षित रूपमा, D-PPE कार्यान्वयन गरिएको छैन तर, किनकि I-PPE अझै पनि छ, पढ्ने प्रयोगकर्ता अब रेपो गोप्य पहुँच गर्न सक्षम छन्!!!
पढ्ने प्रयोगकर्ताले अब गोप्य कुराहरूमा पहुँच पाउनुको कारण के हो? यद्यपि pipeline परिमार्जन गर्न सकिँदैन, शेल स्क्रिप्ट परिमार्जन गर्न अझै पनि सम्भव छ। जब एक pipeline pull_request_target मा ट्रिगर गरिएको छ, यो विशेषाधिकार प्राप्त मोडमा कार्यान्वयन हुनेछ। so यो शेल स्क्रिप्ट पनि हुनेछ।, जसको परिणामस्वरूप शेल स्क्रिप्टले रेपो गोप्य कुराहरूमा पहुँच पाउनेछ!!
रोकथाम उपाय
GitHub ले दुर्भावनापूर्ण PR हरूबाट जोगाउन केही उपायहरू प्रदान गर्दछ।
शाखा सुरक्षा नियमहरू
GitHub मार्फत तपाईंले चयन गरिएका शाखाहरूमा शाखा सुरक्षा नियमहरू परिभाषित गर्न सक्नुहुन्छ।
तपाईंको संरक्षित शाखाहरूको लागि, तपाईंले एउटा नीति निर्दिष्ट गर्न सक्नुहुन्छ जुन आवाश्यक हुन्छ pull request मर्ज गर्नु अघि (साथै आवश्यक संख्यामा अनुमोदनहरू, कोड मालिकहरूबाट समीक्षाहरू, आदि जस्ता अतिरिक्त सर्तहरू।)
विशेष विचार गर्नुपर्ने केही सर्तहरू यस प्रकार छन्:
- "निर्दिष्ट अभिनेताहरूलाई आवश्यक बाइपास गर्न अनुमति दिनुहोस् pull requests"।
- "माथिका सेटिङहरू बाइपास गर्न अनुमति नदिनुहोस्।"
धेरैजसो सर्तहरूले नीतिमा कडाइ थपे पनि, यी सर्तहरूले नीतिलाई खुकुलो पार्छन् र यसले दुर्भावनापूर्ण गतिविधिहरूको लागि खुला ढोका खोल्न सक्छ, उदाहरणका लागि, "विशेषाधिकार प्राप्त" अभिनेताहरूद्वारा प्रमाणहरू चोरी भएको अवस्थामा।
GITHUB_TOKEN अनुमतिहरू प्रतिबन्धित गर्नुहोस् (न्यूनतम-विशेषाधिकार)
GitHub टोकन अनुमतिहरू केवल आवश्यक अनुमतिहरूमा सीमित गर्नुहोस्; यस तरिकाले, आक्रमणकारीहरूले तपाईंको सम्झौता गर्न सफल भए पनि pipeline, तिनीहरूले धेरै गर्न सक्ने छैनन्।
प्रयोग गरेर स्ट्रिङ इन्टरपोलेसनबाट बच्नुहोस् pipeline env चरहरू
जब तपाईं आफ्नो मा केही इनपुट चरहरू प्रयोग गर्नुहुन्छ pipeline, सावधान रहनुहोस् कि तिनीहरूलाई पूर्वनिर्धारित रूपमा "अविश्वसनीय" डेटाको रूपमा विचार गर्नुपर्छ (तिनीहरूको सामग्री अन्तिम प्रयोगकर्ताद्वारा नियन्त्रित हुन्छ)। हेर्नुहोस् अविश्वसनीय कार्यहरू र कार्यप्रवाहहरू सुरक्षित र Github कार्यहरू सिक्नुहोस्।
स्ट्रिङ इन्टरपोलेसन प्रयोग गर्नुको सट्टा स्क्रिप्ट भित्र इनपुट चरहरू घुसाउन तपाईंले सधैं वातावरण चरहरू प्रयोग गर्नुपर्छ।
कार्यप्रवाह सञ्चालन र अनुमोदन आवश्यकताहरू
लागि सार्वजनिक रिपो, GitHub ले निर्दिष्ट गर्न अनुमति दिन्छ "बाह्य" PR हरूसँग कसरी काम गर्ने.
GitHub संगठन सेटिङहरू ("Org >> सेटिङहरू >> कार्यहरू >> सामान्य") बाह्य PR हरू कसरी व्यवस्थापन गर्ने भनेर निर्दिष्ट गर्न दिनुहोस्:
पूर्वनिर्धारित रूपमा, GitHub लाई पहिलो पटक योगदानकर्ताहरूको लागि PR स्वीकृति आवश्यक पर्नेछ, जसले गर्दा दुर्भावनापूर्ण अनुरोध आक्रमणहरू अझ जटिल हुनेछन्। तैपनि, आक्रमणकारीले केही निर्दोष योगदान गरेर उदाहरणका लागि परियोजना मर्मतकर्ताहरूको विश्वास प्राप्त गर्न सक्छ। pull request वास्तविक आक्रमण अघि।
यस अर्थमा, तेस्रो विकल्प (सबै बाहिरी सहयोगीहरूको लागि स्वीकृति आवश्यक) ले उच्च स्तरको नियन्त्रण थप्छ।
लागि निजी रिपोमा, GitHub ले संगठन- र रिपो-स्तर दुवैमा उपयोगी नियन्त्रण पनि प्रदान गर्दछ।
"बाट कार्यप्रवाहहरू चलाउनुहोस् Pull Requests"(पूर्वनिर्धारित रूपमा जाँच गरिएको छैन) ले प्रयोगकर्ताहरूलाई फोर्क PR हरूबाट कार्यप्रवाहहरू चलाउन अनुमति दिन्छ (पढ्न-मात्र अनुमतिहरू भएको र गोप्य कुराहरूमा पहुँच बिना GITHUB_TOKEN प्रयोग गरेर)। अन्तिम विकल्पसँगै यो विकल्प चयन गरेर ("फोर्क PRs कार्यप्रवाहहरूको लागि स्वीकृति आवश्यक छ”), तपाईं निजी रिपो जस्तै नीतिमा पुग्न सक्नुहुन्छ (माथि देखाइए अनुसार)।
हामीले पढ्ने प्रयोगकर्ताबाट PPE शोषणमा देखेका छौं, फोर्कबाट कार्यप्रवाहहरू चलाउन अनुमति दिँदै pull requests असुरक्षित छ!!
बाँकी विकल्पहरू ("फोर्कबाट कार्यप्रवाहहरूमा लेखन टोकनहरू पठाउनुहोस् pull requests"र"for बाट कार्यप्रवाहहरूमा गोप्य र चरहरू पठाउनुहोस् pull requests") सुरक्षा स्तर घटाउनुहोस् फोर्क PR मा लागू गरियो।
तपाईंले यो फोर्क नीतिलाई संगठन स्तरमा वा रिपो-स्तरमा परिभाषित गर्न सक्नुहुन्छ। यदि नीति संगठन-स्तरमा असक्षम पारिएको छ भने, यसलाई रिपो स्तरमा सक्षम गर्न सकिँदैन। तर, यदि नीति संगठन-स्तरमा सक्षम पारिएको छ भने, यसलाई रिपो-स्तरमा असक्षम पार्न सकिन्छ।
पुनरावलोकनमा
हामी आशा गर्छौं कि तपाईंले केही हुनुको प्रभाव देख्नुभएको छ pipeline विषाक्तताको जोखिममा Pipeline कार्यान्वयन। यो धेरै सजिलो छ commit एक कमजोर pipeline, र सुरक्षित लेख्न गाह्रो छ।
त्यसैले यस्ता कमजोरीहरू बारे सचेत हुन Xygeni स्क्यानर प्रयोग गर्नु अत्यन्तै मूल्यवान छ।
जबसम्म तपाईं यसको अस्तित्वको बारेमा सचेत हुनुहुन्न तबसम्म तपाईं कुनै पनि समस्या समाधान गर्न सक्नुहुन्न !!
तर... अझै पनि एउटा विचाराधीन प्रश्न छ... I-PPE बाट कसरी बच्ने?
यो हाम्रो अर्को पोस्टको विषय हुनेछ 🙂 … अप्रत्यक्ष विषाक्तता Pipeline कार्यान्वयन (I-PPE) !!
