On the Security of SAML-based Identity Providers

In previous posts we described Single Sign-On (SSO) and the messages within the authentication flow in detail. Additionally, we showed implementation pitfalls on the Service Provider (SP) side resulting in critical vulnerabilities.

In 2012 we started a study about the security of SAML based Identity Provider (IdP). The motivation to make this study was very simple – if the Identity Provider is vulnerable, all Service Providers are affected. In other words – even if the Service Provider is implemented correctly, an attacker can successfully get illegitimate access to restricted resources, e.g. victim's account.

Basics

At the beginning of the SSO protocol, the Service Provider redirects an unauthenticated user to the Identity Provider. With this redirect a Token Request is sent by the SP to the IdP (through the user agent, e.g. a web browser) in order to trigger the user authentication. The Token Request usually does not contain any sensitive information and thus is not encrypted or protected by a signature.

SAML Token Request

A Token Request usually contains the following parameters:

• ID: A nonce, which guarantees that the Token Request was freshly generated.
• IssueInstant: A timestamp.
• AssertionConsumerServiceURL (ACSUrl): A URL pointing to the SAML interface of the SP, to where the IdP sends the authentication token.
• Version: SAML Version.
• Issuer: The identity of the SP.

By analyzing this parameters and in conjunction with previous research work [Gross], we discovered how critical the parameter AssertionConsumerServiceURL could be.

ACSSpoofing Attack

Requirements: The attacker sets up his own domain (www.attacker.com) and controls the incoming and outgoing messages to this domain. Additionally, the attacker is able to lure the victim to visit his domain. This can be done by posting a malicious link in web forums or sending it via email.
Out-of-scope: The attacker does not control the communication between Client and Service Provider. Thus, he cannot eavesdrop or manipulate this communication (i.e. no man-in-the-middle attack necessary).

The ACS Spoofing Attack protocol flow:

Figure 1: ACS Spoofing Attack: Protocol Flow

1. Step 1: The user visits the domain controlled by the attacker, e.g. www.attacker.com
   
2. Step 2: The attacker generates a TokenRequest containing a malicious ACSUrl and redirects the user to the IdP. The ACSUrl is a URL e.g. www.attacker.com.
   
3. Step 3: The user is redirected to the IdP.
   
4. Step 4: The user authenticates to the IdP. If the user is already authenticated, this step is skipped.
   
5. Step 5: The authentication token containing the identity of the user is generated.
   
6. Step 6: The authentication token will be sent to the domain specified in ACSUrl, which is controlled by the attacker – www.attacker.com.
   
7. Step 7: The attacker redeems the stolen authentication token and authenticates on the SP as the user.
   
8. Step 8: The attacker gets restricted resources controlled by the user.

The exploit:

Figure 2: ACSSpoofing Attack: Exploit Example

Figure 2 shows an exploit of the ACSSpoofing attack. On the left side you can see the encoded Token Request. According to the standard the Token Request is deflated and base64-encoded. On the right side you see the Token Request in XML format before deflating and base64-encoding.
The ACSSpoofing attack will be executed if a normal user clicks on the link in the left window.



Specification vs. Implementation flaw:
ACS Spoofing is an implementation flaw on the IdP-side. The SAML specification[http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf, Page .49] clearly specifies that the IdP MUST verify the ACSUrl. The verification of the received ACSUrl can be done via the data exchanged during the “Trust establishment” phase, see http://web-in-security.blogspot.de/2014/10/single-sign-on.html#more, section “The SSO protocol flow”.
Tools

• ACSScanner: We implemented a tool able to analyze IdPs against ACSSpoofing. You can find the tool here: http://ssoattacks.org/acsscanner/
  
• SAML EnDecoder: A very good and reliable tool to encode SAML messages can be found here: http://www.john-james-andersen.com/blog/programming/great-saml-decodeencode-tool.html
  

Evaluation

We have selected six real-world SSO IdPs that are available as a Software-as-a-Service (SaaS), do not require installation, and configuration is done on the client’s side. The selected IdPs are widespread and are used by enterprises.

According to our evaluation 4 out of 6 (~67%) IdPs were vulnerable against ACSSpoofing, which is a surprisingly high percentage.

Acknowledgements

According to the responsible disclosure model, we promptly reported our findings: CVE-2012-4962, -4963,CVE-2013-0114,CVE-2012-4961,CVE-2013-0115, -0116, -0117. Additionally, we supported some of the security teams by fixing the found flaws. As a result, some of them acknowledged our work : https://www.onelogin.com/whitehat

Authors of this Post

Vladislav Mladenov
Andreas Mayer