Is your Docker security strategy up to par? In this post, we’re focusing on Docker container security and how you can keep your system protected against hackers.
Are Docker Containers Secure?
Whether Docker containers are secure or not depends on your Docker security strategy. They’re not inherently unsecure, and they do enable developers to build, ship, and run applications quickly and safely. However, Docker isn’t infallible. Not having an effective Docker security strategy could leave you open to attack.
What’s more, Docker has a lot of moving parts. This makes it more complex to secure than other deployment technologies. You need to take a comprehensive approach when safeguarding your system, because a Docker vulnerability can come from anywhere.
Read on to learn more about Docker security and how to protect your stack from attackers.
5 Docker Security Vulnerabilities You Need to Know
Now that we’ve touched on Docker container security, let’s look at some of the ways containers become compromised. Below are five Docker security issues to look out for.
CVE-2018-8115: Jack-in-the-box vulnerability
This vulnerability only affects users of Docker for Windows.
It allows hackers to insert malicious code into special container images. That code is then executed by the Windows Host Computer Service Shim library (hcsshim), thus allowing malicious parties to remotely execute code in on host’s file system.
CVE-2019-5736: runC container escape vulnerability
This is a Docker vulnerability that enables malicious parties to gain root-level access to a host’s system by overwriting their runC binary. If successful, the attacker gains control of the host’s system, where they have unlimited access to the server and access to any containers deployed on that server.
CVE-2020-13401: IPv6 input validation vulnerability
CVE-2020-13401 is a Docker vulnerability found in Docker Engine up to 19.03.10. It’s classified as a critical vulnerability because it allows attackers to perform a man-in-the-middle attack (MitM) against another container or the host’s network.
Hackers can use this vulnerability to spoof IPv6 router advertisements. If successful, they can remotely obtain sensitive information and cause DDoS attacks.
CVE-2018-15664: Docker cp vulnerability
Remote attackers can exploit this Docker vulnerability to gain root access to the host’s filesystem by hijacking an initiated Docker cp operation. If the attack is successful, the attacker can change the location of one or more files being written to any desired location on the host’s file system.
CVE-2018-11757: Apache OpenWhisk vulnerability
This vulnerability allowed malicious parties to exploit a bug present in Docker Skeleton Runtime for OpenWisk. If successful, attackers can overwrite a function’s source code in the container. From there, attackers could gain access to sensitive information, edit or delete data, and leech computing resources.
Insight into How Attackers Use Docker Security Against You
You probably already know this, but if you leave an API or vulnerable application exposed long enough, it will eventually get hacked.
That’s exactly what happened with Docker Daemon APIs that are left unsecured, and many became compromised by malicious cryptomining software.
If you visit hub.docker.com, you’ll notice there are countless containers for mining cryptocurrency. Those containers can be used as intended, or they can be used maliciously by compromising an unwitting host and leeching their resources.
When used as good, these containers simply mine cryptocurrency. When used maliciously, they mine cryptocurrency for the malefactor. See the difference?
Investigating a reported cryptojacking attack
There are numerous anecdotal reports on forums talking about compromised Docker containers. This report from 2018 talked about how an attacker exploited a Docker vulnerability and used their server to mine cryptocurrency.
While this falls under the leave vulnerable applications exposed and they’re going to get hacked category, there are some interesting artifacts in the report. Here’s what this sort of attack looks like.
Disclaimer: We can’t say for sure that the specific container below was used in the attack, and we’re not in a position where we can directly observe it. For the purposes of this article, we’re taking the user at their word.
The attack in question
After gaining access to the Docker server, the attacker downloaded a preconfigured cryptomining application from hub.docker.com. That application was used to leech resources from the victim’s system, and those resources were used to mine cryptocurrency directly to the attacker’s wallet.
This configuration is based on the frequently-used lightweight Alpine Linux base:
Container definition on hub.docker.com
This container definition takes us further into a GitHub repository used for automated builds on Docker Hub. We can see from the commit history that the attacker updated the configuration and even experimented with mining different cryptocurrencies.
In the picture below, they are mining the cryptocurrency, Monero.
Commit history for Dockerfile
GitHub Commit changing target pool, and changing from Monero to the cryptocurrency, Aeon
This particular Docker configuration isn’t the only thing our attacker was working on. As of April 6, they set up new repositories and switched the Docker base from Alpine to Ubuntu 16.04. They are also using the “-av=2” switch, which is used for low-power cryptomining on virtual CPUs.
Newly committed repository indicating the shift from Ubuntu Base OS
The configured wallet and pool lead us directly to the attacker’s wallet activity. Judging from their overall activity with Monero, we can see that their cryptomining efforts have been fairly successful. They mined 175 Monero coins (XMR), which was worth approximately $35,000 USD during the time this log was generated.
The historical hash rate for configured wallet
Vulnerable APIs put you at risk of cryptojacking
In real-world tests, deployed configurations with an intentional Docker vulnerability have been compromised within hours.
In our own tests, we found that these vulnerable configurations were used to download Minergate mining software from Docker Hub.
The software was then launched using the attacker’s login information in the command line. Using the Docker client from their machine, the attacker quickly deployed a malicious container. What’s more, they exploited a Docker vulnerability using the same command-line tools that are designed to manage Docker more easily.
Network capture of an attack in progress, currently downloading the Minergate Docker container
What’s the moral of this story? Don’t deploy configurations with a Docker vulnerability.
Effective and opportunistic hackers have an arsenal of automated tools that scan and detect unsecure APIs and other vulnerabilities. And these are the same tools that…
- Make it easier for you to manage and deploy Docker environments
- Enable you to easily mine cryptocurrency
Given the opportunity, malicious parties can turn these tools against you, compromise your Docker container security, and syphon away your resources.
Docker Container Security Best Practices
Now, for the good news. Protecting your network isn’t as hard as you think –– you just need an effective container security strategy. If you don’t know where to start, read the practices below. They will help you take the first step towards strengthening your Docker container security.
Keep privileges limited
Your Docker security strategy will never be effective if you can’t control who’s accessing your containers. That’s why cybersecurity experts encourage organizations to follow the least privileges principle. This approach grants users the minimum privileges necessary to complete their tasks, reducing the likelihood of privilege escalation.
Never assign root privileges unless absolutely necessary. Consider creating a non-root user and making that your default container configuration, just to err on the side of caution. Also, it never hurts to do a privilege audit from time to time to see who and what has root access.
Prioritize Docker container security from the start
From day one, Docker container security should be at the center of your container strategy — when you’re aware of these vulnerabilities, you’re less likely to fall victim to attacks.
If you’ve already adopted and deployed containers, don’t worry. You can prioritize Docker container security right away, so you’re better protected from potential threats. Here’s how you can do it:
- Stay up to date on the thread landscape by joining a Docker security forum
- Ensure your security strategy and your security applications work across multiple platforms
- Keep your host operating system updated and always patched
Remember, good Docker container security starts with the host. If your host gets compromised, it leaves all your processes open to attacks as well.
Only pull images from trusted sources
You wouldn’t download software from an unknown source on the internet, would you? The same logic applies to Docker images.
You should always know and trust the origin of your container images. Many Docker security breaches are a result of vulnerable images and opening yourself up to an attack can wreak havoc across your entire organization. That’s why you should only trust images from reputable registries that perform vulnerability tests and only hosts images from trusted partners.
Limit your resources
Setting Docker CPU usage restrictions and memory limits doesn’t only help your Docker environment run efficiently –– it can also protect you from attacks. If you have a compromised container, this means attackers can divert your computing resources to a rogue activity, like cryptomining.
Docker’s default setting is to share resources equally, without any limits. But you can put restrictions on how containers consume resources. We recommend allocating the resources each container needs so it can function accordingly, without disrupting other services. Doing so will strengthen your Docker security and help prevent bottlenecks and DoS occurrences.
Constantly monitor your system
Vigilance is an essential element of any Docker container security strategy. You should record every access to your system, services, and applications, and then conduct regular audits of that data. Check your logs for anomalies––it could mean something in your container environment has been compromised.
If you do experience an attack from a Docker vulnerability, your logs will serve as forensic evidence. They can help you get to the root of the problem, and they can serve as a paper trail in the event that you must demonstrate compliance.
The Takeaway
Ultimately, Docker is only as safe or unsafe as you allow it to be.
It’s impossible to keep yourself 100% invulnerable. Docker is always going to have common vulnerability exposures (CVE) from time to time. But the steps above will help you minimize risk and reduce the chances of falling victim to an attack.
Consider getting a Managed Threat Detection and Response solution that fills in the gaps your Docker security campaign misses. That way, you can rest easy while your business is protected by industry experts who specialize in cybersecurity.
