Osnovne informacije o Jenkins-u

Tip

Učite i vežbajte AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Učite i vežbajte GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Učite i vežbajte Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Podržite HackTricks

Pristup

Korisničko ime + lozinka

Najčešći način prijave u Jenkins je pomoću korisničkog imena i lozinke.

Ako se ovlašćeni cookie ukrade, može se iskoristiti za pristup sesiji korisnika. Cookie se obično zove JSESSIONID.*. (Korisnik može prekinuti sve svoje sesije, ali bi prvo morao da sazna da je cookie ukraden).

SSO/Plugins

Jenkins se može konfigurisati pomoću pluginova da bude dostupan putem SSO treće strane.

Tokeni

Korisnici mogu generisati tokene da bi aplikacijama dali pristup i omogućili im da se predstavljaju kao oni preko CLI ili REST API-ja.

SSH Keys

Ova komponenta obezbeđuje ugrađeni SSH server za Jenkins. To je alternativni interfejs za Jenkins CLI, i komande se mogu pokretati na ovaj način koristeći bilo koji SSH klijent. (Iz docs)

Autorizacija

U /configureSecurity moguće je konfigurisati metod autorizacije za Jenkins. Postoji nekoliko opcija:

  • Anyone can do anything: Čak i anonimni pristup može administrisati server
  • Legacy mode: Isto kao u Jenkins <1.164. Ako imate “admin” role, dobićete punu kontrolu nad sistemom, a u suprotnom (uključujući ‘anonymous’ korisnike) imaćete pristup samo za čitanje.
  • Logged-in users can do anything: U ovom režimu, svaki ulogovani korisnik dobija punu kontrolu nad Jenkins-om. Jedini korisnik koji neće imati punu kontrolu je anonymous user, koji dobija samo read access.
  • Matrix-based security: Možete konfigurisati ko šta može da radi u tabeli. Svaka kolona predstavlja permisiju. Svaki red predstavlja korisnika ili grupu/rolu. Ovo uključuje specijalnog korisnika ‘anonymous’, koji predstavlja neautentifikovane korisnike, kao i ‘authenticated’, koji predstavlja sve autentifikovane korisnike.

  • Project-based Matrix Authorization Strategy: Ovaj režim je proširenje za “Matrix-based security” koje omogućava dodatne ACL matrice da budu definisane za svaki projekat posebno.
  • Role-Based Strategy: Omogućava definisanje autorizacija koristeći role-based strategy. Upravljajte rolama u /role-strategy.

Security Realm

U /configureSecurity moguće je konfigurisati security realm. Po podrazumevanoj vrednosti Jenkins uključuje podršku za nekoliko različitih Security Realms:

  • Delegate to servlet container: Za delegiranje autentifikacije na servlet container koji pokreće Jenkins controller, kao što je Jetty.
  • Jenkins’ own user database: Koristite ugrađenu Jenkins bazu korisnika za autentifikaciju umesto delegiranja na eksterni sistem. Ovo je podrazumevano omogućeno.
  • LDAP: Delegirajte svu autentifikaciju na konfigurisan LDAP server, uključujući korisnike i grupe.
  • Unix user/group database: Delegira autentifikaciju na osnovnu Unix OS-nivo korisničku bazu na Jenkins controlleru. Ovaj režim takođe omogućava ponovnu upotrebu Unix grupa za autorizaciju.

Pluginovi mogu obezbediti dodatne security realme koji mogu biti korisni za integraciju Jenkins-a u postojeće identity sisteme, na primer:

Jenkins Nodes, Agents & Executors

Definicije iz docs:

Nodes su mašine na kojima rade build agenti. Jenkins nadgleda svaki priključeni node za prostor na disku, slobodan temp prostor, slobodan swap, sinhronizaciju sata i vreme odziva. Node se uklanja iz rada ako bilo koja od ovih vrednosti pređe konfigurisan prag.

Agents upravljaju izvršavanjem zadataka u ime Jenkins controller-a koristeći executors. Agent može koristiti bilo koji operativni sistem koji podržava Java. Alati potrebni za build i testove instaliraju se na node gde agent radi; mogu biti instalirani direktno ili u kontejneru (Docker ili Kubernetes). Svaki agent je efektivno proces sa sopstvenim PID-om na host mašini.

Executor je slot za izvršavanje zadataka; efektivno, to je thread u agentu. Broj executora na node-u definiše broj konkurentnih zadataka koji se mogu izvršavati na tom node-u u istom trenutku. Drugim rečima, ovo određuje broj konkurentnih Pipeline stages koji mogu biti izvršeni na tom node-u u isto vreme.

Jenkins tajne

Enkripcija tajni i kredencijala

Definicija iz docs: Jenkins koristi AES za šifrovanje i zaštitu tajni, kredencijala i njihovih odgovarajućih ključeva za enkripciju. Ovi ključevi enkripcije se čuvaju u $JENKINS_HOME/secrets/ zajedno sa master ključem koji štiti pomenute ključeve. Ovaj direktorijum bi trebalo podesiti tako da samo operativni sistem korisnik pod kojim Jenkins controller radi ima pravo čitanja i pisanja (npr. chmod vrednost 0700 ili odgovarajuće atributi fajla). Master key (ponekad nazivan “key encryption key”) je sačuvan nešifrovan na filesystemu Jenkins controller-a u $JENKINS_HOME/secrets/master.key, što ne štiti od napadača sa direktnim pristupom tom fajlu. Većina korisnika i developera će koristiti ove ključeve indirektno preko Secret API-ja za šifrovanje generičkih tajnih podataka ili kroz credentials API. Za zainteresovane za kripto: Jenkins koristi AES u cipher block chaining (CBC) modu sa PKCS#5 padding-om i nasumičnim IV-ovima za enkriptovanje instanci CryptoConfidentialKey koje se skladište u $JENKINS_HOME/secrets/ sa imenom fajla koje odgovara njihovom CryptoConfidentialKey id-u. Uobičajeni id-evi ključeva uključuju:

  • hudson.util.Secret: koristi se za generičke tajne;
  • com.cloudbees.plugins.credentials.SecretBytes.KEY: koristi se za neke tipove kredencijala;
  • jenkins.model.Jenkins.crumbSalt: koristi se od strane CSRF protection mechanism; i

Pristup kredencijalima

Kredencijali mogu biti scope-ovani na global providers (/credentials/) kojima može pristupiti bilo koji konfigurisan projekat, ili mogu biti ograničeni na konkretne projekte (/job/<project-name>/configure) i stoga dostupni samo iz tog projekta.

Prema the docs: Kredencijali koji su u opsegu se čine dostupnim pipeline-u bez ograničenja. Da bi se spriječilo slučajno izlaganje u build log-u, kredencijali se maskiraju iz regularnog izlaza, tako da poziv env (Linux) ili set (Windows), ili programi koji ispisuju svoje environment promenljive ili parametre neće otkriti kredencijale u build log-u korisnicima koji inače nemaju pristup tim kredencijalima.

Zbog toga, da bi napadač izveo eksfiltraciju kredencijala, mora, na primer, da ih base64-uje.

Tajne u plugin/job konfiguracijama na disku

Ne pretpostavljajte da su tajne samo u credentials.xml. Mnogi pluginovi čuvaju tajne u svojim sopstvenim globalnim XML pod $JENKINS_HOME/*.xml ili u per-job $JENKINS_HOME/jobs/<JOB>/config.xml, ponekad čak i u plain textu (maskiranje u UI ne garantuje šifrovano skladištenje). Ako dobijete read pristup fajl sistemu, enumerišite te XML-ove i pretražite očigledne tagove koji sadrže tajne.

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

Reference

Tip

Učite i vežbajte AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Učite i vežbajte GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Učite i vežbajte Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Podržite HackTricks