DEV Community

Cover image for Why hackers 'first love' a docker container? Hacking Docker
manish srivastava
manish srivastava

Posted on • Updated on

Why hackers 'first love' a docker container? Hacking Docker

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.

Alt Text

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:

Alt Text

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:

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)

Collapse
 
manishfoodtechs profile image
manish srivastava

Thanks Ankush. Glad you find my articles interesting 👍😊