HTTP authentication is so prevalent we rarely question it. But attacks like ContainerDrip have an important reminder for authentication at scale in cloud-native environments.

The latest exploit in the series of issues with cloud infrastructure software is called “ContainerDrip” (CVE-2020-15157). In some cases, it can cause you to leak your registry secrets to an attacker. The attack is actually a kind of secret or password leak using request forgery. Your client unintentionally makes an HTTP API request to the attacker’s endpoint where this request contains the container image registry secret. In this post, I want to point out the bigger underlying problem, but first the attack.

In a nutshell, when you decide to pull a container image, you download its manifest file first – which describes how the container image actually looks. Container images are made of file system layers, and the manifest file tells you where you can download these layers one-by-one, based on URLs.

Without diving into the specifics, the general mechanics of the attack are that a malicious actor pushes a specially crafted manifest file to a public repository (like Docker Hub, let’s say “library/gonnastealyoursecret:v1”). In this manifest, they put a layer URL to their own webserver (https://registry.evil.com). Now, when someone tries to pull the image above, the containerd (managing images) makes a request https://toregistry.evil.com with the secret Docker registry credentials. This server will authenticate itself correctly using HTTPS, but will take the secret from the request and the attacker will have your Docker registry secrets. There are obviously more details, but this is not the point I want to make (see a complete writeup here).

#http #kubernetes