Last updated
Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Найпоширеніший спосіб входу в Jenkins - це використання імені користувача або пароля.
Якщо авторизований cookie буде вкрадено, його можна використовувати для доступу до сесії користувача. Cookie зазвичай називається JSESSIONID.*. (Користувач може завершити всі свої сесії, але спочатку йому потрібно дізнатися, що cookie було вкрадено).
Jenkins можна налаштувати за допомогою плагінів, щоб він був доступний через сторонній SSO.
Користувачі можуть генерувати токени, щоб надати доступ до додатків для їх імітації через CLI або REST API.
Цей компонент забезпечує вбудований SSH сервер для Jenkins. Це альтернативний інтерфейс для Jenkins CLI, і команди можуть бути викликані таким чином, використовуючи будь-який SSH клієнт. (З документації)
У /configureSecurity можна налаштувати метод авторизації Jenkins. Є кілька варіантів:
Будь-хто може робити що завгодно: Навіть анонімний доступ може адмініструвати сервер.
Спадковий режим: Те ж саме, що і Jenkins <1.164. Якщо у вас є роль "адміністратор", вам буде надано повний контроль над системою, а в іншому випадку (включаючи анонімних користувачів) ви матимете доступ для читання.
Увійшли користувачі можуть робити що завгодно: У цьому режимі кожен увійшовший користувач отримує повний контроль над Jenkins. Єдиний користувач, який не матиме повного контролю, - це анонімний користувач, який отримує лише доступ для читання.
Безпека на основі матриці: Ви можете налаштувати хто може робити що в таблиці. Кожен стовпець представляє дозвіл. Кожен рядок представляє користувача або групу/роль. Це включає спеціального користувача 'анонімний', який представляє неавтентифікованих користувачів, а також 'автентифікований', який представляє всіх автентифікованих користувачів.
Стратегія авторизації на основі проекту: Цей режим є розширенням до "Безпеки на основі матриці", яке дозволяє визначити додаткову матрицю ACL для кожного проекту окремо.
Стратегія на основі ролей: Дозволяє визначати авторизації, використовуючи стратегію на основі ролей. Керуйте ролями в /role-strategy.
У /configureSecurity можна налаштувати сферу безпеки. За замовчуванням Jenkins включає підтримку кількох різних сфер безпеки:
Делегувати контейнеру сервлетів: Для делегування аутентифікації контейнеру сервлетів, що працює на контролері Jenkins, наприклад, Jetty.
Власна база даних користувачів Jenkins: Використовуйте вбудовану базу даних користувачів Jenkins для аутентифікації замість делегування зовнішній системі. Це включено за замовчуванням.
LDAP: Делегувати всю аутентифікацію до налаштованого LDAP сервера, включаючи як користувачів, так і групи.
База даних користувачів/груп Unix: Делегує аутентифікацію до бази даних користувачів на рівні Unix на контролері Jenkins. Цей режим також дозволить повторно використовувати групи Unix для авторизації.
Плагіни можуть надавати додаткові сфери безпеки, які можуть бути корисними для інтеграції Jenkins в існуючі системи ідентифікації, такі як:
Визначення з документації:
Вузли - це машини, на яких працюють агенти збірки. Jenkins контролює кожен підключений вузол на предмет вільного місця на диску, вільного тимчасового місця, вільного обміну, часу/синхронізації годинника та часу відгуку. Вузол виводиться з експлуатації, якщо будь-яке з цих значень виходить за межі налаштованого порогу.
Агенти керують виконанням завдань від імені контролера Jenkins, використовуючи виконавців. Агент може використовувати будь-яку операційну систему, яка підтримує Java. Інструменти, необхідні для збірок і тестів, встановлюються на вузлі, де працює агент; їх можна встановити безпосередньо або в контейнері (Docker або Kubernetes). Кожен агент фактично є процесом зі своїм PID на хост-машині.
Виконавець - це слот для виконання завдань; фактично, це потік в агенті. Кількість виконавців на вузлі визначає кількість паралельних завдань, які можуть бути виконані на цьому вузлі одночасно. Іншими словами, це визначає кількість паралельних стадій Pipeline, які можуть виконуватися на цьому вузлі одночасно.
Визначення з документації: Jenkins використовує AES для шифрування та захисту секретів, облікових даних та їх відповідних ключів шифрування. Ці ключі шифрування зберігаються в $JENKINS_HOME/secrets/ разом з майстер-ключем, що використовується для захисту цих ключів. Цю директорію слід налаштувати так, щоб лише користувач операційної системи, під яким працює контролер Jenkins, мав доступ на читання та запис до цієї директорії (тобто значення chmod має бути 0700 або використовувати відповідні атрибути файлів). Майстер-ключ (іноді називається "ключ шифрування" у криптографії) зберігається _незашифрованим_ на файловій системі контролера Jenkins у $JENKINS_HOME/secrets/master.key, що не захищає від атакуючих з прямим доступом до цього файлу. Більшість користувачів і розробників використовуватимуть ці ключі шифрування непрямо через API Secret для шифрування загальних секретних даних або через API облікових даних. Для криптоцікавих, Jenkins використовує AES в режимі шифрування блоку з ланцюгом (CBC) з PKCS#5 заповненням і випадковими IV для шифрування екземплярів CryptoConfidentialKey, які зберігаються в $JENKINS_HOME/secrets/ з іменем файлу, що відповідає їх CryptoConfidentialKey id. Загальні id ключів включають:
hudson.util.Secret: використовується для загальних секретів;
com.cloudbees.plugins.credentials.SecretBytes.KEY: використовується для деяких типів облікових даних;
jenkins.model.Jenkins.crumbSalt: використовується механізмом захисту від CSRF; та
Облікові дані можуть бути обмежені глобальними постачальниками (/credentials/), до яких може отримати доступ будь-який налаштований проект, або можуть бути обмежені конкретними проектами (/job/<project-name>/configure) і, отже, доступні лише з конкретного проекту.
Згідно з документацією: Облікові дані, які знаходяться в межах, стають доступними для конвеєра без обмежень. Щоб запобігти випадковому розкриттю в журналі збірки, облікові дані маскуються від звичайного виводу, тому виклик env (Linux) або set (Windows), або програми, що друкують своє середовище або параметри, не розкриють їх у журналі збірки для користувачів, які інакше не мали б доступу до облікових даних.
Ось чому, щоб ексфільтрувати облікові дані, атакуючий повинен, наприклад, закодувати їх у base64.
Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
