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