Misconfigured Docker API endpoints allow attackers to deliver DDoS botnet agent

A new attack campaign deploys malicious container images on cloud servers by exploiting insecure Docker Engine API endpoints. The malicious image contains a distributed denial-of-service (DDoS) botnet implant written in Python.

“Once a valid endpoint is discovered, it’s trivial to pull a malicious image and launch a container from it to carry out any conceivable objective,” researchers from Cado Security said in a report. “Hosting the malicious container in Dockerhub, Docker’s container image library, streamlines this process even further.”

The malicious OracleIV image

The attack observed by Cado starts with a HTTP POST request to the /images/create endpoint of the unprotected Docker API followed by parameters that pointing to an image called oracleiv_latest that was uploaded to Docker Hub by a user named robbertignacio328832. This request is the equivalent of a docker pull command that downloads the container image and sets it up locally and is followed by a container start command.

The targeting of publicly exposed and unprotected Docker Engine APIs is not new. Several attack groups scan for such instances and typically deploy cryptojacking malware. One example is a group called TeamTNT whose primary targets are cloud environments. The group was behind a worm dubbed Silentbob that was launched earlier this year and targeted insecure Docker and Jupyter Notebook instances and stole AWS credentials.

Like this attack, TeamTNT hosted its malicious container images on Dockerhub from multiple accounts. The new OracleIV image found by Cado was being updated regularly and had over 3,000 downloads, suggesting the campaign was active and successful.

DDoS botnet and cryptojacking

Once started, the rogue container image executes an ELF binary called oracle.sh, followed by wget commands that pull in and execute a variant of the XMRig cryptocurrency miner with a custom configuration. The XMRig instance is not actually used, and these attackers are much more interested in hijacking the server’s resources for DDoS attacks.

The oracle.sh executable was originally written in Python code and was compiled with Cython (C-Extensions for Python). The code implements several different DDoS methods including TCP, UDP, and SYN packet floods, as well as target specific variations that aim to defeat various defenses.

For example, the standard UDP flood involves 40,000-byte packets that are fragmented because of the packet size limit of UDP creating an additional computational overhead on the target required to reassemble the fragments. However, the botnet also implements UDP floods with 18-, 20-, and 8-byte packets. These are launched with the commands called FIVE, VSE, and OVH and seem to be targeted at FiveM servers, Valve’s Source game engine, and French cloud computing company OVH.

The botnet also implements a Slowloris-type attack where it opens many connections to a server and continuously sends small amounts of data to keep those connections open. The bot client connects to a command-and-control server using basic authentication based on a hardcoded key, sends basic information about the host system, and listens for commands.

“The portability that containerization brings allows malicious payloads to be executed in a deterministic manner across Docker hosts, regardless of the configuration of the host itself,” the Cado researchers said. “Whilst OracleIV is not technically a supply chain attack, users of Docker Hub should be aware that malicious container images do indeed exist in Docker’s image library – an issue that seemingly won’t be rectified in the near future.”

The security firm advises organizations to periodically assess the Docker images they pull from Docker Hub to make sure they haven’t been Trojanized. Additionally, they should make sure all the APIs and management interfaces of cloud technologies such as Jupyter, Docker, and Redis are secured with authentication and protected by firewall rules.

Cyberattacks, DDoS