mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-26 20:54:14 -08:00
Translated ['src/pentesting-ci-cd/github-security/abusing-github-actions
This commit is contained in:
Translator
@@ -2,25 +2,35 @@
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Інструменти
|
||||
|
||||
Наступні інструменти корисні для знаходження робочих процесів Github Action і навіть для виявлення вразливих:
|
||||
|
||||
- [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)
|
||||
|
||||
## Основна інформація
|
||||
|
||||
На цій сторінці ви знайдете:
|
||||
|
||||
- **резюме всіх наслідків** для зловмисника, який зміг отримати доступ до Github Action
|
||||
- **резюме всіх впливів** зловмисника, який зміг отримати доступ до Github Action
|
||||
- Різні способи **отримати доступ до дії**:
|
||||
- Маючи **дозволи** на створення дії
|
||||
- Зловживання тригерами, пов'язаними з **pull request**
|
||||
- Зловживання **тригерами, пов'язаними з pull request**
|
||||
- Зловживання **іншими зовнішніми техніками доступу**
|
||||
- **Півотування** з уже скомпрометованого репозиторію
|
||||
- Нарешті, розділ про **техніки пост-експлуатації для зловживання дією зсередини** (оскільки згадані наслідки)
|
||||
- Нарешті, розділ про **техніки пост-експлуатації для зловживання дією зсередини** (викликані згаданими впливами)
|
||||
|
||||
## Резюме наслідків
|
||||
## Резюме впливів
|
||||
|
||||
Для введення про [**Github Actions перевірте основну інформацію**](../basic-github-information.md#github-actions).
|
||||
|
||||
Якщо ви можете **виконувати довільний код у GitHub Actions** в межах **репозиторію**, ви можете:
|
||||
|
||||
- **Викрасти секрети**, змонтовані до конвеєра, та **зловживати привілеями конвеєра** для отримання несанкціонованого доступу до зовнішніх платформ, таких як AWS та GCP.
|
||||
- **Викрасти секрети**, змонтовані в конвеєрі, і **зловживати привілеями конвеєра** для отримання несанкціонованого доступу до зовнішніх платформ, таких як AWS і GCP.
|
||||
- **Скомпрометувати розгортання** та інші **артефакти**.
|
||||
- Якщо конвеєр розгортає або зберігає активи, ви можете змінити кінцевий продукт, що дозволяє здійснити атаку на ланцюг постачання.
|
||||
- **Виконувати код у кастомних робітниках** для зловживання обчислювальною потужністю та півотування до інших систем.
|
||||
@@ -28,16 +38,16 @@
|
||||
|
||||
## GITHUB_TOKEN
|
||||
|
||||
Цей "**секрет**" (який походить з `${{ secrets.GITHUB_TOKEN }}` та `${{ github.token }}`) надається, коли адміністратор активує цю опцію:
|
||||
Цей "**секрет**" (який походить з `${{ secrets.GITHUB_TOKEN }}` і `${{ github.token }}`) надається, коли адміністратор активує цю опцію:
|
||||
|
||||
<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)
|
||||
Цей токен є тим самим, що і **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)
|
||||
|
||||
> [!WARNING]
|
||||
> Github повинен випустити [**потік**](https://github.com/github/roadmap/issues/74), який **дозволяє крос-репозиторний** доступ у GitHub, щоб репозиторій міг отримати доступ до інших внутрішніх репозиторіїв, використовуючи `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)
|
||||
Ви можете побачити можливі **дозволи** цього токена на: [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`
|
||||
@@ -141,9 +151,9 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
|
||||
## Дозволене виконання
|
||||
|
||||
> [!NOTE]
|
||||
> Це був би найпростіший спосіб скомпрометувати Github дії, оскільки цей випадок передбачає, що у вас є доступ до **створення нового репозиторію в організації** або є **права на запис у репозиторії**.
|
||||
> Це був би найпростіший спосіб скомпрометувати Github дії, оскільки цей випадок передбачає, що у вас є доступ до **створення нового репозиторію в організації** або є **права на запис у репозиторій**.
|
||||
>
|
||||
> Якщо ви в цьому сценарії, ви можете просто перевірити [техніки постексплуатації](#post-exploitation-techniques-from-inside-an-action).
|
||||
> Якщо ви в цій ситуації, ви можете просто перевірити [техніки постексплуатації](#post-exploitation-techniques-from-inside-an-action).
|
||||
|
||||
### Виконання з створення репозиторію
|
||||
|
||||
@@ -174,23 +184,23 @@ branches:
|
||||
|
||||
### `pull_request`
|
||||
|
||||
Тригер робочого процесу **`pull_request`** буде виконувати робочий процес щоразу, коли отримується запит на злиття з деякими винятками: за замовчуванням, якщо це **перше** співробітництво, деякий **керівник** повинен **схвалити** **виконання** робочого процесу:
|
||||
Тригер робочого процесу **`pull_request`** буде виконувати робочий процес щоразу, коли надходить запит на злиття з деякими винятками: за замовчуванням, якщо це **перший раз**, коли ви **співпрацюєте**, деякий **керівник** повинен **схвалити** **виконання** робочого процесу:
|
||||
|
||||
<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):
|
||||
|
||||
> За винятком `GITHUB_TOKEN`, **секрети не передаються виконавцю**, коли робочий процес запускається з **форкнутого** репозиторію. **`GITHUB_TOKEN` має права лише на читання** у запитах на злиття **з форкнутими репозиторіями**.
|
||||
> За винятком `GITHUB_TOKEN`, **секрети не передаються виконавцю** під час тригера робочого процесу з **форкнутого** репозиторію. **`GITHUB_TOKEN` має права лише на читання** у запитах на злиття **з форкнутого репозиторію**.
|
||||
|
||||
Зловмисник може змінити визначення Github Action, щоб виконати довільні дії та додати довільні дії. Однак він не зможе вкрасти секрети або перезаписати репозиторій через зазначені обмеження.
|
||||
|
||||
> [!CAUTION]
|
||||
> **Так, якщо зловмисник змінить у PR github action, який буде запущено, його Github Action буде використано, а не той, що з оригінального репозиторію!**
|
||||
> **Так, якщо зловмисник змінить у PR github action, який буде тригером, його Github Action буде використано, а не той, що з оригінального репозиторію!**
|
||||
|
||||
Оскільки зловмисник також контролює код, що виконується, навіть якщо немає секретів або прав на запис у `GITHUB_TOKEN`, зловмисник може, наприклад, **завантажити шкідливі артефакти**.
|
||||
|
||||
@@ -201,7 +211,7 @@ branches:
|
||||
Зверніть увагу, що тригер робочого процесу **`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/).
|
||||
|
||||
Це може виглядати так, ніби **виконуваний робочий процес** є тим, що визначено в **базі**, а **не в PR**, тому це **безпечно** використовувати **`pull_request_target`**, але є **кілька випадків, коли це не так**.
|
||||
Може здатися, що оскільки **виконуваний робочий процес** є тим, що визначено в **базі**, а **не в PR**, це **безпечно** використовувати **`pull_request_target`**, але є **кілька випадків, коли це не так**.
|
||||
|
||||
І цей тригер матиме **доступ до секретів**.
|
||||
|
||||
@@ -209,7 +219,7 @@ branches:
|
||||
|
||||
Тригер [**workflow_run**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run) дозволяє запустити робочий процес з іншого, коли він `завершено`, `запитано` або `в процесі`.
|
||||
|
||||
У цьому прикладі робочий процес налаштовано на виконання після завершення окремого робочого процесу "Запустити тести":
|
||||
У цьому прикладі робочий процес налаштовано на виконання після завершення окремого "Запустити тести" робочого процесу:
|
||||
```yaml
|
||||
on:
|
||||
workflow_run:
|
||||
@@ -217,7 +227,7 @@ workflows: [Run Tests]
|
||||
types:
|
||||
- completed
|
||||
```
|
||||
Крім того, відповідно до документації: Робочий процес, розпочатий подією `workflow_run`, може **доступатися до секретів і записувати токени, навіть якщо попередній робочий процес не був**.
|
||||
Більше того, відповідно до документації: Робочий процес, розпочатий подією `workflow_run`, може **доступати до секретів і записувати токени, навіть якщо попередній робочий процес не був**.
|
||||
|
||||
Такий робочий процес може бути атакований, якщо він **залежить** від **робочого процесу**, який може бути **запущений** зовнішнім користувачем через **`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**.
|
||||
@@ -230,18 +240,18 @@ TODO: Перевірити, чи при виконанні з `pull_request` в
|
||||
|
||||
## Зловживання виконанням з форку
|
||||
|
||||
Ми згадали всі способи, якими зовнішній атакуючий може змусити робочий процес GitHub виконуватися, тепер давайте розглянемо, як ці виконання, якщо погано налаштовані, можуть бути зловживані:
|
||||
Ми згадали всі способи, якими зовнішній атакуючий може змусити робочий процес github виконатися, тепер давайте розглянемо, як ці виконання, якщо погано налаштовані, можуть бути зловживані:
|
||||
|
||||
### Виконання недовіреного чекауту
|
||||
|
||||
У випадку **`pull_request`** робочий процес буде виконуватися в **контексті PR** (тому він виконає **код шкідливого PR**), але хтось повинен **спочатку його авторизувати**, і він буде виконуватися з деякими [обмеженнями](#pull_request).
|
||||
|
||||
У випадку робочого процесу, що використовує **`pull_request_target` або `workflow_run`**, який залежить від робочого процесу, що може бути запущений з **`pull_request_target` або `pull_request`**, код з оригінального репозиторію буде виконуватися, тому **атакуючий не може контролювати виконуваний код**.
|
||||
У випадку робочого процесу, що використовує **`pull_request_target` або `workflow_run`**, який залежить від робочого процесу, що може бути запущений з **`pull_request_target` або `pull_request`**, код з оригінального репозиторію буде виконано, тому **атакуючий не може контролювати виконуваний код**.
|
||||
|
||||
> [!CAUTION]
|
||||
> Однак, якщо **дія** має **явний чекаут PR**, який **отримає код з PR** (а не з бази), вона використовуватиме код, контрольований атакуючим. Наприклад (перевірте рядок 12, де завантажується код PR):
|
||||
> Однак, якщо **дія** має **явний чекаут PR**, який **отримає код з PR** (а не з бази), вона буде використовувати код, контрольований атакуючим. Наприклад (перевірте рядок 12, де завантажується код PR):
|
||||
|
||||
<pre class="language-yaml"><code class="lang-yaml"># INSECURE. Provided as an example only.
|
||||
<pre class="language-yaml"><code class="lang-yaml"># INSECURE. Наведено лише як приклад.
|
||||
on:
|
||||
pull_request_target
|
||||
|
||||
@@ -266,17 +276,17 @@ arg1: ${{ secrets.supersecret }}
|
||||
- uses: fakerepo/comment-on-pr@v1
|
||||
with:
|
||||
message: |
|
||||
Thank you!
|
||||
Дякую!
|
||||
</code></pre>
|
||||
|
||||
Потенційно **недовірений код виконується під час `npm install` або `npm build`**, оскільки скрипти збірки та посилання на **пакети контролюються автором PR**.
|
||||
Потенційно **недовірений код виконується під час `npm install` або `npm build`**, оскільки скрипти збірки та згадані **пакети контролюються автором PR**.
|
||||
|
||||
> [!WARNING]
|
||||
> GitHub dork для пошуку вразливих дій: `event.pull_request pull_request_target extension:yml`, однак існують різні способи налаштування робочих процесів для безпечного виконання, навіть якщо дія налаштована ненадійно (наприклад, використовуючи умовності про те, хто є актором, що генерує PR).
|
||||
> Github dork для пошуку вразливих дій: `event.pull_request pull_request_target extension:yml`, однак існують різні способи налаштування завдань для безпечного виконання, навіть якщо дія налаштована ненадійно (наприклад, використовуючи умовні оператори про те, хто є актором, що генерує PR).
|
||||
|
||||
### Впровадження скриптів у контексті <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 використовує ці **дані для виконання чого-небудь**, це може призвести до **виконання довільного коду:**
|
||||
Зверніть увагу, що є певні [**контексти github**](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
|
||||
@@ -284,21 +294,61 @@ gh-actions-context-script-injections.md
|
||||
|
||||
### **Впровадження скриптів GITHUB_ENV** <a href="#what-is-usdgithub_env" id="what-is-usdgithub_env"></a>
|
||||
|
||||
З документації: Ви можете зробити **змінну середовища доступною для будь-яких наступних кроків** у робочому процесі, визначивши або оновивши змінну середовища та записавши це у файл середовища **`GITHUB_ENV`**.
|
||||
З документації: Ви можете зробити **змінну середовища доступною для будь-яких наступних кроків** у завданні робочого процесу, визначивши або оновивши змінну середовища та записавши це у файл середовища **`GITHUB_ENV`**.
|
||||
|
||||
Якщо атакуючий може **впровадити будь-яке значення** в цю **змінну** середовища, він може впровадити змінні середовища, які можуть виконувати код у наступних кроках, такі як **LD_PRELOAD** або **NODE_OPTIONS**.
|
||||
Якщо атакуючий може **впровадити будь-яке значення** в цю **змінну** середовища, він може впровадити змінні середовища, які можуть виконати код у наступних кроках, таких як **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`**. Атакуючий може завантажити щось на зразок цього, щоб скомпрометувати його:
|
||||
|
||||
<figure><img src="../../../images/image (261).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### Вразливі сторонні дії GitHub
|
||||
### Dependabot та інші довірені боти
|
||||
|
||||
Як зазначено в [**цьому блозі**](https://boostsecurity.io/blog/weaponizing-dependabot-pwn-request-at-its-finest), кілька організацій мають Github Action, яка об'єднує будь-який PRR від `dependabot[bot]`, як у:
|
||||
```yaml
|
||||
on: pull_request_target
|
||||
jobs:
|
||||
auto-merge:
|
||||
runs-on: ubuntu-latest
|
||||
if: ${ { github.actor == 'dependabot[bot]' }}
|
||||
steps:
|
||||
- run: gh pr merge $ -d -m
|
||||
```
|
||||
Яка є проблема, оскільки поле `github.actor` містить користувача, який викликав останню подію, що активувала робочий процес. Існує кілька способів змусити користувача `dependabot[bot]` змінити PR. Наприклад:
|
||||
|
||||
- Форкнути репозиторій жертви
|
||||
- Додати шкідливий код до вашої копії
|
||||
- Увімкнути Dependabot у вашому форку, додавши застарілу залежність. Dependabot створить гілку, що виправляє залежність зі шкідливим кодом.
|
||||
- Відкрити Pull Request до репозиторію жертви з цієї гілки (PR буде створено користувачем, тому нічого ще не станеться)
|
||||
- Потім зловмисник повертається до початкового PR, який Dependabot відкрив у його форку, і виконує `@dependabot recreate`
|
||||
- Потім Dependabot виконує деякі дії в цій гілці, які змінюють PR у репозиторії жертви, що робить `dependabot[bot]` виконавцем останньої події, що активувала робочий процес (і, отже, робочий процес запускається).
|
||||
|
||||
Продовжуючи, що якби замість злиття Github Action мала б ін'єкцію команд, як у:
|
||||
```yaml
|
||||
on: pull_request_target
|
||||
jobs:
|
||||
just-printing-stuff:
|
||||
runs-on: ubuntu-latest
|
||||
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]` актором останньої події, яка викликала робочий процес, і використовуючи шкідливу назву гілки.
|
||||
|
||||
### Вразливі сторонні 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 дозволяє отримувати артефакти з різних робочих процесів і навіть репозиторіїв.
|
||||
Як згадувалося в [**цьому блогпості**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks), цей Github Action дозволяє отримувати артефакти з різних робочих процесів і навіть репозиторіїв.
|
||||
|
||||
Проблема в тому, що якщо параметр **`path`** не встановлений, артефакт витягується в поточний каталог, і він може перезаписати файли, які можуть бути пізніше використані або навіть виконані в робочому процесі. Тому, якщо артефакт вразливий, атакуючий може зловживати цим, щоб скомпрометувати інші робочі процеси, які довіряють артефакту.
|
||||
Проблема в тому, що якщо параметр **`path`** не встановлений, артефакт витягується в поточний каталог і може перезаписати файли, які можуть бути пізніше використані або навіть виконані в робочому процесі. Тому, якщо артефакт вразливий, зловмисник може зловживати цим, щоб скомпрометувати інші робочі процеси, які довіряють артефакту.
|
||||
|
||||
Приклад вразливого робочого процесу:
|
||||
```yaml
|
||||
@@ -349,14 +399,14 @@ path: ./script.py
|
||||
> [!CAUTION]
|
||||
> Тому, якщо дія використовує репозиторій з неіснуючого облікового запису, все ще можливо, що зловмисник може створити цей обліковий запис і скомпрометувати дію.
|
||||
|
||||
Якщо інші репозиторії використовували **залежності з репозиторіїв цього користувача**, зловмисник зможе їх викрасти. Тут ви маєте більш детальне пояснення: [https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/](https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/)
|
||||
Якщо інші репозиторії використовували **залежності з репозиторіїв цього користувача**, зловмисник зможе їх викрасти. Ось більш детальне пояснення: [https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/](https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/)
|
||||
|
||||
---
|
||||
|
||||
## Поворот репозиторію
|
||||
## Пивотинг репозиторію
|
||||
|
||||
> [!NOTE]
|
||||
> У цьому розділі ми поговоримо про техніки, які дозволять **поворот з одного репозиторію в інший**, припускаючи, що у нас є якийсь доступ до першого (перевірте попередній розділ).
|
||||
> У цьому розділі ми поговоримо про техніки, які дозволять **пивотити з одного репозиторію в інший**, припускаючи, що у нас є якийсь доступ до першого (перевірте попередній розділ).
|
||||
|
||||
### Отруєння кешу
|
||||
|
||||
@@ -464,13 +514,13 @@ with:
|
||||
key: ${{ secrets.PUBLISH_KEY }}
|
||||
```
|
||||
|
||||
### Зловживання самостійно хостованими виконавцями
|
||||
### Зловживання самостійно хостингованими виконавцями
|
||||
|
||||
Спосіб знайти, які **Github Actions виконуються в не-Github інфраструктурі**, - це шукати **`runs-on: self-hosted`** у конфігураційному yaml файлі Github Action.
|
||||
Спосіб знайти, які **Github Actions виконуються в не-Github інфраструктурі**, - це шукати **`runs-on: self-hosted`** в конфігураційному yaml файлі Github Action.
|
||||
|
||||
**Самостійно хостовані** виконавці можуть мати доступ до **додаткової чутливої інформації**, до інших **мережевих систем** (вразливі кінцеві точки в мережі? служба метаданих?) або, навіть якщо вони ізольовані та знищені, **більше ніж одна дія може виконуватися одночасно** і зловмисна може **викрасти секрети** іншої.
|
||||
**Самостійно хостинговані** виконавці можуть мати доступ до **додаткової чутливої інформації**, до інших **мережевих систем** (вразливі кінцеві точки в мережі? служба метаданих?) або, навіть якщо вони ізольовані та знищені, **може виконуватися більше однієї дії одночасно**, і зловмисна може **вкрасти секрети** іншої.
|
||||
|
||||
У самостійно хостованих виконавцях також можливо отримати **секрети з процесу \_Runner.Listener**\_\*\* який міститиме всі секрети робочих процесів на будь-якому етапі, скидаючи його пам'ять:
|
||||
У самостійно хостингованих виконавцях також можливо отримати **секрети з процесу \_Runner.Listener**\_\*\* який міститиме всі секрети робочих процесів на будь-якому етапі, скидаючи його пам'ять:
|
||||
```bash
|
||||
sudo apt-get install -y gdb
|
||||
sudo gcore -o k.dump "$(ps ax | grep 'Runner.Listener' | head -n 1 | awk '{ print $1 }')"
|
||||
@@ -517,7 +567,7 @@ ghcr.io/${{ github.repository_owner }}/${{ github.event.repository.name }}:${{ e
|
||||
|
||||
Як ви могли бачити в попередньому коді, реєстр Github розміщений на **`ghcr.io`**.
|
||||
|
||||
Користувач з правами читання над репозиторієм зможе завантажити Docker Image, використовуючи особистий токен доступу:
|
||||
Користувач з правами на читання репозиторію зможе завантажити Docker Image, використовуючи особистий токен доступу:
|
||||
```bash
|
||||
echo $gh_token | docker login ghcr.io -u <username> --password-stdin
|
||||
docker pull ghcr.io/<org-name>/<repo_name>:<tag>
|
||||
@@ -534,20 +584,11 @@ https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forens
|
||||
|
||||
## Приховування своїх слідів
|
||||
|
||||
(Техніка з [**тут**](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)
|
||||
(Техніка з [**тут**](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)
|
||||
|
||||
Організація в GitHub дуже активно повідомляє про облікові записи в GitHub. Все, що вам потрібно зробити, це поділитися "деякими речами" в Issue, і вони подбають про те, щоб ваш обліковий запис був припинений за 12 годин :p і ось, ви зробили свою експлуатацію невидимою на github.
|
||||
Організація в GitHub дуже активно повідомляє про облікові записи в GitHub. Все, що вам потрібно зробити, це поділитися "деякими речами" в Issue, і вони подбають про те, щоб ваш обліковий запис був припинений протягом 12 годин :p і ось, ви зробили свою експлуатацію невидимою на github.
|
||||
|
||||
> [!WARNING]
|
||||
> Єдиний спосіб для організації дізнатися, що вони стали мішенню, - це перевірити журнали GitHub з SIEM, оскільки з інтерфейсу GitHub PR буде видалено.
|
||||
|
||||
## Інструменти
|
||||
|
||||
Наступні інструменти корисні для знаходження робочих процесів Github Action і навіть для знаходження вразливих:
|
||||
|
||||
- [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)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
Reference in New Issue
Block a user