Summary
Rocket.Chat's SAML SSO implementation accepted signed XML responses without correctly binding the verified signature to the specific SAML Response or Assertion element.
This allows an attacker to craft a wrapped SAML document that includes forged identity attributes alongside any valid signature from the trusted IdP, potentially logging in as arbitrary users when SSO is enabled.
Rocket.Chat's SAML SSO implementation accepted signed XML responses without correctly binding the verified signature to the specific SAML Response or Assertion element.
This allows an attacker to craft a wrapped SAML document that includes forged identity attributes alongside any valid signature from the trusted IdP, potentially logging in as arbitrary users when SSO is enabled.
Affected context
This vulnerability occurs in Rocket.Chat deployments that:
- Use SAML-based Single Sign-On (SSO) with a trusted Identity Provider (IdP)
- Rely on XML signature verification without strict binding to the samlp:Response or saml:Assertion
- Accept SAML responses from the IdP and treat them as authoritative for user identity and attributes
It becomes relevant wherever the application trusts signed SAML assertions to establish authenticated sessions.
This vulnerability occurs in Rocket.Chat deployments that:
- Use SAML-based Single Sign-On (SSO) with a trusted Identity Provider (IdP)
- Rely on XML signature verification without strict binding to the samlp:Response or saml:Assertion
- Accept SAML responses from the IdP and treat them as authoritative for user identity and attributes
It becomes relevant wherever the application trusts signed SAML assertions to establish authenticated sessions.
Exploit preconditions
- Attack surface: The SAML SSO login endpoint receiving IdP responses
- Required access: Ability to submit crafted SAML responses to the application (e.g., control over the browser flow or a malicious IdP / proxy in the SSO chain)
- Trigger point: Processing of a signed SAML Response where the application verifies the XML signature but does not ensure that the signed element is the one used for authentication
- Why exploitation is possible: The implementation validates the signature but fails to bind it to the exact Response / Assertion element that is consumed, enabling a signature-wrapping attack with forged identity attributes inside an unsigned portion of the document.
- Attack surface: The SAML SSO login endpoint receiving IdP responses
- Required access: Ability to submit crafted SAML responses to the application (e.g., control over the browser flow or a malicious IdP / proxy in the SSO chain)
- Trigger point: Processing of a signed SAML Response where the application verifies the XML signature but does not ensure that the signed element is the one used for authentication
- Why exploitation is possible: The implementation validates the signature but fails to bind it to the exact Response / Assertion element that is consumed, enabling a signature-wrapping attack with forged identity attributes inside an unsigned portion of the document.
Why this happens
The underlying bug class is a signature-validation logic flaw in SAML processing. The code correctly verifies that a signature originates from a trusted IdP certificate, but does not enforce that the authenticated data (the samlp:Response or saml:Assertion actually used to map identity) is the element covered by that signature.
This pattern aligns with authentication bypass under CWE-287, where the authentication mechanism does not adequately enforce identity verification. Conceptually, the parser is susceptible to XML Signature Wrapping: it can be tricked into using an unsigned or differently signed assertion carrying attacker-chosen attributes, while still considering the overall message "trusted" because some valid signature is present elsewhere in the XML.
The underlying bug class is a signature-validation logic flaw in SAML processing. The code correctly verifies that a signature originates from a trusted IdP certificate, but does not enforce that the authenticated data (the samlp:Response or saml:Assertion actually used to map identity) is the element covered by that signature.
This pattern aligns with authentication bypass under CWE-287, where the authentication mechanism does not adequately enforce identity verification. Conceptually, the parser is susceptible to XML Signature Wrapping: it can be tricked into using an unsigned or differently signed assertion carrying attacker-chosen attributes, while still considering the overall message "trusted" because some valid signature is present elsewhere in the XML.
Potential impact
- Attackers can log in as arbitrary users within the Rocket.Chat instance
- Potential takeover of privileged or administrator accounts if targeted identities are forged
- Unauthorized access to private channels, direct messages, and internal communications
- Escalation from external attacker or rogue IdP to full control over a collaboration environment
- Lateral movement within an organization leveraging compromised chat accounts
- Attackers can log in as arbitrary users within the Rocket.Chat instance
- Potential takeover of privileged or administrator accounts if targeted identities are forged
- Unauthorized access to private channels, direct messages, and internal communications
- Escalation from external attacker or rogue IdP to full control over a collaboration environment
- Lateral movement within an organization leveraging compromised chat accounts
General mitigation guidance
Mitigation focuses on hardening SAML validation logic and reducing trust in loosely bound signatures:
- Ensure that XML signature verification is tightly bound to the specific samlp:Response or saml:Assertion element that will be used for authentication and attribute mapping
- Use well-tested SAML libraries and security profiles that explicitly protect against signature wrapping attacks (e.g., validating IDs and reference URIs, rejecting unexpected extra assertions)
- Enforce strict schema validation to reject SAML responses containing multiple or nested assertions in unusual structures
- Minimize reliance on complex, custom SAML parsing code and adopt defense-in-depth with robust session management and role assignment checks
- Apply least privilege to high-value accounts and enable monitoring for unusual SSO login patterns to limit damage if mis-validation occurs
Mitigation focuses on hardening SAML validation logic and reducing trust in loosely bound signatures:
- Ensure that XML signature verification is tightly bound to the specific samlp:Response or saml:Assertion element that will be used for authentication and attribute mapping
- Use well-tested SAML libraries and security profiles that explicitly protect against signature wrapping attacks (e.g., validating IDs and reference URIs, rejecting unexpected extra assertions)
- Enforce strict schema validation to reject SAML responses containing multiple or nested assertions in unusual structures
- Minimize reliance on complex, custom SAML parsing code and adopt defense-in-depth with robust session management and role assignment checks
- Apply least privilege to high-value accounts and enable monitoring for unusual SSO login patterns to limit damage if mis-validation occurs
How teams detect issues like this
Effective detection approaches typically combine code-level analysis with runtime signals:
- Use static analysis and security code reviews to identify SAML handling code that:
- Verifies signatures without binding them to the exact element consumed
- Accepts multiple assertions or responses without strict reference checking
- Depends on generic XML DOM traversal rather than ID-based resolution
- Review authentication pipelines for any custom XML parsing or manual handling of SAML assertions, especially where the signed element is selected by tag name or position instead of verified identifiers
- Apply security testing (including SAML-specific penetration tests) that exercise signature wrapping scenarios and malformed responses
- Consider automated SSO validation tools or integration tests that simulate attacker-controlled SAML messages and confirm that only signed and expected elements are honored
Effective detection approaches typically combine code-level analysis with runtime signals:
- Use static analysis and security code reviews to identify SAML handling code that:
- Verifies signatures without binding them to the exact element consumed
- Accepts multiple assertions or responses without strict reference checking
- Depends on generic XML DOM traversal rather than ID-based resolution
- Review authentication pipelines for any custom XML parsing or manual handling of SAML assertions, especially where the signed element is selected by tag name or position instead of verified identifiers
- Apply security testing (including SAML-specific penetration tests) that exercise signature wrapping scenarios and malformed responses
- Consider automated SSO validation tools or integration tests that simulate attacker-controlled SAML messages and confirm that only signed and expected elements are honored
Sources
| Source | Link |
|---|---|
| github. | github.com/ |
| hackerone. | hackerone.com/ |
