Download to read offline
Uploaded byCloud Village
One Click, Six Services - Abusing The Dangerous Multi-service Orchestration Pattern
The document discusses vulnerabilities in Google Cloud Platform (GCP) services, particularly focusing on privilege escalation risks associated with multi-service orchestration. Key issues arise from using default service accounts resulting in over-privileged access, creating opportunities for malicious exploitation. Recommendations include implementing custom service accounts with minimal permissions to enhance security during function deployments.
More Related Content
Similar to One Click, Six Services - Abusing The Dangerous Multi-service Orchestration Pattern
![[BDD 2025 - Artificial Intelligence] Building AI Systems That Users (and Comp...](https://cdn.slidesharecdn.com/ss_thumbnails/ai-buildingaisystemsthatusersandcompanieslove-251124030845-038f7732-thumbnail.jpg?width=640&height=640&fit=bounds)
![[BDD 2025 - Mobile Development] Exploring Apple’s On-Device FoundationModels](https://cdn.slidesharecdn.com/ss_thumbnails/md-exploringappleson-devicefoundationmodels-251124030840-d690542c-thumbnail.jpg?width=640&height=640&fit=bounds)
One Click, Six Services - Abusing The Dangerous Multi-service Orchestration Pattern
- 1. One Click, SixServices Abusing The Dangerous Multi-service Orchestration Pattern Liv Matan @ Senior Security Researcher, Tenable @terminatorLM
- 2.
- 3. 1 Click 6 Services 3 Cloud Function Bucket Cloud build Artifact Registry Container Registry Cloud run Eventarc triggers
- 4. IAM • Liv Matan– Senior Security Researcher @ Tenable • Microsoft’s Most Valuable Researcher • Hunt across the major cloud providers 4
- 5. Risks 5 Artifact Registry Cloud Function Bucket Cloud build Container Registry Cloudrun Eventarc triggers
- 6. Risks - NewPE Paths 6 Artifact Registry Cloud Function Bucket Cloud build Container Registry Cloud run Eventarc triggers
- 7. How Does ThisMagic Happen • Service agents: From Google Documentation: “Some Google Cloud services have Google-managed service accounts that allow the services to access your resources.” 7
- 8. Better Performance MoreComplexity More Risks → → • 2nd gen Cloud Functions! (and increased attack surface) 8
- 9. 1ST / 2NDGEN Cloud Functions 9 Cloud run Cloud Function Bucket Cloud build Artifact Registry Container Registry Eventarc triggers 2ND GEN 1ST GEN
- 10. Function Deployment Flow 10 Bucket Cloudbuild Artifact Registry Cloud Function Cloud run Cloud Functions Service Agent service-12345678@gcf-admin-robot.iam.gserviceaccount.com Cloud Build Default Service Account Build, Push Create resources
- 11. ConfusedFunction - ANew PE Vulnerability • Enables an identity with cloudfunctions.create/update to escalate privileges to the (very high) privileges of the Default Cloud Build Service Account • Because of the deployment flow and cross-services dependencies, these are high privileges on Storage, Artifact Registry, and others 11
- 12. ConfusedFunction - ANew PE Vulnerability 12 functions.update Bucket 2 Node.js Cloud Function 1 Cloud build npm install malicious-package 3 Cloud Build Default Service Account package.json
- 13. GCP Dangerous Defaults •GCP used the default service account in the function’s deployment instead of a customer-crafted service account with more limited permissions • This is hard to fix! The architecture requires these high permissions 13
- 14. Fix • A customservice account for the Cloud Build instance deployed as part of the function deployment process • Compute Engine service account as a new default for new Cloud Builds 14
- 15. • Minimum permissionsfor the custom Cloud Build service account to work: • roles/iam.serviceAccountUser— This role is not required on the service account, but the user that deploys the function needs this role. • roles/logging.logWriter— Required to store build logs in Cloud Logging. • roles/artifactregistry.writer— Required to store build images in Artifact Registry. • roles/storage.objectAdmin— Required to retrieve the function source from the Cloud Storage bucket, and to store build images in Container Registry. • The Compute Engine Default SA is notorious for being over-privileged Thoughts on the fix 15
- 16. The Security Architectureof AWS Lambda with Buckets 16 AWS Lambda AWS Managed S3 Bucket Customer’s Lambda Code
- 17. The Bigger Picture- Privilege Escalations 17 Artifact Registry Cloud Function Bucket Cloud build Container Registry Cloud run Eventarc triggers
- 18. Cloud Run AccessPE 18 Cloud run Cloud Function Artifact/Container Registry Cloud Function Service Agent Pull Function’s Image
- 19. Storage Access PE 19 Bucket Cloud Function CloudFunction Code Secrets Vulnerable Code
- 20. Jenganizer – ANew Tool 20
- 21. Using the GCPLog Explorer Example: Cloud Function 21
- 22. Vulnerability Patterns Inthe Cloud • 1 click in the console CSP is configuring a vulnerable deployment to → the user • Even the CSPs themselves get it wrong sometimes • Shared responsibility 22
- 23. Thank you! 24 Liv Matan@ Senior Security Researcher, Tenable Twitter: @terminatorLM
Editor's Notes
- #2 Cloud providers build their services on top of each other, creating risks, and new attack paths due to cross-service interactions and dependencies. It creates a Jenga-like effect, where one service falls or breached, the other ones are prone to be impacted as well.
- #3 Have you ever pondered with the question: What the hell is going on behind the scenes when you create a service in a cloud provider? Spoiler alert - too many things. When I started researching Cloud Functions in GCP, I inspected the logs in the logs explorer and noticed an odd Cloud Build trigger in my account - turns out it was initiated by the Cloud Function itself, is it though? Well, turns out a Cloud Build resource isn’t the only resource that was created in my account, also a storage bucket, an artifact registry or a container registry, and a cloud run resource.
- #5 - Behind every service: more IAM that you might get wrong - Every cross-service interaction is an attack surface
- #6 Well for example, if an attacker has access to cloud run, and cloud run has access to artifact registry, and the cloud function’s image is hosted on artifact registry, someone needs to secure this process. But how does it all happen? How does a service interacts with another service - iam wise? Well, obviously with regular service accounts that are equivalent to managed identities in azure or aws roles, OR, welcome service agents:
- #7 MS controlled managed identities or AWS service-linked role
- #8 Ok, so more complexity into the mix, more services correlated, more IAM. In Cloud Functions, GCP introduced 2nd gen cloud functions, that also includes cloud run and eventarc services in the mix. The cloud provider is trying to empower its services performance and usability, however, it complicates processes, and creates confusion, and new risks. Sometimes even new vulnerabilities - spoiler alert.
- #9 Have you ever pondered with the question: What the hell is going on behind the scenes when you create a service in a cloud provider? Spoiler alert - too many things. When I started researching Cloud Functions in GCP, I inspected the logs in the logs explorer and noticed an odd Cloud Build trigger in my account - turns out it was initiated by the Cloud Function itself, is it though? Well, turns out a Cloud Build resource isn’t the only resource that was created in my account, also a storage bucket, an artifact registry or a container registry, and a cloud run resource.
- #10 Let’s dive into the function deployment flow, so we now know who is responsible for the resources creation - the cloud functions service agent. Behind the scenes, the functions code is stored in a bucket, and the cloud build instance is packing an image of the cloud function’s environment and pushing it to an artifact registry. The interesting part here is that the cloud build service needs to somehow have the required permissions to push to the artifact registry, and also read the function’s code from the storage bucket. For that mission and purpose, GCP is attaching the Cloud Build Default Service Account to the Cloud Build instance they deployed for the function deployment flow.
- #12 GCP is attaching the default cloud build SA to each cloud build instance they create in a customers account for the cloud function deployment process - this is a misconfiguration.
- #13 This shows that it’s so complicated that even Google got it wrong
- #15 The vulnerability still lives to some extent keep in mind that storage admin is very powerful and guess what - the compute engine default service account also allows storage access.
- #16 What about other clouds? AWS for example, saves their customers lambda code, the equivalent of cloud function in GCP, in an aws managed s3 bucket. possible risks here as opposed to the gcp cloud function architecture? In my personal opinion, privilege escalations are very hard to prevent, and keeping the responsibility in the cloud provider’s side like in the AWS architecture where the customer’s function’s code is stored in an AWS Managed storage might be more secure. It depends on who you want to trust more - the cloud provider’s security, or your organization security, again, shared responsibility comes into play.
- #17 When looking at the bigger picture of this architecture of cross-service interactions, we are exposed to new privilege escalation paths, as researchers, and as defenders. I’m going to give you some unique ones I discovered through my research and by looking at the bigger picture. Back to the example of Cloud Run.
- #18 An attacker can pull any function image and execute it, thus, bypassing authentication to execute functions in account. However, since the execution environment stays in the same Cloud Run - the attached identity remains the same.
- #19 Storage access is the holy grail for an attacker in GCP, it’s a super popular permission, and numerous popular services can be abused with storage access In some cases it can become a whitebox party, since source code for compute services is stored in storage buckets. It can even get worse when an attacker has write permissions on buckets that store code to get RCE As we saw earlier, the compute engine default service account allows storage access and also the minimal permission required for the cloud build service account as part of the cloud function deployment process also includes storage access. So, the compute engine service account was used as a fix in the confusedfunction vuln, and it is also wide-spread as defaults in GCP – this combination of popularity and impact of having the permission, is disaster.
- #22 Is is the user’s responsibility? or the cloud provider’s one? essentially, it’s a complicated scenario. We would obviously call it out a vulnerability and give the responsibility to the cloud provider if the user didn’t have control over the resources. Here it’s a bit different, the cloud provider is deploying a vulnerable deployment that the user can be aware of, since the resources deployed are deployed in the customer’s account, and not in a different managed cloud provider’s account. For that exact reason, I had an idea of writing a tool to reveal those hidden resources that the cloud provider is deploying on each service creation - and my fellow teammate Noam Dahan wrote a POC for the tool in AWS.