At Black Hat 2017, researchers from Aqua Security demonstrated a new attack technique that enables attackers to...
use Docker APIs to hide malware on systems, and even potentially execute code in some cases. Over the past several years, containers have steadily grown in popularity within many development and operations environments due to their lightweight and efficient deployment model. However, new attacks, such as abuse of Docker APIs, raise concerns for information security teams.
The Docker attack
If you're saying to yourself, "That's complicated," then you're 100% correct. This attack is in fact enormously complex and it requires a very specific set of Docker REST APIs to be exposed in a specific way. While it definitely serves as an eye opener about how Docker could be abused in development and operations environments, the likelihood of this issue manifesting is probably low. Docker responded to the researchers who reported the issue and have since changed the default API configuration on Docker for Windows to disallow HTTP remotely. This update has further prevented the initial script hijacking from occurring at all. The best recommendation for any organizations running Docker for Windows is to update to the latest version that has this configuration update implemented. Additionally, Docker recommends restricting Docker remote access to authenticated clients by using certificates or other means to block Docker engine ports on certain interfaces where appropriate, and potentially disabling Microsoft-specific name resolution services, such as NetBIOS and LLMNR.
Docker security best practices
In many ways, implementing more stringent controls for how developers use Docker containers in development and testing scenarios can go a long way to mitigating these concerns. First, any implementation of a tool, like Docker for Windows, adds several new layers of complexity and potential security vulnerability to a developer's system. At a minimum, there will be a Moby Linux VM running the Docker engine, and any container OS and application stacks will also need to be secured.
Ideally, any systems used for development in this manner should be isolated from the rest of the main network and prevented from fetching code directly from the internet. One of the major elements of this attack is the retrieval of malicious code from online repositories that a new container will fetch and install -- this should be expressly forbidden on developer workstations. Instead, set up internal repositories that Docker containers can pull from and ensure that only those are in use within the environment.
Additionally, only allow approved Docker virtual machine builds and container instances to be used if possible, especially in any stage of the development and testing environments that are connected to the network. Scanning and security tools, such as Docker Bench and CoreOS Clair, can also be helpful in validating test images and new development configurations that you're testing.
Read an introduction to Docker and its effects on cloud security
Learn about what Docker Content Trust means for container security
Discover how Docker secrets management addresses security concerns