GitHub कैश विषाक्तता

क्या आप जानते हैं कि आपके सीआई के अंतर्गत क्या होता है? गहरी समझ के बिना, आप नवीन आपूर्ति श्रृंखला हमलों के प्रति संवेदनशील हो सकते हैं। यह लेख ऐसे ही एक हमले का वर्णन करता है.

कैशिंग का उपयोग प्रक्रियाओं को गति देने के लिए किया जाता है। एक पैकेज को बार-बार बनाने या डाउनलोड करने के बजाय, यह पुन: उपयोग के लिए कलाकृतियों को आसानी से और स्वचालित रूप से रखता है। हालाँकि, कैश विषाक्त हो सकता है। उदाहरण के लिए, परीक्षण वर्कफ़्लो में उपयोग किया जाने वाला एक दुर्भावनापूर्ण उपकरण इसके कैश को विषाक्त कर सकता है। बाद में, उसी कैश का उपयोग करने वाला कोई अन्य वर्कफ़्लो प्रभावित हो सकता है। यदि इस वर्कफ़्लो में उच्च विशेषाधिकार हैं, तो यह वास्तव में किसी हमले को आगे बढ़ाने की एक विधि है। इस पोस्ट में, हम GitHub CI पाइपलाइन पर एक प्रयोग हमले पर रिपोर्ट करते हैं, लेकिन अन्य CI उत्पादों में एक समान तार्किक भेद्यता मौजूद है।

हमला इस प्रकार होता है: 

1. एक हमलावर एक दुर्भावनापूर्ण टूल या जीथब एक्शन प्रकाशित करता है जिसे जीथब में एक बिना सोचे-समझे वर्कफ़्लो द्वारा उठाया जाता है।
2. वर्कफ़्लो को कैश के साथ डिज़ाइन किया गया है
3. दुर्भावनापूर्ण पेलोड दुर्भावनापूर्ण डेटा को शामिल करने के लिए कैश को संशोधित करता है।
4. इस बिंदु से इस कैश पर कॉल करने वाले अन्य वर्कफ़्लो प्रभावित हो सकते हैं।

हमारे खुलासे के जवाब में, GitHub ने कहा कि उनके पास इस प्रकार के हमले के खिलाफ कैश सुविधा को सख्त करने की कोई योजना नहीं है। 

हम कैश की सामग्री हैश मान पर क्रिप्टोग्राफ़िक रूप से हस्ताक्षर करके और उपयोग से पहले हस्ताक्षर को सत्यापित करके शमन का प्रस्ताव करते हैं। हमले और शमन के बारे में अधिक जानने के लिए पढ़ते रहें।

गिटहब कैश

अक्सर एक रन से दूसरे रन में समान आउटपुट या डाउनलोड की गई निर्भरता का पुन: उपयोग करते हैं (उदाहरण के लिए, पैकेज और निर्भरता प्रबंधन उपकरण जैसे मावेन, ग्रैडल, एनपीएम और यार्न द्वारा डाउनलोड किए गए पैकेज। ये पैकेज आमतौर पर डाउनलोड की गई निर्भरता के स्थानीय कैश में रखे जाते हैं).

सीआई रन को अनुकूलित करने के लिए, GitHub एक कैश संसाधन तक पहुंच प्रदान करता है जिसका उपयोग एपीआई के माध्यम से पाइपलाइन में किया जा सकता है। कैश में प्रविष्टियाँ एक कुंजी-मूल्य संयोजन हैं, जहां कुंजी स्ट्रिंग-आधारित होती हैं, और मान फ़ाइलें या निर्देशिकाएं होती हैं जिन्हें कोई कैश करना चाहता है।

ऊपर दिए कार्रवाई/कैश सीआई में कहीं भी गिट कार्रवाई दो चरणों में चलेगी: एक चरण के दौरान होगा रन प्रक्रिया तब होगी जब इसे बुलाया जाएगा और दूसरा बाद में होगा वर्कफ़्लो (यदि रन एक्शन ने कैश-मिस लौटाया है)।

• कार्रवाई चलाएँ - कैश को खोजने और पुनः प्राप्त करने के लिए उपयोग किया जाता है। खोज कैश कुंजी का उपयोग करके की जाती है, जिसका परिणाम या तो कैश-हिट (सफलता, कैश में पाया गया डेटा) या कैश-मिस होता है। यदि पाया जाता है, तो फ़ाइलों और निर्देशिकाओं को सक्रिय उपयोग के लिए कैश से पुनर्प्राप्त किया जाता है। यदि परिणाम कैश-मिस है, तो वांछित फ़ाइलें और निर्देशिकाएं ऐसे डाउनलोड की जाती हैं जैसे कि उन्हें पहली बार कॉल किया गया हो।
• वर्कफ़्लो कार्रवाई पोस्ट करें - कैश को सहेजने के लिए उपयोग किया जाता है। यदि रन एक्शन में कैश कॉल का परिणाम कैश-मिस लौटाता है, तो यह क्रिया उन निर्देशिकाओं की वर्तमान स्थिति को बचाएगी जिन्हें हम प्रदान की गई कुंजी के साथ कैश करना चाहते हैं। यह क्रिया स्वचालित रूप से होती है और इसे स्पष्ट रूप से कॉल करने की आवश्यकता नहीं होती है।

GitHub कैश अनुमतियाँ

पहुँच प्रतिबंध प्रदान करते हैं कैश अलगाव और विभिन्न शाखाओं के बीच एक तार्किक सीमा बनाकर सुरक्षा (उदाहरण के लिए: शाखा के लिए बनाया गया कैश फ़ीचर-ए [आधार मुख्य के साथ] शाखा के लिए पुल अनुरोध तक पहुंच योग्य नहीं होगा फ़ीचर-बी [आधार मुख्य के साथ]).

कैश क्रिया सबसे पहले कुंजी के लिए कैश हिट खोजती है और कुंजी वाली शाखा में कुंजी पुनर्स्थापित करती है वर्कफ़्लो चलाएँ. यदि वर्तमान शाखा में कोई हिट नहीं है, तो कैश क्रिया कुंजी की खोज करती है और मूल शाखा और अपस्ट्रीम शाखाओं में कुंजी पुनर्स्थापित करती है।

कैश तक पहुंच का दायरा शाखा (वर्तमान और मूल) द्वारा होता है, जिसका अर्थ है कि सभी को पहुंच प्रदान की जाती है workflows के पार चलाता है उक्त शाखा का.

एक और महत्वपूर्ण नोट यह है कि GitHub प्रविष्टियों को पुश करने के बाद संशोधन की अनुमति नहीं देता है - कैश प्रविष्टियाँ केवल-पढ़ने के लिए रिकॉर्ड हैं।

गिटहब सीआई स्कोपिंग

GitHub स्कोप यह निर्दिष्ट करने की अनुमति दें कि विभिन्न कार्यों के लिए किस प्रकार की पहुंच की आवश्यकता है। GitHub के CI का दायरा विभिन्न तरीकों से है, प्रत्येक के अपने मूल्यों और विशेषताओं का सेट है:

• प्रत्येक कार्य के लिए वर्चुअल मशीन (वीएम)।
• कार्य अनुमतियाँ
• कार्यप्रवाह का दायरा
• वर्कफ़्लो चलता है
• गिट शाखाएँ
• वर्कफ़्लो पहचान टोकन
• और दूसरे

GitHub कैश स्कोप को इस तरह से परिभाषित किया गया है जो कुछ अन्य स्कोप प्रतिबंधों को तोड़ सकता है (उदा: GitHub कैश एकाधिक वर्कफ़्लो को प्रभावित कर सकता है).

हमला

हमने एक उदाहरण सीआई का उपयोग किया जिसमें दो वर्कफ़्लो शामिल थे। यह उदाहरण दिखाता है कि कैसे कोई हमला कम अनुमति वाले वर्कफ़्लो से उच्च अनुमति वाले वर्कफ़्लो की ओर बढ़ सकता है।

• इकाई परीक्षण वर्कफ़्लो रनिंग यूनिट-टेस्ट और कोड कवरेज टूल। हम मानते हैं कि उपकरणों में से एक दुर्भावनापूर्ण है या दूरस्थ कोड निष्पादन के प्रति संवेदनशील है। वर्कफ़्लो को इसका उपयोग करने की आवश्यकता है कार्रवाई/कैश गिट कार्रवाई. कोई भी वर्कफ़्लो कैश तक पहुंच सकता है।
• रिलीज वर्कफ़्लो एप्लिकेशन आर्टिफैक्ट बनाता है और रिलीज़ करता है। यह वर्कफ़्लो गोलांग निर्भरता का उपयोग करके अनुकूलित करने के लिए कैश का उपयोग करता है।

RSI इकाई परीक्षण वर्कफ़्लो एक दुर्भावनापूर्ण कार्रवाई का उपयोग करता है जो गोलांग लॉगिंग लाइब्रेरी को बदलकर दुर्भावनापूर्ण सामग्री के साथ कैश प्रविष्टि जोड़ता है (go.uber.org/zap@v1) एप्लिकेशन आर्टिफैक्ट विवरण में स्ट्रिंग, 'बीएडी लाइब्रेरी' जोड़ने के लिए।

अगला, और वर्कफ़्लो इस जहरीली कैश प्रविष्टि का उपयोग करता है। परिणामस्वरूप, दुर्भावनापूर्ण कोड को निर्मित गोलांग बाइनरी और छवि में इंजेक्ट किया जाता है। जब तक प्रवेश कुंजी को हटा नहीं दिया जाता (आमतौर पर निर्भरता अपडेट द्वारा ट्रिगर किया जाता है) कैश विषाक्त बना रहता है। वही जहरीला कैश किसी अन्य को भी प्रभावित करेगा वर्कफ़्लो, रन, तथा बाल शाखा उसी कैश कुंजी का उपयोग करना।

हमारे द्वारा किए गए परीक्षण में, हम छवि विवरण में 'बीएडी लाइब्रेरी' स्ट्रिंग को इंजेक्ट करने में कामयाब रहे:

यह संस्करण 0.4.1 में था. इसके बाद, हमने टैग को अपडेट किया और छवि को कई बार फिर से बनाया, और देखा कि विवरण में 'खराब लाइब्रेरी' बनी हुई है।

गिटहब प्रकटीकरण

हमारे खुलासे पर जीथब की प्रतिक्रिया यह थी कि जीआईटी कार्रवाई,  कार्रवाई/कैश अपेक्षा के अनुरूप व्यवहार करता है और उनके पास कैश का दायरा कड़ा करने की कोई योजना नहीं है।
हालाँकि GitHub टीम इस व्यवहार को समस्याग्रस्त नहीं मानती है, हम DevSecOps अभ्यासकर्ताओं को इस आक्रमण वेक्टर से सावधान रहने की सलाह देते हैं।

mitigations

1. रिलीज़ या महत्वपूर्ण वर्कफ़्लो में कैश का उपयोग न करें।
2. अपने वर्कफ़्लो को क्रमिक रूप से चलाएँ, विश्वसनीय वर्कफ़्लो को पहले चलाकर सुनिश्चित करें कि आपका कैश एक विश्वसनीय वर्कफ़्लो में बनाया गया है।
3. अपनी निर्भरताएँ विक्रेता करें - GoLang में विक्रेता यह सुनिश्चित करने का एक तरीका है कि गो प्रोजेक्ट में उपयोग किए जाने वाले सभी तृतीय पक्ष पैकेज उस एप्लिकेशन के लिए विकसित होने वाले सभी लोगों के लिए सुसंगत हैं। इस तरह, कैश्ड निर्भरताएँ परियोजना की सभी शाखाओं के लिए मान्य रहेंगी। अन्य भाषाएँ इस पद्धति का समर्थन नहीं कर सकती हैं।
4. कैश मान पर क्रिप्टोग्राफ़िक रूप से हस्ताक्षर करें और उपयोग से पहले हस्ताक्षर सत्यापित करें।
   स्क्राइब कैश जैसे वर्कफ़्लो में किसी ऑब्जेक्ट या निर्देशिका पर बारीक हस्ताक्षर करके ऐसे हमलों को कम करता है। रिलीज़ से पहले, आप यह सत्यापित करने के लिए Scribe का उपयोग कर सकते हैं कि रिलीज़ बनाने के लिए केवल विश्वसनीय वर्कफ़्लो द्वारा उत्पन्न कैश का उपयोग किया गया था।

सारांश 

इस पोस्ट में, हमने CI वर्कफ़्लोज़ में कैश पॉइज़निंग हमले की रूपरेखा तैयार की है, जो DevSecOps टीम की नज़रों से छिपा हुआ है, और शमन पर चर्चा की गई है।