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.
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 AttackRequirements: 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).
Figure 1: ACS Spoofing Attack: Protocol Flow
- Step 1: The user visits the domain controlled by the
attacker, e.g. www.attacker.com
- 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.
- Step 3: The user is redirected to the IdP.
- Step 4: The user authenticates to the IdP. If the user is
already authenticated, this step is skipped.
- Step 5: The authentication token containing the identity of
the user is generated.
- Step 6: The authentication token will be sent to the domain
specified in ACSUrl, which is controlled by the attacker –
- Step 7: The attacker redeems the stolen authentication token
and authenticates on the SP as the user.
- Step 8: The attacker gets restricted resources controlled by the user.
Figure 2: ACSSpoofing Attack: Exploit Example
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
ACSUrlcan 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”.
- ACSScanner: We implemented a tool able to analyze IdPs
against ACSSpoofing. You can find the tool here:
- SAML EnDecoder: A very good and reliable tool to encode SAML
messages can be found here:
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.
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 PostVladislav Mladenov