Basic Jenkins Information
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 में लॉगिन करने का सबसे सामान्य तरीका एक उपयोगकर्ता नाम या पासवर्ड है।
यदि एक अधिकृत कुकी चुराई जाती है, तो इसका उपयोग उपयोगकर्ता के सत्र तक पहुँचने के लिए किया जा सकता है। कुकी को आमतौर पर JSESSIONID.* कहा जाता है। (एक उपयोगकर्ता अपने सभी सत्रों को समाप्त कर सकता है, लेकिन उसे पहले यह पता लगाना होगा कि एक कुकी चुराई गई थी)।
Jenkins को प्लगइन्स का उपयोग करके तीसरे पक्ष के SSO के माध्यम से पहुँच योग्य बनाने के लिए कॉन्फ़िगर किया जा सकता है।
उपयोगकर्ता टोकन उत्पन्न कर सकते हैं ताकि CLI या REST API के माध्यम से उनके रूप में अनुप्रयोगों को पहुँच प्रदान की जा सके।
यह घटक Jenkins के लिए एक अंतर्निहित SSH सर्वर प्रदान करता है। यह Jenkins CLI के लिए एक वैकल्पिक इंटरफ़ेस है, और किसी भी SSH क्लाइंट का उपयोग करके इस तरह से कमांड को लागू किया जा सकता है। (From the docs)
/configureSecurity में यह संभव है कि Jenkins के प्राधिकरण विधि को कॉन्फ़िगर करें। कई विकल्प हैं:
कोई भी कुछ भी कर सकता है: यहां तक कि गुमनाम पहुँच भी सर्वर का प्रशासन कर सकती है।
Legacy mode: Jenkins <1.164 के समान। यदि आपके पास "admin" भूमिका है, तो आपको सिस्टम पर पूर्ण नियंत्रण दिया जाएगा, और अन्यथा (गुमनाम उपयोगकर्ताओं सहित) आपको पढ़ने की पहुँच मिलेगी।
लॉग इन किए गए उपयोगकर्ता कुछ भी कर सकते हैं: इस मोड में, हर लॉग इन किया गया उपयोगकर्ता Jenkins का पूर्ण नियंत्रण प्राप्त करता है। एकमात्र उपयोगकर्ता जिसे पूर्ण नियंत्रण नहीं मिलेगा वह गुमनाम उपयोगकर्ता है, जिसे केवल पढ़ने की पहुँच मिलती है।
Matrix-based security: आप एक तालिका में कौन क्या कर सकता है कॉन्फ़िगर कर सकते हैं। प्रत्येक स्तंभ एक अनुमति का प्रतिनिधित्व करता है। प्रत्येक पंक्ति एक उपयोगकर्ता या समूह/भूमिका का प्रतिनिधित्व करती है। इसमें एक विशेष उपयोगकर्ता 'गुमनाम' शामिल है, जो अप्रमाणित उपयोगकर्ताओं का प्रतिनिधित्व करता है, साथ ही 'प्रमाणित', जो सभी प्रमाणित उपयोगकर्ताओं का प्रतिनिधित्व करता है।
Project-based Matrix Authorization Strategy: यह मोड "Matrix-based security" का एक विस्तार है जो प्रत्येक परियोजना के लिए अतिरिक्त ACL मैट्रिक्स को अलग से परिभाषित करने की अनुमति देता है।
Role-Based Strategy: भूमिका-आधारित रणनीति का उपयोग करके प्राधिकरण को परिभाषित करने की अनुमति देता है। /role-strategy में भूमिकाओं का प्रबंधन करें।
/configureSecurity में यह संभव है कि सुरक्षा क्षेत्र को कॉन्फ़िगर करें। डिफ़ॉल्ट रूप से Jenkins कुछ विभिन्न सुरक्षा क्षेत्रों के लिए समर्थन शामिल करता है:
Delegate to servlet container: Jenkins नियंत्रक को चलाने वाले एक सर्वलेट कंटेनर के लिए प्रमाणीकरण को सौंपने के लिए, जैसे Jetty।
Jenkins’ own user database: प्रमाणीकरण के लिए Jenkins के अपने अंतर्निहित उपयोगकर्ता डेटा स्टोर का उपयोग करें, बजाय इसके कि एक बाहरी प्रणाली को सौंपें। यह डिफ़ॉल्ट रूप से सक्षम है।
LDAP: एक कॉन्फ़िगर किए गए LDAP सर्वर को सभी प्रमाणीकरण सौंपें, जिसमें उपयोगकर्ता और समूह दोनों शामिल हैं।
Unix user/group database: Jenkins नियंत्रक पर अंतर्निहित Unix OS-स्तरीय उपयोगकर्ता डेटाबेस को प्रमाणीकरण सौंपता है। यह मोड प्राधिकरण के लिए Unix समूहों के पुन: उपयोग की अनुमति भी देगा।
प्लगइन्स अतिरिक्त सुरक्षा क्षेत्रों को प्रदान कर सकते हैं जो Jenkins को मौजूदा पहचान प्रणालियों में शामिल करने के लिए उपयोगी हो सकते हैं, जैसे:
docs से परिभाषाएँ:
Nodes वे मशीनें हैं जिन पर निर्माण एजेंट चलते हैं। Jenkins प्रत्येक जुड़े हुए नोड की निगरानी करता है कि डिस्क स्थान, फ्री टेम्प स्पेस, फ्री स्वैप, घड़ी का समय/सिंक और प्रतिक्रिया समय। यदि इनमें से कोई भी मान कॉन्फ़िगर किए गए थ्रेशोल्ड से बाहर चला जाता है, तो एक नोड को ऑफ़लाइन ले लिया जाता है।
Agents Jenkins नियंत्रक की ओर से कार्य निष्पादन का प्रबंधन करते हैं executors का उपयोग करके। एक एजेंट किसी भी ऑपरेटिंग सिस्टम का उपयोग कर सकता है जो Java का समर्थन करता है। निर्माण और परीक्षण के लिए आवश्यक उपकरण उस नोड पर स्थापित होते हैं जहां एजेंट चलता है; उन्हें प्रत्यक्ष रूप से या एक कंटेनर में (Docker या Kubernetes) स्थापित किया जा सकता है। प्रत्येक एजेंट वास्तव में मेज़बान मशीन पर अपने स्वयं के PID के साथ एक प्रक्रिया है।
एक executor कार्य निष्पादन के लिए एक स्लॉट है; वास्तव में, यह एजेंट में एक थ्रेड है। एक नोड पर executors की संख्या उस नोड पर एक समय में निष्पादित होने वाले समानांतर कार्यों की संख्या को परिभाषित करती है। दूसरे शब्दों में, यह उस नोड पर एक समय में निष्पादित होने वाले समानांतर Pipeline stages की संख्या को निर्धारित करता है।
docs से परिभाषा: Jenkins गुप्त, क्रेडेंशियल्स और उनके संबंधित एन्क्रिप्शन कुंजियों को एन्क्रिप्ट और सुरक्षित करने के लिए AES का उपयोग करता है। ये एन्क्रिप्शन कुंजियाँ $JENKINS_HOME/secrets/ में संग्रहीत होती हैं, साथ ही मास्टर कुंजी जो इन कुंजियों की सुरक्षा के लिए उपयोग की जाती है। इस निर्देशिका को इस तरह कॉन्फ़िगर किया जाना चाहिए कि केवल ऑपरेटिंग सिस्टम उपयोगकर्ता जिसके रूप में Jenkins नियंत्रक चल रहा है, को इस निर्देशिका में पढ़ने और लिखने की पहुँच हो (यानी, chmod मान 0700 या उपयुक्त फ़ाइल विशेषताओं का उपयोग करके)। मास्टर कुंजी (जिसे कभी-कभी क्रिप्टोजार्गन में "कुंजी एन्क्रिप्शन कुंजी" कहा जाता है) Jenkins नियंत्रक फ़ाइल सिस्टम में _अनएन्क्रिप्टेड_ में $JENKINS_HOME/secrets/master.key में संग्रहीत होती है, जो उन हमलावरों के खिलाफ सुरक्षा नहीं करती है जिनके पास उस फ़ाइल तक सीधा पहुँच है। अधिकांश उपयोगकर्ता और डेवलपर्स इन एन्क्रिप्शन कुंजियों का अप्रत्यक्ष रूप से उपयोग करेंगे या तो Secret API के माध्यम से सामान्य गुप्त डेटा को एन्क्रिप्ट करने के लिए या क्रेडेंशियल्स API के माध्यम से। क्रिप्टोक्यूरियस के लिए, Jenkins AES का उपयोग करता है जो सिफर ब्लॉक चेनिंग (CBC) मोड में PKCS#5 पैडिंग और यादृच्छिक IVs के साथ CryptoConfidentialKey के उदाहरणों को एन्क्रिप्ट करने के लिए उपयोग किया जाता है जो $JENKINS_HOME/secrets/ में संग्रहीत होते हैं जिनका फ़ाइल नाम उनके CryptoConfidentialKey आईडी के अनुरूप होता है। सामान्य कुंजी आईडी में शामिल हैं:
hudson.util.Secret: सामान्य गुप्तों के लिए उपयोग किया जाता है;
com.cloudbees.plugins.credentials.SecretBytes.KEY: कुछ क्रेडेंशियल प्रकारों के लिए उपयोग किया जाता है;
jenkins.model.Jenkins.crumbSalt: CSRF सुरक्षा तंत्र द्वारा उपयोग किया जाता है; और
क्रेडेंशियल्स को वैश्विक प्रदाताओं (/credentials/) के लिए स्कोप किया जा सकता है जिन्हें किसी भी कॉन्फ़िगर की गई परियोजना द्वारा पहुँचा जा सकता है, या उन्हें विशिष्ट परियोजनाओं (/job/<project-name>/configure) के लिए स्कोप किया जा सकता है और इसलिए केवल विशिष्ट परियोजना से पहुँचा जा सकता है।
the docs के अनुसार: स्कोप में क्रेडेंशियल्स पाइपलाइन के लिए बिना किसी सीमा के उपलब्ध होते हैं। निर्माण लॉग में आकस्मिक प्रदर्शन को रोकने के लिए, क्रेडेंशियल्स को नियमित आउटपुट से मास्क किया जाता है, इसलिए env (Linux) या set (Windows) का एक आह्वान, या अपने वातावरण या पैरामीटर को प्रिंट करने वाले कार्यक्रम निर्माण लॉग में उन्हें प्रकट नहीं करेंगे उन उपयोगकर्ताओं के लिए जिनके पास अन्यथा क्रेडेंशियल्स तक पहुँच नहीं होगी।
इसलिए क्रेडेंशियल्स को एक्सफिल्ट्रेट करने के लिए एक हमलावर को, उदाहरण के लिए, उन्हें base64 करना होगा।
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
