Last updated
Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Основна структура середовища github великої компанії полягає в тому, щоб мати підприємство, яке володіє кількома організаціями, і кожна з них може містити кілька репозиторіїв та кілька команд. Менші компанії можуть просто володіти однією організацією і не мати підприємств.
З точки зору користувача, користувач може бути членом різних підприємств та організацій. У межах них користувач може мати різні ролі в підприємстві, організації та репозиторії.
Більше того, користувач може бути частиною різних команд з різними ролями в підприємстві, організації або репозиторії.
І нарешті, репозиторії можуть мати спеціальні механізми захисту.
Власник підприємства: Люди з цією роллю можуть керувати адміністраторами, керувати організаціями в межах підприємства, керувати налаштуваннями підприємства, забезпечувати дотримання політики в організаціях. Однак вони не можуть отримати доступ до налаштувань організації або вмісту, якщо їх не призначать власником організації або не нададуть прямий доступ до репозиторію, що належить організації.
Члени підприємства: Члени організацій, що належать вашому підприємству, також є автоматично членами підприємства.
В організації користувачі можуть мати різні ролі:
Власники організації: Власники організації мають повний адміністративний доступ до вашої організації. Цю роль слід обмежити, але не менше ніж двом людям у вашій організації.
Члени організації: За замовчуванням, неадміністративна роль для людей в організації є членом організації. За замовчуванням, члени організації мають певну кількість дозволів.
Менеджери з виставлення рахунків: Менеджери з виставлення рахунків - це користувачі, які можуть керувати налаштуваннями виставлення рахунків для вашої організації, такими як платіжна інформація.
Менеджери з безпеки: Це роль, яку власники організації можуть призначити будь-якій команді в організації. Коли вона застосовується, вона надає кожному члену команди дозволи на управління сповіщеннями про безпеку та налаштуваннями в межах вашої організації, а також права на читання для всіх репозиторіїв в організації.
Якщо ваша організація має команду безпеки, ви можете використовувати роль менеджера з безпеки, щоб надати членам команди найменший доступ, який їм потрібен до організації.
Менеджери GitHub App: Щоб дозволити додатковим користувачам керувати GitHub Apps, що належать організації, власник може надати їм дозволи менеджера GitHub App.
Зовнішні співпрацівники: Зовнішній співпрацівник - це особа, яка має доступ до одного або кількох репозиторіїв організації, але не є явно членом організації.
Ви можете порівняти дозволи цих ролей у цій таблиці: https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles
У https://github.com/organizations/<org_name>/settings/member_privileges ви можете побачити дозволи, які користувачі матимуть лише за те, що є частиною організації.
Налаштування, які тут сконфігуровані, вказуватимуть на такі дозволи членів організації:
Бути адміністратором, автором, читачем або не мати дозволів на всі репозиторії організації.
Якщо члени можуть створювати приватні, внутрішні або публічні репозиторії.
Якщо можливе форкання репозиторіїв.
Якщо можливо запрошувати зовнішніх співпрацівників.
Якщо можна публікувати публічні або приватні сайти.
Дозволи, які мають адміністратори над репозиторіями.
Якщо члени можуть створювати нові команди.
За замовчуванням створюються ролі репозиторіїв:
Читання: Рекомендується для некодуючих учасників, які хочуть переглядати або обговорювати ваш проект.
Тріаж: Рекомендується для учасників, які повинні проактивно управляти проблемами та запитами на злиття без доступу на запис.
Запис: Рекомендується для учасників, які активно вносять зміни до вашого проекту.
Управління: Рекомендується для менеджерів проектів, які повинні управляти репозиторієм без доступу до чутливих або руйнівних дій.
Адміністратор: Рекомендується для людей, які потребують повного доступу до проекту, включаючи чутливі та руйнівні дії, такі як управління безпекою або видалення репозиторію.
Ви можете порівняти дозволи кожної ролі в цій таблиці https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role
Ви також можете створити свої власні ролі в https://github.com/organizations/<org_name>/settings/roles
Ви можете переглянути команди, створені в організації в https://github.com/orgs/<org_name>/teams. Зверніть увагу, що для перегляду команд, які є дочірніми для інших команд, вам потрібно отримати доступ до кожної батьківської команди.
Користувачі організації можуть бути перераховані в https://github.com/orgs/<org_name>/people.
У інформації про кожного користувача ви можете побачити команди, членом яких є користувач, і репозиторії, до яких має доступ користувач.
Github пропонує різні способи аутентифікації у вашому обліковому записі та виконання дій від вашого імені.
Зайшовши на github.com, ви можете увійти, використовуючи своє ім'я користувача та пароль (і можливо 2FA).
Ви можете налаштувати свій обліковий запис з одним або кількома публічними ключами, що дозволяє відповідному приватному ключу виконувати дії від вашого імені. https://github.com/settings/keys
Ви не можете видавати себе за користувача з цими ключами, але якщо ви їх не використовуєте, може бути можливим, що ви будете виявлені за відправлення комітів без підпису. Дізнайтеся більше про пильний режим тут.
Ви можете згенерувати персональний токен доступу, щоб надати додатку доступ до вашого облікового запису. При створенні персонального токена доступу користувач повинен вказати дозволи, які токен матиме. https://github.com/settings/tokens
Oauth додатки можуть запитувати у вас дозволи для доступу до частини вашої інформації github або для видавання вас за себе для виконання деяких дій. Загальним прикладом цієї функціональності є кнопка входу з github, яку ви можете знайти на деяких платформах.
Ви можете створити свої власні Oauth додатки в https://github.com/settings/developers
Ви можете побачити всі Oauth додатки, які мають доступ до вашого облікового запису в https://github.com/settings/applications
Ви можете побачити обсяги, які Oauth Apps можуть запитувати в https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps
Ви можете побачити доступ третіх сторін додатків в організації в https://github.com/organizations/<org_name>/settings/oauth_application_policy
Деякі рекомендації з безпеки:
OAuth App завжди має діяти як аутентифікований користувач GitHub у всьому GitHub (наприклад, при наданні сповіщень користувачеві) і з доступом лише до вказаних обсягів.
OAuth App може використовуватися як постачальник ідентичності, активуючи "Увійти з GitHub" для аутентифікованого користувача.
Не створюйте OAuth App, якщо ви хочете, щоб ваш додаток діяв на одному репозиторії. З обсягом repo OAuth, OAuth Apps можуть діяти на всіх репозиторіях аутентифікованого користувача.
Не створюйте OAuth App, щоб діяти як додаток для вашої команди або компанії. OAuth Apps аутентифікуються як один користувач, тому якщо одна особа створює OAuth App для використання компанією, а потім залишає компанію, ніхто інший не матиме доступу до нього.
Більше тут тут.
Додатки Github можуть запитувати дозволи для доступу до вашої інформації github або видавання вас за себе для виконання конкретних дій над конкретними ресурсами. У GitHub Apps вам потрібно вказати репозиторії, до яких додаток матиме доступ.
Щоб встановити GitHub App, ви повинні бути власником організації або мати адміністративні дозволи в репозиторії.
GitHub App має підключатися до особистого облікового запису або організації.
Ви можете створити свій власний додаток GitHub в https://github.com/settings/apps
Ви можете побачити всі додатки GitHub, які мають доступ до вашого облікового запису в https://github.com/settings/apps/authorizations
Це API кінцеві точки для додатків GitHub https://docs.github.com/en/rest/overview/endpoints-available-for-github-app. Залежно від дозволів додатка, він зможе отримати доступ до деяких з них.
Ви можете побачити встановлені додатки в організації в https://github.com/organizations/<org_name>/settings/installations
Деякі рекомендації з безпеки:
GitHub App має виконувати дії незалежно від користувача (якщо додаток не використовує токен користувача до сервера). Щоб зберегти токени доступу користувача до сервера більш безпечними, ви можете використовувати токени доступу, які закінчуються через 8 годин, і токен оновлення, який можна обміняти на новий токен доступу. Для отримання додаткової інформації дивіться "Оновлення токенів доступу користувача до сервера."
Переконайтеся, що GitHub App інтегрується з конкретними репозиторіями.
GitHub App має підключатися до особистого облікового запису або організації.
Не очікуйте, що GitHub App знатиме і робитиме все, що може зробити користувач.
Не використовуйте GitHub App, якщо вам просто потрібен сервіс "Увійти з GitHub". Але GitHub App може використовувати потік ідентифікації користувача для входу користувачів і виконання інших дій.
Не створюйте GitHub App, якщо ви лише хочете діяти як користувач GitHub і робити все, що може зробити цей користувач.
Якщо ви використовуєте свій додаток з GitHub Actions і хочете змінити файли робочого процесу, ви повинні аутентифікуватися від імені користувача з токеном OAuth, який включає обсяг workflow. Користувач повинен мати адміністративні або записні дозволи на репозиторій, що містить файл робочого процесу. Для отримання додаткової інформації дивіться "Розуміння обсягів для OAuth додатків."
Більше тут тут.
Це не спосіб аутентифікації в github, але зловмисна Github Action може отримати неавторизований доступ до github і в залежності від привілеїв, наданих дії, можуть бути здійснені кілька різних атак. Дивіться нижче для отримання додаткової інформації.
Git дії дозволяють автоматизувати виконання коду, коли відбувається подія. Зазвичай виконуваний код є якимось чином пов'язаним з кодом репозиторію (можливо, створити контейнер Docker або перевірити, що PR не містить секретів).
У https://github.com/organizations/<org_name>/settings/actions можна перевірити налаштування github actions для організації.
Можна заборонити використання github actions повністю, дозволити всі github actions або просто дозволити певні дії.
Також можна налаштувати хто потребує схвалення для запуску Github Action та дозволи GITHUB_TOKEN Github Action, коли вона запускається.
Github Action зазвичай потребує певних секретів для взаємодії з github або сторонніми додатками. Щоб уникнути їх розміщення у відкритому тексті в репозиторії, github дозволяє розміщувати їх як Secrets.
Ці секрети можна налаштувати для репозиторію або для всієї організації. Тоді, щоб Action могла отримати доступ до секрету, вам потрібно оголосити його так:
Секрети можна отримати лише з Github Actions, які їх оголосили.
Після налаштування в репозиторії або організаціях користувачі github не зможуть отримати до них доступ знову, вони зможуть лише змінювати їх.
Отже, єдиний спосіб вкрасти секрети github - це мати доступ до машини, яка виконує Github Action (в цьому випадку ви зможете отримати доступ лише до секретів, оголошених для Action).
Github дозволяє створювати середовища, де ви можете зберігати секрети. Потім ви можете надати github action доступ до секретів всередині середовища за допомогою чогось на зразок:
Ви можете налаштувати середовище, щоб воно було доступним для всіх гілок (за замовчуванням), тільки захищених гілок або вказати, які гілки можуть отримати доступ до нього. Також можна встановити кількість необхідних перевірок перед виконанням дії з використанням середовища або почекати деякий час перед тим, як дозволити розгортання.
Github Action може бути виконано в середовищі github або може бути виконано в інфраструктурі третьої сторони, налаштованій користувачем.
Декілька організацій дозволяють запускати Github Actions в інфраструктурі третьої сторони, оскільки це зазвичай дешевше.
Ви можете перелічити самостійно хостовані ранери організації за адресою https://github.com/organizations/<org_name>/settings/actions/runners
Спосіб знайти, які Github Actions виконуються в не-github інфраструктурі, - це шукати runs-on: self-hosted у конфігурації yaml Github Action.
Неможливо запустити Github Action організації всередині самостійно хостованого середовища іншої організації, оскільки унікальний токен генерується для Ранера під час його налаштування, щоб знати, до якої організації належить ранер.
Якщо кастомний Github Runner налаштований на машині всередині AWS або GCP, наприклад, Action може отримати доступ до метаданих і викрасти токен облікового запису служби, з яким працює машина.
Якщо всі дії (або шкідлива дія) дозволені, користувач може використовувати Github action, яка є шкідливою і компрометує контейнер, в якому вона виконується.
Запуск шкідливої Github Action може бути зловжито зловмисником для:
Викрадення всіх секретів, до яких має доступ Action
Бічного переміщення, якщо Action виконується в інфраструктурі третьої сторони, де можна отримати доступ до токена SA, що використовується для запуску машини (ймовірно, через сервіс метаданих)
Зловживання токеном, що використовується робочим процесом, щоб викрасти код репозиторію, де виконується Action, або навіть змінити його.
Захист гілок призначений для не надання повного контролю над репозиторієм користувачам. Мета полягає в тому, щоб встановити кілька методів захисту перед тим, як мати можливість писати код у деякій гілці.
Захисти гілок репозиторію можна знайти за адресою https://github.com/<orgname>/<reponame>/settings/branches
Неможливо встановити захист гілки на рівні організації. Тому всі вони повинні бути оголошені в кожному репозиторії.
Різні захисти можуть бути застосовані до гілки (наприклад, до master):
Ви можете вимагати PR перед злиттям (тому ви не можете безпосередньо зливати код у гілку). Якщо це вибрано, можуть бути застосовані різні інші захисти:
Вимагати певну кількість схвалень. Дуже поширено вимагати, щоб 1 або 2 інші особи схвалили ваш PR, щоб одна особа не могла безпосередньо зливати код.
Скасувати схвалення, коли нові коміти додаються. Якщо ні, користувач може схвалити легітимний код, а потім користувач може додати шкідливий код і злити його.
Вимагати перевірок від Власників коду. Принаймні 1 власник коду репозиторію повинен схвалити PR (щоб "випадкові" користувачі не могли його схвалити)
Обмежити, хто може скасувати перевірки запитів на злиття. Ви можете вказати людей або команди, яким дозволено скасовувати перевірки запитів на злиття.
Дозволити вказаним акторам обійти вимоги запиту на злиття. Ці користувачі зможуть обійти попередні обмеження.
Вимагати, щоб перевірки статусу пройшли перед злиттям. Деякі перевірки повинні пройти перед тим, як зможете злити коміт (наприклад, github action, що перевіряє, чи немає жодного секрету в чистому тексті).
Вимагати вирішення розмови перед злиттям. Усі коментарі до коду повинні бути вирішені перед тим, як PR може бути злитий.
Вимагати підписаних комітів. Коміти повинні бути підписані.
Вимагати лінійної історії. Запобігти злиттю комітів, які не відповідають гілкам.
Включити адміністраторів. Якщо це не встановлено, адміністратори можуть обійти обмеження.
Обмежити, хто може надсилати запити на злиття до відповідних гілок. Обмежити, хто може надіслати PR.
Як ви можете бачити, навіть якщо вам вдалося отримати деякі облікові дані користувача, репозиторії можуть бути захищені, що заважає вам зливати код у master, наприклад, щоб скомпрометувати CI/CD pipeline.
Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
