GCP - Workflows Privesc
Workflows
Основна інформація:
GCP - Workflows Enumworkflows.workflows.create
, iam.serviceAccounts.ActAs
, workflows.executions.create
, (workflows.workflows.get
, workflows.operations.get
)
workflows.workflows.create
, iam.serviceAccounts.ActAs
, workflows.executions.create
, (workflows.workflows.get
, workflows.operations.get
)Наскільки мені відомо, неможливо отримати shell з доступом до кінцевої точки метаданих, що містить облікові дані SA, пов'язані з Workflow. Однак, можливо зловживати дозволами SA, додаючи дії для виконання всередині Workflow.
Можна знайти документацію по коннекторам. Наприклад, це сторінка коннектора Secretmanager. У бічній панелі можна знайти кілька інших конекторів.
А тут ви можете знайти приклад конектора, який друкує секрет:
Оновлення з CLI:
Якщо у вас немає веб-доступу, ви можете запустити та побачити виконання Workflow за допомогою:
Ви також можете перевірити вихідні дані попередніх виконань, щоб знайти чутливу інформацію
Зверніть увагу, що навіть якщо ви отримаєте помилку, наприклад, 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
OIDC
workflows.workflows.update
...
workflows.workflows.update
...З цією дозволом замість workflows.workflows.create
можливо оновити вже існуючий робочий процес і виконати ті ж атаки.
Last updated