GCP - Workflows Privesc
Workflows
基本情報:
GCP - Workflows Enumworkflows.workflows.create
, iam.serviceAccounts.ActAs
, workflows.executions.create
, (workflows.workflows.get
, workflows.operations.get
)
workflows.workflows.create
, iam.serviceAccounts.ActAs
, workflows.executions.create
, (workflows.workflows.get
, workflows.operations.get
)私の知る限り、Workflowに攻撃されたSAの資格情報を含むメタデータエンドポイントへのアクセスでシェルを取得することは不可能です。しかし、Workflow内で実行するアクションを追加することで、SAの権限を悪用することは可能です。
コネクタのドキュメントを見つけることができます。例えば、これはSecretmanagerコネクタのページです。 サイドバーには他のいくつかのコネクタが見つかります。
ここに秘密を印刷するコネクタの例があります:
CLIからの更新:
ウェブアクセスがない場合でも、Workflowの実行をトリガーして確認することが可能です:
以前の実行の出力を確認して、機密情報を探すこともできます。
PERMISSION_DENIED: Permission 'workflows.operations.get' denied on...
のようなエラーが発生しても、その権限がないために、ワークフローは生成されています。
OIDCトークンの漏洩(およびOAuth?)
ドキュメントによると、OAuthまたはOIDCトークンを含むHTTPリクエストを送信するワークフローステップを使用することが可能です。しかし、Cloud Schedulerの場合と同様に、OAuthトークンを含むHTTPリクエストはホスト.googleapis.com
に対して行う必要があります。
したがって、**ユーザーが制御するHTTPエンドポイントを指定することでOIDCトークンを漏洩させることは可能ですが、OAuthトークンを漏洩させるにはその保護をバイパスする必要があります。しかし、コネクタまたはOAuthトークンを使用したHTTPリクエストを介して、SAの代理で任意のGCP APIに連絡してアクションを実行することは依然として可能です。
OAuth
OIDC
workflows.workflows.update
...
workflows.workflows.update
...この権限を使用すると、workflows.workflows.create
の代わりに、既存のワークフローを更新し、同じ攻撃を実行することが可能です。
Last updated