Ukranian - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

Github Security

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

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

Що таке Github

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

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

pageBasic Github Information

Зовнішній рекон

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

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

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

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

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

Github Dorks

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

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

Витоки Github

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

Інструменти (кожен інструмент містить свій список регулярних виразів):

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

Зовнішні вілки

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

Захист організації

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

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

  • Базові дозволи: Учасники матимуть дозвіл Немає/Читати/Запис/Адміністратор над репозиторіями організації. Рекомендовано Немає або Читати.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • API-1, API-2

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

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

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

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

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

  • [API](https://docs.github.com/en/rest/actions/permissions#get-default-workflow-permissions-for-an-

Інтеграції

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

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

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

Рекон & Атаки, використовуючи облікові дані

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

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

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

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

Зверніть увагу, що якщо ви вдалося вкрасти куку user_session (наразі налаштовано з параметром SameSite: Lax), ви можете повністю видаавати себе за користувача без необхідності облікових даних або 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

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

pageAbusing Github Actions

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

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

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

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

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

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

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

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

  • Перехоплення PR: Ви можете змінити PR іншої людини, додаючи шкідливий код, схвалюючи отриманий PR самостійно та зливаючи все.

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

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

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

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

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

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

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

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 з заднім прохідним шлюзом

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

Підроблені коміти - Задній прохід через коміти репозиторію

У 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

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

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

PreviousPentesting CI/CD MethodologyNextAbusing Github Actions

Last updated