Synopsis
A cross account code execution vulnerability existed in GCP 1st Gen Cloud functions. Successful exploitation of this vulnerability could allow a malicious attacker to execute arbitrary code within Cloud Functions belonging to other projects. The attacker could gain unauthorized access to sensitive data, escalate privileges, manipulate service operations, or disrupt the normal functioning of critical cloud services.
When a Cloud Function is first utilized in a project, it automatically creates a bucket within the same region to store the function’s code, with each folder in the bucket corresponding to a different function. If an attacker is able to take control of this bucket before the victim deploys their first function in the specified region, they can exploit the deployment process to execute arbitrary code within the victim’s function.
Reproduction Steps
Attacker Actions:
1. The attacker, after obtaining the victim's project ID through various methods such as open-source intelligence, exfiltration, or enumeration (as this information is typically not secret), predicts the bucket name that the victim's Cloud Function will attempt to create:
- gcf-sources-{project-id}-{region}
The attacker creates buckets across all possible regions to increase the likelihood of successful exploitation:
- gcf-sources-{project-id}-us-west1
- gcf-sources-{project-id}-us-central1
- gcf-sources-{project-id}-europe-west1
- (and others)
2. The attacker configures the created buckets as public to allow the victim's function to write to them.
3. The attacker waits for the victim to deploy their Cloud Function.
4. Upon deployment, the attacker modifies the function’s code to inject malicious payloads, thereby gaining remote code execution.
Victim Actions:
1. The victim deploys their first Cloud Function in a specific region (ensuring that no other function exists in that region, as the bucket would already be secured if one did).
2. The function’s code is inadvertently stored in the attacker's bucket.
Solution
To address this issue, Google adopted the same validation mechanism used in 2nd generation Cloud Functions, which ensures that the destination bucket for storing the function’s code belongs to the same project as the function itself.
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]