The inexorable movement of data and applications to the cloud that began several years ago and accelerated during the pandemic shows no signs of slowing down. The rationale for this transformation is driven by a desire to outsource non-critical functions (building and maintaining data centers, running and patching standard software packages) and to achieve business agility (scaling up, the ability to rapidly shift focus in light of market conditions).
Some of this migration is to public clouds such as Amazon Web Services (AWS) and Microsoft Azure. These platforms have brought the notion of the “shared-responsibility model” to the fore, related to the security and compliance of the overall solution. In this article, I consider the public cloud shared-responsibility model through the perspective of some recent security vulnerabilities found in public-cloud platforms, and the ramifications they had on users.
Here’s a sneak peek at the conclusion: Cloud service providers are not necessarily great at hardening the software images they supply to companies.
The Shared-Responsibility Model
As a picture is worth a thousand words, so here is the infographic for the AWS shared-responsibility model; and here is the one for Microsoft Azure. Both models try to communicate that “we take care of the basics while you take care of what’s under your control.” In other words, AWS will ensure that S3 buckets can only be accessed consistent with the policy governing their use – and it is the customer’s responsibility to set a policy appropriate to the data stored there. When delivering platform-as-a-service (PaaS) services on Azure, Microsoft’s responsibility is to ensure that the OS used to deliver the service is patched and hardened.
Now let’s consider how these models work in real life by looking at three security bugs and how they impacted customers, which we can characterize as the good, the bad and the ugly.
The Good…
Container-escape vulnerabilities enable an exploit to move beyond a container that an attacker has previously broken into. This is similar to an attacker crafting an exploit to escape a virtual machine (VM) and get into the hypervisor – thus gaining access to the contents of the underlying OS and other VMs running under the same hypervisor.
An example is CVE-2019-5736, a bug in RunC, a building-block project for the container technologies used by many enterprises as well as public-cloud providers. In 2019, it patched a vulnerability that would allow root-level code-execution, container escape and access to the host filesystem.
While the issue was reported more than two years ago, it is illustrative of a case where the shared-responsibility model worked to the advantage of public-cloud customers. The vulnerability and accompanying exploit were disclosed on Feb. 11, 2019, coincident with all the major cloud service providers patching the vulnerability. Organizations that ran containers in their own data centers had to scramble to patch their container OS images.
The Bad…
More recently, in August, Microsoft made public a vulnerability reported in Azure Cosmos DB, the scalable NoSQL database delivered in a PaaS model. The vulnerability was in the Jupyter Notebook feature of Cosmos DB and thus only affected customers who had that feature enabled. Unfortunately, the Jupyter Notebook feature had automatically enabled for all Cosmos DBs created after February of this year, thus even exposing customers who didn’t use the feature to a potential attack.
The Cosmos DB service is effectively multi-tenant. Thus, data from multiple customers is co-mingled in the same service instance. Access to specific data is limited by simple software constructs, which were subverted in this case. This means that an attacker could sign up for an Azure account, fire up a Cosmos DB instance and exploit it to access data from all other customers’ instances.
This is an example of a vulnerability which is only encountered in the cloud, as it exists in a bespoke Azure PaaS service. And it highlights the fact that just because a company isn’t actively using a particular feature (Jupyter Notebooks), that doesn’t mean it’s not exposed to vulnerabilities within that feature.
…and the Ugly
In September, Microsoft disclosed a series of vulnerabilities related to the Open Management Infrastructure (OMI) agent included in certain Linux virtual machine images it supplies to customers.
The OMI agent is included in VM images supplied to customers based on which Azure services the customer intends to use. Microsoft however did not document the presence of the agent — even though the agent runs at the highest possible privilege level. In some instances (with certain Azure services enabled), it accepts connections via HTTPS across the internet.
Collectively dubbed “OMIGOD,” the group of four vulnerabilities included one critical that rated a 9.8 out of a possible 10 on the CVSS bug-severity scale; it allows remote code execution.
This is a case where a lack of transparency in a different kind of software supply chain (the stock VM images supplied by a cloud service provider) opens the VMs deployed by a customer to an extremely consequential attack. As if to reinforce that point, attacks on this vulnerability commenced almost immediately upon disclosure of the vulnerability and mitigation/patching had to be a coordinated affair – with Microsoft patching the Linux images it supplies and customers needing to patch already running versions of the old images.
Takeaways
Being on public clouds is good when a sweeping vulnerability such as the container escape is discovered. Cloud service providers are generally great at mitigating such issues at scale and the mitigation often involves little work by their customers. There are, however, significant security risks when running workloads in the public cloud as well.
There is no guarantee that services delivered in a PaaS model are implemented in a hardened and secure manner. There is also great incentive for attackers to expend energy trying to break into such services as a discovered vulnerability is easily leveraged across a large set of targets.
Furthermore, the incentive of the cloud service provider (to remove barriers standing in the way of more usage) and that of a user (to enable the minimal set of features) don’t align. Thus, even Cosmos DB customers who never used or intended to use the Jupyter Notebook feature were exposed to a potential attack due to this dissonance in goals.
While it may feel easy to trust them to get the shared-responsibility model right, there are clear recent examples where the trust has been misplaced. Treat all software you receive from cloud service providers with a healthy dose of skepticism – scan them and account for every open port and all present software packages.
Oliver Tavakoli is CTO at Vectra AI.
Enjoy additional insights from Threatpost’s Infosec Insiders community by visiting our microsite.
