Jenkins Security
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Jenkins एक उपकरण है जो लगभग किसी भी प्रोग्रामिंग भाषाओं और स्रोत कोड रिपॉजिटरी के लिए निरंतर एकीकरण या निरंतर वितरण (CI/CD) वातावरण स्थापित करने के लिए एक सीधा तरीका प्रदान करता है। इसके अलावा, यह विभिन्न नियमित विकास कार्यों को स्वचालित करता है। जबकि Jenkins व्यक्तिगत चरणों के लिए स्क्रिप्ट बनाने की आवश्यकता को समाप्त नहीं करता, यह निर्माण, परीक्षण और तैनाती उपकरणों के पूरे अनुक्रम को एक साथ जोड़ने का एक तेज़ और अधिक मजबूत तरीका प्रदान करता है, जो कि मैन्युअल रूप से आसानी से बनाया जा सकता है।
बिना प्रमाणीकरण के दिलचस्प Jenkins पृष्ठों की खोज करने के लिए जैसे (/people या /asynchPeople, यह वर्तमान उपयोगकर्ताओं की सूची बनाता है) आप उपयोग कर सकते हैं:
जांचें कि क्या आप प्रमाणीकरण की आवश्यकता के बिना कमांड निष्पादित कर सकते हैं:
बिना क्रेडेंशियल्स के आप /asynchPeople/ पथ या /securityRealm/user/admin/search/index?q= में यूजरनेम देख सकते हैं।
आप /oops या /error पथ से Jenkins संस्करण प्राप्त कर सकते हैं।
बुनियादी जानकारी में आप Jenkins के अंदर लॉगिन करने के सभी तरीके देख सकते हैं:
आप उन Jenkins उदाहरणों को खोजने में सक्षम होंगे जो आपको एक खाता बनाने और इसके अंदर लॉगिन करने की अनुमति देते हैं। बस इतना ही।
यदि SSO कार्यात्मकता/प्लगइन्स मौजूद थे तो आपको एक परीक्षण खाते (जैसे, एक परीक्षण Github/Bitbucket खाता) का उपयोग करके एप्लिकेशन में लॉग-इन करने का प्रयास करना चाहिए। यहाँ से ट्रिक करें।
Jenkins में पासवर्ड नीति और यूजरनेम ब्रूट-फोर्स शमन की कमी है। यह ब्रूट-फोर्स उपयोगकर्ताओं के लिए आवश्यक है क्योंकि कमजोर पासवर्ड या यूजरनेम के रूप में पासवर्ड का उपयोग हो सकता है, यहां तक कि उल्टे यूजरनेम के रूप में पासवर्ड भी हो सकते हैं।
Use this python script or this powershell script.
कई संगठन SaaS-आधारित स्रोत नियंत्रण प्रबंधन (SCM) सिस्टम जैसे GitHub या GitLab को आंतरिक, स्वयं-होस्टेड CI समाधान जैसे Jenkins या TeamCity के साथ मिलाते हैं। यह सेटअप CI सिस्टम को SaaS स्रोत नियंत्रण विक्रेताओं से वेबहुक घटनाओं को प्राप्त करने की अनुमति देता है, मुख्य रूप से पाइपलाइन नौकरियों को ट्रिगर करने के लिए।
इसको प्राप्त करने के लिए, संगठन SCM प्लेटफार्मों के IP रेंज को व्हाइटलिस्ट करते हैं, जिससे उन्हें वेबहुक के माध्यम से आंतरिक CI सिस्टम तक पहुँचने की अनुमति मिलती है। हालाँकि, यह ध्यान रखना महत्वपूर्ण है कि कोई भी GitHub या GitLab पर खाता बना सकता है और इसे वेबहुक को ट्रिगर करने के लिए कॉन्फ़िगर कर सकता है, संभावित रूप से आंतरिक CI सिस्टम को अनुरोध भेज सकता है।
इन परिदृश्यों में हम मान लेंगे कि आपके पास Jenkins तक पहुँचने के लिए एक वैध खाता है।
Jenkins में कॉन्फ़िगर की गई Authorization तंत्र और समझौता किए गए उपयोगकर्ता की अनुमति के आधार पर, आप निम्नलिखित हमलों को करने में सक्षम हो सकते हैं या नहीं।
For more information check the basic information:
यदि आपने Jenkins तक पहुँच प्राप्त कर ली है, तो आप http://127.0.0.1:8080/asynchPeople/ में अन्य पंजीकृत उपयोगकर्ताओं की सूची देख सकते हैं।
Use this script to dump build console outputs and build environment variables to hopefully find cleartext secrets.
यदि समझौता किया गया उपयोगकर्ता एक नया Jenkins नोड बनाने/संशोधित करने के लिए पर्याप्त विशेषाधिकार रखता है और SSH क्रेडेंशियल पहले से अन्य नोड्स तक पहुँचने के लिए संग्रहीत हैं, तो वह उन क्रेडेंशियल्स को चुरा सकता है एक नोड बनाकर/संशोधित करके और एक होस्ट सेट करके जो क्रेडेंशियल्स को रिकॉर्ड करेगा बिना होस्ट कुंजी की पुष्टि किए:
आप आमतौर पर Jenkins ssh क्रेडेंशियल्स को वैश्विक प्रदाता (/credentials/
) में पाएंगे, इसलिए आप उन्हें किसी अन्य रहस्य की तरह डंप भी कर सकते हैं। अधिक जानकारी के लिए रहस्यों को डंप करने के अनुभाग में देखें।
Jenkins सर्वर में शेल प्राप्त करना हमलावर को सभी रहस्यों और env वेरिएबल्स को लीक करने और एक ही नेटवर्क में स्थित अन्य मशीनों का शोषण करने का अवसर देता है या यहां तक कि क्लाउड क्रेडेंशियल्स इकट्ठा करने का भी।
डिफ़ॉल्ट रूप से, Jenkins SYSTEM के रूप में चलेगा। इसलिए, इसे समझौता करने से हमलावर को SYSTEM विशेषाधिकार मिलेंगे।
प्रोजेक्ट बनाना/संशोधित करना Jenkins सर्वर पर RCE प्राप्त करने का एक तरीका है:
आप एक Groovy स्क्रिप्ट निष्पादित करके भी RCE प्राप्त कर सकते हैं, जो एक नया प्रोजेक्ट बनाने की तुलना में अधिक छिपा हुआ हो सकता है:
आप पाइपलाइन बनाकर/संशोधित करके भी RCE प्राप्त कर सकते हैं:
पाइपलाइनों का शोषण करने के लिए आपको अभी भी Jenkins तक पहुँच प्राप्त करनी होगी।
पाइपलाइन्स को प्रोजेक्ट्स में बिल्ड तंत्र के रूप में भी उपयोग किया जा सकता है, इस मामले में इसे रेपोजिटरी के अंदर एक फ़ाइल के रूप में कॉन्फ़िगर किया जा सकता है जो पाइपलाइन सिंटैक्स को शामिल करेगा। डिफ़ॉल्ट रूप से /Jenkinsfile
का उपयोग किया जाता है:
यह भी संभव है कि पाइपलाइन कॉन्फ़िगरेशन फ़ाइलों को अन्य स्थानों पर संग्रहीत किया जाए (उदाहरण के लिए अन्य रेपोजिटरी में) जिसका लक्ष्य रेपोजिटरी की पहुँच और पाइपलाइन पहुँच को अलग करना है।
यदि एक हमलावर के पास उस फ़ाइल पर लिखने की पहुँच है तो वह इसे संशोधित कर सकेगा और संभावित रूप से ट्रिगर कर सकेगा पाइपलाइन को बिना Jenkins तक पहुँच के। संभव है कि हमलावर को कुछ शाखा सुरक्षा को बायपास करना पड़े (प्लेटफ़ॉर्म और उपयोगकर्ता विशेषाधिकार के आधार पर, उन्हें बायपास किया जा सकता है या नहीं)।
कस्टम पाइपलाइन को निष्पादित करने के लिए सबसे सामान्य ट्रिगर्स हैं:
मुख्य शाखा पर पुल अनुरोध (या संभावित रूप से अन्य शाखाओं पर)
मुख्य शाखा पर पुश (या संभावित रूप से अन्य शाखाओं पर)
मुख्य शाखा को अपडेट करें और प्रतीक्षा करें जब तक कि इसे किसी तरह निष्पादित नहीं किया जाता
यदि आप एक बाहरी उपयोगकर्ता हैं तो आपको अन्य उपयोगकर्ता/संस्थान के रेपोजिटरी के मुख्य शाखा पर PR बनाने और पाइपलाइन को ट्रिगर करने की उम्मीद नहीं करनी चाहिए... लेकिन यदि यह खराब कॉन्फ़िगर किया गया है तो आप पूरी तरह से कंपनियों को केवल इसका शोषण करके समझौता कर सकते हैं।
पिछले RCE अनुभाग में पहले से ही एक तकनीक का संकेत दिया गया था पाइपलाइन को संशोधित करके RCE प्राप्त करने के लिए।
यह संभव है कि पूरी पाइपलाइन या विशिष्ट चरणों के लिए स्पष्ट पाठ env वेरिएबल्स घोषित किए जाएं। ये env वेरिएबल्स संवेदनशील जानकारी नहीं होनी चाहिए, लेकिन एक हमलावर हमेशा सभी पाइपलाइन कॉन्फ़िगरेशन/Jenkinsfiles की जाँच कर सकता है:
Jenkins द्वारा सामान्यतः रहस्यों के साथ कैसे व्यवहार किया जाता है, इसके बारे में जानकारी के लिए बुनियादी जानकारी देखें:
क्रेडेंशियल्स को वैश्विक प्रदाताओं (/credentials/
) या विशिष्ट परियोजनाओं (/job/<project-name>/configure
) के लिए स्कोप किया जा सकता है। इसलिए, सभी को निकालने के लिए आपको कम से कम सभी परियोजनाओं से समझौता करना होगा जो रहस्यों को शामिल करती हैं और कस्टम/जहरीले पाइपलाइनों को निष्पादित करना होगा।
एक और समस्या है, पाइपलाइन के env के अंदर एक रहस्य प्राप्त करने के लिए आपको रहस्य का नाम और प्रकार जानना होगा। उदाहरण के लिए, यदि आप एक usernamePassword
रहस्य को string
रहस्य के रूप में लोड करने की कोशिश करते हैं, तो आपको यह त्रुटि मिलेगी:
यहाँ कुछ सामान्य गुप्त प्रकारों को लोड करने का तरीका है:
इस पृष्ठ के अंत में आप सभी क्रेडेंशियल प्रकार पा सकते हैं: https://www.jenkins.io/doc/pipeline/steps/credentials-binding/
सभी रहस्यों को एक साथ डंप करने का सबसे अच्छा तरीका है Jenkins मशीन को समझौता करना (उदाहरण के लिए बिल्ट-इन नोड में एक रिवर्स शेल चलाना) और फिर मास्टर कीज़ और एन्क्रिप्टेड रहस्यों को लीक करना और उन्हें ऑफ़लाइन डिक्रिप्ट करना। इस बारे में अधिक जानकारी Nodes & Agents section और Post Exploitation section में है।
दस्तावेज़ों से: triggers
निर्देश स्वचालित तरीकों को परिभाषित करता है जिनमें पाइपलाइन को फिर से ट्रिगर किया जाना चाहिए। उन पाइपलाइनों के लिए जो GitHub या BitBucket जैसे स्रोत के साथ एकीकृत हैं, triggers
आवश्यक नहीं हो सकते हैं क्योंकि वेबहुक-आधारित एकीकरण पहले से मौजूद हो सकता है। वर्तमान में उपलब्ध ट्रिगर्स हैं cron
, pollSCM
और upstream
।
क्रोन उदाहरण:
Check other examples in the docs.
A Jenkins instance might have different agents running in different machines. From an attacker perspective, access to different machines means different potential cloud credentials to steal or different network access that could be abuse to exploit other machines.
For more information check the basic information:
You can enumerate the configured nodes in /computer/
, you will usually find the Built-In Node
(which is the node running Jenkins) and potentially more:
It is विशेष रूप से दिलचस्प Built-In node को समझौता करना क्योंकि इसमें संवेदनशील Jenkins जानकारी होती है।
To indicate you want to run the pipeline in the built-in Jenkins node you can specify inside the pipeline the following config:
एक विशेष एजेंट में पाइपलाइन, एक क्रोन ट्रिगर के साथ, पाइपलाइन और स्टेज पर्यावरण चर के साथ, एक चरण में 2 चर लोड करना और एक रिवर्स शेल भेजना:
आप /credentials/
को एक्सेस करके रहस्यों की सूची बना सकते हैं यदि आपके पास पर्याप्त अनुमतियाँ हैं। ध्यान दें कि यह केवल credentials.xml
फ़ाइल के अंदर के रहस्यों की सूची बनाएगा, लेकिन बिल्ड कॉन्फ़िगरेशन फ़ाइलों में भी अधिक क्रेडेंशियल्स हो सकते हैं।
यदि आप प्रत्येक प्रोजेक्ट की कॉन्फ़िगरेशन देख सकते हैं, तो आप वहाँ क्रेडेंशियल्स (रहस्यों) के नाम भी देख सकते हैं जो रिपॉजिटरी और प्रोजेक्ट के अन्य क्रेडेंशियल्स तक पहुँचने के लिए उपयोग किए जा रहे हैं।
इन फ़ाइलों की आवश्यकता है Jenkins रहस्यों को डिक्रिप्ट करने के लिए:
secrets/master.key
secrets/hudson.util.Secret
ऐसे रहस्य आमतौर पर मिल सकते हैं:
credentials.xml
jobs/.../build.xml
jobs/.../config.xml
यहाँ उन्हें खोजने के लिए एक regex है:
यदि आपने रहस्यों को डिक्रिप्ट करने के लिए आवश्यक पासवर्ड्स को डंप किया है, तो उन रहस्यों को डिक्रिप्ट करने के लिए यह स्क्रिप्ट का उपयोग करें।
/var/lib/jenkins/config.xml
या C:\Program Files (x86)\Jenkis\
में Jenkins config.xml फ़ाइल तक पहुँचें।
<useSecurity>true</useSecurity>
शब्द के लिए खोजें और शब्द true
को false
में बदलें।
sed -i -e 's/<useSecurity>true</<useSecurity>false</g' config.xml
Jenkins सर्वर को पुनः प्रारंभ करें: service jenkins restart
अब फिर से Jenkins पोर्टल पर जाएं और इस बार Jenkins कोई प्रमाण पत्र नहीं मांगेगा। आप प्रशासक पासवर्ड फिर से सेट करने के लिए "Manage Jenkins" पर नेविगेट करें।
सेटिंग्स को <useSecurity>true</useSecurity>
में बदलकर सुरक्षा को फिर से सक्षम करें और Jenkins को फिर से पुनः प्रारंभ करें।
AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE) GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE)