Docker is a technology that allows you to perform operating system level virtualization. An incredible number of companies and production hosts are running Docker to develop, deploy and run applications inside containers.

You can interact with Docker via the terminal and also via remote API. The Docker remote API is a great way to control your remote Docker host, including automating the deployment process, control and get the state of your containers, and more. With this great power comes a great risk — if the control gets into the wrong hands, your entire network can be in danger.

(Also, web application firewalls (WAFs) are quickly evolving into the next phase of application security, WAAP, according to Gartner. Read their whitepaper to learn about the merits of WAAP and why your enterprise may need it.)

In February, a new vulnerability (CVE-2019-5736) was discovered that allows you to gain host root access from a docker container.  The combination of this new vulnerability and exposed remote Docker API can lead to a fully compromised host.

According to Imperva research, exposed Docker remote API has already been taken advantage of by hundreds of attackers, including many using the compromised hosts to mine a lesser-known-albeit-rising cryptocurrency for their financial benefit.

In this post you will learn about:

• Publicly exposed Docker hosts we found
• The risk they can put organizations in
• Protection methods

Publicly Accessible Docker Hosts

The Docker remote API listens on ports 2735 / 2736. By default, the remote API is only accessible from the loopback interface (“localhost”, “127.0.0.1”), and should not be available from external sources. However, as with other cases —  for example, publically-accessible Redis servers such as RedisWannaMine —  sometimes organizations are misconfiguring their services, allowing easy access to their sensitive data.

We used the Shodan search engine to find open ports running Docker.

We found 3,822 Docker hosts with the remote API exposed publicly.

We wanted to see how many of these IPs are really exposed. In our research, we tried to connect to the IPs on port 2735 and list the Docker images. Out of 3,822 IPs, we found approximately 400 IPs are accessible.

Red indicates Docker images of crypto miners, while green shows production environments and legitimate services  

We found that most of the exposed Docker remote API IPs are running a cryptocurrency miner for a currency called Monero. Monero transactions are obfuscated, meaning it is nearly impossible to track the source, amount, or destination of a transaction.  

Other hosts were running what seemed to be production environments of MySQL database servers, Apache Tomcat, and others.

Hacking with the Docker Remote API

The possibilities for attackers after spawning a container on hacked Docker hosts are endless. Mining cryptocurrency is just one example. They can also be used to:

• Launch more attacks with masked IPs
• Create a botnet
• Host services for phishing campaigns
• Steal credentials and data
• Pivot attacks to the internal network

Here are some script examples for the above attacks.

1. Access files on the Docker host and mounted volumes

By starting a new container and mounting it to a folder in the host, we got access to other files in the Docker host:

It is also possible to access data outside of the host by looking on container mounts. Using the Docker inspect command, you can find mounts to external storage such as NFS, S3 and more. If the mount has write access, you can also change the data.

2. Scan the internal network

When a container is created in one of the predefined Docker network “bridge” or “host,” attackers can use it to access hosts the Docker host can access within the internal network. We used nmap to scan the host network to find services. We did not need to install it, we simply used a ready image from the Docker Hub:

It is possible to find other open Docker ports and navigate inside the internal network by looking for more Docker hosts as described in our Redis WannaMine post.

×

Nov 7 Upcoming Webinar

Elevate your Security Posture by Balancing Effectiveness and Efficiency

Register Now

3. Credentials leakage

It is very common to pass arguments to a container as environment variables, including credentials such as passwords. You can find examples of passwords sent as environment variables in the documentation of many Docker repositories.

We found 3 simple ways to detect credentials using the Docker remote API:

Docker inspect command

“env” command on a container

Docker inspect doesn’t return all environment variables. For example, it doesn’t return ones which were passed to docker run using the –env-file argument. Running “env” command on a container will return the entire list:

Credentials files on the host

Another option is mounting known credentials directories inside the host. For example, AWS credentials have a default location for CLI and other libraries and you can simply start a container with a mount to the known directory and access a credentials file like “~/.aws/credentials”.

4. Data Leakage

Here is an example of how a database and credentials can be detected, in order to run queries on a MySQL container:

Wrapping Up

In this post, we saw how dangerous exposing the Docker API publicly can be.

Exposing Docker ports can be useful, and may be required by third-party apps like ‘portainer’, a management UI for Docker.

However, you have to make sure to create security controls that allow only trusted sources to interact with the Docker API. See the Docker documentation on Securing Docker remote daemon.

Imperva is going to release a cloud discovery tool to better help IT, network and security administrators answer two important questions:

• What do I have?
• Is it secure?

The tool will be able to discover and detect publicly-accessible ports inside the AWS account(s). It will also scan both instances and containers. To try it, please contact Imperva sales.

We also saw how credentials stored as environment variables can be retrieved. It is very common and convenient, but far from being secure. Instead of using environment variables, it is possible to read the credentials on runtime (depends on your environment). In AWS you can use roles and KMS. In other environments, you can use 3rd party tools like Vault or credstash.

***

Check out the webinar with Imperva and Forrester Research on the topic, “Five Best Practices for Application Defense in Depth.” Listen to Terry Ray, Imperva SVP and Imperva Fellow, Kunal Anand, Imperva CTO, and Forrester principal analyst Amy DeMartine as they discuss how the right multi-layered defense strategy bolstered by real-time visibility to help security analysts distinguish real threats from noise can provide true protection for enterprises using open-source applications in the cloud (such as the Docker hosts above). Sign up to watch the recording!