It seems that containers and container management tools are found exposed on the internet every other day -- sometimes...
with little to no security in place at all.
In June 2018, over 22,000 container orchestration administration and API management consoles were discovered in public. Some of them didn't have any authentication in place and many used weak or default authentication.
Most of these were Kubernetes containers hosted in the public cloud in AWS. For cloud and DevOps teams using containers in the cloud, it's easy to accidentally expose more than you bargained for, possibly with unfortunate results.
This scenario played out in 2018 with the discovery that exposed Docker APIs were being used by attackers to create containers for cryptojacking attacks, according to research from Trend Micro Inc. To understand how the attacks occurred, you have to know a bit about Docker itself.
How Docker APIs are abused
Docker operates as a daemon or service within an operating system that enables container images to be created, built and run, leveraging the OS kernel for resource sharing. By default, the local Docker client within the OS can be executed to create, pull/import or run the kernels with commands like docker import, docker pull and docker run.
These commands are fine when they are run from the local system, but some organizations want to allow remote users to execute the same commands from afar, turning Docker host systems into more traditional client-server architectures. This could work on an internal network with adequate controls, but exposing these APIs and ports to the internet without adding layers of security controls to the implementation is a dangerous decision.
By default, the two Docker ports that are exposed by this remote control are TCP 2375 for plain HTTP connections and TCP port 2376 for HTTPS connections. Obviously, HTTPS connections are preferred, but even these should have transport layer security (TLS) or other authentication methods enabled for any connecting clients who want to run Docker commands.
According to research from Trend Micro, none of these security precautions were in place before the 2018 exposure. Attackers were able to access the Docker API ports; easily run the Docker create, pull and import commands to, for example, create a local image; pull an image from an online or accessible Docker image registry; or import an image from a .tar.gz file or other remotely accessible compressed files.
Researchers were also able to fetch automated install scripts that set the container up with Secure Shell access for root users so they could install and run Monero cryptocurrency mining software.
Additionally, the malicious containers were able to install the masscan tool and began scanning all the visible networks from the host for these same ports -- 2375 and 2376. This way, the attackers not only used the containers for mining cryptocurrency, but also to look for new victims.
How to prevent the misuse of Docker APIs
There are several precautions organizations can take to mitigate this kind of attack. First, stop opening Docker APIs to the internet. There's rarely a good reason for these APIs to be exposed publicly for all to see, as they're more often implemented on a private network.
Second, implement authentication for users that can connect using TLS or other supported methods -- ideally, multifactor authentication -- if they're supported for any of the open APIs. Also, don't allow images to be run on any Docker hosts that aren't trusted and signed by approved registries.
I've yet to find an enterprise that had Monero currency mining as a core business objective, so prevent that from happening with the equivalent of a Docker container image whitelist. Finally, make sure no one container can consume a disproportionate share of resources on the host.
By following these steps, organizations should be able to prevent hackers from taking advantage of their cloud containers for malicious activities, such as cryptojacking.