Taarifa za Msingi za Jenkins

Tip

Jifunze na fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Jifunze na fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Jifunze na fanya mazoezi ya Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks

Ufikiaji

Jina la Mtumiaji + Nenosiri

Njia inayotumika zaidi kuingia kwenye Jenkins ni kwa kutumia jina la mtumiaji au nenosiri.

Ikiwa cookie yenye idhini imeibiwa, inaweza kutumika kufikia kikao cha mtumiaji. Cookie kawaida huitwa JSESSIONID.*. (Mtumiaji anaweza kumaliza vikao vyake vyote, lakini atahitaji kwanza kugundua kuwa cookie imeibiwa).

SSO/Plugins

Jenkins inaweza kusanidiwa kwa kutumia plugins ili iweze kupatikana kupitia SSO ya mtu wa tatu.

Tokens

Watumiaji wanaweza kutengeneza tokens kuwapa applications uwezo wa kuwatumia (impersonate) kupitia CLI au REST API.

SSH Keys

Kipengele hiki kinatoa server ya SSH iliyojengewa ndani kwa Jenkins. Ni kiolesura mbadala kwa Jenkins CLI, na amri zinaweza kuitwa kwa njia hii kwa kutumia mteja yeyote wa SSH. (Kutoka kwa docs)

Authorization

Katika /configureSecurity inawezekana kusanidi njia ya authorization ya Jenkins. Kuna chaguzi mbalimbali:

  • Anyone can do anything: Hata ufikiaji wa anonymous unaweza kusimamia server.
  • Legacy mode: Kama ilivyokuwa kwenye Jenkins <1.164. Ikiwa una “admin” role, utapewa full control juu ya mfumo, na vinginevyo (ikijumuisha watumiaji anonymous) utapata tu ufikiaji wa read.
  • Logged-in users can do anything: Katika mode hii, kila mtumiaji aliyesajiliwa ana full control ya Jenkins. Mtumiaji pekee ambaye hatakuwa na full control ni anonymous user, ambaye anapata tu read access.
  • Matrix-based security: Unaweza kusanidi nani anaweza kufanya nini katika jedwali. Kila column inawakilisha permission. Kila row inawakilisha user au group/role. Hii ni pamoja na mtumiaji maalum ‘anonymous’, unaowakilisha watumiaji wasioidhinishwa, pamoja na ‘authenticated’, unaowakilisha watumiaji wote waliothibitishwa.

  • Project-based Matrix Authorization Strategy: Mode hii ni ongezeko la “Matrix-based security” ambalo linaruhusu ACL matrix za ziada kufafanuliwa kwa kila project kwa njia tofauti.
  • Role-Based Strategy: Inaruhusu ufafanuzi wa authorizations kwa kutumia role-based strategy. Simamia roles katika /role-strategy.

Security Realm

Katika /configureSecurity inawezekana kusanidi security realm. Kwa default Jenkins ina msaada kwa Security Realms kadhaa tofauti:

  • Delegate to servlet container: Kwa kutoa authentication kwa servlet container inayotumia Jenkins controller, kama Jetty.
  • Jenkins’ own user database: Tumia hifadhi ya data ya watumiaji ya ndani ya Jenkins kwa authentication badala ya kuirudisha kwa mfumo wa nje. Hii imewezeshwa kwa default.
  • LDAP: Rudisha authentication yote kwa server ya LDAP iliyosanidiwa, ikijumuisha watumiaji na makundi.
  • Unix user/group database: Inarudisha authentication kwa hifadhi ya watumiaji ya mfumo wa Unix kwenye controller ya Jenkins. Mode hii pia itaruhusu kutumia tena makundi ya Unix kwa ajili ya authorization.

Plugins zinaweza kutoa security realms za ziada ambazo zinaweza kuwa muhimu kwa kuingiza Jenkins katika mifumo ya utambulisho iliyopo, kama:

Jenkins Nodes, Agents & Executors

Definitions kutoka kwa docs:

Nodes ni mashine ambazo ambapo agents za build zinaendesha. Jenkins inafuatilia kila node iliyounganishwa kwa nafasi ya disk, nafasi ya temp bure, swap bure, saa/synchronization na wakati wa majibu. Node inachukuliwa offline ikiwa yoyote ya thamani hizi inapita kigezo kilichosanidiwa.

Agents huendesha utekelezaji wa kazi kwa niaba ya Jenkins controller kwa kutumia executors. Agent inaweza kutumia mfumo wowote wa uendeshaji unaounga mkono Java. Zana zinazohitajika kwa builds na tests zinasakinishwa kwenye node ambapo agent inakimbia; zinaweza kusakinishwa moja kwa moja au ndani ya container (Docker au Kubernetes). Kila agent kwa ujumla ni mchakato mwenye PID yake mwenyewe kwenye mashine mwenyeji.

Executor ni slot kwa uendeshaji wa kazi; kwa vitendo, ni thread ndani ya agent. Idadi ya executors kwenye node inaamua idadi ya kazi zinazoendeshwa sambamba ambazo zinaweza kutekelezwa kwenye node hiyo kwa wakati mmoja. Kwa maneno mengine, hii inabainisha idadi ya stages za Pipeline zinazoweza kuendeshwa kwa wakati mmoja kwenye node hiyo.

Jenkins Secrets

Encryption of Secrets and Credentials

Definition kutoka kwa docs: Jenkins inatumia AES ku-encrypt na kulinda secrets, credentials, na funguo zao za encryption. Funguo hizi za encryption zinahifadhiwa katika $JENKINS_HOME/secrets/ pamoja na master key inayotumika kulinda funguo hizo. Dirisha hili linapaswa kusanidiwa ili mtumiaji wa mfumo wa uendeshaji ambaye Jenkins controller inakimbia kama yeye tu ndiye awe na haki ya kusoma na kuandika kwenye dirisha hili (kwa mfano, chmod ya 0700 au kutumia sifa za faili zinazofaa). Master key (mara nyingine inatajwa kama “key encryption key” katika istilahi za crypto) inahifadhiwa unencrypted kwenye filesystem ya controller ya Jenkins katika $JENKINS_HOME/secrets/master.key ambayo haisilindii dhidi ya wavamizi walio na ufikiaji wa moja kwa moja wa faili hiyo. Watumiaji na watengenezaji wengi watatumia funguo hizi za encryption kwa njia isiyo ya moja kwa moja kupitia API ya Secret kwa ajili ya ku-encrypt data ya siri za jumla au kupitia credentials API. Kwa wanaovutiwa na crypto, Jenkins inatumia AES katika cipher block chaining (CBC) mode na PKCS#5 padding na IVs za nasibu ku-encrypt instances za CryptoConfidentialKey ambazo zinahifadhiwa katika $JENKINS_HOME/secrets/ kwa jina la faili linalolingana na id ya CryptoConfidentialKey. IDs za kawaida za funguo ni pamoja na:

  • hudson.util.Secret: inatumiwa kwa secrets za jumla;
  • com.cloudbees.plugins.credentials.SecretBytes.KEY: inatumiwa kwa aina fulani za credentials;
  • jenkins.model.Jenkins.crumbSalt: inatumiwa na CSRF protection mechanism; na

Credentials Access

Credentials zinaweza kuwekwa sakani kwa global providers (/credentials/) ambazo zinaweza kufikiwa na project yoyote iliyosanidiwa, au zinaweza kuwekwa sakani kwa projects maalum (/job/<project-name>/configure) na kwa hivyo zinaweza kufikiwa tu kutoka project husika.

Kulingana na docs: Credentials zilizo ndani ya scope zinapatikana kwenye pipeline bila vikwazo. Ili kuzuia kufichuka kwa bahati mbaya katika build log, credentials zinatahaniwa (masked) kutoka kwenye output ya kawaida, kwa hivyo mtego wa env (Linux) au set (Windows), au programu zinazochapisha environment yao au parameters hazitawaonyesha katika build log kwa watumiaji ambao vinginevyo hawana ufikiaji wa credentials.

Ndiyo maana ili kutekeleza exfiltration ya credentials mwizi anahitaji, kwa mfano, kuzi-base64.

Secrets in plugin/job configs on disk

Usidhani secrets ziko tu katika credentials.xml. Plugins nyingi zinaweka secrets katika XML zao za kimataifa chini ya $JENKINS_HOME/*.xml au katika per-job $JENKINS_HOME/jobs/<JOB>/config.xml, wakati mwingine hata kwa plaintext (masking ya UI haiwahakikishi uhifadhi uliosenwa). Ikiwa unapata ufikiaji wa kusoma filesystem, orodhesha XML hizo na tafuta tags za siri zilizoonekana wazi.

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

Marejeo

Tip

Jifunze na fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Jifunze na fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Jifunze na fanya mazoezi ya Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks