How Leaked Environment Variables and Internal APIs Compromise Azure Managed Identities

TLDR: Researchers at Black Hat 2024 demonstrated that Azure Functions and Azure Machine Learning services often leak sensitive environment variables, including internal API endpoints and authentication secrets. By exploiting these leaks, an attacker can extract valid JWT tokens and storage account access keys to move laterally within a cloud environment. This research highlights the critical need to treat managed identity configurations as high-value secrets rather than default infrastructure settings.

Cloud security often relies on the assumption that managed identities are inherently safer than static credentials. The logic is sound: why manage long-lived keys when the cloud provider can rotate tokens for you? However, this convenience creates a false sense of security. If the underlying service hosting your code is misconfigured, those "secure" identities become a primary target for privilege escalation.

The Mechanics of the Leak

The core of this research centers on how Azure services like Azure Functions and Azure Machine Learning manage their internal environment. When a developer deploys code to these platforms, the environment is populated with variables that the service needs to function. These variables often include the MSI_ENDPOINT and MSI_SECRET, which are used by the service to communicate with the Azure Instance Metadata Service to request tokens.

The researchers found that these variables are frequently accessible to the code running within the container or virtual machine. If an attacker gains remote code execution—perhaps through a standard web vulnerability like command injection—they can simply dump the environment variables to gain the keys to the kingdom.

# A simple command to dump environment variables
env | grep MSI

Once an attacker has the MSI_ENDPOINT and the associated secret, they can impersonate the service. They are no longer limited to the permissions of the web application; they inherit the identity assigned to that resource.

From Token Theft to Persistence

The research goes beyond simple token theft. By analyzing the binaries responsible for managing these identities, such as the identityresponderd daemon, the team discovered that these processes often communicate with internal, undocumented endpoints. These endpoints are designed to facilitate the mounting of file shares or the retrieval of workspace secrets.

In the case of CVE-2023-28312, the researchers demonstrated that an attacker could interact with these internal APIs to extract sensitive metadata. The impact is severe: an attacker can obtain a valid JWT token for the managed identity, which can then be used from outside the Azure environment to access other resources, provided the identity has sufficient Identity and Access Management (IAM) permissions.

The persistence mechanism is equally clever. Because the certificates and private keys used by these agents are stored in predictable locations on the file system, an attacker with root access can exfiltrate them. Even if the service is restarted or the environment is partially hardened, the attacker can continue to use these credentials to authenticate as the service until the certificate expires or the resource is deleted.

Real-World Engagement Strategy

For a penetration tester, this finding changes the post-exploitation phase of a cloud assessment. When you land on an Azure-hosted service, do not stop at the application layer. Your first move should be to inspect the environment variables. If you find MSI_ENDPOINT or MSI_SECRET, you have effectively bypassed the need for further application-level exploitation.

During an engagement, you should:

1. Enumerate the environment: Check for any variables related to MSI, AZURE, or STORAGE.
2. Test the endpoint: Attempt to query the MSI_ENDPOINT to see if it returns a valid token.
3. Check for internal agents: Look for processes like dsimountagent or identityresponderd. If they are running, they are likely your path to higher privileges.

The risk is compounded by the fact that Azure AD sign-in logs often do not record the source IP address for these token requests. This makes it incredibly difficult for a blue team to distinguish between a legitimate service request and an attacker using stolen credentials from an external network.

Hardening Your Infrastructure

Defending against this requires a shift in how we view serverless security. First, follow the principle of Least Privilege strictly. If a function does not need to access a storage account, do not assign it an identity that has those permissions.

Second, treat your environment variables as secrets. If you are using Azure Key Vault, ensure that your application retrieves secrets at runtime rather than relying on environment variables that might be logged or exposed through a directory traversal vulnerability.

Finally, do not blindly trust the default configurations provided by the cloud platform. The researchers noted that CVE-2023-1056 was a result of an insecure internal configuration that allowed unauthorized information disclosure. Always assume that the underlying infrastructure is part of your attack surface. If you are building on Azure, verify the permissions of your managed identities and monitor for unusual token requests. The tools are there, but they are only as secure as the configuration you wrap around them.