Common Container Security Threats

Containers have become the most popular medium for deploying applications lately. Rise of the popularity of Kubernetes, Docker and DevOps methodologies have all contributed to this popularity. While containers are the most popular and efficient way to deploy applications, many enterprises appear to still be in the early stages of adopting a security strategy for containers.

There have been many incidents of container security breaches recently associated with large enterprises. This article discusses common container security threats in detail with examples of recent attacks.

Later in the series, we'll address how an enterprise can get started on the journey to securing its container application deployments by creating a secure container infrastructure architecture, followed by container image management best practices and updating existing CICD technologies.

Take a look at the second article in this series: Securing Container Infrastructure with Red Hat OpenShift.

Types of container security threats

To address the container security threats and vulnerabilities, one has to study and understand the various types of known attacks. Although not exhaustive, the following are the broad categories of container threats and vulnerabilities.

Access control exploits

These types of threats are nothing new to IT security professionals; they have been around for a long time. Overlooking basic authentication and authorization to orchestrators like Kubernetes and Docker can offer attackers full access to container deployment.

Securing the container orchestrator console/dashboard and APIs is the first step of securing the container infrastructure. Recent attacks on Tesla, Shopify, and Aviva based on unsecured kubernetes consoles are a good example of this type of attack.

In the case of Tesla, the Kubernetes console was left configured without a password and hackers were able to take control and find the credentials to AWS cloud. They were able to gain access to S3 buckets with sensitive data, as well as run cryptocurrency mining in Kubernetes pods.

In a similar attack on WeightWatchers, the insecure Kubernetes cluster console was found by scanning publicly available IPs on kublet TCP port 10250.

Another example of a security vulnerability with unsecured API is the use of Docker API to create new rogue containers on container hosts with the community images and malware for cryptocurrency mining.

Container image vulnerabilities

The use of container images with vulnerabilities can cause a wide range of security issues from allowing malware to be installed to creating kernel panics and access to the host kernel. There are a number of reports of rogue containers infected with cryptocurrency mining malware embedded in community docker images. Docker hub has recently removed images with backdoors to run cryptocurrency mining malware that may still be in use as of today.

Container privilege escalations

These types of attacks are based on exploiting defects or vulnerabilities that exist in container run times or in the Linux kernel. Runc is the low-level container runtime that does the most of the heavy lifting under the hood for Docker, CRIO and containerd. In one of the recent exploits , exploited containers allowed attackers to overwrite host runc library and gain root access to the container hosts.

In another instance, somewhat old Linux kernel vulnerability CVE-2017-7308 can be used to change the current process's namespaces into process 1's and the host's namespaces by calling a Linux kernel system call, allowing a full escape to host.

Application code exploits

These are typical bad coding practices presenting chances to exploit the application run times. These type of vulnerabilities are not specific to the containerized application but may be prominent because of the cloud-native application dependencies on APIs. Some of the examples are SQL injection, cross-site scripting (XSS), server-side request forgery (SSRF), weaknesses in cryptography key generation and authentication, as well as incorrect use of cookies.

With Kubernetes pod concepts, each self-contained container pod can talk to all other pods/containers over the network overlay. It is possible a compromised container/pods can spread the malware across multiple containers/pods on multiple container hosts. Usually, this type of network traffic is east-west traffic and may not be detected without enhanced security mechanisms or network policies due to the dynamic scaling capabilities of the Kubernetes or docker container orchestration.

Containers/pods exposed to the Internet are under the same type of threats that affect the non-containerized workloads such as the denial of services (DDOS), SQL injection, cross-site scripting (XSS).

Public image and code repository compromise

Early this year (2019), Docker announced that their Docker Hub user database was compromised by a hacker for a brief period of time. Roughly 5% of the Docker Hub users were affected by this data breach. The data compromised included usernames, passwords and VCS credentials like github, gitlab and bitbucket tokens.

How WWT can help

WWT security teams can sit with you and evaluate the existing container security processes, infrastructure, application and security requirements. Whether it is a greenfield or brownfield deployment, we'll work with you to architect container security solutions to meet your application and compliance security requirements.

Schedule a Cloud Security Tools Rationalization Workshop to get started.