How to Secure Containers from Cyber Attack | OT Cybersecurity

Container technology has been around for over a decade. Containers provide a handy way to break applications into smaller parts and run them on different servers (as microservices). However, this introduces security vulnerabilities—a significant problem as the number of developers using containers is on the upswing with cloud making it easier to use engines like Docker, rkt and Mesos for the management of containerized applications.

How large is the problem? Forrester Research in 2017 found that 31% of enterprise cloud developers were using containers. Going by forecasts, the number is expected to double by 2021[i]. Therefore, the growing concerns around security cannot be ignored.

The core technical challenges of container security arise in three major areas: The image, container host and the container. The solutions lie in the right combination of tools, processes, and people.  

Image Code

Typically, a container consists of the application code on top of either a single layer of base image or multiple reusable layers above the base image. These layers contain third-party code libraries and components required to execute the application. This is the first area to be vulnerable to bugs and code deficiencies.

One solution is to strip down the images to their barebones and also remove unused and outdated images regularly. There are several tools available such as Aqua, Twistlock and Clair that can scan the image and the code libraries to identify vulnerabilities. Some of these tools use the package manager manifests to identify installed dependencies/ libraries and check them against known issues. Others scan the image binaries for known vulnerabilities. Using these tools is highly recommended to harden and standardize the images.

• Exploit Example: The Heartbleed vulnerability in the OpenSSL cryptographic software library which allows attackers to snoop, steal data from services and impersonate services and users. 

Image Source

Standardized images available in the public domain, from vendors such as Docker or private ones created by IT teams, are not completely insulated from attack. Clever attackers inject their images by breaching the network between the container host and repositories.

To combat this, techniques like ‘creation of digests’ (hashes of the original image which are shared with the hosts via a pre-established agreement) or ‘insertion of verifiable digital signatures’ are implemented. Some enterprise-grade image storage and management solutions are Dockyard, Atomic Registry, and Docker Enterprise Registry. Using these help deliver safer applications.

• Exploit Example: The number of security vulnerabilities identified with official images on Docker Hub is a clear sign that image sources could not be fully trusted[ii].

Shared Host

The host machines that run containers are generally shared resources. They too should be hardened against vulnerabilities. Unessential software on the host adds to the vulnerabilities or increases the attack surface. Appropriate networking and security practices should be implemented to ensure container isolation. One of the common vulnerability seen in containers with older Bash Shell is Shellshock. Nmap[iii], which scans for the presence of Shellshock, makes this an easy exploit.

These issues are solved using specialized operating system distributions like Core OS, Redhat Atomic and Ubuntu Core which are available for container deployments. While these OSs are stripped down, it is advisable to harden them further to ensure a reduced attack surface.

• Exploit Example: The CVE-2014-9357 vulnerability in Docker 1.3.2 which allows attackers to execute arbitrary code with root privileges.

Container Tooling

Most large-scale applications rely on additional toolsets, be it for container orchestration or for CI/CD. This results in a broader spread of containers communicating with each other across hosts, datacenters or cloud. Segmenting the network and using cryptographic protocols such as TLS to secure the communication is recommended barring a few specific use cases.

• Exploit Example: The CVE-2016-1906 vulnerability remote attackers to gain privileges by updating a build configuration that was created with an allowed type to a type that is not allowed

Container Runtime Privileges

Containers are sometimes run with root privileges on the host machine. This presents a potential risk if the privileges are not set correctly or if the configurations and access to the host are not secured.

This is addressed by restricting kernel Capabilities. Capabilities are groups of permissions that can be given to child processes. No process should have all privileges, instead, they should have only the privileges required to perform the intended service. By doing this, the damage caused by compromised containers is restricted. Red Hat’s container platform OpenShift has the ideal security feature: By default, no containers are allowed to run as root!

Exploit Example: Capabilities like SYS_ADMIN and STUID provide root level privileges that can be exploited by intruders. Such processes should be dropped unless expressly needed.

User Privileges in Containers and Hosts

A container is never as isolated as a VM. The users and processes in containers exist in the host’s user and pid namespaces respectively. Sometimes users inside the containers have or need higher privileges which can be risky if the privileges are not managed appropriately. The container breakout attacks use improperly set permissions and host configurations to escalate the privilege for the containers, to reduce the isolation and allow containers to access privileged resources.

There are tools like Centrify which set privileges at levels which can restrict specific Docker commands on the host.

Kernel Calls Isolation

There are occasions when the container makes kernel calls for a process (like system services) to execute. This privilege can be misused to either harm other processes or hog system resources.

Tools such as Linux Capabilities and Sec Comp can be fine-tuned to prevent or set limits around containers’ kernel calls. SElinux security modules can be used to apply policy prior to kernel call executions. AppArmor security profiles can be created using tools like Bane. AppArmour protects operating systems and their applications from security threats.

Vulnerability Creep

Over time, new vulnerabilities are identified. Once what was considered safe is found to be vulnerable.

Regular audits of the container environment and the orchestrator/ tool-chains should be carried out. CIS standards are available for the commonly used runtimes like Docker and Orchestrators like Kubernetes which can be used as a baseline for evaluation. In instances where standards are not publicly available, develop your own standards looking at the runtime design and capabilities for other container runtimes.

Conclusion

Security always presents new challenges. New exploits find their way into systems. It is essential to, therefore, ensure continuous monitoring of the container environment and take action.  

There is no one size fits all solution for most of the exploits. Enterprise architects must determine the right balance between security and ease of use before choosing tools and processes to counter the exploits.

The golden rule remains: Provide the minimum resources and privileges required to stay functional.

[i] https://451research.com/blog/1657-featured-insight
[ii] https://blog.acolyer.org/2017/04/03/a-study-of-security-vulnerabilities-on-docker-hub/
[iii] https://nmap.org/nsedoc/scripts/http-shellshock.html