CircleCI 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)
CircleCI є платформою безперервної інтеграції, де ви можете визначити шаблони, вказуючи, що ви хочете, щоб вона робила з деяким кодом і коли це робити. Таким чином, ви можете автоматизувати тестування або деплойменти безпосередньо з вашої основної гілки репозиторію, наприклад.
CircleCI успадковує дозволи з github та bitbucket, пов'язані з обліковим записом, який входить в систему. У моєму тестуванні я перевірив, що, поки у вас є права на запис у репозиторії в github, ви зможете керувати налаштуваннями проекту в CircleCI (встановлювати нові ssh-ключі, отримувати api-ключі проекту, створювати нові гілки з новими конфігураціями CircleCI...).
Однак вам потрібно бути адміністратором репозиторію, щоб перетворити репозиторій на проект CircleCI.
Згідно з документацією, існують різні способи завантаження значень у змінні середовища всередині робочого процесу.
Кожен контейнер, запущений CircleCI, завжди матиме конкретні змінні середовища, визначені в документації такі як CIRCLE_PR_USERNAME, CIRCLE_PROJECT_REPONAME або CIRCLE_USERNAME.
Ви можете оголосити їх у відкритому тексті всередині команди:
Ви можете оголосити їх у відкритому тексті всередині середовища виконання:
Ви можете оголосити їх у відкритому тексті всередині build-job environment:
Ви можете оголосити їх у відкритому тексті всередині середовища контейнера:
Це секрети, які будуть доступні лише проекту (через будь-яку гілку). Ви можете побачити їх оголошеними в https://app.circleci.com/settings/project/github/<org_name>/<repo_name>/environment-variables
Функціональність "Імпорт змінних" дозволяє імпортувати змінні з інших проектів до цього.
Це секрети, які є всередині організації. За замовчуванням будь-який репозиторій зможе доступати до будь-якого секрету, збереженого тут:
Однак, зверніть увагу, що можна вибрати іншу групу (замість усіх учасників), щоб надавати доступ до секретів лише конкретним людям. Це наразі один з найкращих способів підвищити безпеку секретів, не дозволяючи всім отримувати до них доступ, а лише деяким.
Якщо у вас є доступ до VCS (наприклад, github), перевірте файл .circleci/config.yml кожного репозиторію на кожній гілці та пошукайте потенційні секрети у відкритому тексті, збережені там.
Перевіряючи код, ви можете знайти всі назви секретів, які використовуються в кожному файлі .circleci/config.yml. Ви також можете отримати назви контекстів з цих файлів або перевірити їх у веб-консолі: https://app.circleci.com/settings/organization/github/<org_name>/contexts.
Щоб екстрагувати ВСІ секрети проекту та контексту, вам просто потрібно мати ПРАВО НА ЗАПИС до лише 1 репозиторію в усій організації github (і ваш обліковий запис повинен мати доступ до контекстів, але за замовчуванням кожен може отримати доступ до кожного контексту).
Функціональність "Імпорт змінних" дозволяє імпортувати змінні з інших проектів до цього. Тому, зловмисник може імпортувати всі змінні проекту з усіх репозиторіїв і потім екстрагувати їх усі разом.
Усі секрети проекту завжди встановлюються в середовищі завдань, тому просто викликавши env і обфускуючи його в base64, ви зможете екстрагувати секрети в консолі веб-логів робочих процесів:
Якщо ви не маєте доступу до веб-консолі, але у вас є доступ до репозиторію і ви знаєте, що використовується CircleCI, ви можете просто створити робочий процес, який запускається кожну хвилину і експортує секрети на зовнішню адресу:
Вам потрібно вказати ім'я контексту (це також екстрактує секрети проекту):
Якщо ви не маєте доступу до веб-консолі, але у вас є доступ до репозиторію і ви знаєте, що використовується CircleCI, ви можете просто модифікувати робочий процес, який тригериться кожну хвилину і експортує секрети на зовнішню адресу:
Просто створення нового .circleci/config.yml в репозиторії не є достатнім для запуску збірки circleci. Вам потрібно увімкнути його як проект у консолі circleci.
CircleCI надає вам можливість запускати ваші збірки на їхніх машинах або на ваших власних. За замовчуванням їхні машини розташовані в GCP, і спочатку ви не зможете знайти нічого релевантного. Однак, якщо жертва виконує завдання на своїх власних машинах (можливо, у хмарному середовищі), ви можете знайти кінцеву точку метаданих хмари з цікавою інформацією.
Зверніть увагу, що в попередніх прикладах все запускалося всередині контейнера docker, але ви також можете попросити запустити віртуальну машину (яка може мати різні хмарні дозволи):
Або навіть контейнер Docker з доступом до віддаленого сервісу Docker:
Можна створити токени користувача в CircleCI для доступу до API-інтерфейсів з доступом користувачів.
https://app.circleci.com/settings/user/tokens
Можна створити токени проектів для доступу до проекту з правами, наданими токену.
https://app.circleci.com/settings/project/github/<org>/<repo>/api
Можна додати SSH-ключі до проектів.
https://app.circleci.com/settings/project/github/<org>/<repo>/ssh
Можна створити cron job у прихованій гілці в несподіваному проекті, який витікає всі змінні середовища контексту щодня.
Або навіть створити в гілці / змінити відому задачу, яка буде витікати всі контексти та секрети проектів щодня.
Якщо ви є власником github, ви можете дозволити неперевірені orbs і налаштувати один у задачі як бекдор.
Ви можете знайти вразливість до ін'єкції команд в деякій задачі та ін'єктувати команди через секрет, змінюючи його значення.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
