Exploiting Shared Infrastructure: How Managed Data Services Leak Tenant Credentials

TLDR: Researchers demonstrated that managed data services like AWS Glue and Azure Synapse often run customer code in shared, restricted runtimes that are not as isolated as they appear. By exploiting RCE vulnerabilities within these environments, an attacker can escape the sandbox, access internal management APIs, and steal credentials belonging to other tenants. This research proves that shared infrastructure is a massive blind spot for cloud security, and pentesters should prioritize testing the boundaries of these "serverless" environments.

Cloud providers sell the dream of total isolation. You spin up a managed service, you push your code, and you assume the provider handles the heavy lifting of keeping your data separate from the neighbor’s. But as this research from Black Hat 2023 highlights, the abstraction layer is often thinner than we think. When a service is "managed," it means the provider is running your code on their hardware, often in a multi-tenant environment. If that environment is misconfigured or if the runtime itself has a flaw, the entire premise of tenant isolation collapses.

The Anatomy of a Cross-Tenant Breach

The core of this research centers on the concept of a "shared restricted runtime." In services like AWS Glue or Azure Synapse, the provider needs a way to execute user-defined scripts (ETL jobs) without giving the user full control over the underlying host. They use sandboxes to limit what that code can do. The problem arises when the sandbox is not a hard wall, but a permeable membrane.

In the case of AWS Glue, the researchers found that they could achieve Remote Code Execution (RCE) within the development endpoint. Once they had a shell, they didn't just have access to their own environment; they had access to the internal network of the managed service. By querying the Instance Metadata Service (IMDS), they confirmed they were not running in their own account, but in a provider-managed account.

The real breakthrough came when they discovered internal APIs that were not intended for public consumption. By interacting with these APIs, they could bypass permission checks and assume roles that belonged to other tenants. This is the holy grail for an attacker: moving from a single compromised instance to full access over other customers' data.

Practical Exploitation: From RCE to Credential Theft

The researchers used a clever approach to identify these vulnerabilities. They looked for "jar" files and internal service names that hinted at the underlying architecture. Once they identified a target, they used standard techniques like shell injection to gain a foothold.

For those of you running these tests, the workflow is straightforward but requires patience. You need to identify where the service executes your code and then use tools like jq to parse the responses from internal metadata services. Here is a simplified look at how they interacted with the internal environment:

# Querying the metadata service for credentials
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/

# Using the discovered role to list S3 buckets
aws s3 ls --profile victim

The demo showed that once they had the credentials, they could list S3 buckets and read data that clearly belonged to other organizations. This is a classic case of Broken Access Control, where the service fails to enforce the boundary between tenants at the API level.

Why This Matters for Your Next Engagement

If you are performing a cloud penetration test, stop focusing solely on the customer-side misconfigurations like open S3 buckets or overly permissive IAM policies. Those are low-hanging fruit. Start looking at the managed services the client is using. Ask yourself: where is this code running? Is it a shared runtime? Can I reach the metadata service?

The impact of these vulnerabilities is catastrophic. Because the flaw exists in the provider's infrastructure, a single exploit can potentially affect thousands of customers simultaneously. This is not a bug in the client's code; it is a bug in the platform they are trusting. When you find these issues, you aren't just reporting a vulnerability; you are reporting a systemic failure in the provider's isolation model.

Defensive Considerations

For the blue teams reading this, the reality is that you cannot "patch" the provider's infrastructure. However, you can reduce your blast radius. Implement strict network segmentation and ensure that your managed services are running within a Virtual Private Cloud (VPC) where possible. Use IAM roles with the principle of least privilege, and monitor for unusual API calls originating from your managed service identities. If a service is making calls to resources it shouldn't be touching, that is your primary indicator of compromise.

The cloud is not magic. It is just someone else's computer, and that computer has the same flaws as any other. As researchers, our job is to keep digging into these abstractions until we find the cracks. The next time you see a "serverless" label, don't take it at face value. Treat it like any other target, and you might just find that the wall between you and the rest of the cloud is thinner than you thought.