ContainerDrip, Another Example of Why HTTP Basic Authentication Is Flawed
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.
Join the DZone community and get the full member experience.Join For Free
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).
Illustration of the ContainerDrip attack scenario:
The conceptual problem I see here is giving your secrets to a semi-authenticated entity. When opening an HTTPS connection against evil.com, you and your browser are making additional efforts to ensure this is the site you wanted to visit. You typed evil.com in your browser address bar and the browser cross-checked the URL with the TLS certificate. In automated DevOps processes, such as docker pull or even other REST API-based redirections, there is no human part of the process. If someone fed the system with a malicious URL and automation ended up there, there is nothing you can do since anyone can get a valid TLS certificate for their domain. Therefore, I call these sites semi-authenticated since the TLS certificate is valid but we have not validated the reason to end up there.
This bring us to my point: Even with authenticated entities, we should not share secrets. Protocols, like HTTP basic authentication, are outdated because the client shares their secret with the verifier in order to get authenticated. There are many crypto protocols out there that are based on zero-knowledge proofs (asymmetric cryptography) or require the client to prove that they have the secret by asking it to hash a nonce with the secret. Such protocols and methods should be the basis of the future authentication standards in cloud native and microservices based architectures.
Hope I made sense :-) Follow me on: https://www.linkedin.com/in/benyamin-ben-hirschberg-66141890/
Opinions expressed by DZone contributors are their own.