GCP <--> Workspace Pivoting

htARTE（HackTricks AWS Red Team Expert） でAWSハッキングをゼロからヒーローまで学びましょう！

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

• HackTricksで企業を宣伝したいまたはHackTricksをPDFでダウンロードしたい場合は、SUBSCRIPTION PLANSをチェックしてください！

• 公式PEASS＆HackTricksスワッグを入手する

• The PEASS Familyを発見し、独占的なNFTsのコレクションを見つける

• 💬 Discordグループまたはtelegramグループに参加するか、Twitter 🐦 @carlospolopmをフォローする

• ハッキングトリックを共有するには、HackTricksとHackTricks CloudのGitHubリポジトリにPRを提出してください。

GCPからGWSへ

ドメインワイドデリゲーションの基礎

Google Workspaceのドメインワイドデリゲーションは、Google Workspace Marketplaceからの外部アプリまたは内部のGCPサービスアカウントが、ユーザーを代表してWorkspace全体のデータにアクセスできるようにします。

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

これが正確にどのように機能するかの詳細については、次を確認してください：

pageGCP - Understanding Domain-Wide Delegation

既存のデリゲーションの侵害

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

ドメインワイドデリゲーションを構成する際にはWorkspaceユーザーが必要ではありませんので、1つの有効なユーザーがあれば十分であり、偽装には必須です。 ただし、偽装されたユーザーの権限が使用されるため、スーパー管理者であればすべてにアクセスできます。アクセス権がない場合は無意味です。

GCP Generate Delegation Token

このシンプルなスクリプトは、委任されたユーザーとして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. リソースマネージャ APIを使用して、GCPプロジェクトを列挙します。

2. 各プロジェクトリソースを繰り返し、初期IAMユーザーがアクセス権を持つGCPサービスアカウントリソースを列挙します。これは、_GetIAMPolicy_を使用します。

3. 各サービスアカウントロールを繰り返し、対象のサービスアカウントリソースで serviceAccountKeys.create 権限を持つ組み込み、基本、カスタムロールを見つけます。エディターロールは、この権限を元々持っていることに注意する必要があります。

4. IAMポリシーで関連する権限を持つ各サービスアカウントリソースに、新しい KEY_ALG_RSA_2048 秘密鍵を作成します。

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

6. _make_authorization_grant_assertion メソッドは、DWDの下でJWTを生成するために、subject として参照されるターゲットのワークスペースユーザーを宣言する必要性を明らかにします。これは特定のユーザーを必要とするように見えるかもしれませんが、重要なのはDWDがドメイン内のすべてのアイデンティティに影響を与えるということです。したがって、任意のドメインユーザーのためにJWTを作成することは、そのドメイン内のすべてのアイデンティティに影響を与えます。単純に言えば、1つの有効なWorkspaceユーザーが十分です。 このユーザーは、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 [e-mail] \
--domain target-org.com

# List the directory
./gcp_delegation.py --keyfile ./credentials.json \
--impersonate [e-mail] \
--domain target-org.com \
--list

# Create a new admin account
./gcp_delegation.py --keyfile ./credentials.json \
--impersonate [e-mail] \
--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管理コンソールでのドメイン全体の委任の管理ページで見つけることができます。

3. OAuthスコープ権限の添付: 新しい委任を構成する際、GoogleはクライアントID（GCPサービスアカウントのOAuth IDリソース）と、委任に必要な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

4. 対象アイデンティティの代理として行動する: この時点で、GWSに機能する委任オブジェクトがあります。今、GCPサービスアカウントの秘密キーを使用して、API呼び出し（OAuthスコープパラメータで定義されたスコープ内）を実行し、Google Workspaceに存在する任意のアイデンティティの代理として行動できます。サービスアカウントは、必要に応じてアクセス許可に応じてREST APIアプリケーションに対してアクセストークンを生成します。

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

組織間委任

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

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

デフォルトでは、Workspaceのユーザーは新しいプロジェクトを作成する権限を持ち、新しいプロジェクトを作成すると作成者が所有者ロールを取得します。

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

ユーザーがディレクトリを列挙できるようにするには、十分な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>

さらなる列挙を確認する：

pageGCP - IAM, Principals & Org Policies Enum

Gcloudの悪用

gcloud フローに関する詳細情報は以下で見つけることができます：

pageGCP - Non-svc Persistance

そこで説明されているように、gcloud は https://www.googleapis.com/auth/drive スコープをリクエストすることができ、これによりユーザーがユーザーのドライブにアクセスできるようになります。 攻撃者として、ユーザーのコンピューターを物理的に侵害し、かつユーザーがまだログインしている場合、ドライブへのアクセス権を持つトークンを生成してログインすることができます。

gcloud auth login --enable-gdrive-access

GWSからGCPへ

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

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

Googleグループ特権昇格

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

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

参考文献

• https://www.hunters.security/en/blog/delefriend-a-newly-discovered-design-flaw-in-domain-wide-delegation-could-leave-google-workspace-vulnerable-for-takeover