VRT Addition - SAML Replay

[adamdyche]

Description

---

With more and more companies implementing SAML into their systems to provide end users more login options to their systems. Additional SAML related vulnerabilities should be considered as part of the VRT process. As such I am proposing the addition of SAML Replay as a part of the VRT. While SAML Replay is typically associated with MiTM, as you need access to the post body containing the SAML Assertion in order to pull off the attack. It is possible for the request or post body to be obtained in a logging environment typically associated with the Service Provider, or the end user having a SSL inspection service provided by their parent company logging requests to a SIEM for potential insider threat monitoring. In this case MiTM, or local replay of the vulnerability is just a means to demonstrate the misconfiguration of the service providers SAML service, and the potential security implications that has.

Definition of SAML Replay and Remediation Requirements/Sources

---

By default, a SAML Assertion is vulnerable to Replay attacks. A replay attack involves the unauthorized reuse of a SAML Assertion performing a legitimate SAML action such as SSO. This when accomplished allows for the attacker to successfully impersonate the victim providing full access to the Service Provider without any prior access to the Identity Provider or any of the victim's information, bypassing all login requirements.

There are two things required to successfully remediate this vulnerability. The first is to ensure that the SAML Configuration of the Service Provider validates the NotBefore and NotOnorAfter attribute within the SAML Assertion to only allow it to be used during that 10-minute window. The second thing that needs to be done is that the Service Provider must keep a cache record of all SAML Assertion ID's as each one is unique to that request, prevent reuse if the same Assertion ID is seen more than once.

https://snyk.io/blog/common-saml-vulnerabilities-remediate/
https://nvd.nist.gov/vuln/detail/CVE-2018-14637
https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html
https://stackoverflow.com/questions/62204127/spring-security-saml-replay-attack-prevention
https://attack.mitre.org/techniques/T1606/002/
https://attack.mitre.org/techniques/T1212/
https://hackerone.com/reports/888930

Changes

---

Addition to the VRT

Template Drafted	Priority	VRT Category	Specific vulnerability names	Variant / Affected function	CVSS String
X	Varies	Broken Authentication and Session Management	SAML Replay	No Expiration	AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H

In regard to the proposed changes, and specifically the variant of a SAML Replay. That is in place for when the Service Provider which configured the SAML integration doesn't respect the NotOnorAfter associated with the Assertion allowing it to be replayed after it was meant to no longer be valid. As when it is respected it is meant to only be accepted during the 10-minute window.

The Priority associated with a SAML Replay will vary based on the security impact associated with the type of data the Server Provider holds, associated actions assigned to admin accounts/normal users, as well as any compliance requirements. Lastly if the Assertion can be replayed after the 10-minute window the raises the priority as it means it can essentially be accepted whenever.

Proposed Triage Testing

---

For the proposed triage testing the agent would perform the following actions:

1. Review the submission based on Bugcrowd policies/procedures
2. Once confirmed that the submission meets reporting requirements confirm that the SAML Replay exists
3. For this they can either follow the steps as outlined in the submitted reports Proof of Concept directly or perform the following steps
4. Register with the Service Provider and an Identity Provider if accounts do not already exist.
5. Setup SAML within the Service Provider and Identity Provider by following the necessary steps outlined by the service provider if an integration does not already exist for testing
6. Launch Burp
7. Launch a browser that can talk to Burp that contains a containerized service such as Firefox with the Multi-Account Containers extension to ensure that multiple tabs cannot talk to each other. Additionally, you can use two separate browsers as long as they both talk to Burp
8. Log into the Identity Provider and launch the app
9. In Burp look for the associated POST request containing the SAMLResponse payload.
10. Right-click on the request, select Request In Browser, select any option and copy
11. Paste the Burp generated URL in either a new containerized tab, or the other browser
12. After which you should have a successful SAML Replay
13. Pass on the report to the program owner as Triaged.

Notes

---

Please note, that the proposed risk ranking is based purely on CVSS and doesn't account for any additional compliance regulatory concerns like GDPR, CCPA, PCI, SOX, SOC, etc.

Lastly it should always be up to the Program Owner on if they are willing to accept the report after Triage based on their own internal policies or procedures. As any valid vulnerability regardless of attack vector, likelihood of attack, etc. should always be sent to the program owner unless it is something truly out of scope, or a known issue based on the individual program and not the triage process.

[Saharpourkhani]

B

[TimmyBugcrowd]

Hey @adamdyche

Sorry for the late response on this. I've looked into your issue and did researcher on my side as well and I totally agree with this new VRT entry. While the token can be obtained in different ways I also believe it must be handled case by case, hence the Varies priority.
I also agree with it being nested under Broken Authentication and Session Management. I will make sure that this will be added in the next VRT release.

Thank your your participation.