Jenkins Security
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Jenkins - це інструмент, який пропонує простий спосіб створення середовища безперервної інтеграції або безперервної доставки (CI/CD) для майже будь-якої комбінації мов програмування та репозиторіїв вихідного коду за допомогою конвеєрів. Крім того, він автоматизує різні рутинні завдання розробки. Хоча Jenkins не усуває необхідність створення скриптів для окремих кроків, він забезпечує швидший і надійніший спосіб інтеграції всієї послідовності інструментів збірки, тестування та розгортання, ніж те, що можна легко створити вручну.
Щоб шукати цікаві сторінки Jenkins без аутентифікації, такі як (/people або /asynchPeople, це перераховує поточних користувачів), ви можете використовувати:
Перевірте, чи можете ви виконувати команди без необхідності аутентифікації:
Без облікових даних ви можете подивитися всередині /asynchPeople/ або /securityRealm/user/admin/search/index?q= для імен користувачів.
Ви можете отримати версію Jenkins з шляху /oops або /error.
У базовій інформації ви можете перевірити всі способи входу в Jenkins:
Ви зможете знайти екземпляри Jenkins, які дозволяють вам створити обліковий запис і увійти в нього. Так просто.
Також, якщо функціональність/плагіни SSO були присутні, то ви повинні спробувати увійти в додаток, використовуючи тестовий обліковий запис (тобто, тестовий Github/Bitbucket обліковий запис). Трюк з тут.
Jenkins не має політики паролів та захисту від брутфорсу імен користувачів. Важливо брутфорсити користувачів, оскільки можуть використовуватися слабкі паролі або імена користувачів як паролі, навіть перевернуті імена користувачів як паролі.
Використовуйте цей python скрипт або цей powershell скрипт.
Багато організацій поєднують SaaS-based source control management (SCM) systems такі як GitHub або GitLab з внутрішнім, самостійно розгорнутим CI рішенням, таким як Jenkins або TeamCity. Це налаштування дозволяє CI системам отримувати webhook події від постачальників SaaS source control, в основному для запуску pipeline jobs.
Щоб досягти цього, організації дозволяють IP-діапазони SCM платформ, дозволяючи їм отримувати доступ до внутрішньої CI системи через webhooks. Однак важливо зазначити, що будь-хто може створити обліковий запис на GitHub або GitLab і налаштувати його для тригера webhook, потенційно надсилаючи запити до внутрішньої CI системи.
У цих сценаріях ми будемо припускати, що у вас є дійсний обліковий запис для доступу до Jenkins.
Залежно від Authorization механізму, налаштованого в Jenkins, і дозволів скомпрометованого користувача, ви можете або не можете виконати наступні атаки.
Для отримання додаткової інформації перевірте основну інформацію:
Якщо ви отримали доступ до Jenkins, ви можете перерахувати інших зареєстрованих користувачів за адресою http://127.0.0.1:8080/asynchPeople/
Використовуйте цей скрипт для вивантаження консолей збірок та змінних середовища збірок, щоб сподіватися знайти секрети у відкритому тексті.
Якщо скомпрометований користувач має достатні привілеї для створення/модифікації нового Jenkins вузла і SSH облікові дані вже збережені для доступу до інших вузлів, він може викрасти ці облікові дані, створивши/модифікувавши вузол і встановивши хост, який буде записувати облікові дані без перевірки ключа хоста:
Ви зазвичай знайдете облікові дані Jenkins ssh у глобальному постачальнику (/credentials/
), тому ви також можете їх скинути так, як ви б скинули будь-яку іншу таємницю. Більше інформації в Розділі скидання секретів.
Отримання shell на сервері Jenkins дає зловмиснику можливість викрити всі секрети та змінні середовища і експлуатувати інші машини, розташовані в тій же мережі, або навіть збирати облікові дані хмари.
За замовчуванням Jenkins буде працювати як SYSTEM. Отже, компрометація його надасть зловмиснику привілеї SYSTEM.
Створення/модифікація проекту є способом отримання RCE на сервері Jenkins:
Ви також можете отримати RCE, виконуючи Groovy скрипт, який може бути більш непомітним, ніж створення нового проекту:
Ви також можете отримати RCE, створюючи/модифікуючи pipeline:
Щоб експлуатувати pipeline, вам все ще потрібно мати доступ до Jenkins.
Pipeline також можуть використовуватися як механізм збірки в проектах, в цьому випадку може бути налаштований файл всередині репозиторію, який міститиме синтаксис pipeline. За замовчуванням використовується /Jenkinsfile
:
Також можливо зберігати конфігураційні файли pipeline в інших місцях (в інших репозиторіях, наприклад) з метою розділення доступу до репозиторію та доступу до pipeline.
Якщо зловмисник має доступ на запис до цього файлу, він зможе модифікувати його і потенційно запустити pipeline, навіть не маючи доступу до Jenkins. Можливо, що зловмиснику потрібно буде обійти деякі захисти гілок (в залежності від платформи та привілеїв користувача, їх можна обійти або ні).
Найбільш поширені тригери для виконання користувацького pipeline:
Запит на злиття до основної гілки (або потенційно до інших гілок)
Пуш до основної гілки (або потенційно до інших гілок)
Оновлення основної гілки і очікування, поки вона буде виконана якимось чином
Якщо ви є зовнішнім користувачем, вам не слід очікувати, що ви зможете створити PR до основної гілки репозиторію іншого користувача/організації і запустити pipeline... але якщо він погано налаштований, ви могли б повністю скомпрометувати компанії, просто експлуатуючи це.
У попередньому розділі RCE вже була вказана техніка для отримання RCE, модифікуючи pipeline.
Можливо оголосити змінні середовища у відкритому тексті для всього pipeline або для конкретних етапів. Ці змінні середовища не повинні містити чутливу інформацію, але зловмисник завжди може перевірити всі конфігурації pipeline/Jenkinsfiles:
Для отримання інформації про те, як зазвичай обробляються секрети в Jenkins, ознайомтеся з основною інформацією:
Облікові дані можуть бути обмежені глобальними постачальниками (/credentials/
) або конкретними проектами (/job/<project-name>/configure
). Тому, щоб ексфільтрувати всі з них, вам потрібно зламати принаймні всі проекти, які містять секрети, і виконати користувацькі/отруйні конвеєри.
Є ще одна проблема: щоб отримати секрет всередині env конвеєра, вам потрібно знати ім'я та тип секрету. Наприклад, якщо ви намагаєтеся завантажити секрет usernamePassword
як секрет string
, ви отримаєте цю помилку:
Ось спосіб завантажити деякі поширені типи секретів:
В кінці цієї сторінки ви можете знайти всі типи облікових даних: https://www.jenkins.io/doc/pipeline/steps/credentials-binding/
Найкращий спосіб вивести всі секрети одразу - це зламати машину Jenkins (наприклад, запустивши реверс-шелл у вбудованому вузлі) і потім викрити майстер-ключі та зашифровані секрети і розшифрувати їх офлайн. Більше про те, як це зробити, у розділі Nodes & Agents та в розділі Post Exploitation.
З документації: Директива triggers
визначає автоматизовані способи, якими Пайплайн має бути повторно запущений. Для Пайплайнів, які інтегровані з джерелом, таким як GitHub або BitBucket, triggers
можуть бути непотрібні, оскільки інтеграція на основі вебхуків, ймовірно, вже присутня. Доступні тригери: cron
, pollSCM
та upstream
.
Приклад cron:
Перевірте інші приклади в документації.
Екземпляр Jenkins може мати різні агенти, що працюють на різних машинах. З точки зору зловмисника, доступ до різних машин означає різні потенційні облікові дані хмари для крадіжки або різний мережевий доступ, який можна зловживати для експлуатації інших машин.
Для отримання додаткової інформації перевірте основну інформацію:
Ви можете перерахувати сконфігуровані вузли в /computer/
, зазвичай ви знайдете Вбудований Вузол
(який є вузлом, що запускає Jenkins) і потенційно більше:
Це особливо цікаво скомпрометувати Вбудований вузол, оскільки він містить чутливу інформацію Jenkins.
Щоб вказати, що ви хочете запустити конвеєр у вбудованому вузлі Jenkins, ви можете вказати в конвеєрі наступну конфігурацію:
Pipeline в конкретному агенті, з тригером cron, з змінними середовища pipeline та stage, завантажуючи 2 змінні в кроці та відправляючи зворотний shell:
Ви можете перерахувати секрети, отримавши доступ до /credentials/
, якщо у вас достатньо прав. Зверніть увагу, що це лише перераховує секрети всередині файлу credentials.xml
, але файли конфігурації збірки також можуть містити додаткові облікові дані.
Якщо ви можете бачити конфігурацію кожного проекту, ви також можете побачити там імена облікових даних (секретів), які використовуються для доступу до репозиторію та інші облікові дані проекту.
Ці файли потрібні для дешифрування секретів Jenkins:
secrets/master.key
secrets/hudson.util.Secret
Такі секрети зазвичай можна знайти в:
credentials.xml
jobs/.../build.xml
jobs/.../config.xml
Ось регулярний вираз, щоб знайти їх:
Якщо ви скинули необхідні паролі для декодування секретів, використовуйте цей скрипт для декодування цих секретів.
Доступ до файлу Jenkins config.xml у /var/lib/jenkins/config.xml
або C:\Program Files (x86)\Jenkins\
Знайдіть слово <useSecurity>true</useSecurity>
і змініть слово true
на false
.
sed -i -e 's/<useSecurity>true</<useSecurity>false</g' config.xml
Перезапустіть сервер Jenkins: service jenkins restart
Тепер знову перейдіть до порталу Jenkins, і Jenkins не запитає жодних облікових даних цього разу. Перейдіть до "Управління Jenkins", щоб знову встановити пароль адміністратора.
Увімкніть безпеку знову, змінивши налаштування на <useSecurity>true</useSecurity>
і знову перезапустіть Jenkins.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)