June 13, 2022

Escalating privileges in Google Cloud, from app to cloud access

A short blogpost that shows an exploitation scenario where an attacker, who has managed to gain SSRF or code execution capabilities, can leak tokens and escape to the Google Cloud platform.

Table of Contents

Introduction

Example app setup

     A vulnerable app

     (Ab)using the token to escape to the Cloud Platform

Conclusion

Introduction

Modern web applications require a host of additional services to function and fulfil their objectives. These additional services have historically been run within the same server, process or as obtuse functions within the same codebase. Over the last decade or so, these monolithic applications have broken away to lead the way for microservices based architectures which allow each major function of the applications logic to exist as an independent function having its own compute and resources.

Cloud service providers have used this need of running applications as micro services to build out managed services that are owned and operated by the service providers but with the data provided by the customer. From a hacker point of view, new attack surfaces have replaced older easier ones. The access between different microservices and the flow of data and commands is completely transparent to the user (and the attacker). It is therefore, an interesting (and often sought after) hacker objective to escalate privileges within the cloud and to escape to the cloud layer so that access to these other micro services and their data is obtained.

Example app setup

Let’s take a look at an overly simplified example of a web app hosted on the Google Cloud. The part of the application visible to the world is just the tip of the iceberg in most cases. As an attacker, the primary avenue of access would be through the web application. 

The web app interacts and accesses data and functionality across the cloud platform using access tokens that are either stored as environment variables on the compute instance or generated temporarily by accessing a metadata endpoint. Applications running on the VM use a service account that is attached to the compute instance to call Google Cloud APIs. 

Google Cloud Platform

When configuring a compute instance, a service account is attached to the instance whose permission level can be configured. The default setting of “Allow default access” allows access to a few services including read access to Cloud Storage. 

Identity and API access

However, the only way to access the service account token is from within the compute instance by making a GET request with the "Metadata-Flavor: Google" header to “http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token".

For an attacker, this would be possible via a Server Side Request Forgery (SSRF) that allows HTTP header control or a Remote Code Execution bug that would allow cURL or wget execution.

A vulnerable app

Consider the following application that serves as a simple app that fetches the HTTP headers of the domain that you provide. 

Fetch headers

Functionality of this type is often vulnerable to Server Side Request Forgeries (SSRF). However, since the functionality only retrieves HTTP headers, the actual functionality itself is not of great use to an attacker. The functionality, however, is also vulnerable to a command injection that allows an attacker to pass and execute arbitrary commands on the server.

A user input of ”example.org;id” shows the below output

output

This feature can be abused to make requests to the Google VM instance metadata endpoint at http://169.254.169.254/ OR http://metadata.google.internal/. 

Using a user input of example.org;curl -H "Metadata-Flavor:Google" "http://metadata.google.internal/", it is possible to interact with the metadata endpoint.

metadata endpoint

Next, making a request to "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token" will generate a token for the service account attached to the instance on which the app is running. This token can then be used to make requests to the Google Cloud Platform and escape to other services.

token that can then be used to make requests to the Google Cloud Platform and escape to other services

You can make a request to "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/scopes" to get a list of scopes the token is valid for. As mentioned earlier, the default scope token gives read access to Cloud Storage that can be used to then pilfer data.

request for getting a list of scopes the token is valid for

Note that all the cURL requests have the mandatory "Metadata-Flavor:Google" HTTP header, without which the HTTP request will fail.

(Ab)using the token to escape to the Cloud Platform

Once the token is obtained, it can be used in REST API calls to the Google Cloud to retrieve information.

Along with the Google project ID obtained from "http://metadata.google.internal/computeMetadata/v1/project/project-id", the token allows read access to buckets as shown below

the token allows read access to buckets

Individual files from buckets can then be enumerated and downloaded as well.

Similarly other services (for which scope is enabled) can be accessed using their API equivalents obtained via the Google Cloud documentation.

There are numerous tools also available that can be used with a token to identify what access is enabled, essentially making GET requests to every list and get REST API across Google Cloud services and see if which of them return data. 

Conclusion

Attackers are constantly on the lookout for ways of subverting defences and to escalate their privileges within any system. Apps hosted on the Google Cloud platform are common targets for attackers as any weaknesses in an app hosted on a compute instance could lead to additional access based on the tokens and credentials being accessible to an attacker post exploitation.

Service accounts attached to instances can often have more privileges than required. Even the default access scope allows for listing of buckets and reading the contents of bucket objects. As infrastructure owners, it is important to ensure service accounts do not have excess privileges, apart from ensuring no web application vulnerabilities exist that could provide server side access to attackers.

Following the principle of least privileges (POLP) and access can help prevent attacks that would allow privilege and access elevation from a web app to the Google Cloud platform.

***

This article is brought to you by Kloudle Academy, a free e-resource compilation, created and curated by Kloudle. Kloudle is a cloud security management platform that uses the power of automation and simplifies human requirements in cloud security. Receive alerts for Academy by subscribing here.

Written by:
Riyaz Walikar

Riyaz Walikar

Chief Hacker

Riyaz is a security evangelist, offensive security expert and researcher with over a decade of experience in the cyber security industry. His passion to break into some of the most well defended networks and systems in his career spanning 15 years has earned him a lot respect within the security industry. He has led Security Assessment and Penetration Testing teams at Pricewaterhouse Coopers (PwC) and Appsecco, and the Product Security Team at Citrix before co-founding Kloudle. Riyaz now specializes in cloud native, container and cloud security in general, helping build an easy to use security management platform to help companies enhance their visibility in the cloud, identify security misconfigurations and automate remediation for security gaps enabling compliance and operational security in multi-cloud environments. He is also an avid speaker and trainer and presents his research and findings at security conferences and community meetups around the world including BlackHat USA, BH Europe, BH Asia, nullcon and OWASP AppsecUSA.Specialties: Cloud (AWS, GCP, Azure, IBM, Others) Security, Cloud-Native Security, Kubernetes, Container Security, Web Application Security, Network and System Penetration Testing, Wireless Network Security, Malware Analysis and Reverse Engineering, Threat Modelling, Windows Forensics, Security Code Review, Vulnerability Research, Exploit Development and Reverse Engineering. Certifications: CKA, CKAD, OSCP

Read more