We are often told that the cloud is more secure than on-premises solutions. But is it really? Both are subject to similar risks and vulnerabilities, and the cloud can sometimes be more complicated than on-premises because of our unfamiliarity with deployment and patching.
Recent events have brought cloud risks into focus. Below is an overview of those events, the lessons to be learned from them, and other common cloud risks administrators need to understand.
Microsoft leaves door open to Azure Cosmos
Researchers at security firm Wiz recently announced that they were able to obtain complete unrestricted access to the accounts and databases of several thousand Microsoft Azure customers in their Cosmos databases. They could manipulate the local Jupyter notebook and escalate privileges to other customer notebooks containing several customer secrets including their Cosmos DB primary key. “The vulnerability affects only Cosmos DBs that had Jupyter notebook enabled and allowed access from external IPs,” the researchers wrote. They recommend several ways to identify and protect these Jupyter notebooks in another blog post, and CISA recommends that users of these services roll and regenerate the Azure certificate keys.
Azure Linux virtual machine vulnerability requires manual patch
Then the same researchers discovered a major issue that they called OMIGOD. Vulnerabilities were found in the Open Management Infrastructure (OMI), the Linux equivalent of Microsoft’s Windows Management Infrastructure (WMI). This service is silently installed on all Azure Linux virtual machines. It is not easily patched and at this time any newly installed Linux virtual machine is subject to remote code execution potential.
The Wiz researchers found 65% of customers were potentially exposed to risk. What’s even more disturbing to me as someone who monitors for patching issues is that this vulnerability is not only difficult to patch, Microsoft itself didn’t seem to fully understand the recommendations and processes to patch and protect machines. As the company notes in its blog, this app has no auto-update mechanism, so you have to perform a manual patch. Microsoft is in the process of updating a fixed version of the OMI to depend on a patched version.
The OMI and Azure Cosmos vulnerabilities show that even the biggest and best cloud providers can have vulnerabilities. The key takeaway here is to note how well cloud providers respond when those vulnerabilities become known.
Credentials left exposed on repositories
Another common way that cloud services are misconfigured or left insecure is the cloud equivalent of a sticky note on your desktop with the password written on it. Too often developers leave behind static or saved passwords in GitHub repositories. You’ll often hear people talk about “builds” and “versions” of code. This allows developers to keep track of the various versions as well as follow up with bug fixes. It also allows developer to leave behind notes in the margins, and sometimes that includes hard-coded credentials that attackers can then discover.
In June, GitHub added scanning for credentials to their tools. They’ve been scanning code for secrets that shouldn’t be exposed since 2015, but they added scanning for package registry credentials to ensure that these passwords can’t be found by attackers.
Cloud services security lessons learned
Developers and admins should always:
- Review which of the cloud services you use have external IP access.
- Evaluate the risks involved in external access and determine if there are other ways to protect that access.
- Set up for notifications from your cloud vendors to keep apprised of security issues.
- Stay aware of the security chatter and news regarding the development platform you use. In the case of Microsoft Azure, you can use the Microsoft Security Response Center landing page and filter on the product family of Azure for the tools you use. Cloud vendors will often fix the issue on their end and alert you if you need to install patches.
Small- to medium-sized businesses have options, too. Decide where you want your data to reside and determine if the vendors you use chose appropriate solutions. I often use the password policy of a site as a clue to let me know how responsive and responsible a vendor is. If there is a limit to the number of characters or a limit on the use of complex pass phrases, it’s a sign that the vendor is using an older authentication solution. If the site limits two-factor authentication to merely using a cell phone text feature and doesn’t offer an authentication application, it’s a sign that their authentication processes need to be better.
Many financial organizations offer only cell phone authentication as their two-factor option. Financial organizations are often the slowest in rolling out new technologies as their testing and requirements lead to long rollouts. Ensure that your financial information is at least protected by some sort of two-factor process.
Review if the vendors you use have set up bug bounty programs to ensure that researchers can disclose issues directly to them. For example, Microsoft has an online bug bounty program as well as one specific to Azure.
Review where the vendor draws the line as to what is their responsibility and what is your responsibility. Microsoft has several whitepapers on this concept of shared responsibility between the vendor and the developer. Review these documents to see what your vendors are supposed to be doing. In Microsoft’s case:
“For on-premises solutions, the customer is both accountable and responsible for all aspects of security and operations. For IaaS solutions, the elements such as buildings, servers, networking hardware, and the hypervisor should be managed by the platform vendor. The customer is responsible or has a shared responsibility for securing and managing the operating system, network configuration, applications, identity, clients, and data. PaaS solutions build on IaaS deployments, and the provider is additionally responsible to manage and secure the network controls. The customer is still responsible or has a shared responsibility for securing and managing applications, identity, clients, and data. For SaaS solutions, a vendor provides the application and abstracts customers from the underlying components. Nonetheless, the customer continues to be accountable; they must ensure that data is classified correctly, and they share a responsibility to manage their users and end-point devices.”
Finally, look at the vendor’s process to make its customers aware of cloud security issues. Do they recommend that you sign up for alerts when using their software? When installing the on-premises part of the cloud service, do they ensure that it always checks for needed updates when you use the application? Review what current users say about the software and how responsive the vendor is to their customer base. Reach out to other business decision makers as to their experiences with their cloud vendors. Does the vendor update its cloud services on a timely basis and how well do they inform you of these deployment mandates?
Bottom line, no matter where your data is, you’ll need to review how your vendors respond to issues. Attackers and researchers looking for cloud computing vulnerabilities. Become a more aware consumer of cloud services. Ask your vendors how they handle security and communication to you and your business. Monitor how fast your vendor responds to issues, not how many claims they give you that they are secure.
Copyright © 2021 IDG Communications, Inc.
