Threat Alert: Exploiting Open Docker Daemons for DDoS Attacks

Aqua’s research team continuously investigates and analyzes the anatomy of new attacks in the wild. Recently, we identified attacks that exploited misconfigured open Docker daemons, where attackers were actively using this attack vector to hijack environments in order to launch targeted DDoS attacks. Each of the attacks were carried out using a botnet of containers, each based on a dedicated Docker image that the attackers created to carry out the attacks.

We identified two container-based botnet attacks that resulted in service request denials. The attackers used two Denial of Service methods:

UDP Flood Attack

A UDP flood is a Denial of Service (DoS) attack where UDP packets are continually sent to the target host, using random ports. In a UDP flood attack, the denial of service occurs since the targeted host is continually engaged in checking if system processes are listening to the requested ports and returning a Destination Unreachable message when they are not. This cyclic process ties system resources, which overloads the server and renders it inaccessible.

Slowloris Attack

A Slowloris attack is a DoS attack that targets HTTP servers, using a dedicated software, for example slowhttptest. During the attack the targeted hosts continually receive incomplete HTTP requests. The targeted host keeps multiple open connections while waiting to receive the completed request. As a result, the server reaches the maximum concurrent open connections, making it unable to open new connection to service legitimate HTTP requests.

The Attack Chain

To carry out each attack, the attackers used dedicated Docker images. The images each have an entry point and are assigned command arguments.

Following are the attacks’ details:

Each of the attacks targeted unprotected Docker daemons. To carry out the attacks, the attackers needed to obtain the following information:

• Identified open Docker daemons
• Obtained Docker images with the capabilities they required
• A Docker client to deploy the images onto the remote daemons

To identify open Docker daemons, the attackers likely used a scanning tool, for example, shodan, which periodically scan the Internet for IP addresses and provides a list of hosts, open ports and services.

Next, the attackers built dedicated images and uploaded them to Docker hub. Then, they used their own Docker client (through an API, or with the docker client binary itself) to deploy and run the images remotely on the exposed hosts.

The Anatomy of the Attacks

Let’s now take a look at the images that the attackers used, and the steps that we followed to analyze the attacks.

The Udpflood Attack

In this attack we identified the entry point of the image as /udpflood. A quick search of the binary on VirusTotal reveals no results.

Next, we inspected the binary with IDA. We noticed an invocation of two threads: the first start_routine is called start_flood, and the second start_routine is called start_tick.

This new information led us to discover that the source code is available on Github. Comparing the udpflood binary with the source code, we found online reveals several differences between the two.

For example, try_gb is a parameter that sets the amount of data to send in order to flood the target. In the public source code, the try_gb parameter is limited to the range of 0 to 1024 as shown in the snippet below:

diep is an exit function which accepts an error message

The error message is: You specify to send too much traffic; it is easy to be judged Abuse. 

From the attack’s details we notice the command line for the udpflood binary includes the argument -g 30720 and the range check for try_gb parameter was missing:

This is the beginning of the main function. Source: Ghidra decompiler.

The anomalies as well as the similarities that we identified, led us to believe that udpflood is a self-compiled binary of the modified open source code. However, as the name suggests, the modified binary works in the exact same way as the open source binary, by flooding the target host with UDP packets.

The slowhttptest Attack

The entry point for this image is “slowhttptest”, which is not recognized on VirusTotal.

Slowhttptest is a utility that leverages DoS attacks and Kali distribution by default.

We believe that to carry out the slowhttptest attack, the attackers created a self-complied binary, as the variant of the binary file is unidentified by malware scanning tools, for example Virus Total. However, the self-compiled file carries many similarities to the open source version.

The slowhttptest binary has numerous capabilities, but as we can see in the command line for the binary, the ‘-H’ flag is set, and specifies the attack to be “slowloris”.

Connecting the Dots

Let’s look at the similarities of both attacks. Both were executed in the following ways:

• The attackers identified the target—open Docker daemons
• Chose the DDoS method
• Modified and compiled open source tools to better suit their needs
• Created Docker images with the modified tools
• Uploaded the images to Docker Hub
• Infected open Docker daemons to create a botnet
• Ran the attacks from the botnet, in order to make the targets inaccessible

Another thing that the attacks had in common was that they both targeted AliBaba cloud based hosted servers:

The attackers’ choice of targets points to the reason they compiled the binaries– cloud service providers offer some protection from DDoS attacks, and because they support multiple, concurrent open connections, the attackers had to send a high volume of packets to the target hosts. To that end, the attackers modified the source code to add additional capabilities, and then compiled the files. Another reason the attackers used their own compiled files was to avoid detection by security products that might be found on the compromised hosts.

Additionally, both images were removed from the Docker hub after the attacks.

It is common for attackers to do more than deploy and run an unauthorized image. It is also easy for attackers to take control over on the host machine or persist themselves there, as described in the Maneuver Docker API for Host Takeoverpost. 

Summary

In summary, we identified two separate yet very similar attacks, which took place in the cloud native ecosystem. The attackers exploited open Docker daemons in order to create a botnet and used this botnet to DDoS their targets. This analysis of this case study serves as a good example for how attackers are adjusting to the move to the cloud by enterprises. We see how attackers continuously adapt, modify their tools, and develop new attack vectors. We can also see the difficulties both the attackers, and the defenders face.

What can I do?

Misconfigured Docker daemons are an easily exploited target and for multiple purposes. To protect your environment from similar attacks, make sure to deploy assurance policies in your environment. Assurance policies protect your environment by allowing only compliant images to run. Any non-compliant or unauthorized containers are blocked when instantiated.