# GCP - IAM Privesc

{{#include ../../../banners/hacktricks-training.md}}

## IAM

IAM に関する詳細情報は次を参照してください:

{{#ref}}
../gcp-services/gcp-iam-and-org-policies-enum.md
{{#endref}}

### `iam.roles.update` (`iam.roles.get`)

上記の権限を持つ攻撃者は、あなたに割り当てられた role を更新し、次のような他のリソースに対して追加の権限を付与できるようになります:
```bash
gcloud iam roles update <rol name> --project <project> --add-permissions <permission>
```
**vuln environmentの作成、exploit、およびクリーンアップを自動化するスクリプトはこちら**と、この権限を悪用する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/)を参照してください。
```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 権限を使用して）権限昇格を達成できるからです。
```bash
gcloud iam roles create <ROLE_ID> \
--project=<PROJECT_ID> \
--title="<Title>" \
--description="<Description>" \
--permissions="permission1,permission2,permission3"
```
### `iam.serviceAccounts.getAccessToken` (`iam.serviceAccounts.get`)

前述の権限を持つ攻撃者は、**Service Account に属する access token を要求することができます**。そのため、私たちより権限の高い Service Account の access token を要求できる可能性があります。
```bash
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/).

### `iam.serviceAccountKeys.create`

上記の権限を持つ attacker は、**create a user-managed key for a Service Account** を実行でき、その 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
```
自動化用スクリプトは[**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` はサービスアカウントのキーを変更するためには動作しません**。その操作には `iam.serviceAccountKeys.create` 権限も必要です。

### `iam.serviceAccounts.implicitDelegation`

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

![](https://rhinosecuritylabs.com/wp-content/uploads/2020/04/image2-500x493.png)

注意: [**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 を直接使用してトークンを取得する方法を示します:
```bash
curl -X POST \
'https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/'"${TARGET_SERVICE_ACCOUNT}"':generateAccessToken' \
-H 'Content-Type: application/json' \
-H 'Authorization: Bearer '"$(gcloud auth print-access-token)" \
-d '{
"delegates": ["projects/-/serviceAccounts/'"${DELEGATED_SERVICE_ACCOUNT}"'"],
"scope": ["https://www.googleapis.com/auth/cloud-platform"]
}'
```
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/5-iam.serviceAccounts.implicitDelegation.sh) and a python script to abuse this privilege [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.implicitDelegation.py). For more information check the [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).

### `iam.serviceAccounts.signBlob`

前述の権限を持つ攻撃者は、**GCP内の任意のペイロードに署名することができる**ようになります。したがって、対象のSAの未署名JWTを作成してそれをblobとして送信し、SAにJWTを署名させることが可能になります。詳細は[**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 tokens (JWTs) に署名することができる**ようになります。前の方法との違いは、**JWTを含むblobにGoogleに署名させる代わりに、既にJWTを期待するsignJWTメソッドを使う**点です。これにより使いやすくなりますが、任意のバイトではなくJWTのみ署名できます。

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ポリシーを**追加する**ことができるようになります。これを悪用して、自分自身にサービスアカウントを偽装するために必要な権限を**付与する**ことが可能です。以下の例では、興味のあるSAに対して自分に`roles/iam.serviceAccountTokenCreator`ロールを付与しています:
```bash
gcloud iam service-accounts add-iam-policy-binding "${VICTIM_SA}@${PROJECT_ID}.iam.gserviceaccount.com" \
--member="user:username@domain.com" \
--role="roles/iam.serviceAccountTokenCreator"

# If you still have prblem grant yourself also this permission
gcloud iam service-accounts add-iam-policy-binding "${VICTIM_SA}@${PROJECT_ID}.iam.gserviceaccount.com" \ \
--member="user:username@domain.com" \
--role="roles/iam.serviceAccountUser"
```
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 permission** は、AWS の **iam:PassRole permission** に似ています。Compute Engine インスタンスの起動などの操作を実行する際に、Service Account として「actAs」できる権限を与えるため、権限管理において重要です。これがないと、ユーザが不適切にアクセスを得る可能性があります。さらに、**iam.serviceAccounts.actAs** を悪用するには複数の方法があり、それぞれに必要な権限セットが異なるのに対し、他の方法は単一の権限だけで済むものもあります。

#### Service account impersonation <a href="#service-account-impersonation" id="service-account-impersonation"></a>

Service account を impersonate することは、より高い権限を取得するために非常に有用です。別の service account を impersonate する方法は次の三通りがあります（詳細は [https://cloud.google.com/iam/docs/understanding-service-accounts#impersonating_a_service_account](https://cloud.google.com/iam/docs/understanding-service-accounts#impersonating_a_service_account) を参照）:

- Authentication **using RSA private keys**（上で説明）
- Authorization **using Cloud IAM policies**（ここで説明）
- **Deploying jobs on GCP services**（ユーザアカウントの侵害により関連することが多い）

### `iam.serviceAccounts.getOpenIdToken`

前述の権限を持つ攻撃者は、OpenID JWT を生成できます。これらはアイデンティティを主張するために使用され、必ずしもリソースに対する暗黙の認可を含むとは限りません。

この[**interesting post**](https://medium.com/google-cloud/authenticating-using-google-openid-connect-tokens-e7675051213b)によれば、audience（トークンを使って認証したいサービス）を指定する必要があり、google によって署名された JWT が返され、その JWT に service account と audience が示されます。

You can generate an OpenIDToken (if you have the access) with:
```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
```
その後、それを使ってサービスにアクセスできます:
```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 を使用している場合)

サービスアカウントに代わって OpenID トークンを作成する方法の例は[**こちら**](https://github.com/carlospolop-forks/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.getOpenIdToken.py)で確認できます。

## 参考

- [https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/)

{{#include ../../../banners/hacktricks-training.md}}
