Verification of SAML Tokens - Traps and Pitfalls

Verification of SAML Tokens - Traps and Pitfalls

This post will describe some findings in Single Sign-On area and problems related to the security of SAML-based authentication interfaces.

We will describe 6 attacks: Replay Attack, Token Recipient Confusion, Signature Exclusion, XML Signature Wrapping, Certificate Faking and Certificate Injection.

All 6 attacks are related to the SAML SSO interface and are high critical regarding the security.

Replay Attack (RA)

Every SSO protocol provides parameters to limit the reuse and lifetime of the authentication tokens. Taking into account that the reuse of tokens is optional, the validation of the attributes providing freshness is not considered as critical.
On the other hand, the time restriction regarding the usage of authentication tokens is more critical and should be evaluated. Otherwise, tokens issued once might be valid for an extended time period or even an infinite amount of time.

The attacker needs access to a valid token. More specifically, the token in question is required to have been valid for the targeted SP at any time in the past. This can be achieved if the attacker had legitimate access (for a limited period of time) to the SP via SSO and used this access to generate and store a token for himself. Alternatively, searching for published tokens in forums or in technical documentations could also provide valid, though most possibly outdated, tokens.

During our research we found that approximately 30% (6 of 22) of the analyzed SPs did not provide a proper check of the timestamps. By this means, the reuse of authentication for infinite amount of time was applicable.

Token Recipient Confusion (TRC)

In real-life SSO there exist multiple SPs federating with the same IdP. In order to distinguish the authentication tokens generated for different SPs, each token contains information about its recipient. In most cases this is the URL of the SP for which the token was generated.

The goal of Token Recipient Confusion (TRC) is to use an authentication token tA (generated for a service SA) on a second service Starget . The attack is considered successful, if Starget becomes "confused" by the recipient of the token and accepts tA as valid. As a prerequisite, the attacker needs access to a valid token. An additional requirement is that both services (SA and Starget ) have to be federating with the same IdP. This is a realistic assumption, since an IdP usually offers authentication services for multiple SPs.

There are two different approaches for a TRC exploit:

Exploit 1: Suppose that SP SA  (Developer Department) and Starget (Sales Department) are accepting tokens from the same IdP, and the attacker does not have access to Starget .
The attacker (e.g. a worker in the developer team) does, however, have a legitimate account on SA, thus he can request a token from the IdP for this service. By sending tA to Starget (instead of SA ), the attack is performed. It is considered successful if tA is accepted by Starget; the attacker is thus logged in with the same account name as he has for SA and gets access to Starget's corresponding resources.

Exploit 2: Alternatively, the attacker can set up his own SP (Sbad ) offering some service for registered users (e.g., a weather forecast). To authenticate to Sbad, SSO is used and the attacker specifically federates it with the same IdP used by Starget . After that, the attacker lures the victim (a legitimate user of Starget ) to register with and authenticate to Sbad. Instead of or in addition to its usual service (weather forecast), Sbad stores all tokens in a database so that the attacker can access them. The attacker can then try to use the tokens to log in on Starget as the victim. The attack is considered successful, if an authentication token tbad issued for the victim for service Sbad is successfully verified on Starget .
Considering the fact that the attack is known since 2008 [Armando et.al], we were surprised by the large number of vulnerable implementations (17 of 22, ор 77%).

Signature Exclusion (ǾSig)

SAML tokens are protected by a digital signature, which provides integrity and authenticity. By this means, every signature should be validated. Otherwise, every user could create his own token containing the identity of other users and thus gain access to other accounts.

Unfortunately, the validation procedure can be implemented incorrectly. The following toy example shows such faulty implementation:

1. public boolean verifyToken(SAMLToken token){

2.   foreach (Signature sig : token.getSignatures){

3.     if (verifySignature(sig) == false){ 

4.       return false; 

5.     }

6.   }

7.   return true;

8. }

The verifyToken-method extracts every signature within the token and verifies it. However, if no signature is provided, verifyToken will return true. In this case an attacker can remove all signatures within the token and afterwards change all values.

The goal of our research was to consider all applicable attacks on SAML we know. For this purpose we evaluated ØSig, too. However, we didn't expect to achieve any meaningful results since the attack is very simple and known by most developers. The fact that only one implementation (out of 22) was susceptible to ØSig confirmed our assumptions.

XML Signature Wrapping (XSW)

The idea of XSW is to exploit the separation between verification and application logic on the SP. In case both logics have different ”views” of the same document, XSW can be applicable.

For this attack to work, the attacker modifies the contents of the
token by injecting malicious data without invalidating the signature. One example for this is shown in the following figure.

For the given example, the verification logic will verify the signature based on the contents of the original Assertion, which is selected by ID=111222. The attacker manipulates his token by injecting malicious contents, for example, the identity of other users.

However, if the business logic automatically processes the first Assertion found within the token (ID=666), an attacker can effectively bypass the integrity protection and enforce the processing of unverified data on the SP.

Multiple possibilities to apply XSW exist and a detailed study regarding this attack type was already published by Somorovsky et.al [BreakingSAML, AmazonSignatureWrapping].

Surprisingly, two years after the large scale study of Somorovsky et.al., 50% (11 of 22) of the tested implementations were still susceptible to XSW. Considering the attack has been known since 2005 and a study was published in 2012, we didn't expected this large number of vulnerable implementations.

Certificate Faking (CF)

The cryptographic verification of the digital signature guarantees the integrity of the token. Additionally, it is essential to verify the token’s authenticity, too. In other words, the SP should check whether the token was signed by a trusted IdP. The CF attack utilizes possible flaws in the selection logic of the key used for the verification of tokens, by providing an attacker generated token signed by an attacker generated key.
In order to run the attack, the attacker must be able to create SAML tokens and sign them with his own self-created key.
 

Certificate Injection (CInj)

During the evaluation of the SPs we found a possible backdoor, allowing us to bypass even a secure SAML implementation. We found out that the configuration of the SAML interface is in most cases done via a relatively simple Web interface.

This Web interface is a security critical area and thus has to be well protected. During our research, we recognized that the security of the entire SSO module depends on the security of the applied Web interface and the stored information (which includes, e.g., the IdP certificate used for verification). This observation led to the Certificate Injection (CInj) attack. The basic idea of CInj is to inject a malicious certificate and store it on the SP. Since the SSO module uses this certificate for the token verification, tokens signed by the attacker, who possesses the private key to the injected certificate, will be successfully verified.

By this means, even a correctly implemented SSO module, which mitigates all attacks mentioned before, can still be bypassed. In order to apply CInj we used CSRF attacks to inject a malicious configuration regarding the SAML interface. In case that the target SP does not provide any CSRF protection, the attacker can enable and configure the SAML interface by injecting the malicious contents via a CSRF attack. As a result, he is able to remotely
establish a trust relationship between the target SP and a malicious certificate, which does not belong to any trusted IdP.
The attacker uses CSRF attack techniques in order to inject the
malicious contents, thus, he must be able to lure the victim to click
on a link or to visit a web page.

Approximately 30% (6 of 22) of the analyzed SPs were vulnerable against the CInj attack. Even worse, some of the SPs provided a good implementation of the SAML interface mitigating all of the attacks mentioned before, but still failing to protect against CInj. iThis attack is a very good example of how complex an authentication architecture can be and how a vulnerability of one interface, in this case the web interface, leads to vulnerabilities in other interfaces, e.g. the SAML interface.

Authors of this Post

Vladislav Mladenov
Christian Mainka (@CheariX)
Florian Feldmann