Kubernetes: SSRF vulnerability can be exploited when a hijacked aggregated api server such as metrics-server returns 30X

Report Submission Form

Summary:

This report uses metrics-server as example, but it should be applicable to any aggregated api server.

When metrics-server is hijacked, either by modifying the container image directly or by running another pods using the same label selector in kube-system namespace, and is returning 30X redirect, the clients calling the metrics api will follow the redirect.

It could be a serious issue in managed Kubernetes offerings such as Azure Kubernetes Service (AKS) where clients from managed components may be redirected to call the internal endpoints.

Note: my coworker, Nicolas Joly, found the issue and reported my team (AKS)

Kubernetes Version:

all k8s versions on AKS. I believe it’s the same in other cloud providers.

Component Version:

n/a

Steps To Reproduce:

• Attached main.go is a very simple redirection api server. I’ve built the docker image on weinong/go-redirect.
• update and deploy go-redirect.yaml with your endpoint to capture the redirected traffic in kube-system namespace. It uses the same pod label selector as metrics-server does
• you should be able to observe redirected traffic from the control plane components

Supporting Material/References:

Sample output being logged in the web server capturing redirected traffic:

2022/04/16 00:30:13 src IP: 20.51.80.40:4096
GET / HTTP/1.1
Host: 20.85.59.5
Accept: application/json, */*
Accept-Encoding: gzip
Authorization: Bearer <omitted>
User-Agent: azurepolicyaddon/v0.0.0 (linux/amd64) kubernetes/$Format

GET / HTTP/1.1
Host: 20.85.59.5
Accept: application/vnd.kubernetes.protobuf, */*
Authorization: Bearer <omitted>
User-Agent: kube-controller-manager/v1.17.13 (linux/amd64) kubernetes/f4a8e76/system:serviceaccount:kube-system:generic-garbage-collector

2022/04/16 00:34:37 src IP: 20.69.190.88:21504
GET / HTTP/1.1
Host: 20.85.59.5
Accept: application/json, */*
Accept-Encoding: gzip
Authorization: Bearer  <omitted>
User-Agent: cpmonitor/v0.0.0 (linux/amd64) kubernetes/$Format

• [attachment / reference]

Impact

• Bearer token may be logged in the logging system in those internal backend
• Potentially, they may be logged by kube-controller-manager or kubernetes api-server at certain verbose level (not verified)
• Redirected traffic may hit external/internal endpoints for spamming which would look originating from the cloud providers