Github Security

Reading time: 13 minutes

Що таке Github

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

Основна інформація

Basic Github Information

Зовнішнє розвідка

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

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

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

Github Dorks

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

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

• https://github.com/obheda12/GitDorker (Список Dorks)
• https://github.com/techgaun/github-dorks (Список Dorks)
• https://github.com/hisxo/gitGraber (Список Dorks)

Github Витоки

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

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

• https://github.com/zricethezav/gitleaks
• https://github.com/trufflesecurity/truffleHog
• https://github.com/eth0izzle/shhgit
• https://github.com/michenriksen/gitrob
• https://github.com/anshumanbh/git-all-secrets
• https://github.com/kootenpv/gittyleaks
• https://github.com/awslabs/git-secrets

Зовнішні форки

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

Github Витоки в видалених/внутрішніх форках

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

Accessible Deleted Data in Github

Укріплення організації

Привілеї учасників

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

• Базові дозволи: Учасники матимуть дозвіл None/Read/write/Admin над репозиторіями організації. Рекомендується None або Read.
• Форкування репозиторіїв: Якщо це не потрібно, краще не дозволяти учасникам форкувати репозиторії організації.
• Створення сторінок: Якщо це не потрібно, краще не дозволяти учасникам публікувати сторінки з репозиторіїв організації. Якщо потрібно, ви можете дозволити створювати публічні або приватні сторінки.
• Запити на доступ до інтеграцій: З цим увімкненим зовнішні співпрацівники зможуть запитувати доступ до GitHub або OAuth додатків для доступу до цієї організації та її ресурсів. Це зазвичай потрібно, але якщо ні, краще вимкнути це.
• Я не зміг знайти цю інформацію в відповіді API, поділіться, якщо ви знаєте
• Зміна видимості репозиторію: Якщо увімкнено, учасники з адміністративними правами для репозиторію зможуть змінити його видимість. Якщо вимкнено, тільки власники організації можуть змінювати видимість репозиторіїв. Якщо ви не хочете, щоб люди робили речі публічними, переконайтеся, що це вимкнено.
• Я не зміг знайти цю інформацію в відповіді API, поділіться, якщо ви знаєте
• Видалення та передача репозиторію: Якщо увімкнено, учасники з адміністративними правами для репозиторію зможуть видаляти або передавати публічні та приватні репозиторії.
• Я не зміг знайти цю інформацію в відповіді API, поділіться, якщо ви знаєте
• Дозволити учасникам створювати команди: Якщо увімкнено, будь-який учасник організації зможе створювати нові команди. Якщо вимкнено, тільки власники організації можуть створювати нові команди. Краще, щоб це було вимкнено.
• Я не зміг знайти цю інформацію в відповіді API, поділіться, якщо ви знаєте
• Більше речей можна налаштувати на цій сторінці, але попередні є найбільш пов'язаними з безпекою.

Налаштування дій

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

• Політики дій Github: Це дозволяє вказати, які репозиторії можуть виконувати робочі процеси та які робочі процеси повинні бути дозволені. Рекомендується вказати, які репозиторії повинні бути дозволені і не дозволяти всім діям виконуватись.
• API-1, API-2
• Робочі процеси запитів на злиття з зовнішніх співпрацівників: Рекомендується вимагати схвалення для всіх зовнішніх співпрацівників.
• Я не зміг знайти API з цією інформацією, поділіться, якщо ви знаєте
• Виконання робочих процесів з запитів на злиття: Це сильно не рекомендується виконувати робочі процеси з запитів на злиття, оскільки утримувачі походження форку отримають можливість використовувати токени з правами читання на вихідному репозиторії.
• Я не зміг знайти API з цією інформацією, поділіться, якщо ви знаєте
• Дозволи робочих процесів: Сильно рекомендується надавати лише права читання на репозиторій. Не рекомендується надавати права на запис і створення/схвалення запитів на злиття, щоб уникнути зловживання GITHUB_TOKEN, наданим для виконання робочих процесів.
• API

Інтеграції

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

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

Розвідка та атаки, що зловживають обліковими даними

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

З обліковими даними користувача

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

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

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

З SSH ключем користувача

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