Cybersecurity Vulnerabilities: the Problem With Containers 

Containers represent a lightweight and more agile method of increasing the speed and efficiency of DevOps, compared to traditional virtual machines. Application compatibility is not an issue anymore since containers are able to seamlessly connect various libraries and versions.

That is probably the reason why this approach has become so popular in such a short amount of time. Gartner estimates that next year, 70% of businesses will reap the benefits of containerized infrastructures. So, while developers, testers, and scrum masters are happy, there is one missing piece to this bright picture. Security.

One big issue with containers is that the widened distribution of an operating system environment also increases the attack surface. One infected library compromising the entire host and getting to the root is only one example of how dangerous containers might be if not handled properly. Quick detection of possible threats is available by using relevant MITRE ATT&CK mapping within tools like SOC Prime’s Cyber Threat Search Engine.

Along with that, security engineers can instantly translate search queries into vendor-specific formats by using Uncoder.IO, a free online converter based on SIGMAC. Maintaining continuous logs monitoring is crucial because while vulnerabilities in containers won’t go away overnight, this method of enhancing DevOps still has enough advantages for developers. So let’s take a look at the most common weaknesses of containers and try to figure out the best ways to avoid them.

Common Vulnerabilities in Containers

Besides vulnerable libraries that can potentially infect the rest of the workloads, there is a number of risks that are implied when we talk about platforms like Docker as well as orchestration tools like Kubernetes. It is important to understand the overall nature of container attacks and what adversaries are striving to achieve if you want to effectively mitigate cyber threats associated with them.

For starters, the initial access attack vector usually widely exploits the fact that software applications that are being deployed, rely on packages and components, as well as chains of dependency and commonly accessible libraries. Injecting malicious code is more than real for the attackers. To boot, the malware might go undetected and spread quite fast, resulting in a so-called supply chain attack. Using cyber-risk management platforms can help you with protection from new attacks.

Another concern is threats leveraging lateral movement and privilege escalation. Developers should be aware of the basic configuration of access management in containers and set up custom settings if needed, guided by a principle of least privilege.

Adrian Mouat, a chief scientist at a container advisory firm, argues that if configured properly, containers might end up being even safer than hardware devices or nevertheless popular VMs. At the same time, he outlines some main vulnerabilities that the security team should be aware of should they decide to use containers.

• Kernel exploits. Unlike VMs, if a container crashes the operating system it’s running on, it can crash all the other working containers as well.
• Poisoned images. Running an unreliable image can give the attackers access to both host and sensitive data.
• DoS attacks. All containers on the same host share kernel resources. Hence, one container can potentially take up most of them, preventing other ones from functioning partially or at all.
• Container breakouts. A user that has certain privileges inside the container, will have the same privileges on the host if it breaks out.
• Compromised credentials. To access a server or a service, a container has to use credentials like API keys or username and password combinations. Hijacked or compromised credentials might give attackers access to a whole system.

Now, when we are able to assess the broad picture of potential weak spots of containers, let’s review possible ways of executing safer policies in order to minimize the chances of adversaries exploiting containers.

How to Enhance Containers’ Security

While quite often containers are seen as software virtualization tools that lack security, from the other perspective, they can actually be used to enhance security. Because apart from portability and easiness of deployment, what you get with containers is the ability to run isolated processes.

Simply put, one software application can run on the same bare metal as another one, and even on the same operating system without knowing about each other. Quite often, teams in larger organizations also combine VMs and containers to create a set of virtualized structures that complement each other from both the hardware and software sides.

Initially, the danger hides within the image that is necessary to run a container. Because it is self-contained and might bring some publicly available stuff, there is no way of checking the image contents before running it. And that makes it possible to run malware hidden within those images. Vetting images might be a solution to this issue.

Another concern is the easiness of containers’ access to the OS. Since they don’t have a middleman like a hypervisor for VM, malware can break out of the container and gain access to sensitive data in other containers. Load containers into the cloud to avoid unnecessary leakage.

Multi-level security might also be an issue, especially if you are running hundreds or thousands of containers. It’s hard to imagine monitoring the security of all the traffic, sessions, users, applications, and processes including containers daemon, and so on.

The least that is necessary to do is to secure the daemon, make sure all the images are legitimate and secure the OS. And as always, restrict privileges and stop excessive API access where it’s not necessary.