Introduction
Containers and container adoption is expected to reach a $4.5 billion market cap by the end of 2022 according to a survey by the 451 Research Group. Cloud-Native Systems are one of the hottest trends in the cloud computing ecosystem, quickly becoming the new normal for application/software development. In this blog series, we will address current security challenges in container security and generic/container-specific security threats for Docker and Kubernetes. New and emerging products are built around containers, among to transform how applications are developed and delivered using the DevSecOps methodology. Such a methodology is based on continuous development, integration, and a scalable deployment model. As you are modernising your enterprise, how do you mitigate the risks surrounding container security?
4Cs of Cloud Computing
Let’s take a look at the cloud computing architecture. The 4Cs of Cloud Computing are Code, Container, Cluster, and Cloud. They make up the cloud computing architecture for modern software/application development. With the increasing adoption of containers, security is a key component of software development. Securing these 4 layers are crucial for maintaining the layered security approach adopted by the industry as a whole.
Containers
There’s a general misconception when it comes to containers and containerisation. So why exactly are containers used as opposed to Virtual Machines? The key difference lies in the reality that hypervisors enable hardware-level virtualization, this allows for the provisioning of virtual machines as opposed to containers. Virtualisation happens at the hardware level, containers, however, are hosted on top of the host operating system to enable lightweight, portable and reliable access to “code” that can be deployed across several platforms efficiently.
Difference Between Virtualization & Container Architecture
What is a Container?
According to Docker’s Definition,
“A container is a standard unit of software that packages code and all its dependencies so that the application runs quickly and reliably from one computing environment to another”
In practical terms, this provides developers with several advantages.
Containers can be seen as virtualizing the operating system, run times, libraries, any other third-party dependencies, and the software code (as a unit). Secondly, containers solve problems around isolation of infrastructure, image size, portability, agility, and delivery of software, leveraging a modern development pipeline to achieve fast and reliable software development.
Regarding Kubernetes, it is FREE and open-source software (FOSS) to orchestrate containers at scale. Kubernetes is free and can be downloaded from its repository on GitHub. Administrators must build and deploy the Kubernetes release to a local system or cluster in a public cloud, such as AWS, Google Cloud Platform (GCP), or Microsoft Azure.
Security Challenges
Security remains one of the top challenges for container adoption across small and medium enterprises.
Monitoring is also on the list of top challenges for container adoption. Today, a lot of sensitive/critical production workloads are deployed in containers. A CNCF Survey shows that there’s a significant increase in the use of containers in production. About 84% of respondents said they were running containers with production workloads. However, existing security products used by many offer no visibility to cloud or container deployments, making monitoring all but impossible.
With an increase in containers being deployed in production, they become a hot target for hackers. As with any new technology, increased adoption leads to an increase in criminal interest. Bad actors/threat actors who learn container exploits, escapes, privilege escalation, and lateral movement tactics will present a growing threat to the security of containers deployed in production. Having addressed the production aspect, it is to be noted that development environments are still a ripe hacker target.
When it comes to securing containers in terms of architecture, we will adopt a zero trust model which emphasizes the core message – “trust, but verify”.
One of the predominant examples of container security threats is container malware. Example: Kinsing Malware Campaign, which targets misconfigured Docker API ports through malware reported by security researchers from Aqua Security. The campaign exploited the docker ports to run a malicious Ubuntu container.
For evasion and persistence, the malware utilized the shell script d.sh that did the following:
- Disabled security measures and cleared the log
- Downloaded and ran the shell script every minute using crontab
- Halted and deleted files related to numerous applications like other malware and cryptominers
- Installed and ran the Kinsing malware
- Killed other malicious Docker containers and deleted their image
- Looked for other commands running and cron; if cron jobs are found, it deletes all cron jobs including its own.
The usage of unprotected Docker API is the baseline of the malware campaign because this connection allows a hacker to run the Ubuntu container that includes a shell script that disables all the features and programs that may interfere with cryptomining malware activities. Another script that is released before any Kinsing payload execution collects information from host and configuration history folders on the infected host. These files can be used to infect the network and spread laterally throughout the network.
The last stage of the attack involves the downloading and deployment of the cryptocurrency miner malware after particular commands from the C&C server get received. This is the main purpose of Kinsing malware because it is a great way to make a profit from victims without actually contacting them and the mining operation can remain undetected for several months.
Current Challenges in Container Security involve insecure Container Images, Container Registries, Container Runtime, Container Orchestration, and issues regarding the Host OS (operating system) security. In this article, for brevity and to keep it simple, we will address container image security and container runtime security only. The other topics will be taken up in subsequent articles in the blog series.
Container Image Security
Container Image
Container images form a critical part of the container ecosystem discussed above. At its most fundamental level, an image is a read-only software package that contains everything an application needs to run. This is advantageous for several reasons, they are incredibly convenient and speed up development and deployment. They also use very little in the way of hardware resources traditionally.
The image contains all the dependencies, application code, system libraries, and settings for the application within a container. However, it is this that has drawn the attention of threat actors who scan for vulnerabilities in the dependencies, libraries, and even the container itself. For organizations making use of multiple images maintaining all the dependencies and libraries can prove difficult as an image can include any number of dependencies and libraries.
Data relating to threat actors exploiting vulnerabilities within images is staggering. One report showed that of the 4 million images analyzed 51% of them were found to contain exploitable vulnerabilities. In practical terms, this can result in serious cyber incidents. In one case, 20 compromised Docker images spread to the malicious cryptominer. In total, the cryptominer was downloaded almost 20 million times from those 20 compromised images.
For that reason, organizations must make vulnerability scanning within images a priority and a habitual task. Some modern security solutions are capable of doing this but if the organization relies on legacy security software of SIEM services there will be little visibility into cloud containers.
Container Configuration
Another issue discovered by researchers resulting in compromised containers is how the root account is managed. The root account has the most privileges within a container allowing the user to modify any data stored and run. Further, if a root account is compromised malicious code can be executed to install malware or access sensitive data stored within the container. Too often all those responsible for developing and maintaining a container have root access.
In properly configuring containers root access should be highly restricted and those employed in developing and maintaining the container should receive privileges suitable to their roles. While this might be a bit of an admin pain it certainly improves the security stance of the container tenfold.
Another area where containers are misconfigured is when they are assigned the “privileged” flag. Similar to the root account, the privileged flag allows a developer access to the host elements such as devices and other pieces of hardware. If compromised such access is a dream come true for a threat actor.
Security researchers have also noted that access to the container is also an area of concern when it comes to container configuration. To prevent exploitation and allow unrestricted access to a container all SSH and web page connections to the host machine should be monitored and recorded, and all root accounts should be managed, stored, and regularly rotated in a secure vault.
Conclusion
In this article, we learned about containers, their architecture and the common security challenges in general. Next part (Part 2) of this blog series will cover, Docker specific vulnerabilities such as runC code execution, how log4j shell affects the docker container, docker daemon vulnerabilities, linux/host specific configuration vulnerabilities. Lastly we will look at how to ensure container immutability and docker related best practices.