diff --git a/src/pentesting-web/saml-attacks/README.md b/src/pentesting-web/saml-attacks/README.md index 860d32b0632..799379a60de 100644 --- a/src/pentesting-web/saml-attacks/README.md +++ b/src/pentesting-web/saml-attacks/README.md @@ -217,6 +217,8 @@ The talk linked in the Tools section also demonstrates XSLT-oriented SAML testin **XML Signature Exclusion** tests how a SAML implementation behaves when the `Signature` element is absent. A vulnerable service may skip signature validation and accept altered assertion content.[[8]](#references) +Do not treat a missing signature and a bad signature as equivalent tests. Some consumers reject a present-but-invalid signature but interpret a missing `Signature` as "nothing to verify" and continue. Compare a valid signed baseline, the same message with a corrupted `SignatureValue`, and a message with **every response- and assertion-level signature removed**. If only the last variant succeeds, the omission has bypassed the validator branch rather than defeating cryptographic verification.[[17]](#references) + ![https://epi052.gitlab.io/notes-to-self/img/saml/signature-exclusion.svg](<../../images/image (457).png>) ### XML Signature Exclusion Tool @@ -229,9 +231,12 @@ With the signatures removed, forward the request. If the Service Provider accept Some products keep the **SAML authentication endpoint reachable even when SSO was never configured**. If a constructor or config-loading error leaves security fields at language defaults such as `""` or `false`, the unconfigured path can become **less secure** than the configured one.[[13]](#references) +The same failure can occur after SAML is enabled when verification is conditional on nullable trust material, for example `if (verificationCertificate != null) verify(response)`. A missing certificate must disable authentication or hard-fail the request; it must never route parsed attacker input directly to identity extraction. SolarWinds Web Help Desk 2026.1 and earlier demonstrated this pattern in CVE-2026-28323, while a second branch accepted absent signatures even when a certificate was configured.[[16]](#references)[[17]](#references) + ### What to test - Reach the SAML ACS / login handler while SSO is **disabled**, **never configured**, or after deleting its config. The handler should fail closed before parsing attacker-controlled XML. +- Enable SAML but leave the verification certificate unset, empty, deleted, or unreadable, then submit directly to the ACS. Missing trust material must be a rejecting state rather than a reason to skip verification.[[17]](#references) - Check whether missing configuration skips initialization of fields such as the **signature verification mode**, **trusted issuer**, **audience**, **certificate path**, or **local-user policy**, while request processing still continues. - Look for **fail-open mode checks** such as `if mode in {response, assertion, both} verify_signature(...)` with **no rejecting `else`**. An empty / malformed mode can silently disable both response- and assertion-signature verification. - Compare **presence checks** with **normalized comparisons**. A whitespace-only `` can satisfy `issuer != null`, then be trimmed to `""` and match an empty configured issuer. @@ -249,6 +254,36 @@ Practical details to check: A recent example of this pattern is the Synology DS925+ SAML SSO bypass documented by Chanze Lee. +### End-to-end forged-response workflow + +Once signature enforcement fails, test a schema-valid response whose selected assertion contains the target local identity in `Subject/NameID`. Prefer a known existing account and confirm authorization on a protected resource: auto-provisioning an unknown `NameID` may yield a session that is authenticated-looking but unusable.[[17]](#references) + +A stateful ACS may still require cookies or anti-CSRF fields. A reliable test client should preserve the full browser-side state and discover dynamic values instead of hard-coding them:[[17]](#references) + +```text +GET login page -> retain session cookie +parse current form action and CSRF token +build schema-valid Response with the target NameID and no Signature elements +Base64-encode the XML as required by the HTTP-POST binding +POST CSRF token + SAMLResponse with the same cookie jar +request a protected page/API and verify the resolved identity and privileges +``` + +### Assertion-context validation matrix + +A valid XML signature protects only the signed object; the SP must consume that same object and separately establish that the assertion is successful, current, intended for this SP, and bound to the expected login transaction. Mutate each property independently because a consumer may enforce one while ignoring the others.[[4]](#references)[[17]](#references) + +| Mutation | Secure acceptance condition | Failure enabled | +| --- | --- | --- | +| Remove both response- and assertion-level signatures; separately corrupt a present signature | A trusted signature must cover the response or the exact assertion subsequently consumed; both absence and invalidity reject | Arbitrary identity forgery | +| Remove the configured verification certificate / IdP trust object | Authentication stops before `NameID` extraction | Configuration-driven fail-open | +| Set `Issuer` to an arbitrary or other IdP | Response/assertion issuer matches the configured trusted IdP | Unauthorized-IdP assertion reuse | +| Point `Destination` at another ACS | Destination equals this SP's registered ACS URL | Cross-SP response submission | +| Exclude this SP entity ID from `AudienceRestriction` | Audience contains this SP | Token recipient confusion | +| Use future `NotBefore`, expired `NotOnOrAfter`, or omit time restrictions | Assertion satisfies the SP's bounded-lifetime policy with only explicit clock skew | Old/future assertion replay | +| Omit `InResponseTo` or reference an unrelated request | For SP-initiated SSO, it matches a still-pending `AuthnRequest`; any supported IdP-initiated mode is tested as a separate policy | Unsolicited or uncorrelated login | +| Return a non-success `StatusCode` with a usable assertion | Non-success status blocks identity extraction | Authentication despite IdP failure | + ## Certificate Faking Certificate faking tests whether a **Service Provider (SP) verifies that a SAML message is signed** by a trusted Identity Provider (IdP). Sign the SAML Response or Assertion with a **self-signed certificate** to determine whether the SP validates the certificate trust relationship.[[8]](#references) @@ -497,5 +532,7 @@ The same parser weakness that gives an overread can also crash the SAML processi - [13] [Pwn2Own Ireland 2025: Bypassing Authentication via Synology DS925+ SAML SSO](https://chanzep.github.io/posts/pwn2own-ireland-2025-bypassing-authentication-via-synology-ds925-saml-sso) - [14] [How to test SAML: a methodology (part one)](https://epi052.gitlab.io/notes-to-self/blog/2019-03-07-how-to-test-saml-a-methodology/) - [15] [youtube.com - Watch](https://www.youtube.com/watch?v=WHn-6xHL7mI) +- [16] [SolarWinds Web Help Desk SAML Authentication Bypass Vulnerability (CVE-2026-28323)](https://www.solarwinds.com/trust-center/security-advisories/cve-2026-28323) +- [17] [Signature Optional: Analysis of CVE-2026-28323](https://bishopfox.com/blog/signature-optional-analysis-of-cve-2026-28323) {{#include ../../banners/hacktricks-training.md}}