Direkt zum Hauptbereich

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.


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”.
  • 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
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 Post

Vladislav Mladenov
Andreas Mayer

Beliebte Posts aus diesem Blog

CORS misconfigurations on a large scale

Inspired by James Kettle's great OWASP AppSec Europe talk on CORS misconfigurations, we decided to fiddle around with CORS security issues a bit. We were curious how many websites out there are actually vulnerable because of dynamically generated or misconfigured CORS headers. The issue: CORS misconfiguration Cross-Origin Resource Sharing (CORS) is a technique to punch holes into the Same-Origin Policy (SOP) – on purpose. It enables web servers to explicitly allow cross-site access to a certain resource by returning an Access-Control-Allow-Origin (ACAO) header. Sometimes, the value is even dynamically generated based on user-input such as the Origin header send by the browser. If misconfigured, an unintended website can access the resource. Furthermore, if the Access-Control-Allow-Credentials (ACAC) server header is set, an attacker can potentially leak sensitive information from a logged in user – which is almost as bad as XSS on the actual website. Below is a list of CORS misc…

Printer Security

Printers belong arguably to the most common devices we use. They are available in every household, office, company, governmental, medical, or education institution.
From a security point of view, these machines are quite interesting since they are located in internal networks and have direct access to sensitive information like confidential reports, contracts or patient recipes.

TL;DR: In this blog post we give an overview of attack scenarios based on network printers, and show the possibilities of an attacker who has access to a vulnerable printer. We present our evaluation of 20 different printer models and show that each of these is vulnerable to multiple attacks. We release an open-source tool that supported our analysis: PRinter Exploitation Toolkit (PRET) https://github.com/RUB-NDS/PRET Full results are available in the master thesis of Jens Müller and our paper. Furthermore, we have set up a wiki (http://hacking-printers.net/) to share knowledge on printer (in)security.
The hi…