GCP - IAM, Principals & Org Policies Enum

htARTE(HackTricks AWS Red Team Expert)を通じてゼロからヒーローまでAWSハッキングを学びましょう!

HackTricksをサポートする他の方法:

サービスアカウント

サービスアカウントについての紹介はこちらを参照してください:

pageGCP - Basic Information

列挙

サービスアカウントは常にプロジェクトに属しています:

gcloud iam service-accounts list --project <project>

ユーザー&グループ

GCPでのユーザー&グループの動作についての紹介は、以下をチェックしてください:

pageGCP - Basic Information

列挙

権限 serviceusage.services.enableserviceusage.services.use を使用すると、プロジェクトで サービスを有効にでき ます。

デフォルトでは、Workspaceユーザーには Project Creator の役割が付与され、新しいプロジェクトを作成 する権限が与えられます。ユーザーがプロジェクトを作成すると、そのユーザーには owner 役割が付与されます。そのため、彼は Workspaceを列挙できるようにプロジェクトでこれらのサービスを有効にできます

ただし、これらのAPIを呼び出すためには、Workspaceで十分な権限が必要 であることに注意してください。

adminサービスを有効にでき、かつユーザーが Workspaceで十分な特権を持っている 場合、次の行で すべてのグループ&ユーザーを列挙 できます。 identity groups と表示されていても、グループなしのユーザー も返されます:

# Enable admin
gcloud services enable admin.googleapis.com
gcloud services enable cloudidentity.googleapis.com

# Using admin.googleapis.com
## List all users
gcloud organizations list #The DIRECTORY_CUSTOMER_ID is the Workspace ID
gcloud beta identity groups preview --customer <workspace-id>

# Using cloudidentity.googleapis.com
## List groups of a user (you can list at least the groups you belong to)
gcloud identity groups memberships search-transitive-groups --member-email <email> --labels=cloudidentity.googleapis.com/groups.discussion_forum

## List Group Members (you can list at least the groups you belong to)
gcloud identity groups memberships list --group-email=<email>
### Make it transitive
gcloud identity groups memberships search-transitive-memberships --group-email=<email>

## Get a graph (if you have enough permissions)
gcloud identity groups memberships get-membership-graph --member-email=<email> --labels=cloudidentity.googleapis.com/groups.discussion_forum

前の例では、パラメータ --labels が必要なので、一般的な値が使用されます(PurplePanda がここで行っているように のように API を直接使用する場合は必要ありません)。

管理サービスが有効になっていても、侵害されたワークスペースユーザーに十分な権限がないため、それらを列挙する際にエラーが発生する可能性があります:

IAM

IAM に関する基本情報については、こちらを参照してください

デフォルトの権限

ドキュメント によると、組織リソースが作成されると、デフォルトでドメイン内のすべてのユーザーに Billing Account Creator および Project Creator の役割が付与されます。これらのデフォルトの役割により、ユーザーはすぐに Google Cloud を使用できるようになりますが、組織リソースの通常の運用には適していません。

これらの 役割 は以下の 権限 を付与します:

  • billing.accounts.create および resourcemanager.organizations.get

  • resourcemanager.organizations.get および resourcemanager.projects.create

さらに、ユーザーがプロジェクトを作成すると、ドキュメント によると、そのプロジェクトの所有者が自動的に付与されます。したがって、デフォルトでは、ユーザーはプロジェクトを作成し、その上で任意のサービスを実行できます(マイナー?ワークスペースの列挙?...)

GCP 組織での最高権限は Organization Administrator 役割です。

set-iam-policy と add-iam-policy-binding

ほとんどのサービスでは、リソース上の権限を変更するために add-iam-policy-binding または set-iam-policy メソッドを使用できます。主な違いは、add-iam-policy-binding は既存の IAM ポリシーに新しいロールバインディングを追加するのに対し、set-iam-policy は以前に付与された権限を削除し、コマンドで指定された権限のみを設定します。

列挙

# Roles
## List roles
gcloud iam roles list --project $PROJECT_ID # List only custom roles
gcloud iam roles list --filter='etag:AA=='

## Get perms and description of role
gcloud iam roles describe roles/container.admin
gcloud iam roles describe --project <proj-name> <role-name>

# Policies
gcloud organizations get-iam-policy <org_id>
gcloud resource-manager folders get-iam-policy <folder-id>
gcloud projects get-iam-policy <project-id>

# MISC
## Testable permissions in resource
gcloud iam list-testable-permissions --filter "NOT apiDisabled: true" <resource>
## Grantable roles to a resource
gcloud iam list-grantable-roles <project URL>

cloudasset IAM 列挙

異なるリソース(組織、フォルダ、プロジェクトなど)内のユーザーのすべての権限をチェックするための異なる方法があります。

  • 権限 cloudasset.assets.searchAllIamPolicies は、リソース内の すべての IAM ポリシー をリクエストできます。

gcloud asset search-all-iam-policies #By default uses current configured project
gcloud asset search-all-iam-policies --scope folders/1234567
gcloud asset search-all-iam-policies --scope organizations/123456
gcloud asset search-all-iam-policies --scope projects/project-id-123123
  • 権限 cloudasset.assets.analyzeIamPolicy は、リソース内のプリンシパルの すべてのIAMポリシー をリクエストできます。

# Needs perm "cloudasset.assets.analyzeIamPolicy" over the asset
gcloud asset analyze-iam-policy --organization=<org-id> \
--identity='user:email@hacktricks.xyz'
gcloud asset analyze-iam-policy --folder=<folder-id> \
--identity='user:email@hacktricks.xyz'
gcloud asset analyze-iam-policy --project=<project-name> \
--identity='user:email@hacktricks.xyz'
  • 権限 cloudasset.assets.searchAllResources は、組織、フォルダ、またはプロジェクトのすべてのリソースをリストアップすることを許可します。IAM 関連のリソース(役割など)が含まれます。

gcloud asset search-all-resources --scope projects/<proj-name>
gcloud asset search-all-resources --scope folders/1234567
gcloud asset search-all-resources --scope organizations/123456
  • 権限 cloudasset.assets.analyzeMove は、プロジェクトなどのリソースに影響を与えるポリシーを取得するのにも役立ちます。

gcloud asset analyze-move --project=<proj-name> \
--destination-organization=609216679593
  • 私は、権限 cloudasset.assets.queryIamPolicy が主体の権限を見つけるためのアクセス権も与える可能性があると考えています

# But, when running something like this
gcloud asset query --project=<proj> --statement='SELECT * FROM compute_googleapis_com_Instance'
# I get the error
ERROR: (gcloud.asset.query) UNAUTHENTICATED: QueryAssets API is only supported for SCC premium customers. See https://cloud.google.com/security-command-center/pricing

testIamPermissions列挙

前述の方法でIAM情報にアクセスできない場合、Red Teamにいる場合は、https://github.com/carlospolop/bf_my_gcp_perms ツールを使用して現在の権限を総当たり攻撃することができます。

ただし、cloudresourcemanager.googleapis.comサービスが有効になっている必要があります。

Privesc

次のページでは、IAM権限を悪用して特権を昇格する方法を確認できます:

pageGCP - IAM Privesc

認証なしの列挙

pageGCP - IAM, Principals & Org Unauthenticated Enum

ポストエクスプロイテーション

pageGCP - IAM Post Exploitation

永続化

高い権限を持っている場合は、次のことができます:

  • 新しいSAsを作成する(またはWorkspaceの場合はユーザーを作成する)

  • 自分自身が制御するプリンシパルにより多くの権限を付与する

  • 脆弱なSAsにより多くの特権を付与する(vm内のSSRF、脆弱なCloud Functionなど)

  • ...

組織ポリシー

Org Policiesについての紹介はこちらをご覧ください:

pageGCP - Basic Information

IAMポリシーは、ロールを介してプリンシパルがリソースに対して持つ権限を示し、それらのサービスがどのように使用されるか、どの機能が無効になるかを制限する組織ポリシーがあります。これにより、GCP環境の各リソースの最小特権を向上させるのに役立ちます。

gcloud resource-manager org-policies list --organization=ORGANIZATION_ID
gcloud resource-manager org-policies list --folder=FOLDER_ID
gcloud resource-manager org-policies list --project=PROJECT_ID

特権昇格

以下のページで、組織ポリシーの権限を悪用して特権を昇格する方法を確認できます:

pageGCP - Orgpolicy Privesc

最終更新