CVE-2023-22647

9.9 CRITICAL

📋 TL;DR

This CVE-2023-22647 vulnerability in SUSE Rancher allows standard users with existing permissions to manipulate Kubernetes secrets in the local cluster, potentially gaining access to service account tokens. The issue affects Rancher versions from 2.6.0 before 2.6.13 and from 2.7.0 before 2.7.4. Attackers can exploit improper privilege management to escalate privileges within Kubernetes clusters managed by Rancher.

💻 Affected Systems

Products:
  • SUSE Rancher
Versions: from >= 2.6.0 before < 2.6.13, from >= 2.7.0 before < 2.7.4
Operating Systems: Linux
Default Config Vulnerable: ⚠️ Yes
Notes: Affects Rancher deployments managing Kubernetes clusters where standard users have permissions to manipulate secrets.

📦 What is this software?

⚠️ Risk & Real-World Impact

🔴

Worst Case

Attackers gain full control over Kubernetes clusters by accessing service account tokens, leading to data exfiltration, resource hijacking, or complete cluster compromise.

🟠

Likely Case

Privileged users or compromised accounts escalate privileges to access sensitive secrets and service accounts, potentially compromising multiple workloads.

🟢

If Mitigated

With proper RBAC controls and network segmentation, impact is limited to specific namespaces or resources the user already had access to.

🌐 Internet-Facing: MEDIUM
🏢 Internal Only: HIGH

🎯 Exploit Status

Public PoC: ✅ No
Weaponized: LIKELY
Unauthenticated Exploit: ✅ No
Complexity: MEDIUM

Requires authenticated user with existing permissions; exploitation involves multiple steps including secret manipulation and follow-up commands.

🛠️ Fix & Mitigation

✅ Official Fix

Patch Version: 2.6.13, 2.7.4

Vendor Advisory: https://github.com/rancher/rancher/security/advisories/GHSA-p976-h52c-26p6

Restart Required: Yes

Instructions:

1. Backup Rancher configuration and data. 2. Upgrade to Rancher 2.6.13 if on 2.6.x series. 3. Upgrade to Rancher 2.7.4 if on 2.7.x series. 4. Restart Rancher services. 5. Verify cluster functionality post-upgrade.

🔧 Temporary Workarounds

Restrict Secret Manipulation Permissions

linux

Tighten RBAC policies to prevent standard users from manipulating Kubernetes secrets.

kubectl create clusterrole restricted-secret-access --verb=get,list,watch --resource=secrets
kubectl create clusterrolebinding restrict-secrets --clusterrole=restricted-secret-access --group=system:authenticated

🧯 If You Can't Patch

  • Implement strict RBAC controls limiting standard users' access to Kubernetes secrets and service accounts.
  • Monitor and audit all secret manipulation operations in Kubernetes audit logs for suspicious activity.

🔍 How to Verify

Check if Vulnerable:

Check Rancher version: kubectl get pods -n cattle-system -l app=rancher -o jsonpath='{.items[0].spec.containers[0].image}' | grep -o 'rancher/rancher:v[0-9.]*'

Check Version:

kubectl get pods -n cattle-system -l app=rancher -o jsonpath='{.items[0].spec.containers[0].image}'

Verify Fix Applied:

Verify version is 2.6.13 or higher for 2.6.x series, or 2.7.4 or higher for 2.7.x series using same command.

📡 Detection & Monitoring

Log Indicators:

  • Unusual secret deletion operations followed by service account token access attempts
  • Multiple failed then successful secret manipulation events from same user

Network Indicators:

  • Unexpected API calls to Kubernetes secrets endpoints from standard user accounts

SIEM Query:

source="kubernetes-audit" AND (verb="delete" AND resource="secrets") AND (verb="create" AND resource="serviceaccounts/token")

🔗 References

📤 Share & Export