Facebook Google Plus Twitter LinkedIn YouTube RSS Menu Search Resource - BlogResource - WebinarResource - ReportResource - Eventicons_066 icons_067icons_068icons_069icons_070

Google Cloud Platform (GCP) Privilege Escalation Vulnerability In Cloud Functions

Medium

Synopsis

Tenable Research has discovered a vulnerability in Google Cloud Platform (GCP) that allows privilege escalation from Cloud Function permissions to the default Cloud Build service account permissions. These permissions include high privileges in services such as Cloud Build, storage (including the source code of other functions), artifact registry, and container registry.

 

The vulnerability could be exploited with permissions to update or create a new Google Cloud Function, thus getting Cloud Build to act as a confused deputy to run malicious code (a malicious dependency) under the Cloud Build editor privileges, including leaking the Cloud Build Default Service Account ([email protected]) token.

Attackers could upload a malicious package to a registry, and the default Cloud Function deployment process would install that package after attackers include its name in the Cloud Function code.

Google has remediated the vulnerability for future Cloud Build accounts created. However, for existing Cloud Build instances customer action is required.

 

Regarding severity, Tenable generally adheres to the CVSS severity scale (https://nvd.nist.gov/vuln-metrics/cvss). 

 

Tenable reported this vulnerability to Google VRP as a Privilege Escalation vulnerability.

Google acknowledged this issue as a “bypass of significant security controls”.

 

This limited advisory will be updated in the future with full details of the proof of concept.

Solution

GCP launched a feature in Cloud Functions giving customers the ability to choose a custom service account for the Cloud Build instance deployed as part of the function deployment process. More details about the fix can be found in the recent update to the GCP documentation.

 

Additionally, GCP are changing the default behavior for how Cloud Build uses service accounts in new projects to improve the default security posture of our customers going forward. These changes are being deployed over several weeks in May and June 2024. The changes are as follows:

  • Projects without an organization: Customers who enabled the Cloud Build API on projects after the change will use the Compute Engine service account by default for builds submitted using the Cloud Build API or the Google Cloud CLI. These projects won't have the option to use the legacy Cloud Build service account, but can use a user-specified service account.

  • Projects with an organization: Customers who enabled the Cloud Build API on projects after the change will use the Compute Engine service account by default for builds submitted using the Cloud Build API or the Google Cloud CLI. Customers can use a user-specified service account or opt out of the change by enabling the Cloud Build service account in their organization.

  • Existing projects without an organization: Customers who enabled the Cloud Build API on your projects before the change will continue with the old behavior, using the legacy Cloud Build service account by default for all your builds. You can continue to use a user-specified service account, by either selecting the Compute Engine service account or creating your own.

  • Existing projects with an organization: Customers who enabled the Cloud Build API on their projects before the change will continue with the old behavior, using the legacy Cloud Build service account by default. They can also continue to use a user-specified service account.

  • Triggering: Customers will have to specify a service account when you create or update a trigger, unless the default service account for their project is the legacy Cloud Build service account.

  • API: Enabling the Cloud Build API also enables the Identity and Access Management API.

  • Cloud Build service account name: The Cloud Build service account will be referred to as the legacy Cloud Build service account.

 

More information on the new organization policy introduced by GCP and the updates that will take place can be found here.

Disclosure Timeline

Jul 13, 2023 - Ermetic researchers disclose to vendor. Automated acknowledgment.
October 2, 2023 - Ermetic acquired by Tenable.
October 3, 2023 - GCP confirms the behavior reported and awarded a bounty.
January 16, 2024 - GCP updated the Cloud Build Service Account behavior and released new updates regarding security mitigations and Cloud Build processes
February 14, 2024 - GCP released a Pre-GA update to allow Cloud Build service account customization in 2nd gen Cloud Functions.
May-June, 2024 - Cloud Build service account changes rolled out region-by-region in GCP
June 5, 2024 - Limited advisory released.

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]

Risk Information

Tenable Advisory ID: TRA-2024-20
Credit:
Liv Matan
Affected Products:
GCP Cloud Function
GCP Cloud Build
Risk Factor:
Medium

Advisory Timeline

June 5, 2024 - Initial release.