Signing URLs in GCP: Convenience vs. Security
Why `iam.serviceAccounts.signBlob` permission can cause trouble in your GCP environment
If you've ever worked with a cloud storage service (e.g., AWS S3, or GCP Cloud Storage) you may know that creating signed URLs is one way to provide secure, temporary access to objects stored on cloud buckets.
A signed URL contains authentication information, has an expiration time, and allows users without credentials to upload and download bucket objects. Anyone who knows the URL can access the resource until the URL expiration time is reached.
Signing URLs for GCP
GCP provides several ways to sign Cloud Storage URLs:
- Signing with HMAC authentication
- V2 signing with service account authentication
- V4 signing with service account authentication
Signing with HMAC authentication is used for compatibility with other cloud providers.
V2 signing is a legacy method for signing URLs with service account authentication.
This article will concentrate on two methods to create a V4 signature, which is the recommended way to sign URLs for Cloud Storage bucket objects. Notably, these methods also work for V2 signatures.
Signing via service account key
One way to generate a V4 signature is to sign a “blob” (arbitrary bytes) with a service account key (read more about service accounts here). The key is essentially a private RSA key that can be created for your service account (see docs). Cryptographically signing data with the service account private key allows GCP to both identify and authenticate data (in our case, signed URLs) and associate it with the corresponding service account.
Keep in mind, as stated in Google documentation, managing service account keys implies a security risk if the keys aren’t managed correctly, and the responsibility for securely managing these private keys falls directly to you. In addition, for serverless environments, such as App Engine, Cloud Functions, or Cloud Run, service account keys are an inconvenient way to sign URLs because it forces programmers to manage the key and deal with its secure storing and rotation.
This fact induces developers to seek other solutions that let them create signed URLs using service account attached to a computing instance.
Due to these factors, developers seek other easier solutions which let them create signed URLs using a service account attached to a computing instance. The instance uses the service account to interact with Google Cloud API using a temporary token that can be obtained via metadata endpoints, all without managing service account static credentials.
The documentation provides detailed information on implementing this method in your program. Alternatively, you can use Cloud Storage client libraries that already use this method.
These articles and sources explain why and how to use this method in detail:
- Go examples: “Uploading images directly to Cloud Storage using Signed URL” Google Cloud blog article
- Python: “How to Generate Signed URLs Using Python in Google Cloud Run” Medium article and “How to generate a Blob signed url in Google Cloud Run?” StackOverFlow answer
To exploit these conditions, a malicious user must only compromise a service account token (i.e., via SSRF, RCE, or local file read vulnerabilities) with the iam.serviceAccounts.signBlob permission. To make matters worse, the signBlob IAM method cannot be limited by IAM conditions, so there is currently no method for developers to limit what service accounts can be used to sign data.
Because of the way Google Cloud functions, the chance of finding a default service account with high privileges is almost 100%. Default service accounts are created automatically when you enable or use Google Cloud services, and let the service access other Google Cloud resources.
When a default service account is created, it is automatically granted the basic Editor role on your project. The role includes almost all permissions related to the corresponding project, which leaves your account at risk of privilege escalation.
In this repository, you can find Terraform script and instructions on how to set up a vulnerable testing GCP project using the script. Then you can exploit the vulnerable project by following exploit steps in the README file.
News & Updates...
A peculiar case of dependency confusion potentially affecting 136M monthly package downloads
This final post summarizes the previous articles on Angular into a concise checklist.
We are happy to share our methodology and security guide on how to do security reviews of Angular applications. In this article we will talk about DOM manipulation and Open Redirects.