Know The Enemy: Common Vulnerabilities in Public Cloud

 

Taking advantage of the public cloud provides organizations with numerous financial and operational advantages. By outsourcing the management of infrastructure to a cloud service provider (CSP), the organization takes advantage of the cost savings associated with shared equipment and does not need to maintain and secure their own infrastructure.

However, cloud security can be a difficult challenge, and the use of the public cloud introduces its own challenges. To operate securely in the public cloud, organizations need to understand how cloud deployments differ from on-prem and the associated security implications.

• Remote Access Protocols

With cloud computing, a user does not have direct access to the machine that they are leasing. As a result, they need the ability to remotely access their cloud deployment. However, if remote access protocols are poorly secured, this can leave the cloud deployment open to attack.

The Remote Desktop Protocol (RDP) is a protocol commonly used for remote access to cloud systems. On Amazon, RDP is enabled by default but does not allow two-factor authentication (2FA) to be enabled to protect access. If a user’s credentials are compromised in a data breach or other incident, then an attacker could access their cloud deployment via RDP.

Secure Shell (SSH) allows users to remotely access the command line on cloud deployments. While SSH on Amazon cloud allows 2FA to be used, a poorly designed or implemented 2FA system could be bypassed or defeated by an attacker. Implementing a secure multi-factor authentication system is essential to cloud security.

• Supply Chain Vulnerabilities

Code reuse and the use of existing libraries are considered best practice. The use of existing open-source code can improve the efficiency of development and benefits from the fact that multiple parties can review it for errors in functionality and security. However, the fact that code is open source doesn’t guarantee that it is secure. 10% of the open-source components downloaded for use in 2018 contained known security vulnerabilities. By using these components in applications running on the cloud, an organization can open their cloud deployment up to attack.

Supply chain vulnerabilities aren’t limited to the applications running on the cloud. Cloud users often take advantage of Linux distributions to run on their cloud deployment. These distributions are also open source, and attackers have been known to gain access to the Github accounts hosting them in the past. If a Linux distribution on the cloud has a known vulnerability or a hidden backdoor, this can allow an attacker access to an organization’s cloud deployment. It is vital that an organization keeps software and operating systems up to date on the cloud to ensure their security.

• Misconfigured Security Settings

The cloud is a very different environment than an on-premises deployment, and many organizations have trouble with the shared responsibility model for security on the cloud. In a cloud deployment, the CSP has responsibility for security on the components that they control and the client must secure the rest.

One of the most common ways that this model causes problems is clients failing to properly configure the security settings provided by the CSP. Many data breaches are caused by the failure to make cloud deployments private (which is the default). Setting a cloud deployment to public makes it accessible to anyone with knowledge of the URL, and tools exist to search for these poorly secured cloud deployments. This issue has driven Amazon to provide additional security controls and visual cues to help cloud users properly configure their cloud security.

Security misconfiguration issues are not limited to problems with CSP-provided controls. When operating in the cloud, it is important to properly configure deployed security appliances as well, as demonstrated by the Capital One hack.

• VM Isolation Breakouts

On public cloud, cloud customers share physical infrastructure with other customers. A customer’s cloud deployment is contained within a virtual machine, and different cloud deployments are isolated from one another using software-based controls on the host machine.

Users of public cloud need to consider the fact that their data and processing may not be completely secret from other users. Attacks like Spectre, Meltdown, and RAMBleed can circumvent the software-based isolation controls by taking advantage of hardware vulnerabilities on the host machine. Since different VMs can use adjacent memory on the host machine, this could allow an attacker to read or modify memory across VMs.

However, an attacker does not need to use these hardware-based attacks to break VM isolation. Numerous VM breakout vulnerabilities have been discovered in the past, and exploiting one on a vulnerable cloud system could allow an attacker to gain access to the host machine. From there, they could access the memory of any VMs operating on the same physical machine.

The Importance of Cloud-Specific Security

Securing the cloud is very different from securing a traditional on-premises deployment. In an on-prem environment, the in-house security team has complete visibility and control over their systems and does not share infrastructure with untrusted third parties.

On the public cloud, the organization is operating on shared infrastructure without visibility or control over a significant component of their infrastructure stack. The structure of a cloud deployment also differs from on-prem environments, which can render traditional security solutions less effective. In order to effectively secure a cloud deployment against common threats, an organization needs to deploy security solutions that are specifically built for the cloud and have the ability to detect and protect sensitive data regardless of its location within the organization’s network.