Japanese - Ht Cloud
HackTricks TrainingTwitterLinkedinSponsor

GCP <--> Workspace Pivoting

HackTricksをサポートする

GCPからGWSへ

ドメイン全体の委任の基本

Google Workspaceのドメイン全体の委任は、外部アプリ（Google Workspace Marketplaceから）または内部のGCPサービスアカウントのいずれかのアイデンティティオブジェクトが、ユーザーに代わってWorkspace全体のデータにアクセスすることを可能にします。

これは基本的に、GCPプロジェクト内のサービスアカウントが、同じ組織のWorkspaceユーザー（または異なる組織のユーザー）をなりすますことができる可能性があることを意味します。

この仕組みの詳細については、以下を確認してください：

既存の委任を侵害する

攻撃者がGCP上のアクセスを侵害し、会社の有効なWorkspaceユーザーのメール（できればスーパ管理者）を知っている場合、彼はアクセスできるすべてのプロジェクトを列挙し、プロジェクトのすべてのSAを列挙し、アクセスできるサービスアカウントを確認し、なりすますことができる各SAでこれらのステップを繰り返すことができます。 アクセスできるすべてのサービスアカウントのリストとWorkspaceのメールのリストを持っている攻撃者は、各サービスアカウントでユーザーをなりすますことを試みることができます。

ドメイン全体の委任を設定する際にはWorkspaceユーザーは必要ないため、有効なユーザーが1人いれば十分で、なりすますために必要です。 ただし、なりすましたユーザーの権限が使用されるため、スーパ管理者であればすべてにアクセスできるようになります。アクセス権がない場合は無意味です。

GCP委任トークンを生成する

このシンプルなスクリプトは、委任されたユーザーとしてOAuthトークンを生成し、その後gcloudの有無にかかわらず他のGoogle APIにアクセスするために使用できます：

# Impersonate indicated user
python3 gen_delegation_token.py --user-email <user-email> --key-file <path-to-key-file>

# Impersonate indicated user and add additional scopes
python3 gen_delegation_token.py --user-email <user-email> --key-file <path-to-key-file> --scopes "https://www.googleapis.com/auth/userinfo.email, https://www.googleapis.com/auth/cloud-platform, https://www.googleapis.com/auth/admin.directory.group, https://www.googleapis.com/auth/admin.directory.user, https://www.googleapis.com/auth/admin.directory.domain, https://mail.google.com/, https://www.googleapis.com/auth/drive, openid"

DeleFriend

これは、次の手順に従って攻撃を実行できるツールです。

  1. Resource Manager APIを使用してGCPプロジェクトを列挙します。

  2. 各プロジェクトリソースを反復処理し、初期IAMユーザーがアクセスできるGCPサービスアカウントリソースを_GetIAMPolicy_を使用して列挙します。

  3. 各サービスアカウントロールを反復処理し、ターゲットサービスアカウントリソース上で_serviceAccountKeys.create_権限を持つ組み込み、基本、およびカスタムロールを見つけます。Editorロールは本質的にこの権限を持っていることに注意する必要があります。

  4. IAMポリシー内で関連する権限を持つ各サービスアカウントリソースに対して**新しいKEY_ALG_RSA_2048**プライベートキーを作成します。

  5. 各新しいサービスアカウントを反復処理し、JWT オブジェクトを作成します。このオブジェクトはSAプライベートキーの資格情報とOAuthスコープで構成されています。新しい_JWT_オブジェクトを作成するプロセスは、oauth_scopes.txtリストからのすべての既存のOAuthスコープの組み合わせを反復処理し、すべての委任の可能性を見つけるために行われます。リストoauth_scopes.txtは、Workspaceアイデンティティを悪用するために関連性があると見なされたすべてのOAuthスコープで更新されます。

  6. _make_authorization_grant_assertionメソッドは、DWDの下でJWTを生成するために、_subject_と呼ばれるターゲットワークスペースユーザーを宣言する必要性を明らかにします。これは特定のユーザーを必要とするように思えるかもしれませんが、DWDはドメイン内のすべてのアイデンティティに影響を与えることを理解することが重要です。したがって、任意のドメインユーザーのためにJWTを作成することは、そのドメイン内のすべてのアイデンティティに影響を与え、組み合わせ列挙チェックと一致します。簡単に言えば、有効なWorkspaceユーザー1人で進むのに十分です。 このユーザーはDeleFriendの_config.yaml_ファイルで定義できます。ターゲットワークスペースユーザーが既に知られていない場合、ツールはGCPプロジェクト上の役割を持つドメインユーザーをスキャンすることによって有効なワークスペースユーザーの自動識別を促進します。再度重要な点は、JWTはドメイン固有であり、すべてのユーザーのために生成されるわけではないため、自動プロセスはドメインごとに1つのユニークなアイデンティティを対象とします。

  7. 各JWTのために新しいベアラートークンを列挙して作成し、tokeninfo APIに対してトークンを検証します。

GitlabのPythonスクリプト

Gitlabは、ユーザーディレクトリをリストし、SA資格情報と偽装するユーザーを示すjsonを指定しながら新しい管理アカウントを作成できるこのPythonスクリプトを作成しました。使用方法は次のとおりです：

# Install requirements
pip install --upgrade --user oauth2client

# Validate access only
./gcp_delegation.py --keyfile ./credentials.json \
--impersonate steve.admin@target-org.com \
--domain target-org.com

# List the directory
./gcp_delegation.py --keyfile ./credentials.json \
--impersonate steve.admin@target-org.com \
--domain target-org.com \
--list

# Create a new admin account
./gcp_delegation.py --keyfile ./credentials.json \
--impersonate steve.admin@target-org.com \
--domain target-org.com \
--account pwned

新しい委任を作成する（持続性）

ドメイン全体の委任を確認することができます https://admin.google.com/u/1/ac/owl/domainwidedelegation.

GCPプロジェクトでサービスアカウントを作成する能力とGWSに対するスーパ管理者権限を持つ攻撃者は、SAsがいくつかのGWSユーザーを偽装できる新しい委任を作成することができます：

  1. 新しいサービスアカウントと対応するキー ペアの生成： GCPでは、新しいサービスアカウントリソースは、コンソールを介して対話的に、または直接API呼び出しやCLIツールを使用してプログラム的に生成できます。これには、役割 iam.serviceAccountAdmin または iam.serviceAccounts.create 権限を備えたカスタムロールが必要です。サービスアカウントが作成されると、関連するキー ペアを生成します（iam.serviceAccountKeys.create 権限）。

  2. 新しい委任の作成： Google Workspaceでグローバルなドメイン全体の委任を設定できるのはスーパ管理者ロールのみであることを理解することが重要です。ドメイン全体の委任はプログラム的に設定できず、Google Workspaceのコンソールを通じて手動で作成および調整することのみが可能です。

  • ルールの作成は、APIコントロール → Google Workspace管理コンソールでのドメイン全体の委任の管理のページにあります。

  1. OAuthスコープ権限の添付： 新しい委任を構成する際、GoogleはクライアントID（GCPサービスアカウントリソースのOAuth ID）と、委任が必要とするAPI呼び出しを定義するOAuthスコープの2つのパラメータのみを要求します。

  • OAuthスコープの完全なリストはこちらで確認できますが、以下の推奨があります：https://www.googleapis.com/auth/userinfo.email, https://www.googleapis.com/auth/cloud-platform, https://www.googleapis.com/auth/admin.directory.group, https://www.googleapis.com/auth/admin.directory.user, https://www.googleapis.com/auth/admin.directory.domain, https://mail.google.com/, https://www.googleapis.com/auth/drive, openid

  1. ターゲットアイデンティティの代理として行動する： この時点で、GWSに機能する委任オブジェクトがあります。今、GCPサービスアカウントの秘密鍵を使用してAPI呼び出しを行うことができ（OAuthスコープパラメータで定義されたスコープ内で）、Google Workspaceに存在する任意のアイデンティティの代理として行動することができます。私たちが学んだように、サービスアカウントはそのニーズに応じてアクセス トークンを生成し、REST APIアプリケーションに対する権限に従います。

  • この委任を使用するためのツールについては、前のセクションを確認してください。

組織間の委任

OAuth SA IDはグローバルであり、組織間の委任に使用できます。組織間のグローバルな委任を防ぐ制限は実装されていません。簡単に言えば、異なるGCP組織のサービスアカウントを使用して、他のWorkspace組織でドメイン全体の委任を構成できます。これにより、Workspaceへのスーパ管理者アクセスのみが必要になり、同じGCPアカウントへのアクセスは不要になります。攻撃者は、自身が管理するGCPアカウントでサービスアカウントと秘密鍵を作成できます。

Workspaceを列挙するためのプロジェクトの作成

デフォルトで、Workspace ユーザーは新しいプロジェクトを作成する権限を持っており、新しいプロジェクトが作成されると、作成者はそのプロジェクトに対してオーナー権限を取得します。

したがって、ユーザーはプロジェクトを作成し、新しいプロジェクトでWorkspaceを列挙するためにAPIを有効にし、列挙を試みることができます。

ユーザーがWorkspaceを列挙できるようにするには、十分なWorkspace権限も必要です（すべてのユーザーがディレクトリを列挙できるわけではありません）。

# Create project
gcloud projects create <uniq-projec-name> --name=proj-name
# Set project
gcloud config set project <uniq-projec-name>
# Enable svcs
gcloud services enable admin.googleapis.com
gcloud services enable cloudidentity.googleapis.com
# Get org ID
gcloud organizations list
# Get currents email user groups (at least you can check the groups and members of the groups you belong to)
gcloud identity groups memberships search-transitive-groups --member-email <email> --labels=cloudidentity.googleapis.com/groups.discussion_forum
gcloud identity groups memberships list --group-email=g<group-email>

# FROM HERE THE USER NEEDS TO HAVE ENOUGH WORKSPACE ACCESS
gcloud beta identity groups preview --customer <org-cust-id>

Check more enumeration in:

Gcloud資格情報の悪用

You can find further information about the gcloud flow to login in:

As explained there, gcloud can request the scope https://www.googleapis.com/auth/drive which would allow a user to access the drive of the user. As an attacker, if you have compromised physically the computer of a user and the user is still logged with his account you could login generating a token with access to drive using:

gcloud auth login --enable-gdrive-access

もし攻撃者がユーザーのコンピュータを侵害した場合、彼はファイル google-cloud-sdk/lib/googlecloudsdk/core/config.py を修正し、CLOUDSDK_SCOPES にスコープ 'https://www.googleapis.com/auth/drive' を追加することができます：

したがって、次回ユーザーがログインすると、攻撃者がドライブにアクセスするために悪用できるドライブへのアクセスを持つトークンが作成されます。明らかに、ブラウザは生成されたトークンがドライブへのアクセスを持つことを示しますが、ユーザーが**gcloud auth loginを自ら呼び出すため、彼はおそらく何も疑わないでしょう。**

ドライブファイルをリストするには：curl -H "Authorization: Bearer $(gcloud auth print-access-token)" "https://www.googleapis.com/drive/v3/files"

GWSからGCPへ

特権GCPユーザーへのアクセス

攻撃者がGWSに完全にアクセスできる場合、彼はGCPに対する特権アクセスを持つグループやユーザーにアクセスできるため、GWSからGCPへの移行は通常「簡単」です。なぜなら、GWSのユーザーはGCPに対して高い特権を持っているからです。

Googleグループ特権昇格

デフォルトでは、ユーザーは組織のWorkspaceグループに自由に参加できます。これらのグループにはGCPの権限が割り当てられている可能性があります（https://groups.google.com/でグループを確認してください）。

google groups privescを悪用することで、GCPに対する何らかの特権アクセスを持つグループに昇格できるかもしれません。

参考文献

HackTricksをサポートする
PreviousGCP - Workflows EnumNextGCP - Understanding Domain-Wide Delegation

Last updated