5 Common Container Exploits

There are many ways to hack a container. Some exploits are much harder than others to pull off, or only work under rare conditions.

You can be sure that the bad guys who want to break into your systems will start with the easy exploits. That’s why understanding common container security exploits, then taking steps to eliminate them within your environments, is the first step in establishing a strong container security posture.

With that goal in mind, let’s take a look at five of the most common container exploits and explain how to mitigate them using container security tools.

Container Image Malware

Malware inside container images is an ever-present threat – so much so, in fact, that, according to a recent study published in InfoQ, more than half of the public container images available on Docker Hub, the most popular public container registry, include exploitable vulnerabilities. If you deploy containers that contain malware, the malware can run inside your environment along with the “legitimate” contents of the container image.

Fortunately, container image malware exploits are relatively easy to prevent. The main solution is to scan container images before deploying them with a container image scanner, and never blindly trust a container image no matter what its source.

It’s important to recognize that container image scanners can typically only identify malware that is tracked through public vulnerability databases. Thus, even if your images pass their scans, there’s a chance that unknown malware could lurk within them. But image scanning will detect the vast majority of malware that could be hidden inside images.

Locking down access to your container registry can also reduce container malware risks by preventing malicious parties from injecting vulnerable images into your registry.

Privilege Escalation Exploits

A privilege escalation exploit happens when a process running inside a container manages to gain access to resources (such as processes running in other containers or on the host operating system) that it shouldn’t be able to control. Most often, privilege escalations result from a bug in the container runtime, which is the software that executes containers.

There are two main ways to mitigate container privilege escalation threats. One is to ensure that all of your container tooling is up-to-date. That way, your runtime, orchestrator, and the rest of your stack won’t be subject to known exploits.

The second part of the solution is to lock down container access privileges through all of the tools available to you. You can use host-level frameworks like SELinux or AppArmor for this purpose. You can also use tooling like Kubernetes’s RBAC framework or security contexts. (In fact, you can use all of these tools at the same time to achieve maximum protection.) Access controls won’t prevent the coding flaws that enable privilege escalation attacks, but they may be able to block some attacks by preventing unauthorized requests between containers, or between containers and the host.

Access Control Exploits

Speaking of access control, it’s not only through privilege escalation exploits that container security issues can arise. You may also run into problems if you simply grant containers more privileges than they should have. In that case, attackers who manage to gain control of the container may be able to use it to access other resources on the host. They don’t have to exploit a software vulnerability to do this because the container has unnecessary privileges by default.

Enforcing strong access controls is the key to mitigating this type of risk. Avoid mistakes like allowing containers to run in “privileged” mode (which means the container has root access to host-level resources), and enforce the principle of least privilege when configuring access control rights for each container. In most cases, you can manage these privileges using your orchestrator’s access control framework.

Network Security Exploits

Improperly configured networking rules can also become a vector for attack – or exacerbate exploits that originate elsewhere – by allowing containers to communicate via the network.

To prevent network risks, the networking resources that containers expose should be restricted to the minimum necessary. You can enforce this policy within two layers of your stack.

First, you can use your orchestrator to restrict network communications between containers. In Kubernetes, for example, you can write network policies to define the network traffic rules for containers.

Second, you can scan your container images to determine whether they contain unsafe network settings. For example, image scanners can help you identify vulnerable network ports that are set to be open within containers based on the image.

Container Orchestrator Exploits

A variety of exploits can be launched via the orchestration tool you use. Since there are multiple container orchestrators out there, and a large number of potential exploits for each one, a full discussion of orchestrator exploits is beyond the scope of this article.

In general, however, best practices for securing your orchestrator include:

• Enforcing least privilege using the orchestrator’s RBAC tooling.
• Running frameworks like SELinux and AppArmor on your nodes to help prevent exploits against the orchestrator.
• Using auditing features (if your orchestrator supports them) to detect suspicious requests.
• Using abstracts like Kubernetes namespaces to separate unrelated workloads from each other in order to reduce the chances of an exploit against one workload “spilling over” to impact others.

Conclusion

From container image malware, to privilege escalation attacks, to network security risks and beyond, your containers may be subject to a variety of exploits. The good news, however, is that these risks can all be managed effectively, so long as you have the right tools in place.

Bio

Chris Tozzi has worked as a Linux systems administrator and freelance writer with more than ten years of experience covering the tech industry, especially open source, DevOps, cloud native and security. He also teaches courses on the history and culture of technology at a major university in upstate New York.