8.6 High
CVSS3
Attack Vector
LOCAL
Attack Complexity
LOW
Privileges Required
NONE
User Interaction
REQUIRED
Scope
CHANGED
Confidentiality Impact
HIGH
Integrity Impact
HIGH
Availability Impact
HIGH
CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H
9.3 High
CVSS2
Access Vector
NETWORK
Access Complexity
MEDIUM
Authentication
NONE
Confidentiality Impact
COMPLETE
Integrity Impact
COMPLETE
Availability Impact
COMPLETE
AV:N/AC:M/Au:N/C:C/I:C/A:C
0.003 Low
EPSS
Percentile
64.0%
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.
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:
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.
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.
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:
Here are some script examples for the above attacks.
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 inspectcommand, 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.
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.
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 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:
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”.
Here is an example of how a database and credentials can be detected, in order to run queries on a MySQL container:
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:
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.
Imperva is hosting a live webinar with Forrester Research on Wednesday March 27 1 PM PT on the topic, “Five Best Practices for Application Defense in Depth.” Join 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 and ask questions live or see the recording!
The post Hundreds of Vulnerable Docker Hosts Exploited by Cryptocurrency Miners appeared first on Blog.
8.6 High
CVSS3
Attack Vector
LOCAL
Attack Complexity
LOW
Privileges Required
NONE
User Interaction
REQUIRED
Scope
CHANGED
Confidentiality Impact
HIGH
Integrity Impact
HIGH
Availability Impact
HIGH
CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H
9.3 High
CVSS2
Access Vector
NETWORK
Access Complexity
MEDIUM
Authentication
NONE
Confidentiality Impact
COMPLETE
Integrity Impact
COMPLETE
Availability Impact
COMPLETE
AV:N/AC:M/Au:N/C:C/I:C/A:C
0.003 Low
EPSS
Percentile
64.0%