CVE-2024-9487 - GitHub Enterprise Server SAML SSO Authentication Bypass

In early 2024, security researchers uncovered a serious flaw—CVE-2024-9487—affecting GitHub Enterprise Server (GHES). This vulnerability allowed attackers to bypass SAML Single Sign-On (SSO) authentication, leading to unauthorized user provisioning and access to sensitive resources. Here, we’ll take a deep look at what went wrong, how it could be exploited, and what you need to do if you run a GitHub Enterprise Server instance.

This post is written in straightforward American English, aiming to help you understand the incident even if you don’t have deep security chops.

The Gory Details: What’s CVE-2024-9487?

This vulnerability is all about improper verification of cryptographic signatures in the way GHES handles SAML authentication. Quite simply, when a user logs in using SAML SSO, the system is supposed to check the digital signature (proof of authenticity) on the SAML assertion carefully.

But if you had the encrypted assertions feature enabled, the GitHub Enterprise Server could incorrectly accept a forged or manipulated SAML response or metadata document, as long as the attacker had a valid signed document to start with.

As a result, SAML SSO authentication could be bypassed, and attackers could create users or gain unauthorized access to the instance.

Direct network access to your GHES instance.

- Possession of a signed (but potentially reused/modified) SAML response or metadata document.
- Impact: Attacker can create/modify users — in essence, they could walk right in the front door.

This vulnerability was responsibly reported via the GitHub Bug Bounty program.

SP verifies the signature. If valid, lets the user in.

CVE-2024-9487 exploited weak points in steps 3-4. When the SAML assertion was encrypted, GitHub Enterprise Server didn’t validate the signature strictly enough. So, if an attacker could snag a legitimate signed response, they could modify or replay it (with user info tweaked) and trick the server into accepting it as valid, resulting in new accounts or unauthorized logins.

Exploit Scenario

Let’s say an attacker is on the same network as GHES, maybe as a rogue employee or someone who’s gained VPN access. They get ahold of a legitimate signed (and encrypted) SAML response (sometimes easier than you’d hope, if logs are poorly protected or through phishing).

They could then modify the decrypted assertion to forge a new user or escalate privileges, then re-encrypt it — relying on the original document’s signature to pass through the weak verification.

The key: GitHub Enterprise Server failed to correctly verify that the decrypted assertion was actually signed or otherwise valid!

Code Snippet: What Might the Vulnerable Check Look Like?

Here’s a simplified Python-style pseudocode for how SAML assertion validation could look in a broken implementation:

def process_saml_response(saml_response):
    if config.ENCRYPTED_ASSERTIONS_ENABLED:
        assertion = decrypt(saml_response.encrypted_assertion)
        # ⚠️ BUG: Only checking overall response signature, not the assertion itself!
        if validate_signature(saml_response): 
            return authenticate_user(assertion)
        else:
            return fail_auth()
    else:
        assertion = saml_response.assertion
        if validate_signature(assertion):
            return authenticate_user(assertion)
        else:
            return fail_auth()

The problem above? When assertions are encrypted, only the top-level response is validated, but the decrypted assertion (user data) isn’t re-signed or re-verified. This gap is what attackers could exploit.

Original References

- GitHub Security Advisory for CVE-2024-9487
- Official Release Notes
- GitHub Bug Bounty

3.14.2

- If you cannot upgrade, disable encrypted SAML assertions as a temporary workaround (but check with your security policy/team first).

TL;DR — What You Need to Know

- CVE-2024-9487 lets attackers skip SAML login if they have internal network access and capture a valid signed SAML response.

Always keep your enterprise software up to date — and watch those cryptographic checks!

*This writeup is exclusive and aims to clearly explain the risk and resolution for CVE-2024-9487 affecting GHES. For further details, check the official GitHub advisory.*

Timeline

Published on: 10/10/2024 22:15:11 UTC
Last modified on: 11/15/2024 16:57:10 UTC