Check Point researchers recently published two vulnerabilities they’d found in Microsoft’s Azure cloud services. (https://research.checkpoint.com/2020/remote-cloud-execution-critical-vulnerabilities-in-azure-cloud-infrastructure-part-i/
). These flaws highlight a wave of potential attacks on cloud infrastructure and the exposure of workloads running in multi-tenant cloud environments.
The second attack among the two (CVE-2019-1372) targeted Azure App Services. App Services is a platform enabling developers and service owners to deploy applications at the package level and let Azure take care of providing the complete underlying infrastructure from bare metal to application service containers. The application instances run on different nodes and each node can run different applications from different customer accounts. In the Check Point example, an Azure customer account with trial license was created to run the researchers’ application.
The application ended up running on the same node as other applications from other paying customers. Azure, as expected from any multi-tenant cloud service, made utmost efforts to create a virtual environment for the application which was sandboxed and separated from others.
however, a management process, running on the same node, was vulnerable for a buffer overflow attack and could be exploited using a specially crafted message. This process is running on all nodes, communicates with the application processes, and has high privilege level due to its purpose.
The result is that a rogue actor can sign up with questionable credentials to Azure trial, run a specially crafted application in Azure App Services, and take the management process on a given node under his control. From this point, the attacker can see other applications running in the same node, access their data and infect them. Even access the network resources they have access to.
These types of attacks mean that companies running cloud workloads can be exposed regardless to vulnerabilities in their workloads or architectures. It underlines the key premise of zero-trust which is “don’t trust, verify” and shows how un-trusted workloads can be inserted into the environment not only from the application side, but also from the underlying infrastructure.
The strength of a zero-trust based solution, which continuously authenticate workloads before allowing them to connect and access resources, is in the fact that it would not need to protect against the above App Service breach in order to keep the client environment secured. More than that, it would provide a generic solution which is independent on future potential vulnerabilities in the infrastructure that are just not known yet. When attackers utilize the breach and take control of the privilege process, they will not be able to monetize it in order to connect or penetrate the client environment, as that process is not trusted in that environment.
Of course, not all zero-trust solutions are born equal. To be effective one needs to make sure the zero-trust solution put in place is able to continuously verify and authenticate workloads, does not require continuous re-configuration of micro segmentation policies, does not generate numerous false positives, and doesn’t not create a burden to DevOps and DevSecOps.
I happen to know such a solution