From a5a150c96dac6f7972de45190c2c46aafd726832 Mon Sep 17 00:00:00 2001 From: Translator Date: Sun, 31 Aug 2025 08:22:29 +0000 Subject: [PATCH] Translated ['src/pentesting-ci-cd/gitblit-security/gitblit-embedded-ssh- --- .../gitblit-security/README.md | 21 ++++ ...embedded-ssh-auth-bypass-cve-2024-28080.md | 107 ++++++++++++++++++ .../pentesting-ci-cd-methodology.md | 95 ++++++++-------- 3 files changed, 177 insertions(+), 46 deletions(-) create mode 100644 src/pentesting-ci-cd/gitblit-security/README.md create mode 100644 src/pentesting-ci-cd/gitblit-security/gitblit-embedded-ssh-auth-bypass-cve-2024-28080.md diff --git a/src/pentesting-ci-cd/gitblit-security/README.md b/src/pentesting-ci-cd/gitblit-security/README.md new file mode 100644 index 000000000..0a70acf43 --- /dev/null +++ b/src/pentesting-ci-cd/gitblit-security/README.md @@ -0,0 +1,21 @@ +# Gitblit सुरक्षा + +{{#include ../../banners/hacktricks-training.md}} + +## Gitblit क्या है + +Gitblit Java में लिखा गया एक self‑hosted Git server है। यह standalone JAR के रूप में या servlet containers में चल सकता है और Git over SSH के लिए embedded SSH service (Apache MINA SSHD) के साथ आता है। + +## विषय + +- Gitblit Embedded SSH Auth Bypass (CVE-2024-28080) + +{{#ref}} +gitblit-embedded-ssh-auth-bypass-cve-2024-28080.md +{{#endref}} + +## संदर्भ + +- [Gitblit project](https://gitblit.com/) + +{{#include ../../banners/hacktricks-training.md}} diff --git a/src/pentesting-ci-cd/gitblit-security/gitblit-embedded-ssh-auth-bypass-cve-2024-28080.md b/src/pentesting-ci-cd/gitblit-security/gitblit-embedded-ssh-auth-bypass-cve-2024-28080.md new file mode 100644 index 000000000..4e29b97e4 --- /dev/null +++ b/src/pentesting-ci-cd/gitblit-security/gitblit-embedded-ssh-auth-bypass-cve-2024-28080.md @@ -0,0 +1,107 @@ +# Gitblit Embedded SSH Auth Bypass (CVE-2024-28080) + +{{#include ../../banners/hacktricks-training.md}} + +## सारांश + +CVE-2024-28080 Gitblit के embedded SSH सर्विस में एक authentication bypass है जो Apache MINA SSHD के साथ एकीकरण करते समय session state के गलत हैंडलिंग के कारण हुआ। अगर किसी user अकाउंट में कम से कम एक SSH public key रजिस्टर्ड है, तो एक attacker जो username और उस user की किसी भी public key को जानता है, private key और password के बिना authenticate कर सकता है। + +- प्रभावित: Gitblit < 1.10.0 (observed on 1.9.3) +- Fixed: 1.10.0 +- शोषण के लिए आवश्यकताएँ: +- Git over SSH instance पर enabled होना चाहिए +- पीड़ित अकाउंट में कम से कम एक SSH public key Gitblit में रजिस्टर्ड होनी चाहिए +- Attacker को पीड़ित username और उनकी किसी एक public key का पता होना चाहिए (अकसर खोजने योग्य, उदाहरण के लिए https://github.com/.keys) + +## मूल कारण (state leaks between SSH methods) + +RFC 4252 के अनुसार, public‑key authentication दो चरणों में होती है: सर्वर पहले जाँचता है कि दिया गया public key किसी username के लिए स्वीकार्य है या नहीं, और केवल challenge/response के साथ signature के बाद ही वह user को authenticate करता है। MINA SSHD में, PublickeyAuthenticator को दो बार बुलाया जाता है: key acceptance पर (अभी signature नहीं) और बाद में जब client signature लौटाता है। + +Gitblit का PublickeyAuthenticator पहले, pre‑signature कॉल पर session context को बदल देता था (mutate) करके authenticated UserModel को session से जोड़ देता था और true लौटाता था ("key acceptable")। जब बाद में authentication password पर fallback हुआ, तो PasswordAuthenticator ने उस mutated session state पर भरोसा किया और short‑circuit करते हुए बिना password validate किए true लौटाया। परिणामस्वरूप, किसी भी password (खाली सहित) को एक prior public‑key "acceptance" के बाद उसी user के लिए स्वीकार कर लिया गया। + +उच्च‑स्तरीय दोषपूर्ण flow: + +1) Client username + public key भेजता है (अभी signature नहीं) +2) Server key को user का मानता है और जल्दबाजी में user को session से जोड़ देता है, true लौटाता है ("acceptable") +3) Client sign नहीं कर पाता (private key नहीं), तो auth password पर fallback होता है +4) Password auth session में पहले से मौजूद user देखता है और बिना शर्त success लौटाता है + +## Step‑by‑step exploitation + +- पीड़ित का username और उनकी किसी एक public key इकट्ठा करें: +- GitHub public keys को https://github.com/.keys पर दिखाता है +- Public servers अक्सर authorized_keys एक्सपोज़ करते हैं +- Configure OpenSSH ताकि वह केवल public half प्रस्तुत करे जिससे signature generation fail हो, और password पर fallback मजबूर हो जबकि server पर public‑key acceptance path ट्रिगर हो रहा हो। + +Example SSH client config (no private key available): +```sshconfig +# ~/.ssh/config +Host gitblit-target +HostName +User +PubkeyAuthentication yes +PreferredAuthentications publickey,password +IdentitiesOnly yes +IdentityFile ~/.ssh/victim.pub # public half only (no private key present) +``` +कनेक्ट करें और पासवर्ड प्रॉम्प्ट पर Enter दबाएँ (या कोई भी स्ट्रिंग टाइप करें): +```bash +ssh gitblit-target +# or Git over SSH +GIT_SSH_COMMAND="ssh -F ~/.ssh/config" git ls-remote ssh://@/ +``` +प्रमाणीकरण इसलिए सफल हो जाता है क्योंकि पहले के public‑key चरण ने session को एक authenticated user में बदल दिया था, और password auth उस स्थिति पर गलत तरीके से भरोसा कर लेता है। + +नोट: यदि ControlMaster multiplexing आपके SSH config में सक्षम है, तो बाद के Git कमांड्स वही authenticated connection reuse कर सकते हैं, जिससे प्रभाव बढ़ सकता है। + +## प्रभाव + +- किसी भी Gitblit user की पूर्ण impersonation जिसकी कम से कम एक registered SSH public key हो +- victim की permissions के अनुसार repositories तक read/write access (source exfiltration, unauthorized pushes, supply‑chain risks) +- यदि लक्ष्य admin user हो तो संभावित administrative प्रभाव +- शुद्ध network exploit; किसी brute force या private key की आवश्यकता नहीं + +## पता लगाने के सुझाव + +- SSH logs की समीक्षा करें उन सीक्वेंस के लिए जहाँ publickey प्रयास के बाद खाली या बहुत छोटा password देकर सफल password authentication होती है +- इन flows की तलाश करें: publickey method द्वारा unsupported/mismatched key material पेश किया जाना और उसके तुरंत बाद उसी username के लिए password के सफल होने की घटना + +## निवारण + +- Gitblit v1.10.0+ में upgrade करें +- जब तक upgrade नहीं हो जाता: +- Gitblit पर Git over SSH को Disable करें, या +- SSH service के network access को सीमित करें, और +- ऊपर बताए गए संदिग्ध पैटर्न की निगरानी करें +- यदि compromise का संदेह हो तो प्रभावित user credentials को rotate करें + +## General: abusing SSH auth method state‑leakage (MINA/OpenSSH‑based services) + +पैटर्न: यदि किसी server का public‑key authenticator pre‑signature "key acceptable" चरण के दौरान user/session state को बदल देता है और अन्य authenticators (जैसे password) उस स्थिति पर भरोसा करते हैं, तो आप निम्न तरीके से authentication bypass कर सकते हैं: + +- लक्ष्य user के लिए एक वैध public key पेश करना (कोई private key आवश्यक नहीं) +- client को signing fail करने के लिए मजबूर करना ताकि server password पर fallback कर ले +- password authenticator किसी leaked state पर short‑circuit करते हुए किसी भी password को स्वीकार कर लेना + +व्यावहारिक सुझाव: + +- Public key harvesting at scale: https://github.com/.keys, organizational directories, team pages, leaked authorized_keys जैसे सामान्य स्रोतों से public keys खींचें +- Forcing signature failure (client‑side): IdentityFile को केवल .pub पर पॉइंट करें, IdentitiesOnly yes सेट करें, और PreferredAuthentications में पहले publickey फिर password शामिल रखें +- MINA SSHD integration pitfalls: +- PublickeyAuthenticator.authenticate(...) को user/session state जोड़ने नहीं देना चाहिए जब तक कि post‑signature verification path signature की पुष्टि न कर दे +- PasswordAuthenticator.authenticate(...) को किसी prior, incomplete authentication method के दौरान mutated किसी भी state से सफलता infer नहीं करनी चाहिए + +संबंधित protocol/design नोट्स और साहित्य: +- SSH userauth protocol: RFC 4252 (publickey method is a two‑stage process) +- प्रारम्भिक acceptance oracles और auth races पर ऐतिहासिक चर्चा, जैसे CVE‑2016‑20012 विवाद OpenSSH व्यवहार के इर्द‑गिर्द + +## References + +- [Gitblit CVE-2024-28080: SSH public‑key fallback to password authentication bypass (Silent Signal blog)](https://blog.silentsignal.eu/2025/06/14/gitblit-cve-CVE-2024-28080/) +- [Gitblit v1.10.0 release notes](https://github.com/gitblit-org/gitblit/releases/tag/v1.10.0) +- [Apache MINA SSHD project](https://mina.apache.org/sshd-project/) +- [PublickeyAuthenticator API](https://svn.apache.org/repos/infra/websites/production/mina/content/sshd-project/apidocs/org/apache/sshd/server/auth/pubkey/PublickeyAuthenticator.html) +- [RFC 4252: The Secure Shell (SSH) Authentication Protocol](https://datatracker.ietf.org/doc/html/rfc4252) + + +{{#include ../../banners/hacktricks-training.md}} diff --git a/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md b/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md index 206b667ca..2916a0cc8 100644 --- a/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md +++ b/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md @@ -1,4 +1,4 @@ -# Pentesting CI/CD Methodology +# Pentesting CI/CD कार्यप्रणाली {{#include ../banners/hacktricks-training.md}} @@ -6,99 +6,102 @@ ## VCS -VCS का मतलब है **Version Control System**, यह सिस्टम डेवलपर्स को **अपने स्रोत कोड का प्रबंधन** करने की अनुमति देता है। सबसे सामान्य है **git** और आप आमतौर पर कंपनियों को निम्नलिखित **प्लेटफार्मों** में इसका उपयोग करते हुए पाएंगे: +VCS का अर्थ है **Version Control System**, यह सिस्टम डेवलपर्स को उनके **source code** को **manage** करने की अनुमति देता है। सबसे आम वाला है **git** और आमतौर पर कंपनियाँ इसे निम्नलिखित **platforms** में से किसी एक पर उपयोग करती हैं: - Github - Gitlab - Bitbucket - Gitea -- Cloud providers (वे अपने स्वयं के VCS प्लेटफार्म प्रदान करते हैं) +- Gitblit +- Cloud providers (they offer their own VCS platforms) + ## CI/CD Pipelines -CI/CD पाइपलाइनों से डेवलपर्स को **कोड के निष्पादन को स्वचालित** करने की अनुमति मिलती है विभिन्न उद्देश्यों के लिए, जिसमें एप्लिकेशन का निर्माण, परीक्षण और तैनाती शामिल है। ये स्वचालित कार्यप्रवाह **विशिष्ट क्रियाओं** द्वारा **प्रेरित** होते हैं, जैसे कोड पुश, पुल अनुरोध, या अनुसूचित कार्य। ये विकास से उत्पादन तक की प्रक्रिया को सरल बनाने के लिए उपयोगी हैं। +CI/CD pipelines डेवलपर्स को कोड के execution को **automate** करने में सक्षम बनाते हैं, जैसे कि build, test, और deploy करने के लिए। ये automated workflows विशिष्ट actions से **trigger** होते हैं, जैसे code pushes, pull requests, या scheduled tasks. ये development से production तक के प्रोसेस को streamline करने में उपयोगी हैं। -हालांकि, इन सिस्टम को **कहीं निष्पादित** करने की आवश्यकता होती है और आमतौर पर **संवेदनशील जानकारी तक पहुंचने या कोड तैनात करने के लिए विशेषाधिकार प्राप्त क्रेडेंशियल्स के साथ**। +हालाँकि, इन सिस्टम्स को किसी न किसी जगह पर **execute** होना पड़ता है और आमतौर पर उन्हें **privileged credentials** चाहिए होते हैं ताकि वे code deploy कर सकें या sensitive information तक पहुँच पाएं। ## VCS Pentesting Methodology > [!NOTE] -> भले ही कुछ VCS प्लेटफार्मों को इस अनुभाग के लिए पाइपलाइनों को बनाने की अनुमति हो, हम केवल स्रोत कोड के नियंत्रण पर संभावित हमलों का विश्लेषण करने जा रहे हैं। +> Even if some VCS platforms allow to create pipelines for this section we are going to analyze only potential attacks to the control of the source code. -आपकी परियोजना के स्रोत कोड वाले प्लेटफार्मों में संवेदनशील जानकारी होती है और लोगों को इस प्लेटफार्म के भीतर दिए गए अनुमतियों के साथ बहुत सावधान रहना चाहिए। ये कुछ सामान्य समस्याएं हैं जो VCS प्लेटफार्मों में हो सकती हैं जिनका हमलावर दुरुपयोग कर सकता है: +जो platforms आपके project का source code रखते हैं उनमें sensitive जानकारी होती है और लोगों को इस प्लेटफ़ॉर्म के अंदर दिए गए permissions के साथ बहुत सावधान रहना चाहिए। ये कुछ सामान्य समस्याएँ हैं जो VCS platforms में attackers द्वारा abused की जा सकती हैं: -- **Leaks**: यदि आपके कोड में कमिट्स में लीक हैं और हमलावर को रिपॉजिटरी तक पहुंच प्राप्त है (क्योंकि यह सार्वजनिक है या क्योंकि उसके पास पहुंच है), तो वह लीक का पता लगा सकता है। -- **Access**: यदि एक हमलावर **VCS प्लेटफार्म के भीतर एक खाते तक पहुंच प्राप्त कर सकता है**, तो वह **अधिक दृश्यता और अनुमतियाँ** प्राप्त कर सकता है। -- **Register**: कुछ प्लेटफार्म केवल बाहरी उपयोगकर्ताओं को एक खाता बनाने की अनुमति देंगे। -- **SSO**: कुछ प्लेटफार्म उपयोगकर्ताओं को पंजीकरण करने की अनुमति नहीं देंगे, लेकिन किसी को भी एक मान्य SSO के साथ पहुंचने की अनुमति देंगे (इसलिए एक हमलावर अपने github खाते का उपयोग करके प्रवेश कर सकता है, उदाहरण के लिए)। -- **Credentials**: Username+Pwd, व्यक्तिगत टोकन, ssh कुंजी, Oauth टोकन, कुकीज़... उपयोगकर्ता कई प्रकार के टोकन चुरा सकते हैं ताकि किसी तरह एक रिपॉजिटरी तक पहुंच प्राप्त कर सकें। -- **Webhooks**: VCS प्लेटफार्म वेबहुक उत्पन्न करने की अनुमति देते हैं। यदि वे **अदृश्य रहस्यों** के साथ **संरक्षित नहीं हैं**, तो एक **हमलावर उनका दुरुपयोग कर सकता है**। -- यदि कोई रहस्य नहीं है, तो हमलावर तीसरे पक्ष के प्लेटफार्म के वेबहुक का दुरुपयोग कर सकता है -- यदि रहस्य URL में है, तो वही होता है और हमलावर के पास भी रहस्य होता है -- **Code compromise:** यदि एक दुर्भावनापूर्ण अभिनेता के पास रिपॉजिटरी पर कुछ प्रकार की **लिखने** की पहुंच है, तो वह **दुर्भावनापूर्ण कोड** को **इंजेक्ट** करने की कोशिश कर सकता है। सफल होने के लिए, उसे **ब्रांच सुरक्षा को बायपास** करने की आवश्यकता हो सकती है। ये क्रियाएँ विभिन्न लक्ष्यों के साथ की जा सकती हैं: -- मुख्य शाखा को **उत्पादन को समझौता करने** के लिए समझौता करना। -- मुख्य (या अन्य शाखाओं) को **डेवलपर्स की मशीनों को समझौता करने** के लिए समझौता करना (क्योंकि वे आमतौर पर परीक्षण, टेराफॉर्म या अन्य चीजें अपनी मशीनों में रिपॉजिटरी के भीतर निष्पादित करते हैं)। -- **पाइपलाइन को समझौता करना** (अगले अनुभाग की जांच करें) +- **Leaks**: यदि आपका code commits में leaks रखता है और attacker repo तक पहुँच सकता है (क्योंकि यह public है या उसके पास access है), तो वह उन leaks को खोज सकता है। +- **Access**: यदि एक attacker VCS platform के अंदर किसी account तक **access** प्राप्त कर लेता है तो वह और भी अधिक visibility और permissions प्राप्त कर सकता है। +- **Register**: कुछ platforms बाहरी users को बस अकाउंट बनाने की अनुमति देते हैं। +- **SSO**: कुछ platforms users को register करने की अनुमति नहीं देते, पर किसी valid SSO के साथ किसी को भी access देने की अनुमति देते हैं (तो एक attacker उदाहरण के लिए अपने github account का उपयोग करके अंदर आ सकता है)। +- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... उपयोगकर्ता अनेक प्रकार के tokens चोरी कर सकता है ताकि किसी न किसी तरह से repo तक पहुँच सके। +- **Webhooks**: VCS platforms webhooks generate करने की अनुमति देते हैं। यदि वे **not protected** हैं गैर-दिखने वाले secrets के साथ तो **attacker उनका गलत इस्तेमाल कर सकता है**। +- यदि कोई secret inplace नहीं है, तो 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 के अंदर tests, terraform या अन्य चीज़ें अपने machines पर execute करते हैं)। +- **Compromise the pipeline** (अगला सेक्शन देखें) ## Pipelines Pentesting Methodology -पाइपलाइन को परिभाषित करने का सबसे सामान्य तरीका है **रिपॉजिटरी में होस्ट की गई CI कॉन्फ़िगरेशन फ़ाइल** का उपयोग करना जिसे पाइपलाइन बनाती है। यह फ़ाइल निष्पादित कार्यों के क्रम, प्रवाह को प्रभावित करने वाली शर्तों, और निर्माण वातावरण सेटिंग्स का वर्णन करती है।\ -ये फ़ाइलें आमतौर पर एक सुसंगत नाम और प्रारूप रखती हैं, उदाहरण के लिए — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), और .github/workflows के तहत स्थित GitHub Actions YAML फ़ाइलें। जब प्रेरित किया जाता है, तो पाइपलाइन कार्य **चयनित स्रोत से कोड खींचता है** (जैसे कमिट / शाखा), और **CI कॉन्फ़िगरेशन फ़ाइल में निर्दिष्ट आदेशों को** उस कोड के खिलाफ चलाता है। +Pipeline को define करने का सबसे सामान्य तरीका है **CI configuration file जो repository में host किया गया हो** जिसे pipeline build करता है। यह file executed jobs के order, flow को प्रभावित करने वाली conditions, और build environment settings का विवरण देती है.\ +ये files आम तौर पर एक consistent name और format रखती हैं, जैसे — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), और GitHub Actions YAML files जो .github/workflows के अंतर्गत होते हैं। जब trigger होता है, pipeline job चुने गए स्रोत (उदा. commit / branch) से **code को pull करता है**, और CI configuration file में निर्दिष्ट commands को उस code पर **run** करता है। -इसलिए हमलावर का अंतिम लक्ष्य किसी तरह **उन कॉन्फ़िगरेशन फ़ाइलों को समझौता करना** या **वे जो आदेश निष्पादित करते हैं**। +इसलिए attacker का अंतिम लक्ष्य किसी न किसी तरह से उन configuration files या उन commands को **compromise** करना है जिनको वे execute करते हैं। ### PPE - Poisoned Pipeline Execution -Poisoned Pipeline Execution (PPE) पथ एक SCM रिपॉजिटरी में अनुमतियों का दुरुपयोग करता है ताकि एक CI पाइपलाइन को हेरफेर किया जा सके और हानिकारक आदेशों को निष्पादित किया जा सके। आवश्यक अनुमतियों वाले उपयोगकर्ता CI कॉन्फ़िगरेशन फ़ाइलों या अन्य फ़ाइलों को संशोधित कर सकते हैं जो पाइपलाइन कार्य द्वारा उपयोग की जाती हैं ताकि दुर्भावनापूर्ण आदेश शामिल किए जा सकें। यह "CI पाइपलाइन को विषाक्त" करता है, जिससे इन दुर्भावनापूर्ण आदेशों का निष्पादन होता है। +The Poisoned Pipeline Execution (PPE) path SCM repository में permissions का उपयोग करके CI pipeline को manipulate करने और हानिकारक commands execute कराने का exploit करता है। जिन users के पास आवश्यक permissions होते हैं वे CI configuration files या pipeline job द्वारा उपयोग की जाने वाली अन्य files को modify कर के malicious commands शामिल कर सकते हैं। यह CI pipeline को "poison" कर देता है, जिससे ये malicious commands execute हो जाते हैं। -एक दुर्भावनापूर्ण अभिनेता को PPE हमले को सफलतापूर्वक करने के लिए सक्षम होना चाहिए: +एक malicious actor के लिए PPE attack सफल होने के लिए उसे सक्षम होना चाहिए कि: -- **VCS प्लेटफार्म पर लिखने की पहुंच** हो, क्योंकि आमतौर पर पाइपलाइन तब प्रेरित होती है जब एक पुश या पुल अनुरोध किया जाता है। (पहुंच प्राप्त करने के तरीकों का सारांश देखने के लिए VCS पेंटेस्टिंग पद्धति की जांच करें)। -- ध्यान दें कि कभी-कभी एक **बाहरी PR को "लिखने की पहुंच" के रूप में गिना जाता है**। -- भले ही उसके पास लिखने की अनुमतियाँ हों, उसे यह सुनिश्चित करने की आवश्यकता है कि वह **CI कॉन्फ़िगरेशन फ़ाइल या अन्य फ़ाइलों को संशोधित कर सकता है जिन पर कॉन्फ़िगरेशन निर्भर करता है**। -- इसके लिए, उसे **ब्रांच सुरक्षा को बायपास** करने में सक्षम होना पड़ सकता है। +- VCS platform पर उसके पास **write access** हो, क्योंकि आमतौर पर pipelines तब trigger होते हैं जब push या pull request किया जाता है। (Access पाने के तरीकों के सार के लिए VCS pentesting methodology देखें). +- ध्यान दें कि कभी-कभी एक **external PR को "write access" माना जा सकता है**। +- भले ही उसके पास write permissions हों, उसे यह सुनिश्चित करना होगा कि वह **CI config file या उन अन्य files को modify कर सके जिन पर config निर्भर करता है**। +- इसके लिए उसे संभवतः **branch protections** को **bypass** करने में सक्षम होना चाहिए। -PPE के 3 प्रकार हैं: +PPE के 3 रूप हैं: -- **D-PPE**: एक **Direct PPE** हमला तब होता है जब अभिनेता **CI कॉन्फ़िगरेशन** फ़ाइल को संशोधित करता है जिसे निष्पादित किया जाने वाला है। -- **I-DDE**: एक **Indirect PPE** हमला तब होता है जब अभिनेता **संशोधित करता है** एक **फ़ाइल** जिसे CI कॉन्फ़िगरेशन फ़ाइल निष्पादित होने पर **निर्भर करती है** (जैसे एक मेक फ़ाइल या एक टेराफॉर्म कॉन्फ़िगरेशन)। -- **Public PPE या 3PE**: कुछ मामलों में पाइपलाइनों को **उन उपयोगकर्ताओं द्वारा प्रेरित किया जा सकता है जिनके पास रिपॉजिटरी में लिखने की पहुंच नहीं है** (और जो शायद संगठन का हिस्सा भी नहीं हैं) क्योंकि वे एक PR भेज सकते हैं। -- **3PE Command Injection**: आमतौर पर, CI/CD पाइपलाइनों **पर्यावरण चर सेट करेंगी** **PR के बारे में जानकारी** के साथ। यदि उस मान को एक हमलावर द्वारा नियंत्रित किया जा सकता है (जैसे PR का शीर्षक) और इसका **उपयोग** एक **खतरनाक स्थान** में किया जाता है (जैसे **sh आदेशों** को निष्पादित करना), तो एक हमलावर **वहाँ आदेश इंजेक्ट कर सकता है**। +- **D-PPE**: A **Direct PPE** attack तब होता है जब actor उस CI config file को **modify** कर देता है जिसे execute किया जाना है। +- **I-DDE**: An **Indirect PPE** attack तब होता है जब actor उस **file** को **modify** करता है जिस पर CI config file निर्भर करती है (जैसे 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) और वह value किसी **dangerous जगह** (जैसे sh commands execute करने में) उपयोग होती है, तो attacker वहाँ **command inject** कर सकता है। ### Exploitation Benefits -पाइपलाइन को विषाक्त करने के 3 प्रकारों को जानने के बाद, चलिए देखते हैं कि एक हमलावर सफल शोषण के बाद क्या प्राप्त कर सकता है: +Poisoned pipeline के 3 रूपों को जानने के बाद, चलिए देखते हैं कि सफल exploitation के बाद attacker क्या प्राप्त कर सकता है: -- **Secrets**: जैसा कि पहले उल्लेख किया गया था, पाइपलाइनों को उनके कार्यों के लिए **विशेषाधिकार** की आवश्यकता होती है (कोड प्राप्त करना, इसे बनाना, इसे तैनात करना...) और ये विशेषाधिकार आमतौर पर **रहस्यों में दिए जाते हैं**। ये रहस्य आमतौर पर **env चर या सिस्टम के भीतर फ़ाइलों के माध्यम से** सुलभ होते हैं। इसलिए एक हमलावर हमेशा जितना संभव हो सके उतने रहस्यों को निकालने की कोशिश करेगा। -- पाइपलाइन प्लेटफार्म के आधार पर हमलावर को **कॉन्फ़िगरेशन में रहस्यों को निर्दिष्ट करने की आवश्यकता हो सकती है**। इसका मतलब है कि यदि हमलावर CI कॉन्फ़िगरेशन पाइपलाइन को संशोधित नहीं कर सकता (**I-PPE** उदाहरण के लिए), तो वह **केवल उन रहस्यों को निकाल सकता है जो पाइपलाइन के पास हैं**। -- **Computation**: कोड कहीं निष्पादित होता है, जिस स्थान पर यह निष्पादित होता है उसके आधार पर एक हमलावर आगे बढ़ने में सक्षम हो सकता है। -- **On-Premises**: यदि पाइपलाइनों को ऑन-प्रिमाइसेस पर निष्पादित किया जाता है, तो एक हमलावर एक **आंतरिक नेटवर्क में अधिक संसाधनों तक पहुंच** प्राप्त कर सकता है। -- **Cloud**: हमलावर **क्लाउड में अन्य मशीनों** तक पहुंच प्राप्त कर सकता है लेकिन वह **IAM भूमिकाओं/सेवा खातों के टोकन** को भी निकाल सकता है ताकि **क्लाउड के भीतर आगे की पहुंच प्राप्त की जा सके**। -- **Platforms machine**: कभी-कभी कार्य **पाइपलाइनों प्लेटफार्म मशीनों** के भीतर निष्पादित होते हैं, जो आमतौर पर एक क्लाउड के भीतर होते हैं जिसमें **कोई और पहुंच नहीं होती**। -- **Select it:** कभी-कभी **पाइपलाइनों प्लेटफार्म में कई मशीनें कॉन्फ़िगर की गई होती हैं** और यदि आप **CI कॉन्फ़िगरेशन फ़ाइल को संशोधित कर सकते हैं** तो आप **यह निर्दिष्ट कर सकते हैं कि आप दुर्भावनापूर्ण कोड कहाँ चलाना चाहते हैं**। इस स्थिति में, एक हमलावर शायद प्रत्येक संभावित मशीन पर एक रिवर्स शेल चलाएगा ताकि इसे आगे बढ़ाने की कोशिश की जा सके। -- **Compromise production**: यदि आप पाइपलाइन के भीतर हैं और अंतिम संस्करण इससे बनाया और तैनात किया गया है, तो आप **कोड को समझौता कर सकते हैं जो उत्पादन में चलने वाला है**। +- **Secrets**: जैसा कि पहले बताया गया, pipelines अपने jobs के लिए **privileges** चाहती हैं (code retrieve करना, build करना, deploy करना...) और ये privileges आमतौर पर **secrets** में store किए जाते हैं। ये 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**: code कहीं execute होता है; कहाँ execute होता है इस पर निर्भर करते हुए attacker आगे pivot कर सकता है। +- **On-Premises**: यदि pipelines on premises execute होते हैं, तो attacker एक internal network में पहुँच सकता है जहाँ और भी resources उपलब्ध हो सकते हैं। +- **Cloud**: attacker अन्य machines तक access कर सकता है 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 कर सकते हैं तो आप **निर्दिष्ट कर सकते हैं कि आप malicious code कहाँ चलाना चाहते हैं**। ऐसी स्थिति में attacker संभवतः प्रत्येक मशीन पर reverse shell चला कर आगे exploit करने की कोशिश करेगा। +- **Compromise production**: यदि आप pipeline के अंदर हैं और final version वहीं से build और deploy होता है, तो आप production में चलने वाले code को compromise कर सकते हैं। ## More relevant info ### Tools & CIS Benchmark -- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) एक ओपन-सोर्स उपकरण है जो आपके सॉफ़्टवेयर आपूर्ति श्रृंखला स्टैक का सुरक्षा अनुपालन के लिए ऑडिट करता है जो एक नए [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf) पर आधारित है। ऑडिटिंग पूरे SDLC प्रक्रिया पर केंद्रित है, जहां यह कोड समय से लेकर तैनाती समय तक के जोखिमों को उजागर कर सकता है। +- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) is an open-source tool for auditing your software supply chain stack for security compliance based on a new [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). The auditing focuses on the entire SDLC process, where it can reveal risks from code time into deploy time. ### Top 10 CI/CD Security Risk -Cider के अनुसार शीर्ष 10 CI/CD जोखिमों के बारे में इस दिलचस्प लेख की जांच करें: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/) +Check this interesting article about the top 10 CI/CD risks according to Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/) ### Labs -- प्रत्येक प्लेटफार्म पर जिसे आप स्थानीय रूप से चला सकते हैं, आप इसे स्थानीय रूप से लॉन्च करने का तरीका पाएंगे ताकि आप इसे अपनी इच्छानुसार कॉन्फ़िगर कर सकें। +- On each platform that you can run locally you will find how to launch it locally so you can configure it as you want to test it - Gitea + Jenkins lab: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat) ### Automatic Tools -- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** एक स्थैतिक कोड विश्लेषण उपकरण है जो इन्फ्रास्ट्रक्चर-एज़-कोड के लिए है। +- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** is a static code analysis tool for 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](https://www.cidersecurity.io/blog/research/ppe-poisoned-pipeline-execution/?utm_source=github&utm_medium=github_page&utm_campaign=ci%2fcd%20goat_060422) + {{#include ../banners/hacktricks-training.md}}