Ukranian - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

Github Security

Support HackTricks

What is Github

(From here) На високому рівні, GitHub - це вебсайт та хмарний сервіс, який допомагає розробникам зберігати та керувати своїм кодом, а також відстежувати та контролювати зміни в їхньому коді.

Basic Information

Basic Github Information

External Recon

Репозиторії Github можуть бути налаштовані як публічні, приватні та внутрішні.

  • Приватний означає, що тільки люди з організації зможуть отримати до них доступ

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

  • Публічний означає, що весь інтернет зможе отримати до нього доступ.

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

Github Dorks

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

Tools (кожен інструмент містить свій список dorks):

Github Leaks

Зверніть увагу, що github dorks також призначені для пошуку витоків, використовуючи параметри пошуку github. Цей розділ присвячений тим інструментам, які завантажують кожен репозиторій і шукають чутливу інформацію в них (навіть перевіряючи певну глибину комітів).

Tools (кожен інструмент містить свій список regex):

Коли ви шукаєте витоки в репозиторії та запускаєте щось на зразок git log -p, не забувайте, що можуть бути інші гілки з іншими комітами, що містять секрети!

External Forks

Можливо компрометувати репозиторії, зловживаючи запитами на злиття. Щоб дізнатися, чи вразливий репозиторій, вам в основному потрібно прочитати конфігурації yaml Github Actions. Більше інформації про це нижче.

Github Leaks in deleted/internal forks

Навіть якщо видалено або внутрішньо, може бути можливим отримати чутливі дані з форків репозиторіїв github. Перевірте це тут:

Accessible Deleted Data in Github

Organization Hardening

Member Privileges

Є деякі за замовчуванням привілеї, які можуть бути надані членам організації. Їх можна контролювати зі сторінки https://github.com/organizations/<org_name>/settings/member_privileges або з Organizations API.

  • Базові дозволи: Члени матимуть дозвіл None/Read/write/Admin над репозиторіями організації. Рекомендується None або Read.

  • Форкування репозиторіїв: Якщо це не потрібно, краще не дозволяти членам форкувати репозиторії організації.

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

  • Запити на доступ до інтеграцій: З цим увімкненим зовнішні співпрацівники зможуть запитувати доступ до GitHub або OAuth додатків для доступу до цієї організації та її ресурсів. Це зазвичай потрібно, але якщо ні, краще вимкнути.

  • Я не зміг знайти цю інформацію в відповіді API, поділіться, якщо ви знаєте

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

  • Я не зміг знайти цю інформацію в відповіді API, поділіться, якщо ви знаєте

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

  • Я не зміг знайти цю інформацію в відповіді API, поділіться, якщо ви знаєте

  • Дозволити членам створювати команди: Якщо увімкнено, будь-який член організації зможе створювати нові команди. Якщо вимкнено, тільки власники організації можуть створювати нові команди. Краще, щоб це було вимкнено.

  • Я не зміг знайти цю інформацію в відповіді API, поділіться, якщо ви знаєте

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

Actions Settings

Кілька налаштувань, пов'язаних з безпекою, можна налаштувати для дій зі сторінки https://github.com/organizations/<org_name>/settings/actions.

Зверніть увагу, що всі ці конфігурації також можуть бути встановлені для кожного репозиторію незалежно

  • Політики дій Github: Це дозволяє вказати, які репозиторії можуть виконувати робочі процеси та які робочі процеси повинні бути дозволені. Рекомендується вказати, які репозиторії повинні бути дозволені і не дозволяти всім діям виконуватися.

  • API-1, API-2

  • Робочі процеси запитів на злиття з зовнішніх співпрацівників: Рекомендується вимагати затвердження для всіх зовнішніх співпрацівників.

  • Я не зміг знайти API з цією інформацією, поділіться, якщо ви знаєте

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

  • Я не зміг знайти API з цією інформацією, поділіться, якщо ви знаєте

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

  • API

Integrations

Дайте знати, якщо ви знаєте кінцеву точку API для доступу до цієї інформації!

  • Політика доступу до сторонніх додатків: Рекомендується обмежити доступ до кожного додатку та дозволити лише необхідні (після їх перегляду).

  • Встановлені додатки GitHub: Рекомендується дозволяти лише необхідні (після їх перегляду).

Recon & Attacks abusing credentials

Для цього сценарію ми будемо припускати, що ви отримали доступ до облікового запису github.

With User Credentials

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

Зверніть увагу, що може використовуватися 2FA, тому ви зможете отримати доступ до цієї інформації лише якщо зможете пройти цю перевірку.

Зверніть увагу, що якщо вам вдасться вкрасти cookie user_session (в даний час налаштоване з SameSite: Lax), ви зможете повністю видати себе за користувача без необхідності в облікових даних або 2FA.

Перевірте розділ нижче про обхід захисту гілок, якщо це буде корисно.

With User SSH Key

Github дозволяє користувачам встановлювати SSH ключі, які будуть використовуватися як метод аутентифікації для розгортання коду від їх імені (2FA не застосовується).

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

# Go to the the repository folder
# Get repo config and current user name and email
git config --list

Якщо користувач налаштував своє ім'я користувача як своє ім'я користувача github, ви можете отримати доступ до публічних ключів, які він налаштував у своєму обліковому записі за адресою https://github.com/<github_username>.keys, ви можете перевірити це, щоб підтвердити, що приватний ключ, який ви знайшли, може бути використаний.

SSH ключі також можуть бути налаштовані в репозиторіях як ключі для розгортання. Будь-хто, хто має доступ до цього ключа, зможе запускати проекти з репозиторію. Зазвичай на сервері з різними ключами для розгортання локальний файл ~/.ssh/config надасть вам інформацію про те, до якого ключа це відноситься.

GPG Ключі

Як пояснено тут, іноді потрібно підписувати коміти, інакше вас можуть виявити.

Перевірте локально, чи має поточний користувач будь-який ключ за допомогою:

gpg --list-secret-keys --keyid-format=long

З токеном користувача

Для введення про токени користувача перевірте основну інформацію.

Токен користувача може використовуватися замість пароля для Git через HTTPS або може бути використаний для автентифікації до API через базову автентифікацію. Залежно від привілеїв, які до нього прикріплені, ви можете виконувати різні дії.

Токен користувача виглядає так: ghp_EfHnQFcFHX6fGIu5mpduvRiYR584kK0dX123

З Oauth-додатком

Для введення про додатки Github Oauth перевірте основну інформацію.

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

Це обсяги, які може запитувати Oauth-додаток. Завжди слід перевіряти запитувані обсяги перед їх прийняттям.

Більше того, як пояснено в основній інформації, організації можуть надавати/відмовляти в доступі стороннім додаткам до інформації/репозиторіїв/дій, пов'язаних з організацією.

З додатком Github

Для введення про додатки Github перевірте основну інформацію.

Зловмисник може створити шкідливий додаток Github для доступу до привілейованих даних/дій користувачів, які, ймовірно, приймуть їх як частину фішингової кампанії.

Більше того, як пояснено в основній інформації, організації можуть надавати/відмовляти в доступі стороннім додаткам до інформації/репозиторіїв/дій, пов'язаних з організацією.

Компрометація та зловживання Github Action

Існує кілька технік для компрометації та зловживання Github Action, перевірте їх тут:

Abusing Github Actions

Обхід захисту гілок

  • Вимагати певну кількість схвалень: Якщо ви скомпрометували кілька облікових записів, ви можете просто приймати свої PR з інших облікових записів. Якщо у вас є лише обліковий запис, з якого ви створили PR, ви не можете прийняти свій власний PR. Однак, якщо у вас є доступ до середовища Github Action всередині репозиторію, використовуючи GITHUB_TOKEN, ви можете схвалити свій PR і отримати 1 схвалення таким чином.

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

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

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

  • Коли файл CODEOWNER неправильно налаштований, Github не скаржиться, але не використовує його. Тому, якщо він неправильно налаштований, захист власників коду не застосовується.

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

  • Включити адміністраторів: Якщо це не налаштовано і ви є адміністратором репозиторію, ви можете обійти ці захисти гілок.

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

  • Видалення захисту гілок: Якщо ви є адміністратором репозиторію, ви можете вимкнути захист, злити свій PR і знову встановити захист.

  • Обхід захисту на надсилання: Якщо репозиторій дозволяє лише певним користувачам надсилати пуш (зливати код) у гілки (захист гілки може захищати всі гілки, вказуючи шаблон *).

  • Якщо у вас є доступ на запис до репозиторію, але вам не дозволено надсилати код через захист гілки, ви все ще можете створити нову гілку і в її межах створити github action, яка спрацьовує, коли код надсилається. Оскільки захист гілки не захищає гілку, поки вона не створена, цей перший пуш коду в гілку виконає github action.

Обхід захисту середовищ

Для введення про середовище Github перевірте основну інформацію.

У разі, якщо середовище може бути доступним з усіх гілок, воно не захищене і ви можете легко отримати доступ до секретів всередині середовища. Зверніть увагу, що ви можете знайти репозиторії, де всі гілки захищені (вказуючи їхні назви або використовуючи *), у цьому сценарії, знайдіть гілку, в яку ви можете надсилати код, і ви можете екстрагувати секрети, створивши новий github action (або модифікувавши один).

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

push: # Run it when a push is made to a branch
branches:
- current_branch_name #Use '**' to run when a push is made to any branch

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

Постійність

  • Генерувати токен користувача

  • Вкрасти токени github з секретів

  • Видалення результатів робочих процесів та гілок

  • Надати більше прав всій організації

  • Створити вебхуки для ексфільтрації інформації

  • Запросити зовнішніх співпрацівників

  • Видалити вебхуки, що використовуються SIEM

  • Створити/змінити Github Action з бекдором

  • Знайти вразливий Github Action для ін'єкції команд через модифікацію значення секрету

Підроблені коміти - Бекдор через коміти репозиторію

У Github можливо створити PR до репозиторію з форка. Навіть якщо PR не буде прийнято, ідентифікатор коміту всередині оригінального репозиторію буде створено для версії коду з форка. Тому, зловмисник може закріпити використання конкретного коміту з, здавалося б, легітимного репозиторію, який не був створений власником репозиторію.

Як цей:

name: example
on: [push]
jobs:
commit:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@c7d749a2d57b4b375d1ebcd17cfbfb60c676f18e
- shell: bash
run: |
echo 'hello world!'

Для отримання додаткової інформації перегляньте https://www.chainguard.dev/unchained/what-the-fork-imposter-commits-in-github-actions-and-ci-cd

Підтримайте HackTricks
PreviousPentesting CI/CD MethodologyNextAbusing Github Actions

Last updated