This article will make an overview of different Cloud vulnerabilities that appeared over the past year. First of all, before talking about Cloud vulnerability, we should define what is a vulnerability in Cloud context.

What is a Cloud vulnerability ? It’s essential to consider this question, because it allows us to identify a real cloud vulnerability from a simple misconfiguration.
A miss-configuration is the consequence of the use of a service without the security means set up by the Cloud Provider. Whereas a Cloud vulnerability is a weakness in a Cloud service allowing an attacker to undermine the integrity of this service, and therefore its normal operation.
It should be noted that during this Year, AWS, Azure and GCP released a lot of new services. Most of these services are audited and certified (PCI-DSS, ISO 27001, ....). However, these certifications do not mean that the services are infallible. It informs about the minimum level of security that can be achieved with a good use of the service.

Vulnerability Azure

The first vulnerability we are going to talk about is not a 2020 vulnerability, but it is one of the most critical for Azure over the last two years. It appears on October 08, 2019, with a magnificent score of 9,5 on the NVD website. This vulnerability affects the Azure App service.

Azure App Service is a service allowing to create and host web applications, mobile back ends and RESTful APIs, without having to manage any infrastructure. It offers automatic scalability and high availability, supports both Windows and Linux, and allows automated deployments from GitHub, Azure DevOps, or any Git repo.

The 2019-1372 vulnerability is critical because it allows an attacker to execute non-privileged code in an NT AUTHORITY/SYSTEM context.
The NT AUTHORITY/SYSTEM context is the highest level of your computer, they have full access rights on your computer, and allows you to install software with a very high level of privileges.

This vulnerability is critical and is due to Azure forgetting to clean up user entries. Without going into details, it can be exploited through a Heap overflow allowing the attacker to execute his code. ( Here is an article detailing how to use this RCE_Azure vulnerability).

So we saw a vulnerability on the Azure cloud provider, however Azure is not the only one to be affected, Google Cloud Platform too.

Vulnerability GCP

In this chapter we will talk about vulnerabilities on GCP and more specifically on the GKE service. Several vulnerabilities on the GKE service have been released during the year 2020, however as explained in the introduction we will only focus on the vulnerability specific to the service and not to the operating system (such as Windows with Netlogon, and the Linux kernel).
These two medium criticality vulnerabilities are CVE-2020-8559 and CVE-2020-8555 .

The CVE 2020-8559 is rated 6.4. It allows an attacker to perform a Man In The Middle between a Kubelet and the client.

A Man In The Middle is an attack that aims to intercept communications between two parties, without either party suspecting that the communication channel between them has been compromised. It is often used to obtain the victim's identification tokens and thus steal the victim's identity. However, it is normally difficult to do because it requires being on the same subnetwork as the victim. For example a wifi hotspot at a train station or an Internet cafe.

In our case it is only effective if the attacker has already compromised a node, and your cluster has an authentication method such as a certificate or authentication credentials. The attacker will be able to steal these tokens and pretend to be the victim to the kubernete instances.

This first vulnerability allows a better understanding of why it is very important to use secure communication channels. However, it should be noted that this vulnerability is very hard to exploit, because the requirements are difficult to obtain in the GKE context.

The CVE 2020-8555 is a vulnerability noted 6.3. It affects the kube-controller-manager in its version v1.0-1.14. and allows to extract up to 500 bits of information per request on an unprotected endpoint of the host network by performing a Server Side Request Forgery (SSRF).

Server-side request forgery (also known as SSRF) is a web security vulnerability that allows an attacker to induce the server-side application to make HTTP requests to an arbitrary domain of the attacker's choosing.
A successful SSRF attack can often result in unauthorized actions or access to data within the organization, either in the vulnerable application itself or on other back-end systems that the application can communicate with.

In order to be able to use this attack the attacker must follow these steps:

1. An attacker with permissions to do so creates a pod
2. The attacker attaches a volume to the pod. This volume can be one with certain built-in Volume types (GlusterFS, Quobyte, StorageFS, ScaleIO). An attacker with permissions to create a StorageClass can use this capability to the same effect.
3. By using the volume attachment or storage class creation, the attacker makes the kube-controller-manager k8s component make GET requests or POST requests without an attacker-controlled request body from the master's host network.

This attack still requires sufficient rights to create a pod. It is therefore not necessarily so obvious to use. Thanks to these two vulnerabilities we have seen a rough outline of the diversity in attack that can exist on GCP. However it should be noted that these attacks are mostly difficult to execute because it requires a high level of access.

Conclusion

We have seen that there are vulnerabilities on the different cloud providers, although they are limited at the moment. Cloud providers such as GCP, AWS, Azure are globally and for the moment well secured. By comparison, there have been at least more than 350 vulnerabilities on windows since 2019.
The Cloud brings a new way of looking at security, with security shared between the cloud provider and the user (company or individual). The Cloud provider is the owner of the infrastructure, the hypervisor and the physical network. The company remains the owner and responsible for the data, applications, virtual network, operating system and account/environment access.

It is important to see security in the Cloud as a whole with the application part, data encryption, role and access management with IAM and Role Based Access Control (RBAC).
However, as with any technology, security depends essentially on how it is used.

Source :

https://github.com/kubernetes/kubernetes/issues/92914
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8559
https://nvd.nist.gov/vuln/detail/CVE-2020-8559
https://nvd.nist.gov/vuln/detail/CVE-2020-8555
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8555
https://blog.alcide.io/new-kubernetes-control-plane-vulnerability-cve-2020-8555
https://research.checkpoint.com/2020/remote-cloud-execution-critical-vulnerabilities-in-azure-cloud-infrastructure-part-ii/
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-1372
https://cloud.google.com/kubernetes-engine/docs/security-bulletins