Last updated
AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE) GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE)
Google Workspaceのドメイン全体の委任は、外部アプリ（Google Workspace Marketplaceから）または内部のGCPサービスアカウントのいずれかのアイデンティティオブジェクトが、ユーザーに代わってWorkspace全体のデータにアクセスすることを可能にします。
これは基本的に、GCPプロジェクト内のサービスアカウントが、同じ組織のWorkspaceユーザー（または異なる組織のユーザー）をなりすますことができる可能性があることを意味します。
この仕組みの詳細については、以下を確認してください：
GCP - Understanding Domain-Wide Delegation攻撃者がGCP上のアクセスを侵害し、会社の有効なWorkspaceユーザーのメール（できればスーパ管理者）を知っている場合、彼はアクセスできるすべてのプロジェクトを列挙し、プロジェクトのすべてのSAを列挙し、アクセスできるサービスアカウントを確認し、なりすますことができる各SAでこれらのステップを繰り返すことができます。 彼がアクセスできるすべてのサービスアカウントのリストとWorkspaceのメールのリストを持っていれば、攻撃者は各サービスアカウントでユーザーをなりすますことを試みることができます。
ドメイン全体の委任を設定する際にはWorkspaceユーザーは必要ないため、有効なユーザーが1人いれば十分で、なりすますために必要です。 ただし、なりすましたユーザーの権限が使用されるため、スーパ管理者であればすべてにアクセスできるようになります。アクセス権がない場合は無意味です。
このシンプルなスクリプトは、委任されたユーザーとしてOAuthトークンを生成し、その後gcloudの有無にかかわらず他のGoogle APIにアクセスするために使用できます：
これは、次の手順に従って攻撃を実行できるツールです。
Resource Manager APIを使用してGCPプロジェクトを列挙します。
各プロジェクトリソースを反復処理し、初期IAMユーザーがアクセスできるGCPサービスアカウントリソースを_GetIAMPolicy_を使用して列挙します。
各サービスアカウントロールを反復処理し、ターゲットサービスアカウントリソースに対して_serviceAccountKeys.create_権限を持つ組み込み、基本、およびカスタムロールを見つけます。エディターロールは本質的にこの権限を持っていることに注意する必要があります。
IAMポリシーで関連する権限が見つかった各サービスアカウントリソースに対して**新しいKEY_ALG_RSA_2048**プライベートキーを作成します。
各新しいサービスアカウントを反復処理し、JWT オブジェクトを作成します。このオブジェクトは、SAプライベートキーの資格情報とOAuthスコープで構成されています。新しい_JWT_オブジェクトを作成するプロセスは、oauth_scopes.txtリストからのすべての既存のOAuthスコープの組み合わせを反復処理し、すべての委任の可能性を見つけるために行われます。リストoauth_scopes.txtは、Workspaceアイデンティティを悪用するために関連性があると見なされたすべてのOAuthスコープで更新されます。
_make_authorization_grant_assertionメソッドは、DWDの下でJWTを生成するために、_subject_と呼ばれるターゲットワークスペースユーザーを宣言する必要性を明らかにします。これは特定のユーザーを必要とするように思えるかもしれませんが、DWDはドメイン内のすべてのアイデンティティに影響を与えることを理解することが重要です。したがって、任意のドメインユーザーのためにJWTを作成することは、そのドメイン内のすべてのアイデンティティに影響を与え、組み合わせ列挙チェックと一致します。簡単に言えば、有効なWorkspaceユーザー1人で進むのに十分です。
このユーザーはDeleFriendの_config.yaml_ファイルで定義できます。ターゲットワークスペースユーザーが既に知られていない場合、ツールはGCPプロジェクトで役割を持つドメインユーザーをスキャンすることによって有効なワークスペースユーザーの自動識別を促進します。再度重要な点は、JWTはドメイン固有であり、すべてのユーザーのために生成されるわけではないため、自動プロセスはドメインごとに1つのユニークなアイデンティティを対象とします。
各JWTのために新しいベアラートークンを列挙して作成し、tokeninfo APIに対してトークンを検証します。
Gitlabは、ユーザーディレクトリをリストし、SA資格情報と偽装するユーザーを示すjsonを指定しながら新しい管理アカウントを作成できるこのPythonスクリプトを作成しました。使用方法は次のとおりです：
ドメイン全体の委任を確認することができます https://admin.google.com/u/1/ac/owl/domainwidedelegation.
GCPプロジェクトでサービスアカウントを作成する能力とGWSに対するスーパ管理者権限を持つ攻撃者は、SAsがいくつかのGWSユーザーを偽装できる新しい委任を作成することができます：
新しいサービスアカウントと対応するキー ペアの生成： GCPでは、新しいサービスアカウントリソースは、コンソールを介して対話的に、または直接API呼び出しとCLIツールを使用してプログラム的に生成できます。これには、役割 iam.serviceAccountAdmin または iam.serviceAccounts.create 権限を持つカスタムロールが必要です。サービスアカウントが作成されると、関連するキー ペアを生成します（iam.serviceAccountKeys.create 権限）。
新しい委任の作成： Google Workspaceでグローバルなドメイン全体の委任を設定できるのはスーパ管理者ロールのみであることを理解することが重要です。ドメイン全体の委任はプログラム的に設定できず、Google Workspaceのコンソールを通じて手動で作成および調整することのみが可能です。
ルールの作成は、APIコントロール → Google Workspace管理コンソールでのドメイン全体の委任の管理のページにあります。
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
ターゲットアイデンティティの代理として行動する： この時点で、GWSに機能する委任オブジェクトがあります。今、GCPサービスアカウントの秘密鍵を使用してAPI呼び出しを行うことができ（OAuthスコープパラメータで定義されたスコープ内で）、Google Workspaceに存在する任意のアイデンティティの代理として行動することができます。私たちが学んだように、サービスアカウントはそのニーズに応じて、REST APIアプリケーションに対する権限に従ってアクセストークンを生成します。
この委任を使用するためのツールについては、前のセクションを確認してください。
OAuth SA IDはグローバルであり、組織間の委任に使用できます。組織間のグローバルな委任を防ぐ制限は実装されていません。簡単に言えば、異なるGCP組織のサービスアカウントを使用して、他のWorkspace組織でドメイン全体の委任を構成することができます。これにより、Workspaceへのスーパ管理者アクセスのみが必要となり、同じGCPアカウントへのアクセスは不要になります。攻撃者は、個人的に制御するGCPアカウントでサービスアカウントと秘密鍵を作成できます。
デフォルトで、Workspace ユーザーは新しいプロジェクトを作成する権限を持っており、新しいプロジェクトが作成されると、作成者はそのプロジェクトに対してオーナー権限を取得します。
したがって、ユーザーはプロジェクトを作成し、新しいプロジェクトでWorkspaceを列挙するためにAPIを有効にし、列挙を試みることができます。
ユーザーがWorkspaceを列挙できるようにするには、十分なWorkspace権限も必要です（すべてのユーザーがディレクトリを列挙できるわけではありません）。
チェック さらに列挙するには:
GCP - IAM, Principals & Org Policies Enumgcloudのログインフローに関する詳細情報は以下で確認できます:
そこで説明されているように、gcloudは**https://www.googleapis.com/auth/driveのスコープを要求することができ、これによりユーザーは自分のドライブにアクセスできます。
攻撃者として、もしあなたがユーザーのコンピュータを物理的に**侵害し、ユーザーがまだ自分のアカウントでログインしている場合、次のコマンドを使用してドライブへのアクセスを持つトークンを生成してログインすることができます:
もし攻撃者がユーザーのコンピュータを侵害した場合、彼はファイル 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に対する特権アクセスを持つグループやユーザーにアクセスできるため、GWSからGCPへの移行は通常「簡単」です。なぜなら、GWSのユーザーはGCPに対して高い特権を持っているからです。
デフォルトでは、ユーザーは組織のWorkspaceグループに自由に参加できます。これらのグループにはGCPの権限が割り当てられている可能性があります（https://groups.google.com/でグループを確認してください）。
google groups privescを悪用することで、GCPに対する何らかの特権アクセスを持つグループに昇格できるかもしれません。
AWSハッキングを学び、練習する：HackTricks Training AWS Red Team Expert (ARTE) GCPハッキングを学び、練習する：HackTricks Training GCP Red Team Expert (GRTE)
