mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-26 20:54:14 -08:00
Translated ['src/banners/hacktricks-training.md', 'src/pentesting-ci-cd/
This commit is contained in:
Translator
@@ -9,10 +9,10 @@
|
||||
- **резюме всіх впливів** атаки, якщо зловмисник зможе отримати доступ до Github Action
|
||||
- Різні способи **отримати доступ до дії**:
|
||||
- Маючи **дозволи** на створення дії
|
||||
- Зловживання **тригерами, пов'язаними з pull request**
|
||||
- Зловживання тригерами, пов'язаними з **pull request**
|
||||
- Зловживання **іншими зовнішніми техніками доступу**
|
||||
- **Півотування** з уже скомпрометованого репозиторію
|
||||
- Нарешті, розділ про **техніки пост-експлуатації для зловживання дією зсередини** (щоб викликати згадані впливи)
|
||||
- **Півотинг** з уже скомпрометованого репозиторію
|
||||
- Нарешті, розділ про **техніки пост-експлуатації для зловживання дією зсередини** (оскільки згадані впливи)
|
||||
|
||||
## Резюме впливів
|
||||
|
||||
@@ -20,10 +20,10 @@
|
||||
|
||||
Якщо ви можете **виконувати довільний код у GitHub Actions** в межах **репозиторію**, ви можете:
|
||||
|
||||
- **Викрасти секрети**, змонтовані до конвеєра, та **зловживати привілеями конвеєра** для отримання несанкціонованого доступу до зовнішніх платформ, таких як AWS та GCP.
|
||||
- **Викрасти секрети**, змонтовані в конвеєрі, та **зловживати привілеями конвеєра** для отримання несанкціонованого доступу до зовнішніх платформ, таких як AWS та GCP.
|
||||
- **Скомпрометувати розгортання** та інші **артефакти**.
|
||||
- Якщо конвеєр розгортає або зберігає активи, ви можете змінити кінцевий продукт, що дозволяє здійснити атаку на ланцюг постачання.
|
||||
- **Виконувати код у кастомних робітниках** для зловживання обчислювальною потужністю та півотування до інших систем.
|
||||
- **Виконувати код у кастомних робітниках** для зловживання обчислювальною потужністю та півотингу до інших систем.
|
||||
- **Перезаписати код репозиторію**, залежно від дозволів, пов'язаних з `GITHUB_TOKEN`.
|
||||
|
||||
## GITHUB_TOKEN
|
||||
@@ -32,10 +32,10 @@
|
||||
|
||||
<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`.
|
||||
> 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)
|
||||
|
||||
@@ -134,7 +134,7 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
|
||||
```
|
||||
</details>
|
||||
|
||||
Можливо перевірити дозволи, надані Github Token в репозиторіях інших користувачів, **перевіряючи журнали** дій:
|
||||
Можна перевірити дозволи, надані Github Token в репозиторіях інших користувачів, **перевіряючи журнали** дій:
|
||||
|
||||
<figure><img src="../../../images/image (286).png" alt="" width="269"><figcaption></figcaption></figure>
|
||||
|
||||
@@ -143,7 +143,7 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
|
||||
> [!NOTE]
|
||||
> Це був би найпростіший спосіб скомпрометувати Github дії, оскільки цей випадок передбачає, що у вас є доступ до **створення нового репозиторію в організації** або є **права на запис у репозиторії**.
|
||||
>
|
||||
> Якщо ви в цій ситуації, ви можете просто перевірити [техніки постексплуатації](./#post-exploitation-techniques-from-inside-an-action).
|
||||
> Якщо ви в цьому сценарії, ви можете просто перевірити [техніки постексплуатації](./#post-exploitation-techniques-from-inside-an-action).
|
||||
|
||||
### Виконання з створення репозиторію
|
||||
|
||||
@@ -167,14 +167,14 @@ branches:
|
||||
```
|
||||
---
|
||||
|
||||
## Forked Execution
|
||||
## Витягнуте виконання
|
||||
|
||||
> [!NOTE]
|
||||
> Існують різні тригери, які можуть дозволити зловмиснику **виконати Github Action з іншого репозиторію**. Якщо ці тригери налаштовані неналежним чином, зловмисник може зуміти їх скомпрометувати.
|
||||
|
||||
### `pull_request`
|
||||
|
||||
Тригер робочого процесу **`pull_request`** буде виконувати робочий процес щоразу, коли отримується запит на злиття з деякими винятками: за замовчуванням, якщо це **перше** співробітництво, деякий **керівник** повинен **схвалити** **виконання** робочого процесу:
|
||||
Тригер робочого процесу **`pull_request`** буде виконувати робочий процес щоразу, коли отримується запит на злиття з деякими винятками: за замовчуванням, якщо це **перший раз**, коли ви **співпрацюєте**, деякий **керівник** повинен **схвалити** **виконання** робочого процесу:
|
||||
|
||||
<figure><img src="../../../images/image (184).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
@@ -185,12 +185,12 @@ branches:
|
||||
|
||||
Більше того, за замовчуванням **запобігає запису прав** і **доступу до секретів** цільового репозиторію, як зазначено в [**документації**](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`, зловмисник може, наприклад, **завантажити шкідливі артефакти**.
|
||||
|
||||
@@ -198,7 +198,7 @@ branches:
|
||||
|
||||
Тригер робочого процесу **`pull_request_target`** має **права на запис** до цільового репозиторію та **доступ до секретів** (і не запитує дозволу).
|
||||
|
||||
Зверніть увагу, що тригер робочого процесу **`pull_request_target`** **виконується в базовому контексті** і не в контексті, наданому PR (щоб **не виконувати ненадійний код**). Для отримання додаткової інформації про `pull_request_target` [**перевірте документацію**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target).\
|
||||
Зверніть увагу, що тригер робочого процесу **`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`**, але є **кілька випадків, коли це не так**.
|
||||
@@ -209,7 +209,7 @@ branches:
|
||||
|
||||
Тригер [**workflow_run**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run) дозволяє запустити робочий процес з іншого, коли він `завершено`, `запитано` або `в процесі`.
|
||||
|
||||
У цьому прикладі робочий процес налаштовано на виконання після завершення окремого робочого процесу "Запустити тести":
|
||||
У цьому прикладі робочий процес налаштовано на виконання після завершення окремого "Запустити тести" робочого процесу:
|
||||
```yaml
|
||||
on:
|
||||
workflow_run:
|
||||
@@ -217,10 +217,10 @@ workflows: [Run Tests]
|
||||
types:
|
||||
- completed
|
||||
```
|
||||
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_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**.
|
||||
Такий робочий процес може бути атакований, якщо він **залежить** від **робочого процесу**, який може бути **запущений** зовнішнім користувачем через **`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_call`
|
||||
|
||||
@@ -230,18 +230,18 @@ TODO: Перевірити, чи при виконанні з `pull_request` в
|
||||
|
||||
## Зловживання виконанням з форку
|
||||
|
||||
Ми згадали всі способи, якими зовнішній атакуючий може змусити робочий процес github виконатися, тепер давайте подивимося, як ці виконання, якщо погано налаштовані, можуть бути зловживані:
|
||||
Ми згадали всі способи, якими зовнішній атакуючий може змусити робочий процес github виконатися, тепер давайте розглянемо, як ці виконання, якщо погано налаштовані, можуть бути зловживані:
|
||||
|
||||
### Виконання недовіреного чекауту
|
||||
|
||||
У випадку **`pull_request`,** робочий процес буде виконуватися в **контексті PR** (тому він виконає **код шкідливого PR**), але хтось повинен **спочатку його авторизувати**, і він буде виконуватися з деякими [обмеженнями](./#pull_request).
|
||||
У випадку **`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"># НЕБЕЗПЕЧНО. Наведено лише як приклад.
|
||||
on:
|
||||
pull_request_target
|
||||
|
||||
@@ -266,15 +266,15 @@ 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>
|
||||
### Впровадження скриптів у контексті <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 використовує ці **дані для виконання чого-небудь**, це може призвести до **випадкового виконання коду:**
|
||||
|
||||
@@ -284,21 +284,21 @@ 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`**. Атакуючий може завантажити щось на зразок цього, щоб скомпрометувати його:
|
||||
Наприклад ([**це**](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
|
||||
### Вразливі дії третьої сторони Github
|
||||
|
||||
#### [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 дозволяє отримувати артефакти з різних робочих процесів і навіть репозиторіїв.
|
||||
|
||||
Проблема в тому, що якщо параметр **`path`** не встановлений, артефакт витягується в поточний каталог і може перезаписати файли, які можуть бути пізніше використані або навіть виконані в робочому процесі. Тому, якщо артефакт вразливий, атакуючий може зловживати цим, щоб скомпрометувати інші робочі процеси, які довіряють артефакту.
|
||||
Проблема в тому, що якщо параметр **`path`** не встановлений, артефакт витягується в поточний каталог, і він може перезаписати файли, які можуть бути пізніше використані або навіть виконані в робочому процесі. Тому, якщо артефакт вразливий, атакуючий може зловживати цим, щоб скомпрометувати інші робочі процеси, які довіряють артефакту.
|
||||
|
||||
Приклад вразливого робочого процесу:
|
||||
```yaml
|
||||
@@ -323,7 +323,7 @@ with:
|
||||
name: artifact
|
||||
path: ./script.py
|
||||
```
|
||||
Це можна атакувати за допомогою цього робочого процесу:
|
||||
Це може бути атаковано за допомогою цього робочого процесу:
|
||||
```yaml
|
||||
name: "some workflow"
|
||||
on: pull_request
|
||||
@@ -344,19 +344,19 @@ path: ./script.py
|
||||
|
||||
### Викрадення видаленого репозиторію простору імен
|
||||
|
||||
Якщо обліковий запис змінює своє ім'я, інший користувач може зареєструвати обліковий запис з цим ім'ям через деякий час. Якщо репозиторій мав **менше 100 зірок до зміни імені**, Github дозволить новому зареєстрованому користувачу з таким же ім'ям створити **репозиторій з таким же ім'ям**, як той, що був видалений.
|
||||
Якщо обліковий запис змінює своє ім'я, інший користувач може зареєструвати обліковий запис з цим ім'ям через деякий час. Якщо репозиторій мав **менше 100 зірок до зміни імені**, Github дозволить новому зареєстрованому користувачу з таким же ім'ям створити **репозиторій з таким же ім'ям**, як і той, що був видалений.
|
||||
|
||||
> [!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]
|
||||
> У цьому розділі ми поговоримо про техніки, які дозволять **пивотити з одного репозиторію в інший**, припускаючи, що у нас є якийсь доступ до першого (перевірте попередній розділ).
|
||||
> У цьому розділі ми поговоримо про техніки, які дозволять **поворот з одного репозиторію в інший**, припускаючи, що у нас є якийсь доступ до першого (перевірте попередній розділ).
|
||||
|
||||
### Отруєння кешу
|
||||
|
||||
@@ -421,8 +421,6 @@ secret_myql_pass: ${{secrets.MYSQL_PASSWORD}}
|
||||
|
||||
secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
|
||||
```
|
||||
</details>
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Отримати зворотний шелл з секретами</summary>
|
||||
@@ -464,13 +462,13 @@ with:
|
||||
key: ${{ secrets.PUBLISH_KEY }}
|
||||
```
|
||||
|
||||
### Зловживання самостійно розгорнутими виконавцями
|
||||
### Зловживання самостійно хостованими виконавцями
|
||||
|
||||
Спосіб знайти, які **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 }')"
|
||||
@@ -530,11 +528,11 @@ https://book.hacktricks.xyz/generic-methodologies-and-resources/basic-forensic-m
|
||||
|
||||
### Чутлива інформація в журналах Github Actions
|
||||
|
||||
Навіть якщо **Github** намагається **виявити секретні значення** в журналах дій і **уникнути їх відображення**, **інша чутлива інформація**, яка могла бути згенерована під час виконання дії, не буде прихована. Наприклад, JWT, підписаний секретним значенням, не буде прихований, якщо його не [налаштувати спеціально](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret).
|
||||
Навіть якщо **Github** намагається **виявити секретні значення** в журналах дій і **уникнути їх відображення**, **інша чутлива інформація**, яка могла бути згенерована під час виконання дії, не буде прихована. Наприклад, JWT, підписаний секретним значенням, не буде прихований, якщо його не [налаштовано спеціально](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)
|
||||
(Техніка з [**тут**](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.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user