Cisco announced a few days ago that it discovered and fixed a critical vulnerability in its CloudCenter Orchestrator, whereby a misconfiguration caused the Docker Engine management port to be reachable outside of the CloudCenter Orchestrator system. An attacker could exploit this vulnerability by loading Docker containers on the affected system with arbitrary privileges. As a secondary impact this may allow the attacker to gain root privileges on the affected CloudCenter Orchestrator.
So what does it mean when you configure a Docker Engine management port to be reachable outside of the system? Let’s review what happens.
We start by configuring Docker Engine to listen to remote API requests. This is done by modifying Docker service file and adding “-H=0.0.0.0:2376” parameter to the Docker daemon command.
Note that we can also add TLS parameters (--tlscacert, --tlscert and --tlskey) to use encrypted channel.
We now start the Docker Engine daemon. Notice that in the system journal there is a warning about “--tlsverify” parameter. Nevertheless Docker is fully functional and allows local and Remote access.
You can now access the Docker Engine from a remote machine. Just add “-H tcp://<host IP>:2376” to your Docker commands.
You can now download images and run containers on the remote host. If you know your Docker run parameters you can easily get to a state where you can tamper with the remote host file system, add users, and run processes. The below example shows how we can add a file on the remote host root filesystem using a non-privileged container:
What went wrong?
Assuming remote access was needed in the first place (otherwise it should not have been configured) then this vulnerability could have been prevented if Docker Daemon was configured for authentication of the remote TLS communication. This is controlled using the “--tlsverify” parameter of the Docker Daemon run command.
You can follow the following guide for how to setup Docker Daemon for remote communication:
https://docs.docker.com/engine/security/https/
As you can see below, once Docker Daemon is configured correctly an anonymous remote connection is blocked:
Conclusion:
Similar to the Vine incident that we blogged about earlier this year, this isn’t a vulnerability in Docker itself. Rather, it’s improper configuration of Docker in the application context.
Whether this was due to ignorance of the implications of neglecting to configure the system properly, or due to the lack of a process to test and vet the environment before release, the lesson to be learned is that organizations should be extra careful when implementing a new technology such as Docker. They must understand how to configure deployments correctly, and follow well-documented best practices.
I believe that there are many more such vulnerabilities yet to be discovered, which also highlights the need for a layered approach to security. A single point of failure is always asking for trouble. There are quite a few controls that Aqua provides, any one of which could prevent or mitigate a vulnerability like this one from being exploited - including out-of-the-box access control for Docker commands, not allowing an unregistered image to run, not allowing a container to run as root, and not allowing a container to escalate privileges. If you’d like to know more - schedule a demo with us.
Docker Security, Network, Cisco, Host Security, Vulnerability Management