The Dangers of SAML Replay Attacks

Learn More

SAML PEN Testing Suite

Click ‘Learn More’ button to explore AssureBridge IDM 360™ SAML PEN Testing suite.

Learn More

Introduction

Single Sign-on represents a significant attack vector for hackers.  It is particularly vulnerable for two reasons.  If SSO is hacked, then by definition an illicit party has gained access to your system.   Further, SSO entry points are public knowledge.  A system that supports SSO has told other parties exactly what URL on what server is looking for SSO traffic.  This makes Single sign-on a very tempting target for intruders.

This blog will describe SAML Replay Attacks.  What are they?  How to determine if you are vulnerable and how to prevent them.  This blog is part of a series on SSO related vulnerabilities.

What is SAML Replay?

To understand SAML replay, let’s have a very quick refresher on a SAML Handshake.

A SAML Handshake is usually a 3 step process.

  1. A user attempts to access an application (Service Provider)
  2. The service provider sends via a SAML Authentication Request to the Identity Provider
  3. The identity provider sends a Signed Assertion back to the service provider (SP) identifying the user and allowing the SP to log them in.

The Authentication Request and Assertion are SAML documents and they are sent via browser redirects so they pass through the user’s browser.  This makes them easy to steal via techniques such as cross site scripting or malicious plugins.

In a replay attack.  The hacker steals the assertion from a legitimate user and the sends it to the service provider.

If successful, the hacker is then logged in under the original user’s identity.

How to test for a replay vulnerability

Are you or your partners vulnerable?  There is a very good chance that you are.  Many SAML service providers are implemented using free API libraries that do not protect against replay attacks.  Even the ones that do still fail to protect servers in a cluster (more on this below).

Unfortunately, standard vulnerability scanners to not test for this serious vulnerability.  The process of procuring an assertion and confirming if the system can be breached is hard to automate 100%

The basic process is to perform an SSO with a valid user; capture the assertion sent through the browser; log out the original user (to guard against false positives) and then replay the assertion to see if login is granted.   The test needs to be completed before the Assertion expires (typically between 5 minutes and an hour).

Tools that can assist here are:

SAML Tracer:  capturing assertions from the browser

PostMan:   Posting SAML Assertions to a service provider

SafeSAML™:  A SAML vulnerability testing suite with free replay tester.

How to protect against SAML Replay

Rule 1.  Setting an expiration date in the SAML assertion is not enough.

Rule 2.  See rule 1.

The SAML specification is very specific about how to prevent replay

https://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf

In section 4.1.4.5 it states “The service provider MUST ensure that bearer assertions are not replayed, by maintaining the set of used ID values for the length of time for which the assertion would be considered valid based on the NotOnOrAfter attribute in the ”.

This means that until the assertion expires, any implementation must remember the assertion (using its ID number) and not accept any other assertion with the same ID number.  Note that this is not optional but a hard requirement of the specification.

So it seems simple enough.  Maintain a cache of all assertion IDs that have been received and if a new assertion comes in that matches one of the IDs in the cache, reject it as a duplicate.  The IDs can be discarded from cache after the Assertion has expired (using the NotOnOrAfter value).

The main complexity here is that professional grade service providers are almost always clustered.  A per-server cache will only provide a 50% or less chance of protection.

For example:

In a distributed cluster, when the User logs in, the assertion may go to (and get cached on) Server1.  If the hacker steals the assertion and replays it, there is a 50% or greater chance the assertion will be replayed to Server2.  If the assertions are locally cached, this means Server2 would not see that the assertion is being re-used and let the hacker in.

To prevent this, make sure whatever caching mechanism that is tracking the used assertions is distributed across all the web servers in the cluster.

SAML replay protection is crucial to maintaining site security. Make sure your implementation follows the standards.

Learn More

SAML PEN Testing Suite

Click ‘Learn More’ button to explore AssureBridge IDM 360™ SAML PEN Testing suite.

Learn More