The attacker, with one captured signed SOAP envelope from a victim and no other privileges, can invoke arbitrary operations on the service as the victim principal for the lifetime of the captured signing key. There is no rate limit on replays. The DetectReplays setting on transport-security bindings does not mitigate the issue because the attack does not reuse the original timestamp — the fresh timestamp in the wsse:Security header is …
An unauthenticated remote attacker who can place a SOAP header lexically before wsse:Security can embed a ds:Signature of their choosing inside that header and cause the server to verify the attacker-supplied signature instead of the one carried in the security header.
CoreWCF’s WS-Security 1.0 receive pipeline validates the SignatureMethod of an incoming ds:SignedInfo against the configured SecurityAlgorithmSuite, but does not validate the DigestMethod declared on each ds:Reference. As a result, a sender can populate ds:SignedInfo with SignatureMethod values the suite accepts (for example rsa-sha256 under Basic256Sha256) while declaring a per-reference DigestMethod the suite rejects (for example http://www.w3.org/2000/09/xmldsig#sha1). The signature is then verified where it permits SHA-1 digests, and the message is …
When the proof key recovered from the RSTR can be observed by a party that is not the legitimate client, that party can impersonate the authenticated Windows principal for the lifetime of the SCT (default ~10 hours) and decrypt or forge any subsequent WS‑SecureConversation traffic that uses keys derived from the SCT.
When a service is configured to validate SAML tokens using a method other than X.509 certificate signing, the final signature verification is skipped.
When enabling DetectReplayedTokens, a token can be replayed and will be detected despite it being reused.
The relying application is given a ClaimsPrincipal for a subject whose authority over the assertion the sender never proved. There are two distinct exploit shapes: Holder-of-key downgrade. An attacker who obtains a holder-of-key SAML assertion that was issued without KeyInfo (issuer bug, custom STS shape, or assertion captured from an interaction where KeyInfo was elided) can present it to the service and be authenticated as the assertion’s subject without producing …
Full impersonation of any principal the trusted STS could have issued an assertion for — including administrative principals when the relying party grants them via SAML claims. Affects both SAML 1.1 and SAML 2.0.