Cryptocurrency Mining Attacks Shifting Left
Recently, there has been a flurry of cryptocurrency mining attacks hitting various entities around the globe ranging from celebrity Twitter accounts to customers running workloads across Kubernetes clusters.
For today, we'll ignore the celebrity accounts and focus on how Anchore can be used to protect your organization from cryptomining attacks. Back in April, Microsoft did an excellent job providing details into one of these attacks that leveraged a specific cryptomining image that currently has more than 10 million pulls on Docker Hub!
The central premise is straightforward, “Allow only trusted images: Enforce deployment of only trusted containers, from trusted registries.” But what happens when using trusted images isn’t enough? First, let’s set up a list of trusted images using Anchore, explore why whitelisting/blacklisting images is a good start to protecting your organization and then discuss how Anchore can amplify your security by creating STOP actions in your CI/CD pipeline using in-depth inspection of the container image itself.
Whitelisting/Blacklisting Cryptocurrency Mining Images
To cover all of the bases, let’s start by building out a thorough blacklist of some commonly used mining images you can find on Docker Hub. Using Anchore Enterprise, navigate to Policy Bundles > Whitelist/Blacklist Images. From here you can add the specific image you would like to blacklist. In the end, you might have something that looks like this:
Additionally, let’s add your approved images to the whitelist. Building off a set of approved and hardened images is a very healthy development practice for teams to adopt. This way Anchore can flag any unapproved images that may be passed through your pipeline. Ultimately, whitelisting is far more powerful, but there is no harm in doubling down here. I went ahead and set up an Ubuntu image on my whitelist below:
This is effective because it will prevent one attack scenario, which is an attacker pulling down any of the hundreds of mining images from Docker Hub and running them inside your environment. However, an attacker can easily maneuver around an organization’s whitelist/blacklist. For example, an attacker could always build a custom miner using your approved base image and a series of Docker instruction commands. That is a terrible scenario for an organization to experience, but it could happen if an insider threat or attacker decides to make a few quick crypto-bucks all while using your own approved container images and K8’s infrastructure.
Monitor the Instructions in the Dockerfile
Let’s take a look at the build steps of the kannix/monero-miner image that was referenced in the Microsoft report and demonstrate how Anchore can detect a threat even if the attacker was building using an approved image or is using a non-blacklisted image.
This image is created in a multi-stage build, using FROM ubuntu:latest as the version. Thus, even if we had our whitelist above, the attacker could still build this image successfully using our whitelisted image FROM ubuntu:20.04. To prevent this, Anchore can monitor subsequent lines to detect a Monero mining image is being built.
Anchore Enterprise policy does just that. The second RUN command features an apt-get update and apt-get install which is prohibited in Anchore policy bundle using the Dockerfile Gate, and Instruction trigger.
This generates an automatic STOP action in Anchore and prevents this from moving further in your pipeline. Failing this check will prevent your image from progressing further in the selected policy bundle. For the sake of this post, let’s see what other harmful instructions generate a STOP action and alert using Anchore.
Over the next few lines, the image performs a ‘RUN git clone’ to pull down the build scripts and necessary files for xmrig. This would generate a STOP action in Anchore because it violates Anchore’s Transfer Protocol Checks that are applied to every image. As seen below, Anchore monitors the RUN, FROM, COPY and ADD instructions for external requests using HTTP, HTTPS, FTP and SFTP protocols.
Next, Anchore’s cryptomining checks have generated yet another STOP action because Monero already exists as a blacklisted user using the effective user check on the Dockerfile instruction as seen below.
Immediately after setting the effective user, they set the working directory to /home/monero. Similar to setting the user as Monero, setting the working directory /home/monero is pretty common in Monero images. Anchore’s cryptomining checks can look for that by monitoring the Dockerfile Instruction WORKDIR as seen here:
In the last few crypto mining checks, we can monitor for xmrig itself. I did an attribute match and name match on the file using Anchore which generated two additional stop actions.
Lastly, Anchore generated a check around the ENTRYPOINT [“./xmrig”].
After all of these checks are in place your compliance tab of Anchore Enterprise should look a bit like this:
Conclusion
Cryptocurrency mining attacks will continue to evolve. In this post, we’ve demonstrated the flexibility of Anchore policy enforcement to provide contextualized security enforcement to the user. It’s important that organizations take steps to increase their security posture further to the left to prevent these images from being deployed into a production Kubernetes cluster.
DevSecOps is centered on the premise that security actions must run at the same speed and scale as development and operations. Tools like Anchore Enterprise provide organizations with a new line of defense by providing deep image inspection and policy-based enforcement mechanisms that monitor for security threats before they enter the development pipeline.
