As a kind of lightweight virtualization technology, containers run in the operating system kernel of a host. Therefore, traditional security issues remain in hosts and networks. Besides, container escape risks, container image risks, virtual network risks, and configuration risks will become new security threats facing containerized infrastructure.
Attacks on Container Images
With the prevalence of the container technology, container images have become an indispensable part of the software supply chain. However, container images that business relies on, whether containing security vulnerabilities or malicious code, may cause more serious consequences than external attacks from hackers.
Image vulnerability exploitation
If an image contains a vulnerability, a container created via this image also has the same vulnerability. An attacker can execute attacks more efficiently if exploiting the vulnerability in an image to target the container.
A vulnerability CVE-2019-5021 is found in the Alpine image favored by developers . In the Alpine image 3.3 through 3.9, the password of user root is left empty. Upon a compromise to a container created via a vulnerable image, attackers could exploit this vulnerability to escalate their privileges to container root.
Image poisoning
Image poisoning is a broad topic. It refers to the act of an attacker breaking into or taking advantage of a victim’s host to carry out malicious activities in a certain manner such as uploading an image to a public repository, uploading an image to the victim’s local repository upon a system compromise, or crafting an image with a similar name as the legitimate one, to trick the victim into using the malicious image to create and run a container.
For instance, in June 2018, a study showed that an account named docker123321 uploaded 17 malicious images that contained cryptomining code to Docker Hub. By the time Docker Hub removed these images, these images had been downloaded more than 5 million times in total. According to statistics, hackers, through these malicious images, have obtained Monero coins worth US $90,000.
Container Escape
Similar to virtualization technologies, escape is one of the most severe security risks that threaten the security of underlying hosts and the entire cloud computing system.
Risky configurations result in container escape
If a user provides certain risky parameter configurations for containers not in his or her complete control, it is possible for attackers to escape the containers.
Risky mounting results in container escape
In certain scenarios, users will mount external sensitive volumes to a container to implement certain functions or facilitate operations. For example, it is easy to escape the container if the Docker Socket file (/var/run/docker.sock) is mounted to a container controlled by the attacker. Alternatively, an attacker could directly mount a host disk in a container and switch the root directory to escape the container.
Program vulnerabilities lead to container escape
Servers and clients involved in the container ecology inevitably contain vulnerabilities, for instance, the container escape vulnerability CVE-2019-5736 in runC.
Kernel vulnerabilities lead to container escape
In recent years, the Linux system has countless kernel vulnerabilities exposed, many of which can be exploited for privilege escalation. A good example is a DirtyCow vulnerability (CVE-2016-5195). By writing shellcode in vDSO and hijacking the invocation process of a normal function, an attacker that successfully exploits this vulnerability could obtain reverse shell on a host to escape the container.
DoS Attacks
The container runtime, by default, does not limit the resource usage of the processes in the container. Also, Kubernetes, by default, has no limit on the usage of resources such as the CPU and memory of pods created by users. In this case, attackers could run a malicious program in a container or launch denial-of-service attacks against a container to consume considerable host resources and affect the normal operating of hosts or other containers on hosts.
In addition to the preceding typical security risks, configuration security, privilege control and isolation, and network security of Kubernetes and other orchestration platforms also have an impact on the security of the whole cloud native infrastructure.
Shift Left to Find Security Issues in the Earliest Time Possible
In an agile development system represented by DevSecOps, development security and operations security are integrated. The security operations owner (usually CIO or CISO) has to consider how to maximize the overall IT security protection capability within a given security budget.
In a cloud native architecture characterized by short-lived containers and complicated business and networks, the existing physical or virtual security devices fail to deliver good adaptability, entailing high costs during security detection. The shift-left approach is intended for organizations to make convergence analysis of security vulnerabilities and fix them as soon as possible by devoting more security resources and taking security actions earlier in the software development lifecycle.
Generally, cloud native security encompasses secure coding, supply chain (software library and open-source software) security, and image (repository) security. These resources are mostly white-box, demand less investment, and have a long lifecycle. If security is assured for such resources, it is hard for attackers to gain persistence even if they launch successful attacks.
Related Link: What Is Cloud Native Security
