Azure Functions Privilege Escalation

Azure Functions Privilege Escalation

Azure Functions, a serverless computing service, is widely used by organizations to run their applications and workflows on the cloud. However, recent research by cybersecurity experts has revealed a critical vulnerability in Azure Functions that can enable an attacker to gain unauthorized access to sensitive data and escalate privileges.

In this article, we’ll dive into the technical details of the vulnerability and explore the steps that organizations can take to secure their Azure Functions deployments.

The Vulnerability: Privilege Escalation through Azure Functions

The vulnerability in Azure Functions stems from a REST API method that allows an attacker with read permissions (e.g., Reader role) to extract sensitive data from the filesystem running an Azure Function.

The Azure Interface provides the capability for users (those with Reader or higher privileges) to access files related to the Function App, including the code for the application endpoints (functions). Within the Azure Interface, under the section labeled App files, one can view the files present at the root of the Function App. These typically include requirement files and any auxiliary files you wish to make accessible for all underlying functions.

Within the individual functions (HttpTrigger1), one can navigate to the Code + Test section to review the source code for the function. Similar to the code found in an Automation Account Runbook, this function code is accessible to anyone with Reader privileges. Developers usually hardcode credentials such as API keys, Basic auth, JWT token etc. in source code, so It’s not uncommon to discover hard coded credentials in this section. This is also what we focus on during the audit. Sensitive data should be stored in a secure location, such as Key Vault.

Both methods of file access depend on an unpublicized API that can be located by monitoring your browser traffic while using the Azure Interface. The subsequent management.azure.com API endpoint employs the VFS function to enumerate files in the Function App:

https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Web/sites/{name}/hostruntime/admin/vfs/home/site/wwwroot/{functionName}/{fileName}?api-version=2022-03-01

By using this method, an attacker can read any file/directory (except those restricted to the root user such as “/root” directory) on the filesystem running an Azure Function. For example, an attacker can read the “/etc/passwd” file to obtain a list of user accounts on the system.

The vulnerability becomes critical when an attacker discovers interesting parameters stored in system environment variables. By essentially using the same REST API method but with a different URL path “/proc/self/environ”, an attacker can extract environment variables from the filesystem running an Azure Function.

The following command can be used to get the environmental variables, write it to a temp file and output it.

curl -X GET -H "Authorization: Bearer $(az account get-access-token | jq '.accessToken' -r)" -H "Content-Type:application/json" -H "Accept:application/json" 'https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Web/sites/{name}/hostruntime/admin/vfs/proc/self/environ?api-version=2022-03-01' > environment-variables.txt && cat environment-variables.txt

Once the attacker obtains the sensitive data, they can use it to escalate privileges and gain unauthorized access to the Azure Function.

The output reveals a number of interesting variables.

After opening SAS URL stored in the CONTAINER_START_CONTEXT_SAS_URI, the “encryptedContext” JSON blob was displayed.Conveniently, we possess the encryption key stored in the “CONTAINER_ENCRYPTION_KEY” parameter used for this data.

Utilizing CyberChef, we can swiftly assemble the components to decrypt the data.

Here’s how the recipe appears in CyberChef:

Once decrypted, we obtain another JSON blob of data, this time with only one encrypted segment (“EncryptedEnvironment”). We won’t be interacting with that data as the crucial information has already been decrypted below:

  • Master key (https://learn.microsoft.com/en-us/azure/azure-functions/security-concepts?tabs=v4#function-access-keys)
  • Function key (https://learn.microsoft.com/en-us/azure/azure-functions/security-concepts?tabs=v4#function-access-keys)
  • Connection strings
  • MSISecret
  • AzureWebEncryptionKey
  • WEBSITE_AUTH_SIGNING_KEY
  • Function’s specific secrets
  • Blob storage SAS URLs

It’s worth mentioning that the “MICROSOFT_PROVIDER_AUTHENTICATION_SECRET” will also be present if the Function App has been configured to authenticate users via Azure AD. This is an App Registration credential that could be beneficial for gaining access to the tenant.

While the jobs storage data provides a convenient route to access the Function App Storage Account, our primary interest lies in the Function “Master” App Secret, as it can be utilized to overwrite the functions in the app. By overwriting these functions, we can achieve full command execution within the container. This would also enable us to access any linked Managed Identities on the Function App.

Remediation: Steps to Secure Azure Functions

The initial report of this issue was submitted to MSRC on November 23, 2022.

There were several preliminary attempts at resolving the issue, but eventually, the vulnerable API was limited for the Reader role on January 17, 2023. On January 24, 2023, Microsoft retracted the fix after it led to some customer issues.

On March 6, 2023, Microsoft reintroduced the fix to address the problem. The global rollout was finalized on March 8. As of the time of writing, the Reader role no longer possesses the capability to read files with the Function App VFS APIs. It’s worth noting that the Linux escalation route remains a feasible option if an attacker has command execution on a Linux Function App.

We recommend to follow least privilege principle. It means that the user, role or group should have only required permissions. These permissions should be isolated (white-listed) only to resources that they need to interact with.

Review all managed identities and Azure service accounts and their permissions, and restrict them to the minimal permissions needed.

Avoid security risks posed by unused and reducible permissions by granting only the appropriate permissions. The appropriate permissions are the ones with the least-permissive access required by an application or user to perform their required tasks.

Regularly review and audit the configuration of Azure Functions and other services to identify and remediate any potential vulnerabilities.

Conclusion

The Azure Functions privilege escalation vulnerability highlights the importance of regular security assessments and audits for cloud-based services. Organizations should adopt a proactive approach to security by least privilege and security best practices, following the principle of and regularly reviewing and auditing the configuration of their cloud-based services.

By taking these steps, organizations can ensure the security and integrity of their data on the cloud and mitigate the risk of unauthorized access and data breaches.

About the author

Citadelo
Citadelo
Citadelo is a firm of ethical hackers on your side. We think like hackers, but we don't abuse it. On the contrary, our main goal is to reveal vulnerabilities without causing damage. We have been conducting simulated attacks for our clients since 2006
Show more from author

Related blogs