Synopsis
Tenable Research has identified and responsibly disclosed a critical privilege escalation vulnerability in GCP Eventarc. This flaw allowed an attacker with restricted Eventarc permissions to exfiltrate access tokens for any service account in a project, including the highly privileged Eventarc Service Agent.
An attacker with only Eventarc access (roles/eventarc.messageBusUser, roles/eventarc.developer) can create a pipeline in Eventarc that authenticates using arbitrary service accounts in the project, even without iam.serviceAccounts.actAs permissions. Additionally, the user can manipulate the Eventarc service agent to authenticate with its own access token. The attacker can therefore create an Eventarc Pipeline that will authenticate to a public Cloud Run in the attacker’s control, exfiltrating the access tokens.
The Eventarc service agent has the following notable permissions, which allow the attacker to use a single exfiltration to escalate privileges to any service account:
iam.serviceAccounts.actAs
iam.serviceAccounts.getAccessToken
iam.serviceAccounts.getOpenIdToken
Since service agents use predictable naming schemes, the attacker does not even need permissions to list all service accounts to exploit this vulnerability.
Proof of Concept:
Setup:
- Create a public Cloud Run in the attacker’s project that logs the Authorization header
- Give the attacker the Eventarc roles mentioned above in the victim’s project
- Create an Eventarc Message Bus in the victim’s project
Attack:
- Go to https://console.cloud.google.com/eventarc/pipelines/create
- Choose a name and region for the pipeline
- Under ‘Enrollments’, add an enrollment for the Eventarc Advanced bus, with the expression ‘true’, then press ‘Continue’
- Press ‘Continue’ again
- Under ‘Destination type’, choose ‘Cloud Run service (via HTTP)’, and choose the Cloud Run from the attacker’s project
- Check ‘Enable authentication’, and choose ‘OAuth token’ for ‘Auth header’
- Under ‘Service account’, click ‘Enter manually’, and enter a unique name (it doesn’t need to exist)
- In your intercepting proxy, enable a ‘Match and Replace’ rule from <UNIQUE-NAME>@<VICTIM-PROJECT>.iam.gserviceaccount.com to service-<VICTIM-PROJECT-NUMBER>@gcp-sa-eventarc.iam.gserviceaccount.com
- Click ‘Create’ (the creation may take a few minutes)
- Once the pipeline is created, send a message to the Event Bus:
gcloud eventarc message-buses publish <VICTIM-MESSAGE-BUS> --location=<BUS-LOCATION> --json-message='{"specversion": "1.0", "type": "test.event", "source": "manual.test", "id": "abc-123", "data": {"hello": "world"}}'
- Wait a little while for the pipeline to trigger, and you will find the authorization header in the logs of the Cloud Run in the attacker’s project
Solution
Google fixed the issue by enforcing iam.serviceAccounts.actAs permission checks during pipeline creation and preventing pipelines from generating a token for the Eventarc P4SA. This ensures that users cannot configure pipelines to run as service accounts they lack the necessary permissions for, and prevents existing vulnerable pipelines from being exploited.
Disclosure Timeline
All information within TRA advisories is provided “as is”, without warranty of any kind, including the implied warranties of merchantability and fitness for a particular purpose, and with no guarantee of completeness, accuracy, or timeliness. Individuals and organizations are responsible for assessing the impact of any actual or potential security vulnerability.
Tenable takes product security very seriously. If you believe you have found a vulnerability in one of our products, we ask that you please work with us to quickly resolve it in order to protect customers. Tenable believes in responding quickly to such reports, maintaining communication with researchers, and providing a solution in short order.
For more details on submitting vulnerability information, please see our Vulnerability Reporting Guidelines page.
If you have questions or corrections about this advisory, please email [email protected]