mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-07-29 07:00:29 -07:00
Translated ['', 'src/pentesting-ci-cd/circleci-security.md', 'src/pentes
This commit is contained in:
@@ -4,7 +4,7 @@
|
||||
|
||||
## IAM
|
||||
|
||||
IAMに関する詳細は以下を参照してください:
|
||||
IAM についての詳細は以下を参照:
|
||||
|
||||
{{#ref}}
|
||||
../gcp-services/gcp-iam-and-org-policies-enum.md
|
||||
@@ -12,16 +12,16 @@ IAMに関する詳細は以下を参照してください:
|
||||
|
||||
### `iam.roles.update` (`iam.roles.get`)
|
||||
|
||||
上記の権限を持つattackerは、あなたに割り当てられたロールを更新し、他のリソースに対する追加の権限をあなたに付与できるようになります:
|
||||
前述の権限を持つ attacker は、あなたに割り当てられた role を更新し、次のような他の resource への追加権限を付与できます:
|
||||
```bash
|
||||
gcloud iam roles update <rol name> --project <project> --add-permissions <permission>
|
||||
```
|
||||
vuln environment の creation、exploit、および cleaning を自動化するスクリプトは **こちら** にあり、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/) をご覧ください。
|
||||
この脆弱な環境の**作成、exploit、クリーンアップを自動化するスクリプトはこちら**、またこの権限を悪用する python スクリプトは[**ここ**](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/)を確認してください。
|
||||
```bash
|
||||
gcloud iam roles update <Rol_NAME> --project <PROJECT_ID> --add-permissions <Permission>
|
||||
```
|
||||
### `iam.roles.create` & `iam.serviceAccounts.setIamPolicy`
|
||||
`iam.roles.create` の権限は、プロジェクトや組織内でカスタムロールを作成できるようにします。攻撃者の手に渡ると危険で、後にエンティティに割り当てられる(例えば `iam.serviceAccounts.setIamPolicy` 権限を使用して)ことで権限昇格を目的とした新しい権限セットを定義できてしまいます。
|
||||
iam.roles.create 権限は、project/organization 内で custom roles を作成することを許可します。攻撃者の手に渡ると、これは危険です。なぜなら、後で entity に割り当て可能な新しい permissions のセットを定義できるようになるためです(たとえば、iam.serviceAccounts.setIamPolicy 権限を使用して)。その目的は privilege escalation です。
|
||||
```bash
|
||||
gcloud iam roles create <ROLE_ID> \
|
||||
--project=<PROJECT_ID> \
|
||||
@@ -31,9 +31,9 @@ gcloud iam roles create <ROLE_ID> \
|
||||
```
|
||||
### `iam.serviceAccounts.getAccessToken` (`iam.serviceAccounts.get`)
|
||||
|
||||
前述の権限を持つ攻撃者は、**Service Account に属する access token をリクエストできる**ため、自分より権限の高い Service Account の access token を取得できる可能性があります。
|
||||
前述の権限を持つ attacker は、**Service Account に属する access token を要求**できるため、こちらよりも高い権限を持つ Service Account の access token を要求することが可能です。
|
||||
|
||||
攻撃者制御下のコードが metadata service から **managed Vertex AI Agent Engine runtime token** を盗み、Vertex AI service agent として再利用するような **resource-driven** バリアントについては、次を参照してください:
|
||||
attacker-controlled code が metadata service から **managed Vertex AI Agent Engine runtime token** を盗み、それを Vertex AI service agent として再利用する **resource-driven** 変種については、以下を確認してください:
|
||||
|
||||
{{#ref}}
|
||||
../gcp-post-exploitation/gcp-vertex-ai-post-exploitation.md
|
||||
@@ -42,27 +42,23 @@ gcloud iam roles create <ROLE_ID> \
|
||||
gcloud --impersonate-service-account="${victim}@${PROJECT_ID}.iam.gserviceaccount.com" \
|
||||
auth print-access-token
|
||||
```
|
||||
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/4-iam.serviceAccounts.getAccessToken.sh) and a python script to abuse this privilege [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.getAccessToken.py). For more information check the [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).
|
||||
[**脆弱な環境の作成、exploit、クリーンアップを自動化するスクリプトはこちら**](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)です。詳細は[**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/)を確認してください。
|
||||
|
||||
### `iam.serviceAccountKeys.create`
|
||||
|
||||
前述の権限を持つ攻撃者は、Service Account に対してユーザー管理キーを作成できるようになり、その Service Account として GCP にアクセスできるようになります。
|
||||
この権限を持つ attacker は、**Service Account の user-managed key を作成**でき、その Service Account として GCP にアクセスできるようになります。
|
||||
```bash
|
||||
gcloud iam service-accounts keys create --iam-account <name> /tmp/key.json
|
||||
|
||||
gcloud auth activate-service-account --key-file=sa_cred.json
|
||||
```
|
||||
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/3-iam.serviceAccountKeys.create.sh) and a python script to abuse this privilege [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccountKeys.create.py). For more information check the [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).
|
||||
`iam.serviceAccounts.implicitDelegation`
|
||||
|
||||
注意:`iam.serviceAccountKeys.update` は SA のキーを変更するためには機能しません。キーを変更するには `iam.serviceAccountKeys.create` の権限も必要だからです。
|
||||
Service Account に対して **`iam.serviceAccounts.implicitDelegation`** 権限を持ち、その Service Account が別の Service Account に対して **`iam.serviceAccounts.getAccessToken`** 権限を持っている場合、implicitDelegation を使って**その3つ目の Service Account の token を作成**できます。以下の図で説明します。
|
||||
|
||||
### `iam.serviceAccounts.implicitDelegation`
|
||||

|
||||
|
||||
もしあるサービスアカウントに対して **`iam.serviceAccounts.implicitDelegation`** 権限を持ち、かつそのサービスアカウントが第三のサービスアカウントに対して **`iam.serviceAccounts.getAccessToken`** 権限を持っている場合、implicitDelegation を使ってその第三のサービスアカウントのトークンを作成できます。説明のための図は次のとおりです。
|
||||
|
||||

|
||||
|
||||
注意: [**documentation**](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) メソッドを使って token を生成する場合にのみ機能します。そこで、API を直接使って token を取得する方法は以下のとおりです:
|
||||
```bash
|
||||
curl -X POST \
|
||||
'https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/'"${TARGET_SERVICE_ACCOUNT}"':generateAccessToken' \
|
||||
@@ -77,19 +73,19 @@ You can find a script to automate the [**creation, exploit and cleaning of a vul
|
||||
|
||||
### `iam.serviceAccounts.signBlob`
|
||||
|
||||
該当する権限を持つ攻撃者は、GCP上で任意のペイロードに署名することができます。したがって、ターゲットのサービスアカウントの未署名のJWTを作成し、それをblobとして送信してターゲットのサービスアカウントにJWTを署名させる、ということが可能になります。詳細は[**read this**](https://medium.com/google-cloud/using-serviceaccountactor-iam-role-for-account-impersonation-on-google-cloud-platform-a9e7118480ed)を参照してください。
|
||||
An attacker with the mentioned permissions will be able to **GCPで任意のpayloadをsignする**. So it'll be possible to **SAのunsigned JWTを作成し、それをblobとして送って、対象のSAによってJWTをsignしてもらう**. For more information [**read this**](https://medium.com/google-cloud/using-serviceaccountactor-iam-role-for-account-impersonation-on-google-cloud-platform-a9e7118480ed).
|
||||
|
||||
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/6-iam.serviceAccounts.signBlob.sh) and a python script to abuse this privilege [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.signBlob-accessToken.py) and [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.signBlob-gcsSignedUrl.py). For more information check the [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).
|
||||
|
||||
### `iam.serviceAccounts.signJwt`
|
||||
|
||||
該当する権限を持つ攻撃者は、整形式のJSON Web Token (JWT) に署名することができます。前の方法との違いは、JWTを含むblobをgoogleに署名させるのではなく、最初からJWTを期待する signJWT メソッドを使う点です。これにより使いやすくなりますが、任意のバイト列ではなくJWTのみを署名できる点に注意してください。
|
||||
An attacker with the mentioned permissions will be able to **適切に形式化されたJSON web tokens (JWTs)をsignする**. The difference with the previous method is that **instead of making google sign a blob containing a JWT, we use the signJWT method that already expects a JWT**. This makes it easier to use but you can only sign JWT instead of any bytes.
|
||||
|
||||
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/7-iam.serviceAccounts.signJWT.sh) and a python script to abuse this privilege [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.signJWT.py). For more information check the [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).
|
||||
|
||||
### `iam.serviceAccounts.setIamPolicy` <a href="#iam.serviceaccounts.setiampolicy" id="iam.serviceaccounts.setiampolicy"></a>
|
||||
|
||||
該当する権限を持つ攻撃者は、サービスアカウントにIAMポリシーを追加することができます。これを悪用して、サービスアカウントをインパーソネートするために必要な権限を自分に付与することが可能です。以下の例では、興味のあるサービスアカウントに対して `roles/iam.serviceAccountTokenCreator` ロールを自分に付与しています:
|
||||
An attacker with the mentioned permissions will be able to **service accountsにIAM policiesを追加する**. You can abuse it to **自分自身に** the permissions you need to impersonate the service account. In the following example we are granting ourselves the `roles/iam.serviceAccountTokenCreator` role over the interesting SA:
|
||||
```bash
|
||||
gcloud iam service-accounts add-iam-policy-binding "${VICTIM_SA}@${PROJECT_ID}.iam.gserviceaccount.com" \
|
||||
--member="user:username@domain.com" \
|
||||
@@ -100,47 +96,47 @@ gcloud iam service-accounts add-iam-policy-binding "${VICTIM_SA}@${PROJECT_ID}.i
|
||||
--member="user:username@domain.com" \
|
||||
--role="roles/iam.serviceAccountUser"
|
||||
```
|
||||
脆弱環境の作成、exploit、およびクリーンアップを自動化するスクリプトは[**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/d-iam.serviceAccounts.setIamPolicy.sh)**.**
|
||||
[**こちらで vuln 環境の作成、exploit、クリーンアップを自動化するスクリプトを見つけられます**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/d-iam.serviceAccounts.setIamPolicy.sh)**.**
|
||||
|
||||
### `iam.serviceAccounts.actAs`
|
||||
|
||||
The **iam.serviceAccounts.actAs permission** は **iam:PassRole permission from AWS** のようなものです。Compute Engine インスタンスの起動などの操作を、Service Account として "actAs" する能力を付与するため、権限管理上重要です。これがないと、ユーザーが不適切に権限を得る可能性があります。さらに、**iam.serviceAccounts.actAs** を悪用する手法はいくつか存在し、それぞれが複数の permissions を必要とするのに対し、他の手法は単一の権限だけで済む場合もあります。
|
||||
**iam.serviceAccounts.actAs permission** は **AWS の iam:PassRole permission** に似ています。Compute Engine インスタンスの起動のようなタスクを実行する際に重要で、Service Account に対して「actAs」する能力を与えることで、権限管理を安全にします。これがないと、ユーザーが不正に過剰なアクセスを得る可能性があります。さらに、**iam.serviceAccounts.actAs** の exploit には複数の方法があり、それぞれに一連の permissions が必要です。これは、1つの permission だけで済む他の方法とは対照的です。
|
||||
|
||||
#### サービスアカウントのなりすまし <a href="#service-account-impersonation" id="service-account-impersonation"></a>
|
||||
#### Service account impersonation <a href="#service-account-impersonation" id="service-account-impersonation"></a>
|
||||
|
||||
サービスアカウントをなりすますことは、**より高い権限を取得する**上で非常に有用です。別のサービスアカウントを[impersonate another service account](https://cloud.google.com/iam/docs/understanding-service-accounts#impersonating_a_service_account)する方法は次の3つです:
|
||||
Service Account を impersonate することは、**新しくより強い権限を取得する**のに非常に役立ちます。別の Service Account を [impersonate する](https://cloud.google.com/iam/docs/understanding-service-accounts#impersonating_a_service_account) 方法は3つあります:
|
||||
|
||||
- 認証 **using RSA private keys**(上で説明済み)
|
||||
- 認可 **using Cloud IAM policies**(ここで説明)
|
||||
- **Deploying jobs on GCP services**(ユーザーアカウントの侵害に関連することが多い)
|
||||
- RSA private keys を使った Authentication
|
||||
- Cloud IAM policies を使った Authorization
|
||||
- GCP services 上で jobs をデプロイすること(user account の compromise により適しています)
|
||||
|
||||
### `iam.serviceAccounts.getOpenIdToken`
|
||||
|
||||
前述の権限を持つ攻撃者は OpenID JWT を生成できます。これらはアイデンティティを主張するために使用され、リソースに対する暗黙の権限を必ずしも伴うわけではありません。
|
||||
ここで挙げた permissions を持つ attacker は OpenID JWT を生成できます。これらは identity を証明するために使われ、resource に対する暗黙の authorization を必ずしも持ちません。
|
||||
|
||||
この[**interesting post**](https://medium.com/google-cloud/authenticating-using-google-openid-connect-tokens-e7675051213b)によれば、audience(トークンを使って認証したいサービス)を指定する必要があり、指定したサービスアカウントと JWT の audience を示す、google によって署名された JWT を受け取ります。
|
||||
この [**興味深い post**](https://medium.com/google-cloud/authenticating-using-google-openid-connect-tokens-e7675051213b) によると、audience(token を使って authentication したい service)を指定する必要があり、google 署名付きの JWT が返されます。その JWT には service account と JWT の audience が示されます。
|
||||
|
||||
アクセス権があれば、次のようにして OpenIDToken を生成できます:
|
||||
以下の方法で OpenIDToken を生成できます(access がある場合):
|
||||
```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
|
||||
```
|
||||
これで、次のようにサービスにアクセスできます:
|
||||
その後、次のようにしてそのまま service にアクセスできます:
|
||||
```bash
|
||||
curl -v -H "Authorization: Bearer id_token" https://some-cloud-run-uc.a.run.app
|
||||
```
|
||||
この種類のトークンによる認証をサポートするサービスには、次のものがあります:
|
||||
この種の token による authentication をサポートするサービスには、以下があります:
|
||||
|
||||
- [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) (if using Google OIDC)
|
||||
- [Google Cloud Endpoints](https://cloud.google.com/endpoints/docs/openapi/authenticating-users-google-id) (Google OIDC を使用している場合)
|
||||
|
||||
service account の代理で OpenID token を作成する方法の例は[**here**](https://github.com/carlospolop-forks/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.getOpenIdToken.py)で確認できます。
|
||||
service account を behalf にして OpenID token を作成する方法の例は[**here**](https://github.com/carlospolop-forks/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.getOpenIdToken.py)で確認できます。
|
||||
|
||||
## 参考
|
||||
## References
|
||||
|
||||
- [https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/)
|
||||
|
||||
|
||||
Reference in New Issue
Block a user