Translated ['src/pentesting-ci-cd/cloudflare-security/cloudflare-domains

2026-01-12 13:05:19 -08:00 · 2025-01-11 19:05:51 +00:00
parent 06ae0ca85c
commit 652d8299d6
44 changed files with 2150 additions and 515 deletions
--- a/src/pentesting-ci-cd/cloudflare-security/cloudflare-domains.md
+++ b/src/pentesting-ci-cd/cloudflare-security/cloudflare-domains.md
@@ -22,9 +22,9 @@ Cloudflareに設定された各TLDには、いくつかの**一般設定とサ
 - [ ] **プロキシされていない**ウェブページを確認する
 - [ ] CNAMEまたはIPアドレスで**直接アクセス可能な**プロキシ化されたウェブページを確認する
 - [ ] **DNSSEC**が**有効**であることを確認する
- [ ] **すべてのCNAMEでCNAMEフラッティング**が**使用**されていることを確認する
+- [ ] **すべてのCNAMEでCNAMEフラッティングが使用されている**ことを確認する
 - これは**サブドメインの乗っ取り脆弱性を隠す**のに役立ち、読み込み時間を改善します
- [ ] ドメインが[**スプーフィングに対して脆弱でないこと**](https://book.hacktricks.xyz/network-services-pentesting/pentesting-smtp#mail-spoofing)を確認する
+- [ ] ドメインが[**スプーフィングに対して脆弱でない**](https://book.hacktricks.wiki/en/network-services-pentesting/pentesting-smtp/index.html#mail-spoofing)ことを確認する

 ### **メール**

@@ -38,7 +38,7 @@ TODO

 #### **概要**

- [ ] **SSL/TLS暗号化**は**フル**または**フル（厳格）**であるべきです。他の設定では、いずれかの時点で**平文トラフィック**が送信されます。
+- [ ] **SSL/TLS暗号化**は**フル**または**フル（厳格）**であるべきです。それ以外は、いずれかの時点で**平文トラフィック**を送信します。
 - [ ] **SSL/TLS推奨設定**が有効であるべきです

 #### エッジ証明書
@@ -52,7 +52,7 @@ TODO

 ### **セキュリティ**

- [ ] **`WAF`**セクションでは、**ファイアウォール**と**レート制限ルールが使用されているか**確認することが興味深いです。
+- [ ] **`WAF`**セクションでは、**ファイアウォール**と**レート制限ルールが使用されている**か確認することが興味深いです。
 - **`バイパス`**アクションは、リクエストに対して**Cloudflareのセキュリティ**機能を**無効**にします。使用すべきではありません。
 - [ ] **`ページシールド`**セクションでは、ページが使用されている場合は**有効**であることを確認することをお勧めします
 - [ ] **`APIシールド`**セクションでは、CloudflareでAPIが公開されている場合は**有効**であることを確認することをお勧めします
@@ -65,17 +65,17 @@ TODO

 #### **CloudFlare DDoS保護**

- 可能であれば、**ボットファイトモード**または**スーパーボットファイトモード**を有効にしてください。プログラム的にアクセスされるAPIを保護している場合（例えば、JSフロントエンドページから）。そのアクセスを壊さずにこれを有効にできないかもしれません。
- **WAF**では、**URLパスによるレート制限**を作成したり、**確認済みボット**に対して（レート制限ルール）、または**IP、クッキー、リファラー**に基づいて**アクセスをブロック**することができます。したがって、ウェブページから来ないリクエストやクッキーを持たないリクエストをブロックできます。
- 攻撃が**確認済みボット**からの場合、少なくとも**ボットに対してレート制限を追加**してください。
- 攻撃が**特定のパス**に対するものであれば、予防策としてこのパスに**レート制限を追加**してください。
+- 可能であれば、**ボットファイトモード**または**スーパーボットファイトモード**を有効にします。プログラム的にアクセスされるAPIを保護している場合（例えば、JSフロントエンドページから）。そのアクセスを壊さずにこれを有効にできないかもしれません。
+- **WAF**では、**URLパスによるレート制限**を作成することができます（レート制限ルール）、または**IP、クッキー、リファラー**に基づいて**アクセスをブロック**することができます。したがって、ウェブページから来ないリクエストやクッキーを持たないリクエストをブロックできます。
+- 攻撃が**確認済みのボット**からの場合、少なくとも**ボットにレート制限を追加**します。
+- 攻撃が**特定のパス**に対するものである場合、予防策としてこのパスに**レート制限を追加**します。
 - **ツール**からIPアドレス、IP範囲、国、またはASNを**ホワイトリスト**に追加することもできます。
- **管理ルール**が脆弱性の悪用を防ぐのに役立つかどうか確認してください。
- **ツール**セクションでは、特定のIPや**ユーザーエージェント**に対して**ブロックまたはチャレンジを与える**ことができます。
- DDoSでは、**いくつかのルールを上書きしてより制限的にする**ことができます。
- **設定**：**セキュリティレベル**を**高**に設定し、**攻撃中**の場合は**攻撃中**に設定し、**ブラウザ整合性チェックが有効**であることを確認してください。
- Cloudflare Domains -> Analytics -> Security -> **レート制限**が有効か確認する
- Cloudflare Domains -> Security -> Events -> **検出された悪意のあるイベント**を確認する
+- **管理ルール**が脆弱性の悪用を防ぐのに役立つかどうか確認します。
+- **ツール**セクションでは、特定のIPやユーザーエージェントに**ブロックまたはチャレンジを与える**ことができます。
+- DDoSでは、**いくつかのルールをオーバーライドしてより制限的にする**ことができます。
+- **設定**：**セキュリティレベル**を**高**に設定し、**攻撃中**の場合は**攻撃中**に設定し、**ブラウザ整合性チェックが有効**であることを確認します。
+- Cloudflare Domains -> Analytics -> Security -> **レート制限**が有効か確認します
+- Cloudflare Domains -> Security -> Events -> **検出された悪意のあるイベント**を確認します

 ### アクセス

@@ -89,11 +89,11 @@ _セキュリティに関連するオプションは見つかりませんでし

 ### キャッシング

- [ ] **`設定`**セクションで**CSAMスキャンツール**を有効にすることを検討してください
+- [ ] **`設定`**セクションで**CSAMスキャンツール**を有効にすることを検討します

 ### **ワーカーズルート**

-_すでに_ [_cloudflare workers_](./#workers) _を確認しているはずです_
+_すでに_ [_cloudflare workers_](#workers) _を確認しているはずです_

 ### ルール

@@ -103,7 +103,7 @@ TODO

 - [ ] **`HTTP/2`**が**有効**であれば、**`HTTP/2 to Origin`**も**有効**であるべきです
 - [ ] **`HTTP/3 (with QUIC)`**が**有効**であるべきです
- [ ] **ユーザー**の**プライバシー**が重要であれば、**`オニオンルーティング`**が**有効**であることを確認してください
+- [ ] **ユーザーのプライバシー**が重要な場合、**`オニオンルーティング`**が**有効**であることを確認します

 ### **トラフィック**

@@ -111,7 +111,7 @@ TODO

 ### カスタムページ

- [ ] セキュリティに関連するエラーが発生した場合（ブロック、レート制限、または攻撃中モードなど）にカスタムページを構成することはオプションです
+- [ ] セキュリティに関連するエラーが発生した場合（ブロック、レート制限、または攻撃中モードなど）、カスタムページを設定することはオプションです

 ### アプリ

--- a/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md
+++ b/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md
@@ -16,9 +16,9 @@

 ## 影響の概要

-[**Github Actionsの基本情報を確認する**](../basic-github-information.md#github-actions)についての紹介。
+[**Github Actionsの基本情報**](../basic-github-information.md#github-actions)についての紹介。

-**リポジトリ内でGitHub Actionsに任意のコードを実行できる**場合、次のことができるかもしれません：
+**リポジトリ内でGitHub Actionsで任意のコードを実行できる**場合、次のことができるかもしれません：

 - パイプラインにマウントされた**シークレットを盗む**ことができ、**パイプラインの権限を悪用**して、AWSやGCPなどの外部プラットフォームに不正アクセスすることができます。
 - **デプロイメント**や他の**アーティファクトを侵害**することができます。
@@ -56,7 +56,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 \
@@ -67,7 +67,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 \
@@ -141,9 +141,9 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
 ## 許可された実行

 > [!NOTE]
-> これはGithubアクションを危険にさらす最も簡単な方法であり、このケースは**組織内に新しいリポジトリを作成するアクセス権**を持っているか、**リポジトリに対する書き込み権限**を持っていることを前提としています。
+> これはGithubアクションを危険にさらす最も簡単な方法です。このケースでは、**組織内に新しいリポジトリを作成するアクセス権**があるか、**リポジトリに対する書き込み権限**があることを前提としています。
 >
-> このシナリオにいる場合は、[Post Exploitation techniques](./#post-exploitation-techniques-from-inside-an-action)を確認するだけです。
+> このシナリオにいる場合は、[Post Exploitation techniques](#post-exploitation-techniques-from-inside-an-action)を確認するだけです。

 ### リポジトリ作成からの実行

@@ -151,9 +151,9 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}

 ### 新しいブランチからの実行

-既にGithubアクションが設定されているリポジトリで**新しいブランチを作成できる**場合、**それを修正し、**コンテンツを**アップロード**し、その後**新しいブランチからそのアクションを実行**することができます。この方法で、**リポジトリおよび組織レベルのシークレットを抽出**することができます（ただし、それらがどのように呼ばれているかを知っている必要があります）。
+既にGithubアクションが設定されているリポジトリで**新しいブランチを作成できる**場合、**それを修正し、**コンテンツを**アップロード**し、その後**新しいブランチからそのアクションを実行**することができます。この方法で、**リポジトリおよび組織レベルのシークレットを外部に持ち出す**ことができます（ただし、どのように呼ばれているかを知っている必要があります）。

-修正されたアクションを**手動で**実行可能にすることができます。**PRが作成されたとき**や**コードがプッシュされたとき**（どれだけ目立ちたいかによります）：
+修正されたアクションを**手動で**実行可能にすることができます。**PRが作成されたとき**や**コードがプッシュされたとき**（どれだけ目立ちたくないかによります）：
 ```yaml
 on:
 workflow_dispatch: # Launch manually
@@ -170,7 +170,7 @@ branches:
 ## フォークされた実行

 > [!NOTE]
-> 攻撃者が**他のリポジトリのGithub Actionを実行する**ことを可能にする異なるトリガーがあります。これらのトリガー可能なアクションが不適切に構成されている場合、攻撃者はそれらを妥協させることができるかもしれません。
+> 攻撃者が**他のリポジトリのGithub Actionを実行する**ことを許可する異なるトリガーがあります。これらのトリガー可能なアクションが不適切に構成されている場合、攻撃者はそれらを妥協することができるかもしれません。

 ### `pull_request`

@@ -179,18 +179,18 @@ branches:
 <figure><img src="../../../images/image (184).png" alt=""><figcaption></figcaption></figure>

 > [!NOTE]
-> **デフォルトの制限**は**初めての**貢献者に対してのものであるため、**有効なバグ/タイプミスを修正する**ことで貢献し、その後**新しい`pull_request`権限を悪用するために他のPRを送信する**ことができます。
+> **デフォルトの制限**は**初めての**貢献者に対して適用されるため、**有効なバグ/タイプミスを修正する**ことで貢献し、その後**新しい`pull_request`権限を悪用するために他のPRを送信する**ことができます。
 >
-> **これをテストしましたが、うまくいきませんでした**：~~別のオプションは、プロジェクトに貢献した誰かの名前でアカウントを作成し、そのアカウントを削除することです。~~
+> **これをテストしましたが、機能しませんでした**：~~別のオプションは、プロジェクトに貢献した誰かの名前でアカウントを作成し、そのアカウントを削除することです。~~

 さらに、デフォルトでは**書き込み権限**と**シークレットアクセス**をターゲットリポジトリに対して防ぎます。これは[**ドキュメント**](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,18 +198,18 @@ 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)。\
-さらに、この特定の危険な使用に関する詳細は、[**githubのブログ投稿を確認してください**](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/)。
+ワークフロートリガー**`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`を使用することは**安全**に見えるかもしれませんが、**安全でない場合がいくつかあります**。

-このトリガーは**シークレットへのアクセス**を持ちます。
+この場合、**シークレットへのアクセス**があります。

 ### `workflow_run`

 [**workflow_run**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run)トリガーは、別のワークフローが`completed`、`requested`、または`in_progress`のときにワークフローを実行することを許可します。

-この例では、ワークフローは別の「テストを実行」ワークフローが完了した後に実行されるように構成されています：
+この例では、ワークフローは、別の「テストを実行」ワークフローが完了した後に実行されるように構成されています：
 ```yaml
 on:
 workflow_run:
@@ -217,26 +217,26 @@ 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 }}`\
-2つ目の例は、**信頼できない**コードから**`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 }}`\
+2つ目の例は、**信頼できない**コードから**`workflow_run`**ワークフローに**アーティファクト**を**渡し**、このアーティファクトの内容を**RCEに対して脆弱**な方法で使用することです。

 ### `workflow_call`

 TODO

-TODO: `pull_request`から実行されたときに使用/ダウンロードされたコードが元のものであるかフォークされたPRのものであるかを確認する
+TODO: `pull_request`から実行された場合、使用/ダウンロードされたコードが元のものであるかフォークされたPRのものであるかを確認します。

 ## フォークされた実行の悪用

-外部の攻撃者が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からコードを取得する**（ベースからではなく）場合、攻撃者が制御するコードが使用されます。例えば（PRコードがダウンロードされる12行目を確認）：
@@ -272,11 +272,11 @@ Thank you!
 潜在的に**信頼できないコードは`npm install`または`npm build`の間に実行されます**。ビルドスクリプトと参照された**パッケージはPRの作者によって制御されています**。

 > [!WARNING]
-> 脆弱なアクションを検索するためのGitHubドークは：`event.pull_request pull_request_target extension:yml`ですが、アクションが不適切に構成されていても、ジョブを安全に実行するためのさまざまな方法があります（PRを生成するアクターについての条件を使用するなど）。
+> 脆弱なアクションを検索するためのGitHubドークは：`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アクションがその**データを使用して何かを実行する**場合、**任意のコード実行**につながる可能性があります：

 {{#ref}}
 gh-actions-context-script-injections.md
@@ -284,11 +284,11 @@ gh-actions-context-script-injections.md

 ### **GITHUB_ENVスクリプトインジェクション** <a href="#what-is-usdgithub_env" id="what-is-usdgithub_env"></a>

-ドキュメントによると：環境変数を定義または更新し、これを**`GITHUB_ENV`**環境ファイルに書き込むことで、ワークフロージョブの後続のステップで**環境変数を利用可能にする**ことができます。
+ドキュメントによると：環境変数を定義または更新し、これを**`GITHUB_ENV`**環境ファイルに書き込むことで、ワークフロージョブの後続のステップで利用可能にすることができます。

-攻撃者がこの**env**変数内に**任意の値を注入**できる場合、**LD_PRELOAD**や**NODE_OPTIONS**などのコードを実行する環境変数を注入することができます。
+攻撃者がこの**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`**環境変数に格納するワークフローを想像してください。攻撃者は、これを妥協するために次のようなものをアップロードすることができます：
+例えば、([**これ**](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>

@@ -298,7 +298,7 @@ gh-actions-context-script-injections.md

 [**このブログ投稿**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks)で述べたように、このGitHubアクションは、異なるワークフローやリポジトリからアーティファクトにアクセスすることを可能にします。

-問題は、**`path`**パラメータが設定されていない場合、アーティファクトが現在のディレクトリに抽出され、後で使用または実行される可能性のあるファイルを上書きできることです。したがって、アーティファクトが脆弱な場合、攻撃者はこれを悪用してアーティファクトを信頼する他のワークフローを妥協させることができます。
+問題は、**`path`**パラメータが設定されていない場合、アーティファクトが現在のディレクトリに抽出され、後で使用または実行される可能性のあるファイルを上書きできることです。したがって、アーティファクトが脆弱な場合、攻撃者はこれを悪用してアーティファクトを信頼する他のワークフローを妨害する可能性があります。

 脆弱なワークフローの例：
 ```yaml
@@ -341,6 +341,64 @@ path: ./script.py
 ---

 ## その他の外部アクセス
+
+### 削除された名前空間のリポジトリハイジャック
+
+アカウントが名前を変更すると、他のユーザーがその名前でアカウントを登録できるようになります。リポジトリが名前変更前に**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/)
+
+---
+
+## リポジトリピボティング
+
+> [!NOTE]
+> このセクションでは、最初のリポジトリに何らかのアクセス権があると仮定して、**1つのリポジトリから別のリポジトリにピボットする**技術について説明します（前のセクションを確認してください）。
+
+### キャッシュポイズニング
+
+キャッシュは**同じブランチ内のワークフロー実行間で維持されます**。つまり、攻撃者が**パッケージを妨害**し、それがキャッシュに保存され、**より特権のある**ワークフローによって**ダウンロード**および実行されると、そのワークフローも**妨害**される可能性があります。
+
+{{#ref}}
+gh-actions-cache-poisoning.md
+{{#endref}}
+
+### アーティファクトポイズニング
+
+ワークフローは**他のワークフローやリポジトリからのアーティファクト**を使用することができます。攻撃者が**アーティファクトをアップロードするGithub Actionを妨害**することに成功すれば、他のワークフローも**妨害**される可能性があります：
+
+{{#ref}}
+gh-actions-artifact-poisoning.md
+{{#endref}}
+
+---
+
+## アクションからのポストエクスプロイト
+
+### OIDCを介したAWSおよびGCPへのアクセス
+
+以下のページを確認してください：
+
+{{#ref}}
+../../../pentesting-cloud/aws-security/aws-basic-information/aws-federation-abuse.md
+{{#endref}}
+
+{{#ref}}
+../../../pentesting-cloud/gcp-security/gcp-basic-information/gcp-federation-abuse.md
+{{#endref}}
+
+### シークレットへのアクセス <a href="#accessing-secrets" id="accessing-secrets"></a>
+
+スクリプトにコンテンツを注入している場合、シークレットにアクセスする方法を知っておくと興味深いです：
+
+- シークレットまたはトークンが**環境変数**に設定されている場合、**`printenv`**を使用して環境を介して直接アクセスできます。
+
+<details>
+
+<summary>Github Action出力のシークレットをリストする</summary>
 ```yaml
 name: list_env
 on:
@@ -390,15 +448,15 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
 ```
 </details>

- シークレットが**式内で直接使用される**場合、生成されたシェルスクリプトは**ディスク上**に保存され、アクセス可能です。
+- 秘密が**式内で直接使用される**場合、生成されたシェルスクリプトは**ディスク上**に保存され、アクセス可能です。
 - ```bash
 cat /home/runner/work/_temp/*
 ```
- JavaScriptアクションの場合、シークレットは環境変数を通じて送信されます。
+- JavaScriptアクションの場合、秘密は環境変数を通じて送信されます。
 - ```bash
 ps axe | grep node
 ```
- **カスタムアクション**の場合、リスクはプログラムが**引数**から取得したシークレットをどのように使用するかによって異なります：
+- **カスタムアクション**の場合、秘密を取得したプログラムの使用方法によってリスクが異なる可能性があります：

 ```yaml
 uses: fakeaction/publish@v3
@@ -408,16 +466,16 @@ key: ${{ secrets.PUBLISH_KEY }}

 ### セルフホストランナーの悪用

-**Github Actionsが非Githubインフラストラクチャで実行されている**かを見つける方法は、Github Actionの設定yaml内で**`runs-on: self-hosted`**を検索することです。
+**Github Actions**が非Githubインフラストラクチャで実行されているかを見つける方法は、Github Action構成yaml内で**`runs-on: self-hosted`**を検索することです。

-**セルフホスト**ランナーは、**追加の機密情報**や他の**ネットワークシステム**（ネットワーク内の脆弱なエンドポイント？メタデータサービス？）にアクセスできる可能性があります。また、隔離されて破壊されていても、**同時に複数のアクションが実行される可能性**があり、悪意のあるアクションが他のアクションの**シークレットを盗む**ことができます。
+**セルフホスト**ランナーは、**追加の機密情報**や他の**ネットワークシステム**（ネットワーク内の脆弱なエンドポイント？メタデータサービス？）にアクセスできる可能性があります。また、隔離されて破壊されていても、**同時に複数のアクションが実行される可能性**があり、悪意のあるアクションが他のアクションの**秘密を盗む**ことができます。

-セルフホストランナーでは、**\_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 }')"
 ```
-[**この投稿で詳細情報を確認してください**](https://karimrahal.com/2023/01/05/github-actions-leaking-secrets/)。
+チェック [**こちらの投稿で詳細情報を確認してください**](https://karimrahal.com/2023/01/05/github-actions-leaking-secrets/)。

 ### Github Docker Images Registry

@@ -426,7 +484,7 @@ Github内に**Dockerイメージをビルドして保存する**Githubアクシ

 <details>

-<summary>Github Action Build &#x26; Push Docker Image</summary>
+<summary>Github Action Build & Push Docker Image</summary>
 ```yaml
 [...]

@@ -464,21 +522,21 @@ ghcr.io/${{ github.repository_owner }}/${{ github.event.repository.name }}:${{ e
 echo $gh_token | docker login ghcr.io -u <username> --password-stdin
 docker pull ghcr.io/<org-name>/<repo_name>:<tag>
 ```
-その後、ユーザーは**Dockerイメージのレイヤー内の漏洩した秘密**を検索できます：
+その後、ユーザーは**Dockerイメージのレイヤー内の漏洩した秘密を検索することができます：**

 {{#ref}}
-https://book.hacktricks.xyz/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics
+https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics.html
 {{#endref}}

 ### 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上で見えなくなります。
+GitHubの組織は、アカウントをGitHubに報告することに非常に積極的です。必要なのは、Issueに「いくつかのもの」を共有するだけで、彼らはあなたのアカウントが12時間以内に停止されることを確実にします :p これで、あなたのエクスプロイトはGitHub上で見えなくなります。

 > [!WARNING]
 > 組織がターゲットにされたことを把握する唯一の方法は、GitHub UIからPRが削除されるため、SIEMからGitHubログを確認することです。