Doomsday Docker security hole uncovered. A security vulnerability has been disclosed for a flaw in runc, Docker and Kubernetes’ container runtime, which can be used to attack any host system running containers. (ie: amazon elastic container service)

One of the great security fears about containers is that an attacker could infect a container with a malicious program, which could escape and attack the host system. Well, we now have a security hole that could be used by such an attack: RunC container breakout, CVE-2019-5736.

This is how Docker containers can be exploited to mine for cryptocurrency

Researchers have detailed how Docker containers are becoming a prime target for cryptojackers at a time when fraudulent cryptocurrency mining is a lucrative business.

Cybercriminals are turning away from ransomware deployments in their droves in favor of cryptocurrency malware.

Known as cryptojacking, these malware variants will plunder the CPU’s of infected machines in order to steal computational power in order to mine for virtual coins such as Ethereum (ETH) and Monero (XMR), of which these cryptocurrencies are then sent to wallets controlled by attackers.

The problem is becoming more widespread. In recent times, prison sentences have been issued to cryptojacking operators, universities have closed down networks to stop cryptocurrency mining operations, routers have become enslaved for cryptojacking purposes, and one in three organizations have reported crypojacking attacks.

Docker containers are standard units of software which package up code and all dependencies linked to them to increase the speed of applications moving from one computing environment to another.

These lightweight tools can be useful tools within the application development-deployment life-cycle and according to Docker, over 3.5 million applications have been placed in containers using such technology.

Doomsday Docker security hole uncovered

However, while Docker increases in popularity with IT professionals, cybercriminals are also exploring how the container technology can be exploited for their own ends.

Researchers from Threat Stack shared insight with ZDNet into how cryptojacking attacks are now taking place against containers used by the enterprise.

The first stage of the attack is to identify front-facing systems and websites vulnerable to remote code injection attacks. A command is sent through the application layer — often by way of manipulating a text field on a domain or via an exposed API in a website URL — or by “probing an embedded shell console commonly found on code reference websites,” according to the researchers.

The injected code then filters down to the back-end operating system and eventually finds its way to the container environment.

The second phase of such attacks initiates when the container is spun up. In recent attacks spotted, the code is executed and commands are sent directly to the shell within a Docker container.

“While restricted to the container’s reduced view of the host operating system, the attacker can now arbitrarily run untrusted code,” Threat Stack says.

In stage three, a cryptomining malware is downloaded through a wget command. In attacks which have been observed to date, CNRig has been used to infect machines.

The payload uses the CryptoNight algorithm, which is written in C++, and is compatible with Linux CPUs. Based upon the XMRig Monero rig, CNRig also contains automatic update capabilities.

Threat Stack says that the speed of this stage suggests that automatic scripts are in place to execute the payload, which is followed by the change of permissions on the CNRig executable to make sure it operates without any need for further authentication.

The cryptojacking payload runs out of the /tmp directory.

CNRig will then attempt to establish three connections; two to create a secure pathway between the infected machine and the attacker’s mining pool, and one out to a CDN. However, in the cases currently on record, these attempts are not always successful due to networking layer protections and firewalls.

Threat Stack told ZDNet that the company has detected an “increasing number of attackers targeting container orchestration tools like Docker and expect to see this trend to continue as more organizations deploy containers.’

The attack vector is an interesting one and not immediately apparent in connection to cryptojacking. However, when money is to be made, attackers often prove themselves resourceful and innovative.

In order to protect themselves against such threats, the company says that enterprise players should make sure underlying files are not writable from containers; soft and hard limits are set on CPU consumption, and alerts should be enabled for when interactive shells are launched.

RunC is the underlying container runtime for Docker, Kubernetes, and other container-dependent programs. It’s an open-source command-line tool for spawning and running containers. Docker originally created it. Today, it’s an Open Container Initiative (OCI) specification. It’s widely used. Chance are, if you’re using containers, you’re running them on runC.

According to Aleksa Sarai, a SUSE container senior software engineer and a runC maintainer, security researchers Adam Iwaniuk and Borys Popławski discovered a vulnerability, which “allows a malicious container to (with minimal user interaction) overwrite the host runc binary and thus gain root-level code execution on the host. The level of user interaction is being able
to run any command (it doesn’t matter if the command is not attacker-controlled) as root.”

To do this, an attacker has to place a malicious container within your system. But, this is not that difficult. Lazy sysadmins often use the first container that comes to hand without checking to see if the software within that container is what it purports to be.

How bad is this? As bad as you can imagine. Scott McCarty, Red Hat technical product manager for containers, warned:

The disclosure of a security flaw (CVE-2019-5736) in runc and dockerillustrates a bad scenario for many IT administrators, managers, and CxOs. Containers represent a move back toward shared systems where applications from many different users all run on the same Linux host. Exploiting this vulnerability means that malicious code could potentially break containment, impacting not just a single container, but the entire container host, ultimately compromising the hundreds-to-thousands of other containers running on it. While there are very few incidents that could qualify as a doomsday scenario for enterprise IT, a cascading set of exploits affecting a wide range of interconnected production systems qualifies…and that’s exactly what this vulnerability represents.”

Besides runC, Sarai reports that the problem can also attack container systems using LXCand Apache Mesos container code. So, yes, if you’re running any kind of containers, you need to patch ASAP.

Doomsday Docker security hole uncovered – Amazon elastic container service

amazon elastic container service

Doomsday Docker security hole uncovered. Most, if not all, cloud container systems are vulnerable to this potential attack. Amazon Web Services (AWS), for example, states that while there’s a patch available for Amazon Linux, patches are still being rolled out for Amazon Elastic Container Service (Amazon ECS), Amazon Elastic Container Service for Kubernetes (Amazon EKS), and AWS Fargate.

Red Hat claims that if you deploy SELinux, this bug shouldn’t bother you. However, while you should run SELinux, and it’s set on by default in Red Hat Enterprise Linux (RHEL), many sysadmins don’t run it because it’s difficult to maintain.

In addition, Sarai notes, “This vulnerability is *not* blocked by the default AppArmor policy, nor by the default SELinux policy on Fedora (because container processes appear to be running as container_runtime_t). However, it *is* blocked through correct use of user namespaces (where the host root is not mapped into the container’s user namespace).”

A Red Hat representative clarified, “that is only true for the “moby-engine” package on Fedora. The “docker” package as well as podman are protected against this exploit because they run container processes as container_t. as opposed to container_runtime_t which is what moby uses. RHEL doesn’t ship Moby at all, so the vulnerability is completely mitigated by SELinux in enforcing mode.”

The quick and easy answer is to patch runC as soon as possible.

Doomsday Docker security hole uncovered

This is how Docker containers can be exploited to mine for cryptocurrency

Doomsday Docker security hole uncovered

Doomsday Docker security hole uncovered – Amazon elastic container service

Related Videos:

Related Posts:

About the Author: Bernard Aybout