[BreachExchange] Containerd Bug Exposes Cloud Account Credentials

[Destry Winant]

https://threatpost.com/containerd-bug-cloud-account-credentials/160546/

The flaw (CVE-2020-15157) is located in the container image-pulling process.

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.