How hackers know vulnerabilities of my docker containers?
Docker and containers are becoming ever more popular and settling into the standard toolkit of developers and ops folks. Docker runs as a daemon named “dockerd”, which serves as the top-level interface to Docker’s core functionality. The “docker” command line tool for example, talks to dockerd to get your task done. The API that dockerd exposes, variously called the Docker API or the Docker Remote API. The port 2375 is the de-facto standard for the Docker API. As it stands, the endpoint is unauthenticated and unencrypted. see: IANA allocates port 2375 to docker
Now, let us go to a search engine to find the how many docker daemons are available to hack via default port 2375 port of Docker. On 1 June 2020, at 11 Am , Indian Standard Time (GMT :+5.30) by using shodan.io , I found 5,209 docker daemons are prone to hackers.
Top Docker hosts version with the remote API exposed publicly.
18.06.1-ce: 3,604
17.05.0-ce: 672
19.03.8: 293
1.13.1: 164
18.05.0-ce: 29
Even the latest Stable release 19.03.8 / March 10, 2020 is inviting hackers.
But what hacker’s do with your docker container?
The possibilities for attackers after spawning a container on hacked Docker hosts are endless. The 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. Mining cryptocurrency is just one example.
• Access files on the Docker host and mounted volumes.
• Scan the internal network
• Credentials leakage
• Data Leakage
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.
Vulnerabilities related to docker / popular docker images:
LATEST DOCKER RELATED Vulnerabilities:(solutions at end)
CVE-2020-13401 |
An issue was discovered in Docker Engine before 19.03.11. An attacker in a container, with the CAP_NET_RAW capability, can craft IPv6 router advertisements, and consequently spoof external IPv6 hosts, obtain sensitive information, or cause a denial of service. Published: June 02, 2020; 10:15:10 AM -04:00 |
V3.1: 9.8 CRITICAL V2: 7.5 HIGH |
---|---|---|
CVE-2020-11878 |
The Jitsi Meet (aka docker-jitsi-meet) stack on Docker before stable-4384-1 uses default passwords (such as passw0rd) for system accounts. Published: April 17, 2020; 12:15:14 PM -04:00 |
V3.1: 9.8 CRITICAL V2: 7.5 HIGH |
CVE-2020-10952 |
GitLab EE/CE 8.11 through 12.9.1 allows blocked users to pull/push docker images. Published: March 27, 2020; 03:15:11 PM -04:00 |
V3.1: 6.5 MEDIUM V2: 5.8 MEDIUM |
CVE-2020-5252 |
The command-line "safety" package for Python has a potential security issue. There are two Python characteristics that allow malicious code to “poison-pill” command-line Safety package detection routines by disguising, or obfuscating, other malicious or non-secure packages. This vulnerability is considered to be of low severity because the attack makes use of an existing Python condition, not the Safety tool itself. This can happen if: You are running Safety in a Python environment that you don’t trust. You are running Safety from the same Python environment where you have your dependencies installed. Dependency packages are being installed arbitrarily or without proper verification. Users can mitigate this issue by doing any of the following: Perform a static analysis by installing Docker and running the Safety Docker image: $ docker run --rm -it pyupio/safety check -r requirements.txt Run Safety against a static dependencies list, such as the requirements.txt file, in a separate, clean Python environment. Run Safety from a Continuous Integration pipeline. Use PyUp.io, which runs Safety in a controlled environment and checks Python for dependencies without any need to install them. Use PyUp's Online Requirements Checker. Published: March 23, 2020; 07:15:12 PM -04:00 |
V3.1: 4.1 MEDIUM V2: 1.9 LOW |
CVE-2020-10665 |
Docker Desktop allows local privilege escalation to NT AUTHORITY\SYSTEM because it mishandles the collection of diagnostics with Administrator privileges, leading to arbitrary DACL permissions overwrites and arbitrary file writes. This affects Docker Desktop Enterprise before 2.1.0.9, Docker Desktop for Windows Stable before 2.2.0.4, and Docker Desktop for Windows Edge before 2.2.2.0. Published: March 18, 2020; 03:15:18 PM -04:00 |
V3.1: 6.7 MEDIUM V2: 7.2 HIGH |
CVE-2020-7606 |
docker-compose-remote-api through 0.1.4 allows execution of arbitrary commands. Within 'index.js' of the package, the function 'exec(serviceName, cmd, fnStdout, fnStderr, fnExit)' uses the variable 'serviceName' which can be controlled by users without any sanitization. Published: March 15, 2020; 06:15:14 PM -04:00 |
V3.1: 9.8 CRITICAL V2: 7.5 HIGH |
CVE-2019-12825 |
Unauthorized Access to the Container Registry of other groups was discovered in GitLab Enterprise 12.0.0-pre. In other words, authenticated remote attackers can read Docker registries of other groups. When a legitimate user changes the path of a group, Docker registries are not adapted, leaving them in the old namespace. They are not protected and are available to all other users with no previous access to the repo. Published: February 17, 2020; 09:15:11 AM -05:00 |
V3.1: 4.3 MEDIUM V2: 4.0 MEDIUM |
CVE-2020-5239 |
In Mailu before version 1.7, an authenticated user can exploit a vulnerability in Mailu fetchmail script and gain full access to a Mailu instance. Mailu servers that have open registration or untrusted users are most impacted. The master and 1.7 branches are patched on our git repository. All Docker images published on docker.io/mailu for tags 1.5, 1.6, 1.7 and master are patched. For detailed instructions about patching and securing the server afterwards, see https://github.com/Mailu/Mailu/issues/1354 Published: February 12, 2020; 08:15:11 PM -05:00 |
V3.1: 8.8 HIGH V2: 6.5 MEDIUM |
CVE-2020-8945 |
The proglottis Go wrapper before 0.1.1 for the GPGME library has a use-after-free, as demonstrated by use for container image pulls by Docker or CRI-O. This leads to a crash or potential code execution during GPG signature verification. Published: February 12, 2020; 01:15:10 PM -05:00 |
V3.1: 9.8 CRITICAL V2: 7.5 HIGH |
CVE-2019-19921 |
runc through 1.0.0-rc9 has Incorrect Access Control leading to Escalation of Privileges, related to libcontainer/rootfs_linux.go. To exploit this, an attacker must be able to spawn two containers with custom volume-mount configurations, and be able to run custom images. (This vulnerability does not affect Docker due to an implementation detail that happens to block the attack.) Published: February 12, 2020; 10:15:12 AM -05:00 |
V3.1: 7.0 HIGH V2: 4.4 MEDIUM |
CVE-2014-5278 |
A vulnerability exists in Docker before 1.2 via container names, which may collide with and override container IDs. Published: February 07, 2020; 01:15:10 PM -05:00 |
V3.1: 5.3 MEDIUM V2: 4.3 MEDIUM |
CVE-2019-3682 |
The docker-kubic package in SUSE CaaS Platform 3.0 before 17.09.1_ce-7.6.1 provided access to an insecure API locally on the Kubernetes master node. Published: January 17, 2020; 04:15:10 AM -05:00 |
V3.1: 7.8 HIGH V2: 4.6 MEDIUM |
CVE-2019-14819 |
A flaw was found during the upgrade of an existing OpenShift Container Platform 3.x cluster. Using CRI-O, the dockergc service account is assigned to the current namespace of the user performing the upgrade. This flaw can allow an unprivileged user to escalate their privileges to those allowed by the privileged Security Context Constraints. Published: January 07, 2020; 01:15:10 PM -05:00 |
V3.1: 8.8 HIGH V2: 6.5 MEDIUM |
CVE-2014-0048 |
An issue was found in Docker before 1.6.0. Some programs and scripts in Docker are downloaded via HTTP and then executed or used in unsafe ways. Published: January 02, 2020; 12:15:10 PM -05:00 |
V3.1: 9.8 CRITICAL V2: 7.5 HIGH |
CVE-2014-8179 |
Docker Engine before 1.8.3 and CS Docker Engine before 1.6.2-CS7 does not properly validate and extract the manifest object from its JSON representation during a pull, which allows attackers to inject new attributes in a JSON object and bypass pull-by-digest validation. Published: December 17, 2019; 01:15:13 PM -05:00 |
V3.1: 7.5 HIGH V2: 5.0 MEDIUM |
CVE-2014-8178 |
Docker Engine before 1.8.3 and CS Docker Engine before 1.6.2-CS7 do not use a globally unique identifier to store image layers, which makes it easier for attackers to poison the image cache via a crafted image in pull or push commands. Published: December 17, 2019; 09:15:16 AM -05:00 |
V3.1: 5.5 MEDIUM V2: 1.9 LOW |
CVE-2014-9356 |
Path traversal vulnerability in Docker before 1.3.3 allows remote attackers to write to arbitrary files and bypass a container protection mechanism via a full pathname in a symlink in an (1) image or (2) build in a Dockerfile. Published: December 02, 2019; 01:15:10 PM -05:00 |
V3.1: 8.6 HIGH V2: 8.5 HIGH |
CVE-2019-16884 |
runc through 1.0.0-rc8, as used in Docker through 19.03.2-ce and other products, allows AppArmor restriction bypass because libcontainer/rootfs_linux.go incorrectly checks mount targets, and thus a malicious Docker image can mount over a /proc directory. Published: September 25, 2019; 02:15:13 PM -04:00 |
V3.1: 7.5 HIGH V2: 5.0 MEDIUM |
CVE-2019-15752 |
Docker Desktop Community Edition before 2.1.0.1 allows local users to gain privileges by placing a Trojan horse docker-credential-wincred.exe file in %PROGRAMDATA%\DockerDesktop\version-bin\ as a low-privilege user, and then waiting for an admin or service user to authenticate with Docker, restart Docker, or run 'docker login' to force the command. Published: August 28, 2019; 05:15:10 PM -04:00 |
V3.0: 7.8 HIGH V2: 9.3 HIGH |
Source: National Vulnerability Database (NVD – USA) lists various vulnerability related to docker or popular images of docker in its hub: https://nvd.nist.gov/vuln/search/results?form_type=basic&results_type=overview&search_type=all&query=docker&startIndex=20
Solutions?
(a)Choosing another container technology: lxc/podman
(b) Running docker in daemon-less + rootless containers like lxc/podman
(c)If you can’t switch to another technology then make your docker more secure.
Refer to this article:
New Type of Docker : Rootless + Safer : for every Docker user.
manish srivastava ・ Jun 1 '20
I hope you people like the above article and learned something.
IMP REQUEST:
You are most welcome to join my team form for joining .
Also you are most welcome to join OPEN SOURCE INTELLIGENT SYSTEM (OSINT)if you can help in open source project regarding safeguarding humans from various diseases like CORONA outbreak
https://github.com/Manishfoodtechs/OSINTHRH/wiki
Contact email: Manishfoodtechs@gmail.com.
If you have any problem, our team is also engaged in professional consultancy and delivery.
Top comments (1)
Thanks Ankush. Glad you find my articles interesting 👍😊