CVE-2024-45409 - Critical Authentication Bypass in Ruby SAML Library – How Hackers Could Forge Logins (Exploit Details Inside)

CVE-2024-45409 is a serious vulnerability affecting the Ruby SAML library, which is widely used by developers to add SAML-based Single Sign-On (SSO) to their Ruby apps. This bug allows an attacker to forge SAML login responses. In plain terms: If your system uses a vulnerable version, an attacker could sign in as any user—even as an admin—without ever knowing a password.

All projects using Ruby-SAML v1.13. through v1.16. and <= v1.12.2

- Any Ruby app that uses SAML for login via this library, including gems like devise_saml_authenticatable, omniauth-saml, etc.

Why Is This a Big Deal?

SAML is a standard for allowing one site (the _Identity Provider_, or IdP) to tell another site (the _Service Provider_, or SP; your app) who a user is. It's what powers “Sign in with SSO” at many companies.

The huge risk:
A flaw in verifying SAML response signatures means that attackers can craft their own authentication tickets, tricking any Ruby SAML-based app into logging them in as whoever they want.

What was the bug?

Ruby-SAML failed to correctly validate the signature on SAML Responses. Even if the signature was only present on another part of the document (such as inside an Assertion), the library would accept the entire SAML Response as “trusted.” This means an attacker could take a legitimate, signed SAML response and attach their own forged assertion—no signature required on the forged part.

Reference:
- Ruby-SAML GitHub Security Advisory
- NVD Entry for CVE-2024-45409

Step-by-Step Exploit Scenario

Suppose Alice gets a valid SAML response from your company IdP. The attacker, Mallory, can do the following:

Intercept or obtain any signed SAML document (even not meant for them).

2. Copy the valid signature from the Response but swap in their own, unsigned Assertion naming them as another user (say, “admin”).

Here’s a Simple Exploit Code Snippet (Python-ish Pseudocode)

> Note: This is illustrative—real SAML handling requires more details! But the basic idea looks like this:

# Assume you have a valid SAML Response signed by the IdP:
valid_response_xml = open('legit_response.xml').read()

# You craft your own Assertion:
evil_assertion = """
<saml:Assertion>
  <saml:Subject>
    <saml:NameID>admin@example.com</saml:NameID>
  </saml:Subject>
  <saml:AttributeStatement>
    <saml:Attribute Name="role">
      <saml:AttributeValue>admin</saml:AttributeValue>
    </saml:Attribute>
  </saml:AttributeStatement>
</saml:Assertion>
"""

# Place your evil_assertion into the body of the valid_response_xml,
# keeping the <ds:Signature> from the original response intact.

new_response_xml = inject_evil_assertion(valid_response_xml, evil_assertion)

# Then, POST new_response_xml to the SAML endpoint of the vulnerable Ruby app.
import requests
requests.post('https://target-app.com/saml/acs';, data={'SAMLResponse': b64encode(new_response_xml)})

In practice, you’d use a SAML library to handle proper encoding, but this is the idea. The key: There’s a valid signature somewhere, but your assertion is not signed, and the app still trusts it!

Upgrade ruby-saml to 1.17. or 1.12.3 (depending on your branch).

- If you use devise_saml_authenticatable or omniauth-saml, make sure their dependencies are patched too.

Gemfile example

# Secure version
gem 'ruby-saml', '~> 1.17.'

Then:

bundle update ruby-saml

Check your Gemfile.lock for vulnerable versions:

  bundle list | grep ruby-saml
  

References

- GitHub Security Advisory for CVE-2024-45409
- CVE-2024-45409 on NIST NVD
- OneLogin ruby-saml Releases
- SAML in Simple Terms (Intro)

In Summary

CVE-2024-45409 is a scary, easy-to-exploit bug that breaks SAML authentication in Ruby systems. If you use SSO in Ruby, patch now—attackers could already be logging in as you read this!


Got questions or need help? Comment below or tweet at us. Stay safe, patch fast!

Timeline

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