CVE-2023-3597 - Keycloak’s Authentication Bypass via Invalid Step-Up 2FA Registration Explained

---

Keycloak is widely used for single sign-on (SSO) and identity management solutions for both public and enterprise applications. In June 2023, a potential security disaster came to light with the discovery of CVE-2023-3597, a flaw that allows authenticated users to bypass or weaken multi-factor authentication (MFA).

What Is CVE-2023-3597? The Real-World Problem

Keycloak implements “step-up authentication,” meaning that after you login with username and password (first factor), you may be asked for a second authentication step (like a TOTP code).

But, in some Keycloak versions, the code responsible for managing this flow is not strict enough in step-up validation. Here’s how attackers abused this weakness:

They log in using their password.

2. They register a malicious (or fake) second factor, alongside an existing one (or even by tricking the workflow).
3. That bypasses the second-factor requirement, fooling Keycloak into thinking extra 2FA was performed, even when it wasn’t.

Attack Walkthrough: Step-by-Step

Let’s walk through a practical exploit scenario, borrowing from Red Hat’s advisory and community discussions.

Assume:
- Attacker has a valid username/password.

Tamper with factor registration:

Instead of submitting an actual 2FA code, the attacker manipulates the registration branch to *enroll* a “fake” device/factor.

- They can do this via API calls or crafted web requests—Keycloak accepts their “new” factor as legitimate due to poor backend checks.

Bypass achieved:

The system moves forward, believing step-up was fulfilled, even though there was never a *real* secondary verification.

The heart of the issue is in code similar to this (simplified)

// org.keycloak.authentication
public void authenticate(AuthenticationFlowContext context) {
    // ... existing user session check
    if (userHasRegisteredSecondFactor(context.getUser())) {
        // Allow access
        context.success();
    } else {
        // Offer to register second factor (here is where the logic is weak)
        context.challenge(createRegistrationForm());
    }
}

In this pattern, the act of attempting to register a new factor is *not properly separated* from proving ownership of an existing factor.

Attackers exploit this by combining registration and step-up in a single session or request.

Proof of Concept: Simulating the Flaw

Let’s say an attacker uses CURL or Burp Suite to submit a crafted POST to /auth/realms/{realm}/login-actions/authenticate:

POST /auth/realms/demo/login-actions/authenticate

action=register&credential_type=totp&totp_code=fake1234

Upon receiving this, Keycloak adds a “totp” credential for the user, but doesn’t actually validate ownership or verify the code strictly!

How to Fix

Official Resolution:
You need to update to a patched Keycloak version (22..1+). Always review Keycloak Release Notes for your version.

References

- Red Hat CVE-2023-3597 Security Advisory
- Keycloak Issue Tracker - JIRA
- Keycloak Release Notes

What’s the Takeaway?

A bug in one line of logic gave attackers a cheap ticket into protected data. Whenever a system’s multi-factor system lets users “add” new credentials without validating the *current* factor, all bets are off.

Patch now. Audit. And never trust MFA registration without strict verification.

If you’re responsible for a Keycloak deployment, apply all security updates and review your authentication flows. More flaws like CVE-2023-3597 are yet to be discovered!

Timeline

Published on: 04/25/2024 13:15:50 UTC
Last modified on: 04/25/2024 13:18:02 UTC