Jenkins Security
Basic Information
Jenkins - це інструмент, який пропонує простий спосіб створення середовища безперервної інтеграції або безперервної доставки (CI/CD) для майже будь-якої комбінації мов програмування та репозиторіїв вихідного коду за допомогою конвеєрів. Крім того, він автоматизує різні рутинні завдання розробки. Хоча Jenkins не усуває необхідність створення скриптів для окремих етапів, він забезпечує швидший і надійніший спосіб інтеграції всієї послідовності інструментів збірки, тестування та розгортання, ніж те, що можна легко створити вручну.
Unauthenticated Enumeration
Щоб шукати цікаві сторінки Jenkins без аутентифікації, такі як (/people або /asynchPeople, це перераховує поточних користувачів), ви можете використовувати:
Перевірте, чи можете ви виконувати команди без необхідності аутентифікації:
Без облікових даних ви можете подивитися всередину /asynchPeople/ або /securityRealm/user/admin/search/index?q= для імен користувачів.
Ви можете отримати версію Jenkins з шляху /oops або /error
Відомі вразливості
Увійти
У базовій інформації ви можете перевірити всі способи входу в Jenkins:
Реєстрація
Ви зможете знайти екземпляри Jenkins, які дозволяють вам створити обліковий запис і увійти в нього. Так просто.
SSO Вхід
Також, якщо функціональність/плагіни SSO були присутні, тоді ви повинні спробувати увійти в додаток, використовуючи тестовий обліковий запис (тобто, тестовий Github/Bitbucket обліковий запис). Трюк з тут.
Брутфорс
Jenkins не має політики паролів та захисту від брутфорсу імен користувачів. Важливо брутфорсити користувачів, оскільки можуть використовуватися слабкі паролі або імена користувачів як паролі, навіть перевернуті імена користувачів як паролі.
Password spraying
Використовуйте цей python скрипт або цей powershell скрипт.
IP Whitelisting Bypass
Багато організацій поєднують 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 системи.
Internal Jenkins Abuses
У цих сценаріях ми будемо припускати, що у вас є дійсний акаунт для доступу до Jenkins.
Залежно від Authorization механізму, налаштованого в Jenkins, і дозволів скомпрометованого користувача, ви можете або не можете виконати наступні атаки.
Для отримання додаткової інформації перевірте основну інформацію:
Listing users
Якщо ви отримали доступ до Jenkins, ви можете перерахувати інших зареєстрованих користувачів за адресою http://127.0.0.1:8080/asynchPeople/
Dumping builds to find cleartext secrets
Використовуйте цей скрипт для вивантаження консолей збірок та змінних середовища збірок, щоб сподіватися знайти секрети у відкритому тексті.
Викрадення SSH облікових даних
Якщо скомпрометований користувач має достатні привілеї для створення/модифікації нового Jenkins вузла і SSH облікові дані вже збережені для доступу до інших вузлів, він може викрасти ці облікові дані, створивши/модифікувавши вузол і встановивши хост, який буде записувати облікові дані без перевірки ключа хоста:
Ви зазвичай знайдете облікові дані Jenkins ssh у глобальному постачальнику (/credentials/
), тому ви також можете їх скинути так, як ви б скинули будь-яку іншу таємницю. Більше інформації в Розділі скидання секретів.
RCE в Jenkins
Отримання shell на сервері Jenkins дає зловмиснику можливість викрити всі секрети та змінні середовища і експлуатувати інші машини, розташовані в тій же мережі, або навіть збирати облікові дані хмари.
За замовчуванням Jenkins буде працювати як SYSTEM. Отже, компрометація його надасть зловмиснику привілеї SYSTEM.
RCE Створення/Модифікація проекту
Створення/модифікація проекту є способом отримання RCE на сервері Jenkins:
RCE Виконання Groovy скрипту
Ви також можете отримати RCE, виконуючи Groovy скрипт, який може бути менш помітним, ніж створення нового проекту:
RCE Створення/Модифікація Pipeline
Ви також можете отримати RCE, створюючи/модифікуючи pipeline:
Експлуатація Pipeline
Щоб експлуатувати pipeline, вам все ще потрібно мати доступ до Jenkins.
Будівельні Pipeline
Pipeline також можуть використовуватися як механізм збірки в проектах, в цьому випадку може бути налаштований файл всередині репозиторію, який міститиме синтаксис pipeline. За замовчуванням використовується /Jenkinsfile
:
Також можливо зберігати конфігураційні файли pipeline в інших місцях (в інших репозиторіях, наприклад) з метою розділення доступу до репозиторію та доступу до pipeline.
Якщо зловмисник має доступ на запис до цього файлу, він зможе модифікувати його і потенційно запустити pipeline, навіть не маючи доступу до Jenkins. Можливо, зловмиснику потрібно буде обійти деякі захисти гілок (в залежності від платформи та привілеїв користувача, їх можна обійти або ні).
Найбільш поширені тригери для виконання користувацького pipeline:
Запит на злиття до основної гілки (або потенційно до інших гілок)
Пуш до основної гілки (або потенційно до інших гілок)
Оновлення основної гілки і очікування, поки вона буде виконана якимось чином
Якщо ви є зовнішнім користувачем, вам не слід очікувати, що ви зможете створити PR до основної гілки репозиторію іншого користувача/організації і запустити pipeline... але якщо він погано налаштований, ви могли б повністю скомпрометувати компанії, просто експлуатуючи це.
Pipeline RCE
У попередньому розділі 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 (наприклад, запустивши реверс-шелл у вбудованому вузлі) і потім викрити майстер-ключі та зашифровані секрети і розшифрувати їх офлайн. Більше про те, як це зробити, у розділі Вузли та агенти та у розділі Постексплуатація.
Тригери
З документації: Директива triggers
визначає автоматизовані способи, якими Пайплайн має бути повторно запущений. Для Пайплайнів, які інтегровані з джерелом, таким як GitHub або BitBucket, triggers
можуть бути непотрібні, оскільки інтеграція на основі вебхуків, ймовірно, вже присутня. Доступні тригери: cron
, pollSCM
та upstream
.
Приклад cron:
Перевірте інші приклади в документації.
Вузли та Агенти
Екземпляр Jenkins може мати різні агенти, що працюють на різних машинах. З точки зору атакуючого, доступ до різних машин означає різні потенційні облікові дані хмари для крадіжки або різний мережевий доступ, який можна зловживати для експлуатації інших машин.
Для отримання додаткової інформації перевірте основну інформацію:
Ви можете перерахувати сконфігуровані вузли в /computer/
, зазвичай ви знайдете Вбудований Вузол
(який є вузлом, що запускає Jenkins) і потенційно більше:
Це особливо цікаво скомпрометувати Вбудований вузол, оскільки він містить чутливу інформацію Jenkins.
Щоб вказати, що ви хочете запустити конвеєр на вбудованому вузлі Jenkins, ви можете вказати в конвеєрі наступну конфігурацію:
Повний приклад
Pipeline в конкретному агенті, з тригером cron, з змінними середовища pipeline та stage, завантажуючи 2 змінні в кроці та відправляючи зворотний shell:
Доступ до довільних файлів для RCE
RCE
Після експлуатації
Metasploit
Jenkins Secrets
Ви можете перерахувати секрети, отримавши доступ до /credentials/
, якщо у вас достатньо прав. Зверніть увагу, що це лише перераховує секрети всередині файлу credentials.xml
, але файли конфігурації збірки також можуть містити додаткові облікові дані.
Якщо ви можете бачити конфігурацію кожного проекту, ви також можете побачити там імена облікових даних (секретів), які використовуються для доступу до репозиторію та інші облікові дані проекту.
From Groovy
From disk
Ці файли потрібні для дешифрування секретів Jenkins:
secrets/master.key
secrets/hudson.util.Secret
Такі секрети зазвичай можна знайти в:
credentials.xml
jobs/.../build.xml
jobs/.../config.xml
Ось регулярний вираз, щоб їх знайти:
Декодування секретів Jenkins офлайн
Якщо ви скинули необхідні паролі для декодування секретів, використовуйте цей скрипт для декодування цих секретів.
Дешифрування секретів Jenkins з Groovy
Створити нового адміністратора
Доступ до файлу Jenkins config.xml у
/var/lib/jenkins/config.xml
абоC:\Program Files (x86)\Jenkis\
Знайдіть слово
<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.
Посилання
Last updated