Pentesting CI/CD कार्यप्रणाली

Reading time: 9 minutes

VCS

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

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

CI/CD Pipelines

CI/CD pipelines developers को कोड के execution को automate करने में मदद करते हैं — build, test और deploy applications जैसे कार्यों के लिए। ये automated workflows συγκεκριμένες actions द्वारा trigger होते हैं, जैसे code pushes, pull requests, या scheduled tasks. ये development से production तक के process को streamline करने में उपयोगी हैं।

हालाँकि, इन systems को कहीं execute करना पड़ता है और अक्सर उन्हें privileged credentials to deploy code or access sensitive information की आवश्यकता होती है।

VCS Pentesting Methodology

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

• Leaks: If your code contains leaks in the commits and the attacker can access the repo (because it's public or because he has access), he could discover the leaks.
• Access: अगर कोई attacker VCS platform के अंदर किसी account तक access प्राप्त कर लेता है तो वह ज़्यादा visibility और permissions हासिल कर सकता है।
• Register: कुछ platforms बाहरी users को सिर्फ 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 generate करने की अनुमति देती हैं। अगर वे नॉन-प्रोटेक्टेड हैं और किसी non visible secret से सुरक्षित नहीं हैं तो attacker उनका दुरुपयोग कर सकता है।
• अगर कोई secret मौजूद नहीं है, attacker तीसरे पक्ष के 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 hosted in the repository जिसे pipeline build करता है। यह file executed jobs के order, flow को प्रभावित करने वाली conditions, और build environment settings का वर्णन करती है.
ये files आम तौर पर एक सुसंगत नाम और format रखती हैं, उदाहरण के लिए — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), और GitHub Actions YAML files जो .github/workflows के अंतर्गत होते हैं। जब trigger होता है, pipeline job selected source (उदाहरण: commit / branch) से code को pull करता है, और CI configuration file में specified commands को उस code पर run करता है।

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

PPE - Poisoned Pipeline Execution

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

किसी malicious actor को PPE attack सफलतापूर्वक करने के लिए निम्न होना चाहिए:

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

PPE के 3 flavours हैं:

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

Exploitation Benefits

PPE के 3 flavours जानने के बाद, आइए देखें कि successful exploitation के बाद attacker क्या हासिल कर सकता है:

• Secrets: जैसा पहले बताया गया था, pipelines अपने jobs के लिए privileges चाहती हैं (code retrieve करना, build करना, deploy करना...) और ये privileges आम तौर पर secrets में दिए जाते हैं। ये secrets आम तौर पर env variables या system के अंदर files के माध्यम से उपलब्ध होते हैं। इसलिए attacker हमेशा जितने अधिक secrets exfiltrate कर सकेगा उतना करेगा।
• pipeline platform पर निर्भर करते हुए attacker को config में secrets specify करने पड़ सकते हैं। इसका अर्थ है कि अगर attacker CI configuration pipeline को modify नहीं कर सकता (I-PPE उदाहरण के लिए), तो वह केवल उन secrets को ही exfiltrate कर सकता है जो उस pipeline के पास हैं।
• Computation: कोड कहीं execute होता है, उस execution स्थान पर attacker आगे pivot कर सकता है।
• On-Premises: अगर pipelines on premises execute होती हैं, तो attacker internal network में पहुँच सकता है और और resources तक access हासिल कर सकता है।
• Cloud: attacker अन्य machines in the cloud तक पहुँच सकता है और साथ ही IAM roles/service accounts tokens exfiltrate करके cloud के अंदर और access प्राप्त कर सकता है।
• Platforms machine: कभी-कभी jobs pipelines platform machines के अंदर execute होती हैं, जो आम तौर पर cloud में होती हैं और जिनके पास अक्सर और अधिक access नहीं होता।
• Select it: कभी-कभी pipelines platform कई machines configure कर सकता है और अगर आप CI configuration file modify कर सकते हैं तो आप indicate कर सकते हैं कि आप malicious code कहाँ चलाना चाहते हैं। ऐसी स्थिति में attacker संभवतः हर possible 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 के लिए auditing करता है based on एक नए CIS Software Supply Chain benchmark. auditing पूरा SDLC process पर केंद्रित है, जहाँ यह code time से deploy time तक के risks को उजागर कर सकता है।

Top 10 CI/CD Security Risk

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

Labs

• हर platform के लिए जिसे आप 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