What if I told you that it was possible to compromise the multitenant Kubernetes clusters hosting Azure Container Instances (ACI) for a time, establishing complete control over other users’ containers within Azure?
Ya, that happened. The incident was called Azurescape.
Would you believe me if I told you that a cross-tenant vulnerability existed in Amazon Web Services (AWS) for a while, allowing attackers to abuse AWS AppSync to access resources in other organizations’ accounts?
Yep. That happened too. Security researchers at DataDog have a good writeup on it.
As an API hacker, you should be aware of the risks involved in accessing and exposing data related to environments that support multiple customers. Cross-Tenant Data Leakage (CTDL) is an emerging threat that API hackers should look closely at in multi-tenant apps and APIs.
In this article, we will discuss what CTDL is, how it can happen, and how to look for it.
Understanding Cross-Tenant Data Leaks (CTDL)
A Cross Tenant Data Leak (CTDL) refers to the unauthorized disclosure of data between clients through shared resources. Shared resources can be network resources, application servers, data stores, and APIs, among others. CTDL happens when data intended for one client is accessed by another client who is utilizing the same resources or infrastructure.
A common example you probably can think about is broken object level authorization (BOLA). By changing the URL of the application, you can access data that is not intended for you. But it can get much worse than that.
How CTDL can happen
CTDL can happen due to configuration issues where multiple tenants use the same infrastructure. For example, if a service provider sets up a cloud-based service for several clients but fails to configure it securely, CTDL can result. Additionally, CTDL can happen due to vulnerabilities in the application software itself, which an attacker can exploit to gain unauthorized access to data from other client accounts.
The point here is that there are several ways CTDL can manifest itself. So it’s important to approach your API security testing with an eye toward multi-tenancy testing. In other words, always ensure you have access to multiple accounts so you can test whether you can access data across a tenant boundary.
How to Detect CTDL in an API
There is no single methodology for detecting Cross-Tenant Data Leakage (CTDL) in an API. It all comes down to understanding what sensitive data and resources exist in the system, how it’s being protected, and determining how tenant isolation is being maintained.
Identifying sensitive data and resources
The first step is to identify sensitive data types that could be exposed, including personally identifiable information (PII), financial data, and proprietary information. This can be done by reviewing the API documentation and understanding the types of data that are processed and how they are accessed.
If the API documentation is hard to come by, consider following my guidance on how to generate your own rogue API docs. This will allow you to get a clear picture of how you would attempt to access the data and resources of a different tenant and what that data may look like.
Pay close attention to things like unique IDs, GUIDs, tenant names, and subdomain names that might act as tenant demarcation points in URLs, cookies, or access tokens.
Check for authentication and authorization issues
The second step is to check for unauthenticated access to data, which can be done by performing API testing with different user accounts and roles. This will help identify if there are any authentication or authorization issues that can result in data exposure across tenants.
I have a good article on how to use the Burp extension Autorize to look for authorization issues that can be useful here. While that article discusses finding vertical privilege escalation within the same tenant, you could use the same approach to check for horizontal privilege escalation across tenants and help find CTDL.
It’s important to look for weaknesses with role-level authorization, the misuse of resource-level access, and abuse of field-level authorization. I cover all this in my article about how to find access control issues in APIs. If you follow those steps while taking advantage of extensions like Autorize, you can let Burp Suite do a lot of the heavy lifting for you.
Pay attention to the security controls for tenant isolation
Depending on how the API is architected, there are several ways that you could come across data leakage.
Imagine being able to download PDF reports from a common URL. Behind the scenes, these PDFs may be stored in Azure Storage or an AWS S3 bucket. Or on the disk of a small web server. How is the API fetching the data? Does it include a unique identifier that represents the tenant in the URL? Is it dynamically constructed based on data in cookies or tokens? Can that be tampered with to allow you to fetch someone else’s data?
The same can be considered for any potential database queries an API may trigger. It is common to find that a database isn’t adequately sharded and isolated, which could allow access to other people’s data if the query can be manipulated to break out of the isolation.
Yes, once we start getting into manipulating SQL queries there is a huge cornucopia of data access exploitation that we may have control over. But sometimes, it’s more trivial than that.
I’ve encountered incidents where the security controls for tenant isolation were based on a tenant GUID found in the request’s URL, which was easily tampered with and exploited. The developers weren’t verifying that the GUID matched the tenant that the access token was issued to, giving me access to anyone’s data by simply changing the tenant id in the URL path. It altered the database query and gave me everything I needed. It’s really nothing more than another form of a BOLA vulnerability but with far greater implications.
Conclusion
So where we at?
Simply put, when data leaks from one tenant to another, that’s tenant bleed. That’s CTDL. It’s an impactful class of vulnerability that affects many multi-tenant apps and APIs.
Cross-Tenant Data Leakage is out there. I already mentioned a few disclosures in the wild at the beginning of this article. But there are many more.
Like the Azure Active Directory issue that Wiz Research found called BingBang. Or the vulnerability found in Azure Automation codenamed AutoWarp that Orca Security found. Or ChaosDB, the critical vulnerability in Microsoft’s CosmosDB that allowed attackers to access other tenants’ data.
And don’t think I am singling out Azure. AutoWarp affected AWS too.
And AWS has had other issues. Like leaking configuration across tenants in AWS App Runner. Or SuperGlue, a critical security issue in the AWS Glue service that could allow a threat actor to create resources and access data of other AWS Glue customers.
The list goes on and on. And that’s just two providers of multi-tenant apps and APIs. It’s happening all over the place.
CTDL is an emerging threat that API hackers need to be knowledgeable about. This article has discussed what CTDL is, how it can happen, and how to detect it in an API. Apply what you’ve learned here during your next engagement and see what you find.
You might be (un)pleasantly surprised.
Like what you read? Then make sure you download my free Ultimate Guide of API Hacking Resources.
