Many Online Social Networks (OSN) are using OAuth 2.0 to grant access to API endpoints nowadays. Despite many thorough threat model analyses (e.g. RFC6819), only a few real world attacks have been discovered and demonstrated. To our knowledge, previously discovered loopholes are all based on the misuse of OAuth. It was generally believed that the correct use of OAuth 2.0, e.g. by following RFC6819, is secure enough. We break this belief by demonstrating a massive leakage of user data which roots from the scotoma of OAuth’s fundamental design rationale: focus on protecting user, not protecting application.
We show that, even if OSN providers and application developers follow best practice, application impersonation is inevitable on many platforms: According to the OAuth 2.0 standard, they support implicit-authorization-grant flow and bearer-token usage. Although it has become common knowledge for application developers to use authorization-code-grant flow and use access token in a MAC-token style wherever possible, there is no mechanism for them to opt out from the OSN platforms’ support of implicit-authorization-grant flow and bearer-token usage. Since different applications may have different privileges like accessing permissions and rate limits, application impersonation in general enables privilege escalation and the consequence depends on platform-specific details.
As a proof-of-concept experiment, application impersonation has been demonstrated on a large-scale Facebook-like (not Facebook) OSN. Based on this technique, one can use a casual crawler to collect its 100-million-user social graph within just one week and the projected cost based on Amazon Web Service is just $150 USD. Due to its implementation specifics, similar techniques can be applied on this OSN to obtain other private data like all users’ status lists and albums. Note that, without privilege escalation, this amount of data (order of 108) cannot be obtained in such short time with such little cost even on open graphs like Twitter.
Our discovery shows that it is urgent for industrial practitioners to provide the two aforementioned opt-outs in OAuth and review their API design. This work also highlights that application protection must be considered in the design of the next version of OAuth, and similarly other Single-Sign-On protocols.
Many Online Social Networks (OSN) are using OAuth 2.0 to grant access to API endpoints nowadays. Despite of many thorough threat model analyses and security guidelines (e.g. RFC6819), most OSNs are still vulnerable to a variety of attacks. To our knowledge, previously discovered loopholes are all based on the misuse of OAuth 2.0 and some depend on provider-side or application-side faults beyond the scope of OAuth protocol, such as XSS and open redirector. It was generally believed that correct use of OAuth 2.0 (by OSN provider and application developer) is secure enough. However, we clarify this common misunderstanding by demonstrating various leakage of user data which roots from the blind-spot of the OAuth’s fundamental design rationale: OAuth focuses on protecting the user, not the application.
We show that, even if OSN providers and application developers follow the current best practice in using OAuth 2.0, application impersonation is still inevitable on many OSN platforms: According to the OAuth 2.0 standard, they support implicit-grant flow and bearer-token usage. Although it has become common knowledge for application developers to use authorization-code-grant flow and use access token in a MAC-token style wherever possible, there is no mechanism for them to opt out from the support of implicit-grant flow and bearer-token usage in an OSN platform. Note that different applications may have different privileges like accessing permissions and rate limits. Towards this end, application impersonation in general enables privilege escalation and the extent of the actual damage would depend on platform-specific details.
The OAuth 2.0 protocol has been adopted by mainstream Single-Sign-On services to support user authentication and authorization for 3rd party applications. Using OAuth 2.0, an identity provider (IdP) (e.g. Facebook) can grant data access privileges by issuing an “access token” to a third-party application (App) (e.g. Priceline) upon approval by the user. The App can then use the access token to retrieve the protected user data hosted by the IdP and thus assume the identity of the authorizing user without knowing his/ her log-in credential.
Due to the complexity of the multi-party interactions and trust relationships in OAuth 2.0, numerous security problems and practical attacks such as Covert Redirect and App Impersonation have been discovered recently. Worse still, many third-party application developers may not have the resource or know-how to properly implement OAuth-based services. As a result, the security analysis and testing of deployed OAuth 2.0 applications/systems have received increasing attention lately. However, all these studies either rely on manual analysis to discover new vulnerabilities in OAuth 2.0 implementations or perform automated testing for a limited set of specific, previously-known vulnerabilities across a large number of OAuth implementations. In contrast, we propose an adaptive model-based testing tool, OAuthTester, which enables the automatic discovery of vulnerabilities via systematic testing and evaluation of OAuth implementations.
Based on the OAuth protocol specification, we first construct an initial state-machine-based system model which abstracts and defines the expected behavior of the multi-party system, namely, the IdP, the 3rd-party App and the authorizing User. OAuthTester then automatically augments the initial model with implementation specifics extracted from network traces. Based on the resultant model, OAuthTester autonomously generates and executes test cases (in the form of HTTP request sequences) and collects responses from the IdP and App to adapt, augment as well as rectify the current system model in a self-learning manner. In particular, OAuthTester compares the expected behavior predicted by the current system model with the observed responses to determine whether the test target is vulnerable. Deviation of the observed responses from the predicted behavior is an indication that either 1) possible vulnerabilities are discovered or 2) the current model overlooks some situations/ corner cases of the system and OAuthTester would then rectify the system model automatically after confirming that no predefined security properties have been violated. OAuthTester continues this iterative process until all the paths in the evolving state machine have been covered.
Our adaptive model-based security testing provides a higher code coverage guarantee, which enables the discovery of new vulnerabilities while reducing the number of possible false negatives. Furthermore, our method enables one to substantially reduce the manual efforts required by large-scale security testing of OAuth implementations because our approach can cater for the implementation differences of practical OAuth systems via observations extracted from network traces.
Riding on the widespread user adoption of OAuth2.0-based Single-Sign-On (SSO) services for 3rd party websites, many major Identity Providers (IdPs) such as Facebook, Google and Sina, have recently adapted the OAuth2.0 protocol to support SSO for 3rd-party Mobile Apps on their social-media platform. However, due to the differences in the end-to-end system setup and operating environment for mobile app SSO services, the original OAuth2.0 protocol becomes under-specified. In particular, the OAuth2.0 standard does not cover or define the critical security requirements and protocol details to govern the interactions between the 3rd-party (client-side) mobile app and its corresponding backend server during the SSO process. As a result, various IdPs have developed different home-brewed extensions of OAuth2.0-based Application Programming Interface (API) to support SSO of 3rd-party mobile apps in their own platform. Unfortunately, the implicit security assumptions and operational requirements of such home-brewed adaptations/ APIs are often not clearly documented or well-understood by the 3rd-party mobile app developers. Worse still, there is also a lack of security-focused SSO-API-usage-guidelines for the 3rd-party app developers.
These problems have led us to discover a new type of widespread, insecure implementations of OAuth2.0-based SSO services among a large number of popular 3rd-party mobile apps which use various top-tier IdPs. The root cause of this vulnerability is a common, but misplaced trust in the authenticating information received by the 3rd party app’s backend server from its own client-side mobile app, which in turn, relies on potentially tampered information obtained from the client-side mobile app of the IdP. Leveraging on this newly discovered vulnerability, we have developed a remote exploit which enables an attacker to effortlessly sign into a victim’s mobile app account via OAuth2.01 without any need to trick or interact with the victim, for example via malicious apps or network eavesdropping, etc. While our current attack is demonstrated over the Android platform, the exploit itself is platform-agnostic: any iOS or Android user of the vulnerable mobile app is affected as long as he/ she has used the OAuth2.0-based SSO service with the app before.
The OAuth2.0 protocol was originally designed to serve the authorization need for 3rd-party websites. However, many major Identity Providers (IdPs) such as Facebook, Google and Sina, have recently adapted the OAuth2.0-based protocols to support Single-Sign-On (SSO) services for 3rd-party mobile apps (which take the role of Relying Party under the context of OAuth2.0). When OAuth2.0 is used as a SSO scheme, a user can log into the mobile Relying Party (RP), e.g., IMDB, via the IdP without sharing the identity credential with the RP. In this paper, we will focus on OAuth2.0 and OpenID Connect (which is built on top of OAuth2.0), since they are the de facto SSO standards.
To support SSO services with 3rd-party mobile apps, the security of the adapted OAuth2.0 protocol has been evaluated by the literature. Prior studies mainly focus on how the differences of mobile systems (i.e., vulnerabilities in the system-provided components) can compromise mobile SSO systems. However, the security implications resulting from the major protocol changes, when adapting the OAuth2.0-based protocols to mobile platforms, are often left out. For example, the standard OAuth2.0 implicit flow has shown to be insecure for authentication and thus a revised version, i.e., a variant of OpenID Connect (OIDC), is recommended. Nevertheless, they do not consider that the SSO results, even in the revised version, are passed through the user device. Consequently, these security-critical results are subject to tampering and further enable an adversary to infer the program logic of the RP server.
Towards this end, the goal of this research is to further the understanding of (1) how the changes of OAuth1 protocol flow, if not well implemented, can lead to nontrivial security flaws, (2) the overall security quality of mobile SSO systems by checking whether existing vulnerabilities have been fixed or not. Our work consists of two pillars: (1) We perform a standard static code analysis of three first-tier Android IdP apps (Facebook, Google and Sina) and their corresponding SDKs widely used by the RP to understand their client-side program logic. (2) We develop a tool to dynamically test Top-600 US and Chinese Android apps to see how well the RP/IdP servers perform the OAuth transactions.
Single Sign-On (SSO) protocols like OAuth2.0 and OpenID Connect have been widely adopted to simplify user authentication and service authorization for third-party applications. Motivated by the prevalence of SSO services, main-stream Identity Providers (IdPs) like Google and Facebook, have provided their Software Development Kits (SDKs) to facilitate the implementation of third party services (e.g. IMBD and Uber), which are referred to as the Relying Parties (RP) under the SSO framework.
To further enhance flexibility, some high-profile open source projects have integrated SSO SDK modules from different IdPs so that an RP application can readily support multiple IdPs at the same time. These SDKs are the core component of SSO services and have enjoyed millions of downloads.
Typically, an SSO SDK provider would release the source code of its SDK and provide documentations, together with simple usage examples. It then leaves the rest to the RP developers. Without fully understanding the SDK internals, most RP developers simply follow the sample codes to invoke the SDK functions. As such, one important question is that: Is an SSO SDK itself secure? Note that if the internals of a SDK already contain vulnerabilities, then all RP applications using the vulnerable SDK become susceptible. Given the popularity of these SDKs and the nature of SSO services, any security breach can lead to critical implications. For example, an attacker may be able to log into billions of user accounts.
The goal of this work is to systematically test whether an SSO SDK is vulnerable by itself. We will focus on the logic vulnerabilities of a SDK, which allow an attacker to log into RP applications as a victim. To the best of our knowledge, this is the first work to analyze the SSO SDKs. Most existing work on SSO security does not analyze the code of the SSO system, let alone the SDK. More specifically, there are mainly two types of work in the literature. The first type reasons about the specification of the standard SSO protocols by different methods including model checking, cryptographic proof and manual analyses. The other type aims to discover vulnerabilities of real-world SSO implementations via network traffic analysis and large-scale automated testing. The former does not care about the SSO implementation, and the latter treats the implementation as a black box. Consequently, both cannot detect logic flaws buried deep in the SSO SDKs.
To this end, this paper introduces S3KVetter, a tool which automatically identifies vulnerabilities in the SSO SDK internals. Our key insight is to leverage dynamic symbolic execution, a widely used technique for program analysis, to track feasible execution paths and the associated predicates of the SSO SDK under test. For each path, S3KVetter then utilizes a theorem prover to check whether the predicates violate SSO security properties. Although these techniques have been heavily studied, they cannot be directly applied to SSO-like applications due to the multi-party nature and multiple-lock-step operations of SSO services. We have thus developed new techniques including request order scheduling and multi-party coordination for this kind of multi-party applications.
We have implemented a full-featured prototype of S3KVetter and applied it to check 10 popular SSO SDKs. These SDKs are all carefully engineered and enjoy a large number of downloads. They support different SSO protocols (OAuth2.0 or OpenID Connect) and various grant flows (authorization code flow and implicit flow). To our surprise, S3KVetter has discovered, among these security-focused SDKs, 7 classes of serious logic vulnerabilities and 4 of them are previously unknown. The security impact can range from sniffing user activities at the RP, to the total hijacking of the victim’s RP account.