Vladislav Mladenov (Place of birth: Pleven/Bulgaria) [email protected]
30th June 2017
Ruhr-University Bochum Horst G¨ortz Institute for IT-Security Chair for Network and Data Security
Dissertation zur Erlangung des Grades eines Doktor-Ingenieurs der Fakult¨atf¨urElektrotechnik und Informationstechnik an der Ruhr-Universit¨atBochum
First Supervisor: Prof. Dr. rer. nat. J¨org Schwenk Second Supervisor: Prof. Dr.-Ing. Felix Freiling
www.nds.rub.de
Abstract
Single Sign-On (SSO) is a concept of delegated authentication, where an End- User authenticates only once at a central entity called Identity Provider (IdP) and afterwards logs in at multiple Service Providers (SPs) without reauthenti- cation. For this purpose, the IdP issues an authentication token, which is sent to the SP and must be verified. There exist different SSO protocols, which are implemented as open source libraries or integrated in commercial products. Google, Facebook, Microsoft and PayPal belong to the most popular SSO IdPs. This thesis provides a comprehensive security evaluation of the most popular and widely deployed SSO protocols: OpenID Connect, OpenID, and SAML. A starting point for this research is the development of a new concept called malicious IdP, where a maliciously acting IdP is used to attack SSO. Generic attack classes are developed and categorized according to the requirements, goals, and impact. These attack classes are adapted to different SSO proto- cols, which lead to the discovery of security critical vulnerabilities in Software- as-a-Service Cloud Providers, eCommerce products, web-based news portals, Content-Management systems, and open source implementations. The discov- ered flaws result in unauthorized access to End-User accounts, read access to locally stored sensitive files, as well as efficient Denial-of-Service (DoS) attacks. In this thesis, mechanisms strengthening the authentication in SSO will be described. Such mechanisms protect the authentication token during transport and mitigate its theft by relying on features of the established TLS channel between the participants, for example End-User and SP. The work described in this thesis influenced multiple SSO libraries and sys- tems on the web, which use SAML, OpenID and OpenID Connect for authenti- cation. The discovered vulnerabilities were reported to the responsible security teams, which we supported in fixing the issues. An important result of this the- sis is the change of the current OpenID Connect specification, which has been proposed as a countermeasure of the discovered attacks and adjusted in collab- oration with the OAuth and OpenID Connect working groups of the Internet Engineering Task Force (IETF).
3
Kurzfassung
Single Sign-On (SSO) ist ein Konzept mit dessen Hilfe sich ein Benutzer ein- malig an einer zentralen Instanz, dem Identity Provider (IdP), anmeldet und diese Authentifikation anschließend benutzt, um sich bei weiteren Dienstleis- tern (Service Providern, SPs) anzumelden. Zu diesem Zweck erstellt der IdP ein Authentifizierungstoken, welches dann vom SP ¨uberpr¨uft und f¨ur den Lo- gin genutzt wird. Es existieren unterschiedliche SSO Protokolle, die in open source Bibliotheken und kommerziellen Produkten implementiert sind. Zu den bekanntesten SSO Anbietern in Internet geh¨oren Google, Facebook, Microsoft und PayPal.
Die vorliegende Dissertation stellt eine umfassende Sicherheitsuntersuchung von verschiedenen SSO Protokollen und deren Implementierungen vor. Aus- gangsbasis f¨ur diese protokoll-¨ubergreifende Untersuchung ist die Entwicklung eines neuartigen Konzepts (malicious IdP, mIdP), das erstmals die Benutzung eines b¨osartigen IdPs f¨ur Angriffe einf¨uhrt. Der mIdP ist in der Lage, valide wie invalide Nachrichten und Authentifizierungtokens an verschiedene SPs zu senden. Darauf aufbauend werden generische Angriffsklassen entwickelt, die entsprechend ihrer Voraussetzungen und ihrer erreichten Ziele kategorisiert wer- den. Anschließend werden diese Angriffsklassen auf verschiedene SSO Pro- tokolle angewendet, was zur Entdeckung zahlreicher kritischen Schwachstellen in Software-as-a-Service Cloud Anbietern, eCommerce Produkten, web-basierten Nachrichtenportalen, Content-Management Systemen und open source Biblio- theken f¨uhrt. Die gefundenen Schwachstellen erm¨oglichen den unerlaubten Zu- gang zu fremden Accounts, das Auslesen von gesch¨utzten Ressourcen sowie das Aussetzen von Dienstanbietern mithilfe von Denial-of-Service Techniken. Um die Sicherheit von SSO Systemen zu verbessern und einen erh¨ohten Schutz gegen Angriffe zu erlangen, werden in dieser Dissertation Technologien beschrieben, die die Authentifizierungstoken w¨ahrend des Transports zus¨atzlich absichern und einen Diebstahl verhindern bzw. erkennen. Diese Technologien nutzen einen vorliegenden TLS Kanal und binden ihn kryptografisch an den Authentifizierungstoken.
Die Dissertation hat die Entwicklung vieler SSO Bibliotheken und Systeme, die SAML, OpenID oder OpenID Connect einsetzen, beeinflusst. Die gefun- denen Schwachstellen wurden mit den Entwicklern kommuniziert, die bei der Behebung unterst¨utzt wurden. Ein weiteres Ergebnis dieser Arbeit ist die Anderung¨ der OpenID Connect und OAuth Spezifikation, die aufgrund zweier neu aufgedeckter Angriffe angepasst werden musste. Eine entsprechende Gegen- maßnahme wurde in Zusammenarbeit mit der OpenID Connect und OAuth Arbeitsgruppe ver¨offentlicht.
A typical Internet user has many accounts and identities. For each identity, he is typically supposed to use a strong and unique password. The management of credentials for each system can be a challenging task or lead to the usage of short and weak passwords on multiple providers. Single Sign-On (SSO) was proposed to reduce the complexity of the authentication on different indepen- dent systems. SSO is a concept to delegate the authentication of an End-User on a Service Provider (SP) to a third party – the so-called Identity Provider (IdP). In SSO, the End-User authenticates only once at the IdP to log in at SPs. For this purpose, the IdP issues an authentication token containing statements regarding the End-User and sends this token to the SP. Once the SP receives an authentication token, it verifies this token and authenticates the End-User. Summarized, SSO facilitates the End-User authentication on multiple systems by reducing the number of the credentials managed by the End-User. There exist multiple SSO protocols – SAML, OpenID and OpenID Connect. With respect to the security, these protocols are a desired target for attacks, since vulnerabilities usually lead to compromising one or multiple End-User accounts. Even though the SSO protocols can significantly differ from each other, the concepts behind the attacks are often similar. This thesis provides a generic approach for systematizing known and novel attacks in generic classes and categorizing these according the impact and requirements. It investigates the trust establishment between the SP and the IdP in general and focuses on a new feature added to modern SSO protocols like OpenID and OpenID Connect called dynamic trust establishment. Based on our observations, a novel concept to analyze SSO by using a malicious IdP was developed, which was not considered so far and led to the discovery on novel attacks. We show the applicability of this concept during our evaluation by revealing security issues in implementations of every SSO protocol.
1.1 Thesis Outline and Contributions
This thesis contributes towards the security of different SSO protocols, to the detection and exploitation in numerous implementations, and addresses coun- termeasures strengthening the authentication.
Chapter 2 presents an overview of SSO and introduces the definition of three SSO phases: (1) Trust Establishment (2) End-User authentication at the IdP, and (3) End-User authentication at the SP. It presents the participants in SSO
11 and explains their roles and relations between each other.
Chapter 3 introduces a novel concept for analyzing SSO – malicious IdP. Initially, we reveal insights regarding the SSO ecosystem and systematically analyze the applicability of malicious IdPs in SSO. Furthermore, we compare our approach with existing ones and discuss the advantages and disadvantages of each approach. We conclude with a summary addressing existing challenges and future research problems.
Chapter 4 depicts the existing attackers, their capabilities within the SSO ecosystem as well as their goals. Furthermore, we present a classification re- garding the impact of an attack in three different categories: (1) Category A – one account is compromised, (2) Category B – all accounts are compromised without any interaction with the victim, and (3) Category C – the attacker can read files locally stored on the provider. Finally, we present our classification regarding the complexity of an attack by introducing Single-Phase Attacks and Cross-Phase Attacks. Single-Phase Attacks abuse one single step in the protocol. Usually, this is the validation of a specific parameter or the authentication token. Cross-Phase Attacks are more complex than Single-Phase Attacks since they abuse the binding between multiple parameters or messages in different phases of the protocol.
Chapter 5 gives an overview of the relevant security components, which are target of the attacks discussed in the following chapters. In addition, we in- troduce six different generic attack classes, describe these further and show on which SSO protocols the attack can be applied.
Chapter 6 handles with the OpenID Connect protocol. First, we describe the protocol and introduce the technical details needed to understand the attacks and countermeasures. Then, six different Single-Phase Attack and three Cross- Phase Attack classes are presented and further explained by providing the first in-depth security analysis of OpenID Connect. We are the first summarizing the existing threats and attack techniques. In addition, two of the introduced Cross-Phase Attacks break the current OpenID Connect specification affecting all implementations. Consequentially, a summary of our evaluation on exist- ing OpenID Connect implementations revealing critical security vulnerabilities breaking the End-User authentication is provided. We present our approach for automated analysis as an online webservice and discuss the design, imple- mentation details, advantages, and disadvantages.
Chapter 7 and 8 introduce the OpenID and the SAML protocol. We describe the protocols and provide technical details regarding relevant messages. Differ- ent Single-Phase Attack and Cross-Phase Attack classes will be introduced and described further. Afterwards, we present the provided evaluation and discuss the results. We conclude with a description of our approach for automated analysis of the according protocol.
12 Chapter 9 To enhance the security of SSO, we provide research on mecha- nisms strengthening the authentication token against theft by cryptographi- cally binding it to a specific and unique TLS channel. We propose two different approaches, TLS Unique (TLS Unique) and Holder-of-Key (HoK), and discuss their advantages and disadvantages.
1.2 Publications
In this section the author gives an overview of his contribution to numerous academic publications. The knowledge and results of these publications are related to this thesis. The publications are listed chronologically.
◮ “Options for integrating eID and SAML”, Proceedings of the 2013 ACM workshop on Digital identity management, 2013 [57]: In the paper, we investigate the security of the German national identity card, reveal an existing threat and propose a mitigation. The author’s contribution lies in the security analysis and the design of the proposed countermeasure.
◮ “On the Security of Holder-of-Key Single Sign-On”, IT-Sicherheit, 2014 [81]: This paper is a joint work with Andreas Mayer and J¨org Schwenk. The paper provides a security analysis of the SAML-based Holder-of-Key SSO profile and adapt a previously discovered attack on this profile. To fix the vulnerability an enhancement of the SAML profile is proposed and proof- of-concept implementation is provided. The contribution of the author, lies in the security analysis of the proposed countermeasure.
◮ “Strengthening Web Authentication through TLS – Beyond TLS Client Certificates”, Open Identity Summit, 2014 [80]: This is a joint work with J¨org Schwenk, Florian Feldmann, and Christopher Meyer. The paper describes a method to strengthen bearer tokens against Man-in-the- Middle attacks, by using the uniqueness of a TLS session and binding such tokens a specific TLS channel. In case of a theft, the token redemption is recognized and the illegitimate access prevented. The author’s contribution lies in the design and concept of the proposed approach to strengthen the web authentication.
◮ “Guardians of the Clouds: When Identity Providers Fail”, Proceed- ings of the 6th Edition of the ACM Workshop on Cloud Computing Security, 2014 [82]: This is a joint work with Andreas Mayer, Marcus Niemietz, and J¨org Schwenk. The paper provides a comprehensive analysis of the security of SAML IdPs and presents a novel attack technique (ACSSpoofing) break- ing the End-User authentication. The contribution of the author lies in the co-founding of the ACSSpoofing attack, evaluation of 50% of the IdPs and implementation of an online penetration testing tool – ACSScanner.
◮ “Your Software at My Service: Security Analysis of SaaS Single Sign-On Solutions in the Cloud”, Proceedings of the 6th Edition of the ACM Workshop on Cloud Computing Security, 2014 [75]: This is a joint
13 work with Christian Mainka, Florian Feldmann, Julian Krautwald and J¨org Schwenk. The paper presents a comprehensive evaluation of SAML-based SPs attacking different verification modules. The author’s contribution lies in the initial idea of the analysis and comprehensive research regarding the targets of the evaluation. Together with Christian Mainka and Florian Feldmann the author developed the systematization of all relevant attacks. The author evaluated 7 of the tested 22 tested SPs.
◮ “Automatic Recognition, Processing and Attacking of Single Sign- On Protocols with Burp Suite”, Proceedings of the 6th Edition of the ACM Workshop on Cloud Computing Security, 2014 [76]: This is a joint work with Christian Mainka, Tim G¨unther, and J¨org Schwenk. The paper presents EsPReSSO, the first tool for recognition of different SSO proto- cols based on the exchanged messages, which facilitates the security anal- ysis. EsPReSSO was designed together with Christian Mainka and imple- mented by Tim G¨unther within his bachelor thesis supervised by the author. The author contributed to the design of the protocol recognition module of EsPREeSSO.
◮ “Do not trust me: Using malicious IdPs for analyzing and at- tacking Single Sign-On”, 2016 IEEE European Symposium on Security and Privacy (EuroS&P), 2016 [78]: The paper provides the first in-depth analysis of OpenID on existing libraries and websites. By using a novel idea to use amalicious IdP for attacks the author, together with Christian Mainka, developed novel attacks, which were applied on 17 implementations and 70 websites. 70% of the libraries and 26% of the websites were vulner- able against at least one attack breaking the End-User authentication. The novel analyzing approach by using a malicious IdP, the development of the attacks and the evaluation is an equal contribution with Christian Mainka. The author evaluated all Java libraries and half of the tested websites.
◮ “SoK: XML parser vulnerabilities”, 10th USENIX Workshop on Of- fensive Technologies (WOOT 16), 2016 [112]: This is a joint work with Cristopher Sp¨ath, Christian Mainka and J¨org Schwenk. The paper provides a comprehensive research and systematization of knowledge regarding exist- ing XML-based attacks executed during the parsing process. A large-scale study is applied on 17 XML parsers by revealing 66% of them vulnerable in the default configuration. The evaluation was conducted within the master thesis of Cristopher Sp¨ath supervised by the author. The author’s contribu- tion, together with Christian Mainka, lies in the development of the attack classification.
◮ “SoK: Single Sign-On Security – An Evaluation of OpenID Con- nect”, 2017 IEEE European Symposium on Security and Privacy (EuroS&P), 2017 [85]: This is a joint work with Christian Mainka, Tobias Wich, and J¨org Schwenk. The paper provides an in-depth security analysis of the OpenID Connect protocol. Furthermore, novel attacks were discovered and classified in two categories: Single-Phase Attacks and Cross-Phase Attacks. The pa-
14 per describes two specification flaws breaking the security of the protocol. All attacks are discovered by the author and Christian Mainka. The contri- bution of the author lies in the evaluation of half of the implementations and design and concept of the automated tool Practical Offensive Evaluation of Single Sign-On Services (PrOfESSOS).
Other Publications The author published other academic papers beyond SSO security, which indirectly influenced this thesis. They are listed chronologically.
◮ “Penetration test tool for XML-based web services”, ESSoS Doctoral Symposium, 2013 [74]: This paper is a joint work with Christian Mainka, Juraj Somorovsky, and J¨org Schwenk. It gives an overview of WS-Attacker – a fully automated penetration testing tool for webservices, describes its functionality and addresses future challenges. The author contributed in the description of the WS-Attacker capabilities.
◮ “SECRET: On the Feasibility of a Secure, Efficient, and Collab- orative Real-Time Web Editor”, ACM Asia Conference on Computer and Communications Security (ASIACCS), 2017 [43]: This paper is a joint work with Dennis Felsch, Christian Mainka and J¨org Schwenk. The pa- per describes the first secure, efficient, and collaborative real-time editor – SECURE, enabling the collaborative work on encrypted documents. The author’s main contribution lies in the evaluation of SECRET ’s efficiency.
◮ “SoK: Printer Security”, 38th IEEE Symposium on Security and Pri- vacy (S&P 2017), 2017 [86]: This paper is a joint work with Jens M¨uller, Juraj Somorovsky and J¨org Schwenk. The paper describes multiple attack classes bypassing the security of network printers and resulting in Denial- of-service attacks, privilege escalation or credentials and document leakage. The author’s contribution lies in the supervision of Jens M¨uller’s master thesis. Together with Jens M¨uller and Juraj Somorovsky, the author con- tributes with a research and evaluation of systems beyond printers, which are susceptible against the introduced attacks.
15
2 Single Sign-On – Basics
In this section, we introduce the basics needed to understand the SSO attacks described in this thesis. For this purpose, in Section 2.1 we first introduce the participants and their role in SSO. In Section 2.2 we present the SSO authen- tication flow separated in three phases. Furthermore, we give technical details regarding the messages and highlight significant differences between the SSO protocols. We conclude with an abstract overview of an authentication token described further in Section 2.3.
2.1 Single Sign-On Roles
In Figure 2.1 we depict three different roles: Identity Provider (IdP), Service Provider (SP) and an End-User and describe the relation between them.
Figure 2.1: SSO participants and their roles: Service Provider (SP), End-User and Identity Provider (IdP).
Identity Provider (IdP). The IdP is an entity managing the identities of different users. It provides at least one authentication mechanism, e.g., user- name/password. It issues authentication tokens containing information about the authenticated End-User, which are sent to the according SP. End-User. The End-User is a human being navigating his user agent (UA), e.g., a web browser, on the Internet. He visits the SP and requests restricted resources requiring authentication. Service Provider (SP). The SP is a public available service offering access to resources for registered End-Users. The SP delegates the authentication for
17 End-Users starting a login attempt by forwarding this user to an IdP. After- wards, the SP consumes authentication tokens generated by an IdP and verifies them.
2.2 Single Sign-On in Three Phases
Every SSO protocol consists of three phases (cf. Figure 5.4): (1.) Phase 1: registration and trust establishment between Service Provider (SP) and Identity Provider (IdP), (2.) Phase 2: End-User authentication at the IdP, (3.) Phase 3: End-User authentication at the SP via the authentication token.
End-User UA Service Provider Identity Provider https://sp.com https://idp.com
Phase 1: Trust Establishment
Phase 2: Token Generation
Phase 3: Token Redemption
Figure 2.2: SSO in three phases: (1.) Trust Establishment, (2.) End-User authentication at the IdP, and (3.) End-User authentication at the SP.
2.2.1 Phase 1: Trust Establishment Initially, the trust establishment phase between SP and IdP is provided. In classical SSO systems, trust is established by an administrator manually regis- tering a specific IdP at the SP. A typical example is SAML: The administrator visits the IdP and downloads the IdP’s metadata, for instance its certificate. Next, he uploads it at the SP and configures further parameters like important URLs of the IdP. We call this full trust establishment, since only authorized people (the administrator) can invoke this manual trust establishment. Modern SSO systems offer a more flexible alternative to this approach: dy- namic registration that is executed automatically on the fly during an End- User’s login procedure. It is supported by protocols like OpenID, BrowserId, OAuth Authorization Framework 2.0 (OAuth) and OpenID Connect and basi- cally works as follows: (1.) The End-User starts a login process at the SP by submitting his identifier (e.g., his email[email protected]). (2.) The SP extracts the domain of it (the part after the @-sign) to identify the IdP. (3.) The SP can dynamically register at the IdP, for example, by sending a POST request to a specified URL at the IdP. We call this conditional trust establishment, since every End-User can invoke this dynamic trust establishment on a custom IdP. SSO systems based on a conditional trust establishment require additional verification steps by processing the authentication token. If these steps are not implemented correctly, attacks such as ID Spoofing (IDS) (see subsection 6.2.1) are applicable.
18 2.2.1.1 OpenID Connect In OpenID Connect the trust establishment can be done manually or dynami- cally via the Dynamic Registration [99].
Manual Trust Establishment. The administrator of the SP can first create an account at the IdP, e.g., a developer account on Facebook. Via the web interface at the IdP, the administrator of the SP, can apply for credentials (client id/client secret) by registering the SP and providing information like the URL of the SP and name displayed to the End-User. Once finished, the IdP generates unique credentials (client id/client secret), which the administrator manually configures at the SP.
Dynamic Trust Establishment. OpenID Connect provides a mechanism to dy- namically register an SP at the IdP and exchange (client id/client secret) [99]. The protocol flow is depicted in Figure 2.3. Service Provider Identity Provider https://sp.com https://idp.com regEndp Phase 1: SP Registration 1.1. Registration request: {redirect_uri, supported algorithms ...}
Figure 2.3: Dynamic Registration in OpenID Connect and establishing a shared secret used for the validation of the authentication token.
1. The SP initiates the registration by sending the registration request, which contains parameters like redirect uri, supported algorithms and sup- ported protocol features. Usually, all configurations, which can be made manually at the IdP, can be specified within the registration request. 2. The IdP responds in the next step by directly assigning a freshly generated client id/client secret to the SP and optionally a validity period. Now, the SP has all required information to proceed with the End-User authen- tication.
2.2.1.2 OpenID In OpenID the dynamic trust establishment is part of the core protocol. Thus, no manual configuration is needed nor possible. During the registration, the SP proceeds as follows (see Figure 2.4): 1. The SP generates an asymmetric key pair needed for the Diffie-Hellman key exchange: KSP , PKSP and sends the public key to the IdP. 2. The IdP generates its own asymmetric key pair (KIdP , PKIdP ), a sym- metric key KSP,IdP and a random string, called association, referencing
19 Service Provider Identity Provider https://sp.com https://idp.com regEndp Phase 1: SP Association
1.1. Association request: {PKSP}
1.2. Association response: {PKIdP, α, Enc(K)}
Figure 2.4: The trust establishment and key exchange in OpenID.
KIdP the symmetric key. Then, it computes the session key Ksession = PKSP , encrypts the symmetric key KSP,IdP , and sends the public key, the en- crypted symmetric key and the association to the SP. 3. The SP decrypts the symmetric key and uses it later for the signature verification.
2.2.1.3 SAML SAML does not provide any mechanisms to dynamically exchange key mate- rial and register the SPs. Usually the SP registration is done via manually exchanging SAML metadata containing information regarding supported flows, key material and endpoints [103].
2.2.2 Phase 2: Token Generation In the second phase, the End-User authenticates at the IdP and the authen- tication token or a reference to it is generated. The abstract protocol flow is depicted in Figure 2.5 and explained further. In the first step, the SP generates
Service Provider Identity Provider End-User UA https://sp.com https://idp.com
Figure 2.5: Abstract overview of the End-User authentication at the IdP within SSO. an AuthnReq and forwards the End-User to the IdP. This is usually a HTTP redirect to a pre-registered URL at the IdP. The AuthnReq contains informa- tion about the SP, URL pointing to the endpoint where the AuthnResponse is
20 sent, requested attributes and optionally a nonce as well as timestamps. The End-User then logs in at the IdP, which then generates an authentication token. The AuthnResponse is then submitted to the SP. In case that the authentica- tion token is sent within the AuthnResponse the SP verifies it and logs in the End-User. The exact message flow in dependence of the according SSO protocol is de- picted in chapter 6 for OpenID Connect and chapter 7 for OpenID and chapter 8 for SAML.
2.2.3 Phase 3: Token Redemption If the AuthnResponse contains a reference to the authentication token, the SP communicates with the IdP directly (in the back-channel) and redeems the reference. In exchange the SP receives the authentication token and verifies it.
Service Provider Identity Provider End-User UA https://sp.com https://idp.com
Figure 2.6: End-User authentication at the SP by verifying the authentication token.
The exact message flow in dependence of the according SSO protocol is de- picted in chapter 6 for OpenID Connect and chapter 7 for OpenID. In SAML Phase 3 is defined only for the Artifact Binding, which is not in the scope of this thesis.
2.3 Authentication Token
Independent of the concrete SSO protocol implementation, every authentication token contains information that can be categorized as follows: Class I: Identity. The authentication token contains information about a subject (e.g., an End-User) authenticating at the SP. In some protocols, this is an email address. Others like OpenID, OpenID Connect and BrowserId use unique URLs or usernames. It should be noted that multiple parameters (and not only one) represent the unique identity of the End-User. Class II: Freshness. The freshness of an authentication token guarantees that the authentication token is 1. freshly generated by the IdP, 2. redeemed only once at the SP, and 3. (optionally) additional restrictions regarding the lifetime of the token can be made. Parameters like timestamps and nonce values belong to this category. Such parameters restrict the validity period of the authentication token or enforce its one-time usage.
21 (1.) = issuer subject
(2.) = timestamp expired nonce
(3.) = audience (4.) = signature
Figure 2.7: Authentication tokens contain information regarding the: (1) Issuer of the authentication token and the authenticated End-User, (2) Freshness, (3) The attended recipient, and (4) Integrity protection.
Class III: Recipient. An authentication token contains information on the intended recipient, for example, the URL or a unique ID of the SP. Since there exist multiple SPs on the Internet, it is reasonable to restrict each authentication token to specific SP(s). Class IV: Signature. The authentication token (or a subset of it) can be signed. The signature value as well as parameters specifying meta information like key references or used algorithms belong to this category.
22 3 Malicious IdPs in SSO
In an Single Sign-On (SSO) protocol, there are three entities involved – End- Users, Service Providers (SPs), and Identity Providers (IdPs) (see Figure 3.1). For instance, End-User 1 can use the services of two different SPs by logging in with his account on Identity Provider 1. An example of such an IdP is Google.
Service Provider 1 Identity Provider 1 End-User 1 UA https://sp1.com https://idp1.com
Malicious Service Provider Malicious Identity Provider Attacker UA https://sp2.com https://idp2.com
Service Provider 3 Identity Provider 3 End-User 3 UA https://sp3.com https://idp3.com
Figure 3.1: In the SSO ecosystem, there exist multiple End-Users, SPs, and IdPs communicating with each other.
On the other side, End-User 3 can use the same SPs, but he uses a different IdP for authentication, e.g., Facebook. Each SPs can support the login with multiple IdPs, e.g., Google, Facebook, LinkedIn, and PayPal. Considering Figure 3.1, the question raises if the SSO ecosystem still works as intended if malicious entities such as End-Users, SPs, and IdPs are included. The short answer is Yes. In this thesis, we show that an attacker can act as a malicious End-User, SP or IdP. For some attacks, combinations of two malicious entities are needed. For example, to (1) steal an authentication token from a valid End-User by acting as a malicious SP and (2) redeem the authentication token by acting as a malicious End-User. To cover as much as possible attack scenarios on SPs regardless which ma- licious entity is needed, we searched for a generic analyzing approach. This approach should be able to simulate attacks executed by malicious End-Users, SPs, and IdPs. We discovered that by using a malicious IdP, we could achieve this goal.
3.1 Are IdPs Trusted Third Parties?
An IdP is usually considered trusted, since they provide authentication mech- anisms proving the identity of subjects and issue signed statements containing the proved identity. This role is comparable with the role of a Certificate
23 Authority (CA) issuing certificates. Considering large IdPs like Google and Facebook, the comparison with a CA seems reasonable, but it is not correct for most IdPs. For example, a CA can make statements regarding any other entity, and all customers assume this statement as valid. Thus, malicious or compromised CAs break the security of the entire system. SSO protocols are designed in a way that malicious IdPs can be detected. In SSO each IdP has a limited scope: An IdP can issue statements for users at this specific IdP. This limitation is shown in Figure 3.2. Companies may outsource their services to a specific SP, but they want to remain the control on the identity management. Therefore, each company pro- vides its own IdP (see Figure 3.2a) by logging employees of Company 1 at their accounts. Noteworthy is the fact, that the SP strictly separates the accounts of different companies with respect to the used IdP. Thus, a maliciously acting IdP of one company should not be able to issue statements regarding the ac- counts of another company. It can only compromise its own accounts, which is a trivial case.
IdP IdP IdP IdP IdP Malicious IdP Malicious IdP IdP Company 1 Company 2 Company 3 Company 1 Company 2 Company 3
Accounts Accounts Accounts Account Accounts Accounts Account Accounts Company 1 Company 2 Company 3 Attacker Company 1 Company 2 Attacker Company 3 Service Provider Service Provider (a) SPs enforce a strict separation be- (b) We show how a malicious IdP tween compartments. Therefore, a can bypass the existing restric- malicious IdP can only attack its tions and compromise compart- own compartment. ments controlled by other IdPs.
Figure 3.2: Malicious IdPs and their role in the SSO ecosystem.
At first glance, the concept of malicious IdP seems trivial: an IdP is consid- ered as a Trusted Third Party (TTP), allowing it to compromise the security of the entire SP. Nevertheless, in protocols such as OpenID, BrowserId, OAuth Authorization Framework 2.0 (OAuth) and OpenID Connect, the IdPs are con- ditionally trusted by strictly connecting each account to one specific IdP. In other words, the protocols themselves provide mechanisms detecting a mali- ciously acting malicious IdP. It depends on the SP if these mechanisms are implemented correctly. In our research, we discovered attacks violating the ac- count separation regarding the IdP (see Figure 3.2b). We could show that a malicious IdP can bypass the existing limitations and log in at accounts con- trolled by other IdPs. The setup and usage of a malicious IdP is possible since many SPs support as much as possible IdPs to cover more potential End-Users. For this reason, the SPs use modern protocols like OpenID and OpenID Connect, which introduce a novel ”open” concept of delegated authentication – the End-User can freely
24 choose his IdP and the identity of an End-User relies on a fully qualified URL like https://google.com/Alice or an email address like [email protected]. Because of this openness, it is possible for anyone to run an IdP and use it as a TTP at the SP. Nevertheless, such an IdP can act honestly or maliciously.
3.2 Malicious IdP– Advantages and Disadvantages
In this section, we will provide an analysis of the advantages and disadvantages by using a malicious IdP with respect to the applicability, control over the exchanged messages, and existing limitations.
Eval result (mIdP)
User- SSO Agent
SP
Figure 3.3: Malicious IdPs: The Eval module acts as a malicious IdP. Thus, it controls each message in each phase of the protocol.
The analysis and exploitation of SSO vulnerabilities relies in the HTTP mes- sages exchanged between the participating entities. For example, if the attacker acts as an End-User, he can see and manipulate only the messages passing his own user agent (UA). The communication between the SP and the IdP cannot be evaluated.
Advantages By using the concept of malicious IdPs more messages can be analyzed since the used IdP takes part in every phase and step of the protocol, controls the content of every message, and can provide tests with valid or in- valid tokens. Note that the malicious IdP does not control the communication between the browser and the SP, but since it controls the messages that are forwarded to the SP (e.g., by using HTTP redirects), he can even manipulate these messages. Thus, this approach gives the full flexibility to analyze an SSO protocol implementation.
Disadvantages An important limitation is that a malicious IdP must imple- ment each SSO protocol that it wants to analyse. For this reason, this thesis uses one malicious IdP implementation for OpenID, one for OpenID Connect, one for SAML. This is an acceptable downside, since even the attacks them- selves must be adapted to the specific protocol.
Applicability There exist multiple SSO libraries providing IdP functionality. Thus, every attacker can download, install and configure such a library and deploy his own IdP – a custom IdP. A malicious IdP is a custom IdP acting maliciously by creating invalid or malicious tokens or exchanging the order of
25 sent messages [44, 78]. There are two ways enforcing an SP to use the malicious IdP. Manual configuration of the SP. First, an SP establishes a trust relationship with the IdP. For this purpose, key material and important URLs (e.g., the URL of the IdP and the callback URL of the SP) are exchanged manually. As a result, the SP can verify the signature contained in the received authentication tokens. Dynamic configuration. In OpenID Connect, the features Discovery [100] and Dynamic Registration [99] can be used to establish on the fly a trust relationship between an SP and the custom IdP (conditional trust establishment). A user can enforce the usage of the malicious IdP by entering its URL at the SP. The SP discovers all necessary information about the IdP, such as supported cryp- tographic algorithms, important URLs and exchanges the key material. Similar approach is described for other SSO protocols like SAML [15], OpenID [113], and OAuth [58].
3.3 Additional Approaches
By systematically studying previous work on SSO analysis, we identify six dif- ferent categories: manual testing, formal analysis, static code analysis, dynamic code analysis, message invariants, and malicious IdPs.
Manual Testing Even though manual testing is often considered as out-of- scope in research papers and even not described directly, it is an important part during every security evaluation. Manual testing offers great flexibility, which is needed at least at the beginning. Most research ideas start by manual testing, so does this thesis: we first applied our attacks manually on multiple libraries to prove our ideas and methodology. Since manual testing does not scale for a larger number of targets, it is considered insufficient with respect to re-tests for each new version of an implementation or large-scale evaluations. Nevertheless, this approach has already been applied to SSO protocols. For example, in 2012, Somorovsky et. al [111] manually evaluated numerous SAML libraries, but a further manual analysis in 2014 showed that the investigated attack is still applicable [75]. This means two things: 1. Manual testing is a valid technique to initially identify serious security issues and prove whether new concepts deliver the expected results. 2. Manual testing does not help to bring implementations closer to specifications at a sufficient level.
IdP
model SSO User- Eval result Agent
SP
Figure 3.4: Formal Analysis.
26 Formal Analysis This approach provides a security evaluation based on a for- mal protocol description, see Figure 3.4. The main goal of such analysis is to find generic vulnerabilities. An important limitation however is that implemen- tation flaws and specific vulnerabilities are not covered, since the Evaluation module (Eval) is not able to analyze real network traffic and to see, how an implementation reacts to manipulated messages. This approach does not answer research question Q3 (and even Q2), because specifications precisely address several attacks. For example, the OpenID Con- nect specification clearly states how to prevent Replay attacks, but our obser- vation via manual testing was that implementations are not aware of this. The real advantage of formal analysis relies in finding generic issues in specifications like in SAML [5], BrowserId [44], and OAuth [45]. Thus, in a perfect world, this step should be included during the creation of a specification to proof its correctness, which was also stated by Guangdong [53].
Static Code Analysis During a static code analysis, the Eval module has full access to the code of the targeted system. Figure 3.5a illustrates this approach. Analyzing the program code is a reliable approach to track down implemen- tation flaws, for example, in the verification logic. However, static code analysis is hardly used for SSO protocols. We see two reasons for this: 1. such analysis requires full (or at least partial) access to the code of the running implementa- tion (see dashed lines). This is possible for a library evaluation (especially for open-source libraries), but it is not applicable to online websites (e.g., Amazon). 2. The biggest downside of static code analysis is that it must be applied for every programming language and in addition, for every SSO protocol.
Dynamic Code Analysis Guangdong [53] showed a more convenient approach combining program code analysis with formal analysis (cf. Figure 3.5). In this case, the Eval module expects HTTP traces plus initial knowledge, for example, the credentials of at least two different users. The Eval module then creates formal model based on this information, generates test cases, and simulates the SSO authentication. The output of the tests can then be further inspected to identify vulnerabilities. Although dynamic code analysis is very flexible, it has significant downsides:
27 Prot. Lang. Accessible communication Vulnerabilities Automated analysis indep. indep. SP↔B B↔IdP IdP↔SP Generic Impl. possible? Manual No Yes Yes Yes Yes Yes Yes Yes Formal No No No No Yes Yes Yes Yes Static Code No No No No No Yes Yes Yes Dynamic Code No No Yes Yes Yes Yes Yes Yes Message No Invariant Yes Yes Yes Yes Yes Yes Yes Malicious IdP No Yes Yes Yes Yes Yes Yes Yes
Table 3.1: Comparison of existing approaches to analyze SSO protocols.
(1.) Signed messages are considered as unmodifiable and thus not evaluated1. This is an enormous limitation regarding conditionally trusted SSO protocols since attacks like ID Spoofing (IDS) are not considered. (2.) The direct com- munication between IdP and SP cannot be evaluated. By this means, our Cross-Phase Attacks cannot be evaluated.
IdP
Eval SSO
User-Agent result
HTTP, SP JS Code Figure 3.6: Message invariants.
Message Invariants The message invariants approach [128, 133] is depicted in Figure 3.6. The Eval module again expects HTTP traces and analyzes the traffic to define messages and parameters that are modifiable. Instead of creating a large subset of tests by executing all possibilities, it examines relations between different parameters. Such relations can be used to influence parameters in one message, which automatically reflects in another one. In this manner points of attacks can be identified and evaluated. The limitations of this approach are identical with the previous one.
3.4 Lessons Learned
We summarized the different approaches to analyze SSO considering their ad- vantages and disadvantages in Table 3.1. Since we need a scalable solution that can be applied to numerous imple- mentations, we need an approach that can evaluate an implementation auto-
1Note that fuzzing techniques can manipulate signed values, but not in a meaningful way. Thus, they are not considered further.
28 matically. Therefore, the manual approach is omitted. A formal approach unfortunately does not help to find implementation issues, so we cannot apply it, too. Static and dynamic code analyses have the disadvantage that they de- pend on the used programming language. Thus, this approach is difficult to apply, since we must implement this approach in dependence of each language. In addition, the attack surface is limited by the inaccessible communication between the SP and IdP. Thus, this approach cannot bring an implementation closer to a specification. The message invariant approach seems to be promis- ing, but it has the huge disadvantage that the communication between the SP and the IdP is not part of the evaluation. In addition, not all messages sent through the browser can be manipulated. To the best of our knowledge, the malicious IdP approach is the best way to analyze implementation flaws in SSO since it offers great flexibility, and full control over all phases and messages. Furthermore, it and can be used as a basis for an automated analysis.
29
4 Attacker Goals and Capabilities
In this chapter, we describe the main goals of the attacker in Section 4.1 and his capabilities in Section 4.2, which we assign later to each of the described attacks. In addition, we introduce in Section 4.3 three different categories measuring the impact of each attack. We use this classification to assign all introduced attacks in this thesis to a specific Attacker Type (AT) and impact.
4.1 Attacker Goals
We assume that the victim has an account at an honest Identity Provider (IdP) and at an honest Service Provider (SP) and that the victim uses Single Sign-On (SSO) to authenticate at the SP. The victim’s identity, for example his email address, is considered public and thus known by the attacker. The goal of the attacker is to access a protected account to which he has no entitlement, e.g., the account of the victim. Another goal of the attacker is to get access to system files stored on the server, e.g., /etc/passwd. We assume that the attacker does not have access to these files and is not able to read them. In addition, the attacker try to enforce the target server to initiate connections to arbitrary URLs. The goal is to increase the computational resources of the server leading to Denial-of-Service (DoS) or gather more information of the internal network and thus get access to non-public information.
4.2 Attacker Capabilities
For the security analysis explained in the next chapters, we distinguish four different Attacker Types (ATs) as shown in Figure 4.1. Each attacker type specifies on a detailed level the different attacker capabilities. The attacker types AT1, AT2, and AT3 are related to the web attacker model [1]: • The attacker can deploy his own web service on a domain, e.g., http: //attacker.com, which is fully under his control. The web service can respond to HTTP requests with arbitrary content. The attacker can ob- tain TLS certificates for this domain making his web service available via HTTPS. • The attacker only controls the HTTP requests send to his web service. He does not have any special network privileges. In addition, the attacker can send HTTP requests to honest servers generated by his web service. These requests can contain arbitrary content.
31 • The attacker can lure the victim to visit his web service. Since the HTTP response will be processed by the user’s browser, the attacker is able to call browser’s APIs, for example, opening a new window and loading a web page. Thus, the attacker can generate and send cross-origin HTTP requests. In an SSO environment, the web attacker can play different roles. He can act as a malicious End-User by starting the SSO authentication like any other End-User, but manipulating the messages sent through his user agent (UA). The attacker can set up a malicious IdP running on a controlled domain and generating valid as well as malformed tokens. Moreover, the attacker can act as a malicious SP collecting authentication tokens from honest End-Users and issued for this SP. In this thesis, we do not use a malicious SP to carry out attacks. In general, we do not assume that the attacker knows any secrets (passwords, secret keys etc.) other than those established by himself. Thus, we exclude any kind of phishing attacks luring the victim to enter his credentials on a malicious website. Target Target End-User End-User Provider Provider Attacker Attacker Token
Figure 4.1: Overview of the attacker types: AT1, AT2, AT3, and AT4.
AT1 – Message Generation For the first type of attacks, we assume that the attacker can generate valid messages with the expected format. These messages can be of any publicly available format (plain XML, SAML, XSLT, DTD, or JSON) and can contain any data that is publicly available or chosen arbitrarily by the attacker. This attacker type requires less resources than the classic web attacker since it does not require a web service and interaction with the victim. Thus, the attacks assigned to this attacker type are more powerful. Note 1: No secret information, such as secret keys or passwords known either to the SP, the IdP, and the victim must be used to generate these messages. For example, AT1 includes the capability to create arbitrary tokens, but no corresponding valid signatures σ = SIGIdP (t) (as the attacker does not have
32 access to the secret key of IdP). AT1+: An exception to Note 1 occurs for tokens generated by an attacker who uses his own key material, for example by using its own malicious IdP. The secret key used to generate the digital signature σ was chosen by the attacker, thus, he can create tokens with arbitrary content and then correctly sign them with a corresponding signature σ. In this case, the attacker uses his web service (the malicious IdP), but he does not need any victim interaction.
AT2 – Access to Valid Token In AT2, we assume the attacker having access to a valid token of the victim, which is issued by an honest IdP and contains the corresponding valid signature σ = SIGIdP (t). Multiple possibilities to obtain such a token exist: For example, they can be stolen via XSS [134], or they can simply be found in public support forums by using an online search engine like Google. Please note that token theft via Man-in-the-Middle (MitM) attacks or eavesdropping on the communication channel between the Client and SP is not part of AT2. A special case of AT2 occurs, when the attacker himself is a valid user of the system. He can then use his credentials on his IdP to let it issue tokens for his own account on demand (but not for the victim account). Note: In general, an attacker will not be able to choose the contents of such a token arbitrarily – even as a regular user he will be restricted to his given identity and the according permissions. Thus, the main goal of attacks related to AT2 is to expand the rights provided by the given token.
AT3 – Classic Web Attacker For attacker type AT3, we assume that the attacker can influence the victim to click on an attacker provided link. This includes both, a technical method to provide an attacker generated link to the user (e.g., by e-mail or through user forums), and the technical and/or social means to convince the user to activate (i.e. click on) the link. AT3 further assumes that the victim is logged in to his account on the tar- geted SP at the time of clicking on the malicious link (i.e., the victim has an active authenticated session with the SP or the IdP. Note: The attacker can enforce a victim to start the authentication on an SP with the malicious IdP (even if the victim does not have an account at the malicious IdP). This special case we use for our attacks on OpenID Connect called IdP Confusion and Malicious Endpoints.
AT4 – Man-in-the-Middle For this attacker type, it is assumed the attacker has all abilities of the web attacker and in addition he controls the network com- munication. The attacker can read, control, and block contents of unencrypted network traffic [1]. It is assumed that the attacker cannot manipulate HTTPS traffic between honest participants since he does not have valid certificate for honest domains and the participants detect untrusted/self-signed certificates. This AT4 is not relevant for the attacks introduced in this thesis and will be not considered further.
33 4.3 Impact
In this section, we categorize the impact, which can be achieved by successfully executing an attack, in three different categories.
Category A (Cat A) Attacks belonging to this category involve a certain kind of victim interaction. For example, the victim clicks on a link or he has to post his (expired) token somewhere on the web (e.g., in a support forum). If the attack is successful, the attacker impersonates only one End-User.
Category B (Cat B) This category is stealthy and hard to detect because it does not require any interaction from the victim. This means that the at- tacker can log in with an arbitrary identity, for example, using an @google.com identity at the SP simply by using his malicious IdP. Cat B attacks are more powerful than Cat A since no user interaction is necessary.
Category C (Cat C) Attacks assigned to this category introduce an unpriv- ileged read access on system files stored on the server. In comparison to the previous categories, the scope is not End-User accounts by files containing sen- sitive information like stored private keys or server configuration files. Usually, such attacks can be used for efficient DoS attacks too.
34 5 Generic Single Sign-On Attack Concepts
In this chapter, we first give an abstract overview of the relevant components used on a provider (Identity Provider and Service Provider) within the Sin- gle Sign-On (SSO) authentication, in Section 5.1. In Section 5.2, we introduce generic attack concepts applied to at least one of the provider components. Fur- thermore, we show which SSO protocols are targeted by these attacks. Finally, we define two new attack categories – Single-Phase Attacks and Cross-Phase Attacks in Section 5.3. Based on this separation we can find the causes behind more complex attacks and explain their complex nature. The differentiation between these attack categories also helps to highlight the relation of different messages exchanged in different phases.
5.1 Architecture of a SSO Provider
Figure 5.1 shows a generic block diagram of the different security related com- ponents of a provider (an Service Provider (SP) or an Identity Provider (IdP)). The End-User communicates with a provider by using his user agent (UA), for example a web browser. The communication takes place via the HTTP Protocol.
Username/Password Target Provider
Web Authorization & Session Management Ressources End-User UA Frontend Access Management
Single Sign-On Parser Verificator Processor User Database
Figure 5.1: Overview of the different modules related to the authentication pro- cess on the target provider.
Web Frontend On the server side of this communication, the provider uses a Web Frontend, for example, a web server listening on a specific port and forwarding the traffic to the according handlers (PHP, Java, etc.). The Web Frontend implements RFC 6265 [11] in order to make HTTP stateful and to allow the deployment of different web applications. Username/Password The Username/Password module manages the corre- sponding authentication and the password-recovery mechanism. For example,
35 it compares the Username/Password combination sent to the Web Frontend with the information stored in the User Database. Session Management (SM) The SM module resolves the received session cookies by the Web Frontend to a user identity and forwards this information to the Authorization & Access Management (AAM). Single Sign-On Module The Single Sign-On module carries out the veri- fication of the received authentication tokens (see . Section 2.3). After a suc- cessful token verification, it forwards the information about the authenticated user to the AAM. During the verification, the SSO module fetches the config- ured IdP certificate from the User Database and uses it to verify the provided digital signature within the authentication token. The SSO module contains three internal modules: • The Parser is a module that converts an input string into data objects, which can then be further processed by the following components. The structure of the parsed messages can differ according to the Identity Man- agement (IdM) protocol. For example, this could be a JSON or an XML parser. For our analysis, the SAML case is most important, in which an XML parser is applied. • The Verificator provides the verification of the authentication token. This module is responsible for the validation of all security relevant pa- rameters within the authentication token. • The Processor extracts the information regarding the authenticated End-User from the authentication token and forwards it to the business logic. This information is usually his name, which is then looked up in the AAM to get the according access rights. At the end of the processing, the authentication token will be deleted, since it is not needed anymore. Authorization & Access Management (AAM) The AAM component controls the access to the restricted resources. Previous components (User- name/Password, Session Management, and Single Sign-On) provide informa- tion regarding the authenticated End-User to it. Consequentially, the AAM fetches information from the User Database and enables or restricts access to the resources. User Database The User Database stores information about users and their credentials, for example Username/Password combinations with their corre- sponding access rights. Additionally, it stores the SSO configuration data like the endpoint and certificate of the federated IdP or registered SPs. Resources. The Resources include the entirety of data accessible to regis- tered users or stored files.
Initial Authentication The Initial Authentication is started when the End- User does not have a valid authenticated session with the provider. He cannot provide a corresponding session cookie and therefore must authenticate first. In this case, the End-User can choose to authenticate via Username/Password or to initiate SSO. Initial Authentication by using Username/Password: During the Username/- Password authentication, the module verifies the correctness of the End-User
36 supplied credentials. The Username/Password module fetches the data stored within the User Database and uses it for verification. If the authentication is successful, the information about the user is forwarded to the AAM and a session cookie is set. Initial Authentication by using SSO: 1. The SSO procedure at the SP side consists of two phases. The redirection of the End-User to the IdP and the verification of the received authentica- tion token. Initially, the SSO module at the SP fetches information about the federated IdP from the User Database. It then generates the Auth- nReq and redirects the End-User to a specified IdP. In the subsequent phase (after the End-User provides the authentication token), the SSO module verifies the received authentication token. For the verification of the digital signature, it loads the IdP’s certificate from the User Database. In case of successful token verification, the SSO module extracts informa- tion about the End-User’s identity from the token and forwards it to the AAM. Finally, a session cookie is set by the Web Frontend. 2. The SSO procedure at the IdP side consists of two phases. The received AuthnReq must be parsed. Thus, the IdP must determine the according SP by processing the AuthnReq. This step is needed since, the URLs of the SP to which the AuthnResponse is sent, must be validated. Then, the End-User authentication takes place, for example by using the User- name/Password module. If successful, a session cookie is set by the Web Frontend and the authentication is made persistent. Finally, the corre- sponding key material for signing or/and encrypting the AuthnResponse is loaded and the authentication token is issued by the IdP.
Repeated Authentication Whenever an HTTP Request arrives at the provider, the Web Frontend module checks if a corresponding session cookie is provided indicating that the End-User has already been authenticated. Repeated Authentication indicates that the End-User has already been au- thenticated. In this case, the received session cookie is forwarded to the Session Management module that resolves the identity of the End-User by using the value of the session cookie. Consequentially, the identity of the End-User is forwarded to the AAM.
5.2 Generic Attacks
In this section, we describe generic attack concepts independent of the SSO protocol. We focus on the idea of the attack rather than the exact execution. The details as well as exploit examples will be shown later in chapter 6, chapter 7 and chapter 8.
5.2.1 Identity Attack (IA) Identity Attacks target the verification of the End-User’s identity at the SP. In this thesis, this class of attacks targets the protocols SAML, OpenID, and
Table 5.1: Overview of generic attacks on SSO protocols.
OpenID Connect where the SP conditionally trusts the statements made by the IdP. In other words, the SP must provide additional checks to verify that the IdP is allowed to make the statements within the authentication token. If this verification is not provided, a maliciously acting IdP can make statements in the name of other IdPs like Google, which will be accepted by the SP.
5.2.2 Replay Attack (RA)
Replay attacks target the multiple redemption of a SSO token regardless of the existing freshness and lifetime restrictions. Therefore, an attacker in possession of a stolen token, for example by eavesdropping the communication between the End-User and the SP, can redeem it at the SP and gain access to the End-User’s resources. Another possibility for an attack is given, if a malicious End-User, having access to an SP for a limited time, can store the used token and redeem it for an infinite amount of time at the SP. In SSO protocols, the tokens contain at least one parameter guaranteeing freshness and one defining the expiration time. It is up to the SP to implement this verification correctly. A special case of Replay Attacks exists in SAML, where the AuthnReq can contain parameters restricting the lifetime and guaranteeing freshness. Thus, the IdP should verify the relevant parameters.
5.2.3 Wrong Recipient (WR)
With respect to the existence of multiple SPs, an authentication token must indicate the SP it is intended for. It should be guaranteed that (1) the token can be successfully verified by a single SP only and (2) that the token is delivered to the correct SP. In other words, a token redeemed at one SP cannot be redeemed at another SP. Thus, malicious SPs capturing valid tokens from different End- Users cannot use these on other SPs. Wrong Recipient attack targets only SPs. In SSO protocols, the tokens con- tain at least one parameter defining the recipient. It is up to the SP to imple- ment this verification correctly.
38 5.2.4 Signature Bypass (SB) In a typical SSO protocol flow, the token is digitally signed by the IdP and verified by the SP. The verification is a complex process requiring multiple steps: • The signed parts must be determined. The SP must be able to distinguish signed from unsigned parts within the token. Additionally, it should check if all required security relevant parameters are protected by the signature. • For the verification, the correct keys must be chosen. Thus, the SP must use the key material associated with the IdP that issued the token. • The key material must be protected against manipulations, e.g., overwrit- ing with another key material. • The usage of insecure cryptographic algorithms must be avoided. If one of the mentioned verification steps is violated, the token can be ma- nipulated and the statements made by the IdP can be modified. As a result, the attacker can log in at any account at the IdP. It depends on the SP to implement the verification correctly. In SAML, an additional case exists, where the AuthnReq can be signed. Thus, the IdP can be a target for this type of attacks, as well.
5.2.5 Covert Redirect (CR) Covert Redirect attacks target the IdP by enforcing it to send the token to a domain controlled by the attacker instead to a legitimate SP [127]. In SSO, the IdP registers multiple SPs and stores information regarding the identity of the SP, URLs used for the token transmission as well as crypto- graphic key material. A task of the IdP is to check the information in each AuthnReq, to determine the SP, and to validate the URL to which the token will be sent. If this verification is not implemented correctly, the attacker can steal tokens from other End-Users and redeem these at the SP. The attack is applicable to OpenID Connect and SAML since the SP registers the URL at the IdP, which must be verified later. In OpenID, the SP does not register its URL at the IdP. Thus, the IdP cannot verify this parameter. For this reason, this class of attacks cannot be applied on OpenID.
5.2.6 Message Serialization (MS) In dependence of the SSO protocol, each message has to be serialized/parsed. Serialization means that the incoming message has to be first extracted from the incoming HTTP request and then converted in a programming object, e.g., an XML node or a JSON object. For the serialization, a parser is used (see Figure 5.1). Any abnormal behavior during this parsing directly affects SSO se- curity: for instance, if some data element is present twice with different content, the second content may overwrite the first during the parsing, or vice versa. In addition, the parser’s features are very powerful and if not hardened can be used for attacks. These features can be used to break out of the normal SSO
39 Username/Password Target Provider
Web Authorization & Session Management Ressources End-User UA Frontend Access Management
Single Sign-On Parser Verificator Processor User Database XXE Attack XSLT Attack
Figure 5.2: The attacker sends an XML document containing malicious code, which points to a file stored on the local filesystem. As a result, the attacker breaks out of the usual processing schema, bypasses the security verification provided by the SSO-Verificator plus the AAM, and reads locally stored files.
validation process, access locally stored files on the provider, and send these to arbitrary domains, see Figure 5.2. In SAML and OpenID, an eXtended Markup Language (XML) parser is used to serialize messages exchanged between the participants. Thus, MS attacks can be applied. In contrast, OpenID Connect is entirely based on JSON. Currently, no parsing attacks are known against JSON parser. XML offers the possibility to describe the document’s structure by using a Document Type Definition (DTD). Unfortunately, the usage of these features can lead to security vulnerabilities enabling very efficient Denial-of-Service at- tacks [42] or allowing unauthorized access to files stored at the target SP, for example, /etc/passwd or key files.
5.2.6.1 Denial-of-Service (DoS) attacks In this section, we describe how XML External Entity Attacks (XXEAs) can be used to start efficient DoS attacks. The first example is depicted in Listing 5.1 and introduces the possibility for an attacker to allocate a large amount of the free memory on the server by sending a small XML document.
1 3 4 5 6 ]> 7 &a2;
Listing 5.1: An XML-Bomb based on the Billion Laughs Attack [117].
In the given example, the document contains three Entities: a0 is mapped to the string dos, a1 contains multiple references to the XML Entity a0, and a2 containing multiple references to the XML Entity a1. Within the element , the XML Entity a2 is called and resolved during the message pars- ing/serialization. The result is that the string &a2; will be replaced by the string "dos" repeated 25 times1. An attacker, starting DoS via XXEA can
1a2 = 5*a1 = 5*(5*a0)=25*"dos".
40 define more Entities referencing to each other recursively and allocating more memory than in the shown example. The second example is shown in Listing 5.2 and defines two Entities refer- encing to each other and building an infinite loop. By sending this small XML document to a server, an infinite loop can be enforced allocating CPU resources for long/infinite time.
1 3 4 ]> 5 &a;
Listing 5.2: Infinite loop by two entities referencing to each other.
5.2.6.2 File Access XXEAs can be used to access local files on the server. This can be achieved by using the front channel or the back channel (if ). In the front-channel case, the processed XML document is sent back to the sender, while in the back-channel case the server does not send the processed XML file.
File Access through the Front Channel The XML document presented in Listing 5.3 shows how this can be done.
1 2 4 ]> 5 6 &file; 7
Listing 5.3: File Access by using XML Entities.
The XML document defines one XML Entity (file) referencing a local file, e.g., /etc/passwd. The XML Entity is then called in row 6. While the document is parsed, the referenced file is read by the XML Parser and printed within the element . If the resulted XML document is sent back to the sender, sensitive information leaks. Unfortunately, the attack vector described in Listing 5.3 is limited by the fact that the referenced document must be XML conform. Thus, it must not contain special characters like <,> as well as non-closed XML elements. To solve this problem, the content of the file can be encapsulated in a CDATA container, which is less restrictive regarding the allowed characters and text. An example is shown in Listing 5.4 and Listing 5.5. First, the attacker sends the XML message depicted in Listing 5.4. The document contains four parameter Entities: start, file, end and dtd. The usage of parameter Entities is needed since these are less restrictive regarding the declared content. The start XML Entity, cf. row 4, defines a string, which opens a CDATA-block when it is processed. The file XML Entity, cf. row 5, defines a reference to a file. The end XML Entity, cf. row 6, defines a string
41 1 2 4 5 6 "> 7 8 %dtd; 9 ]> 10 &all;
Listing 5.4: The XML document sent by the attacker to the server containing parameter Entities, which will be concatenated.
closing the CDATA-block when it is processed. The dtd XML Entity, cf. row 7, defines a URL handler on the URL http://attacker.com/parameterEntity. dtd. In row 8 the dtd XML Entity is called and the file stored on the given URL is downloaded.
1
Listing 5.5: The file stored on http://attacker.com/parameterEntity.dtd The downloaded file defines a new XML Entity all concatenating the Entities start, file, and end. The construct defined in Listing 5.5 must be declared in a separate file since its declaration is not allowed in Listing 5.4. Considering row 10 in Listing 5.4, the XML Entity all is called. As a result, a CDATA-block is opened, the content of a file is printed, and the CDATA-block is closed.
File Access through the Back Channel In case of SAML the server usually responds with an error message and does not send the parsed XML message back to the sender. Thus, the attacker needs another channel to retrieve the information gathered during the messages processing. Similar to the previous attack vector, the attacker can use parameter Entities to read a file, append the content to a string, and call a URL. The attacker first creates an XML document and sends it to the server, see Listing 5.6.
1 2 3 &send;
Listing 5.6: Enforcing the server to send a local file to a URL. In the given example, the XML document defines an XML Entity referencing an external file, which will be downloaded. The external file is depicted in Listing 5.7.
1 2 "> 3 %all;
Listing 5.7: The file stored on http://attacker.com/parameterEntity_oob. dtd
42 In the first row, a parameter XML Entity referencing a local file is declared. In row 2 a second parameter XML Entity is defined, which declares an XML Entity send referencing a URL and appending the content referenced file. In row 3 the XML Entity all is called. Considering Listing 5.6, in row 3 the XML Entity all is called and the defined URL containing the read file is sent to the attacker.
5.3 Single-Phase Attacks vs. Cross-Phase Attacks
We executed extensive research on different SSO protocols and known attacks. We observed that the most attacks on SSO abuse an insufficient or missing verification step on the SSO token or one of the security relevant parameters.
End-User UA Service Provider Identity Provider https://sp.com https://idp.com
Phase 1: Trust Establishment
Phase 2: Token Generation
Phase 3: Token Redemption
– Loading the attack vectors. – Attack execution.
Figure 5.3: Single-Phase Attacks are started in one phase and the result of the attack occurs in the same phase.
If this step is part of a single authentication phase, for example at the token generation at the IdP in Phase 3, we assign the attack to the Single-Phase Attacks. The identification of such vulnerabilities is relatively easy because a Single-Phase Attack can be conducted by only manipulating, at most, one message in one phase of the SSO protocol.
End-User UA Service Provider Identity Provider https://sp.com https://idp.com
Phase 1: Trust Establishment
Phase 2: Token Generation
Phase 3: Token Redemption
– Loading the attack vectors. – Attack execution.
Figure 5.4: Cross-Phase Attacks are started in one phase, but the result of the attack occurs in a different phase.
In contrast, Cross-Phase Attacks manipulate multiple messages in different phases. This concept introduces more complex attacks that have scarcely been
43 studied before. In general, Cross-Phase Attacks abuse the lack of a binding between two or more protocol phases. This means that the attacker can skip or bypass an important verification step leading to broken End-User authen- tication. In this thesis, we will show that the concept of Cross-Phase Attacks can be applied to all described SSO protocols – SAML, OpenID, and OpenID Connect.
44 6 Attacks on OpenID Connect
OpenID Connect is a new Single Sign-On (SSO) protocol released in February 2014. It is based on OAuth Authorization Framework 2.0 (OAuth), but uses concepts from OpenID. In our research, we carefully analyzed OpenID Connect by considering the protocol flow, the exchanged messages, as well as additional features like Discovery [100] and Dynamic Registration [99]. In our analysis, we identified serious vulnerabilities by providing the first in-depth security analysis of the OpenID Connect protocol.
Attack Class Generic Attacker Category Target Complexity Attack Type ID Spoofing IA AT1+ Cat B SP Single-Phase Wrong Recipient WR AT2 Cat A SP Single-Phase Replay Attack RA AT2 Cat A SP Single-Phase Signature Bypass SB AT1 Cat B SP Single-Phase Covert Redirect CR AT3 Cat A IdP Single-Phase Subclaim-Spoofing IA AT1 Cat B IdP Single-Phase IdP Confusion IA AT1+, AT3 Cat A SP Cross-Phase Malicious Endpoints IA AT1+, AT3 Cat A SP Cross-Phase Issuer Confusion IA AT1+ Cat B SP Cross-Phase
Cat A – Attacker gets access to one victim’s account. Cat B – Attacker gets access to all accounts. Cat C – Attacker gets access to system files. AT1 – Message Generation. AT1+ – Message Generation + malicious IdP. AT2 – Access to Valid Token. AT3 – Classic Web Attacker. .
Table 6.1: Overview of the attacks on OpenID Connect described in this chap- ter.
Considering all SSO protocols one can say that the essence of each SSO protocol is the authentication token containing statements regarding the End- User who is going to be authenticated. These statements can be grouped into four classes: (1) identity, (2) recipient, (3) freshness, and (4) signature. The authentication token, is similar across all SSO protocols and is a valuable target for our identified Single-Phase Attacks: ID Spoofing, Wrong Recipient, Replay Attack, Signature Bypass, Covert Redirect, and Sub Claim Spoofing (SCS). By changing one or more of the values in the token different attacks can be conducted. More complex are Cross-Phase Attacks. They target not only the token statements, but also multiple protocol messages in different phases of the pro-
45 tocol execution. Due to the high complexity of such attacks, they are very hard to identify. In this section, we describe three novel Cross-Phase Attacks: one implementation flaw (Issuer Confusion (IC)), and two specification flaws (IdP Confusion and Malicious Endpoints), which could only be revealed through a deep protocol understanding of the relation between all SSO messages. We summarize all attacks described in this chapter in Table 6.1 and assign them to an attacker type, category depicting the impact, target of the at- tack (SP/IdP) and attack type (Single-Phase Attack/Cross-Phase Attack). We applied these attacks on existing implementations officially referenced by the OpenID Connect’s official website [47]. The results are devastating – we find 75% of them vulnerable to at least one Single-Phase Attack. All libraries are susceptible to the Cross-Phase Attacks abusing the lack in the current spec- ification, which is not surprising since the attacks abuse a logic flaw in the protocol and not an implementation error. We address the existing problems in a Practical Offensive Evaluation of Single Sign-On Services (PrOfESSOS). PrO- fESSOS is our open source implementation for a fully automated Evaluation-as- a-Service for SSO. It introduces a generic approach to improve the security of OpenID Connect implementations by systematically detecting vulnerabilities. In collaboration with the IETF OAuth and OpenID Connect working group, we integrate PrOfESSOS into the OpenID Connect certification process [48]. In this section, we first introduce the OpenID Connect protocol and describe the relevant steps and messages in Section 6.1. In Section 6.2, we describe all Single-Phase Attacks and in Section 6.3 all Cross-Phase Attacks. The method- ology and the results of the provided evaluation are presented in Section 6.4. In Section 6.5, we describe our tool for automated analysis of OpenID Connect – PrOfESSOS. In Section 6.6, we conclude by summarizing the lessons learned during our research.
6.1 OpenID Connect Basics
In this section, we introduce the OpenID Connect protocol flow, all relevant messages and the authentication token issued by the IdP.
6.1.1 Core Protocol Flow In Figure 6.1 Phase 2 (the End-User authentication at the IdP) and Phase 3 (the End-User authentication at the SP) of the hybrid protocol flow in OpenID Connect [101, Section 3.3] are depicted and further described. We do not explain Phase 1 (the manual SP registration and trust establishment) in more detail since we assume that the SP is already registered at the IdP and possess the corresponding key material and URL endpoints.
Phase 2 In Phase 2 the End-User, starting a login attempt at the SP, is redirected to the IdP for authentication. For this purpose, the SP generates an AuthnReq in Step 2.1 (see Figure 6.1) and redirects the End-User to the IdP. The AuthnReq in OpenID Connect contains the following parameters:
46 End-User UA Service Provider Identity Provider https://sp.com https://idp.com
Figure 6.1: Phase 2 and Phase 3 in the OpenID Connect protocol flow.
• response type: This parameter specifies the OpenID Connect protocol flow. There are three different flows – code, implicit and hybrid. In Figure 6.1, the hybrid flow is depicted. • scope: The parameters define the resources requested by the SP. Later, the IdP shows a consent page depicting these resources, which will be authorized by the End-User and shared with the SP. • client id: A unique string identifying the SP, which is established during the registration phase. • state: A random string chosen by the SP and reflected by the IdP pre- venting CSRF attacks. • redirect uri: The callback URI of the SP where the authentication token is sent by the IdP. • nonce: A parameter included in the ID Token (id token) guaranteeing freshness and binding the AuthnReq to the id token. An example is shown in Listing 6.1.
Listing 6.1: An example of the AuthnReq generated by the SP and sent to the IdP via an HTTP Redirect.
In Step 2.2, the End-User authenticates at the IdP and authorizes the access to the requested resources. In Step 2.3, the IdP generates the id token and the code. The code is a reference to a second id token and an Access Token (access token), which are sent in Phase 3. An example of the AuthnResponse is depicted in Listing 6.2.
Listing 6.3: id token in OpenID Connect issued by the IdP and send to the SP.
Phase 3 Once, the code is received, the SP redeems it at the IdP, see step 3.1. Additionally, the SP authenticates itself at the IdP in the same step by sending its client id and client secret. In Step 3.2, the SP receives the id token and the access token. The id token is verified by the SP and compared with the one sent through the front-channel in Step 2.3. The claims must be identical. Optionally, in Step 3.3 the access token is sent to the IdP to access more authorized resources, e.g., additional End-User information like gender and age. In Step 3.4, the resources are sent to the SP.
6.1.2 ID Token In the following section, we describe the structure and content of the id token. The id token is a Base64 encoded JSON Web Token (JWT). An example of the decoded id token is depicted in Listing 6.3 and it contains the following information.
Identity of the End-User The identity of the user consists of two parts: is- suer and subject. The issuer (see Listing 6.3: Line 6, iss) is a mandatory identity claim identifying the originator (the IdP) of the id token, for exam- ple https://idp.com. The subject (Line 7, sub) is a mandatory identity claim that specifies the End-User’s identifier. The subject must be locally unique and never reassigned (e.g., [email protected]). It is essential to note that both values – issuer and subject – must be used to identify the End-User uniquely.
48 Timestamps and Freshness The timestamp parameters expired (Line 8, exp) and (Line 9, iat) define the creation and expiration times of the token. The nonce (Line 10) parameter is a randomly chosen string value, sent by the SP within the AuthnReq and passed unmodified to the id token. It is used to mitigate replay attacks. In addition, the nonce value binds the AuthnReq to the id token.
Audience Restrictions The audience (Line 11, aud) is a mandatory claim specifying the audience(s) for which the id token is intended to be used for (e.g., https://sp.com). It must contain the client id of the SP that requests the token.
6.1.3 Discovery and Dynamic Client Registration OpenID Connect provides mechanisms for dynamic and fully automatic open trust establishment between IdP and SP by means of the Discovery and Dy- namic Registration. Open in the context of SSO means that End-Users can be logged in at an SP even if the End-User’s IdP is not known to the SP beforehand. An End-User can simply submit his identity at the SP, which is usually a URL (e.g., https://idp.com/alice) or an email address (e.g., al- [email protected]). Based on this identity the SP discovers the responsible IdP (e.g., https://IdP.com/) and retrieves all information needed for the authentication. Afterwards, the SP dynamically registers on the discovered IdP and establishes a trust relationship to be able to (retrieve and) verify the authentication tokens used later in the SSO protocol flow. A detailed description of the Discovery phase with respect to the security is shown in Figure 6.2 (see Section 6.3).
6.2 Single-Phase Attacks
In the following sections, we systematically analyze problems that can occur if a verification step in one phase is not implemented properly and map these precisely on the OpenID Connect protocol.
6.2.1 ID Spoofing (IDS) The ID Spoofing (IDS) attack abuses an implementation flaw at the SP and targets the identity related information in the authentication token. The attack belongs to Cat B. The idea of IDS is that the attacker starts a login attempt at the SP using his malicious IdP. The malicious IdP then generates an authen- tication token for an identity managed by another honest IdP, for example, by Google, but signs it with its own key. If this authentication token is accepted by the SP, the attacker is logged in and has access to accounts managed by other honest IdPs.
Requirements We assume that the SP allows the usage of the malicious IdP – Attacker Type (AT)1+.
49 Exploit In OpenID Connect, the identity of an End-User is represented by the combination of two parameters: (1) sub, defining the identity of the authenti- cated End-User at the IdP and (2) iss, which defines the issuer of the token. Usually this is the URL of the IdP. Here the attacker can try two different strategies: Strategy 1: First, he can change the sub value to the victim’s value. In case that the SP uses only the sub value and ignores the iss parameter pointing to the malicious IdP, then the attacker is logged in at the SP in victim’s account. Strategy 2: In case that the SP uses both sub and iss parameters to authen- ticate the End-User, by using his malicious IdP the attacker can change both values to the victims’.
Impact If applicable, the impact of the attack is devastating since the attacker can log in at every account at the SP (Cat B) without any End-User interaction.
Countermeasure As a countermeasure for IDS, the SSO Verificator at the SP must verify that the malicious IdP is not allowed to issue tokens managed by another IdP. This can be implemented by checking the iss value and verifying the signature with the key material corresponding to this iss.
6.2.2 Wrong Recipient (WR)
The idea of the Wrong Recipient attack is that an attacker redeems an id token issued for one SP at another SP.
Requirements We assume that the attacker possesses a valid id token – AT2.
Exploit By acting as a malicious SP the attacker receives authentication to- kens from different users. Behind the scenes, he tries to redeem these tokens at other SPs and thus get unauthorized access to different accounts. This attack is feasible since an IdP is used by multiple SPs and issues tokens for all of them.
Impact The attack requires the interaction with the victim using the malicious SP. As a result, the attacker gets access to the victim’s account – Cat A.
Countermeasure Every issued authentication token must only be consumed by a specified SP. Therefore, the Verificator at the SP must verify the Recip- ient information. In OpenID Connect, the parameter specifying the recipient of the token is the aud parameter. It contains the unique identifier of the SP (client id). Once the SP receives an id token, it must verify that the aud parameter corresponds to its own client id to counter the Wrong Recipient attack.
50 6.2.3 Replay Attack (RA) Replay attacks circumvent the one-time use requirements and the time restric- tions of an authentication token. In worst case scenario, an End-User, for example a former employee, has access to an SP for infinite amount of time.
Requirements We assume that the attacker possesses a valid id token – AT2.
Exploit To start a Replay Attack the attacker only sends multiple times the authentication token even after its expiration. Then, he observes the reaction of the SP. In case that the authentication token is accepted and the attacker is logged in, the attack is successful.
Impact The impact is limited by the fact that the attacker can log in only in the account stated by the id token – Cat A. Nevertheless, the attacker gets access to the SP without authenticating himself at the IdP. Thus, even if the attacker’s account is locked or deleted at the IdP, he can still log in at the SP and use some resources.
Countermeasure Replay attacks are possible if Freshness parameters are not verified properly. Such a limitation can be based on timestamps defining a time- slot for the validity of the authentication token. A more restrictive option of single use parameters are nonces, which should be verified. In OpenID Connect, the relevant parameters are iat (issued at), exp (expired), and nonce.
6.2.4 Signature Bypass (SB) SSO protocols use cryptographic operations to protect the integrity of the au- thentication token or at least parts of it1. Signature Bypass attacks evade this integrity protection and enable the modification of any content within the au- thentication token. If a Signature Bypass is possible, all previous described Single-Phase Attacks are applicable since (1) any identity of an End-User can be inserted, (2) any audience can be stated, and (3) all timestamps and nonces can be adjusted.
Requirements The Signature Bypass attack class relies on AT1. Thus, the attacker does not need any victim interaction and supported features by the SP.
Exploit The signature value itself, but also all relevant information to verify the signature, belong to the Signature information data2. An id token in OpenID Connect has several relevant parameters. The signature value itself is transferred in the JWT. The JWT header contains a parameter alg. By setting its value to none, the signature verification could be disabled [84]. According to
1E.g., in SAML. The XML-Signature protects the Assertion element in most cases, but not the XML root element Response. 2E.g., the algorithm being used, certificate information, etc.
51 the OpenID Connect specification, none is not allowed if the token is transferred via the user agent (UA) of the End-User; however, multiple implementations missed this check. The JWT header can optionally contain further parameters such as the key id (kid), which is used to identify the key to be used for the signature. If an attacker can point to his own key, the wrong (untrusted) key is used and he can sign arbitrary tokens containing arbitrary identities.
Impact Since the attacker can issue valid authentication tokens containing any statement, he can log in at any account at the SP. Thus, Signature Bypasses belong to Cat B attacks.
Countermeasure To prevent such attacks, the Verificator at the SP must (1) blacklist all weak, broken, and thus insecure cryptographic algorithms, for example, the none algorithm. (2) ensure that the correct key material is loaded, which can be done by verifying the signature with the key material correspond- ing to the iss in the id token, and (3) verify that all parameters used for the authentication within the authentication token are protected by the signature.
6.2.5 Covert Redirect (CR) Covert Redirect addresses the URL validation within the AuthnReq at the IdP. The goal of such attacks is to enforce the IdP to send the code or id token to an arbitrary URL controlled by the attacker. Once the attacker has the id token, he can redeem it at the SP through his own UA.
Requirements We assume that the victim visits a webpage created by the attacker, e.g., by clicking on a malicious link – AT3. In addition, we assume that the victim is already logged in at the IdP. Thus, the AuthnResponse is generated directly without prompting the victim to authenticate at the IdP.
Exploit Once the victim visits the webpage created by the attacker, a mali- cious AuthnReq is generated and sent through the victim’s UA to the IdP. In OpenID Connect, the parameter used by the attacker to enforce the theft is the redirect uri, sent within the malicious AuthnReq to the IdP.
Impact The attacker steals a valid authentication token issued for the victim. Since only one account is compromised, we refer this attack to Cat A attacks.
Countermeasure The redirect uri is established during the registration phase. Optionally, the SP can register multiple URLs. The Verificator at the IdP should strictly match the received URL within the AuthnReq or Token Request (see Step 3.1 in Figure 6.1) with the registered one. Unfortunately, very often SPs vary the URL by varying the HTTP GET parameters or the URL path. Thus, many IdPs provide less restrictive validation of the URLs, which can result in security issues as shown by Egor Homakov [39, 40, 56].
Listing 6.4: Example of an AuthnReq containing claims, which have to be added [65].
6.2.6 Sub Claim Spoofing (SCS) SCS is started against the IdP and it targets the verification of the AuthnReq. The idea of SCS is that the AuthnReq contains requested claims regarding an End-User, which must be checked by the IdP and included in the id token. In case that the verification step is skipped, malicious statements, e.g., other End-User identities can be inserted in the authentication token. Thus, the SP will verify and accept the authentication token and provide a login at the wrong account.
Requirements The attacker does not need any victim interaction or access to valid tokens – AT1.
Exploit Within the AuthnReq the SP can request individual claims about the End-User either by using the HTTP parameter claims or within a JWT. An example of a JWT containing requested claims is shown in Listing 6.4. In the given example, the SP requests the claims auth time and acr to be added to the issued id token. Noteworthy, the SP can even request a claim to have a specific value. An attacker can use this feature to create a malicious AuthnReq containing claims about the victim and require the IdP to add these claims to the id token. An example is shown in Listing 6.5. In this case, the attacker issues an AuthnReq requesting the IdP to add the value sub to the id token with the value set to the identity of the victim. The IdP receives the AuthnReq and authenticates the attacker. Instead of setting the value of sub to attacker’s identity, it sets up the identity to the victim’s identity. In case the
Listing 6.5: Example of a malicious AuthnReq containing claims regarding an End-User reflected in the id token [65].
issued id token contains the victim’s identity the SP will successfully verify the token and log in the attacker at the victim’s account.
Impact SCS is a Cat B attack, since the attacker can enforce the IdP to issue valid authentication tokens regarding arbitrary End-Users. In addition, no End-User interaction is needed.
Countermeasure The countermeasure against the attack is that an IdP should not insert unverified statements in the id token. In addition, unknown or duplicate claims should be excluded from the id token.
6.3 Cross-Phase Attacks
A Single-Phase Attack can be conducted by only manipulating one message, at most, in one phase of the SSO protocol. In contrast to this, Cross-Phase Attacks manipulate multiple messages in different phases. This concept introduces more complex attacks, which have scarcely been studied. In general, Cross-Phase Attacks abuse the lack of a binding between two or more protocol phases. This means the attacker can skip or bypass an important verification step leading to a broken End-User authentication. In this section, we first show how the Discovery phase influences the OpenID Connect protocol flow. Based on this knowledge we developed two attacks – IdP Confusion and Malicious Endpoints – abusing a flaw in the current OpenID Connect specification. Our third attack – Issuer Confusion – makes use of an implementation flaw. The result of the introduced Cross-Phase Attacks is that the attacker is logged in at the SP at the victim’s account.
54 Discovery Phase in OpenID Connect Two of the attacks described in this section depend on the Discovery phase – Issuer Confusion and Malicious End- points. Thus, we briefly introduce the relevant messages. Figure 6.2 shows how
Figure 6.2: The OpenID Connect Discovery phase influences all other phases. the information retrieved during the Discovery phase influences the OpenID Connect phases. The first two messages are used to discover the URL where the metadata of the IdP is stored based on the identity entered by an End-User. The Discov- ery request (see Step 1.1.1), is an HTTP message sent to the IdP’s discovery service. The response is a JSON message containing two parameters: (1) href, which points to the metadata of the IdP and (2) rel, which identifies the type of service3. Consequentially, a new HTTP request is sent to the URL specified via the href parameter. The response contains the metadata with all informa- tion regarding the IdP: endpoints, supported authentication flows, supported algorithms for signing and encrypting messages, public keys of the IdP etc. Figure 6.2 depicts the relation between the endpoints received in the last messages of the Discovery phase and the OpenID Connect phases. The Dynamic Registration Endpoint (regEndp) will be used by the SP to register the SP at the IdP and receive the SP credentials (e.g., client id/client secret). The Authorization Endpoint (authEndp) points to the Authorization server responsible for the authentication of the End-User. Noteworthy is the fact that only the authEndp is visible for the End-User during the authentication. All other endpoints are called by the SP directly and thus cannot be seen by the End-User. The next three endpoints Token Endpoint (tokenEndp), Userinfo Endpoint (userInfoEndp) and JWKS Endpoint (jwksEndp) are used in the last phase (Phase 3) of the protocol: the End-User authentication.
3E.g., http://openid.net/specs/connect/1.0/issuer
55 6.3.1 Specification Flaw: IdP Confusion IdP Confusion is a novel Cat A attack on OpenID Connect, which abuses a weakness in the current specification; in this case, the connection between Phase 2 (the End-User authentication at the IdP) and Phase 3 (the redemption of the received code) is missing.
Service Provider Attacker Identity Provider End-User UA https://sp.com https://attackerIdP.com
– Discover the IdP and get it s metadata: Discovery authEndp tokenEndp/ issuer, regEndp, authEndp, tokenEndp userInfoEndp/ jwksEndp
Figure 6.3: IdP Confusion Cross-Phase Attack: Logical flaw in the OpenID Connect specification.
More precisely, the SP receives a code from the victim by the end of Phase 2. Due to the flaw in the specification, it is unable to determine to which IdP the code belongs. Because the attacker has modified an important step in Phase 2, the SP wrongly sends the code (plus client id and client secret) to the malicious IdP, which the attacker can use for its own purposes.
Requirements We assume that the SP allows the use of custom IdPs. Ad- ditionally, we assume that during the registration, the SP receives the same client id from the malicious IdP as at the honest IdP. In other words, the SP has the same client id on two different IdPs, which is allowed according to the specification.
Exploit Figure 6.3 shows the attack: • In the first step the victim clicks on a malicious link or visits an attacker controlled website. This click automatically manages to start a login attempt at the SP with an identity controlled by the malicious IdP, for example [email protected]. • If the SP supports Discovery, metadata is retrieved. • In Step 2.1 the SP redirects the End-User to the authorization endpoint of the malicious IdP. • In Step 2.2 the malicious IdP redirects the End-User to the honest IdP. Additionally, it replaces the nonce parameter. This manipulation is nec- essary to successfully impersonate the victim at the SP. Please note that up to now all steps do not require any interaction of the End- User and are transparent to him. Thus, he is not able to detect the attack.
56 • In Step 2.3 the End-User must authenticate to the IdP. In case the End- User has already authenticated, this step will be skipped. This is the only step in which it is possible for the victim to detect the attack. For instance, it might seem suspicious for the victim to get an authentication pop-up. If the user is already authenticated at the honest IdP, this step is usually transparent for the End-User. • The IdP generates a valid code and returns it together with the state parameter back to the SP. • The SP still believes that it is communicating with the malicious IdP due to Step 1.2. For this reason, it redeems the received code at the malicious IdP and additionally sends its client id and client secret. • As a result, the attacker has a valid code, which he can then redeem through his browser at the SP. The attacker now starts his authentication at the SP and sends the stolen code to it. The SP redeems the code at the honest IdP and logs the attacker into the victim’s account.
Impact The IdP Confusion attack is assigned to the Cat A attacks since a victim interaction is needed and only his account is compromised.
Countermeasure We describe the countermeasure for this attack in Section 6.6.
6.3.2 Specification Flaw: Malicious Endpoints Attacks The Malicious Endpoints Attack is a novel attack on OpenID Connect, which abuses a weakness in the current specification. The connection between Phase 1 (the Discovery) and Phase 3 (the redemption of the received code) is missing. Similar to IdP Confusion, the idea is to confuse and force the SP to send a valid code together with the SPs client id and client secret to a URL controlled by the attacker. More precisely, the SP downloads in Phase 1 maliciously craft metadata from the malicious IdP, forcing the SP to use the honest IdP during Phase 2 for the End-User authentication, but to redeem the received tokens at the malicious IdP in Phase 3. In addition, we extended Malicious Endpoints Attack to Server Side Request Forgery (SSRF) and Denial-of-Service (DoS) attacks.
6.3.2.1 Broken End-User Authentication This Cat A attack manipulates the information in the Discovery and Dynamic Registration Phases in such a way that the attacker gains access to sensitive information. The attacker (1) pursues the theft of the credentials between the honest IdP and the honest SP and (2) steals a valid code authorizing the SP to access End-User’s resources at the honest IdP.
Requirements We assume that the End-User (victim) has an active account at the SP and that he also has an account at the honest IdP. In addition, the SP supports the Discovery.
Listing 6.6: Endpoints returned by the malicious IdP
Exploit In the following, we describe the attack protocol flow we depicted in Figure 6.4. Phase 1.1 - Injecting malicious endpoints. Similar to the IdP Confusion attack, the victim is lured to log in with [email protected] at the SP. Consequentially, the SP starts a discovery with the malicious IdP to initiate the actual attack, which responds with the values shown in Listing 6.6. This dif- fers to the IdP Confusion attack, where the malicious IdP does not manipulate this message. Phase 1.2 – Dynamic Registration. In the next step, the SP accesses regEndp for the Dynamic Registration. It sends a registration request to https:// honestIdP.com/register and receives a client id and client secret. Note: The SP automatically starts the Dynamic Registration, even if it is already registered at the honest IdP. The reason for this behavior is that the SP believes that http://attackerIdP.com is the responsible IdP since it is not known from previous authentication procedures. Thus, http://attackerIdP. com is a new IdP for the SP and it starts the registration procedure. Phase 2 – End-User Authentication at the IdP. In the next phase, the SP redirects the End-User to the authEndp, https://login.idp.com/, where the End-User must authenticate himself and authorize the SP. The End-User is not able to detect any abnormalities in comparison to the normal protocol flow. Phase 1.1 and Phase 1.2 cannot be observed by the End-User, and in Phase 2 the End-User will be prompted to authenticate to the honest IdP and authorize the honest SP (he trusts both). Thus, the End-User authorizes the SP and the IdP generates the code, which is sent to the SP. Note: Phase 2 follows the specified OpenID Connect protocol flow – there are no parameter manipulations, no redirects to malicious websites, and no
58 observation of the network traffic between the End-User, the honest IdP, and the SP. Thus, the attack started at the beginning of the protocol flow can be neither detected nor prevented by any of the participants at this point. Phase 3 – The Theft. Now the SP redeems the received code from the previ- ous phase. It sends the code, together with the corresponding SP’s credentials received during the Dynamic Registration (client id/client secret), to the real tokenEndp. The attacker receives a valid code and client id/client secret. Thus, he is authorized to access the End-User’s resources at the IdP, retrieve a valid id token.
Impact The attack is Cat A attacks since a victim interaction is needed and only his account is compromised.
Countermeasure We describe the countermeasure for this attack in Section 6.6.
6.3.2.2 Server Side Request Forgery A Server Side Request Forgery (SSRF) attack describes the ability of an at- tacker to create requests from a vulnerable web application to the application’s Intranet and the Internet. Usually, SSRF is used to attack internal services placed behind a firewall and thus not accessible from the Internet. Recent researches revealed how critical SSRF attacks could be by examin- ing large companies like PayPal [106] and Yahoo [64]. In case of PayPal, the attacker was even able to compromise customer data via SSRF. In context of OpenID Connect, the malicious IdP can be used to start such attacks in order to (1) gather information about the Intranet infrastructure of the Client, and (2) disseminate attack vectors.
Setup The attacker sets up a malicious IdP returning endpoints called by the SP during the protocol flow. The endpoints are URL strings specifying protocol (http(s), ftp, smb etc.), port, path, and parameters. Since there are no restrictions regarding the URLs, these can point to the Intranet infrastructure of the SP. The SP will use these URLs and performs HTTP GET requests on them. In this manner, the SP can, for example, be enforced to invoke internal REST-based web services. This capability of the attacker is considered by the attacker model, since the attacker can use his UA and send arbitrary HTTP requests to every publicly available domain. Thus, he can cause the SP to establish connection with the malicious IdP.
Attack description In comparison to the previous Malicious Endpoints At- tacks, the attacker now initiates the OpenID Connect authentication at the SP by entering his identity (e.g., [email protected]). Thus, no CSRF attack is needed. In the end of the Discovery phase, the malicious IdP returns the malicious endpoints called during the different phases of the protocol. Previous researches reveal how the execution of URLs can be used to (1) connect and
59 (a) Memory usage at the SP within 5 (b) Memory usage at the SP within 5 parallel OpenID Connect authenti- parallel OpenID Connect authen- cation flows to an honest IdP. tication flows to a malicious Dis- covery service pointing to a large file (in this case, we used a Debian Linux image file with 3.7 GB).
Figure 6.5: Comparison of the memory consumption on an SP by (a) working normally and (b) under DoS attack by using Malicious Endpoints. execute commands on different services like Memcached, (2) Port scanning and (3) data retrieving [2, 93].
6.3.2.3 Denial-of-Service Attacks
By applying Denial-of-Service (DoS) attacks, the attacker allocates resources on a SP and negatively affects its workflow. Such resources are CPU usage, network traffic, or memory. The attack can target one or more of these resources during the execution of the DoS attack. Figure 6.5 compares the memory usage at the SP using (a) an honest IdP and (b) a malicious Discovery service when a DoS attack is applied.
Setup The setup is similar to the SSRF attack – the attacker sets up a mali- cious Discovery service returning endpoints called by the SP during the protocol flow. The attacker can use his UA and send HTTP request to the SP causing the SP to establish connection with the malicious Discovery service.
Attack description An attack can be started by using a malicious endpoint pointing to a large data file, which will be downloaded. The SP calls later the malicious endpoint URL, allocates network resources, as well as large amount of the memory, which will be unnecessarily used. We provide a measurement shown in Figure 6.5(b) on an Apache Tomcat server with 1280 MB memory and 4x2.4 GHz CPU. In Figure 6.5(a) we first measured the memory usage at the SP within five parallel OpenID Connect pro- tocol runs with an honest IdP. One can say that almost imperceptible changes in the memory consumption occur. In Figure 6.5(b) we repeated the same tests, but this time we used our malicious Discovery service pointing to a large file. After few seconds, the memory usage increased almost threefold. After 60 seconds, the SP was not accessible for any incoming requests.
Figure 6.6: Issuer Confusion Cross-Phase Attack: The attacker uses his mali- cious IdP to store the wrong issuer at the SP in Phase 1. In Phase 3, it issues an authentication token containing the identity of the victim.
6.3.3 Implementation Flaw: Issuer Confusion (IC) Issuer Confusion is a Cat B attack and is depicted in Figure 6.6. The idea of Issuer Confusion is to confuse the SP into successfully accepting an id token issued by the malicious IdP, while believing that it was issued by an honest IdP. The main idea is related to the IDS attack – an id token issued and signed by malicious IdP in the name of the honest IdP is successfully verified at the SP. Still, in comparison to IDS, the Issuer Confusion abuses a missing verifica- tion step in Phase 1 to break the entire security even if the verification of the authentication token in Phase 3 is implemented correctly. In subsection 6.2.1, we showed the IDS attack abusing the skipped verification of the iss parameter. Consequentially, the question arises of how this verification step can be imple- mented correctly. In other words, how can the SP verify that the iss within the authentication token really belongs to the IdP that has generated the token? According to the specification, “the Issuer Identifier for the OpenID Provider (which is typically obtained during Discovery) MUST exactly match the value of the iss (issuer) Claim” [101]. This means the correct verification of the authentication token in Phase 3 depends on parameters exchanged in Phase 1.
Requirements The attack assumes an SP, allowing the usage of custom IdPs, for example, the malicious IdP.
Exploit The attack proceeds as depicted in Figure 6.6: • The attacker starts the login at the SP. • In Step 1.2 the SP discovers the IdP – in our example https://attackerIdP. com – and retrieves the identity of the IdP, public keys, and important URLs. Here the malicious IdP returns the parameter issuer: https: // honestIdP. com (instead of https://attackerIdP.com). • Phase 2 is not depicted in Figure 6.6 since no manipulations or any attack takes place here. • In Phase 3, Step 3.2, the SP receives an authentication token (called id token in OpenID Connect) and verifies it. The id token once more contains the value issuer: https: // honestIdP. com , which matches the
61 SP Single-Phase Attacks Cross-Phase Attacks Libraries Custom Dynamic IdP Trust Wrong Signa- Issuer IDS Recipi- ture Specification Replay Conf. ent Bypass Flaws mod auth openidc Yes Yes X X X Vuln. X Vuln. MITREid Con- Yes Yes X X X X X nect Vuln. oidc-client Yes Yes Vuln. Vuln. X Vuln. Vuln. Vuln. phpOIDC Yes Yes Vuln. Vuln. Vuln. Vuln. Vuln. Vuln. Drupal Yes No Vuln. Vuln. Vuln. Vuln. OpenIDConnectd Vuln. Vuln. pyoidc Yes Yes Vuln. Vuln. Vuln. X Vuln. Vuln. Ruby Yes Yes X X X X X OpenIDConnect Vuln. Apache Oltu Yes No X X Vuln. Vuln. X Vuln. Total 8/8 6/8 4/8 4/8 5/8 5/8 3/8 8/8 Successful At- tacks
Table 6.2: Security analysis results of officially referenced SPs libraries. Only 2 of 8 (25%) libraries implemented all required verification steps properly.
value of Step 1.2. If the validation is successful, the attacker gets access to the victim’s account at the SP. In summary, the attacker manipulates the issuer parameter in two different protocol phases, meaning we have a Cross-Phase Attack.
Impact Since the attacker can issue valid tokens regarding any identity of an End-User by using only his malicious IdP, we refer this attack to Cat B attacks.
Countermeasure This attack abuses an implementation flaw. The SP must verify that the returned issuer parameter matches the IdP. To fix it, the SP must verify that the issuer returned in Step 1.2 matches the called URL (according to the specification).
6.4 Evaluation
In this section, we describe the evaluation of existing SP and IdP implemen- tations. The selection of the target implementations is provided by using the official OpenID Connect website [47] referencing popular implementations.
6.4.1 Evaluation of OpenID Connect SPs We selected all 12 open source libraries officially referenced on the OpenID Connect website [47]4. In addition, 11 commercial products like Amazon and MS Azure and 18 tools supporting JSON-based operations (e.g., encryption and
4Note that the referenced list is growing rapidly.
62 signing) are referenced although we did not consider them in our evaluation. Our list contains implementations in C, C#, Java, PHP, Python, and Ruby. Initially, we provided a manual analysis as proof-of-concept of our analyzing methodology and attacks. Moreover, during the development of our tool for automated analysis (PrOfESSOS) a benchmark was implemented to recognize false results.
Setup We documented the supported features of the SPs. Such features are (1) flows (code, implicit, hybrid), (2) cryptographic algorithms, and (3) addi- tional features such as Discovery and Dynamic Registration. 4 of 12 libraries do not support a full SP functionality. Such libraries are used as a foundation to implement an SP. Features like an authenticated session after a successful login or an End-User profile page are not implemented by these libraries. Without this part, it is not possible to verify if an attack is successful or not. Therefore, we did not consider these libraries. We concentrated on the remaining 8. These libraries support the usage of a malicious IdP. Only 2 out of 8 libraries did not support Discovery and Dy- namic Registration. Because of that, we manually configured them to use our malicious IdP needed for the security evaluation. For the remaining 6, no pre- configuration and no manual steps were required.
Amazon PrOfESSOS can also be applied to live websites. We chose Ama- zon Web Services for our proof-of-concept since Amazon supports the usage of malicious IdP. PrOfESSOS can be started by simply configuring its URL in the configuration area. Thus, we could evaluate all known attacks. Amazon is not susceptible to any of them. Interestingly, Amazon already implemented a countermeasure against the IdP Confusion attack similar to the countermeasure proposed by IETF [73].
Results The results of our security evaluation are presented in Table 6.2. 75% of the libraries were susceptible to at least one critical implementation issue5, for instance, one of the Single-Phase Attacks or the Issuer Confusion attack. Even though Single-Phase Attacks are well-known, security relevant param- eters were ignored and not verified at all. We reported all issues to the de- velopers of the libraries and supported them while fixing the vulnerabilities. Even though many of the vulnerabilities exist due to missed checks, reporting and fixing the issues involved huge outlays since we had to precisely explain the security issues and the impact of the attacks. This showed us that many developers are not aware of the risks of skipping one security check, especially in the complex Cross-Phase Attacks. In the case of attacks abusing weaknesses in the specification like IdP con- fusion, all implementations are vulnerable. This is an expected result since even a correct implementation, which strictly follows the specification rules is still susceptible. Moreover, such attacks are targeting the protocol specification
5Beyond that, all the libraries were vulnerable to the specification issues.
63 srcgie ytedvlpr edn oscr aiaino the of validation validation secure proper the to of multiple leading importance developers by the the result, by addressed a recognized that As already is is 118]. and result 56, this 40, studied [39, for well evaluations reason are main The attacks 6.2. Redirect Section 6.3. in Table described in attacks results the documented and attacks the Then, executed we these. libr installed the needed, collected if all first and, we functionality mast evaluation, the IdP the within viding During provided libraries was [65]. evaluation Connect J.Krautwald The OpenID of existing [47]. the on of referenced evaluation cially an started we 2014, IdPs In Connect OpenID of Evaluation 6.4.2 execution. successful language the program for relevant the not Thus, are code details. source implementation the the of instead itself att Applicable – libraries Connect OpenID IdP the of Evaluation 6.3: Table available. not Feature – n/a C eas l fte goeukoncam ihnthe within claims I unknown 8 se ignore of are them IdPs 5 evaluated of only All all on feature. because started this SCS support be IdPs could these attack only since SCS the Interestingly, parameter. X X tak r o plcbe neetnl,nn fteIP supports 64 Redir IdPs Covert the that of see none i can Interestingly, depicted one fre are evaluation applicable. a results previous not The offer the are these to SPs. attacks Similar since arbitrary with Salesforce 6.4. used and ble be PayPal can Google, and choose account We Connect. oetRdrc #2 Redirect Covert #1 Redirect Covert Spoofing Claim Sub aiainecp o ah ur n rgetpr fthe of part fragment and query path, for except Validation – * Validation; – n a e htallbaisecp pceOt r eueaantthe against secure are Oltu Apache except libraries all that see can One nadto oteIPlbais eeautdpoietIP using IdPs prominent evaluated we libraries, IdP the to addition In upre osadfaue,wihwr ouetdi 6] Afterw [65]. in documented were which features, and flows supported
X X n/a Thinktecture IdentityServer v3
n/a n/a n/a Nimbus OAuth 2.0 SDK
X X X MITREid Connect
X X X oxAuth Vuln. Vuln. n/a
URI Apache Oltu
X X X phpOIDC AuthnReq X X n/a edocumented we oauth2-server-php redirect ueagainst cure re pro- aries X X X . rthesis er OpenID
security pyoidc claims Covert Ta- n ards, acks offi- dPs and uri ect X X X Ruby OpenIDConnect e Google+ PayPal Salesforce Sub Claim Spoofing n/a n/a n/a Covert Redirect #1 X X* X Covert Redirect #2 X X* X
X– Validation; X* – Validation except for path, query and fragment part of the URI n/a – Feature not available.
Table 6.4: OpenID Provider Live Implementations - Applicable Attack- Scenarios within the AuthnReq. Thus, SCS could not be applied.
6.5 Automated Analysis
Simultaneous to our initial manual analysis, we developed PrOfESSOS, con- firmed the results of our evaluation and to verify whether the reported issues were fixed by the developers. Once configured, the re-evaluation with PrOfES- SOS requires only a few minutes. Another main advantage of PrOfESSOS is its capability to analyze Cross- Phase Attacks. It can analyze all currently known specification flaws and pro- poses countermeasures. Thus, implementations, which are susceptible against the newest attacks, can be warned and a proper fix is introduced.
6.5.1 Architecture A user of PrOfESSOS – the penetration tester – can access it via its web interface.6 The penetration tester enters the URL of the target SP and selects the attacks to be tested. In Figure 6.7 we depict the architecture and components of PrOfESSOS.
Security Test Runner (STR) PrOfESSOS is an Evaluation-as-a-Service (EaaS) web application. As such, it is available for multiple penetration testers simulta- neously. The Security Test Runner (STR) component is basically the executing processor of PrOfESSOS so that multiple, parallel, running tests do not inter- fere with each other. The STR navigates the malicious IdP during the testing, gets the HTTP and HTML results back, and evaluates the attack’s success condition.
Malicious IdP The malicious IdP is a highly configurable IdP capable of act honestly and maliciously. The IdP gets information from the STR about the target SP, for example, important URLs needed to start the authentication flow (e.g., login page URL). It also needs information to verify, whether the login
6Demo: https://openid.sso-security.de.
65 PrOfESSOS Testing SPs
Security Test Runner Attacker IdP Honest IdP (https://sso-security.de) (https://attack-sso.de) (https://honest-sso.de)
Target SP Pentester (https://honestSP.com) Figure 6.7: Test scenario when using PrOfESSOS. attempt was successful, for example, a URL to the user profile and an attack description, containing information about the attack protocol flow, plus order and content of the messages. The IdP logs all information during the testing and pushes the results to the STR.
Honest IdP Using only one IdP for testing implementations is quite limited. During some attacks, the malicious IdP confuses the SP by making it believe he is communicating with the honest IdP (mainly for Cross-Phase Attacks). Un- fortunately, the malicious IdP cannot observe this communication. Therefore, it is impossible to analyze the exact behavior of the SP during the attacks and evaluate the results. To solve this limitation, PrOfESSOS introduces a second honest IdP, which does not perform any attacks. Instead, it is only used to simulate the victim’s IdP and to observe the communication between the SP and any honest IdP. Similar to the malicious IdP, the honest IdP pushes reports to the STR, which evaluates the results.
6.5.2 Automated Analysis Workflow PrOfESSOS evaluates the target SP in three stages: setup, configuration eval- uation, and attacks.
Stage 1: Setup The penetration tester starts the SSO evaluation by visiting the homepage of PrOfESSOS. In the background, the STR creates one malicious IdP and another honest IdP instance on the fly (cf. Figure 6.7).
Stage 2: Configuration Evaluation The penetration tester enters the URL of the SP that he wants to test. PrOfESSOS then fetches the HTML document at the URL and tries to detect the login form. If PrOfESSOS can automatically detect the form, it enters the URL of the malicious IdP to start the authenti-
66 cation. Otherwise, the penetration tester must provide additional information so PrOfESSOS can start a login attempt automatically. Once PrOfESSOS can successfully log in at the SP, the next challenge has to be solved: PrOfESSOS must detect the name of the user currently logged in. In some cases, the username is simply printed on the website. On more complex SPs, the penetration tester can provide a link to a URL where this information can be found. PrOfESSOS needs this kind of information for attacks related to the Identity information (Class I) of the SSO token. If, for example, an attack sends two different usernames in one token, PrOfESSOS must decide, which value is used. Finally, PrOfESSOS starts a new login attempt, but this time the malicious IdP creates an invalid token (containing a wrong signature). By this means, it tests whether a false login state can be distinguished from a correct login. If this test fails, PrOfESSOS aborts the SP evaluation.
Table 6.5: Configuration summary of Single-Phase and Cross-Phase Attacks supported by PrOfESSOS.
Stage 3: Attacks In this stage, the penetration tester selects different attacks that will be executed against the target SP. In Table 6.5 we summarize the configuration of all attacks described in this thesis. PrOfESSOS uses two IdPs – an honest IdP and a malicious IdP. The honest IdP strictly follows the OpenID Connect specification. It is used for monitoring
67 the HTTP traffic and does not apply any protocol or message manipulation. On the other side, the malicious IdP can differ from the OpenID Connect specifi- cation. Once an attack is started, the malicious IdP takes the attack configura- tion and manipulates the specified messages. All other messages are untouched. The attack configuration thus only specifies the manipulations deviating from the specified protocol flow. The configuration contains additional information about the applicable protocol flows, required OpenID Connect features (e.g., whether the attack requires Discovery), and about success conditions. For ex- ample, an IDS attack (see Table 6.5, row 1) can be executed on all OpenID Connect flows (code, hybrid and implicit). During the attack execution, the malicious IdP acts according to the OpenID Connect specification until Phase 3. Therein, the malicious IdP must manipulate the id token by setting the sub value to the victim’s identity. More precisely, the malicious IdP first creates a valid id token, then it replaces the sub value, and finally signs the id token. Once the id token is sent, PrOfESSOS observes the reaction of the SP and the corresponding results. In case of IDS, PrOfESSOS validates the success conditions, meaning (1.) whether the login was successful and (2.) if the name of the logged-in user corresponds to the victim’s identity (belonging to the hon- est IdP). Table 6.5 also depicts the more complex Cross-Phase Attacks, such as Issuer Confusion, by specifying manipulations in the Discovery and in the id token. Further attacks can be added by creating a new configuration, which potentially allows for the manipulation of every message or for the addition of new ones according to the attack’s requirements7.
6.5.3 Limitations
PrOfESSOS currently supports only OpenID Connect. Some tests can be started on OAuth SPs due to the familiarities of both protocols. Other pro- tocols such as OpenID and SAML are not yet implemented. We intentionally decided to implement the manual configuration of PrOfESSOS (see Stage 1). The reason for our decision are the existing challenges documented by Zhou et al. [133], which include automatically finding the login button, captchas, invis- ible identity, atypical HTML elements, etc. Such problems make automated configuration and analysis very hard, error-prone, and in the case of complex attacks like Cross-Phase Attacks, they can lead to false results. The configura- tion overhead of filling out six text fields is considered feasible for a penetration tester and developer. PrOfESSOS was not designed for large scale studies, crawling Alexa Top websites and finding security issues. Instead, the main goal was to improve the security of SSO by continuously supporting developers during the implementation of new libraries.
We showed that although the OpenID Connect specification addresses (most) attacks or at least provides countermeasures without stating attacks, implemen- tations often do not follow its guidelines for implementing it securely. Many of the investigated OpenID Connect libraries have critical implementation flaws resulting in broken End-User authentication. We assume that implementation flaws will always exist since developers are not always security experts nor do they follow the specification instructions.
PrOfESSOS To tighten the gap between a specification and an implemen- tation, we propose PrOfESSOS, an Evaluation-as-a-Service that automatically performs and evaluates attacks, which we divide into Single-Phase and Cross- Phase Attacks. Since PrOfESSOS is open source and available on Github, it can serve as the basis for many other research projects besides SSO exclusively. Based on our experiences with SSO security regarding all major protocols (SAML, OpenID, OpenID Connect, OAuth, BrowserId), we are absolutely con- vinced that an approach like PrOfESSOS is the best solution for reaching the required security level that a critical component like an SSO library needs. PrOfESSOS is not designed for large-scale studies, since we expect that imple- mentation issues still exist. Instead, we are collaborating with the OAuth and OpenID Connect working group to include PrOfESSOS in their certification process. If big companies such as Google or Microsoft follow this, the overall security of their SPs will be significantly improved.
Fixing the OpenID Connect Specification After discovering the IdP Con- fusion and Malicious Endpoints Attacks, we promptly contacted the OpenID Connect working group in October 2014. Unfortunately, they did not respond and even a second and third attempt failed. In November 2015, we were then contacted by the IETF OAuth working group because our attacks could be applied to the OAuth protocol as well (parallel work of a different research group [45]). We were invited to a special security meeting in which we discussed different mitigation techniques and helped the working groups to create an update for the OAuth as well as the OpenID Connect specification [73]. In general, the reason for the authentication issues is the missing connection across all phases, which leads to confusion at the SP side. To mitigate the attacks, a parameter linking the phases was added. In Phase 2, by adding the issuer parameter in addition to the code parameter (see Step 2.4 in Figure 6.3), the SP knows to which IdP the code must be sent in Phase 3. Summarized, the issuer parameter must be provided in Phase 1 during the Discovery, Phase 2 as a mitigation against the reported Cross-Phase Attacks, and Phase 3 within the id token. This way, the Cross-Phase Attack can be detected and the leakage of valid authentication tokens can be prevented at the SP side.
69
7 Attacks on OpenID
OpenID was standardized in 2007 by the OpenID Foundation. The main goal of the protocol is to be open as possible by adding new components to the standard Single Sign-On (SSO) information flow and thus providing an auto- mated approach for trust establishment between the Service Provider (SP) and Identity Provider (IdP) on-the-fly. Some of these components were adapted by OpenID Connect and OAuth Authorization Framework 2.0 (OAuth). OpenID introduces two new phases: Discovery and Association. These are similar to the Discovery and Dynamic Registration in OpenID Connect. But, in comparison to OpenID Connect, the Discovery phase is part of the core protocol and thus not optional. With respect to the security, the support of the Discovery phase means that an attacker can easily force the SP to use a malicious IdP. Thus, the SP must explicitly restrict the usage of arbitrary IdPs. During our research, we successfully applied the concept of malicious IdP to analyze OpenID and developed six new attack classes on OpenID, which are summarized in Table 7.1 and assigned to a generic attack class, Attacker Type (AT), impact, target, and complexity.
Attack Class Generic Attacker Category Target Complexity Attack Type ID Spoofing IA AT1+ Cat B SP Single-Phase Wrong Recipient WR AT2 Cat A SP Single-Phase Replay Attack RA AT2 Cat A SP Single-Phase Key Confusion SB AT1+ Cat B SP Single-Phase XXEA MS AT1 Cat C SP Single-Phase Key Confusion SB AT1+ Cat B SP Cross-Phase
Cat A – Attacker gets access to one victim’s account. Cat B – Attacker gets access to all accounts. Cat C – Attacker gets access to system files. AT1 – Message Generation. AT1+ – Message Generation + malicious IdP. AT2 – Access to Valid Token. AT3 – Classic Web Attacker.
Table 7.1: Overview of the attacks on OpenID described in this chapter.
In addition, we provided an analysis of 17 OpenID implementations and find 12 of these vulnerable against al least one attack. We extended our research on websites using OpenID for authentication and reveal security issues on 26% of them. We address the automated security analysis of OpenID by our pentesting tool called OpenID Attacker. In this chapter, we first introduce the OpenID protocol in Section 7.1. In Section 7.2 and Section 7.3 we describe the attacks shown in Table 7.1 and
71 address a proper countermeasure for each of them. The results of our evaluation on existing libraries and websites is presented and discussed in Section 7.4. We introduce our tool for automated analysis, OpenID Attacker, in Section 7.5 and describe the design and challenges addressed by the tool. We conclude with Section 7.6.
7.1 OpenID Basics
In this section, we introduce the OpenID protocol flow and all relevant messages needed to understand the presented attacks.
7.1.1 Core Protocol Flow In Figure 7.1 we give a detailed description of the OpenID protocol flow in- cluding all phases: Phase 1 – Discovery and Association, Phase 2 – End-User authentication at the IdP, and Phase 3 – End-User authentication at the SP. These phases will be described further.
End-User UA Service Provider ID Server Identity Provider https://sp.com https://idp.com Phase 1.1: Discovery 1. Login attempt: IDEnd-User 1.1.1. Discovery Request: lookup IDEnd-User
1.1.2. Discovery Response: URLIdP
Phase 1.2: Association (Optional) 1.2.1. Association Request: dh_modulus, dh_gen, dh_consumer_public 1.2.2. Association Response: assoc_handle, dh_server_public, enc_mac_key
In Step 1, an End-User visits an SP and starts the authentication by select- ing an IdP or entering his identity. An example of two different login pages supporting OpenID authentication is depicted in Figure 7.2.
Phase 1.1: Discovery Once the identity is entered, the SP starts the Dis- covery phase to estimate the corresponding IdP. For this purpose, the SP nor- malizes the entered identity and extracts the domain name of the IdP. For example, by entering the identity [email protected], the SP retrieves the URL https://idp.com. Then, the SP calls this URL and requests a document containing further information regarding the IdP. The document is stored on the ID Server, which is usually controlled by the IdP and deployed on the same
72 Figure 7.2: Login Window starting the OpenID authentication at an SP.
doman. In exceptional cases, the ID Server can run on an independent domain. These cases are considered out of scope for this thesis. In Step 1.1.2., the document is sent within the Discovery Response. Accord- ing to the OpenID specification, it can be a HTML or a XRDS document. An example of the HTML document is shown in Listing 7.1 and explained further.
1 2
3 4 5
6
Listing 7.1: An example of the HTML discovery document. The first link element in line 3 defines the URL of the IdP. In the given example, this is https://idp.com/. In row 4, additional information regarding the End-User’s identity at the IdP is contained. This identity, called local identity, is optional and must be verified by the IdP and contained within the authentication token. In the given example the local identity is https: //idp.com/bob. Alternatively, a XRDS document can be returned. An example is depicted in Listing 7.2.
Listing 7.2: An example of an XRDS discovery document. The XRDS document is an XML document containing the information of an IdP encapsulated in a Service element, see line 3. Similar to Listing 7.1, in line 5 the URL of the IdP is defined, and the local identity is included in line 6. The main advantage of the XRDS document is that it can contain multiple IdP URLs, which are prioritized. The SP can then choose one of these.
73 Phase 1.2: Trust Establishment/Association (optional) The trust establish- ment starts in Phase 1.2. This phase is basically a Diffie-Hellman key exchange between the SP and the IdP. First, the SP creates an asymmetric key pair (a private and a public key). Then, the SP generates a request containing the modulus (dh modulus), the generator (dh gen), and the computed public key (dh consumer public), which it sends to the IdP in Step 1.2.1. The IdP generates on the other side an asymmetric key pair and computes a Diffie-Hellman ses- sion key. Afterwards, the IdP generates randomly a secret key (mac key) used later for signing the authentication token. The IdP encrypts mac key with the Diffie-Hellman session key and stores the result in enc mac key. In addition, a random number referencing to the secret key is generated – assoc handle. The Association Response is sent by the IdP to the SP and contains the as- soc handle, the public key of the IdP (dh server public), and the encrypted secret key (enc mac key), see step 1.2.2. Once the SP receives the Association Response, it computes the Diffie-Hellmann session key, decrypts the symmetric key mac key and stores it together with the assoc handle.
Phase 2: Token Generation In Phase 2, the End-User is redirected to the IdP where he authenticates. First the SP generates and sends the AuthnReq to the IdP (see Step 2.1). The AuthnReq contains the following parameters1: • claimed id – contains the identity of the End-User entered in Step 1 by starting the SSO authentication. • identity – usually the value is equal to the value of claimed id. The only exception is in case that the ID Server is not under control of the IdP and is deployed on a different domain. This special case is considered out of scope and thus not explained further. • assoc handle – contains the value established in Phase 1.2. If the Associ- ation phase was skipped, the parameter is excluded from the AuthnReq. • return to – defines the URL of the SP where the authentication token will be sent to. Simultaneously, the URL represents the identity of the SP since it is unique. • sreg.required – the SP can request further information regarding the End- User such as email, gender or address. An example of an AuthnReq is given in Listing 7.3.
1Please note that we do not explain all specified parameters within the AuthnReq, but only these, which are relevant for the attacks.
74 Listing 7.3: An example of the AuthnReq generated by the SP and sent to the IdP via an HTTP Redirect.
Once the IdP receives the AuthnReq, it authenticates the End-User and gen- erates the authentication token. The authentication token is signed either with the key established during Phase 1.2 or with a freshly generated symmetric key that the IdP known only by the IdP. Finally, the authentication token is sent to the SP (see Step 2.1.3 ). After receiving the authentication token, the SP must verify it. But, before verifying the authentication token, the SP uses the claimed id parameter within the token and starts a Re-Discovery in Step 2.4. By this means, the SP ensures that the previously discovered IdP is the same IdP issuing the authentication token. As a result, the SP loads the information of the re-discovered IdP like key material and URLs of the IdP. Consequen- tially, the SP can either verify the authentication token with the secret key established during the Association (Phase 1.2) and referenced by assoc handle or start Phase 3.
Phase 3: Token Redemption In Step 3.1, the SP sends the received authenti- cation token to the IdP for verification. In case that the authentication token is valid, the IdP returns the result in Step 3.2 and SP authenticates the End-User by using the identity parameter.
7.1.2 OpenID Token An example of an OpenID token containing the information of the authenticated End-User is shown in Listing 7.4 and explained further.
Listing 7.4: An example of the OpenID Token generated by the SP and sent to the IdP via an HTTP Redirect.
Identity of the End-User The identity of the End-User is represented by both parameters – claimed id and identity. These are represented by an URL and in
75 most cases equal. Special cases where the values differ from each other are not relevant for the introduced attacks and thus will not be explained further. Further parameters regarding the identity of the End-User can be contained in the token via extensions. Such extensions are defined by the OpenID specifi- cation and can be requested by the SP. For example parameters like sreg.email and sreg.fullname provide such additional information.
Identity of the IdP The mandatory parameter op endpoint defines the IdP issuing the authentication token.
Timestamps and Freshness The OpenID token contains one parameter con- taining a timestamp and optionally a nonce. Noteworthy is the fact that only the creation time of the token is specified, but not its expiration.
Audience restrictions The recipient of the authentication token is restricted by the parameter return to, which points to the URL of the SP where the authentication token is sent to. The value is taken from the AuthnReq and included in the token.
Key Material and Signature The following parameters are related to the integrity protection of the authentication token. • assoc handle – contains a pointer to the used secret key used for verifica- tion by the SP. • sig – contains a base64 encoded byte array of the computed signature. • signed – contains a list of all parameters protected by the signature.
7.2 Single-Phase Attacks
In this section, we introduce five attack classes assigned to Single-Phase Attacks and explain these further. The introduced ID Spoofing (IDS), Key Confusion (KC), and XXEA attacks are novel in the context of OpenID.
7.2.1 ID Spoofing (IDS) IDS is a novel attack class tricking the SP to login the attacker in arbitrary accounts without any End-User interaction. The idea of IDS is first to enforce the SP to use a malicious IdP for authentication. Then, the malicious IdP issues maliciously crafted tokens containing identities controlled by other IdPs like Google or Yahoo. The OpenID specification addresses this problem and specifies steps detecting such misbehavior. If the SP skips these verification steps or implements them wrong, the attacker can login in any account at the SP by using his malicious IdP.
Requirements The attacker does not need any interaction with the victim or an honest IdP. The attacker forces the SP to use the malicious IdP that creates
76 malicious authentication tokens. The IDS attack is assigned to AT1+ since the attacker only needs to generate arbitrary messages by using his malicious IdP.
Exploit In OpenID the End-User’s identity is represented by a URL, which is controlled by exactly one IdP. In the given example in Listing 7.4 this is https://idp.com/bob, which belongs to the IdP hosted at https://idp.com. The IdP can issue statements only for identities bound to this domain. Strategy 1: A malicious IdP, hosted at https://attackerIdP.com, can how- ever break this rule and issue a token containing an identity parameter set to an identity controlled by other IdP, e.g., https://idp.com/bob. An example is shown in Listing 7.5.
Listing 7.5: An example of the malicious authentication token generated by the malicious IdP (https://attackerIdP.com) and containing the identity of the victim controlled by other IdP (https://idp.com/ bob).
If the SP receiving the malicious token accepts the token, then it is vulnerable against IDS. Strategy 2: The ID Server used during the Discovery and Re-Discovery re- turns the URL of the IdP responsible for the entered identity. Moreover, the ID Server can return a local identity containing the identity of the End-User at the IdP, see Listing 7.1 and Listing 7.2. The protocol flow of an IDS attack using the ID Server is depicted in Figure 7.3 and explained further. To execute the attack, the attacker starts the authentication at the SP with the malicious IdP. The malicious IdP acts honestly and creates a valid authentication token containing the identity of the attacker. During the re- discovery phase (Phase 2, step 2.5) the malicious IdP changes the local identity within the discovery document and sets the value to victim’s identity, e.g., https://idp.com/bob. Consequentially, the SP verifies the authentication token, which is valid. However, in case that the SP uses the returned value during the re-discovery for authentication and ignores the value within the authentication token, the SP
77 Attacker UA Service Provider ID Server Attacker Identity Provider https://sp.com https://attackerIdP.com
Figure 7.3: IDS started within the discovery document returned in Phase 3. processes the wrong identity and the attacker becomes access to the victim’s account. Strategy 3: Another approach to carry out IDS is to spoof the email pa- rameter within the authentication token pointing to the email address of the victim, e.g., bob@idp.com. Some SPs ignore the identity parameter within the authentication token and process the email-address to authenticate the End- User. Unfortunately, OpenID does not provide any mechanisms to verify the correctness of the additional parameters. Thus, a malicious IdP can issue a valid authentication token containing valid identity parameter, but the email of the victim. In this case, it is impossible for the SP to detect the attack since OpenID does not provide any mechanisms providing the validity of the email address. As a result, the attack can log in at the SP in any account.
Impact Since the attacker does not need any interaction with the victim and still can log in at any account at the SP, we categorize the attack to Cat B.
Countermeasure According to the specification [113, Section 11.2], an SP should start a Re-Discovery on the identity within the received token (step 2.4 in Figure 7.1). Thus, the SP can recognize that the entered identity in the first step differs from the identity contained in the authentication token. Moreover, the SP loads the key material of the re-discovered IdP. Thus, the signature created by the malicious IdP is not valid and the authentication token will be rejected.
7.2.2 Key Confusion (KC) KC introduces a novel class of attacks enforcing the SP to use wrong key mate- rial to verify the authentication token. The enforced key is a valid key shared between the SP and the malicious IdP. But, the SP is convinced that this key belongs to other (honest) IdP. The attack belongs to the generic attacks of Signature Bypasses since it circumvents the integrity protection of the authen- tication token and circumvents the security of the Verificator module.
78 Requirements The KC attacks requires a malicious IdP issuing malicious to- kens. No interaction with the victim is needed. Thus, we refer this attack to AT1+ – message generation with malicious IdP.
Exploit To carry out KC, the attacker may follow the following strategy. Strategy 1. Overwriting the secret key handle of an honest IdP. In OpenID the key material established during the Association Phase is referenced by the association handle (assoc handle)– α. The value of α is set by the IdP and is public. Thus, a malicious IdP can establish an association handle with the SP with the same value α and overwrite the stored key material with its own. As a result, the SP will verify an authentication token with the wrong key. Strategy 2. Attacker’s own association handle for signature verification. The association handle is included in the authentication token issued by the IdP. Multiple implementations tend to use this association handle to fetch the stored keys. However, a malicious IdP can issue a token containing the identity of an honest IdP and the identity of the victim, but reference to its own key. In other words, the SP verifying the token assumes that the token was issued by another IdP, but uses the key material exchanged with the malicious IdP.
Impact Bypassing the signature protection leads to total break of the secu- rity of the authentication, since the attacker can issue statements within the authentication token, which will be successfully verified and processed by the SP. As a result, the attacker can log in at any account on the SP – Cat B.
Countermeasure To prevent KC, the SP must ensure that the key material regarding one IdP cannot be overwritten by another IdP. This can be done by binding the association handle to the identity of the IdP during the establish- ment and use this binding to retrieve the corresponding key material. The countermeasure against the second strategy relies on the first counter- measure – the SP must use the association handle within the token with the contained IdP identity to fetch the corresponding key material. By this means, it can detect that the association handle within the authentication token does not correspond to the keys established with the honest IdP.
7.2.3 Token Recipient Confusion (TRC) The Token Recipient Confusion (TRC) attack belongs to the generic class of Wrong Recipient attacks. It targets the verification of the recipient contained in the authentication token and allows an attacker to use the token for one SP on a different SP. The idea of TRC is to force the End-User to click on a link and leak the issued token on a domain controlled by the attacker. In comparison to OpenID Connect and SAML, where the attack can be detected by the IdP (since it knows which URLs are allowed for the requested SP), in OpenID such a validation is not possible because the SP do not register its URL at any point of the protocol flow. In other words, the attack can be detected only by the SP.
79 Requirements The TRC attack requires an interaction with the victim by forcing him to click on a link. Thus, we assign this attack to AT3.
Exploit To exploit the vulnerability the attacker sets up a website, e.g., https: //attacker.com, where the stolen authentication tokens will be collected. Then, the attacker prepares a maliciously crafted AuthnReq containing all required OpenID parameters. In addition, the value of return to parameter is set to the attacker’s website, in our case https://attacker.com. Consequentially, the attacker forces an End-User to click on link and to send the crated Authn- Req through his user agent (UA). In case that the End-User is already authen- ticated at the IdP, the authentication token is generated directly and sent to the attacker’s website. Finally, the attacker downloads the collected token and sends it through his UA. In case that the SP does not verify the return to pa- rameter within the authentication token, which points to the attacker’s website, the attacker gets access to the End-User’s account.
Impact Since the attacker get access only to one account, we refer the attack to Cat A.
Countermeasure The countermeasure against this attack is quite simple – the SP must validate the return to parameter within the token and verify that the stated URL is equal to its own URL.
7.2.4 Replay Attack (RA) The only parameter in OpenID containing simultaneously a timestamp and a nonce is response nonce. It contains the date time when the token was created and optionally a nonce, which is appended. Interestingly, there is not parameter limiting the lifetime of the authentication token. Thus, each SP must define its own policy defining how long the token should be valid. In addition, the lifetime of a token is limited by the lifetime of the association handle and the corresponding key material. According to our investigation, the lifetime of the key material is between 4 hours (Yahoo) and 14 days (MyOpenID). The idea of the attack is to re-use a token multiple times and for a long (infinite) period.
Requirements The attack requires the possession of a valid token issued by an honest IdP – AT2. Note that the attacker cannot change any values within the token, since it is signed by the honest IdP.
Exploit The attacker sends repeatedly a token to a SP and verifies if the login was successful or not.
Impact The impact of the attack is limited by the fact that the attacker cannot compromise any other accounts, but only the account stated within the authentication token – Cat A.
80 Countermeasure The proper countermeasure against Replay Attacks is to val- idate the response nonce parameter and define a reasonable lifetime limitation of the authentication token.
7.2.5 XML External Entity Attack (XXEA) In OpenID there is only one eXtended Markup Language (XML) message, which can be used to carry out XXEAs – the XRDS document in the Discovery phase. The idea of the XXEA is that an attacker enforces the SP to use the malicious IdP, which returns in the Discovery maliciously crafted XRDS document con- taining Document Type Definitions (DTDs). If vulnerable, the SP parses the XML document and processes the defined DTDs. Note that the malicious IdP does not have to process the AuthnReq or to issue any token.
Requirements To start XXEA, the attacker has to create an XML message containing a DTD. In addition, this message can be sent only by an IdP within the discovery phase. Thus we refer this attack to AT1+. Note that the message does not has to be a valid XRDS document.
Exploit Different exploits and attack techniques are shown in Section 5.2.6.1 and 5.2.6.2.
Impact The XXEA is a Cat C attack assigned to AT1+ allowing the attacker to access files stored on the server.
Countermeasure The attack targets the SSO Parser in Figure 5.2. To pro- hibit XXEA, the processing of DTDs should be disabled since it is not needed for OpenID. In addition, XML Schema [114] can be used to verify the structure of XML messages.
7.3 Cross-Phase Attacks
In this section, we present one Cross-Phase Attack bypassing the signature protection of the authentication token.
7.3.1 Key Confusion (KC) In addition to the previously described KC attack, we developed a novel ap- proach to enforce the usage of the wrong key material. We use the Discovery phase to overwrite the information regarding the current IdP, prevent a re- discovery and thus confuse the SP to load the keys shared with the malicious IdP.
Requirements The requirements are the same as previously described for KC strategy 1 – the attacker uses his malicious IdP. Thus, we refer this attack to Attacker Type AT1+.
81 Exploit The exploit is more complex than KC strategy 1, since it requires multiple interactions with the SP in different phases. The attack is depicted in Figure 7.4. In the first step the attacker enters his identity at the malicious
Attacker UA Service Provider ID Server Attacker Identity Provider https://sp.com https://attackerIdP.com https://attackerIdP.com
Figure 7.4: KC attack: Before the authentication token is forwarded in Step 3.2, the attacker starts a second login request with victim’s identity on the honest IdP (https://idp.com). This action overwrites the information stored in $ SESSION regarding the responsible IdP and prevents the re-discovery.
IdP. Consequentially, the SP starts the Discovery and stores the retrieved infor- mation – the identity of the IdP, which is a URL, and the local identity, which is expected within the authentication token. The SP stores this information in a $ SESSION variable and uses it later during the token verification. By storing the discovered values in a variable, the SP can skip the Re-Discovery in Phase 3. Unfortunately, we can overwrite this information and use this for confusing the SP. In Phase 1.2 (the Association), the SP establishes a key β with the malicious IdP. In Phase 2 the SP redirects the attacker to the malicious IdP, which processes the AuthnReq. The authentication of the attacker at his malicious IdP can be skipped since this is not needed. Consequentially, the authentication token containing the identities of the IdP and the victim are issued by the IdP. Now, the malicious IdP postpones the transmission of the token to the SP. The reason is that the discovered information stored in the $ SESSION variable does not correspond to the information within the authentication token. In that case, the SP will determine the mismatch, start the Re-Discovery, and load the proper key material. To prevent this, the attacker must prevent the Re- Discovery phase by overwriting the $ SESSION variable to match the information within the authentication token. To make this happen, the attacker starts a new login attempt at the SP by
82 entering the identity of the victim (see Step 3.1). Consequentially, the SP starts the Discovery and replaces the information stored in the $ SESSION variable. Now, the values do not differ from the values within the authentication token and no Re-Discovery will be executed. In Step 3.2, the attacker forwards the postponed token, which must be verified. 1. The SP ensures that the discovered IdP is equal to the IdP stated in the token. 2. The SP verifies that the discovered identity is equal with the one stated in the token. 3. The SP believes that it communicates with the right IdP and loads the key material by using the association handle β. Unfortunately, β is the key shared between the SP and the malicious IdP. As a result of the attack, the SP verifies with the wrong keys believing that it communicates with the honest IdP (https://idp.com). Consequentially, the SP processes the identity within the token permits the access to the victim’s account.
Impact The impact of the attack is Cat B since the attacker can log in at any account on the SP.
Countermeasure The countermeasure described previously, addressing the binding between the association handle and the IdP’s identity to tech the cor- responding key material, will mitigate this attack too.
7.4 Evaluation
In this section, we present the results of our evaluation on existing implementa- tions. First, we explain the methodology for the SP selection and the analyzing approach. Then, we present and discuss the results.
Selection Methodology and Setup First, we selected 15 open source imple- mentations referenced on the official OpenID website. Considering the entire list, we covered every available language including .NET, C++, ColdFusion, Java, JavaScript, Perl, PHP, Python and Ruby. In addition, we added Drupal and Sourceforge since both products are widely used and show the applicability of the attacks on real-world and in production used implementations. Before testing, we deployed each implementation on a virtual web server. For Sourceforge, we tested the website. Afterwards, we registered two accounts on each SP– one controlled by the victim by using an honest IdP and one controlled by the attacker by using the malicious IdP. During each registration, we used different UAs. The attacker’s account is needed to verify the correct functionality of the malicious IdP. Initially, we started with a White-Box analysis using the malicious IdP. This allowed us to develop different attack classes and strategies. We extended our analysis with a Black-Box approach, mostly on websites where the source code is not available. Black-Box analysis is more challenging since not all messages
83 can be observed and only the reaction of the system, but not the cause for the reaction, can be seen. To better understand the target system, we system- atically varied different parameters in each phase. Thus, supported features, required and optional parameters were determined and documented. Moreover, some parameters were removed or set to values deviating from the normal IdP behavior. We summarized all possible tests, categorized and assigned these to an attack class and systematically executed the tests by documenting the results.
Results In Table 7.2 the results of our evaluation are summarized: 12 of 17 implementations are vulnerable at least to one attack breaking the End-User authentication. Surprisingly large is the number of IDS vulnerabilities – 8 of 17. The result can be explained by the fact that the concept of a malicious IdP is barely studied and known. Thus, in many of the implementations important verification steps checking the statements made by an IdP were skipped resulting in a security gap. Three SPs were vulnerable to KC – Drupal, Zend Framework and Source- forge. Zend Framework is susceptible to KC strategy 1, and Drupal to strategy 2. Interestingly, we discovered the IDS on Sourceforge, which was reported and fixed. Unfortunately, a KC vulnerability still existed since only the as- sociation handle within the authentication token was used to retrieve the key material. We promptly reported our findings and proposed a fix, which was accepted and implemented by the developers of Sourceforge. Surprisingly high is the number of TRC attacks – 6 of 17. We did not expect this result, since the generic attack class Wrong Recipient is known and the OpenID specification clearly address the validation of the return to parameter. One year after our initial evaluation we extended our analysis on websites. The first challenge we addressed was the collection of websites using OpenID for authentication. Since there is not central database or a publicly available list summarizing all existing implementations, we elaborated techniques facilitating the searching process:
• Based on the protocol semantics we defined search terms like inurl: openid.claimed id and openid.identity. Thus, OpenID AuthnReqs and AuthnResponses can be identified. As a result all URLs containing these parameters, will be shown.
• We observed that many implementations start the OpenID protocol by sending the term login?openid. By using this term, we identified most of the target websites.
• We used our searching queries with different searching engines like Google, Bing and Yahoo. However, this approach did not lead to the discovery of any new SPs.
• Knowing the source code of the libraries we used the search engine Nerdy- Data, which analyses the source code of websites. Thus, we were able to
84 Service Provider Program- IDS KC TRC Summary: ming Unauthorized Language Access CF OpenID ColdFusion X Vuln.* Vuln.* Vuln. DotNet OpenAuth NET˙ X X X X Drupal 6 / Drupal 7 PHP X X Vuln.* Vuln.* dyuproject Java X Vuln.* Vuln.* Vuln. janrain PHP, Python, X X X X Ruby JIRA OpenID Plugin Java X X Vuln.* Vuln.* JOID Java X Vuln.* Vuln.* Vuln. JOpenID Java X X Vuln.* Vuln.* libopkele (Apache C++ X X X X mod auth openid) LightOpenID PHP X X X X Perl X X Vuln. Net::OpenID::Consumer Vuln. OpenID 4 Java Java X X X X (WSO2) OpenID CFC ColdFusion X X Vuln.* Vuln.* OpenID for Node.js JavaScript/N- X X Vuln. (everyauth, Passport) odeJS Vuln. Simple OpenID PHP PHP X Vuln.* Class (ownCloud 5) Vuln.* Vuln. Sourceforge n.a. X Vuln.* Vuln.* Vuln.* Zend Framework PHP X X Vuln.* (OpenID Component) Vuln.* Total 8 3 6 12 / 17
Vuln.*: All accounts on the target are compromised. Vuln.: One account on the target is compromised. X: Secure/Attack fails.
Table 7.2: Practical evaluation results: unauthorized access on 12 out of 17 targets. We compromised 2 targets relying on AT3. The other 10 targets make use of a weaker variant – AT1 – and do not require any user interaction.
identify some of the libraries shown in Table 7.2, which were deployed and used in web applications.
All in all, we found 137 websites using OpenID for authentication. First, we identified the possibility to use a malicious IdP for security analysis. We excluded 49% of the websites due to the following problems:
• The website does not support public End-User registration, which disables the possibility to register any test accounts.
85 • Faulty implementation of the OpenID protocol. Some SPs start the au- thentication with an IdP, but break the process due to an exception. Even the usage of honest and widely used IdP like Google was not possible.
• The website restricts the usage of specific IdPs and prevents the usage of our malicious IdP.
• False positives by containing openid parameters within the HTTP re- quests or HTML document, but not offering any OpenID authentication.
As a result 70 of 137 websites support OpenID and the usage of a malicious IdP. The results are depicted in Figure 7.5. 26% of the evaluated websites (18
Vulnerable: IDS 16%
51% 49% 26% Tests with 67% 67% 6% OpenID tests vulnerable OpenID Attacker Not vulnerableNot vulnerable Vulnerable: KC not possible possible 7% 11%
Vulnerable: TRC
Fixed library
Figure 7.5: Statistics of our online website evaluation.
of 70) were vulnerable at least to one attack. On 16% (11 of 70) IDS was appli- cable, four were vulnerable to KC (6%) and 16% to TRC. The lower number of vulnerable websites (26%) in comparison to the evaluated libraries lies on the fact that many of the websites (41%) use the JanRain library. This library is not vulnerable against IDS, KC or TRC. The wide usage of the JanRain library can be explained by the fact that it supports many SSO protocols like OAuth, Facebook Connect, OpenID and OpenID Connect.
Additional Findings The OpenID specification requires that the following pa- rameters are signed: op endpoint, return to, response nonce, assoc handle, claimed id, and identity. Four of the evaluated libraries accepted tokens in which some the parameters are not signed enabling the forgery of the authen- tication token. Additionally, we determined that 2 of 17 libraries allow the execution of XML entities. In addition, we tested Slashdot and identified serious XXE vulnera- bilities. Interestingly, most of the implementations do not use an XML parser to process an XRDS document, but regular expressions. Thus, XXEA was not possible in these cases.
7.5 Automated Analysis
In this section we, introduce OpenID Attacker – our approach for fully auto- mated analysis of OpenID implementations. OpenID Attacker acts as a mali- cious IdP and offers a Graphical User Interface (GUI) to facilitate the config- uration and attack execution. Thus, it can operate in all three phases of the
86 OpenID protocol flow. OpenID Attacker should be reachable on the Internet since it acts as a malicious IdP, which must be reached by the SP. In Figure 7.6 we present OpenID Attacker’s operation modes – analysis, manual and fully automatic. Analysis Mode
OpenID Version Required Messages Required Parameters
Normal Flow
Manual Attack Mode Fully Automatic Attack Mode Manipulate Arbitrary Message Load Attack Class Create Malicious Token Execute Attack Observe Result
Analayse Result AttackNext Store Result
Output Security Report
Figure 7.6: OpenID Attacker offers three operation modes – analysis, manual and automatic mode.
Analysis Mode In this mode OpenID Attacker is used to determine as much as possible information regarding the authentication flow. For this purpose, it acts as an honest IdP issuing valid tokens without executing any attacks. The gathered information includes the OpenID version, required messages and parameters. For instance, one SP can require information regarding the gender of the End-User by requesting the according parameter to be send. Another SP can request a different parameter like the email address. Another example is the support of the association phase, which is optional. Thus, the authentication flow and the exchanged messages can vary. OpenID Attacker gathers all needed information during this phase and returns as a result the information needed for a normal flow including the supported features by the SP.
Manual Attack Mode In this mode OpenID Attacker acts as a malicious IdP manually navigated by the attacker. In other words, the attacker changes manually the pre-configured honest values to malicious ones. Thus, known and new attack vectors can be loaded and different attacks can be started.
87 The idea behind the Manual Mode is the fact that new attack vectors can be specified and evaluated. This is an important and wanted feature guaranteeing flexibility during the security analysis. Another advantage is the possibility to better understand the reaction and sometimes the source code of the targeted implementation by varying the values of different parameters. We used this mode to discover the IDS, KC, and TRC attacks during our white-box analysis.
Fully Automatic Attack Mode In this mode OpenID Attacker acts fully au- tomated. In Figure 7.7 the GUI of OpenID Attacker’s automated analysis is shown.
Figure 7.7: Graphical Interface of OpenID Attacker.
The main difference from the previous mode is that OpenID Attacker is reachable on two different domains – one used by the malicious IdP and one simulating an honestly acting IdP. In other words, we can analyze the com- munication with an honest and a malicious IdP, which gives us a very good overview of the processes happening at the SP. The execution in this mode consists of two parts: (1) training and (2) attack execution. During the training the malicious IdP estimates the normal behavior of the SP. This process is very similar to the one executed in analysis mode. The main difference is that the login flow is started multiple times: 1. logins with the honest IdP simulating a login attempt initiated by the victim, 2. logins with the malicious IdP simulating the attacker learning the authentication flow at the SP and verifying that the malicious IdP can be used, and 3. invalid logins leading to error in the authentication at the SP. As a result, OpenID Attacker is trained to make difference between the final state of the authentication and can determine if a login was successful or led to an error. Moreover, OpenID Attacker can estimate in which account we are logged in – attacker’s or victim’s. At the end, OpenID Attacker knows the behavior of the SP as well as its final
88 states (authenticated as the attacker, authenticated as the victim, error). Thus, it can proceed with the attack execution. To automate the training and attack execution process we use Selenium, which simulates an UA, e.g., Firefox, and can fill out input fields, execute click events and submit entered data automatically without any interaction. OpenID Attacker loads the training results and all known attacks. The attacker can select one specific attack to be performed or to sequentially execute all attacks.
Report In conclusion, OpenID Attacker summarizes the results in a report, which can be exported as an HTML document, see Figure 7.8
Figure 7.8: Security report generated by OpenID Attacker summarizing the re- sults of the executed attacks.
By clicking on the Show Log hyperlink, more detailed overview of the exe- cuted attack, the exchanged messages and results is presented.
7.6 Summary
In this section, we introduced the OpenID protocol including all phases and exchanged messages. We introduced 5 attacks – IDS, TRC, Replay Attack, KC, and XXEA – and described the idea, requirements, impact and countermeasure for each of them. Four of these attacks are novel in the context of OpenID and were not considered so far during security evaluations. We discovered and evaluated the attacks by using our malicious IdP concept, which was the starting point for the analysis. We successfully applied our attacks on existing OpenID libraries and found 12 of 17 vulnerable. In addition, we analyzed websites supporting OpenID and discovered security issues on 26% of them. We responsible disclosed the vulnerabilities and supported the developers fixing the issues. Finally, we im- plemented a fully automated penetration testing tool called OpenID Attacker capable to analyze OpenID implementations. We published OpenID Attacker as open-source on GitHub [77].
89
8 Attacks on SAML
The successor of SAML 1.1, SAML 2.0, was released by OASIS in March 2005 [104]. One of the main improvements made in the new version is the specification of different flows used for authentication in the web by using a user agent (UA). In our research, we carefully analyzed SAML, the exchanged messages and their processing and developed new attacks or extended existing ones. As a result of our analysis, we identified serious vulnerabilities targeting Service Providers (SPs) and Identity Providers (IdPs), which we summarized in different attack classes shown in Table 8.1
Attack Class Generic Attacker Impact Target Complexity Attack Type TRC WR AT2 Cat A SP Single-Phase Replay Attack RA AT2 Cat A SP Single-Phase Signature Exclusion SB AT1 Cat B SP,IdP* Single-Phase Certificate Faking SB AT1+ Cat B SP,IdP* Single-Phase XML Signature Wrapping SB AT2 Cat B SP,IdP* Single-Phase XXEA MS AT1 Cat C SP,IdP Single-Phase XSLT Attack MS AT1 Cat C SP,IdP Single-Phase ACS Spoofing CR AT3 Cat A IdP Single-Phase Certificate Injection SB AT3 Cat B SP Cross-Phase
Cat A – Attacker gets access to one victim’s account. Cat B – Attacker gets access to all accounts. Cat C – Attacker gets access to system files. AT1 – Message Generation. AT1+ – Message Generation + malicious IdP. AT2 – Access to Valid Token. AT3 – Classic Web Attacker. IdP* – Only if the AuthnReq is signed.
Table 8.1: Overview of the attacks on SAML described in this chapter.
In this section, we introduce and describe in detail 9 different attack classes bypassing the security of the target provider and categorize these to a one generic class attack, Attacker Type (AT), impact, target and complexity. In addition, we provide a comprehensive evaluation of existing SP and IdP imple- mentations. The results are surprising since 20 of 22 SPs are susceptible against at least one attack. On the other side, the security of all evaluated IdPs can be bypassed too affecting all SPs using these IdPs. We address the existing security problems by our two tools, ACS-Scanner and SAML-Attacker, which enable the security analysis of SAML implementations. In this section, we first introduce in Section 8.1 the SAML protocol and describe relevant messages and their structure and relevant security parameters. In Section 8.2 we describe 8 different Single-Phase Attacks and in section one
91 attack assigned to the Cross-Phase Attacks. In Section 8.4 we discuss the results of our evaluation and present the possibility of an automated analysis in Section 8.5. We summarize the results of our research in Section 8.6.
8.1 SAML Basics
In this section, we introduce the SAML protocol flow, all relevant messages – the SAMLRequest and SAMLResponse.
8.1.1 Core Protocol Flow In Figure 8.1 the End-User starts a login attempt at the SP is initiated by the End-User. In the following Step 2.1 the SP generates the AuthnReq containing the following two parameters: SAMLRequest and optionally RelayState. The
End-User UA Service Provider Identity Provider https://sp.com https://idp.com
Figure 8.1: The protocol flow in SAML depicting Phase 2 and Phase 3.
SAMLRequest is an eXtended Markup Language (XML) message containing the following parameters: • ID: A unique string guaranteeing freshness. • Issuer: A unique identifier of the SP. • IssueInstant: A Timestamp when the SAMLRequest was generated. • AssertionConsumerServiceURL (optional): A URL defining where the AuthnResponse is sent by the IdP. • Signature (optional): A digital signature protecting the integrity and authenticity of the SAMLRequest (or parts of it). An example of a SAMLRequest is shown in Listing 8.1.
1 8 https://sp.com/ 9
Listing 8.1: Example of a SAML AuthnReq issued by the SP and sent to the IdP.
92 In addition, the AuthnReq can contain the RelayState parameter, which is passed through by the IdP back to the SP and called by the SP after the successful End-User authentication. Usually, the RelayState parameter points to the initial URL navigated by the End-User at the SP before starting the Single Sign-On (SSO) authentication. In Step 2.2, the IdP authenticates the End-User and issues the AuthnRe- sponse, which is sent back to the SP in Step 2.3. The AuthnResponse contains as parameter the SAMLResponse and optionally the RelayState from the Auth- nReq. The content of the SAMLResponse is discussed further in subsection 8.1.2. After receiving the AuthnResponse, the SP verifies it and logs in the End-User.
8.1.2 SAMLResponse On a logical level, the SAMLResponse always contains certain information, re- gardless of the actual SSO mechanism. These contents are shown in Figure 8.2 and defined as follows: saml:Response
saml:Assertion ID=111
saml:Subject Bob saml:Conditions timestamps
recipient=SA
saml:Signature Ref=111 ds:Key
Figure 8.2: An overview of a SAMLResponse
• The identity representing the End-User is stored in the element Sub- ject within the Assertion element [104, Section 2.4.1]. Typically, this is an email address to uniquely identify the End-User. In comparison to OpenID Connect and OpenID, only one parameter is needed to authen- ticate the End-User. • Freshness is used to limit the usage of the token. This can be in the form of a nonce so that the token can only be used once, a timestamp which restricts the usage to a specific time slot, or a combination of both nonce and timestamp. The SAML tokens analyzed for this study usually contain timestamp elements NotOnOrAfter and NotBefore [104, Section 2.5.1] within the Conditions. As a further freshness parameter, the unique ID [104, Section 1.3.4] of the Response and Assertion are used as a nonce. • The Destination is contained in the token to restrict the usage to a specific SP. The value is typically represented by the AudienceRestric- tion [104, Section 2.5.1] and Recipient [104, Section 2.4.1] elements.
93 saml:Response saml:Response
saml:Assertion ID=111 saml:Assertion ID=111
saml:Subject saml:Subject Bob Bob saml:Conditions saml:Conditions timestamps timestamps
(a) SAML token with expired timestamps (b) SAML token addressed for service SA is sent to the SP. will be sent to Starget.
Figure 8.3: (a) and (b)
• To protect the token information, a Signature or HMAC (σ) is used. The IdP is the one to choose which information are protected by σ. SAML tokens use the XML Signature standard [55] to realize this protection: A Signature element is added to the Response. To determine the Assertion, σ belongs to, a Reference to the ID attribute of said Assertion is used in SAML context. The IdP uses its secret key k to generate σ. The corresponding public key is then included in a certificate which is stored at the SP. Note that there is no PKI connected to this certificate. The certificate contains just a public key plus some meta-information.
8.2 Single-Phase Attacks
In this section, we will introduce all attack classes identified during our analysis of the SP and IdP components. The attacks will be described considering the goal, requirements, impact and targeted authentication interface. For each attack class, we will give a short description of the attack background and the motivation for this type of attack. In addition, we list all capabilities required by an attacker to perform this type of attack, sketch a general approach towards an exploit, discuss the possible impact a successful attack of this type would entail and point out which specific component of the SP depicted in Figure 5.1 the attack is targeted at (and thus, which component would be required to take measures to prevent this type of attack).
8.2.1 Token Recipient Confusion (TRC) In real-life SSO there exist multiple SPs federating with the same IdP. 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.
94 The goal of TRC is to use an authentication token tA generated for a service SA (depicted in Figure 8.3 (b) with highlighted Recipient element) 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.
Requirements The attacker has access to valid tokens for SA – AT2). As in the previous two attacks, the attacker has access to a valid token. An addi- tional requirement is that both services (SA and Starget) must be federating with the same IdP. This is a realistic assumption, since an IdP usually offers authentication services for multiple SPs.
Exploit There are two different approaches for a TRC exploit: Exploit 1: Suppose that SPs SA and Starget are accepting tokens from the same IdP, and the attacker does not have access to Starget. The attacker does, however, have legitimate account on SA, thus he can request a token from the IdP. 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 his 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.
Impact TRC is classified as critical, since information disclosure or privilege escalation is possible [7]. A dishonest user can redeem his tokens at different services and get unauthorized access to restricted resources. Furthermore, a malicious SP could collect authentication tokens and forward them to other SPs in order to get login in arbitrary accounts.
Countermeasure TRC also targets the SSO Verificator, which is responsible for checking the restrictions regarding the destination of the token. In the SAML context, specifically the AudienceRestriction [104, Section 2.5.1] and Recipient [104, Section 2.4.1] elements are relevant for this attack type.
8.2.2 Replay Attack (RA) Every SSO protocol provides parameters to limit the reuse and lifetime of the authentication tokens. Considering that the reuse of tokens is optional [54, Sec- tion 6.4.4], the validation of the attributes providing freshness is not considered as critical.
95 On the other hand, the time restriction regarding the usage of authentication tokens is more critical and should be evaluated [54, Section 6.4.1]. Otherwise, tokens issued once might be valid for an extended time period or even an infinite amount of time [104, Section 2.5.1.2].
Requirements To start a Replay Attack the attacker needs access to a valid token (AT2). More specifically, the token in question is required to be valid for the 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.
Exploit To exploit a vulnerable application, the attacker sends an expired authentication token to the target SP, see Figure 8.3 (a). In case that the un- limited reuse of authentication tokens is applicable and the token is successfully verified, the attack is classified as successful.
Impact The attack’s impact is average, since the attacker has limited attack surface – he can only spend authentication tokens he possesses. However, the potential impact drastically rises in case the attacker gains hold of an authen- tication token granting him extended access rights (e.g., as an administrator of the system).
Countermeasure The attack specifically targets the SSO Verificator, see Fig- ure 5.1. This component should validate attributes providing the corresponding restrictions, i.e., the freshness parameter. In the SAML context relevant to this study, this parameter is represented by NotOnOrAfter and NotBefore [104, Sec- tion 2.5.1]. Failing to properly verify these parameters will enable this attack type. Another possibility to enable this attack type would be via additional freshness attributes, which are not part of the digital signature σ.
8.2.3 Signature Exclusion (∅Sig) The integrity of all authentication tokens is integrity protected. In case of SAML, this is realized by a digital signature σ = SIGIdP (t). Signature Exclu- sion (∅Sig) exploits a vulnerability in the verification logic allowing the usage of unsigned tokens, see Figure 8.4 (a).
Requirements The attacker does not need any resources, but only the capa- bility to generate XML messages – AT1.
Exploit To exploit the vulnerability, the attacker creates an authentication token containing statements about other End-Users and sends the token to an SP – AT1. As a result, the attacker is logged in with the corresponding identity.
96 saml:Response saml:Response
saml:Assertion ID=111 saml:Assertion ID=111
saml:Subject saml:Subject Bob Bob saml:Conditions saml:Conditions timestamps timestamps
recipient=SA recipient=SA
saml:Signature Ref=111 saml:Signature Ref=111 ds:Key ds:Key=evilCert (a) The SAML token does not contain any (b) The SAML token is signed with an un- signature. This means, no protection of trusted key. If the key stored in the to- integrity or authenticity is provided. ken is used for the verification without validating the trust relationship to it, Certificate Faking (CF) is applicable.
Figure 8.4: Signature Exclusion (a) and Certificate Faking (b)
The ∅Sig attack can be started on the AuthnReq if it signed. However, the im- pact is limited since no accounts can be compromised directly. But, an attacker can issue AuthnReqs in the name of other SPs and request more resources, which can be considered as a security gap.
Impact Since no digital signature for the token is required, an attacker can generate tokens containing arbitrary identities of other users. The impact of the attack is devastating since the attacker gains access to all accounts and their resources – Cat B.
Countermeasure The attack targets the integrity protection and especially the SSO Verificator (cf. Figure 5.1), which should require that the authen- tication token is signed and verify the applied signature. By this means, the integrity of the authentication token is guaranteed.
8.2.4 Certificate Faking (CF)
The cryptographic verification of the digital signature guarantees the integrity of the authentication token. Additionally, it is essential to verify the token’s authenticity, too (c.f. [54, Section 4.4.2]). In other words, the SP should check whether the token was signed by a trusted IdP. The CF 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, cf. Figure 8.4(b).
Requirements To run the attack, the attacker must be able to create SAML tokens and sign them with his own self-created key – AT1.
97 Exploit To exploit a vulnerability the attacker creates an authentication token. Then, he creates a secret key evilKey and a corresponding public key. The secret key is used to compute the digital signature σ = SIGevilKey(t). The attacker then uses his key pair to create a certificate evilCert containing the corresponding public key to verify σ. SAML uses the XML Signature standard that allows to store evilCert directly within the XML Signature as shown in Figure 8.4 (b). If the target SP uses evilCert to verify the signature σ (without prior check of the trust relationship for the corresponding key), the token will be accepted as valid.
Impact The impact of the attack is identical with the impact of ∅Sig – the attacker gains access to arbitrary accounts, since he can generate and sign valid tokens containing the identities of other End-Users. Thus, the attack’s impact is assigned to Cat B.
Countermeasure The attack targets the SSO Verificator (cf. Figure 5.1), which should verify that the authentication token is signed by a trusted third party instead of accepting any key provided with the token (although the XML Signature standard allows to include certificates, it is essential to verify whether it is a trusted certificate). This attack can be mitigated by manually deploying the trusted certificates to the corresponding SP and not using any certificates provided with the token.
8.2.5 XML Signature Wrapping (XSW) The idea of XML Signature Wrapping (XSW) [83] is to exploit the separation between SSO Verificator and SSO Processor (see Figure 5.1). In case both logics have different ”views” of the same document, XSW can be applicable.
Figure 8.5: The authentication token is signed for a user Bob. Via XSW the attacker can inject a second Assertion containing another identity (e.g., admin). The verification logic will verify the Assertion pointed by the Ref, which is valid. The business logic (SSO Processor) will process the injected (malicious) Assertion.
98 Requirements The attacker needs access to a valid token (AT2) and modifies the contents of the token by injecting malicious data without invalidating the signature. One example for this is shown in Figure 8.5. The goal is to force the SSO Verificator to use different elements than the SSO Processor. For the given example, the SSO Verificator will verify the signature based on the contents of the original Assertion, which is selected by ID. However, if the SSO Processor’s program logic automatically process the first Assertion found within the token, an attacker can bypass the integrity protection and enforce the processing of unverified data at the SP.
Exploit To exploit a vulnerable implementation the attacker manipulates his token by injecting malicious contents, for example, the identity of other users, see Figure 8.5. Multiple possibilities to apply XSW exist and a detailed study regarding this attack type was already published by Somorovsky et.al [110, 111].
Impact XSW allows an attacker to log into arbitrary user accounts and gain unauthorized access to their data – Cat B.
Countermeasure The attack targets the discrepancy in the program logic of SSO Verificator and SSO Processor. The latter should extract and forward only exactly the data verified by the former to Authorization & Access Management (AAM).
8.2.6 XML External Entity Attack (XXEA) The idea of the XXEA is shown in Figure 5.2. The attacker sends an XML doc- ument containing the attack vector and as a result he can read configuration and keystore files or start efficient Denial-of-Service (DoS) attacks. The vulner- able application parses the XML document and processes the defined Document Type Definition (DTD). The DTD contains an External Entity reading a re- source from the filesystem, in this case the /etc/passwd file, and sends the content to the attacker.
Requirements To start XXEA, the attacker only has to create a valid XML message containing a DTD – AT1. Note that the message does not has to be a SAML token (cf. Listing 5.1).
Exploit Different exploits and attack techniques are shown in Section 5.2.6.1 and Section 5.2.6.2.
Impact The XXEA is a Cat C attack assigned to AT1 allowing the attacker to access files stored on the server.
Countermeasure The attack targets the SSO Parser in Figure 5.2. To pro- hibit XXEA, the processing of DTDs should be disabled. XML Schema [114] can be used to verify the structure of XML messages.
99 8.2.7 XSLT Attack (XSLTA) Extensible Stylesheet Language Transformation (XSLT) is a language for trans- forming XML documents into other documents, for example, XML, HTML, JSON or even PDF [61]. The XML Signature standard allows the usage of XSLT by definition, and thus, XSLT can be used in SAML. XSLT is a turing-
saml:Response Bob saml:Signature Ref=111 XSLT Payload
Figure 8.6: XSLT Attack (XSLTA) payload that reads the /etc/passwd file and forwards its content to an attacker controlled server.
complete language [91]. By this means, it is possible to use XSLT, for example, to read/write files on the local filesystem and send them over the Internet. Furthermore, the XSLT transformation will be executed before the digital sig- nature is verified. Thus, an attacker can send a SAML token including a digital signature containing the XSLTA vector, but it is not required that the signature is valid.
Requirements The attacker needs the same resources as for XXEA. In com- parison to XXEA, the message has to be a SAML token. However, this token does not have to be signed with a valid key nor the signature needs to be valid. In other words, the attacks are assigned to AT1.
Exploit To exploit an XSLT vulnerability the attacker prepares a SAML token t and creates an XML Signature for it. Note that it is not important to have a correctly computed signature value – the XSLTA only requires a well-formed XML document. The attacker adds a Transform element to the XML Signature and places the XSLT payload in it as shown in Figure 8.6. The basic idea of the attack is similar to XXEA: First, the attacker reads an arbitrary file using XSLT (in this example by using the unparsed-text() function). Afterwards, he forwards the contents of the file to his own server via a GET parameter.
Impact Similar to the XXEA, XSLTA is a Cat C attack allowing the attacker to access files stored on the server.
Countermeasure The attack targets the SSO Verificator, cf. Figure 5.2. The SSO Verificator should mitigate the usage of XSLT within the token.
100 8.2.8 AssertionConsumerServiceURL Spoofing (ACS Spoofing) The AssertionConsumerServiceURL Spoofing (ACS Spoofing) attack belongs to the generic class of Covert Redirect attacks. ACS Spoofing addresses the URL validation within the AuthnReq at the IdP by enforcing the IdP to send ID Token (id token) to an arbitrary URL controlled by the attacker. Once the attacker has the authentication token, he can redeem it at the SP through his own UA. In SAML the parameter, which must be validated is the Asser- tionConsumerServiceURL (ACSURL). Similar to OpenID Connect, the URL is established during the registration phase of the SP at the IdP. By receiving an AuthnReq the IdP should strictly match the received URL within the AuthnReq with the registered one.
Requirements We assume that the victim clicks on a malicious link – AT2. In addition, we assume that the victim is already logged in at the IdP. Thus, the AuthnResponse is generated directly without prompting the victim to au- thenticate at the IdP.
Exploit To exploit a vulnerability at an IdP, the attacker must lure the victim to click on a malicious link or visit a malicious website – AT3. By clicking on the link, an HTTP request containing an AuthnReq with manipulated ACSURL will be sent to the IdP through End-User’s UA. In case that the End-User is already authenticated at the IdP, the AuthnResponse will be generated and sent to the ACSURL controlled by the attacker.
Impact The attack’s impact is limited by the fact that the victim must click on a link and only the authentication token of the victim can be stolen – Cat A.
Countermeasure Considering Figure 5.1, the SSO Verificator is the target of the attack, which must validate the ACSURL by comparing it with the registered one.
8.3 Cross-Phase Attacks
In this section, we introduce one Cross-Phase Attack bypassing the security of the verification logic in SAML by replacing information exchanged during the registration.
8.3.1 Certificate Injection (CInj) Usually, an SPs provide a Web interface allowing to activate and configure the SSO module. See Figure 8.7 for an example. This is a critical area and thus has to be well protected. During our research, we recognized that the security of the entire SSO module (Figure 5.1) depends on the security of the applied Web interface and the stored information in the AAM module (which includes, e.g., the IdP certificate used for verification). This observation led to the Certificate Injection (CInj) attack.
101 Figure 8.7: The SAML module is configured via the Web interface of the SP. The certificate of the trusted IdP and the according endpoints can be uploaded and stored in the AAM module.
The basic idea of CInj is to inject a malicious certificate and store it in the AAM module. Since the SSO module uses this certificate for the authentication 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 directly related to this module, can still be bypassed.
Requirements 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 webpage – AT3.
Exploit To apply CInj we used CSRF attacks to inject a malicious configura- tion regarding the SAML interface. In case that the target SP does not provide any CSRF protection, the attacker can enable and configure the SAML inter- face by injecting the malicious contents via a CSRF attack. As a result, he can remotely establish a trust relationship between the target SP and a malicious certificate, which does not belong to any trusted IdP. An actual exploit for this attack type can be separated into three consecutive phases:
Phase 1 – Preparation. The attacker creates his private key evilKey and a corresponding public key and uses these to create a certificate evilCert.
Phase 2 – Configuration Injection. The attacker creates a malicious link con- taining the CSRF attack vector, i.e., the injection of evilCert. Luring the victim to click on that link, he will exchange the originally stored certificate in the User Database with the one provided by the attacker.
102 This is possible because the HTTP-request that changes the certificate is sent via the victim’s browser (using the victim’s session cookies).
Phase 3 – Access to resources. The attacker can then generate a token t for an arbitrary user and sign it with the key belonging to evilCert generating σ. Then, he sends (t,σ) to the target SP for verification. The target SP will use the certificate stored in the AAM module and use this for the verification of σ. Since the stored certificate is evilCert, the verification is successful and the attacker can log in with the chosen identity.
Impact CInj is a Cat B attack. If the attacker can inject his own SSO config- uration, the SP and the according SSO module will trust the attacker just as a regular trusted IdP. By this means, the attacker can generate valid tokens for any End-User at the SP and log into his account.
Countermeasure The attack uses the CSRF technique to enforce the victim to change changing configuration data without explicit user interaction. Therefore, it targets the Session Management, which should include a protection against CSRF to mitigate the attack.
8.4 Evaluation
In this section we present the evaluation, which we provide by describing the selection criteria, the security analysis and the results.
8.4.1 Evaluation of SAML SPs Selection Criteria For this study, we intended to analyze the security of the most important SPs. Naturally, the first approach was to analyze all SPs from the Alexa Top 100,000. Unfortunately, this proved to be very inefficient: The main problem of this approach was to decide whether or not an analyzed do- main is an SP, as there is no strict labeling for this kind of site. This is why it is not possible to simply do an automatic keyword search for, for example, “SP”, as this would lead to (1) a substantial amount of false positives, in case websites just advertised working in conjunction with certain SPs, and (2) an at least equally considerable amount of false negatives for those SPs, which called themselves, for example, “Cloud Service Provider” instead of “SP”. Thus, this approach would have meant manually analyzing all 100,000 domains includ- ing their corresponding subdomains, and possibly also studying the provided documentation and external descriptions. In order to find a more efficient way of identifying the most important SPs, our second approach was to use precompiled lists of existing Cloud Service Providers. Such lists could be found at major Identity Providers (e.g., OneL- ogin [92] and Bitium [14]), who maintain up to date lists of their respective supported Cloud Service Providers. Wikipedia also offers a list of known Cloud Service Providers [130]. Further internet research yielded additional indepen- dent lists [32, 121]. After consolidating all the lists and eliminating overlaps,
103 we used the resulting consolidated list as a basis for our analysis. From this list we selected all SPs, which satisfied certain selection criteria: • Cloud Service Provider Type: As we intended to analyze SPs, we concen- trated only on Software-as-a-Service Providers. For this study, this was a sensible approach, as other Cloud Provider Types, such as Platform-as- a-Service (PaaS) or Infrastructure-as-a-Service (IaaS), differ substantially in terms of attack surface and handling. Thus, these other types would require a mostly different approach in terms of attack types, attacker models, etc. • Free Trial Accounts: We did not have any specific funding for opening and maintaining accounts with SPs for this study. Thus, we were limited to analyze only those SPs which offer a free trial account for their services. • SAML-based Single Sign-On: Our goal was to evaluate the security of SAML-based SSO authentication modules. Thus, we included all SPs which offer SSO functionality with support for SAML in their authenti- cation procedures.
Security Analysis After we selected all relevant SPs for our study, we specifi- cally analyzed the security architecture of the SSO authentication mechanisms of these SPs. On a logical level, we identified the components related to the authentication process and the relevant information flows between them. Based on our understanding of the logical architecture of a provider (cf. Fig- ure 5.1), we identified possible attack classes against the corresponding compo- nent. Testing has been performed in a semi-automated blackbox analysis. Since we analyzed real applications for which we did not have access to the source code, we were only able to perform blackbox testing on the SPs. For the analysis itself, we used a self-developed tool to dynamically generate different messages and observed the reaction of the targeted systems. The analysis of each SP was split into three phases: • Learning phase – This phase introduced the calibration of our tool as a preparation for the next phase. We configured the tool to generate valid messages that were accepted by the target SP. Analyzing the system’s responses allowed us to estimate the “normal” (i.e., intended) behavior of the system. • Security phase – This phase was split into several steps - one for each attack. During this phase’s steps, we used our tool to generate different messages deviating from those accepted by the target SP in the previous phase. The actual deviations of the generated messages in each step were depending on the corresponding attack class. All attack classes were applied to each analyzed SP. We then observed the reaction of the systems and analyzed the results. • Verification phase – To verify the results obtained from the previous phase and to mitigate possible false-positives, we used a completely in- dependent platform, for example, another PC, to manually execute the exploits and verify the correctness of the results.
104 Service ∅Sig CF XXEAXSLTA RA XSW TRC CInj Summary Provider Salesforce XXX X XXX X X Google Apps X X X X X X X X X Zoho XXX X X Vuln. X X Vuln. Zendesk X X X X X X Vuln. X Vuln. Clarizen Vuln. X Vuln. X Vuln. Vuln. Vuln. X Vuln. SAManage X X Vuln. X X Vuln. Vuln. Vuln. Vuln. Shiftplanning X X Vuln. X X X Vuln. Vuln. Vuln. Panorama9 X X X X X X Vuln. X Vuln. UserVoice XXX X XX Vuln. X Vuln. Instructure X X X Vuln. Vuln. Vuln. Vuln. X Vuln. The Resumator X X Vuln. X X X Vuln. X Vuln. BambooHR X X X X X X Vuln. Vuln. Vuln. AppDynamics X X Vuln. X Vuln. Vuln. Vuln. X Vuln. IdeaScale X X Vuln. X X X X Vuln. Vuln. Panopto XXX X X Vuln. Vuln. X Vuln. TimeOffManager X X Vuln. X Vuln. Vuln. Vuln. X Vuln. HappyFox XXX X X Vuln. Vuln. X Vuln. SpringCM X X X X X Vuln. X X Vuln. ScreenSteps Live X X Vuln. X X Vuln. Vuln. X Vuln. LiveHive X X Vuln. X Vuln. Vuln. Vuln. X Vuln. Howlr XXX X XX Vuln. Vuln. Vuln. CA Service Mgmt. X X Vuln. X Vuln. X Vuln. Vuln. Vuln. Total 1 0 10 1 6 11 17 6 20/ 22
Table 8.2: Results of our practical evaluation. We evaluated 22 SPs against 8 different attacks: (1.) Signature Exclusion (∅Sig) (2.) Certificate In- jection (CInj) (3.) XML External Entity Attack (XXEA) (4.) XSLT Attack (XSLTA) (5.) Replay Attack (6.) XML Signature Wrapping (XSW) (7.) Token Recipient Confusion (TRC) (8.) Certificate In- jection (CInj). 20 of them were vulnerable to at least one attack so that we could successfully access unauthorized resources.
Results In our evaluation we provided a security analysis of 22 SPs, see Ta- ble 8.2. We discovered vulnerabilities in 20 of 22 leading to security gaps like unauthorized access to one or all accounts as well as access to files stored on the server. As shown in Table 8.2 only one SP is susceptible against ∅Sig and none of the SPs is vulnerable against CF. Based on these results, one can say that the proper validation of the integrity protection and authenticity of the authentication token is a recognized security issue by the developers and thus implemented correctly. Interestingly almost 50% (10 of 22) SPs are vulnerable against XXEA, which is a surprisingly high number. The result can be ex- plained by the fact that the XML DTD support is usually turned on by default in the parsers. Thus, a developer using an XML parser, must be aware of the fact that this feature (1) exists, (2) is turned on by default (even if it is not needed), (3) and leads to security issues. In contrast, the XSLTA is applicable only on one SP since XSLT is turned by default off. Surprisingly high is the number of Replay Attacks – 6 of 22. We considered only the SPs, which do not provide any timestamps validation or validate times- tamps unprotected by the digital signature. Unfortunately, we do not have any explanation for this result, since Replay Attacks are known since many years
105 and the security risks are documented well. Another surprising result is the number of XSW vulnerabilities – 11 of 22. Despite the fact, that this problem was already addressed by Somorovsky et al. in [110, 111], the importance of a proper implementation is not understood. The main problem mitigating the XSW attacks lies on their complexity – there are many variants and potential exploits, which must be addressed. Thus, the mitigation of XSW leads to an implementation overhead and security-conscious development. Another unex- pected result was the large number of TRC-related issues – 17 of 22 ignored the recipient related information at all. The result can be explained by the fact that the attack and the potential risk is unknown for many developers leading to skipped verification checks. The importance of the CInj is highlighted by our evaluation – 6 of 22 SPs are vulnerable. More importantly, even secure implemented SSO modules like IdeaScale or Howlr preventing many of the existing attacks, can be still bypassed by injecting malicious key material through the web interface. During our evaluation, we promptly reported all vulnerabilities to the security team and coordinated the reporting process with the Computer Emergency Response Team (CERT)1. We supported the team fixing the reported issues and provided a re-evaluation confirming the mitigation of the problems.
8.4.2 Evaluation of SAML IdPs Similar to the evaluation on IdPs, we present our selection criteria methodology, approach during the security analysis and the results.
Selection Criteria We evaluated six cloud-based IdPs. The selection was based on Wikipedia’s comprehensive list with SAML-based services [131] and the Entwork World’s review of eight prominent cloud-based SSO products [115]. The requirements regarding the IdP are: 1. On-demand: The IdP must not require any installation and configuration. Thus, any intentionally made mistakes were excluded. 2. Widespread: The IdPs must be used by enterprises. 3. Free trial accounts: Since we don’t have any funding for non-free accounts, we limited our evaluation on IdPs offering free (trial) accounts. We excluded products like Shibboleth or OpenAM that must be downloaded, installed, and configured. Considering the configuration, which can vary, differ- ent results regarding the security can happen. Therefore, a statement covering the security of the entire product cannot be made.
Security Analysis Since we do not have any access to the source code of the IdP, we provide a black-box analysis. To provide the security analysis we set up three test systems: • Victim’s computer: We used this system to create accounts at the IdP and login the End-User.
1https://cert.org
106 SSO Reference Affected ACS Cookie CVE identifiers system SPs Spoofing theft Okta www.okta.com ≈1,300 CVE-2013-0114 X Vuln. OneLogin www.onelogin.com ≈2,600 CVE-2012-4962, Vuln. Vuln. -4963 SSOCircle www.ssocircle.com – CVE-2013-0115, Vuln. Vuln. -0116, -0117 WSO2 Stratos www.wso2.org – CVE-2012-4961 Vuln. X Bitium www.bitium.com ≈1,750 Direct communication Vuln. X Cloudseal www.cloudseal.com – Direct communication X Vuln.
• Attacker’s webpage: We deployed all exploits on this webpage, which is publicly available on the Internet. • Attacker’s computer: We used this system to download the stolen tokens and redeem these at any SPs to verify the success of the attack.
Results In our evaluation we evaluated six prominent IdPs and find all these vulnerable. 4 of 6 IdPs are vulnerable against ACS Spoofing. This is a surprising high number considering the fact that the countermeasure is clearly addressed by the SAML specification. We assume that the reason for this result is the high complexity of SAML defining many XML elements and attributes within the AuthnReq. Thus, it is hard for a developer to know which of these are security relevant and which are not. In addition to ACS Spoofing, we evaluated the security of the web interface of the IdPs, especially against XSS attacks enabling the cookie theft. Four of the IdPs are vulnerable against an XSS attack. In addition, all vulnerable IdPs did not used any further protection of the session cookies, e.g., the HTTPOnly flag protecting the cookie for JavaScript access. Thus, via XSS we are able to steal the session cookies of the victim at the IdP, log in at his account, and issue valid authentication tokens for any of the supported SPs. In summary, one can say that the security of the existing IdPs needs im- provements regarding the security. We proved that one novel attack ACS Spoofing and known XSS attacks are still sufficient to break the security of the entire SSO ecosystem. At the end of our analysis, we reported the vulnera- bilities and supported the teams to fix them. Many of them acknowledged our work [29, 30, 31, 35, 69].
8.5 Automated Analysis
In this section, we present two tools evaluating the security of SAML provider. SAML Attacker simulates a malicious IdP creating arbitrary tokens and capable to validate the verification logic at an SP. ACS-Scanner evaluates automatically
107 the security of an IdP with respect to the ACS Spoofing attack.
8.5.1 SAML Attacker The SAML Attacker was designed in 2013 and implemented within the master thesis of Benjamin Sanno [102].
Configuration If SAML Attacker is started for the first time, a key-pair and a self-signed certificate are generated. These are used to sign the generated authentication tokens. In addition, SAML Attacker provides a default configu- ration of a SAMLResponse, which can be extended and stored.
Evaluation Within the security evaluation, the penetration tester must con- figure the target SP to trust the SAML Attacker’s key material. Usually, this is done during the configuration of the SP. Afterwards, SAML Attacker generates valid token to verify that the config- uration is successful and the penetration tester is logged in at the SP. Then, SAML Attacker generates invalid authentication tokens to test the verification logic at the SP, e.g., by setting invalid recipient URLs or old timestamps. More important, SAML Attacker integrates a full automated library for test- ing XSW provided by WS-Attacker 2. Based on a valid authentication token it generates different potential exploits and send these successively to the SP. In dependence of the result returned by the SP, SAML Attacker determines if the attack was successful or not and displays the result to the penetration tester. Due to the high flexibility of SAML, we decided to implement SAML Attacker as a semi-automated tool facilitating the work of a penetration tester. We consciously did not implement it as a full-automated tool since we desired a powerful tool allowing high flexibility during testing, control over each step of the protocol flow and the possibility for modification of the attack vectors during testing.
8.5.2 ACS-Scanner Based on our crucial findings, we developed an ACS Spoofing penetration test tool, which is online available3. ACS-Scanner can be configured via the web interface and it automatically tests the security of the IdP. Therefore, customers and developers can easily test if their IdP is vulnerable against ACS Spoofing. ACS-Scanner is platform independent and does not require any installation of additional software.
Configuration. There are three parameters, which can be configured in ACS- Scanner: • IdP Endpoint URL defines the URL where the attacked IdP is deployed. The malicious SAML Request will be sent to this URL.
108 • SAML Request Issuer defines the issuer of the SAML Request, e.g., http: //google.com. In many cases, IdPs use this value for the generation of the assertion. Thus, ACS-Scanner allows the change of the value. • SAML Request is an input field, where the malicious SAML authentica- tion request can be configured manually. For normal operations this is not necessary, but experts have the option to build their own handcrafted request message. For example, when the SP verifies the InResponseTo attribute of the assertion, the pentester can use this field to provide a freshly created from a federated SP. ACS-Scanner pro- vides a default SAML as an example.
Evaluation. By clicking on the “Start Test” button ACS-Scanner will start the security analysis: 1. ACS-Scanner generates a unique ID (ID1) and binds it to the malicious SAML Request. Then, both values are stored in the internal Database. 2. ID1 is attached to the ACS URL in the SAML Request, ACSURL = ssoattacks.org/acsscanner/ID1. In case that the tested IdP is vulnerable against ACS Spoofing, it will send the token to ACSURL. 3. ACS-Scanner calls the URL of the IdP in a new browser tab. The user has to authenticate himself to the IdP if he is not already authenticated. Please note that ACS-Scanner does not act as MITM and cannot intercept any credentials used on the IdP for the authentication. 4. If the IdP is vulnerable against ACS Spoofing, it will process the SAML Request and send the assertion to ACSURL. 5. In case that ACS-Scanner receives an assertion, it creates a relation be- tween ID1 ↔ SAML Request ↔ SAML Response. Based on this data, ACS-Scanner classifies the according IdP as vulnerable and displays the results.
8.6 Summary
In this section, we pointed out the different components responsible for au- thentication at the SP and IdP. Some attacks target exactly one component, other attacks abuse the interaction between two of them. The presented at- tacks nevertheless targeted each component at least once. This shows that SSO authentication relies on several components and that interaction between these components must be understood and protected thoroughly. Google and Sales- force showed that this is possible and SSO authentication can be secured by a correct technical implementation. For classical Username/Password authenti- cation, this might not be the case, because the prohibition of weak passwords is a challenging task. While most of the presented SAML attacks are already known [5, 6, 94, 111, 122], it is very surprising that the majority of the SP related attacks is also already covered by previous literature. The SAML standard itself [54] even discusses a lot of the attacks in this thesis, but obviously, this does not ensure the security of SAML implementations. One reason for this might be
109 that the SAML standard is very large and includes a lot of edge use-cases. We recommend extending its security considerations to highlight the issues for different attacker types and the impact in case that a verification is not provided. As an example, the XXEA attacks require AM1, and can therefore be performed with the least knowledge of the SP, but those attacks are not mentioned in the standard. Attacks regarding the Signature Manipulation are not considered either. On the other side, attacks against the IdPs can be started too. Such attacks have greater impact since all SPs are vulnerable and cannot provide counter- measures mitigating the attack. Since SAML is a very flexible and extensible standard, the corresponding specifications are complex and distributed over a bulk of documents. Develop- ers can get lost in the specification and may overlook important security-relevant constraints. This can result in vulnerable implementations, as the discovered ACS Spoofing attack demonstrates. Nevertheless, SAML is also a matured and well-designed standard. Throughout the specification, multiple security recom- mendations are given to avoid common pitfalls. Still, this does not guarantee the absence of flaws in real-world implementations. Even if the SSO protocol is implemented securely, the prevalent authentica- tion trough the web interface creates an attack-surface used by attacks like CInj or XSS. Our results confirm the significance of these attacks for the security in SSO systems.
110 9 TLS Channel Bindings
Motivated by the existing threats and serious vulnerabilities found within to- day’s authentication processes and the associated identity management, we identified one of the root causes for many vulnerabilities – authentication tokens are in most cases bearer tokens. This means that the owner of the authenti- cation token represents the subject stated within this token. With respect to the security one can say that the token theft automatically leads to a broken End-User authentication allowing the attacker to log in at victim’s account. TLS channel bindings address this problem by cryptographically binding a bearer token to specific TLS channel or related key material, for example, a TLS client certificate and the private key. The main idea of a channel binding is not the prevention of the token theft, but the detection of the theft during the token redemption. In this chapter, we first introduce two different channel bindings – TLS Unique (TLS Unique) and Holder-of-Key (HoK). Each binding uses different features from TLS to establish the cryptographic relation between the TLS channel and the token. We describe our approach to strengthen two-party authentication tokens, for example HTTP cookies, by using both channel bind- ings. Moreover, we show how channel bindings can be used in SSO by adapting them on SAML and OpenID Connect.
TLS Unique TLS Unique relies on the uniqueness of each TLS channel. RFC 5929 proposes to use the first TLS Finished message (FIN ) established during the TLS handshake. By binding a bearer token to FIN , an attacker stealing this bearer token must establish a TLS channel with the same FIN , which is not trivial. This binding provides a high level of anonymity since no identity based information is used for the binding.
Holder-of-Key (HoK) HoK relies on TLS client (self-signed) certificates. Dur- ing the TLS handshake, the End-User proves via his UA the possession of a private key related to a certificate. Consequentially, the bearer token is bound to this certificate. To verify the validity of the token, the provider (SP or IdP) verifies each time whether the certificate established in the TLS session corresponds to the bound certificate. Thus, an attacker stealing the bearer to- ken must possess the corresponding TLS client certificate and private key to successfully redeem the token.
111 In Section 9.2 and Section 9.3, we describe how both channel bindings can be used in two-party communication to strengthen bearer tokens like HTTP session cookies. Moreover, we show how they can be applied on the SSO authentication scheme and describe the existing challenges, which we solved.
9.1 Transport Layer Security Basics
To exchange sensitive data between a client and a server, a secure channel has to be established between the two communication partners. Establishing such a channel requires multiple steps. The server side authentication and data protection during transport are usually handled via Transport Layer Security (TLS).
Figure 9.1: TLS Handshake Phase and Application Phase.
Transport Layer Security (TLS) [37] provides multiple security goals, such as (1.) Confidentiality (2.) Authenticity (3.) Integrity and (4.) Replay protection. These goals are achieved by different cryptographic primitives like encryption, Keyed-Hash Message Authentication Codes (HMACs), sequence numbers and nonces. However, TLS protects data only during transport and does not pro- vide any end-to-end payload security. Thus, message level security requires additional mechanisms at a higher level in the protocol stack. TLS consists of a two-phase architecture: The handshake phase and the appli- cation phase (see Figure 9.1). The handshake phase includes multiple messages sent between the UA and the server. It is used to establish cryptographic algo- rithms and an authenticated agreement on a shared secret between the partici- pants. All key material required for a secure communication is derived from this
112 secret. In Step 1, the UA initiates the TLS protocol by sending a ClientHello message to the server. This messages contains the highest supported TLS ver- sion, a unique SessionID, random number, a list of supported cipher suites, and a list with compression algorithms. In Step 2, the server responds with a ServerHello message containing the chosen TLS protocol version, a server chosen SessionID, random number, selected cipher suite and compression algo- rithm. In Step 3, the server sends optionally his Certificate and optionally a certificate chain. The ServerKeyExchange message is sent if additional key material must be transmitted, for example, for ephemeral Diffie-Hellman. In step 5, the server can request a TLS client certificate from the UA. The server indicates the end of the negotiation by sending the ServerHelloDone message, see Step 6. The UA sends a TLS client certificate (see Step 7) if the server requested it. In Step 8, the ClientKeyExchange message is sent to the server. Its con- tent depends on the negotiated cipher suite. The optional CertificateVerify message (see Step 9) contains a signed hash value of all concatenated messages of the handshake phase. Thus, the UA proves the possession of the private key related to the TLS client certificate sent in Step 6. In Step 10, the UA indicates the usage of the negotiated key material and encrypts all further messages. The Finished message (FIN ) (see Step 11) is the first encrypted message send by the UA to the server and contains an HMAC over all previous messages. The server indicates by sending the ChangeCipherSpec message that from now on it uses the negotiated key material. Finally, the server computes a second FIN message over all previously exchanged messages and sends it to the UA. Afterwards, the application data will be encrypted with the negotiated key material.
9.2 TLS Unique
The idea of TLS Unique is described in RFC 5929 [4]. The document introduces an approach how to use parameters from the TLS channel to secure bearer tokens exchanged on the application layer, for example, HTTP cookies. A parameter of interest for the concept of TLS Unique is the first FIN mes- sage. This FIN message is the first message encrypted with the negotiated keys and contains an HMAC computed over all handshake messages previously exchanged between the UA and the server(SP/IdP) Figure 9.1. The HMAC especially includes all random values exchanged within the handshake. Thus, the FIN message can be seen as a unique fingerprint of the TLS session in use. After both parties have established the shared secret and confirmed this by sending the proper FIN message, the protocol continues with the application phase where the actual payload data is exchanged via the secure communication channel. The main idea of TLS Unique is to bind the bearer tokens sent during the application phase to the FIN message. Thus, a stolen bearer token can be redeemed only within the same TLS session or if an attack is able to reproduce the same fingerprint of a new TLS session on his own.
113 9.2.1 TLS Unique in Two-Party Authentication In this section, we describe how TLS Unique can be used to strengthen bearer tokens in a two-party authentication. We apply TLS Unique on HTTP session cookies, since HTTP cookies are often used for End-User authentication and widely deployed. Service Provider End-User UA https://sp.com
TLS Handshake 1.1. 1.1. Extract FIN Extract FIN 1. HTTP GET URI 2. Authentication 3.1. 3. Set cookie: ssid=Hash(FIN Bind cookie to FIN
4. HTTP GET Ressources + 4.1. cookie: ssid Check if cookie sent through the same TLS channel identified by FIN
Figure 9.2: HTTP cookies bound to TLS Unique.
In Figure 9.2 we show our approach to bind the cookie to the TLS channel. Initially, the End-User navigates his UA to a SP 1 running on https://sp. com. The UA calls the URL and establishes a TLS channel. After the TLS handshake, the UA and the SP store the FIN message and proceed with the HTTP communication. 1. In Step 1, the UA sends the HTTP request and receives a login request as an answer. After the successful authentication, the SP immediately sets an HTTP cookie ssid = hash(FIN’) with the value of the Finished message of the TLS session used before Step 1. The value of this cookie serves as a session identifier on server side2. 2. Verifying the Session cookie: In all subsequent HTTP requests, the browser automatically provides the ssid by adding it to the HTTP header of the request. The server accepts the cookie if the following comparison holds: ssid = hash(FIN’). Thus, the server verifies that the session cookie be- longs to the corresponding TLS channel. Note: Even if the attacker is able to steal the session cookies of the End-User, he cannot establish a parallel TLS session to the server with the same Finished message FIN = FIN’. As a result, using the stolen cookies to authenticate through a different TLS channel is not possible.
9.2.2 TLS Unique in Single Sign-On A major problem of SSO protocols are Man-in-the-Middle (MitM) attacks on involved TLS connections. If TLS is badly configured, or if the adversary 1Note that the protocol can be applied on the communication between the UA and the IdP, too. 2Additional cookie properties like confidentiality or integrity protection can also be ap- plied [68].
114 succeeds to mount a DNS/PKI spoofing attack, he may read authentication credentials from the network. The TLS Unique binding from RFC 5929 offers a way for the authenticating party to check if there is a malicious MitM on the network. A usage scenario for a TLS Unique binding within general SSO protocols is sketched in Figure 9.3.
End-User UA Service Provider Identity Provider https://sp.com https://idp.com
TLS1 Handshake Extract FIN1 Extract FIN1 1. HTTP GET URI 2. HTTP 30x + AuthnReq HTTP-Header: tls-unique-sso
Figure 9.3: Binding SSO authentication tokens to TLS Unique
In an SSO protocol, typically at least two TLS sessions are involved: TLS1 between UA and SP, and TLS2 between UA and IdP. Often the first request to SP is not protected by TLS, but to be able to apply the TLS Unique binding, setting up a TLS channel from the beginning of the authentication scheme is essential. Initially, the user agent (UA) extracts the first Finished message FIN1 from TLS1, using the API described in RFC 5929. In Step 2, the SP enforces with the HTTP header tls-unique-sso the UA to send this value added as a parameter to the AuthnReq and forwarded it to the IdP in Step 3. Note: Technically, SP could immediately include the corresponding value FIN1’ into the authentication request in Step 2. However, it is important that this value is included by the UA, as FIN1 is intended to be checked against FIN1’ in Step 5 by SP. After the successful authentication of the End-User in Step 4, the IdP will include FIN1 into the issued authentication token (Step 5). This token is cryp- tographically secured – either by a digital signature or by an HMAC. Thus, the content of the token cannot be altered by an MitM. Additionally, in Step 5 the UA forwards the token to the SP through the previously opened session TLS1. Note: TLS1 must be kept active between UA and SP all the time. This is important, so the Finished message of the current TLS connection is still the same as during the extraction of FIN1’ in Step 3.2. The TLS connection can, for example, be preserved by sending keep-alives on the TCP connection below. When SP receives the authentication token in Step 6, it compares FIN1’ to the value FIN1 read from the token. Access is granted in Step 11 if and only if
115 the authentication token is valid and FIN1’ = FIN1. Based on the modification, even if the attacker is able to steal the authenti- cation token in Step 5, he is not able to redeem it. We assume that the token is issued for FIN1. To redeem the token, the attacker must establish a new TLS channel, which generates a new FIN message (FINMitM). Since the FIN message in the token and the one established within the TLS channel between the attacker and the SP are different, the redemption of the stolen token can be detected by the SP and the attack will be prevented.
9.2.2.1 TLS Unique in SAML
In this section, we will describe how TLS Unique can be implemented in SAML. For this purpose, we use the channel binding extension defined for SAML [105]. The document describes how to encapsulate channel binding related information in general. In this section, we will describe if and how TLS Unique can be adapted for SAML.
SAML AuthnReq In order to trigger TLS Unique at the IdP, the SP can include the element in the AuthnReq. In addition, the base64-encoded raw channel binding data must be included. However, in TLS Unique it is essential that the UA includes this data by himself. Otherwise, the security provided by TLS Unique can be bypassed. There are two options to solve this problem: (1.) The UA adds the information to the AuthnReq. This approach is not feasible since the AuthnReq can be encrypted and thus is only available as a ciphertext. The AuthnReq can be signed and any manipulation will invalidate the signature. (2.) The SP signals via the AuthnReq that TLS Unique is required, but the FIN message is sent over HTTP as described in Figure 9.3 Step 3.
SAML Response The IdP encapsulates the received FIN message in the el- ement and inserts it in the authentication token. There are two options to place the element: (1.) in the SAML Response element en- capsulated in the or (2.) in the SAML Assertion element encapsulated in the element. An advantage using the second approach is the fact that SAML Assertion is usually signed and thus protected by manipulations.
9.2.2.2 TLS Unique in OpenID Connect
Currently, there is no specification describing how TLS Unique can be imple- mented for OpenID Connect. In this section we will describe, how this can be done.
116 OpenID Connect AuthnReq Similarly to SAML, there are two options to start TLS Unique: (1.) The UA adds the FIN message to the AuthnReq. Since the AuthnReq in OpenID Connect is a HTTP Request containing GET or POST parameters, the addition of FIN is feasible. The AuthnReq is usually not signed. (2.) The SP signals via the AuthnReq that TLS Unique is required. But the FIN message is sent over HTTP like described in Figure 9.3 Step 3.
OpenID Connect Response The IdP can add a further parameter to the id token, for example, tls unique containing the FIN message.
9.2.3 Advantages and Disadvantages TLS Unique does not require any installation of further software or changes of preferences in the UA. If applied, the entire authentication flow is used fully transparent for the End-User. With respect to the privacy, the usage of FIN , which is considered unique for each TLS channel, does not lead to leakage of any privacy information. With respect to the applicability of TLS Unique there exist some disadvan- tages. Currently, no UA and web server do implement an API allowing the access to the FIN message. This is however needed to be able to extract the FIN message and use it during the verification process. Thus, an extension of the source code of the UA and existing web servers has to be done. This has a negative impact on the dissemination of TLS Unique since both UAs and web servers have to be updated.
9.3 Holder-of-Key
Holder-of-Key (HoK) is a method enabling the cryptographic binding of bearer tokens to a specific certificate and the according key material. Thus, stolen tokens can be redeemed only if the possession of the according key material is proven. The requirements regarding HoK can be summarized as follows: • The End-User has a certificate Cert and the according private and public key. Cert does not have to be signed by a trusted Certificate Authority (CA), and thus can be self-signed. • The UA has access to Cert and the keys. It can use them during the TLS handshake and the mutual authentication. • The server supports TLS mutual authentication and requires the client certificate during the TLS handshake.
9.3.1 Holder-of-Key in Two-Party Authentication HoK can be used to strengthen bearer tokens in two-party communication. A typical example of such a communication are HTTP cookies exchanged between the UA and the server, see Figure 9.4.
117 Service Provider End-User UA + https://sp.com Cert1 TLS Handshake + Mutual Authentication Extract Client 1. HTTP GET URI Certificate Cert1 2. Authentication 3. Set cookie: ssid=123 4. HTTP GET Ressources + cookie: ssid=123 4.1. Check if the cookie is sent through a TLS channel bound to Cert1 Figure 9.4: Using HoK to strengthen HTTP cookies
Initially, the End-User starts his UA and enters the URL of the server. Con- sequentially, a TLS channel between the UA and the server is established. Note- worthy is the fact that the UA sends the certificate Cert1 and proves the pos- session of the according private key during the TLS handshake. Once the TLS channel is established, the server extracts Cert1 and stores it temporarily in the cache. In Step 1, the UA sends an HTTP request pointing to some restricted re- sources on the server. In Step 2, the server requires authentication to gain the access to the requested resources and the End-User authenticates consequen- tially. In Step 3, the Server sets an HTTP session cookie ssid=123 bound to the identity of the authenticated End-User. In addition, the server binds internally the session cookie to the certificate Cert1 from the TLS handshake. In Step 4, the UA sends the session cookie within the HTTP request. The server verifies if the certificate used in the TLS handshake corresponds the certificate bound to the cookie, Cert1.
Figure 9.5: Using HoK to strengthen SSO authentication tokens
Initially, the End-User navigates his UA to the SPs website. Before the
118 HTTP GET request is sent (see Step 1), a mutual authenticated TLS channel is established. This means that the UA uses the stored certificate Cert1 during the TLS handshake and proves the possession of the according private key to this certificate Cert1. In Step 1, the HTTP request is sent to the SP. Since the End-User is not authenticated yet, the SP redirects him in Step 2, to the IdP via HTTP redirect. The HTTP redirect contains the AuthnReq generated by the SP. In Step 3, the UA starts the communication with the IdP by establishing a mutual authenticated TLS channel. An important requirement regarding the HoK authentication is that the UA uses the same certificate Cert1 as in Step 1. The IdP extracts the received certificate as Cert1’. Consequentially, the AuthnReq is sent by the UA to the IdP via HTTP. In Step 4, the End-User authenticates at the IdP. In Step 5, the IdP generates the authentication token token containing the in- formation about the End-User is sent to the SP. In addition, the token contains the Cert1’ used during the TLS Handshake. In Step 6, the token is forwarded to the SP. The SP verifies the signature and the statements made in the token as usual. In addition, it verifies the contained certificate in the token Cert1’ with the certificate used during the TLS handshake Cert1. Both certificates must be identical.
9.3.2.1 Holder-of-Key in SAML In SAML, a HoK profile was released by OASIS working group in 2010 [87]. The document specifies the exact structure of the AuthnReq and AuthnResponse and the processing rules for the IdP and the SP. An important step is the inclusion of the TLS client certificate in the au- thentication token by the IdP. The IdP extracts the client certificate from the TLS channel and includes it into the element (which is part of the signed Assertion or Response element). As a result, the IdP binds cryptographically the key material exchanged within the TLS channel to the authentication token. On the other side, the SP must provide an additional check, by first extracting the TLS client certificate sent through the TLS chan- nel and second comparing it with the one stated in the element. If these are equal, the authentication token is accepted and the SP authenticates the End-User.
9.3.2.2 Holder-of-Key in OpenID Connect Currently, there is no approach describing how HoK can be implemented. In this section, we will describe, how this can be accomplished. The protocol flow is depicted in Figure 9.6. Initially, the End-User visits the SP and starts a login attempt (see Step 1). Since he is not authenticated, the SP generates the AuthnReq and redirects the End-User to the IdP (see Step 2). Before the AuthnReq is sent to the IdP it is required that the UA establish a TLS channel, whereby it presents the certificate Cert1 and proves the possession of the corresponding private key. This process is part of the TLS handshake.
119 After the successful authentication of the End-User in Step 3, the IdP generates the code, id token, and optionally the Access Token (access token). In ad- dition, the IdP extracts the client certificate from the TLS channel and inserts it in the id token.
Service Provider Identity Provider End-User UA + https://sp.com https://idp.com Cert1
TLS Handshake + Extracts Cert1' from the 4. Token Request: code, client_id, client_secret Mutual Authentication TLS channel 5. Token Response: id_token, access_token Comparing TLS Client certificate with the certificate in the id_token Cert1' == Cert1
Figure 9.6
In Step 4, the AuthnResponse is sent via redirect to the SP. Note that a second TLS channel is established between the UA and SP by using the same client certificate Cert1. Since the code is an opaque string referencing the id token and does not contain any information, it is not possible for the SP to detect a theft. Thus, after Step 4, the SP extracts the presented client certificate and proceeds with the normal protocol flow. In Step 5, the token request is sent to the IdP and the code is redeemed. In Step 5, the SP receives the id token and optionally the access token. Now, the SP can compare the certificate within the id token and the one extracted from the TLS channel. Both values must be the same ensuring that the End-User authenticated at the IdP is the same redeeming the code at the SP. Since the client certificate must be included in the id token, the parameter and its structure must be specified. Main goal of this modification is to apply it with fewer changes as possible and using already existing concepts. We decide to use the proof-of-possession key semantics for JSON Web Tokens (JWTs) specified in RFC 7800 [72]. The document describes how key material can be included into a JWT, which we can adapt on id tokens. In Listing 9.1, an example of a HoK id token is shown. One can see that in addition to the required OpenID Connect parameters, we included the parameter cnf containing the HoK-part of the token. Within the element jwk and x5c the client certificate from the TLS session is included by the IdP and later verified by the SP.
9.3.3 Advantages and Disadvantages HoK relies on existing mechanisms like TLS client certificates used in the TLS handshake. In comparison to TLS Unique, it does not require any modifications of the UA since all modern browsers can handle client certificates on demand. On server-side APIs exist, which extract the client certificate from the TLS handshake and forward it to the web application. Thus, the verification does not require any overhead of implementing new APIs. Summarized, HoK provides
120 1 { 2 "alg": "RS256" 3 } 4 { 5 "iss": "https://idp.com", <-- The ID of the Identity Provider 6 "sub": "End-User 1", <-- The identity of the End-User 7 "aud": "234dsf46fg345", <-- The ID of the Service Provider 8 "nonce": "40c6b33b9a2e", <-- number used only once 9 "exp": 1444148908, <-- expiration: date time 10 "iat": 1444148308, <-- issued at: date time 11 "cnf":{ <-- Holder-of-Key part 12 "jwk":{ 13 "x5c": "23z34sdfsdfs..." <-- x509 certificate of $Cert_{End-User}$ 14 } 15 } 16 }
Listing 9.1: A HoK id token in OpenID Connect issued by the IdP and send to the SP.
on demand support by using existing APIs and thus require less implementation overhead. On the other side, HoK requires TLS client certificates, which have to be installed in the UA of the End-User. This leads to distribution problems and makes HoK less user-friendly than TLS Unique. These problems can be ad- dressed by using two methods: • Self-signed client certificates: HoK relies on the fact that the UA possess a private key, which never leaves the UA. HoK does not require a certificate signed by a valid and trusted CA. • HTML5 features allowing the dynamic generation of client certificates: For this purpose, we use the keygen method, which forces the generation of an asymmetric key pair on the UA and afterwards the storage of the issued client certificate. As a result, the complexity of the distribution process can be reduced. With respect to the End-User’s privacy, it should be mentioned that HoK allows the usage of the same client certificate for multiple logins and for securing multiple bearer tokens. Thus, the End-User leaks privacy information by using the same key material in multiple authentication sessions.
9.4 Summary
Authentication mechanisms based on bearer tokens are prone to a variety of attacks, for example, cookie theft. This way, an attacker may steal these tokens and use them to impersonate the victim. The introduced channel bindings holistically secure the authentication token in the SSO protocol flow by binding the authentication information to specific TLS information. Thus, the exploit of many previously found authentication flaws can be prevented. In this section, we fist described a generic approach applying channel bindings in authentication two different schemes. Afterwards, we proved the applicability of both channel bindings on SSO protocols like SAML and OpenID Connect.
121 In TLS Unique, we use the first Finished message to uniquely identify a TLS session and then cryptographically bind this identifier to the authentication data. TLS Unique can be implemented as a browser plugin, provided that the corresponding API is available to allow access to the required parameters (especially the first Finished message) from the TLS handshake. A few new HTTP headers must be provided by the server to activate and trigger the plugin. HoK relies on TLS client certificates to cryptographically bind this identifier to the authentication data. HoK requires less implementation overhead since it uses already implemented and widely deployed interfaces to access the needed information. However, it requires more resources for set up and installation of the client certificates.
122 10 Related Work
We separated existing research into three categories.
10.1 Single Sign-On Protocol Security
The concept of malicious IdPs was previously described in [36, 41, 62]. However, the described attacks consider only accounts controlled by the malicious IdP, which are compromised. The main scope of these researches is to investigate privacy issues if users use a maliciously acting IdP. In comparison, our malicious IdP analysis targets accounts controlled by other honest IdPs (e.g. Google).
SAML: In 2003 and 2006 Gross et.al Groß [51], Groß and Pfitzmann [52], and in 2008 and 2011 Armando et. al. Armando et al. [5, 6] analyzed a formal model for the SAML Browser/Artifact profile and identified several generic flaws allowing connection hijacking/replay, MitM, and HTTP referrer attacks. In 2012 Somorovsky et al. [110, 111] investigated the XML Signature validation of several SAML frameworks. None of the previous work considered an evaluation via an malicious IdP.
BrowserId: In 2014 Fett et al. [44] built a formal model of the BrowserId protocol [33]. Based on the analysis, the authors defined possible points of Single-Phase Attack and, using manual testing, found a ID Spoofing (IDS) vulnerability. Cross-Phase Attacks were not considered. Since Mozilla will end the BrowserId support on 30th November 2016 [34], further security evaluation is not likely.
OpenID: In 2008, Newman and Lingamneni [88] created a model checker for OpenID and identified a session swapping vulnerability, which forces the victim to log in into attacker’s account on an SP. In 2012 Sun et al. [119] analyzed OpenID Connect in a formal analysis and identified several existing threats such as CSRF, Man-in-the-middle attacks, and the SSL support of OpenID implementations. In 2010, van Delft and Oostdijk published in an independent work an attack describing Key Confusion (KC) Strategy 1. However, KC Strat- egy 2 was not considered [123]. Wang et al. [128] demonstrated the problems related to token verification with different attacks targeting implementation is- sues. The authors developed a tool named BRM-Analyzer analyzing invariants
123 in the messages send through the UA. In 2014, Silva [108] exploited an Ex- ternal Entity vulnerability on Facebook. The same attack was described and evaluated in this thesis.
OAuth Authorization Framework 2.0 (OAuth): OAuth has been analyzed in different formal models [10, 16, 109]. Additional threats are also considered in the OAuth Threat Model and Security Considerations [120]. In 2016, Fett et al. [46] formally analyzed OAuth independent of our work and discovered generic flaws that can be exploited by a network attacker. The IdP Mix-Up attack on OAuth is similar to our IdP Confusion attack on OpenID Connect, but the IdP Confusion attack targets the End-User authentication while the MixUp can only break the authorization. In 2012 Sun and Beznosov [118] provided a large- scale study regarding the security of OAuth implementations and found serious security flaws in many of them. The evaluation concentrated on classical web attacks like XSS, CSRF, and TLS misconfiguration. Further security flaws in OAuth-based applications were discovered [39, 40, 56, 89, 90, 107, 133] whereby the authors concentrated on individual attacks. In 2013 Wang et al. introduced a systematic process for identifying critical assumptions in SDKs, which led to the identification of exploits in constructed apps that resulted in changes in the OAuth specification [129]. Chen et al. [17] revealed serious vulnerabilities in OAuth applications on mobile devices, which were caused by the developer’s misinterpretation of the OAuth protocol.
OpenID Connect: In 2016 Li and Mitchell [66] analyzed OpenID Connect by evaluating the security of 103 SPs using Google as an IdP and found sev- eral vulnerabilities like Replay attacks, Man-in-the-middle, session swapping, and XSS. Attacks like IDS and Cross-Phase Attacks were not considered. We summarized our knowledge of all existing attacks on OpenID Connect in a tech- nical report [8]. The document contains all attacks described in this paper and examples contributing to a better understanding of the attacks.
10.2 Automated Penetration Testing Tools
In 2013 Guangdong [53] introduced AuthScan, a penetration testing tool that automatically extracts the authentication protocol based on HTTP traces and JavaScript code. The authors found security flaws in several SSO systems like MitM attacks, Replay attacks, and Guessable tokens. More complex attacks like IDS or Cross-Phase Attacks were not considered. Xing et al. [132] published InteGuard - a tool detecting the invariance in the communication between the browser and the SP. Another tool similar to InteGuard is BLOCK [67]. Both tools can detect Single-Phase Attacks. However, Cross-Phase Attacks requiring the usage of malicious IdP were not covered by either tool. Yuchen Zhou [133] published a fully automated tool named SSOScan for analyzing the security of OAuth implementations and described five attacks, which can be automat- ically tested by the tool. We used this work as a basis of Practical Offensive
124 Evaluation of Single Sign-On Services (PrOfESSOS) – a website capable to eval- uate different implementations. However, SSOScan is limited to the analysis of Facebook SSO and cannot consider attacks like IDS and Cross-Phase At- tacks. In 2016 Sudhodanan et al. [116] introduced an automated tool for black box testing Multi-Party Web applications, including Cashier-as-a-Service, and discovered multiple vulnerabilities. They extended the OWASP ZAP tool and implemented seven attack patterns. However, the implementation is not pub- licly available, and the authors of the paper excluded the usage of malicious IdP.
10.3 Secure Bindings
Several efforts have been proposed [49, 68, 96] to secure cookies by deploying modern public key-based authentication mechanisms. However, neither signing nor encrypting cookies prevents an adversary from transferring a cookie from one browser to another, thus rendering these efforts ineffective against cookie theft and similar attacks. In 2007, Karlof et al. [59] proposed to strengthen the web browser’s Same Origin Policy (SOP) by taking the server’s TLS certificate into account. They recommended two variants, called weak- and strong-locked Same Origin Policy, respectively. The weak-locked SOP is easier to implement and enforces that web objects are sent only to servers with valid certificate chains (e.g., certificates included in the chain can neither be selfsigned nor expired). The strong-locked SOP tags each web object with the server’s public key and solely returns them to a server if that public key matches the key from the TLS certificate of the current TLS connection to the server. A similar approach called Web Server Key Enabled Cookies (WSKECookies) was presented by Masone et al. [79]. In this concept, the browser stores cook- ies along with the public key of the web server, which initially set them. A WSKECookie is only returned to a web server, which proved possession of the same key pair in following TLS sessions. In both concepts stolen web objects or WSKECookies are not cryptographically bound in any way – neither to the TLS channel nor to the client. Therefore, the attacker can potentially steal them and then use them to authenticate as the victim. In 2008, Gajek et al. [50] proposed a variant of a browser-based Kerberos scheme using TLS client certificates. The concept has been standardized as SAML Holder-of-Key Web Browser SSO Profile by OASIS1 [87]. In contrast to our proposed solution, the Holder-of-Key approach protects neither HTTP cookies nor password-based logins, but only the SAML assertion within the Single Sign-On based authentication. RFC 5929 [4] was published in 2010 as proposed standard. The document describes three channel binding types for TLS, namely tls-unique, tls-server- endpoint, and tls-unique-for-telnet. TLS-unique specifies the API for our pro- posed binding solutions.
1https://www.oasis-open.org/
125 A solution specifically designed for channel bindings within SAML frame- works has been described in [63]. In 2012, Dietz et al. [38] proposed a TLS channel binding called Origin- Bound Certificates (OBC) by using a TLS extension. Their approach changes server authenticated TLS channels into mutually authenticated channels by using client certificates created on the fly by the browser. In consequence, their idea requires changes to the TLS protocol, which would affect all current TLS implementations. They propose to use the issued OBC by cryptographically binding them to HTTP cookies or SSO tokens. Google introduced another TLS extension called Channel ID [9], which again requires fundamental changes to underlying TLS implementations. In sum- mary, the browser creates an additional asymmetric key pair during the TLS handshake and uses the private key to sign all handshake messages up to the ChangeCipherSpec message. Subsequently, the signature, along with the pub- lic key, is sent encrypted through the TLS channel using the established TLS key material. This is done, before finishing the TLS handshake. The browser uses the public key as ”Channel ID” that identifies the TLS connection. In 2015, the Internet Engineering Task Force (IETF) introduced the successor of the Channel ID by publishing the first draft of the Token Binding Protocol. The new mechanism combines existing concepts related to TLS Unique, Origin- Bound Certificates, and Channel ID. The current documentation is available in separate documents [70, 71, 97, 98]. In 2013, OASIS published the SAML Channel Binding Extensions allowing the use of channel bindings in conjunction with SAML [105]. This document allows us to integrate the proposed TLS channel bindings in all SAML related services, e.g., SSO. In 2014, Bhargavan et al. discovered a new vulnerability in TLS allowing an attacker to establish different connections with honest participants that have the same FIN value [13]. Thus, the authors of the paper can bypass the protection mechanisms of TLS Unique. In 2016, Bhargavan and Leurent discovered a new attack class of transcript collision attacks on key exchange protocols and demonstrated concrete attacks on TLS 1.2 client authentication, TLS 1.3 server authentication, and TLS channel bindings [12]. The introduced attacks can bypass the protection of HoK and TLS Unique and led to changes in the Token Binding specification [98] by moving to a stronger channel binding.
126 11 Conclusion and Future Work
In this chapter, we conclude the thesis by summarizing and evaluating our main results. First, we discuss our contribution on analyzing SSO by using a malicious IdP as presented in chapter 3. We summarize the lessons learned by evaluating concrete attacks on different protocols. Finally, we discuss future work and new research areas related to SSO.
Malicious IdPs in Single Sign-On This thesis presented a novel concept for analyzing SSO protocols called malicious IdP. The concept introduces the possi- bility to force a SP to use an IdP controlled by the attacker, which can deviate from the normal behavior, and issue invalid messages and authentication to- kens. We successfully applied this attack concept on three SSO protocols – OpenID Connect, OpenID, and SAML. As a result, we discovered novel attacks bypassing the security of the authentication process and breaking the End-User authentication.
Attacks on Single Sign-On Protocols We presented different attacks on OpenID Connect, OpenID, and SAML, which we categorized in Single-Phase Attacks and Cross-Phase Attacks. Single-Phase Attacks abuse one particular step in the protocol or the verification process, whereby the result can be seen directly. In contrast, Cross-Phase Attacks are more complex and require deep under- standing of the SSO protocol. Such attacks abuse the lack of relation between messages exchanged in different phases of the protocol. Due to their complexity, they are hard to be discovered and barely studied. To the best of our knowledge, we are the first systematically analyzing and evaluating Cross-Phase Attacks in SSO. The applicability of all presented attacks was shown by successfully attacking different libraries, websites and frameworks. The existing security issues were addressed by the development of different penetration testing tools enabling the security analysis and discovery of the presented attacks in an automated manner. The discovered vulnerabilities were responsibly disclosed to the developer or security teams. As a result, numerous widely deployed products like Drupal [18], OwnCloud [24], OXID WebShop [95], Slashdot [25] were fixed and multiple CVEs have been applied [19, 20, 21, 22, 23, 26, 27, 28, 29, 30, 31, 124, 125, 126]. The author cooperated with the Internet Engineering Task Force (IETF) OAuth and OpenID Connect working groups and supported these fixing the discovered specification flow in OpenID Connect [73].
127 Future Work In our security analysis, we addressed problems related to XML parsers. Technologies like JSON could be a valuable target, too. For example, JSON introduces similar technologies like JSLT [3], which is a JavaScript alter- native to XSLT or JSON Schema [60] related to XML Schema. Thus, many of the attacks introduced in this thesis could be adapted on JSON. The develop- ment of a systematic approach to analyze JSON and a comprehensive security analysis could discover interesting and unknown issues. We introduced attacks on SSO. The question rises, whether the concepts can be applied on other multi-party protocols. For example, Cashier-as-a-Service is a valuable target since the architecture is similar to SSO. A cashier, for example PayPal, acts as trusted third party and is used to transfer money to a shop. Thus, a cashier can be compared to an IdP authenticating the End-User and authorizing the money transfer. The shop acts as an SP. By using a malicious cashier controlled by the attacker, the security of many shops can be analyzed. TLS channel bindings introduce a desired feature to strengthen bearer to- kens. Thus, large companies like Google, Microsoft and PayPal currently work on specifying mechanisms cryptographically binding the HTTP with the TLS channel [97]. With respect to the security, an analysis of these new mechanisms and the existing implementations is a valuable target and should be addressed by future researches.
128 12 Bibliography
[1] Devdatta Akhawe, Adam Barth, Peifung E Lam, John Mitchell, and Dawn Song. Towards a formal foundation of web security. In Com- puter Security Foundations Symposium (CSF), 2010 23rd IEEE, pages 290–304. IEEE, 2010.
[2] Dmitry Chastukhin Alexander Polyakov. Ssrf vs. business-critical applications: Xxe tunneling in sap. BlackHat, 2012. URL https://media.blackhat.com/bh-us-12/Briefings/Polyakov/ BH_US_12_Polyakov_SSRF_Business_Slides.pdf.
[3] Dion Almaer. Jslt: A javascript alternative to xslt, 2007. URL http:// ajaxian.com/archives/jslt-a-javascript-alternative-to-xslt.
[4] J. Altman, N. Williams, and L. Zhu. Channel Bindings for TLS. RFC 5929 (Proposed Standard), July 2010. URL http://www.ietf.org/rfc/ rfc5929.txt.
[5] Alessandro Armando, Roberto Carbone, Luca Compagna, Jorge Cuellar, and Llanos Tobarra. Formal analysis of saml 2.0 web browser single sign- on: Breaking the saml-based single sign-on for google apps. In Proceedings of the 6th ACM Workshop on Formal Methods in Security Engineering, FMSE ’08, pages 1–10, New York, NY, USA, 2008. ACM. ISBN 978-1- 60558-288-7. doi: 10.1145/1456396.1456397. URL http://doi.acm.org/ 10.1145/1456396.1456397.
[6] Alessandro Armando, Roberto Carbone, Luca Compagna, Jorge Cuellar, Giancarlo Pellegrino, and Alessandro Sorniotti. From multiple credentials to browser-based single sign-on: Are we more secure? In IFIP Inter- national Information Security Conference, pages 68–79. Springer Berlin Heidelberg, 2011.
[7] Armando, Alessandro and Carbone, Roberto and Compagna, Luca and Cu´ellar, Jorge and Tobarra, M. Llanos. SAML: CVE-2008- 3891. http://www.cvedetails.com, September 2008. URL http://www. cvedetails.com/cve/CVE-2008-3891/.
[8] Authors of the submission. Openid connect. security considerations, http://bit.ly/sec_oidc. Technical report, 2016. URL http://bit. ly/oidc_sec.
129 [9] D. Balfanz and R. Hamilton. Transport Layer Security (TLS) Channel IDs. Internet-Draft, November 2012. URL http://tools.ietf.org/ html/draft-balfanz-tls-channelid-00.
[10] Chetan Bansal, Karthikeyan Bhargavan, and Sergio Maffeis. Discovering concrete attacks on website authorization by formal analysis. In Pro- ceedings of the 2012 IEEE 25th Computer Security Foundations Sympo- sium, CSF ’12, pages 247–262, Washington, DC, USA, 2012. IEEE Com- puter Society. ISBN 978-0-7695-4718-3. doi: 10.1109/CSF.2012.27. URL http://dx.doi.org/10.1109/CSF.2012.27.
[11] A. Barth. HTTP State Management Mechanism. RFC 6265 (Proposed Standard), April 2011. URL http://www.ietf.org/rfc/rfc6265.txt.
[12] Karthikeyan Bhargavan and Ga¨etan Leurent. Transcript collision attacks: Breaking authentication in tls, ike, and ssh. In Network and Distributed System Security Symposium (NDSS), 2016. URL https://mitls.org/ downloads/transcript-collisions.pdf.
[13] Karthikeyan Bhargavan, Antoine Delignat Lavaud, C´edric Fournet, Alfredo Pironti, and Pierre Yves Strub. Triple handshakes and cookie cutters: Breaking and fixing authentication over tls. In Security and Privacy (SP), 2014 IEEE Symposium on, pages 98– 113. IEEE, 2014. URL https://hal.inria.fr/hal-01102259/file/ triple-handshakes-and-cookie-cutters-oakland14.pdf.
[15] Scott Cantor and Rod Widdowson. Identity provider discovery service protocol and profile, March 2008. URL http://www.oasis-open.org/ committees/download.php/28049/sstc-saml-idp-discovery-cs-01. pdf.
[16] Suresh Chari, Charanjit S. Jutla, and Arnab Roy 0003. Universally com- posable security analysis of oauth v2.0. page 526, 2011.
[17] Eric Chen, Yutong Pei, Shuo Chen, Yuan Tian, Robert Kotcher, and Patrick Tague. Oauth demystied for mobile application developers. In Proceedings of the ACM Conference on Computer and Communications Security (CCS). ACM - Association for Computing Machinery, Novem- ber 2014. URL http://research.microsoft.com/apps/pubs/default. aspx?id=231728.
[18] Christian Mainka and Vladislav Mladenov. CVE-2014-1475. http://www.cvedetails.com, 2014. URL http://www.cvedetails.com.
[19] Christian Mainka and Vladislav Mladenov. CVE-2014-2048, 2014. URL http://www.cvedetails.com.
130 [20] Christian Mainka and Vladislav Mladenov. CVE-2014-8249, 2014. URL http://www.cvedetails.com. [21] Christian Mainka and Vladislav Mladenov. CVE-2014-8251, 2014. URL http://www.cvedetails.com. [22] Christian Mainka and Vladislav Mladenov. CVE-2014-8252, 2014. URL http://www.cvedetails.com. [23] Christian Mainka and Vladislav Mladenov. CVE-2014-8254, 2014. URL http://www.cvedetails.com. [24] Christian Mainka and Vladislav Mladenov. Insecure openid implemen- tation (oc-sa-2014-002), 2014. URL http://owncloud.org/security/ advisory/?id=oC-SA-2014-002. [25] Christian Mainka and Vladislav Mladenov. Slashdot acknowledgement, 2014. URL http://beta.slashdot.org/journal/1083427. [26] Christian Mainka and Vladislav Mladenov. CVE-2015-0959, 2015. URL http://www.cvedetails.com. [27] Christian Mainka and Vladislav Mladenov. CVE-2015-0960, 2015. URL http://www.cvedetails.com. [28] Christian Mainka, Vladislav Mladenov, Florian Feldmann, Julian Krautwald. Instructure Advisory IAC00722 - SAML Ruby gem vul- nerability, Feb 2014. URL https://help.instructure.com/entries/ 46981014-Instructure-Advisory-IAC00722-SAML-Ruby-gem-vulnerability. [29] Christian Mainka, Vladislav Mladenov, Florian Feldmann, Julian Krautwald. SAML attacks on Canvas interface, Feb 2014. URL https://help.instructure.com/entries/ 26920510-Instructure-Advisory-IAC44584-SAML-Signature-Wrapping. [30] Christian Mainka, Vladislav Mladenov, Florian Feldmann, Julian Kraut- wald. SAML attacks on Clarizen interface, Feb 2014. URL http: //www.clarizen.com/security-log.html. [31] Christian Mainka, Vladislav Mladenov, Florian Feldmann, Julian Krautwald. Multiple CVEs: VU 190556, VRF HXR9YUNY,VRF HXRAH4O0,VU 774084,VRF HXRAND04, 2014. [32] CloudReviews. CloudReviews, 2014. URL http://www.cloudreviews. com/. [33] Mozilla Corporation. Browserid specification. Technical report, http://www.mozilla.org, 2011. URL https://github.com/mozilla/ id-specs/blob/prod/browserid/index.md. [34] Mozilla Corporation. Persona is no longer actively developed by mozilla, November 2016. URL https://developer.mozilla.org/ en-US/Persona.
[36] Arkajit Dey and Stephen Weis. Pseudoid: Enhancing privacy in federated login. Hot topics in privacy enhancing technologies, pages 95–107, 2010.
[37] T. Dierks and E. Rescorla. The Transport Layer Security (TLS) Protocol Version 1.2. RFC 5246 (Proposed Standard), August 2008. URL http: //www.ietf.org/rfc/rfc5246.txt. Updated by RFCs 5746, 5878, 6176, 7465, 7507, 7568, 7627, 7685.
[38] Michael Dietz, Alexei Czeskis, Dirk Balfanz, and Dan S. Wallach. Origin- Bound Certificates: A Fresh Approach to Strong Client Authentication for the Web. In In Proceedings of the 21. USENIX Security Symposium, Security’12, pages 16–16, Berkeley, CA, USA, 2012. USENIX Association. URL http://dl.acm.org/citation.cfm?id=2362793.2362809.
[39] Egor Homakov. How we hacked Facebook with OAuth2 and Chrome bugs, Februrary 2013. URL http://homakov.blogspot.ca/2013/02/ hacking-facebook-with-oauth2-and-chrome.html.
[41] Golnaz Elahi, Zeev Lieber, and Eric Yu. Trade-off analysis of identity management systems with an untrusted identity provider. In Computer Software and Applications, 2008. COMPSAC’08. 32nd Annual IEEE In- ternational, pages 661–666. IEEE, 2008.
[42] Andreas Falkenberg, Christian Mainka, Juraj Somorovsky, and Jorg Schwenk. A new approach towards dos penetration testing on web ser- vices. 2013 IEEE 20th International Conference on Web Services, 0, 2013. doi: http://doi.ieeecomputersociety.org/10.1109/ICWS.2013.72.
[43] Dennis Felsch, Christian Mainka, Vladislav Mladenov, and J¨org Schwenk. Secret: On the feasibility of a secure, efficient, and collaborative real-time web editor. In ACM Asia Conference on Computer and Communications Security (ASIACCS), 2016.
[44] Daniel Fett, Ralf K¨usters, and Guido Schmitz. Paper: An Expressive Model for the Web Infrastructure: Definition and Application to the BrowserID SSO System. In 35th IEEE Symposium on Security and Pri- vacy (S&P 2014). IEEE Computer Society, 2014.
[45] Daniel Fett, Ralf K¨usters, and Guido Schmitz. A comprehensive formal security analysis of OAuth 2.0. arXiv preprint arXiv:1601.01229, 2016.
132 [46] Daniel Fett, Ralf K¨usters, and Guido Schmitz. A comprehensive formal security analysis of oauth 2.0. In ACM Conference on Computer and Communications Security (CCS), 2016. [47] OpenID Foundation. Openid connect 1.0: Libraries, products, tools, Jan- uary 2016. URL http://openid.net/developers/libraries/. [48] OpenID Foundation. Openid certification, April 2017. URL http:// openid.net/certification/. [49] Kevin Fu, Emil Sit, Kendra Smith, and Nick Feamster. Dos and Don’ts of Client Authentication on the Web. In In Proceedings of the 23th USENIX Security Symposium, Washington D.C., 2001. [50] Sebastian Gajek, Tibor Jager, Mark Manulis, and J¨org Schwenk. A browser-based Kerberos authentication scheme. In Sushil Jajodia and Javier L´opez, editors, Computer Security - ESORICS 2008, 13th Euro- pean Symposium on Research in Computer Security, M´alaga, Spain, Oc- tober 6-8, 2008. Proceedings, volume 5283 of Lecture Notes in Computer Science, pages 115–129. Springer, August 2008. [51] Thomas Groß. Security analysis of the saml single sign-on browser/arti- fact profile. In Computer Security Applications Conference, 2003. Pro- ceedings. 19th Annual, pages 298–307. IEEE, 2003. [52] Thomas Groß and Birgit Pfitzmann. Saml artifact information flow re- visited. In In IEEE Workshop on Web Services Security (WSSS), pages 84–100, 2006. [53] B. Guangdong. AUTHSCAN: Automatic Extraction of Web Authentica- tion Protocols from Implementations. In Network and Distributed System Security Symposium (NDSS), February 2013. [54] Frederick Hirsch, Rob Philpott, and Eve Maler. Security and Pri- vacy Considerations for the OASIS Security Assertion Markup. Lan- guage (SAML) V2.0, March 2005. URL http://docs.oasis-open.org/ security/saml/v2.0/saml-sec-consider-2.0-os.pdf. [55] Frederick Hirsch, David Solo, Joseph Reagle, Donald Eastlake, and Thomas Roessler. XML Signature Syntax and Processing (Second Edi- tion). W3C recommendation, W3C, June 2008. URL http://www.w3. org/TR/2008/REC-xmldsig-core-20080610/. [56] Egor Homakov. How I hacked Github again, Februrary 2014. URL http: //homakov.blogspot.de/2014/02/how-i-hacked-github-again. html. [57] Detlef H¨uhnlein, J¨org Schwenk, Tobias Wich, Vladislav Mladenov, Flo- rian Feldmann, Andreas Mayer, Johannes Schm¨olz, Bud Bruegger, and Moritz Horsch. Options for integrating eid and saml. In Proceedings of the 2013 ACM workshop on Digital identity management, pages 85–96. ACM, 2013.
133 [58] M. Jones, N. Sakimura, and J. Bradley. Oauth 2.0 authorization server metadata. IETF, August 2016. URL https://tools.ietf.org/html/ draft-ietf-oauth-discovery-04.
[59] Chris K. Karlof, Umesh Shankar, Doug Tygar, and David Wagner. Dy- namic pharming attacks and the locked same-origin policies for web browsers. Technical Report UCB/EECS-2007-52, EECS Department, University of California, Berkeley, May 2007. URL http://www.eecs. berkeley.edu/Pubs/TechRpts/2007/EECS-2007-52.html.
[60] Kashyap. An introduction to json schema, 2014. URL http://crypt.codemancers.com/posts/ 2014-02-11-An-introduction-to-json-schema/.
[61] Michael Kay. XSL Transformations (XSLT) Version 2.0 (Second Edition). W3C proposed edited recommendation, W3C, April 2009. URL http: //www.w3.org/TR/2009/PER-xslt20-20090421/.
[62] Zubair Ahmad Khattak, Suziah Sulaiman, and JA Manan. A study on threat model for federated identities in federated identity management system. In Information Technology (ITSim), 2010 International Sympo- sium in, volume 2, pages 618–623. IEEE, 2010.
[63] Florian Kohlar, J¨org Schwenk, Meiko Jensen, and Sebastian Gajek. Se- cure Bindings of SAML Assertions to TLS Sessions. In ARES, pages 62–69, 2010.
[64] Eduard Kovacs. Yahoo patches ssrf vulnerability in image processing system: Researcher, June 2015. URL http://www.securityweek.com/ yahoo-patches-ssrf-vulnerability-image-processing-system-researcher.
[65] Julian Krautwald. Single sign-on – openid connect(ing) people. Master, Ruhr-University Bochum, September 2014.
[66] Wanpeng Li and Chris J. Mitchell. Analysing the security of google’s implementation of openid connect. In Proceedings of the 13th Interna- tional Conference on Detection of Intrusions and Malware, and Vulner- ability Assessment - Volume 9721, DIMVA 2016, pages 357–376, New York, NY, USA, 2016. Springer-Verlag New York, Inc. ISBN 978-3-319- 40666-4. doi: 10.1007/978-3-319-40667-1 18. URL http://dx.doi.org/ 10.1007/978-3-319-40667-1_18.
[67] Xiaowei Li and Yuan Xue. Block: A black-box approach for detection of state violation attacks towards web applications. In Proceedings of the 27th Annual Computer Security Applications Conference, ACSAC ’11, New York, NY, USA, 2011. ACM. ISBN 978-1-4503-0672-0. doi: 10. 1145/2076732.2076767. URL http://doi.acm.org/10.1145/2076732. 2076767.
134 [68] Alex X. Liu, Jason M. Kovacs, Chin-Tser Huang, and Mohamed G. Gouda. A Secure Cookie Protocol. In Proceedings of the 14th IEEE International Conference on Computer Communications and Networks, pages 333–338, San Diego, California, October 2005. URL http://www. cs.utexas.edu/users/alex/publications/.
[69] Lukas Reschke, P´adraic Brady, Enrico Zimuel. Potential XXE/XEE attacks using PHP functions: simplexml load *, DOMDocument::loadXML, and xml parse, March 2014. URL http://framework.zend.com/security/advisory/ZF2014-01.
[70] B. Campbell M. Jones, J. Bradley. Oauth 2.0 token bind- ing, July 2016. URL https://tools.ietf.org/html/ draft-jones-oauth-token-binding-00.
[71] B. Campbell M. Jones, J. Bradley. Openid connect token bound authentication 1.0, July 2016. URL http://openid.net/specs/ openid-connect-token-bound-authentication-1_0.html.
[72] H. Tschofenig M. Jones, J. Bradley. Proof-of-possession key semantics for json web tokens (jwts), April 2016. URL https://tools.ietf.org/ html/rfc7800.
[73] J. Bradley M. Jones. Oauth 2.0 mix-up mitigation, January 2016. URL https://tools.ietf.org/html/ draft-jones-oauth-mix-up-mitigation-01.
[74] Christian Mainka, Vladislav Mladenov, Juraj Somorovsky, and J¨org Schwenk. Penetration test tool for xml-based web services. In ESSoS Doctoral Symposium 2013, page 31, 2013.
[75] Christian Mainka, Vladislav Mladenov, Florian Feldmann, Julian Kraut- wald, and J¨org Schwenk. Your software at my service: Security analysis of SaaS single sign-on solutions in the cloud. In Proceedings of the 6th Edition of the ACM Workshop on Cloud Computing Security, CCSW ’14, 2014. doi: 10.1145/2664168.2664172. URL http://doi.acm.org/10. 1145/2664168.2664172.
[76] Christian Mainka, Vladislav Mladenov, Tim Guenther, and J¨org Schwenk. Automatic recognition, processing and attacking of single sign-on proto- cols with burp suite. Open Identity Summit, 2015.
[77] Christian Mainka, Vladislav Mladenov, and Christian Kossmann. Openid attacker, source code and executable, 2015. URL https://github.com/ RUB-NDS/OpenID-Attacker.
[78] Christian Mainka, Vladislav Mladenov, and J¨org Schwenk. Do not trust me: Using malicious IdPs for analyzing and attacking single sign-on. In IEEE European Symposium on Security and Privacy (EuroS&P 2016), 2016.
135 [79] Chris Masone, Kwang-Hyun Baek, and Sean Smith. WSKE: web server key enabled cookies. In Proceedings of the 11th International Con- ference on Financial cryptography and 1st International conference on Usable Security, FC’07/USEC’07, pages 294–306, Berlin, Heidelberg, 2007. Springer-Verlag. ISBN 3-540-77365-7, 978-3-540-77365-8. URL http://dl.acm.org/citation.cfm?id=1785594.1785634.
[80] Andreas Mayer, Vladislav Mladenov, J¨org Schwenk, Florian Feldmann, and Christopher Meyer. Strengthening web authentication through tls- beyond tls client certificates.
[81] Andreas Mayer, Vladislav Mladenov, and J¨org Schwenk. On the security of holder-of-key single sign-on. In Sicherheit, pages 65–77. Citeseer, 2014.
[82] Andreas Mayer, Marcus Niemietz, Vladislav Mladenov, and J¨org Schwenk. Guardians of the clouds: When identity providers fail. In Proceedings of the 6th Edition of the ACM Workshop on Cloud Com- puting Security, CCSW ’14, pages 105–116, New York, NY, USA, 2014. ACM. ISBN 978-1-4503-3239-2. doi: 10.1145/2664168.2664171. URL http://doi.acm.org/10.1145/2664168.2664171.
[83] Michael McIntosh and Paula Austel. XML Signature Element Wrapping Attacks and Countermeasures. In SWS ’05: Proceedings of the 2005 workshop on Secure web services, pages 20–27, New York, NY, USA, 2005. ACM Press. doi: http://doi.acm.org/10.1145/1103022.1103026.
[84] Tim McLean. Critical vulnerabilities in json web token li- braries, March 2015. URL https://auth0.com/blog/2015/03/31/ critical-vulnerabilities-in-json-web-token-libraries/.
[85] Vladislav Mladenov, Christian Mainka, Tobias Wich, and J¨org Schwenk. Sok: Single sign-on security – an evaluation of openid connect. In 2017 IEEE European Symposium on Security and Privacy (EuroS&P), 2017.
[86] Jens M¨uller, Vladislav Mladenov, Juraj Somorovsky, and J¨org Schwenk. Printer security. In 38th IEEE Symposium on Security and Privacy (S&P 2017), Oktober 2017.
[87] Tom Scavo Nate Klingenstein. Saml v2.0 holder-of-key web browser sso profile version 1.0, August 2010. URL http://docs.oasis-open.org/ security/saml/Post2.0/sstc-saml-holder-of-key-browser-sso. pdf.
[88] Ben Newman and Shivaram Lingamneni. Cs259 final project: Openid (session swapping attack), 2008. URL http://www.stanford.edu/ class/cs259/projects/cs259-final-newmanb-slingamn/report. pdf.
[89] Nir Goldshlager. How I Hacked Facebook OAuth To Get Full Per- mission On Any Facebook Account (Without App ”Allow” Interac-
136 tion), February 2013. URL http://www.nirgoldshlager.com/2013/02/ how-i-hacked-facebook-oauth-to-get-full.html.
[90] Nir Goldshlager. How I Hacked Any Facebook Account...Again!, March 2013. URL http://www.nirgoldshlager.com/2013/03/ how-i-hacked-any-facebook-accountagain.html.
[91] Ruhsan Onder and Zeki Bayram. XSLT version 2.0 is turing-complete: A purely transformation based proof. In Implementation and Application of Automata, pages 275–276. Springer, 2006.
[96] Joon S. Park and Ravi S. Sandhu. Secure Cookies on the Web. IEEE Internet Computing, 4(4):36–44, 2000.
[97] A. Popov, D. Balfanz, A. Langley, and J. Hodges. Token bind- ing over http, August 2016. URL https://tools.ietf.org/html/ draft-ietf-tokbind-https-06.
[98] A. Popov, D. Balfanz, A. Langley, and J. Hodges. The token binding protocol version 1.0, September 2016. URL https://tools.ietf.org/ html/draft-ietf-tokbind-protocol-10.
[99] N Sakimura, J Bradley, and M Jones. Openid connect dy- namic client registration 1.0, 2013. URL http://openid.net/specs/ openid-connect-registration-1_0.html.
[100] N Sakimura, J Bradley, and E. Jay. Openid connect dis- covery 1.0, November 2014. URL https://openid.net/specs/ openid-connect-discovery-1_0.html.
[101] Natsuhiko Sakimura, J Bradley, M Jones, B de Medeiros, and C Morti- more. Openid connect core 1.0, 2014. URL http://openid.net/specs/ openid-connect-core-1_0.html.
[102] Benjamin Sanno. Automated penetration testing for saml-based sso frameworks. Master thesis, Ruhr-University Bochum, December 2012.
137 [103] Rob Philpott Eve Maler Scott Cantor, Jahan Moreh. Meta- data for the oasis security assertion markup language (saml) v2.0, March 2005. URL http://docs.oasis-open.org/security/saml/v2. 0/saml-metadata-2.0-os.pdf.
[104] Rob Philpott Eve Maler Scott Cantor, John Kemp. Assertions and protocols for the oasis security assertion markup language (saml) v2.0, March 2005. URL http://docs.oasis-open.org/security/saml/v2. 0/saml-core-2.0-os.pdf.
[105] Rob Philpott Eve Maler Scott Cantor, John Kemp. Saml v2.0 channel binding extensions version 1.0, July 2013. URL http://docs.oasis-open.org/security/saml/Post2.0/ saml-channel-binding-ext/v1.0/saml-channel-binding-ext-v1. 0.pdf.
[106] Shubham Shah. Accessing paypal’s internal network - the crit- ical nature of ssrf, January 2014. URL http://shubh.am/ demonstrating-the-critical-nature-of-ssrf---accessing-paypal’ s-internal-network-2/.
[107] Ethan Shernan, Henry Carter, Dave Tian, Patrick Traynor, and Kevin Butler. More guidelines than rules: Csrf vulnerabilities from noncompli- ant oauth 2.0 implementations. In Detection of Intrusions and Malware, and Vulnerability Assessment, pages 239–260. Springer, 2015.
[108] Reginaldo Silva. XXE in OpenID: one bug to rule them all, or how I found a Remote Code Execution flaw affecting Facebook’s servers. http://www.ubercomp.com/posts/2014-01-16_facebook_ remote_code_execution, 01 2014.
[109] Quinn Slack and Roy Frostig. Oauth 2.0 implicit grant flow, 2011. URL http://web.stanford.edu/class/cs259/WWW11/.
[110] Juraj Somorovsky, Mario Heiderich, Meiko Jensen, J¨org Schwenk, Nils Gruschka, and Luigi Lo Iacono. All your clouds are belong to us – security analysis of cloud management interfaces. In The ACM Cloud Computing Security Workshop (CCSW), October 2011.
[111] Juraj Somorovsky, Andreas Mayer, J¨org Schwenk, Marco Kampmann, and Meiko Jensen. On breaking saml: Be whoever you want to be. In In Proceedings of the 21. USENIX Security Symposium, Bellevue, WA, August 2012.
[112] Christopher Sp¨ath, Christian Mainka, Vladislav Mladenov, and J¨org Schwenk. Sok: Xml parser vulnerabilities. In 10th USENIX Workshop on Offensive Technologies (WOOT 16), Austin, TX, 2016.
[114] C. M. Sperberg-McQueen, Henry S. Thompson, Murray Maloney, Henry S. Thompson, David Beech, Noah Mendelsohn, and Shudi (Sandy) Gao. W3C XML Schema Definition Language (XSD) 1.1 Part 1: Struc- tures. Last call WD, W3C, December 2009. URL http://www.w3.org/ TR/2009/WD-xmlschema11-1-20091203/.
[115] David Strom. Single sign-on moves to the cloud, 2012. URL http://www.networkworld.com/article/2161919/access-control/ single-sign-on-moves-to-the-cloud.html.
[116] Avinash Sudhodanan, Alessandro Armando, Roberto Carbone, and Luca Compagna. Attack patterns for black-box security test- ing of multi-party web applications. In 23nd Annual Network and Distributed System Security Symposium, NDSS 2016, San Diego, California, USA, February 21-24, 2016, 2016. URL http: //www.internetsociety.org/sites/default/files/blogs-media/ attack-patterns-black-box-security-testing-multi-party-web-applications. pdf.
[117] Sullivan. Security briefs - xml denial of service attacks and defenses. https://msdn.microsoft.com/en-us/magazine/ee335713.aspx, 2009.
[118] San-Tsai Sun and Konstantin Beznosov. The Devil is in the (Imple- mentation) Details: An Empirical Analysis of OAuth SSO Systems. In Proceedings of the 2012 ACM conference on Computer and com- munications security, CCS ’12, pages 378–390, New York, NY, USA, 2012. ISBN 978-1-4503-1651-4. doi: 10.1145/2382196.2382238. URL http://doi.acm.org/10.1145/2382196.2382238.
[119] San-Tsai Sun, Kirstie Hawkey, and Konstantin Beznosov. Systematically breaking and fixing openid security: Formal analysis, semi-automated em- pirical evaluation, and practical countermeasures. Computers & Security, 31(4), 2012. URL http://dblp.uni-trier.de/db/journals/compsec/ compsec31.html#SunHB12.
[120] P. Hunt T. Lodderstedt, M. McGloin. Oauth 2.0 threat model and se- curity considerations, January 2013. URL https://tools.ietf.org/ html/rfc6819.
[121] Talkin’ Cloud. Top 100 Cloud Services Providers (CSPs) List And Re- search, 2014. URL http://talkincloud.com/tc100.
[122] Omar Al Ibrahim Timothy D. Morgan. Xml schema, dtd, and entity attacks. Technical report, VSR, May 2014. URL https://vsecurity. com//download/papers/XMLDTDEntityAttacks.pdf.
139 [123] Bart van Delft and Martijn Oostdijk. A security analysis of openid. In Elisabeth de Leeuw, Simone Fischer-Huebner, S.bner, and Lothar Fritsch, editors, Policies and Research in Identity Management, volume 343 of IFIP Advances in Information and Communication Technology, pages 73–84. Springer Berlin Heidelberg, 2010. ISBN 978-3-642-17302-8. doi: 10.1007/978-3-642-17303-5 6. URL http://dx.doi.org/10.1007/ 978-3-642-17303-5_6. [124] Vladislav Mladenov and Christian Mainka. CVE-2014-8250, 2014. URL http://www.cvedetails.com. [125] Vladislav Mladenov and Christian Mainka. CVE-2014-8253, 2014. URL http://www.cvedetails.com. [126] Vladislav Mladenov and Christian Mainka. Fixing id spoofing and recip- ient confusion in joid, 2014. URL https://code.google.com/p/joid/ source/detail?r=220. [127] Jing Wang. Covert redirect vulnerability, May 2014. URL http: //tetraph.com/covert_redirect/. [128] Rui Wang, Shuo Chen, and XiaoFeng Wang. Signing Me onto Your Ac- counts through Facebook and Google: a Traffic-Guided Security Study of Commercially Deployed Single-Sign-On Web Services. In IEEE, editor, 33th IEEE Symposium on Security and Privacy (S&P 2012), 2012. [129] Rui Wang, Yuchen Zhou, Shuo Chen, Shaz Qadeer, David Evans, and Yuri Gurevich. Explicating sdks: Uncovering assumptions underlying secure authentication and authorization. In In Proceedings of the 22nd USENIX Security Symposium, SEC’13, Berkeley, CA, USA, 2013. USENIX Asso- ciation. ISBN 978-1-931971-03-4. URL http://dl.acm.org/citation. cfm?id=2534766.2534801. [130] Wikipedia. Cloud computing providers, 2014. URL http://en. wikipedia.org/wiki/Category:Cloud_computing_providers. [131] Wikipedia. Saml-based products and services. Wikipedia, March 2016. URL http://en.wikipedia.org/wiki/SAML-based_products_ and_services. [132] Luyi Xing, Yangyi Chen, XiaoFeng Wang, and Shuo Chen. Integuard: Toward automatic protection of third-party web service integrations. In NDSS, 2013. [133] David Evans Yuchen Zhou. Automated testing of web applications for single sign-on vulnerabilities. In In Proceedings of the 23rd USENIX Security Symposium, San Diego, CA, August 2014. USENIX Associa- tion. URL https://www.usenix.org/conference/usenixsecurity14/ technical-sessions/presentation/zhou. [134] Gavin Zuchlinski. The Anatomy of Cross Site Scripting. Hitchhiker’s World, 8, 2003.
140 List of Figures
2.1 SSO participants and their roles: Service Provider (SP), End- UserandIdentityProvider(IdP)...... 17 2.2 SSO in three phases: (1.) Trust Establishment, (2.) End-User authentication at the IdP, and (3.) End-User authentication at theSP...... 18 2.3 Dynamic Registration in OpenID Connect and establishing a shared secret used for the validation of the authentication to- ken...... 19 2.4 The trust establishment and key exchange in OpenID...... 20 2.5 Abstract overview of the End-User authentication at the IdP withinSSO...... 20 2.6 End-User authentication at the SP by verifying the authentica- tiontoken...... 21 2.7 Authentication tokens contain information regarding the: (1) Is- suer of the authentication token and the authenticated End-User, (2) Freshness, (3) The attended recipient, and (4) Integrity pro- tection...... 22
3.1 In the SSO ecosystem, there exist multiple End-Users, SPs, and IdPs communicating with each other...... 23 3.2 Malicious IdPs and their role in the SSO ecosystem...... 24 3.3 Malicious IdPs: The Eval module acts as a malicious IdP. Thus, it controls each message in each phase of the protocol...... 25 3.4 Formal Analysis...... 26 3.5 Code Analysis...... 27 3.6 Message invariants...... 28
4.1 Overview of the attacker types: AT1, AT2, AT3, and AT4. . . . 32
5.1 Overview of the different modules related to the authentication process on the target provider...... 35 5.2 The attacker sends an XML document containing malicious code, which points to a file stored on the local filesystem. As a result, the attacker breaks out of the usual processing schema, bypasses the security verification provided by the SSO-Verificator plus the AAM, and reads locally stored files...... 40 5.3 Single-Phase Attacks are started in one phase and the result of the attack occurs in the same phase...... 43 5.4 Cross-Phase Attacks are started in one phase, but the result of the attack occurs in a different phase...... 43
6.1 Phase 2 and Phase 3 in the OpenID Connect protocol flow. . . . 47 6.2 The OpenID Connect Discovery phase influences all other phases. 55
141 6.3 IdP Confusion Cross-Phase Attack: Logical flaw in the OpenID Connect specification...... 56 6.4 Malicious Endpoints Attack. By manipulating the Discovery, the attacker steals the code...... 58 6.5 Comparison of the memory consumption on an SP by (a) working normally and (b) under DoS attack by using Malicious Endpoints. 60 6.6 Issuer Confusion Cross-Phase Attack: The attacker uses his ma- licious IdP to store the wrong issuer at the SP in Phase 1. In Phase 3, it issues an authentication token containing the identity ofthevictim...... 61 6.7 TestscenariowhenusingPrOfESSOS...... 66
7.1 The OpenID protocol flow...... 72 7.2 Login Window starting the OpenID authentication at an SP. . . 73 7.3 IDS started within the discovery document returned in Phase 3. 78 7.4 KC attack: Before the authentication token is forwarded in Step 3.2, the attacker starts a second login request with victim’s iden- tity on the honest IdP (https://idp.com). This action over- writes the information stored in $ SESSION regarding the respon- sibleIdPandpreventsthere-discovery...... 82 7.5 Statistics of our online website evaluation...... 86 7.6 OpenID Attacker offers three operation modes – analysis, manual and automatic mode...... 87 7.7 Graphical Interface of OpenID Attacker...... 88 7.8 Security report generated by OpenID Attacker summarizing the results of the executed attacks...... 89
8.1 The protocol flow in SAML depicting Phase 2 and Phase 3. . . . 92 8.2 An overview of a SAMLResponse ...... 93 8.3 (a) and (b) ...... 94 8.4 Signature Exclusion (a) and Certificate Faking (b) ...... 97 8.5 The authentication token is signed for a user Bob. Via XSW the attacker can inject a second Assertion containing another identity (e.g., admin). The verification logic will verify the Assertion pointed by the Ref, which is valid. The business logic (SSO Processor) will process the injected (malicious) Assertion. . . . . 98 8.6 XSLTA payload that reads the /etc/passwd file and forwards its content to an attacker controlled server...... 100 8.7 The SAML module is configured via the Web interface of the SP. The certificate of the trusted IdP and the according endpoints can be uploaded and stored in the AAM module...... 102
9.1 TLS Handshake Phase and Application Phase...... 112 9.2 HTTP cookies bound to TLS Unique...... 114 9.3 Binding SSO authentication tokens to TLS Unique ...... 115 9.4 Using HoK to strengthen HTTP cookies ...... 118 9.5 Using HoK to strengthen SSO authentication tokens ...... 118
142 9.6 ...... 120
143
List of Tables
3.1 Comparison of existing approaches to analyze SSO protocols. . . 28
5.1 Overview of generic attacks on SSO protocols...... 38
6.1 Overview of the attacks on OpenID Connect described in this chapter...... 45 6.2 Security analysis results of officially referenced SPs libraries. Only 2 of 8 (25%) libraries implemented all required verification steps properly...... 62 6.3 Evaluation of the IdP OpenID Connect libraries – Applicable attacks...... 64 6.4 OpenID Provider Live Implementations - Applicable Attack-Scenarios 65 6.5 Configuration summary of Single-Phase and Cross-Phase Attacks supportedbyPrOfESSOS...... 67
7.1 Overview of the attacks on OpenID described in this chapter. . . 71 7.2 Practical evaluation results: unauthorized access on 12 out of 17 targets. We compromised 2 targets relying on AT3. The other 10 targets make use of a weaker variant – AT1 – and do not require any user interaction...... 85
8.1 Overview of the attacks on SAML described in this chapter. . . . 91 8.2 Results of our practical evaluation. We evaluated 22 SPs against 8 different attacks: (1.) Signature Exclusion (∅Sig) (2.) Certifi- cate Injection (CInj) (3.) XML External Entity Attack (XXEA) (4.) XSLT Attack (XSLTA) (5.) Replay Attack (6.) XML Sig- nature Wrapping (XSW) (7.) Token Recipient Confusion (TRC) (8.) Certificate Injection (CInj). 20 of them were vulnerable to at least one attack so that we could successfully access unautho- rizedresources...... 105 8.3 Results of our practical evaluation...... 107
145
Listings
5.1 An XML-Bomb based on the Billion Laughs Attack [117]. . . . . 40 5.2 Infinite loop by two entities referencing to each other...... 41 5.3 FileAccessbyusingXMLEntities...... 41 5.4 The XML document sent by the attacker to the server containing parameter Entities, which will be concatenated...... 42 5.5 The file stored on http://attacker.com/parameterEntity.dtd 42 5.6 Enforcing the server to send a local file to a URL...... 42 5.7 The file stored on http://attacker.com/parameterEntity_oob. dtd ...... 42
6.1 An example of the AuthnReq generated by the SP and sent to theIdPviaanHTTPRedirect...... 47 6.2 An example of the AuthnResponse generated by the IdP and sent totheIdPviaanHTTPRedirect...... 48 6.3 id token in OpenID Connect issued by the IdP and send to the SP...... 48 6.4 Example of an AuthnReq containing claims, which have to be added [65]...... 53 6.5 Example of a malicious AuthnReq containing claims regarding an End-User reflected in the id token [65]...... 54 6.6 Endpoints returned by the malicious IdP ...... 58
7.1 An example of the HTML discovery document...... 73 7.2 An example of an XRDS discovery document...... 73 7.3 An example of the AuthnReq generated by the SP and sent to theIdPviaanHTTPRedirect...... 74 7.4 An example of the OpenID Token generated by the SP and sent totheIdPviaanHTTPRedirect...... 75 7.5 An example of the malicious authentication token generated by the malicious IdP (https://attackerIdP.com) and containing the identity of the victim controlled by other IdP (https://idp. com/bob)...... 77
8.1 Example of a SAML AuthnReq issued by the SP and sent to the IdP...... 92
9.1 A HoK id token in OpenID Connect issued by the IdP and send totheSP...... 121
