New Cryptojacking Worm Found in Docker Containers

A new cryptojacking worm, named Graboid, has been spread into more than 2,000 Docker hosts, according to the Unit 42 researchers from Palo Alto Networks. This is the first time such a piece of malware has spread via containers within the Docker Engine (specifically docker-ce).

For anyone who has worked with containers, it should be obvious why this is of utmost importance. In most cases, cryptojacking worms can be discovered and removed with standard software tools. In the case of containers, that is not always (if ever) true. In fact, according to the Unit 42 report, “this type of malicious activity can be difficult to detect.”

As a cryptojacking worm, Graboid malware serves two purposes:

• Cryptomining
• Spreading to other vulnerable hosts

How it works looks something like this:

• That hacker locates an insecure Docker host and sends remote commands to download and deploy a malicious image named pocosow/centos:7.6.1810.
• Using a malicious script (/var/sbin/bash) within the container, four shell scripts (live.sh, worm.sh, cleanxmr.sh, and xmr.sh) are downloaded from a Command and Control (C2) server.

The four scripts are executed, one at a time, with the following purposes:

• The live.sh sends the number of available CPUs to the compromised C2 server.
• The worm.sh script downloads a file that contains a list of IP addresses of hosts with unsecured Docker API endpoints and then randomly chooses one of the addresses as its target to deploy the infected container.
• The cleanxmr.sh script randomly picks one of the hosts from the list and stops the cryptojacking containers on the target.
• The xmr.sh randomly picks one of the hosts and deploys another image (gakeaws/nginx), which contains a binary masquerading as nginx.

A Complicated Issue

Malware found within container images poses a significant threat to businesses. When images aren’t vetted and secure, they can contain any number of issues. “Secure and validated delivery is the foundation of enterprise operating system. The software its running should always be taken from trusted sources, but the flood of insecure Docker images is a serious problem,” said SaltStack chief technology officer and founder Thomas Hatch.

With regards to Graboid, Hatch says, “Not only can the Graboid vulnerability spread, but the attack vector it uses is one of the oldest attack vectors out there. It is a simple software delivery hijack.” In other words, what would normally be a simple means of spreading and detecting, has been made exponentially more challenging (on the detecting side of things) due to the attacker using containers.

For any organization that depends upon Docker container images, it has become more crucial than ever to only use trusted sources for those images. However, the onus isn’t only on the images. Hosting servers and networks carry some of the burden as well.

Connor Gilbert, senior product manager at container security firm StackRox, says, “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).” In other words, a poorly configured server and network are just as guilty. Gilbert continues, “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.”

What Can Be Done?

We’ve reached a point with containers where security must be constantly on the front burner. Antivirus and anti-malware applications currently have no means of analyzing and cleaning containers and container images. That’s the heart of the issue. And even tools like Harbor are only capable of determining if an image contains a vulnerability (not fixing them).

Because of this, it is absolutely critical to only use trusted images and secure the API servers for the likes of Docker and Kubernetes. As a container administrator, you must fully understand the tools available and the best practices for the tools you use.