Nov 1, 2021
82 Views
0 0

Public Clouds & Shared Responsibility: Lessons from Vulnerability Disclosure

Written by

Newsletter
Join thousands of people who receive the latest breaking cybersecurity news every day.
The administrator of your personal data will be Threatpost, Inc., 500 Unicorn Park, Woburn, MA 01801. Detailed information on the processing of personal data can be found in the privacy policy. In addition, you will find them in the message confirming the subscription to the newsletter.
The administrator of your personal data will be Threatpost, Inc., 500 Unicorn Park, Woburn, MA 01801. Detailed information on the processing of personal data can be found in the privacy policy. In addition, you will find them in the message confirming the subscription to the newsletter.
Share this article:
Much is made of shared responsibility for cloud security. But Oliver Tavakoli, CTO at Vectra AI, notes there’s no guarantee that Azure or AWS are delivering services in a hardened and secure manner.
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.
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.
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.
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.
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.
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.
Share this article:
An alleged sports content pirate is accused of not only hijacking leagues’ streams but also threatening to tell reporters how he accessed their systems.
The old RLO trick of exploiting how Unicode handles script ordering and a related homoglyph attack can imperceptibly switch the real name of malware.
Aamir Lakhani, security researcher at Fortinet, says no sector is off limits these days: It’s time for everyone to strengthen the kill chain.



This site uses Akismet to reduce spam. Learn how your comment data is processed.
Join thousands of people who receive the latest breaking cybersecurity news every day.
An attack on the fuel distribution chain in #Iran forced the shutdown of a network of filling stations, leaving mot… https://t.co/pWDaUaFUQ2
5 days ago
Get the latest breaking news delivered daily to your inbox.
The First Stop For Security News
Infosec Insider content is written by a trusted community of Threatpost cybersecurity subject matter experts. Each contribution has a goal of bringing a unique voice to important cybersecurity topics. Content strives to be of the highest quality, objective and non-commercial.
Sponsored Content is paid for by an advertiser. Sponsored content is written and edited by members of our sponsor community. This content creates an opportunity for a sponsor to provide insight and commentary from their point-of-view directly to the Threatpost audience. The Threatpost editorial team does not participate in the writing or editing of Sponsored Content.

source

Article Categories:
Cloud Security

Leave a Reply