बुनियादी Jenkins जानकारी

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 का समर्थन करें

पहुँच

उपयोगकर्ता नाम + पासवर्ड

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

कुकी

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

SSO/Plugins

Jenkins को plugins के माध्यम से इस तरह कॉन्फ़िगर किया जा सकता है कि यह थर्ड-पार्टी SSO के माध्यम से पहुँच योग्य हो।

Tokens

उपयोगकर्ता टोकन जेनरेट कर सकते हैं ताकि एप्लिकेशन CLI या REST API के माध्यम से उनका प्रतिरूपण (impersonate) कर सकें।

SSH Keys

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

अधिकार

/configureSecurity पर Jenkins के authorization method को कॉन्फ़िगर करना संभव है। विकल्प कुछ इस प्रकार हैं:

  • कोई भी कुछ भी कर सकता है: यहाँ तक कि अनाम उपयोगकर्ता भी सर्वर का प्रशासन कर सकते हैं।
  • 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’ जो सभी प्रमाणित उपयोगकर्ताओं का प्रतिनिधित्व करता है।

  • Project-based Matrix Authorization Strategy: यह मोड “Matrix-based security” का एक विस्तार है जो प्रत्येक प्रोजेक्ट के लिए अलग से अतिरिक्त ACL मैट्रिक्स को परिभाषित करने की अनुमति देता है।
  • Role-Based Strategy: भूमिकाओं-आधारित रणनीति का उपयोग करके अनुमतियों को परिभाषित करने में सक्षम बनाता है। भूमिकाओं को /role-strategy में प्रबंधित करें।

Security Realm

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

  • Delegate to servlet container: Jenkins controller पर चलने वाले servlet container (जैसे 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 समूहों के पुन:उपयोग की भी अनुमति देता है।

Plugins अतिरिक्त security realms प्रदान कर सकते हैं जो मौजूदा identity systems में Jenkins को शामिल करने के लिए उपयोगी हो सकते हैं, जैसे:

Jenkins Nodes, Agents & Executors

Definitions from the docs:

Nodes वे मशीनें हैं जिन पर build agents चलते हैं। Jenkins प्रत्येक जुड़े हुए node की disk space, free temp space, free swap, clock time/sync और response time की निगरानी करता है। यदि इन मानों में से कोई भी configured threshold के बाहर चला जाता है तो node को offline कर दिया जाता है।

Agents Jenkins controller की ओर से executors का उपयोग करके टास्क निष्पादन (task execution) को प्रबंधित करते हैं। एक agent किसी भी ऑपरेटिंग सिस्टम का उपयोग कर सकता है जो Java को सपोर्ट करता हो। बिल्ड और टेस्ट के लिए आवश्यक टूल उस node पर इंस्टॉल होते हैं जहाँ agent चलता है; इन्हें सीधे इंस्टॉल किया जा सकता है या एक container (Docker या Kubernetes) में रखा जा सकता है। प्रत्येक agent प्रभावी रूप से host मशीन पर अपने PID के साथ एक प्रोसेस होता है।

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

Jenkins Secrets

Secrets और Credentials का एनक्रिप्शन

Definition from the docs: 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 API के माध्यम से या credentials API के माध्यम से। क्रिप्टोमें रुचि रखने वालों के लिए, Jenkins AES का उपयोग cipher block chaining (CBC) mode में PKCS#5 padding और random IVs के साथ करता है ताकि CryptoConfidentialKey के उदाहरणों को encrypt किया जा सके, जो $JENKINS_HOME/secrets/ में उनके CryptoConfidentialKey id के अनुरूप फ़ाइल नाम के साथ संग्रहीत होते हैं। सामान्य key ids में शामिल हैं:

  • hudson.util.Secret: generic secrets के लिए उपयोग होता है;
  • com.cloudbees.plugins.credentials.SecretBytes.KEY: कुछ credentials प्रकारों के लिए उपयोग होता है;
  • jenkins.model.Jenkins.crumbSalt: CSRF protection mechanism द्वारा उपयोग किया जाता है; और

Credentials पहुँच

Credentials को global providers (/credentials/) के लिए scoped किया जा सकता है जिन्हें किसी भी कॉन्फ़िगर किए गए प्रोजेक्ट द्वारा एक्सेस किया जा सकता है, या इन्हें specific projects (/job/<project-name>/configure) के लिए scoped किया जा सकता है और इसलिए केवल उस विशिष्ट प्रोजेक्ट से ही पहुँचनीय होते हैं।

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

इसीलिए क्रेडेंशियल्स को exfiltrate करने के लिए उदाहरण के तौर पर a attacker को उन्हें base64 करना होगा।

डिस्क पर 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 टैग्स के लिए खोजें।

# 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" {} \\;

संदर्भ

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 का समर्थन करें