A security vulnerability can be exploited to coerce the containerd cloud platform into exposing the host’s registry or users’ cloud-account credentials.
Containerd bills itself as a runtime tool that “manages the complete container lifecycle of its host system, from image transfer and storage to container execution and supervision to low-level storage to network attachments and beyond.” As such, it offers deep visibility into a user’s cloud environment, across multiple vendors.
The bug (CVE-2020-15157) is located in the container image-pulling process, according to Gal Singer, researcher at Aqua. Adversaries can exploit this vulnerability by building dedicated container images designed to steal the host’s token, then using the token to take over a cloud project, he explained.
“A container image is a combination of a manifest file and some individual layer files,” he wrote in a recent post. “The manifest file [in Image V2 Schema 2 format]…can contain a ‘foreign layer’ which is pulled from a remote registry. When using containerd, if the remote registry responds with an HTTP 401 status code, along with specific HTTP headers, the host will send an authentication token that can be stolen.”
He added, “the manifest supports an optional field for an external URL from which content may be fetched, and it can be any registry or domain.”
The attackers can thus exploit the problem by crafting a malicious image in a remote registry, and then convincing the user to access it through containerd (this can be done through email and other social-engineering avenues), according to the National Vulnerability Database writeup.
“If an attacker publishes a public image with a manifest that directs one of the layers to be fetched from a web server they control, and they trick a user or system into pulling the image, they can obtain the credentials used for pulling that image,” according to the bug advisory. “In some cases, this may be the user’s username and password for the registry. In other cases, this may be the credentials attached to the cloud virtual instance which can grant access to other cloud resources in the account.”
Non-Trivial Exploitation
Researcher Brad Geesaman at Darkbit, who did original research into the vulnerability (which he calls “ContainerDrip”), put together a proof-of-concept (PoC) exploit for a related attack vector.
One of the hurdles for exploitation is the fact that containerd clients that pull images may be configured to authenticate to a remote registry in order to fetch private images, which would prevent it from accessing the malicious content. Instead, an attacker would need to place the tainted image into a remote registry that the user already authenticates to.
“The question became: ‘How do I get them to send their credentials to me [for remote-registry authentication]?'” he said in a posting earlier this month. “As it turns out, all you have to do is ask the right question.”
The Google Kubernetes Engine (GKE) is a managed environment for running containerized applications, which can be integrated with containerd. When GKE clusters running COS_CONTAINERD and GKE 1.16 or below are given a deployment to run, a Basic Auth header shows up, which when base64 decoded, turns out to be the authentication token for the underlying Google Compute Engine, used to create virtual machines. This token is attached to the GKE cluster/nodepool.
“By default in GKE, the [Google Cloud Platform] service account attached to the nodepool is the default compute service account and it is granted Project Editor,” explained Geesaman.
That said, also by default, a function called GKE OAuth Scopes “scopes down” the available permissions of that token. Geesaman also found a workaround for that.
“If the defaults were modified when creating the cluster to grant the [“any”] scope to the nodepool, this token would have no OAuth scope restrictions and would grant the full set of Project Editor IAM permissions in that GCP project,” he explained.
And from there, attackers can escalate privileges to “Project Owner” using a known attack vector demonstrated at DEF CON 2020.
He added that the GKE path is one of many possible.
containerd patched the bug, which is listed as medium in severity, in version 1.2.4; containerd 1.3.x is not vulnerable.
Cloud security continues to be a challenge for organizations. Researchers earlier in October disclosed two flaws in Microsoft’s Azure web hosting application service, App Services, which if exploited could enable an attacker to take over administrative servers. Over the summer, malware like the Doki backdoor was found to be infesting Docker containers.
In April, a simple Docker container honeypot was used in a lab test to see just how quickly cybercriminals will move to compromise vulnerable cloud infrastructure. It was quickly attacked by four different criminal campaigns over the span of 24 hours.
