Ukranian - Ht Cloud
HackTricks TrainingTwitterLinkedinSponsor

Basic Github Information

Підтримка HackTricks

Основна структура

Основна структура середовища 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 пропонує різні способи аутентифікації у вашому обліковому записі та виконання дій від вашого імені.

Веб-доступ

Зайшовши на github.com, ви можете увійти, використовуючи своє ім'я користувача та пароль (і можливо 2FA).

SSH ключі

Ви можете налаштувати свій обліковий запис з одним або кількома публічними ключами, що дозволяє відповідному приватному ключу виконувати дії від вашого імені. https://github.com/settings/keys

GPG ключі

Ви не можете видавати себе за користувача з цими ключами, але якщо ви їх не використовуєте, може бути можливим, що ви будете виявлені за відправлення комітів без підпису. Дізнайтеся більше про пильний режим тут.

Персональні токени доступу

Ви можете згенерувати персональний токен доступу, щоб надати додатку доступ до вашого облікового запису. При створенні персонального токена доступу користувач повинен вказати дозволи, які токен матиме. https://github.com/settings/tokens

Oauth додатки

Oauth додатки можуть запитувати у вас дозволи для доступу до частини вашої інформації github або для видавання вас за себе для виконання деяких дій. Загальним прикладом цієї функціональності є кнопка входу з github, яку ви можете знайти на деяких платформах.

Деякі рекомендації з безпеки:

  • OAuth App завжди має діяти як аутентифікований користувач GitHub у всьому GitHub (наприклад, при наданні сповіщень користувачеві) і з доступом лише до вказаних обсягів.

  • OAuth App може використовуватися як постачальник ідентифікації, активуючи "Увійти з GitHub" для аутентифікованого користувача.

  • Не створюйте OAuth App, якщо ви хочете, щоб ваш додаток діяв на одному репозиторії. З обсягом repo OAuth, OAuth Apps можуть діяти на всіх репозиторіях аутентифікованого користувача.

  • Не створюйте OAuth App, щоб діяти як додаток для вашої команди або компанії. OAuth Apps аутентифікуються як один користувач, тому якщо одна особа створює OAuth App для використання компанією, а потім залишає компанію, ніхто інший не матиме доступу до нього.

  • Більше тут тут.

Додатки Github

Додатки 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 Actions

Це не спосіб аутентифікації в github, але зловмисна Github Action може отримати неавторизований доступ до github і залежно від привілеїв, наданих дії, можуть бути здійснені кілька різних атак. Дивіться нижче для отримання додаткової інформації.

Git Actions

Git дії дозволяють автоматизувати виконання коду, коли відбувається подія. Зазвичай виконуваний код є якимось чином пов'язаним з кодом репозиторію (можливо, створити контейнер docker або перевірити, що PR не містить секретів).

Налаштування

У https://github.com/organizations/<org_name>/settings/actions можна перевірити налаштування github actions для організації.

Можна заборонити використання github actions повністю, дозволити всі github actions або просто дозволити певні дії.

Також можна налаштувати хто потребує схвалення для запуску Github Action та дозволи GITHUB_TOKEN Github Action, коли вона запускається.

Git Secrets

Github Action зазвичай потребує деяких секретів для взаємодії з github або сторонніми додатками. Щоб уникнути їх розміщення у відкритому тексті в репозиторії, github дозволяє розміщувати їх як Secrets.

Ці секрети можна налаштувати для репозиторію або для всієї організації. Тоді, щоб Action могла отримати доступ до секрету, вам потрібно оголосити його так:

steps:
- name: Hello world action
with: # Set the secret as an input
super_secret: ${{ secrets.SuperSecret }}
env: # Or as an environment variable
super_secret: ${{ secrets.SuperSecret }}

Приклад використання Bash

steps:
- shell: bash
env:
SUPER_SECRET: ${{ secrets.SuperSecret }}
run: |
example-command "$SUPER_SECRET"

Секрети можна отримати лише з Github Actions, які їх оголосили.

Після налаштування в репозиторії або організаціях користувачі github не зможуть отримати до них доступ знову, вони зможуть лише змінювати їх.

Отже, єдиний спосіб вкрасти секрети github - це мати доступ до машини, яка виконує Github Action (в цьому сценарії ви зможете отримати доступ лише до секретів, оголошених для Action).

Git Environments

Github дозволяє створювати середовища, де ви можете зберігати секрети. Потім ви можете надати github action доступ до секретів всередині середовища за допомогою чогось на кшталт:

jobs:
deployment:
runs-on: ubuntu-latest
environment: env_name

Ви можете налаштувати середовище, щоб воно доступне для всіх гілок (за замовчуванням), тільки захищених гілок або вказати, які гілки можуть отримати доступ до нього. Також можна встановити кількість необхідних перевірок перед виконанням дії з використанням середовища або почекати деякий час перед тим, як дозволити розгортання.

Git Action Runner

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 може отримати доступ до кінцевої точки метаданих і викрасти токен облікового запису служби, з яким працює машина.

Git Action Compromise

Якщо всі дії (або шкідлива дія) дозволені, користувач може використовувати 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.

Посилання

Підтримати HackTricks
PreviousAccessible Deleted Data in GithubNextGitea Security

Last updated