Do you run your secured workloads in the cloud? Countermeasures to prevent unauthorized access to ensure strong security boundaries to mitigate potential cross-tenant vulnerabilities in SaaS/PaaS applications
“There is no cloud, it is just a computer somewhere else” – Unknown
Companies are rapidly adopting cloud computing platforms for their IT infrastructure and services. Recent surveys indicate that over 90% of enterprises now leverage some form of cloud computing, with the majority utilizing public cloud solutions from vendors like Amazon Web Services, Microsoft Azure, and Google Cloud Platform.
In a cloud data center, many different customers share the physical hardware of the cloud provider through multi-tenancy architectures. Rather than assigning dedicated hardware to each customer, public cloud providers leverage virtualization and resource pooling to allow workloads from multiple customers to run on the same physical servers, storage systems, and network infrastructure. Customers rent a segment of the provider's computing resources as opposed to owning the full physical infrastructure. Cloud data centers are designed for multi-tenancy, with advanced isolation mechanisms to keep customer data and applications segmented logically despite co-locating workloads. But the isolation mechanisms are logical, not physical.
Cross-tenant vulnerabilities are a new type of security risk. We have started to see examples in the real world where bugs can enable malicious tenants to break the logical security boundaries, and escape their tenant isolation and access other tenants’ data. Tenable showed how insufficient access control allowed potential access to unauthorized access to cross-tenant applications and sensitive data (including but not limited to authentication secrets) on the Azure platform. And Orca Security discovered a critical security misconfiguration within AWS Glue that could allow an attacker to create resources and access data of other AWS Glue customers. The OWASP foundation has created project to “highly practical guidance for cloud developers to manage the risk of isolation escape by ensuring proper implementation of strong security boundaries, and thereby mitigate potential cross-tenant vulnerabilities in their SaaS/PaaS applications.”
We are going to talk about some countermeasures that you can take to ensure that even when your cloud provider fails to protect you, you have measures in place to protect yourself.
We’re assuming you’re encrypting your data at rest. Maybe this needs repeating, encrypt your data at rest. Encrypting data at rest is vital for regulatory compliance to ensure that sensitive data saved on disks is not readable by any user or application without a valid key. It is often as simple as a check box to enable in the cloud management console. Depending on the resource, it can be done easily in your Terraform files.
But encryption at rest is not quite enough. If you use your cloud providers provided Key Management Service (AWS KMS, Google Cloud Key Management, Azure Key Vault) you have a lower attack vector but you would still be susceptible to cross-tenancy attack, i.e., a cross-tenancy attack would need to be specifically working on the key-store and the encrypted cloud services you’re using. The only way to mitigate these risks is for you to be responsible for your own keys. In an AWS world, this is the difference between SSE-KMS and SSE-C. You need to consider choosing a different provider Hashicorp Vault, Github Secrets, etc.
All this information is found in the AWS configuration, which is either set up using an infrastructure as code tool, or via the web console as outlined above. Using CoGuard, you can either directly scan those IaC files, or get a snapshot of your current cloud configuration and scan for the respective setup there.
There is no argument older than: “But no one can reach that server!!!!!!!!!”. That is true, but especially this discussion about cross-tenant access should make you suspicious: What if one of the servers within the same network gets compromised? Then you have exactly this scenario. Hence, to have access control at every layer (aka defense-in-depth) is crucial. Ideally, fine-grained Role-based access that manages different authentication/authorization layers.
In AWS, you can use IAM policies to achieve that. For Kubernetes, there is an option to enable RBAC directly as well.
On the application layer, you can even sometimes have services that, by default, do not have authentication enabled. By default, MongoDB has no enabled access control, so there is no default user and password. RabbitMQ that has by default a username “guest” with password “guest” account.
In order to detect a service that may not have a proper authentication/authorization enabled, one has to look no further than the configuration files. IAM roles with too wide access (simply a “star”) are possible to be detected inside Terraform/cloudformation files, not enabling RBAC for Kubernetes is possible to be checked by the general Kubernetes configuration, and having some dangerous defaults like the ones in MongoDB or RabbitMQ can be detected within the mongod.conf or rabbitmq.conf. All configurations need to be checked/audited/scanned to truly ensure that defense in depth is achieved (this is our mission at CoGuard).
Labeling of data is a practice recommended in the NIST frameworks. In this scenario, you would know where in your cloud offering sensitive data is stored and what kind. In this way, you can double-down on further security measures there, and recognize if you may need to move it to some other option because the available measures are not sufficient (proper role-based access control, encryption with custom key, etc.). In this way, you can build your strategies accordingly and custom to your project.
At CoGuard, we assume that everything is sensitive by default. And any resources that may be ignored in a security review need to be specifically marked to be ignored, for example, because the configurations are only applicable in a dev environment. In order to avoid having the rules triggered, you can label files to ignore certain rules and avoid the failed checks showing in the final scan results. This is similar to how other dev tools, such as linters and SAST scanners, disable rules. The disabling of the rule is then tracked in the code-repository, and reasons are provided so that the rationale can be understood in the future (and always determined if it still applies).
If you have the resources, the ultimate protection is of course to only decrypt the data when absolutely necessary. There are few good frameworks out there to support homomorphic encryption (e.g. Google’s FHE) for applications, and some attempts are out there to put it into the operating system level. This would allow you to operate on encrypted data without decrypting it.
The current support for different applications is spotty at best. Using a FHE approach requires a lot of custom integration work. It likely only makes sense if you are handling top-secret data.
We assume that this becomes even more interesting since there are cases where data is just being used for training AI, and hence the computations could be performed without decryption. Using homomorphic encryption could have prevented the recent data leak of Microsoft.
CoGuard is best leveraged for auditing configurations. We scan IaC, containers, network and application configurations looking for actionable insights and recommendations on how to remediate vulnerabilities before they can be exploited by attackers. We look for hard coded secrets, API keys, passwords and other sensitive information. We scan IaC source code, file systems, container images and application settings for hard-coded secrets, misconfigurations, vulnerabilities and provide insights into security best practices and suggest remediation steps to ensure your infrastructure is secure and compliant.
Get started for free and scan your IaC for cross-tenant vulnerabilities.
