Docker Hub Repositories Harbour Malicious Containers

In much the same way that GitHub has been used by malicious threat actors to distribute malware, it would not be long until Docker Hub would be abused for similar purposes. In a recent report published by Sysdig over 1,600 publicly available Docker Hub images are been used to hide malicious behavior, including cryptocurrency miners, embedded secret keys and other authenticators that can be used as backdoors, DNS hijackers, as well as website redirectors.

Docker Hub functions as a cloud-based container library that allows users to browse and download Docker images, alternatively, users can upload their creations to the public library or personal repositories.

A Docker image is a template that allows for the quick and easy deployment of a Docker container.

An image will typically include ready-to-use code that allows for much faster application development time. This has resulted in developers using Docker Hub to find images for the fast turnaround of applications.

Unfortunately, this rise in popularity has resulted in hackers attempting to spread malware by making malicious images appear like popular and useful images that already exist on the repository.

Docker Hub has implemented a system known as the Docker Library Project that checks if the image adheres to best practices and that the image developers provide clear documentation and regular updates.

Further, Docker Hub enables Independent Software Vendors (ISVs) via The Docker Verified Publisher Program. This allows images to be signed by verified partners, greatly reducing the risk users face when downloading an image.

Sadly, not all users check that the image they download has been verified by the above means and place themselves at risk of downloading malware.

During Sysdig’a analysis they investigated over 250,000 Linux images and identified 1,652 of them as malicious. Summarizing their findings, researchers noted,

“As expected, cryptomining images are the most common malicious image type. However, embedded secrets in layers are the second most prevalent, which highlights the persistent challenges of secrets management. Secrets can be embedded in an image due to unintentionally poor coding practices or this could be done intentionally by a threat actor. By embedding an SSH key or an API key into the container, the attacker can gain access once the container is deployed. To prevent accidental leakage of credentials, sensitive data scanning tools can alert users as part of the development cycle.”

It is the hiding of secret keys in images, like an API key or SSH key is potentially the most worrying for developers. This is primarily due to the hacker being able to create a backdoor onto the developer's system and potentially a corporate network.

While having several software packages can speed up development tenfold, the research done above clearly also shows the risks involved. To this extent, Sysdig researchers concluded,

“Much of the software used today depends on numerous amounts of other software packages. The origin of these dependencies is extremely varied with some being produced and supported by major corporations, while others are developed by unknown parties who may not be supporting their projects anymore…This notion of sharing code has also spread to containers, where people can easily share their container-based creations on sites like Docker Hub. This has made testing and deploying entire platforms very easy, but has also increased the risk of using something malicious. Threat actors are placing malware into shared containers, hoping users will download and run them on their infrastructure. The malware installed can be anything from cryptominers to backdoors to tools that will automatically exfiltrate data.”

Container Supply Chain Security

Broadly speaking the docker attacks mentioned above, be it the installing of a crypto miner or backdooring a system with a hidden key, can be classified as a supply chain attack.

Such an attack can be defined when a malicious party manages to gain access to your data and infrastructure via a third-party. In this sense, the third party is the downloaded Docker image that if malicious will install a crypto miner as an example. How then does one secure your Docker or Kubernetes supply chain to benefit from faster development times but remain secure?

One article published on the News Stack noted that developers need to look to secure the entire container stack. Further, during each phase of deployment security checks should take place to determine possible risks and mitigation of those risks.

When securing the entire container stack it is advised that off-the-shelf images, from Docker Hub for example, that aren’t properly verified be avoided entirely.

Even when using a verified image care should be taken, and a zero-trust policy adopted, to see what potential vulnerabilities exist inside the image.

These could easily become your vulnerabilities, waiting to be exploited. Care also needs to be taken when building on top of base images. Taylor Smith notes,

“...let’s say the frontend of your application uses Go, so you copy a frontend you found on GitHub using golang:1.2.0 as the base image. Well, you’ve now already included at least fourteen vulnerabilities, five of which are critical, and you haven’t even added your application components yet…Instead, if you pulled that base image from a fully vetted registry, you could cut those vulnerabilities out from the start. Imagine if your application is entirely Go-based with 100 microservices. With the off-the-shelf version, you’ve introduced thousands of entry points for a bad actor. With a trusted image, you’ve significantly reduced the attack surface.”

Containerisation has been a revolution for developers and companies. Developers can bring products to market faster, helping their companies remain competitive.

However, the use of containers like Docker of Kubernetes has opened up new attack vectors and threat actors are more than willing to exploit them.

Often faster development cycles can lead to sloppy security and hackers are all too aware of this.

▼ Show Discussion