Основна інформація про Jenkins

Tip

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Вивчайте та практикуйте Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Підтримка HackTricks

Доступ

Username + Password

Найпоширеніший спосіб входу в Jenkins — за допомогою імені користувача та пароля

If an authorized cookie gets stolen, it ca be used to access the session of the user. The cookie is usually called JSESSIONID.*. (A user can terminate all his sessions, but he would need to find out first that a cookie was stolen).

SSO/Plugins

Jenkins can be configured using plugins to be accessible via third party SSO.

Tokens

Users can generate tokens to give access to applications to impersonate them via CLI or REST API.

SSH Keys

This component provides a built-in SSH server for Jenkins. It’s an alternative interface for the Jenkins CLI, and commands can be invoked this way using any SSH client. (From the docs)

Авторизація

У /configureSecurity можна налаштувати метод авторизації Jenkins. Є кілька опцій:

  • Anyone can do anything: Навіть анонімний доступ може адмініструвати сервер
  • Legacy mode: Як у Jenkins <1.164. Якщо у вас є роль “admin”, вам буде надано повний контроль над системою, а в іншому випадку (включно з anonymous користувачами) ви матимете доступ лише для читання.
  • Logged-in users can do anything: У цьому режимі кожен увійшовший користувач отримує повний контроль над Jenkins. Єдиним користувачем, який не матиме повного контролю, є anonymous user, який отримує лише доступ для читання.
  • Matrix-based security: Ви можете налаштувати хто що може робити у вигляді таблиці. Кожен стовпець представляє дозвіл. Кожен рядок представляє користувача або групу/роль. Це включає спеціального користувача ‘anonymous’, який представляє неавторизованих користувачів, а також ‘authenticated’, який представляє усіх автентифікованих користувачів.

  • Project-based Matrix Authorization Strategy: Цей режим є розширенням до “Matrix-based security”, що дозволяє визначати додаткові ACL-матриці для кожного проєкту окремо.
  • Role-Based Strategy: Дозволяє визначати авторизації за допомогою role-based strategy. Керуйте ролями в /role-strategy.

Security Realm

У /configureSecurity можна налаштувати security realm. За замовчуванням Jenkins підтримує кілька різних Security Realms:

  • Delegate to servlet container: Для делегування автентифікації сервлет-контейнеру, що запускає контролер Jenkins, наприклад Jetty.
  • Jenkins’ own user database: Використовувати вбудоване сховище користувацьких даних Jenkins для автентифікації замість делегування зовнішній системі. Увімкнено за замовчуванням.
  • LDAP: Делегувати всю автентифікацію на налаштований LDAP-сервер, включаючи користувачів та групи.
  • Unix user/group database: Делегує автентифікацію базі користувачів на рівні ОС Unix на контролері Jenkins. Цей режим також дозволяє повторно використовувати Unix-групи для авторизації.

Плагіни можуть надавати додаткові security realms, які можуть бути корисними для інтеграції Jenkins в існуючі системи ідентичності, наприклад:

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 Secrets

Encryption of Secrets and 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.

That is why in order to exfiltrate the credentials an attacker needs to, for example, base64 them.

Secrets in plugin/job configs on disk

Do not assume secrets are only in credentials.xml. Many plugins persist secrets in their own global XML under $JENKINS_HOME/*.xml or in per-job $JENKINS_HOME/jobs/<JOB>/config.xml, sometimes even in plaintext (UI masking does not guarantee encrypted storage). If you gain filesystem read access, enumerate those XMLs and search for obvious secret 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" {} \\;

Посилання

Tip

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Вивчайте та практикуйте Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Підтримка HackTricks