Pentesting CI/CD Methodology

Reading time: 9 minutes

VCS

VCS का मतलब है Version Control System, यह सिस्टम डेवलपर्स को उनके source code को manage करने की अनुमति देता है। सबसे आम है git और आप आमतौर पर कंपनियों को निम्नलिखित platforms में से किसी एक का उपयोग करते हुए पाएँगे:

• Github
• Gitlab
• Bitbucket
• Gitea
• Gitblit
• Cloud providers (they offer their own VCS platforms)

CI/CD Pipelines

CI/CD pipelines डेवलपर्स को कोड के निष्पादन को automate करने में सक्षम बनाते हैं — जैसे build, test, और deploy करने के लिए। ये automated workflows विशिष्ट क्रियाओं द्वारा triggered होते हैं, जैसे code pushes, pull requests, या scheduled tasks. ये development से production तक के प्रक्रिया को आसान बनाने में उपयोगी होते हैं।

हालाँकि, इन सिस्टम्स को कहीं ना कहीं execute करना होता है और आम तौर पर इसके लिए privileged credentials की आवश्यकता होती है ताकि code deploy किया जा सके या sensitive information तक पहुँच प्राप्त की जा सके।

VCS Pentesting Methodology

जिस platform में आपके प्रोजेक्ट का source code होता है, वह संवेदनशील जानकारी रखता है और लोगों को इस platform के अंदर दिए गए permissions के साथ बहुत सावधान रहना चाहिए। VCS platforms में कुछ सामान्य समस्याएँ हैं जिनका attacker दुरुपयोग कर सकता है:

• Leaks: अगर आपके code में commits में leak मौजूद हैं और attacker repo तक पहुँच सकता है (क्योंकि वह public है या उसे access मिला हुआ है), तो वह उन leaks को खोज सकता है।
• Access: अगर attacker VCS platform के अंदर किसी account तक access प्राप्त कर लेता है तो वह और भी अधिक visibility और permissions प्राप्त कर सकता है।
• Register: कुछ platforms बाहरी उपयोगकर्ताओं को बस एक account बनाने की अनुमति देते हैं।
• SSO: कुछ platforms users को register करने की अनुमति नहीं देते, लेकिन valid SSO के साथ किसी को भी access करने दे सकते हैं (तो एक attacker अपने github account का उपयोग करके प्रवेश कर सकता है, उदाहरण के लिए)।
• Credentials: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... कई प्रकार के tokens होते हैं जिन्हें एक user चुरा सकता है ताकि किसी तरह repo तक access प्राप्त किया जा सके।
• Webhooks: VCS platforms webhooks जनरेट करने की अनुमति देते हैं। अगर वे non visible secrets के साथ protected नहीं हैं तो एक attacker उनका दुरुपयोग कर सकता है।
• अगर कोई secret मौजूद नहीं है, तो attacker third party platform के webhook का दुरुपयोग कर सकता है
• अगर secret URL में है, तो भी वही होता है और attacker के पास वह secret भी होगा
• Code compromise: अगर किसी malicious actor के पास repos पर किसी प्रकार का write access है, तो वह malicious code inject करने की कोशिश कर सकता है। सफल होने के लिए उसे शायद branch protections को bypass करना पड़ेगा। ये क्रियाएँ विभिन्न उद्देश्यों के साथ की जा सकती हैं:
• main branch को compromise करके production को compromise करना।
• main (या अन्य branches) को compromise करके developers के machines को compromise करना (क्योंकि वे आम तौर पर repo के अंदर test, terraform या अन्य चीजें अपने machines पर execute करते हैं)।
• Compromise the pipeline (अगला सेक्शन देखें)

Pipelines Pentesting Methodology

pipeline को define करने का सबसे आम तरीका है CI configuration file जो repository में hosted होती है जिसे pipeline build करता है। यह फाइल executed jobs का क्रम, flow को प्रभावित करने वाली conditions, और build environment settings का वर्णन करती है.
ये फाइलें आमतौर पर एक सुसंगत नाम और फॉर्मेट रखती हैं, उदाहरण के लिए — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), और GitHub Actions YAML फाइलें जो .github/workflows के अंतर्गत होती हैं। जब triggered होता है, तो pipeline job code को pull करता है चुने गए स्रोत से (जैसे commit / branch), और उस code के खिलाफ CI configuration file में निर्दिष्ट commands को run करता है।

इसलिए attacker का अंतिम लक्ष्य किसी न किसी तरीके से उन configuration files या उन commands को compromise करना होता है जो वे execute करते हैं।

PPE - Poisoned Pipeline Execution

Poisoned Pipeline Execution (PPE) पथ SCM repository में permissions का दुरुपयोग कर एक CI pipeline को manipulate करने और हानिकारक commands execute करवाने का फायदा उठाता है। जिन users के पास आवश्यक permissions होते हैं वे CI configuration files या pipeline job द्वारा उपयोग की जाने वाली अन्य फाइलों को modify कर सकते हैं ताकि malicious commands शामिल हो सकें। यह CI pipeline को "poison" कर देता है, जिससे ये malicious commands execute होते हैं।

एक malicious actor के लिए PPE attack सफल करने के लिए उसे निम्न बातें करनी होंगी:

• VCS platform पर write access होना चाहिए, क्योंकि आम तौर पर pipelines तब triggered होते हैं जब push या pull request किया जाता है। (Access प्राप्त करने के तरीकों के लिए VCS pentesting methodology देखें).
• ध्यान दें कि कभी-कभी एक external PR भी "write access" माना जा सकता है।
• भले ही उसके पास write permissions हों, उसे यह सुनिश्चित करना होगा कि वह CI config file या उन दूसरी फाइलों को modify कर सके जिन पर config निर्भर करता है।
• इसके लिए उसे शायद branch protections को bypass करने की आवश्यकता पड़े।

PPE के 3 flavour हैं:

• D-PPE: एक Direct PPE attack तब होता है जब actor उस CI config फाइल को modify कर देता है जो execute होने वाली है।
• I-DDE: एक Indirect PPE attack तब होता है जब actor उस file को modify करता है जिस पर CI config फाइल निर्भर करती है (जैसे एक make file या terraform config)।
• Public PPE or 3PE: कुछ मामलों में pipelines उन users द्वारा trigger किए जा सकते हैं जिनके पास repo में write access नहीं है (और जो शायद org का हिस्सा भी न हों) क्योंकि वे एक PR भेज सकते हैं।
• 3PE Command Injection: आम तौर पर, CI/CD pipelines environment variables सेट करते हैं जिनमें PR के बारे में जानकारी होती है। अगर उस value को attacker नियंत्रित कर सकता है (जैसे PR का title) और उसे किसी dangerous जगह पर use किया जाता है (जैसे sh commands execute करना), तो attacker वहाँ commands inject कर सकता है।

Exploitation Benefits

pipeline को poison करने के 3 flavour जानने के बाद, आइए देखें कि successful exploitation के बाद attacker क्या प्राप्त कर सकता है:

• Secrets: जैसा कि पहले बताया गया था, pipelines अपने jobs के लिए privileges की आवश्यकता होती है (code retrieve करने के लिए, build करने के लिए, deploy करने के लिए...) और ये privileges आमतौर पर secrets में दिए जाते हैं। ये secrets आम तौर पर env variables या सिस्टम के अंदर फाइलों के माध्यम से accessible होते हैं। इसलिए attacker हमेशा अधिक से अधिक secrets exfiltrate करने की कोशिश करेगा।
• pipeline platform पर निर्भर करते हुए attacker को config में secrets specify करने पड़ सकते हैं। इसका मतलब है कि अगर attacker CI configuration pipeline को modify नहीं कर सकता (I-PPE जैसा उदाहरण), तो वह केवल उन secrets को ही exfiltrate कर सकता है जो उस pipeline के पास हैं।
• Computation: कोड कहीं न कहीं execute होता है, और जहाँ execute होता है उसके आधार पर attacker आगे pivot कर सकता है।
• On-Premises: अगर pipelines on-premises execute होते हैं, तो attacker एक internal network में पहुँच सकता है जहाँ अधिक resources उपलब्ध हो सकते हैं।
• Cloud: attacker अन्य cloud machines तक पहुँच सकता है और साथ ही इसके IAM roles/service accounts tokens को exfiltrate करके cloud के अंदर और अधिक access प्राप्त कर सकता है।
• Platforms machine: कभी-कभी jobs pipeline platform machines के अंदर execute होते हैं, जो आमतौर पर किसी cloud में होते हैं और जिनके पास अधिक access नहीं होता।
• Select it: कभी-कभी pipeline platform कई machines configure करता है और अगर आप CI configuration file को modify कर सकते हैं तो आप यह निर्दिष्ट कर सकते हैं कि आप malicious code कहाँ चलाना चाहते हैं। ऐसी स्थिति में attacker शायद हर संभव machine पर reverse shell चलाकर आगे exploit करने की कोशिश करेगा।
• Compromise production: अगर आप pipeline के अंदर हैं और final version वहीं से build और deploy होता है, तो आप production में चलने वाले code को compromise कर सकते हैं।

More relevant info

Tools & CIS Benchmark

• Chain-bench एक open-source tool है जो आपके software supply chain stack का security compliance के हिसाब से audit करने के लिए है, यह एक नए CIS Software Supply Chain benchmark पर आधारित है। auditing पूरे SDLC process पर केन्द्रित होती है, जहाँ यह code time से लेकर deploy time तक के जोखिमों को उजागर कर सकती है।

Top 10 CI/CD Security Risk

Cider के अनुसार top 10 CI/CD risks पर यह रोचक article देखें: https://www.cidersecurity.io/top-10-cicd-security-risks/

Labs

• हर platform पर जिसे आप locally चला सकते हैं, आपको यह मिलेगा कि इसे locally कैसे लॉन्च करना है ताकि आप इसे अपनी पसंद के अनुसार configure करके टेस्ट कर सकें
• Gitea + Jenkins lab: https://github.com/cider-security-research/cicd-goat

Automatic Tools

• Checkov: Checkov एक static code analysis tool है infrastructure-as-code के लिए।

References

• https://www.cidersecurity.io/blog/research/ppe-poisoned-pipeline-execution/?utm_source=github&utm_medium=github_page&utm_campaign=ci%2fcd%20goat_060422