LAS VEGAS—A novel attack vector allows for adversaries to abuse the Docker API to hide malware on targeted systems, and even execute remote code.
The proof of concept attack was developed by researchers at Aqua Security, and the technique was first demonstrated today at Black Hat by Sagie Dulce, senior security researcher, with Aqua Security.
The attack works on any Docker installation which exposes its API through TCP, which has (until recently) been the default for Windows PCs running Docker for Windows, an application used by developers to create and test containerized applications.
“The attack endgame is a persistent remote code execution within the enterprise’s network,” Dulce said. “Persistence on the host computer is practically undetectable by existing security products from the host.”
“Only a limited subset of HTTP methods is allowed across origins, including GET, HEAD and POST,” Dulce said. The researcher not only used an API command that did not violate the SOP protection, but also spawned a Docker container on the host machine that uses a Git repository as Command and Control; as it hosts the malicious attack code.
“This container is kind of limited,” Dulce said. “What you really want is to access the entire Docker API so you can run any container you want such as a privilege container with more access to the host or the underlying virtual machine.”
To make that happen Aqua researchers created a “Host Rebinding Attack” technique that is similar to a “DNS Rebinding Attack.” That’s when an adversary abuses DNS to trick a browser into not-enforcing the Same Origin Policy. Aqua’s Host Rebinding Attack targets Microsoft name resolution protocols to achieve the same end goal, but this time via a virtual interface: so the attack itself cannot be detected over the network.
“Host rebinding rebinds a host IP address over the local network to another IP address. It is similar to DNS rebinding, but instead of spoofing DNS responses, controlling a domain, or otherwise meddling with the DNS service, we spoof responses to broadcasted name resolution protocols such as NetBIOS and LLMNR,” the researcher wrote.
The result is a (build) container running within the victim’s Hyper-V VM, sharing the host’s network and executing attacker-controlled arbitrary code, he explained.
“So now that we gained the ability to execute any command against Docker Daemon REST API, we effectively have full root access to the underlying Moby Linux VM. The next step is to leverage this to execute some malicious code, while remaining persistent on the host and concealed within virtual machine,” the researcher explained.
The next step in the attack requires the creation of what Dulce calls a “Shadow Container” that will allow (malicious) container instructions to remain persistent when the virtual machine is rebooted. “If the victim restarts the host or just restarts Docker for Windows, attacker will lose control. To overcome these problems, we suggest a technique we call a ‘Shadow Container’ attack. Using it we gain both persistence and concealment.”
To do this, the attacker writes a container shutdown script that preserves the attacker’s script/state.
“The result is a kind of ‘ping pong’ game, between storing the attack state over in a Shadow Container, and between writing it back to the virtual machine for concealment. When Docker restarts, either after Docker reset or after host reboot, it will run the attacker’s container (that saves the attack script),” he wrote.
This allows the attackers initial intent of staying concealed while being able to perpetrate network reconnaissance, planting malware, or moving laterally within the internal network.
“You have access to the internal network. You can scan the network and find open ports and move laterally, infect other machines,” Dulce said. “But the other thing you have is, because the target is a Docker developer, is a way to infect the local container images with the hope it will spread out in the entire enterprise Docker pipeline.”
Dulce and fellow researcher Michael Cherny, head of research for Aqua Security, said they notified Docker of this attack vector earlier this year.
They said that Docker acknowledged the problem and said it stemmed from allowing remote access to the Docker daemon over TCP/HTTP with all previous versions of Docker for Windows. Since then it has changed the default configuration, closing the HTTP port, to prevent that type of access to the Docker daemon.
Mitigation steps include updating Docker for Windows, but also only allowing authenticated clients (certificates) access to exposed ports, blocking port 2375 on the Moby Linux VM interface via a firewall and also disabling LLMNR and NetBIOS on all endpoints.