Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
(From here) At a high level, GitHub - це вебсайт та хмарний сервіс, який допомагає розробникам зберігати та керувати своїм кодом, а також відстежувати та контролювати зміни в їхньому коді.
Github репозиторії можуть бути налаштовані як публічні, приватні та внутрішні.
Приватний означає, що тільки люди з організації зможуть отримати до них доступ
Внутрішній означає, що тільки люди з підприємства (підприємство може мати кілька організацій) зможуть отримати до нього доступ
Публічний означає, що весь інтернет зможе отримати до нього доступ.
Якщо ви знаєте користувача, репозиторій або організацію, яку хочете націлити, ви можете використовувати github dorks, щоб знайти чутливу інформацію або шукати витоки чутливої інформації в кожному репозиторії.
Github дозволяє шукати щось, вказуючи в якості області користувача, репозиторій або організацію. Тому, з переліком рядків, які будуть з'являтися поруч з чутливою інформацією, ви можете легко шукати потенційну чутливу інформацію у вашій цілі.
Tools (кожен інструмент містить свій список dorks):
Зверніть увагу, що github dorks також призначені для пошуку витоків, використовуючи параметри пошуку github. Цей розділ присвячений тим інструментам, які завантажують кожен репозиторій і шукають чутливу інформацію в них (навіть перевіряючи певну глибину комітів).
Tools (кожен інструмент містить свій список regex):
Коли ви шукаєте витоки в репозиторії та запускаєте щось на зразок git log -p, не забувайте, що можуть бути інші гілки з іншими комітами, що містять секрети!
Можливо компрометувати репозиторії, зловживаючи запитами на злиття. Щоб дізнатися, чи вразливий репозиторій, вам в основному потрібно прочитати конфігурації yaml Github Actions. Більше інформації про це нижче.
Навіть якщо видалено або внутрішньо, може бути можливим отримати чутливі дані з форків репозиторіїв github. Перевірте це тут:
Accessible Deleted Data in GithubЄ деякі за замовчуванням привілеї, які можуть бути надані членам організації. Їх можна контролювати зі сторінки https://github.com/organizations/<org_name>/settings/member_privileges або з Organizations API.
Базові дозволи: Члени матимуть дозвіл None/Read/write/Admin над репозиторіями організації. Рекомендується None або Read.
Форкування репозиторіїв: Якщо це не потрібно, краще не дозволяти членам форкувати репозиторії організації.
Створення сторінок: Якщо це не потрібно, краще не дозволяти членам публікувати сторінки з репозиторіїв організації. Якщо це необхідно, ви можете дозволити створювати публічні або приватні сторінки.
Запити на доступ до інтеграцій: З цим увімкненим зовнішні співпрацівники зможуть запитувати доступ до GitHub або OAuth додатків для доступу до цієї організації та її ресурсів. Це зазвичай потрібно, але якщо ні, краще вимкнути це.
Я не зміг знайти цю інформацію в відповіді API, поділіться, якщо ви знайшли
Зміна видимості репозиторію: Якщо увімкнено, члени з адміністративними правами для репозиторію зможуть змінювати його видимість. Якщо вимкнено, тільки власники організації можуть змінювати видимість репозиторіїв. Якщо ви не хочете, щоб люди робили речі публічними, переконайтеся, що це вимкнено.
Я не зміг знайти цю інформацію в відповіді API, поділіться, якщо ви знайшли
Видалення та передача репозиторіїв: Якщо увімкнено, члени з адміністративними правами для репозиторію зможуть видаляти або передавати публічні та приватні репозиторії.
Я не зміг знайти цю інформацію в відповіді API, поділіться, якщо ви знайшли
Дозволити членам створювати команди: Якщо увімкнено, будь-який член організації зможе створювати нові команди. Якщо вимкнено, тільки власники організації можуть створювати нові команди. Краще, щоб це було вимкнено.
Я не зміг знайти цю інформацію в відповіді API, поділіться, якщо ви знайшли
Більше речей можна налаштувати на цій сторінці, але попередні є найбільш пов'язаними з безпекою.
Кілька налаштувань, пов'язаних з безпекою, можна налаштувати для дій зі сторінки https://github.com/organizations/<org_name>/settings/actions.
Зверніть увагу, що всі ці конфігурації також можуть бути встановлені для кожного репозиторію незалежно
Політики дій Github: Це дозволяє вам вказати, які репозиторії можуть запускати робочі процеси та які робочі процеси повинні бути дозволені. Рекомендується вказати, які репозиторії повинні бути дозволені і не дозволяти всім діям виконуватись.
Робочі процеси запитів на злиття з зовнішніх співпрацівників: Рекомендується вимагати схвалення для всіх зовнішніх співпрацівників.
Я не зміг знайти API з цією інформацією, поділіться, якщо ви знайшли
Запуск робочих процесів з запитів на злиття: Вкрай не рекомендується запускати робочі процеси з запитів на злиття, оскільки утримувачі походження форку отримають можливість використовувати токени з правами читання на вихідному репозиторії.
Я не зміг знайти API з цією інформацією, поділіться, якщо ви знайшли
Дозволи робочих процесів: Вкрай рекомендується надавати лише права читання на репозиторій. Не рекомендується надавати права на запис і створення/схвалення запитів на злиття, щоб уникнути зловживання GITHUB_TOKEN, наданим для виконання робочих процесів.
Дайте знати, якщо ви знаєте кінцеву точку API для доступу до цієї інформації!
Політика доступу до сторонніх додатків: Рекомендується обмежити доступ до кожного додатку та дозволити лише необхідні (після їх перегляду).
Встановлені додатки GitHub: Рекомендується дозволяти лише необхідні (після їх перегляду).
Для цього сценарію ми будемо припускати, що ви отримали доступ до облікового запису github.
Якщо ви якимось чином вже маєте облікові дані для користувача в організації, ви можете просто увійти і перевірити, які ролі підприємства та організації у вас є, якщо ви звичайний член, перевірте, які дозволи мають звичайні члени, в яких групах ви знаходитесь, які дозволи ви маєте над якими репозиторіями та як захищені репозиторії.
Зверніть увагу, що може використовуватися 2FA, тому ви зможете отримати доступ до цієї інформації лише якщо зможете пройти цю перевірку.
Зверніть увагу, що якщо ви вдасться вкрасти cookie user_session (в даний час налаштоване з SameSite: Lax), ви зможете повністю видати себе за користувача без необхідності в облікових даних або 2FA.
Перевірте розділ нижче про обхід захисту гілок, якщо це буде корисно.
Github дозволяє користувачам встановлювати SSH ключі, які будуть використовуватися як метод аутентифікації для розгортання коду від їх імені (2FA не застосовується).
З цим ключем ви можете виконувати зміни в репозиторіях, де у користувача є певні привілеї, однак ви не можете використовувати його для доступу до API github для перерахунку середовища. Однак ви можете перерахувати локальні налаштування, щоб отримати інформацію про репозиторії та користувача, до яких у вас є доступ:
Якщо користувач налаштував своє ім'я користувача як своє ім'я користувача github, ви можете отримати доступ до публічних ключів, які він налаштував у своєму обліковому записі за адресою https://github.com/<github_username>.keys, ви можете перевірити це, щоб підтвердити, що приватний ключ, який ви знайшли, може бути використаний.
SSH ключі також можуть бути налаштовані в репозиторіях як ключі розгортання. Будь-хто, хто має доступ до цього ключа, зможе запускати проекти з репозиторію. Зазвичай на сервері з різними ключами розгортання локальний файл ~/.ssh/config надасть вам інформацію про те, до якого ключа це відноситься.
Як пояснено тут, іноді потрібно підписувати коміти, інакше вас можуть виявити.
Перевірте локально, чи має поточний користувач будь-який ключ за допомогою:
Для введення про токени користувача перевірте основну інформацію.
Токен користувача може використовуватися замість пароля для Git через HTTPS або може бути використаний для автентифікації до API через базову автентифікацію. Залежно від привілеїв, які до нього прикріплені, ви можете виконувати різні дії.
Токен користувача виглядає так: ghp_EfHnQFcFHX6fGIu5mpduvRiYR584kK0dX123
Для введення про додатки Github Oauth перевірте основну інформацію.
Зловмисник може створити шкідливий Oauth-додаток для доступу до привілейованих даних/дій користувачів, які, ймовірно, приймуть їх як частину фішингової кампанії.
Це обсяги, які може запитувати Oauth-додаток. Завжди слід перевіряти запитувані обсяги перед їх прийняттям.
Більше того, як пояснено в основній інформації, організації можуть надавати/відмовляти в доступі стороннім додаткам до інформації/репозиторіїв/дій, пов'язаних з організацією.
Для введення про додатки Github перевірте основну інформацію.
Зловмисник може створити шкідливий додаток Github для доступу до привілейованих даних/дій користувачів, які, ймовірно, приймуть їх як частину фішингової кампанії.
Більше того, як пояснено в основній інформації, організації можуть надавати/відмовляти в доступі стороннім додаткам до інформації/репозиторіїв/дій, пов'язаних з організацією.
Існує кілька технік для компрометації та зловживання 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 буде спрацьовувати.
Зверніть увагу, що після створення гілки захист гілки буде застосовано до нової гілки і ви не зможете її змінити, але на той момент ви вже вивели секрети.
Генерувати токен користувача
Вкрасти токени github з секретів
Видалення результатів робочого процесу та гілок
Надати більше прав всій організації
Створити вебхуки для ексфільтрації інформації
Запросити зовнішніх співпрацівників
Видалити вебхуки, що використовуються SIEM
Створити/змінити Github Action з бекдором
Знайти вразливий Github Action для ін'єкції команд через модифікацію значення секрету
У Github можливо створити PR до репозиторію з форка. Навіть якщо PR не буде прийнято, ідентифікатор коміту всередині оригінального репозиторію буде створено для версії коду з форка. Тому, зловмисник може закріпити використання конкретного коміту з, здавалося б, легітимного репозиторію, який не був створений власником репозиторію.
Як цей:
Для отримання додаткової інформації перегляньте https://www.chainguard.dev/unchained/what-the-fork-imposter-commits-in-github-actions-and-ci-cd
Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
