(This image was created with the assistance of DALL·E 2)
Haven’t we seen this request already? SAML replay attacks
Welcome back to our blog series: Vulnerability of the Month! With this series we would like to give you insights into our and our hackers’ daily work and talk about vulnerabilities. By doing so, we hope to help spread important security knowledge about specific vulnerabilities, how to find them, techniques used and by doing that raise awareness to all the vulnerabilities that may still be out there.
If you want to learn more about the series and why we do it this way, please have a look at the first blog post available here: https://www.bugbounty.ch/votm-jan-23/
Author: this month’s blog post was authored by Kaou Tamine
Credits: this month’s vulnerability was reported by the hacker simioni
Context of the Bug Bounty program
- A time-limited, budget-limited private program
- In scope are multiple cloud-based systems of the customer
- Time between launch of the program and submission of the report: ~2 months
Why this vulnerability
It’s a classic! Whenever there are authentication protocols, handling the auth tokens with all the properties like expiration date and nonce is hard. Not doing so correctly exposes the system to replay attacks of all kinds.
The system affected
A cloud-based system containing a data catalog and metadata about different kinds of data stored elsewhere. Specifically, the endpoint handling authentication and consuming the SAML assertions provided by the customers central identity provider (IdP).
The vulnerability as described by the hacker
This vulnerability is all about careful observation and proper verification of data on endpoints.
Here, the hacker notices that there is no expiration date on the SAML (the «NotOnOrAfter» condition). He also notices that the SAML assertion is not invalidated after use and can be reused. The attack is made clear on our platform with his Burp Suite manipulations (shoutout to Roland Bischofberger and Emanuel Duss for the great Burp Suite plugin 🙂):
- 1st request with the SAML assertion, issued on 18:39:
- The 2nd request, containing the same SAML assertion, issued on 18:51:
- The same request with the SAML response decoded (please note GMT vs. local time):
We can see the following:
A request with a reused SAML assertion, used after the «NotOnOrAfter» timestamp is still being accepted, the redirect to the SSO callback with a valid access token happens as with the valid, original assertion.
Impact analysis
The criticality is limited because of the precondition to acquire a valid SAML assertion first. But once having one, the assertion can be reused over an extended period of time, exposing the system behind the SAML based SSO authentication.
Let’s work together!
Interested in the topic and working with our customers and hackers on such vulnerabilities? We’re hiring – please get in touch: bugbounty.ch/en/jobs!
Interested in finding vulnerabilities? We’re always looking for new hacking talents – please register yourself here: bugbounty.ch/hacker!
All previous Vulnerability of the Month:
