Unpacking Containers to Find Network Vulnerabilities

Containers have seen explosive growth in the last few years. Alongside this growth have come many high-profile news stories about container vulnerabilities. The CVE-2019-11247 vulnerability disclosed last summer that affected Kubernetes application programming interfaces (APIs), for example, highlighted the need for organizations to focus on ensuring more than just the core of components of Kubernetes are secure.

Similarly, the CVE-2018-15664 vulnerability disclosed recently describes a bug in Docker containers that could be employed to enable malicious code inside a container to gain arbitrary read/write file access on the host with root privileges.

These vulnerabilities have made some devs wary about employing containers. But is that justified? Given the huge rise in their deployment and the number of threat intelligence staff working on them, it’s not surprising that vulnerabilities have been found. On the other hand, there are certain patterns in the most vulnerable areas of container security that devs should definitely be aware of.

In this article, we’ll look at the highest-profile container vulnerabilities, and see what we can learn from them.

The Most Dangerous Container Vulnerabilities

Here, we’ve collected the identified container vulnerabilities with the highest impact. To find more information on each vulnerability, check out our archives:

What We Can Learn

Without running through the technical details of each vulnerability above, putting them together in this way reveals a number of key points about container security.

The first is that many of these vulnerabilities are not caused by containers themselves. Rather, key components in the toolchain and stack, if they themselves are vulnerable, can introduce security holes into containers (and even container engines).

Of particular concern is the way that payment processors interact with containers—many of these payment systems do not integrate well with containers and can introduce vulnerabilities into them that undermine the security of entire stacks. Any payment processor you or your business uses should absolutely come with encryption at the bare minimum for security.

This problem runs even deeper. The CVE-2019-1002100 vulnerability, which affects the API Server Patch Permission for Kubernetes, threatens to undermine the security of entire toolchains because Kubernetes acts as the control point of these.

Lastly—and though this was not often pointed out when the vulnerabilities above were revealed—they also have implications for emerging uses of containers, and specifically for defending the IoT from cyberattack. Given the longstanding vulnerabilities that are inherent in IoT devices, pairing them with containers could open up entirely new types of attack vectors.

Lastly, the rise of cloud backup storage for SMBs makes this even more critical because a compromised Kubernetes API represents a potential intrusion risk for cloud storage solutions that are used by millions of businesses all over the globe.

Countries don’t share the same regulations in regards to privacy, which means that cloud storage solutions in the United States will be different than from, say, the UK or China. The best thing you can do will be to research the privacy laws in your country and to find out where your data centers are located so you know where your information will be stored.

Scanning for Cybersecurity

These potential impact of these vulnerabilities means that devs working with containers need to take them seriously from the earliest possible stages of container design. One of the most common misconceptions about threat hunting, especially when it comes to containers, is that a perimeter-scanning process is the best way to spot potential security risks; in other words, put the software out there and see how it is attacked.

While a threat intelligence system is certainly necessary for any company running containers, security should start far before the release of the software. There are several tools that allow devs to do this. Anchore Engine is one of the most popular open source tools because it allows organizations to unpack, validate and ensure the integrity of container contents. There are, however, many similar pieces of software out there.

There are a number of advantages to using tools like this. First, going with an open source solution means that devs can check the integrity of their containers without having to wait for management to make a slow and costly decision on which audit software to use. Secondly, it allows for experimentation: You can play around with the structure and contents of containers and see how this will affect downstream security.

This “shift-left” approach is certainly valuable, but should not be the only strand of your container workflow. Plenty of organizations choose to focus on their CI/CD pipeline, for instance, and use scripts to automate evaluation as container images make their way through.

This is of particular importance if you are making use of components that are offered on a SaaS model because it allows you to check that your SaaS provider has done the research and work necessary to ensure their software doesn’t compromise yours.

The Future

Although the container vulnerabilities above are a legitimate cause for concern, their appearance does seem to be leading to a shift in mindset. In just the past few months we’ve reported that Tripwire has made generally available a Tripwire for DevOps software-as-a-service (SaaS) offering optimized for containers and that StackRox has extended its Kubernetes security platform to add tools that scan for misconfigurations and vulnerabilities.

Whether tools of this type will prevent the appearance of further container vulnerabilities remains to be seen. But they certainly form part of a new paradigm in container security, in which devs at all levels are starting to look at the connections between containers and the systems they are integrated with rather than seeing them as discrete (and potentially dangerous) monolithic components. And that is a shift that should be welcomed.