Basic Github Information

Вивчайте хакінг AWS від нуля до героя з htARTE (HackTricks AWS Red Team Expert)!

Інші способи підтримки HackTricks:

• Якщо ви хочете побачити рекламу вашої компанії на HackTricks або завантажити HackTricks у форматі PDF, перевірте ПЛАНИ ПІДТРИМКИ!

• Отримайте офіційний PEASS & HackTricks мерч

• Дізнайтеся про Сім'ю PEASS, нашу колекцію ексклюзивних NFT

• Приєднуйтесь до 💬 групи Discord або групи telegram або слідкуйте за нами на Twitter 🐦 @hacktricks_live.

• Поділіться своїми хакерськими трюками, надсилайте PR до HackTricks та HackTricks Cloud репозиторіїв GitHub.

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

Основна структура середовища 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

Основні відомості про Github

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

• Для встановлення додатка GitHub ви повинні бути власником організації або мати права адміністратора в репозиторії.

• Додаток GitHub повинен підключатися до особистого облікового запису або організації.

• Ви можете створити свій власний додаток 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 повинен виконувати дії незалежно від користувача (якщо додаток використовує токен користувач-до-сервера). Щоб зробити токени доступу користувача-до-сервера більш безпечними, ви можете використовувати токени доступу, які закінчуються через 8 годин, і оновлюваний токен, який можна обміняти на новий токен доступу. Для отримання додаткової інформації див. "Оновлення токенів доступу користувача-до-сервера."

• Переконайтеся, що додаток GitHub інтегрується з конкретними репозиторіями.

• Додаток GitHub повинен підключатися до особистого облікового запису або організації.

• Не очікуйте, що додаток GitHub знає і робить все, що може користувач.

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

• Не створюйте додаток GitHub, якщо ви лише хочете діяти як користувач GitHub і робити все, що може робити цей користувач.

• Якщо ви використовуєте свій додаток з діями GitHub і хочете змінювати файли робочого процесу, вам потрібно аутентифікуватися від імені користувача за допомогою токена OAuth, який включає область workflow. Користувач повинен мати права адміністратора або права на запис у репозиторії, що містить файл робочого процесу. Для отримання додаткової інформації див. "Розуміння областей для додатків OAuth."

• Більше інформації тут.

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

Середовища Git

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

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

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

Git Action Runner

Дію Github можна виконати всередині середовища github або виконати в інфраструктурі стороннього постачальника, налаштованій користувачем.

Декілька організацій дозволять виконувати дії Github в інфраструктурі стороннього постачальника, оскільки це зазвичай дешевше.

Ви можете переглянути список самостійних ранерів організації за адресою https://github.com/organizations/<org_name>/settings/actions/runners

Щоб дізнатися, які дії Github виконуються в інфраструктурі, що не належить до github, потрібно шукати runs-on: self-hosted в конфігурації yaml дії Github.

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

Якщо користувач налаштував свого власного ранера Github на машині всередині AWS або GCP, наприклад, дія може мати доступ до кінцевої точки метаданих і вкрасти токен облікового запису служби, з яким працює машина.

Компрометація Git Action

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

Зловмисна дія Github може бути використана зловмисником для:

• Вкрадення всіх секретів, до яких має доступ дія

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

• Зловживання токеном, який використовується робочим процесом, для вкрадення коду репозиторію, де виконується дія, або навіть його зміни.

Захист гілок

Захист гілок призначений не надавати повного контролю над репозиторієм користувачам. Мета полягає в тому, щоб встановити кілька методів захисту перед можливістю писати код у деякі гілки.

Захисти гілок репозиторію можна знайти за адресою https://github.com/<orgname>/<reponame>/settings/branches

Неможливо встановити захист гілки на рівні організації. Тому всі вони повинні бути визначені в кожному репозиторії.

До гілки (наприклад, до master) можуть бути застосовані різні захисти:

• Ви можете вимагати PR перед злиттям (таким чином, ви не можете безпосередньо зливати код у гілку). Якщо це вибрано, можуть бути встановлені інші захисти:

• Вимагати певну кількість схвалень. Дуже часто вимагається, щоб 1 або 2 інші людини схвалили ваш PR, щоб один користувач не міг безпосередньо зливати код.

• Скасувати схвалення при додаванні нових комітів. Якщо цього не зробити, користувач може схвалити легітимний код, а потім додати зловмисний код і злити його.

• Вимагати перегляди від власників коду. Принаймні 1 власник коду репозиторію повинен схвалити PR (таким чином, "випадкові" користувачі не можуть його схвалити)

• Обмежити, хто може скасувати перегляди запитів на злиття. Ви можете вказати людей або команди, які мають право скасувати перегляди запитів на злиття.

• Дозволити вказаним акторам обходити вимоги до запитів на злиття. Ці користувачі зможуть обійти попередні обмеження.

• Вимагати успішне проходження перевірок стану перед злиттям. Деякі перевірки повинні пройти перед можливістю злиття коміту (наприклад, дія github, що перевіряє відсутність текстового секрету).

• Вимагати вирішення розмов перед злиттям. Всі коментарі до коду повинні бути вирішені перед тим, як PR може бути злитий.

• Вимагати підписані коміти. Коміти повинні бути підписані.

• Вимагати лінійну історію. Запобігти злиттю комітів у відповідні гілки.

• Включити адміністраторів. Якщо це не встановлено, адміністратори можуть обійти обмеження.

• Обмежити, хто може здійснювати злиття відповідних гілок. Обмежити, хто може надсилати PR.

Як бачите, навіть якщо вам вдалося отримати деякі облікові дані користувача, репозиторії можуть бути захищені, що уникне вам можливість злиття коду в master, наприклад, для компрометації CI/CD конвеєра.

Посилання

• https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization

• https://docs.github.com/en/enterprise-server@3.3/admin/user-management/managing-users-in-your-enterprise/roles-in-an-enterprisehttps://docs.github.com/en/enterprise-server

• https://docs.github.com/en/get-started/learning-about-github/access-permissions-on-github

• https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-github-user-account/managing-user-account-settings/permission-levels-for-user-owned-project-boards

• https://docs.github.com/en/actions/security-guides/encrypted-secrets

Вивчіть хакінг AWS від нуля до героя з htARTE (HackTricks AWS Red Team Expert)!

Інші способи підтримки HackTricks:

• Якщо ви хочете побачити рекламу вашої компанії на HackTricks або завантажити HackTricks у PDF, перевірте ПЛАНИ ПІДПИСКИ!

• Отримайте офіційний PEASS & HackTricks мерч

• Дізнайтеся про Сім'ю PEASS, нашу колекцію ексклюзивних NFT

• Приєднуйтесь до 💬 групи Discord або групи telegram або слідкуйте за нами в Twitter 🐦 @hacktricks_live.

• Поділіться своїми хакінг-прийомами, надсилайте PR до HackTricks та HackTricks Cloud github репозиторіїв.