Recently, researchers from Palo Alto Networks’ threat intelligence team Unit 42 have uncovered the first instance case of a cryptojacking worm that propagates via malicious Docker images.
According with the report:
Unit 42 researchers identified a new cryptojacking worm we’ve named Graboid that’s spread to more than 2,000 unsecured Docker hosts. We derived the name by paying homage to the 1990’s movie “Tremors,” since this worm behaves similarly to the sandworms in the movie, in that it moves in short bursts of speed, but overall is relatively inept.
There have been incidents of cryptojacking malware spreading as a worm, but this is the first time we see a cryptojacking worm spread using containers in the Docker Engine (Community Edition). Because most traditional endpoint protection software does not inspect data and activities inside containers, this type of malicious activity can be difficult to detect. The malicious actor gained an initial foothold through unsecured Docker daemons, where a Docker image was first installed to run on the compromised host.
The malware, which was downloaded from command and control (C2) servers, is deployed to mine for Monero and periodically queries for new vulnerable hosts from the C2 and picks the next target at random to spread the worm to. Our analysis shows that on average, each miner is active 63% of the time and each mining period lasts for 250 seconds. The Docker team worked quickly in tandem with Unit 42 to remove the malicious images once our team alerted them of this operation.
Unit 42 discovered the worm late last month after the a malicious image appeared across several unsecured Docker hosts discovered via Shodan: once remotedly deployed and installed, the contaminated container image connects to a remote command-and-control server and to periodically query for vulnerable hosts and select a target at random to spread the worm.
The threat is real, and despite this is the first case, a lot of similar worms will coming soon.
So, how can i defend my containers?
First, periodically perform a security assessment of your docker infrastructure.
More info on this article: Some thoughts about Docker security concerns
Ensure good host security
In container deployments, as in the non-containerized world, good security relies upon multiple layers; a secure Docker implementation relies on the security of the host as well as the container implementations
Check Image Provenance
Using Docker images downloaded from Docker Hub or another registry provides multiple benefits in building an application, including increased speed and --in the case of “official” images-- the expertise of the image builders and the collective wisdom of previous users.
More info about this topic: Docker images under cryptojacking attack: how to check if a downloaded image is safe
Logging and monitoring are essential for identifying and investigating security incidents and providing audit trails (OWASP, 2016). Centralized logging becomes even more important in a containerized environment, since a given container may no longer be available when it’s time to track down a breach or other issue
Do Not Run Container Processes as Root
Namespaces isolate processes running in one container from processes running in another container or on the host system.
By default, the user namespace for containers is the same as that of the host. More specifically, the root user inside of a container is the root user of the host system and the compromise of a containerized process running as root has the potential to compromise the Docker host
Do Not Store Secrets in Containers
Application containers may need database credentials, SSL certificates and private keys, SSH or encryption keys and API tokens to interact with users and other services
Base Image Security
In addition to checking the provenance of images pulled from registries, Docker Administrators need to be able to trust that their images have up-to-date software, without any known vulnerabilities
Limit container resources
As the number of containers running in a system grows, so does the likelihood that one of the applications has a security flaw that can lead to a denial of service for the other containers. If an attacker can monopolize a shared resource on one container, he may be able to deny access to multiple others