Abusing Github Actions
बुनियादी जानकारी
इस पेज में आपको मिलेगा:
एक सारांश सभी प्रभावों का जब एक हमलावर Github Action तक पहुँच जाता है
एक्शन तक पहुँचने के विभिन्न तरीके:
एक्शन बनाने के लिए अनुमतियाँ होना
pull request संबंधित ट्रिगर्स का दुरुपयोग
अन्य बाहरी पहुँच तकनीकों का दुरुपयोग
पहले से समझौता किए गए repo से पिवोटिंग
अंत में, पोस्ट-एक्सप्लॉइटेशन तकनीकों के बारे में एक अनुभाग जो अंदर से एक्शन का दुरुपयोग करने के लिए है (उल्लेखित प्रभावों का कारण)
प्रभावों का सारांश
Github Actions की मूल जानकारी के बारे में परिचय के लिए देखें।
यदि आप मनमाने Github actions निष्पादित/कोड इंजेक्ट कर सकते हैं एक repository में, तो आप सक्षम हो सकते हैं:
उस repo/organization से secrets चोरी करना।
यदि आप केवल इंजेक्ट कर सकते हैं, तो आप जो भी वर्कफ़्लो में पहले से मौजूद है उसे चुरा सकते हैं।
repo privileges का दुरुपयोग करके अन्य प्लेटफार्मों जैसे AWS और GCP तक पहुँच सकते हैं।
कस्टम वर्कर्स में कोड निष्पादित करें (यदि कस्टम वर्कर्स का उपयोग किया जाता है) और वहां से पिवोट करने का प्रयास करें।
repository कोड को ओवरराइट करें।
यह
GITHUB_TOKEN
(यदि कोई हो) के विशेषाधिकारों पर निर्भर करता है।डिप्लॉयमेंट्स और अन्य आर्टिफैक्ट्स को समझौता करें।
यदि कोड कुछ तैनात या संग्रहीत कर रहा है तो आप उसे संशोधित कर सकते हैं और कुछ और पहुँच प्राप्त कर सकते हैं।
GITHUB_TOKEN
यह "secret" (जो ${{ secrets.GITHUB_TOKEN }}
और ${{ github.token }}
से आता है) तब दिया जाता है जब एडमिन इस विकल्प को सक्षम करता है:
यह टोकन वही है जो एक Github Application उपयोग करेगा, इसलिए यह उन्हीं endpoints तक पहुँच सकता है: https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps
Github को एक flow जारी करना चाहिए जो क्रॉस-रिपॉजिटरी पहुँच की अनुमति देता है GitHub के भीतर, ताकि एक repo अन्य आंतरिक repos तक GITHUB_TOKEN
का उपयोग करके पहुँच सके।
आप इस टोकन के संभावित अनुमतियों को देख सकते हैं: https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token
ध्यान दें कि टोकन जॉब पूरा होने के बाद समाप्त हो जाता है।
ये टोकन इस तरह दिखते हैं: ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7
इस टोकन के साथ आप कुछ दिलचस्प चीजें कर सकते हैं:
ध्यान दें कि कई मौकों पर आप Github Actions envs या secrets के अंदर github user tokens पा सकते हैं। ये tokens आपको repository और organization पर अधिक विशेषाधिकार दे सकते हैं।
अन्य उपयोगकर्ताओं के रिपॉजिटरी में Github Token को दिए गए अनुमतियों की जांच करना संभव है एक्शन के लॉग्स की जांच करके:
Allowed Execution
यह Github actions को समझौता करने का सबसे आसान तरीका होगा, क्योंकि इस मामले में मान लिया गया है कि आपके पास संगठन में एक नया रिपॉजिटरी बनाने की पहुंच है, या किसी रिपॉजिटरी पर लिखने के विशेषाधिकार हैं।
यदि आप इस स्थिति में हैं तो आप बस Post Exploitation techniques की जांच कर सकते हैं।
Repo Creation से Execution
यदि संगठन के सदस्य नए रिपॉजिटरी बना सकते हैं और आप github actions को निष्पादित कर सकते हैं, तो आप एक नया रिपॉजिटरी बना सकते हैं और संगठन स्तर पर सेट किए गए secrets को चुरा सकते हैं।
एक नई Branch से Execution
यदि आप किसी रिपॉजिटरी में एक नई शाखा बना सकते हैं जिसमें पहले से ही एक Github Action कॉन्फ़िगर है, तो आप इसे संशोधित कर सकते हैं, सामग्री अपलोड कर सकते हैं, और फिर नई शाखा से उस एक्शन को निष्पादित कर सकते हैं। इस तरह आप रिपॉजिटरी और संगठन स्तर के secrets को बाहर निकाल सकते हैं (लेकिन आपको यह जानना होगा कि उन्हें कैसे कहा जाता है)।
आप संशोधित एक्शन को मैन्युअल रूप से, जब एक PR बनाया जाता है या जब कुछ कोड पुश किया जाता है (इस पर निर्भर करता है कि आप कितना शोर करना चाहते हैं) निष्पादित कर सकते हैं:
Forked Execution
अलग-अलग ट्रिगर्स हो सकते हैं जो एक हमलावर को किसी अन्य रिपॉजिटरी की Github Action को निष्पादित करने की अनुमति दे सकते हैं। यदि वे ट्रिगर करने योग्य क्रियाएं खराब तरीके से कॉन्फ़िगर की गई हैं, तो एक हमलावर उन्हें समझौता कर सकता है।
pull_request
pull_request
वर्कफ़्लो ट्रिगर pull_request
हर बार वर्कफ़्लो को निष्पादित करेगा जब कोई पुल अनुरोध प्राप्त होता है कुछ अपवादों के साथ: डिफ़ॉल्ट रूप से यदि यह पहली बार है जब आप सहयोग कर रहे हैं, तो कुछ रखरखावकर्ता को वर्कफ़्लो के रन को स्वीकृत करने की आवश्यकता होगी:
चूंकि डिफ़ॉल्ट सीमा पहली बार योगदानकर्ताओं के लिए है, आप एक वैध बग/टाइपो को ठीक करने में योगदान कर सकते हैं और फिर अपने नए pull_request
विशेषाधिकारों का दुरुपयोग करने के लिए अन्य PRs भेज सकते हैं।
मैंने इसका परीक्षण किया और यह काम नहीं करता: एक और विकल्प यह होगा कि किसी ऐसे व्यक्ति के नाम से खाता बनाया जाए जिसने प्रोजेक्ट में योगदान दिया हो और अपना खाता हटा दिया हो।
इसके अलावा, डिफ़ॉल्ट रूप से लिखने की अनुमतियों और लक्षित रिपॉजिटरी तक गुप्त पहुंच को रोकता है जैसा कि दस्तावेज़ों में उल्लेख किया गया है:
GITHUB_TOKEN
को छोड़कर, गुप्त जानकारी रनर को पास नहीं की जाती जब वर्कफ़्लो फोर्क की गई रिपॉजिटरी से ट्रिगर होता है। पुल अनुरोधों मेंGITHUB_TOKEN
के पास केवल पढ़ने की अनुमति होती है फोर्क की गई रिपॉजिटरी से।
एक हमलावर Github Action की परिभाषा को संशोधित कर सकता है ताकि मनमानी चीजें निष्पादित की जा सकें और मनमानी क्रियाएं जोड़ी जा सकें। हालाँकि, वह उल्लिखित सीमाओं के कारण गुप्त जानकारी चुरा नहीं सकेगा या रिपॉजिटरी को अधिलेखित नहीं कर सकेगा।
हां, यदि हमलावर PR में ट्रिगर की जाने वाली github action को बदलता है, तो उसकी Github Action का उपयोग किया जाएगा न कि मूल रिपॉजिटरी की!
चूंकि हमलावर भी निष्पादित कोड को नियंत्रित करता है, भले ही GITHUB_TOKEN
पर गुप्त जानकारी या लिखने की अनुमति न हो, एक हमलावर उदाहरण के लिए दुर्भावनापूर्ण आर्टिफैक्ट अपलोड कर सकता है।
pull_request_target
pull_request_target
वर्कफ़्लो ट्रिगर pull_request_target
के पास लक्षित रिपॉजिटरी के लिए लिखने की अनुमति और गुप्त जानकारी तक पहुंच है (और अनुमति नहीं मांगता)।
ध्यान दें कि वर्कफ़्लो ट्रिगर pull_request_target
बेस संदर्भ में चलता है न कि PR द्वारा दिए गए संदर्भ में (अविश्वसनीय कोड को निष्पादित न करने के लिए)। pull_request_target
के बारे में अधिक जानकारी के लिए दस्तावेज़ देखें।
इसके अलावा, इस विशिष्ट खतरनाक उपयोग के बारे में अधिक जानकारी के लिए इस github ब्लॉग पोस्ट को देखें।
ऐसा लग सकता है कि क्योंकि निष्पादित वर्कफ़्लो वह है जो बेस में परिभाषित है और PR में नहीं है, pull_request_target
का उपयोग करना सुरक्षित है, लेकिन कुछ मामले हैं जहां यह नहीं है।
और इस एक के पास गुप्त जानकारी तक पहुंच होगी।
workflow_run
workflow_run
workflow_run ट्रिगर एक वर्कफ़्लो को एक अलग वर्कफ़्लो से चलाने की अनुमति देता है जब यह completed
, requested
या in_progress
होता है।
इस उदाहरण में, एक वर्कफ़्लो को अलग "Run Tests" वर्कफ़्लो पूरा होने के बाद चलाने के लिए कॉन्फ़िगर किया गया है:
Moreover, according to the docs: The workflow started by the workflow_run
event is able to access secrets and write tokens, even if the previous workflow was not.
इस प्रकार के वर्कफ़्लो पर हमला किया जा सकता है यदि यह workflow पर निर्भर है जिसे बाहरी उपयोगकर्ता द्वारा pull_request
या pull_request_target
के माध्यम से triggered किया जा सकता है। कुछ कमजोर उदाहरण इस ब्लॉग में पाए जा सकते हैं। पहला उदाहरण workflow_run
ट्रिगर किए गए वर्कफ़्लो का है जो हमलावर के कोड को डाउनलोड करता है: ${{ github.event.pull_request.head.sha }}
दूसरा उदाहरण untrusted कोड से artifact को workflow_run
वर्कफ़्लो में पास करने और इस आर्टिफैक्ट की सामग्री का उपयोग करने का है जिससे यह RCE के लिए कमजोर हो जाता है।
workflow_call
workflow_call
TODO
TODO: Check if when executed from a pull_request the used/downloaded code if the one from the origin or from the forked PR
Abusing Forked Execution
हमने उन सभी तरीकों का उल्लेख किया है जिनसे एक बाहरी हमलावर एक github वर्कफ़्लो को निष्पादित करने का प्रबंधन कर सकता है, अब देखते हैं कि इन निष्पादनों का, यदि गलत कॉन्फ़िगर किया गया हो, तो कैसे दुरुपयोग किया जा सकता है:
Untrusted checkout execution
pull_request
के मामले में, वर्कफ़्लो PR के संदर्भ में निष्पादित किया जाएगा (इसलिए यह दुर्भावनापूर्ण PRs कोड निष्पादित करेगा), लेकिन किसी को इसे पहले अधिकृत करना होगा और यह कुछ सीमाओं के साथ चलेगा।
pull_request_target
या workflow_run
का उपयोग करने वाले वर्कफ़्लो के मामले में जो pull_request_target
या pull_request
से ट्रिगर किए जा सकने वाले वर्कफ़्लो पर निर्भर करता है, मूल रिपॉजिटरी का कोड निष्पादित किया जाएगा, इसलिए हमलावर निष्पादित कोड को नियंत्रित नहीं कर सकता।
हालांकि, यदि action में एक explicit PR checkout है जो PR से कोड प्राप्त करेगा (और बेस से नहीं), तो यह हमलावर द्वारा नियंत्रित कोड का उपयोग करेगा। उदाहरण के लिए (लाइन 12 देखें जहां PR कोड डाउनलोड किया गया है):
संभावित untrusted code npm install
या npm build
के दौरान चल रहा है क्योंकि बिल्ड स्क्रिप्ट्स और संदर्भित पैकेज PR के लेखक द्वारा नियंत्रित होते हैं।
कमजोर actions की खोज के लिए एक github dork है: event.pull_request pull_request_target extension:yml
हालांकि, नौकरियों को सुरक्षित रूप से निष्पादित करने के लिए विभिन्न तरीके हैं, भले ही action असुरक्षित रूप से कॉन्फ़िगर किया गया हो (जैसे कि PR उत्पन्न करने वाले actor के बारे में शर्तों का उपयोग करना)।
Context Script Injections
ध्यान दें कि कुछ github contexts हैं जिनके मान PR बनाने वाले उपयोगकर्ता द्वारा नियंत्रित होते हैं। यदि github action उस डेटा का उपयोग कुछ भी निष्पादित करने के लिए कर रहा है, तो यह arbitrary code execution का कारण बन सकता है:
Gh Actions - Context Script InjectionsGITHUB_ENV Script Injection
डॉक्स से: आप किसी भी बाद के चरणों में एक वर्कफ़्लो जॉब में एक environment variable उपलब्ध करा सकते हैं या अपडेट कर सकते हैं और इसे GITHUB_ENV
environment file में लिख सकते हैं।
यदि कोई हमलावर इस env variable के अंदर कोई भी मान inject कर सकता है, तो वह env variables inject कर सकता है जो अगले चरणों में कोड निष्पादित कर सकते हैं जैसे LD_PRELOAD या NODE_OPTIONS।
उदाहरण के लिए (यह और यह), एक वर्कफ़्लो की कल्पना करें जो एक अपलोड किए गए आर्टिफैक्ट पर भरोसा कर रहा है ताकि इसकी सामग्री को GITHUB_ENV
env variable के अंदर संग्रहीत किया जा सके। एक हमलावर इसे समझौता करने के लिए कुछ इस तरह अपलोड कर सकता है:
Vulnerable Third Party Github Actions
जैसा कि इस ब्लॉग पोस्ट में उल्लेख किया गया है, यह Github Action विभिन्न वर्कफ़्लो और यहां तक कि रिपॉजिटरीज़ से आर्टिफैक्ट्स तक पहुंचने की अनुमति देता है।
समस्या यह है कि यदि path
पैरामीटर सेट नहीं है, तो आर्टिफैक्ट वर्तमान निर्देशिका में निकाला जाता है और यह उन फ़ाइलों को ओवरराइड कर सकता है जिन्हें बाद में उपयोग या यहां तक कि वर्कफ़्लो में निष्पादित किया जा सकता है। इसलिए, यदि आर्टिफैक्ट कमजोर है, तो एक हमलावर इसका दुरुपयोग कर सकता है ताकि अन्य वर्कफ़्लो को समझौता किया जा सके जो आर्टिफैक्ट पर भरोसा करते हैं।
कमजोर वर्कफ़्लो का उदाहरण:
यह इस workflow के साथ हमला किया जा सकता है:
अन्य बाहरी एक्सेस
डिलीटेड नेमस्पेस रिपो हाईजैकिंग
यदि एक खाता अपना नाम बदलता है, तो कुछ समय बाद कोई अन्य उपयोगकर्ता उस नाम के साथ एक खाता पंजीकृत कर सकता है। यदि किसी रिपॉजिटरी में नाम बदलने से पहले 100 से कम स्टार्स थे, तो Github नए पंजीकृत उपयोगकर्ता को उसी नाम के साथ एक रिपॉजिटरी बनाने की अनुमति देगा जैसा कि डिलीटेड रिपॉजिटरी का नाम था।
तो यदि कोई एक्शन किसी गैर-मौजूद खाते से रिपो का उपयोग कर रहा है, तो यह अभी भी संभव है कि एक हमलावर उस खाते को बना सके और एक्शन को समझौता कर सके।
यदि अन्य रिपॉजिटरी इस उपयोगकर्ता के रिपो से निर्भरता का उपयोग कर रहे थे, तो एक हमलावर उन्हें हाईजैक कर सकेगा। यहाँ आपके पास एक अधिक पूर्ण व्याख्या है: https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/
रिपो पिवोटिंग
इस अनुभाग में हम उन तकनीकों के बारे में बात करेंगे जो एक रिपो से दूसरे रिपो में पिवोट करने की अनुमति देती हैं, यह मानते हुए कि हमारे पास पहले वाले पर किसी प्रकार की पहुंच है (पिछले अनुभाग की जांच करें)।
कैश पॉइज़निंग
एक कैश उसी शाखा में वर्कफ़्लो रन के बीच बनाए रखा जाता है। इसका मतलब है कि यदि एक हमलावर पैकेज को समझौता करता है जो फिर कैश में संग्रहीत होता है और डाउनलोड और अधिक विशेषाधिकार प्राप्त वर्कफ़्लो द्वारा निष्पादित होता है, तो वह उस वर्कफ़्लो को भी समझौता कर सकेगा।
GH Actions - Cache Poisoningआर्टिफैक्ट पॉइज़निंग
वर्कफ़्लो अन्य वर्कफ़्लो और यहां तक कि रिपो से आर्टिफैक्ट्स का उपयोग कर सकते हैं, यदि एक हमलावर गिटहब एक्शन को समझौता करने में सफल होता है जो एक आर्टिफैक्ट अपलोड करता है जो बाद में किसी अन्य वर्कफ़्लो द्वारा उपयोग किया जाता है, तो वह अन्य वर्कफ़्लो को समझौता कर सकता है:
Gh Actions - Artifact Poisoningएक्शन से पोस्ट एक्सप्लॉइटेशन
OIDC के माध्यम से AWS और GCP तक पहुंच
निम्नलिखित पृष्ठों की जांच करें:
AWS - Federation AbuseGCP - Federation Abuseसीक्रेट्स तक पहुंच
यदि आप किसी स्क्रिप्ट में सामग्री इंजेक्ट कर रहे हैं, तो यह जानना दिलचस्प है कि आप सीक्रेट्स तक कैसे पहुंच सकते हैं:
यदि सीक्रेट या टोकन को पर्यावरण चर पर सेट किया गया है, तो इसे सीधे पर्यावरण के माध्यम से
printenv
का उपयोग करके एक्सेस किया जा सकता है।
यदि सीक्रेट का उपयोग प्रत्यक्ष रूप से एक अभिव्यक्ति में किया जाता है, तो उत्पन्न शेल स्क्रिप्ट डिस्क पर संग्रहीत होती है और सुलभ होती है।
cat /home/runner/work/_temp/*
एक कस्टम एक्शन के लिए, जोखिम इस बात पर निर्भर कर सकता है कि एक प्रोग्राम ने आर्गुमेंट से प्राप्त सीक्रेट का उपयोग कैसे किया है:
Self-hosted runners का दुरुपयोग
यह पता लगाने का तरीका कि कौन से Github Actions गैर-गिटहब इन्फ्रास्ट्रक्चर में निष्पादित हो रहे हैं यह है कि Github Action कॉन्फ़िगरेशन yaml में runs-on: self-hosted
खोजें।
Self-hosted runners को अतिरिक्त संवेदनशील जानकारी, अन्य नेटवर्क सिस्टम्स (नेटवर्क में कमजोर एंडपॉइंट्स? मेटाडेटा सेवा?) तक पहुंच हो सकती है, या, भले ही यह अलग-थलग और नष्ट हो, एक से अधिक एक्शन एक ही समय में चलाए जा सकते हैं और दुर्भावनापूर्ण एक्शन अन्य एक्शन के सीक्रेट्स चुरा सकता है।
Self-hosted runners में यह भी संभव है कि _Runner.Listener_** प्रक्रिया** से सीक्रेट्स प्राप्त किए जाएं जो किसी भी चरण में वर्कफ़्लोज़ के सभी सीक्रेट्स को उसकी मेमोरी को डंप करके शामिल करेगा:
इस पोस्ट में अधिक जानकारी देखें.
Github Docker Images Registry
यह संभव है कि Github actions बनाए जाएं जो Docker image को Github के अंदर build और store करें। एक उदाहरण निम्नलिखित विस्तार योग्य में पाया जा सकता है:
Last updated