Palo Alto Networks’ Unit 42 threat intelligence group has pinpointed a new cryptojacking worm that has infected more than 2,000 unsecured Docker hosts and is being used to mine Monero cryptocurrency. And because someone in that group has a sense of humor, they named the worm “Graboid” in honor of the 1990’s movie “Tremors.”
The group claims an attacker was able to gain an initial foothold within a container through unsecured Docker daemons. Those daemons are what listens to Docker container API requests and manage Docker objects like images that are used to construct applications in a container.
The malware was downloaded from command and control servers and in mining Monero it periodically checks for vulnerable hosts in an attempt to proliferate. It uses a complex method that randomly targets three iterations, installing the worm on the first target, stopping the mining activity on the second target, and starting the miner on the third target.
“Our analysis shows that on average, each miner is active 63% of the time and each mining period lasts for 250 seconds,” the group wrote. It did add that the Docker team “worked quickly in tandem with Unit 42 to remove the malicious images once our team alerted them of this operation.”
The worm is the first detected that is spread using containers within the Community Edition (CE) of the Docker Engine. Unit 42 notes that because most detection processes don’t inspect data and activities within running containers, this form of vulnerability can be difficult to detect.
2,000+ Docker Engines Exposed to Worm
The group cited a Shodan search that shows more than 2,000 Docker engines being exposed to the internet. “Without any authentication or authorization, a malicious actor can take full control of the Docker Engine (CE) and the host,” it added.
While the attack method appears complicated, Unit 42 noted that it does not involve “sophisticated tactics, techniques, or procedures.” However, it can pull new scripts from those command and control servers that could allow it to morph into ransomware or malware that can impact a larger operation.
To counter that chance, the group suggests that organizations don’t expose an unsecured Docker daemon to the internet; use a Unix socket to communicate with the daemon locally or Secure Shell (SSH) to connect to a remote daemon; use firewall rules to whitelist incoming traffic to trusted sources; and frequently check for unknown containers or images in a system.
“There really isn’t a good reason to expose the Docker engine in this way — it’s almost certainly a configuration mistake on the server and the network firewall (if there is a firewall at all),” wrote Connor Gilbert, senior product manager at container-focused security firm StackRox, in a comment on the attack. “Leaving the Docker engine API server exposed without authentication lets people run whatever containers they want on your server if they can contact it. Because of the privileges the Docker engine has this is like leaving the root account available over SSH with no password.”
A Unit 42 report in July found more than 34 million vulnerabilities across various major cloud providers including Amazon Web Services (AWS), Microsoft Azure, and Google Cloud. As part of that report it also found more than 40,000 container systems were operating under default configurations, which was nearly 51% of all publicly exposed Docker containers. Many of these systems allowed unauthenticated users to access data in these containers.
Container Security Is Hard
StackRox released a report in July that found two-thirds of organizations were running more than 10% of their applications in a containerized environment, but that 40% of those organizations thought their security stance was not adequate to protect those environments.
Most of those concerns are over misconfigurations and accidental exposure of access to their containerized environments. However, a robust 43% stated concerns over runtime security, 35% specified concerns about deployment security, and 22% said they were worried about build security.
“Just as with securing [infrastructure-as-a-service], missing container and Kubernetes security best practices and human error in misconfigurations create real threats to organizations and their bottom lines,” said Mark Bouchard, co-founder and CEO of AimPoint Group, in a statement on the report. “The consequences of overlooking security early in the container life cycle will be steep, both in lost time and money and in risk of exploitation.”
Those concerns and the latest Docker attack worm come on the heels of a rash of recent vulnerabilities discovered within several platforms.
Kenna Security earlier this year found that the most popular Docker container files contain at least one notable security vulnerability, while one in five houses what is considered a critical security flaw. And a senior software engineer at SUSE discovered a significant Docker container security flaw that allowed an attacker access to API endpoints behind the docker cp command that would allow an attacker to read and write data on a host machine.