Basiese Jenkins-inligting

Tip

Leer & oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer & oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Leer & oefen Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks

Toegang

Gebruikersnaam + Wagwoord

Die mees algemene manier om by Jenkins aan te meld is met ’n gebruikersnaam en wagwoord

As ’n gemagtigde cookie gesteel word, kan dit gebruik word om toegang tot die gebruiker se sessie te kry. Die cookie word gewoonlik JSESSIONID.* genoem. (’n Gebruiker kan al sy sessies beëindig, maar hy sal eers moet uitvind dat ’n cookie gesteel is).

SSO/Plugins

Jenkins kan met plugins gekonfigureer word om deur derdeparty SSO toeganklik te wees.

Tokens

Gebruikers kan tokens genereer om toepassings toegang te gee om namens hulle op te tree via die CLI of REST API.

SSH Keys

Hierdie komponent verskaf ’n ingeboude SSH-bediener vir Jenkins. Dit is ’n alternatiewe koppelvlak vir die Jenkins CLI, en opdragte kan op hierdie wyse met enige SSH-kliënt uitgevoer word. (From the docs)

Outorisering

In /configureSecurity is dit moontlik om die outoriseringmetode van Jenkins te konfigureer. Daar is verskeie opsies:

  • Anyone can do anything: Selfs anonieme toegang kan die bediener administreer
  • Legacy mode: Dieselfde as Jenkins <1.164. As jy die “admin” role het, sal jy volledige beheer oor die stelsel ontvang, en andersins (insluitend anonieme gebruikers) sal jy lees toegang hê.
  • Logged-in users can do anything: In hierdie modus kry elke aangemelde gebruiker volle beheer van Jenkins. Die enigste gebruiker wat nie volle beheer sal hê nie is die anonieme gebruiker, wat slegs lees toegang kry.
  • Matrix-based security: Jy kan wie wat kan doen in ’n tabel konfigureer. Elke kolom verteenwoordig ’n permisisie. Elke ry verteenwoordig ’n gebruiker of ’n groep/rol. Dit sluit ’n spesiale gebruiker ‘anonymous’ in, wat nie-geauthentiseerde gebruikers verteenwoordig, sowel as ‘authenticated’, wat alle geauthentiseerde gebruikers verteenwoordig.

  • Project-based Matrix Authorization Strategy: Hierdie modus is ’n uitbreiding van “Matrix-based security” wat toelaat dat addisionele ACL-matrikse vir elke projek afsonderlik gedefinieer word.
  • Role-Based Strategy: Maak dit moontlik om outorisasies te definieer met ’n rolgebaseerde strategie. Bestuur die rolle in /role-strategy.

Sekuriteitsdomein

In /configureSecurity is dit moontlik om die security realm te konfigureer. Standaard ondersteun Jenkins ’n paar verskillende Security Realms:

  • Delegate to servlet container: Vir die delegasie van verifikasie aan ’n servlet container wat die Jenkins-controller uitvoer, soos Jetty.
  • Jenkins’ own user database: Gebruik Jenkins se eie ingeboude gebruikersdatabasis vir verifikasie in plaas daarvan om dit aan ’n eksterne stelsel te delegeren. Dit is standaard aangeskakel.
  • LDAP: Delegeer alle verifikasie aan ’n gekonfigureerde LDAP-bediener, insluitend beide gebruikers en groepe.
  • Unix user/group database: Delegeer die verifikasie aan die onderliggende Unix OS-vlak gebruikersdatabasis op die Jenkins-controller. Hierdie modus sal ook hergebruik van Unix-groepe vir outorisering toelaat.

Plugins kan addisionele security realms verskaf wat nuttig kan wees om Jenkins in bestaande identity systems in te sluit, soos:

Jenkins Nodes, Agents & Executors

Definitions from the docs:

Nodes are the machines on which build agents run. Jenkins monitors each attached node for disk space, free temp space, free swap, clock time/sync and response time. A node is taken offline if any of these values go outside the configured threshold.

Agents manage the task execution on behalf of the Jenkins controller by using executors. An agent can use any operating system that supports Java. Tools required for builds and tests are installed on the node where the agent runs; they can be installed directly or in a container (Docker or Kubernetes). Each agent is effectively a process with its own PID on the host machine.

An executor is a slot for execution of tasks; effectively, it is a thread in the agent. The number of executors on a node defines the number of concurrent tasks that can be executed on that node at one time. In other words, this determines the number of concurrent Pipeline stages that can execute on that node at one time.

Jenkins Sekrete

Enkripsie van Sekrete en Credentials

Definition from the docs: Jenkins uses AES to encrypt and protect secrets, credentials, and their respective encryption keys. These encryption keys are stored in $JENKINS_HOME/secrets/ along with the master key used to protect said keys. This directory should be configured so that only the operating system user the Jenkins controller is running as has read and write access to this directory (i.e., a chmod value of 0700 or using appropriate file attributes). The master key (sometimes referred to as a “key encryption key” in cryptojargon) is stored _unencrypted_ on the Jenkins controller filesystem in $JENKINS_HOME/secrets/master.key which does not protect against attackers with direct access to that file. Most users and developers will use these encryption keys indirectly via either the Secret API for encrypting generic secret data or through the credentials API. For the cryptocurious, Jenkins uses AES in cipher block chaining (CBC) mode with PKCS#5 padding and random IVs to encrypt instances of CryptoConfidentialKey which are stored in $JENKINS_HOME/secrets/ with a filename corresponding to their CryptoConfidentialKey id. Common key ids include:

  • hudson.util.Secret: used for generic secrets;
  • com.cloudbees.plugins.credentials.SecretBytes.KEY: used for some credentials types;
  • jenkins.model.Jenkins.crumbSalt: used by the CSRF protection mechanism; and

Credentials Access

Credentials can be scoped to global providers (/credentials/) that can be accessed by any project configured, or can be scoped to specific projects (/job/<project-name>/configure) and therefore only accessible from the specific project.

According to the docs: Credentials that are in scope are made available to the pipeline without limitation. To prevent accidental exposure in the build log, credentials are masked from regular output, so an invocation of env (Linux) or set (Windows), or programs printing their environment or parameters would not reveal them in the build log to users who would not otherwise have access to the credentials.

Dit is hoekom, om die credentials te exfiltrate, ’n aanvaller byvoorbeeld hulle base64 moet enkodeer.

Secrets in plugin/job configs on disk

Moenie aanvaar dat sekrete slegs in credentials.xml is nie. Baie plugins bewaar sekrete in hul eie globale XML onder $JENKINS_HOME/*.xml of in per-job $JENKINS_HOME/jobs/<JOB>/config.xml, soms selfs in plaintext (UI masking waarborg nie enkripsie in stoorplek nie). As jy lêerstelsel-lees toegang kry, enumereer daardie XML’s en soek vir voor die hand liggende geheime tags.

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

Verwysings

Tip

Leer & oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer & oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Leer & oefen Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks