Tenant hopping and its security risks in the cloud

Hybrid and multi-cloud environments have ushered in a new era for business, one that includes greater efficiency, more sophisticated data analysis, lower costs and stronger security for tenants (customers). In these instances, tenants are distinct from individual users where multiple users from a single organization, company, or group are from a single tenant. In these environments, the cloud uses a pool of shared resources and divides them among multiple tenants, with different levels of customization available for each.

The concept is the same in software architectures such as software as a service (SaaS) where a single instance of an application gives access to individual tenants. In both cases, the tenant’s data is separate from other tenants despite accessing the same cloud environment or same software as other users.

Multitenancy is an important feature of cloud computing and reduces the usage of physical devices saving customers time and money, but it’s not without its own risks and weaknesses. The most significant risk multitenancy environments have is the risk of a potential breach of tenant’s boundaries, or in other words—tenant hopping.

Tenant hopping allows threat actors to move laterally between customer environments and applications. This can affect infrastructure platforms and/or software and could lead to the compromise of confidentiality and integrity of data of multiple organizations, making it one of the most dangerous risks confronting SaaS and Cloud providers today. A tenant hopping attack can expose a weak security posture.

Sounding the Alarm

One very alarming example was raised over two years ago when a vulnerability within the Microsoft Azure Portal was discovered that could have potentially resulted in the takeover of an Azure environment.

Researching the Azure Portal, we saw telemetry reports and requests that included access tokens being sent to a non-existing domain. The access tokens in question included the user’s permissions and were valid for any Azure resource—virtual machines, storage servers, traffic managers, etc. Token leakage in this instance could have given attackers access to and the ability to compromise numerous Azure accounts. Luckily that didn’t happen, but it could have.

It’s a simple bug, but if a vendor builds an application on a compromised cloud, that vendor now has a bug, and it might be leaking tokens. These leaked tokens could allow the attacker to alter the application logic and compromise the internal data of the vendor or—in a worst-case scenario—take control of the vendor’s identity management which will open the door to all assets and data.

Azure environments—like many other environments—often contain highly sensitive information, making them prime targets for attackers to snatch privileged user credentials and take control of virtual machines, storage servers and customer data. The culprits could then encrypt this data with ransomware, or expose all passwords, secrets and confidential data.

Here’s another example: Azure allows customers to run applications and define configurations to connect to other Azure services, such as Cosmos DB, and Azure’s NoSQL database service. Azure also allows organizations to manage their own identities. So, if I’m an attacker, I can register a trusted non-registered domain and simply listen to incoming tokens and use them to connect back to the environment, escalating privileges not only to application level but also to infrastructure-level permissions. I can also now control whatever is hosted under that account potentially leading to a compromise that rapidly affects untold numbers of companies and people if the vendor manages other applications on the same account.

Staying Ahead of Tenant Hopping

Tenant hopping is a big risk and there isn’t a simple solution or an easy security control to address the attack surface. To reduce the risk of one misconfiguration or an applicative bug turning into a tenant hopping vulnerability, it is advised to make a fine boundary—manage apps and data in one place and cloud providers and identities in another. Making this solid boundary will contain exploitation of the bug or misconfiguration to the data and assets hosted in the same environment, in the worst-case scenario. But it will not expose privileged identities that could be utilized to the detrimental compromise of the whole environment.