Basic Jenkins Information

Reading time: 8 minutes

tip

AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE) Azure हैकिंग सीखें और अभ्यास करें: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks का समर्थन करें

Access

Username + Password

Jenkins में लॉगिन करने का सबसे सामान्य तरीका एक उपयोगकर्ता नाम या पासवर्ड के साथ है।

यदि एक अधिकृत कुकी चुराई जाती है, तो इसका उपयोग उपयोगकर्ता के सत्र तक पहुँचने के लिए किया जा सकता है। कुकी को आमतौर पर JSESSIONID.* कहा जाता है। (एक उपयोगकर्ता अपने सभी सत्रों को समाप्त कर सकता है, लेकिन उसे पहले यह पता लगाना होगा कि एक कुकी चुराई गई थी)।

SSO/Plugins

Jenkins को तीसरे पक्ष के SSO के माध्यम से पहुँच योग्य बनाने के लिए प्लगइन्स का उपयोग करके कॉन्फ़िगर किया जा सकता है।

Tokens

उपयोगकर्ता टोकन उत्पन्न कर सकते हैं ताकि CLI या REST API के माध्यम से उनके रूप में अनुप्रयोगों को पहुँच दी जा सके।

SSH Keys

यह घटक Jenkins के लिए एक अंतर्निहित SSH सर्वर प्रदान करता है। यह Jenkins CLI के लिए एक वैकल्पिक इंटरफ़ेस है, और किसी भी SSH क्लाइंट का उपयोग करके इस तरह से कमांड को लागू किया जा सकता है। (From the docs)

Authorization

/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 में भूमिकाओं का प्रबंधन करें।

Security Realm

/configureSecurity में यह संभव है कि सुरक्षा क्षेत्र को कॉन्फ़िगर किया जाए। डिफ़ॉल्ट रूप से Jenkins में कुछ विभिन्न सुरक्षा क्षेत्रों के लिए समर्थन शामिल है:

  • Delegate to servlet container: Jenkins नियंत्रक चलाने वाले एक सर्वलेट कंटेनर के लिए प्रमाणीकरण को सौंपना, जैसे Jetty।
  • Jenkins’ own user database: बाहरी प्रणाली को सौंपने के बजाय प्रमाणीकरण के लिए Jenkins के अपने अंतर्निहित उपयोगकर्ता डेटा स्टोर का उपयोग करें। यह डिफ़ॉल्ट रूप से सक्षम है।
  • LDAP: एक कॉन्फ़िगर किए गए LDAP सर्वर को सभी प्रमाणीकरण सौंपें, जिसमें उपयोगकर्ता और समूह दोनों शामिल हैं।
  • Unix user/group database: Jenkins नियंत्रक पर अंतर्निहित Unix OS-स्तरीय उपयोगकर्ता डेटाबेस को प्रमाणीकरण सौंपता है। यह मोड प्राधिकरण के लिए Unix समूहों के पुन: उपयोग की अनुमति भी देगा।

प्लगइन्स अतिरिक्त सुरक्षा क्षेत्रों को प्रदान कर सकते हैं जो Jenkins को मौजूदा पहचान प्रणालियों में शामिल करने के लिए उपयोगी हो सकते हैं, जैसे:

Jenkins Nodes, Agents & Executors

docs से परिभाषाएँ:

Nodes वे मशीनें हैं जिन पर निर्माण एजेंट चलते हैं। Jenkins प्रत्येक जुड़े हुए नोड की निगरानी करता है कि डिस्क स्थान, फ्री टेम्प स्पेस, फ्री स्वैप, घड़ी का समय/सिंक और प्रतिक्रिया समय। यदि इनमें से कोई भी मान कॉन्फ़िगर किए गए थ्रेशोल्ड से बाहर चला जाता है, तो एक नोड को ऑफ़लाइन ले लिया जाता है।

Agents Jenkins नियंत्रक की ओर से कार्य निष्पादन का प्रबंधन करते हैं executors का उपयोग करके। एक एजेंट किसी भी ऑपरेटिंग सिस्टम का उपयोग कर सकता है जो Java का समर्थन करता है। निर्माण और परीक्षण के लिए आवश्यक उपकरण उस नोड पर स्थापित होते हैं जहां एजेंट चलता है; उन्हें प्रत्यक्ष रूप से या एक कंटेनर में (Docker या Kubernetes) स्थापित किया जा सकता है। प्रत्येक एजेंट वास्तव में मेज़बान मशीन पर अपने स्वयं के PID के साथ एक प्रक्रिया है।

एक executor कार्य निष्पादन के लिए एक स्लॉट है; वास्तव में, यह एजेंट में एक थ्रेड है। एक नोड पर executors की संख्या उस नोड पर एक समय में निष्पादित होने वाले समानांतर कार्यों की संख्या को परिभाषित करती है। दूसरे शब्दों में, यह उस नोड पर एक समय में निष्पादित होने वाले समानांतर Pipeline stages की संख्या को निर्धारित करता है।

Jenkins Secrets

Encryption of Secrets and Credentials

docs से परिभाषा: Jenkins गुप्त, क्रेडेंशियल्स और उनके संबंधित एन्क्रिप्शन कुंजियों को एन्क्रिप्ट और सुरक्षित करने के लिए AES का उपयोग करता है। ये एन्क्रिप्शन कुंजियाँ $JENKINS_HOME/secrets/ में संग्रहीत होती हैं, साथ ही उस मास्टर कुंजी के साथ जो उक्त कुंजियों की सुरक्षा के लिए उपयोग की जाती है। इस निर्देशिका को इस तरह कॉन्फ़िगर किया जाना चाहिए कि केवल ऑपरेटिंग सिस्टम उपयोगकर्ता जिसके रूप में Jenkins नियंत्रक चल रहा है, को इस निर्देशिका में पढ़ने और लिखने की पहुँच हो (यानी, chmod मान 0700 या उपयुक्त फ़ाइल विशेषताओं का उपयोग करके)। मास्टर कुंजी (जिसे कभी-कभी क्रिप्टोजार्गन में "कुंजी एन्क्रिप्शन कुंजी" कहा जाता है) Jenkins नियंत्रक फ़ाइल सिस्टम में _unencrypted_ में $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 Access

क्रेडेंशियल्स को वैश्विक प्रदाताओं (/credentials/) के लिए स्कोप किया जा सकता है जिन्हें किसी भी कॉन्फ़िगर की गई परियोजना द्वारा एक्सेस किया जा सकता है, या उन्हें विशिष्ट परियोजनाओं (/job/<project-name>/configure) के लिए स्कोप किया जा सकता है और इसलिए केवल विशिष्ट परियोजना से ही एक्सेस किया जा सकता है।

docs के अनुसार: स्कोप में क्रेडेंशियल्स पाइपलाइन के लिए बिना किसी सीमा के उपलब्ध होते हैं। निर्माण लॉग में आकस्मिक प्रदर्शन को रोकने के लिए, क्रेडेंशियल्स को नियमित आउटपुट से मास्क किया जाता है, इसलिए env (Linux) या set (Windows) का एक आह्वान, या अपने वातावरण या पैरामीटर को प्रिंट करने वाले कार्यक्रमों को निर्माण लॉग में उन्हें प्रकट नहीं करेगा उन उपयोगकर्ताओं के लिए जिनके पास अन्यथा क्रेडेंशियल्स तक पहुँच नहीं होगी।

इसलिए क्रेडेंशियल्स को एक्सफिल्ट्रेट करने के लिए एक हमलावर को, उदाहरण के लिए, उन्हें base64 करना होगा।

References

tip

AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE) Azure हैकिंग सीखें और अभ्यास करें: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks का समर्थन करें