Serverless Tokens in the Cloud: Exploitation and Detections

This article outlines the mechanics and security implications of serverless authentication across major cloud platforms. Attackers target serverless functions in the hope of exploiting vulnerabilities that arise as a result of application developers deploying insecure code and misconfiguring cloud functions. Successful exploits of these weaknesses enable attackers to obtain credentials that can then be abused.

Serverless computing functions are often associated with cloud identities that use authentication tokens to gain temporary, scoped access to cloud services and resources. Exfiltrating these tokens can expose cloud environments to security risks.

Serverless computing is a cloud model where providers like AWS (Lambda), Azure (Functions) and Google Cloud (Functions) manage infrastructure, scaling and maintenance. This model enables organizations and their developers to focus solely on code, while the cloud provider handles backend tasks.

Operating on an event-driven basis, serverless functions execute in response to triggers like HTTP requests, database changes or scheduled events. The function service’s automated scaling adjusts resources to match demand, ensuring cost efficiency by the cloud provider only charging for execution time and resources used.

While serverless computing simplifies development and deployment, it is important to understand the potential risks associated with these services. Some of those risks arise from the fact that developers can assign identities to serverless functions, and those identities are manifested as credential sets that are accessible to the code executing within the function. These credentials are used for authentication and authorization to perform cloud operations.

These credentials are applied with a set of permissions that dictate their use. Depending on the permissions associated with the identity attached to the function, those credentials can enable access to cloud resources and sensitive data.

Attackers target serverless functions for these reasons:

• Serverless functions can often be vulnerable to remote code execution (RCE) or server-side request forgery (SSRF) attacks due to insecure development practices
• Serverless functions are often publicly exposed (either by design or due to misconfiguration) or process inputs from external sources
• Attackers can exploit serverless tokens to obtain unauthorized read/write access that could potentially jeopardize critical infrastructure and data

When using serverless functions, it is important to consider the risks involved when application developers deploy insecure code to cloud functions, and to understand the threats that target these functions.

Using the serverless approach, applications are deployed by executing functions on demand. The primary advantage of this approach is that applications or specific components can be run on an as-needed basis, eliminating the need for a continuously running execution environment.

Each of the major cloud providers shares similar concepts for serverless functions, such as:

• Support for multiple code languages
• The absence of SSH access due to their fully managed architecture
• Using roles, service accounts or managed identities to securely manage resource access

The IAM service in AWS enables the creation and management of users, permissions, groups and roles. The service is responsible for managing identities and their level of access to AWS accounts and services, and control of various features within an AWS account.

Serverless functions use Lambda roles, which do not have default permissions; IAM policies must be used to manage permissions and secure access to other AWS services.

To make permission management simpler, AWS provides managed policies (like AWSLambdaBasicExecutionRole) that developers often attach to these roles to quickly enable basic functionality.

Azure managed identities provide a secure and seamless way for Azure resources to authenticate to and interact with other Azure services without the need for hard-coded credentials. In the same way as AWS and GCP’s function services, these identities eliminate the risks associated with managing credentials in code.

System-assigned managed identities are tied to a single resource and automatically deleted when the resource is removed. On the other hand, user-assigned managed identities are independent resources that can be assigned to multiple services, offering more flexibility for shared authentication scenarios.

An Azure Function with a managed identity attached to it should use its managed identity token to authenticate to an Azure resource. The step-by-step authentication process is as follows:

This section discusses the risks and threats involved in the use of serverless functions. When developing and configuring functions, application developers should be sure to secure those functions against attacks like SSRF and RCE. In the absence of such security, attackers could manipulate serverless functions that are vulnerable to SSRF, causing the functions to send unauthorized requests to internal services. This can lead to unintended access or exposure of sensitive information within the system, such as access tokens, internal database content or service configurations. It is important to emphasise that these risks primarily arise when functions are public, or process inputs from external users and other sources.

In SSRF attacks, an attacker tricks a server (like a serverless function) into making HTTP requests to internal or external resources that the attacker shouldn’t have access to. Since the server itself makes the request, it can access internal services that are not exposed to the internet. A vulnerable serverless function takes a URL as input and fetches data from it.

In GCP, SSRF can be used to access the IMDS at hxxp://metadata.google[.]internal/, extracting short-lived service account tokens. An attacker can then leverage these tokens to impersonate the function and perform unauthorized actions within its IAM role’s permissions. Remote code execution vulnerabilities allow attackers to execute arbitrary code within a function’s environment.

For AWS Lambda, RCE attacks could expose temporary credentials stored in environment variables, such as AWS_ACCESS_KEY_ID and AWS_SESSION_TOKEN.

It is essential to note that these attack vectors are not inherent flaws in the cloud platforms themselves, but rather arise from insecure code written by application developers that could introduce vulnerabilities, such as SSRF or RCE. Application developers can mitigate these risks by implementing secure coding practices such as input validation.

The following simulations demonstrate possible ways attackers could extract serverless tokens and use them for malicious activities in different cloud service providers (CSPs). These attacks could leverage unsecure function code that was deployed by application developers.

To conduct this simulation, we deployed two Google Cloud Run functions that access the function metadata service and extract the tokens of the two different attached service accounts from the following path:

• hxxp[://]metadata.google[.]internal/computeMetadata/v1/instance/service-accounts/default/token

The first example demonstrates the extraction of a default service account. The second example demonstrates the extraction of a custom service account. These examples show how code can directly access the metadata service, just as a vulnerable SSRF code application could access it as well.

As shown in Figure 1, the service account attached to the function was the default serverless service account. Figure 2 demonstrates that the returned access token belongs to the same service account.

Figure 3 shows the custom service account that we attached to the function. Figure 4 shows the returned access token belonging to the custom service account. We then used the returned token to perform operations in the environment.

Figure 5 below shows an example of a command to list buckets.

If attackers can list and read bucket contents in GCP, they can access sensitive files like credentials, backups or internal configurations. This allows them to steal data, compromise the system or move laterally within the environment.

Once attackers obtain an access token for a service account with Editor permissions in GCP (such as the default Compute Engine service account), they can modify, delete or create resources across most services. This includes accessing sensitive data, deploying malicious workloads, escalating privileges or disrupting services. Editor access effectively grants near-full control over the project.

In this simulation, we accessed the environment variables of the Lambda function and extracted from it the AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY and AWS_SESSION_TOKEN.

Figure 6 shows the output of the Lambda function code.

Figure 7 shows the setup of temporary AWS credentials obtained from the previous step (the Lambda environment variables).

Then we used the following command to list all S3 buckets the authenticated session could access.

In this simulation, we accessed the environment variables of the Azure function and extracted the IDENTITY_ENDPOINT and the IDENTITY_HEADER by executing remote commands. Then we extracted the managed identity token from the local identity endpoint, providing these parameters shown below in Figure 8:

• Resource
• api-version
• X-IDENTITY-HEADER

Effective detection mechanisms are critical for identifying token exfiltration in serverless environments. These mechanisms focus on behavior anomalies to flag unauthorized activities. The following are some of the key detection strategies implemented across major cloud platforms.

Detection consists of two stages:

• Validating that the identity is attached to a serverless function
• Identifying anomalous behavior of the serverless identities. Such behavior could include:
  • Source IP addresses that do not suit the context in which the function is executing, such as addresses from Autonomous System Numbers (ASNs) that are not associated with a cloud provider
  • Serverless identities making requests with suspicious user agents

To identify service accounts attached to serverless functions in GCP, we analyze the serviceAccountDelegationInfo section in the logs. This information provides crucial insights into the delegation chain of service accounts. Specifically, when a service account is attached to a function, it delegates its authority to a default serverless service account:

• Google Cloud Run Service Agent (service-@serverless-robot-prod.iam.gserviceaccount[.]com)
• gcf-admin-robot.iam.gserviceaccount[.]com (service-PROJECT_NUMBER@gcf-admin-robo.iam.gserviceaccount[.]com)

These service accounts execute tasks on behalf of the function.

For example, in the log entry in Figure 9, we see the custom service account that was attached to a function (sa-test@.iam.gserviceaccount[.]com) delegating its authority to the Cloud Run Service Agent.

In Figure 9 above, the principalEmail field under authenticationInfo specifies the service account being used (sa-test[@]xdr-analytics.iam.gserviceaccount[.]com).

The serviceAccountDelegationInfo shows the first-party principal (in this case: service-@serverless-robot-prod.iam.gserviceaccount[.]com), indicating that the service account is operating within a serverless environment like Cloud Functions or Cloud Run.

An effective approach to discover serverless identities is to profile service accounts that have previously delegated their authority to default serverless service accounts. This ensures that even if non-default service accounts are attached to functions, they are identified.

In AWS, Lambda functions rely on IAM roles for secure access to AWS services. These roles generate temporary credentials. We can identify the Lambda identity by its role name.

In Azure, managed identities attached to Azure Function Apps are used for authentication.

In a secure cloud environment, serverless functions are typically intended to perform automated, scoped tasks such as responding to API requests or processing events. These functions are not to be used interactively. However, if attackers gain access to a serverless function’s environment or its identity, they might misuse it to run command-line interface (CLI) commands (e.g., gcloud CLI or curl) to interact with cloud resources directly.

One form of detection is to analyze the user agent of API calls. If the user agent matches known CLI tools (e.g., gcloud CLI) or penetration testing frameworks, it is flagged as suspicious, as CLI should not usually be used by serverless identities. This indicates potential exploitation of the environment or service account tokens.

Of note, this method of identifying remote use of serverless tokens according to the user agent cannot be performed in Azure, because user agent information does not appear in Azure logs.

Another approach for detecting remote use of a serverless identity token is to correlate the location of a token’s use with ASN ranges of known cloud provider IP addresses. If a request originates from an external IP address not associated with the CSP, it triggers an alert, highlighting potential unauthorized token usage outside the cloud environment.

Securing serverless tokens requires a combination of proactive measures, posture management and runtime monitoring security practices to minimize the risk of exploitation. First, implement the principle of least privilege by assigning roles with the minimum required permissions for serverless functions. This reduces the potential impact of token misuse.

Additionally, to protect serverless runtime environments in GCP and Azure, restrict access to IMDS by configuring network-level controls and applying request validation mechanisms. Ensure robust input validation and sanitization to prevent attackers from using exploitation techniques like SSRF to access sensitive metadata, tokens and other cloud resources like APIs and databases.

Serverless computing is the preferred choice for modern application development because it offers significant advantages in scalability, cost-efficiency and simplified infrastructure management.

The credentials that enable these functions to interact with cloud services are a critical security element and a prime target for attackers. Compromising these credentials can lead to severe consequences, including unauthorized access to cloud resources and data exfiltration.

Implementing proactive posture management and runtime monitoring protections is a crucial strategy in protecting cloud environments.

Organizations can better protect their serverless environments by:

Palo Alto Networks customers are better protected from the threats discussed above through the following product: